『bq_sushi tokyo #7』に登壇しました。 BigQueryのプロダクトマネージャーである Chad Jennings 氏と、リードエンジニアである Ahmed Ayad 氏がBQについて解説を行うという素晴らしいイベントでした。

スライド

「ゆるやかにBigQuery（データ基盤）を安定活用するプラクティス集」

Shunketsu Oh 氏との共同発表となります。私1人の成果ではなくチームの成果をあくまでも代表してお伝えしているだけです。 PyCon JP 2017でベストトークアワード優秀賞を受賞した発表（構築編）の続き（運用編）です。

主な内容

過去の発表の再掲
- データの民主化
- データ基盤のサービスレベル
- データ集計業務へのスタートアップ手法の適用
システム保守運用Tips

yuzutas0.hatenablog.com

技術志向のエンジニアからは「これはBQの発表なのか？」と言われそうですが「BQをビジネスに活用するとはこういうことだ！」と胸を張って返したいです。と、あえて言わずにはいられないほど内心ビクビクしていたのですが、運営の@kumakumakkkさんや@satoluxxさんが場を盛り上げてくださって、心理的安全性が保たれた状態で話すことができました。

スライド抜粋

※新規発表となる システム保守運用Tips のみ取り上げます。他トピックは発表スライドや過去エントリーを参照ください。

f:id:yuzutas0:20180530082807p:plain

技術要素としては脱PythonでSQLに回帰したほうが移植性・保守性・処理パフォーマンスが向上するという話。

f:id:yuzutas0:20180530082828p:plain

データは3層構造（データレイク、データウェアハウス、データマート）で管理するのが常套手段だが

システムがデータを処理する流れ
人間が段階的に設計を進化させる開発プロセスの流れ

これらの流れの向きは違うという話。

f:id:yuzutas0:20180530082845p:plain

機械学習をビジネス活用するに当たって「何か1つのすごい判断システム」が出来るのではなく

あくまでも業務フローの一部を置き換えるものなので、手作業やシステム判断が混合した業務フローが出来る
なおかつ業務フローの最初と最後で機械学習に食わせるデータや実現可能な性能要件が違う

ということに気付かずに非効率な開発をしてしまったという話。

実況抜粋

BigQuery, DataStudio, SpreadSheetでプロトタイプを適当に作って、実際に必要なのかを見てみるのは正しい気がする #bq_sushi
— しんめたる (@sinmetal) 2018年4月24日

データ案件は小さく試して大きくしていく #bq_sushi
— kiyo (@chidakiyo) 2018年4月24日

SQL万能論！ワカル！#bq_sushi
— なかむらさとる (@satoluxx) 2018年4月24日

#bq_sushi 軽く始めるのはたしかに重要だね、うん。軽く始めて設計を始める。特にデータを経験がない会社とかは。まず勘所探すみたいな感じはいい。
— kuma (@kumakumakkk) 2018年4月24日

SQL設計手法とProlog

SQL で WITH 句を積み重ねていくと Prolog を書いている気持ちになりますよね#bq_sushi
— _ (@apstndb) 2018年4月24日

Prologという言語の存在を初めて知って調べてみました。

Prologは「事物(Object)」と事物間の「関係(relation)」に関する問題を解くために使われるプログラミング言語。プログラムを「宣言的に」表現できる。他の言語では「手続き的に」表現している。自然言語解析や、理解、推論などの人工知能の分野で有効。

http://nw.tsuda.ac.jp/lec/prolog/intro/

確かにこれは今のプログラミング言語のパラダイムとは若干違いますね。以下が私のチームで推奨しているSQLの設計方法となります。

f:id:yuzutas0:20180530084652p:plain