GCPUG Okinawaで使った資料です。

1. BigQueryで実現する
データ統合
なかむら さとる

2. 自己紹介
● 名前：
なかむら さとる
● 経歴：
Groovenauts,inc.所属
元某小売系のインフラ・システム運用エンジニア
● その他：
Google Developers Experts(Cloud)

3. ところでみなさん

4. データがどこで生まれて
どんな処理を経て

5. だれが使ってるのか
（何に使ってる）

6. 知ってますか？

7. 分散されたシステム

8. 分散されたシステム

9. 分散されたシステム

10. こんなシステムのよく
ある問題

11. 同じデータでも色々違う
商品価格:
Price
float
nullable
商品価格:
kakaku
int64
required

12. 作った人がもう居ない（わからない）

13. 影響範囲がわからない（え？そこ？）

14. 見ている数字が違う
売上：100万円
売上：50万円
売上：140万円

15. 欲しい数字がすぐに出ない
A
B
AとBのかけ合わせた数字を
明日の朝までに♡
無理です。
もしくは時間が。。。
このデータも入れてよ☆
好きにデータ出したい ☆(ゝω･)v

16. まだまだあるよ もうディスクが逼迫して
どないしたらええねん
使う人が多くなって処理能力が
セキュリティはきっちりな
お金ないよぉ。老朽化

17. さてどうしましょうか

18. BigQueryがあるじゃないか

19. BigQueryの仕組み
■The 12 Components of Google BigQuery
https://medium.com/google-cloud/the-12-c
omponents-of-google-bigquery-c2b49829a7
c7
■重要なコンポーネント
・Dremel（クエリエンジン）
・Colossus（ストレージエンジン）
・Jupiter（ネットワーク）
・Borg（大規模コンテナ・クラスタ管理）

20. サーバレス・サービスモデル
● 完全なサーバレスモデルである
○ ハードウェア、機能アップデートの管理はすべて Googleが行う
○ VMやCPU、メモリ、ディスクサイズなどの設定も不要
○ 数秒で数十万コアを利用することが出来る
○ 利用者はデータを入れること、抽出することだけを考える

21. 独自のストレージエンジン
● Colossus
○ GFS(Google File System)の後継
○ データセンター規模でのファイルシステム
○ GmailやDocsなどと同じインフラ
○ 同じデータを3箇所のデータセンターにレプリケーション
○ データのシャーディング
○ 暗号化
● Capacitor
○ カラムナーストレージフォーマット
○ データの最適化（並べ替えなど）
○ テーブルパーティショニング
● Poseidon
○ 様々なファイルフォーマットへの対応
（CSV,JSON,Avro,DataStore）
○ クエリとインポート/エクスポートの分離

22. Dremelというクエリエンジン
● 2015年にアップデート
● 最初はBigQuery独自のSQLだけでしたが、Standard-SQLにも対応
（※今後はStandard-SQLを利用、オプティマイザを実装）
● シャッフルやソートはインメモリで実施
● Borgで管理
● いつでも元気にフルスキャン

23. 独立したストレージとネットワーク
● Jupiterネットワーク
○ Googleが独自に開発したネットワーク（ H/W,S/Wともに）
○ 1Pb/secの帯域
○ 謎技術。。。。。（SDNであることは間違いない）
○ ストレージはネットワークで接続

24. 費用について
● クエリ課金
○ クエリ毎に利用したカラムに対するデータ容量で課金
○ 月額固定料金
● ストレージ課金
○ データ容量に対して課金
○ 90日以上変更の無いテーブルはデータ容量に対しての課金が半額
● ストリーミングインサート
○ バッチでInsertするのではなく、1行ずつ個別にいれるデータ量にたいして課金
● https://cloud.google.com/bigquery/pricing?hl=ja#transfer

25. IAMと認証、監査ログ
● Google CloudのIAMと権限の連携（Read/Write/Admin）
● DataSet単位での権限付け
● 認証はO-Authとサービスアカウント
● すべての操作を監査ログで保存し、BigQueryへExportも可能

26. 祝☆Tokyoリージョン
● 国内で初めてのリージョン（待ち望んでいた！）
● 海外にデータはちょっとと言う人向け
（多分性能はそんなにかわらない）

27. じゃ、どうする？

28. システム部門だけでやらない
● 経営者に納得してもらう
● 宣言して周りを巻き込む
● 周りが出来ると思わない、システム部門が歩み寄る

29. 同じデータでも色々
違う問題

30. 色んな方法で解決できる
● BigQueryのクエリで解決
● Dataprepでやっちゃう
● Dataflowでやっちゃう

31. データ・ディクショナリの作成
● 言語（言い方）を統一する
● ちゃんとみんなが見えるところでドキュメント化する
● メタデータ（説明とか）を充実させる

32. 欲しい数字がすぐに
出ない問題

33. 現場の人に直接やってもらう
● データを開放してやってもらう
● 例えばDataStudioとか
● 例えばDataprepとか

34. つまりどうなるの？

35. 色んな効果が出てきます。
● 数字が出るスピードがあがります
● システム部門は色んな心配から開放されます
● つまり生産性があがります
● そうすると新しい発想が生まれます！

36. ありがとうございました。