Google Cloud Next Tokyo 2018 講演資料

1. D1-2-S07
オンプレミスのデータウェアハウス基盤を
BigQuery へ
常田秀明
クラウドエバンジェリスト・日本情報通信株式会社
9月19日

2. 常田秀明
日本情報通信株式会社
バリューインテグレーション本部
クラウド・テクニカルエバンジェリスト
今年のテーマは既存アプリのモダナイゼーション（理想はあれど実装
は泥臭い世界、データをどうするかがとても難しい）
好きなサービスは、PaaS全般。ノンコーディングツールも好き。
Photo
Speaker

3. Agenda
● なぜ BigQuery を選択するのか
● どのように BigQuery に移行するのか
● まとめ

4. 1 なぜ BigQuery を選択する
のか
既存のデータウェアハウスの持つ課題と BigQuery の
特徴を理解する

5. オンプレミスのDWHの歴史
RDBMS
DWH
Data
Data
RDBMS
Data Warehouse データの倉庫
専用アプライアンスの登場
蓄積されたデータの利活用
BI/BA(Business Analytics)
の歴史
企業内の様々なデータ
複雑でかつ指数的に増加

6. BI/BA(Business Analytics)から見る
データウェアハウス
RDBMS
Data
Data
RDBMS
データソース BI/BA(Business
Analytics)
構造化データレイク
データマート
(分析結果の書き込み）
ETL
クレンジング
ETL
データ集約
Data Wherehouse
データ
処理エンジン

7. オンプレミスDWHの課題
● 容量
● コスト
● 技術的な課題

8. HadoopとDWHの世界
非構造化データレイク
HDFS/クラウドストレージ
（膨大な領域)
運用コストが高い→導入後に高いハードル
(ソフトウェア OSS)
MapReduse→Spark/Hive(SQL)
データ処理エンジン
データ分析ソフトウェア
構造化データレイク
（限られた領域)
アプライアンスDWH
製品コストが高い→導入前に高いハードル
(Teradata、Oracle Exadata、HP Verticaなど)
主にSQLベース
データ処理エンジン
データ分析ソフトウェア

9. BigQuery とは
● 分散型データストアから進化した列
指向データウェアハウス
● フルマネージドサービス
● ペタバイトデータの処理可能
● SQL対応、ML対応

10. BigQuery とは
● Hadoopほど「箱」ではない、
RDBMSほど「スキーマ固定」ではな
い。程よい「箱」
● 仕組みとしても、コスト面でもデータ
の倉庫として始めやすい（ゆるく始
められる）
● 「クラウド」的なサービス
基礎技術としての分散データストア
構造化データレイク
（膨大な容量)
データ処理エンジン
Spark/MapReduce/Excel
等のコネクタ
Hadoopの良いところをもった DWH
運用コストも導入コストも安い
SQL準拠

11. DWHとしての BigQuery 既存BAツール
構造化データレイク
データマート
ETL
クレンジング
BigQuery
データ
処理エンジン
● 既存BAツールのデータマートとし
てはまだ使いづらい
● 無制限に格納できる構造化デー
タレイク
● 様々な処理を BigQuery 側で行う
ことで最適化出来る
頻繁な分析結果
の読み書き
クラウド世代の
BIツール
処理は極力
BigQueryで実施
データ処理エンジン

12. 気になるポイントを解決
従来のDWH/RDBMSが持っている機能を提供
1. バックアップの提供
2. データの暗号化
3. ユーザ行動の監査
4. きめ細かいアクセス制御

13. オンプレミスDWHから BigQuery へ
検討すべき3つの項目
1. 既存業務の継続性担保
2. 処理性能担保
3. 大容量の移行方式の確立

14. 分析ソフトウェアと BigQuery 接続の注意点
● 分析ソフトウェアの利用を検討している場合、BigQuery のもつ性能を
最大限に活用出来るかを評価する。
○ BigQuery 対応状況
○ BigQuery の特性を考慮すること

15. 既存の製品特性を理解して BigQuery へ
DWHアプライアンス BigQuery 影響
構造 行指向 列指向 DMLの性能特性が異なる
インデックス なし なし 列指向ではデータ＝インデックスとなる。クエリ性能に差異
キャッシュ なし あり 繰り返し処理の性能に差異
データ分散キー あり なし 結合処理の性能に差異
パーティショニング なし
ゾーンマップが類似
あり
分割テーブル
Netezzaソートキー＝ BigQuery パーティションキーとなる
マテリアライズド
ビュー
あり なし 特定クエリ性能に差異
費用 － ストレージ、クエリ量に
よる課金
テーブルの物理分割で費用低減
注意) 弊社比較

16. [Database]変更に伴う影響
検討項目抜粋

17. 数値からみる BigQuery の特性
単位(sec) / 傾向としての参考値 (Read処理) 弊社比較

18. 移行のモチベーション
● コスト
○ 利用した分だけ課金、スモールスタート可能
● パフォーマンス
○ 同時並行（リソースという概念がない）
● ビジネスの俊敏性
○ バージョンアップなど保守不要、フルマネージ、スケール

19. 2 どのように BigQuery に移
行するのか
業務継続を考慮しながらどのように移行計画を立案す
べきか

20. オンプレミスDWHから BigQuery へ
検討すべき3つの項目
1. 既存業務の継続性担保
2. 処理性能担保
3. 大容量の移行方式の確立
a. 利用しているシステムを止められない
b. データがTB以上存在

21. データ種類からみる2段階の移行
更新されないデータが対象、いつでも移行可能
1 . 事前移行
システム処理やユーザ操作により更新される可能性があるデータが対象
更新されないことを担保する必要があるためシステム停止が必要
2 . 切替移行

22. ケーススタディ
● データセンタは都内
● システム停止は12時間以内
● データ総量量は、5TB(非圧縮30TB)
● 専用線未契約
● データの80%以上はBIでユーザ部門が利用
● BigQuery はUSリージョンを利用

23. ケーススタディ
Data
Source群
DataWhar
ehouse
データ移行
DataPrep
ETL
接続先切替 接続先切替
BIツール
分析アプリケーション
※本資料ではこの「データ移行」について話をします
Data
Source群Data
Source群

24. DWHの中のデータ種類
データマート
(利用部門の用途
により最適化）
データレイク
(構造化データ）
過去データ
現在利用データ
更新なし
更新あり
月次
日次
切替時に静止が必
要

25. データ種別分類の方法
表：切替時対象の調査シート例

26. データ移行の考え方

27. Google Cloud Platform
(Region に注意）作業エリア
Data Center
データ移行のシステム面での制約
「切替移行」に割り当てられる「時間」を把握する
DWH 媒体
Data Export
媒体
搬送
Cloud
Storage
BigQuery
転送
(専用回線)
GCS 経由の
読み込み
Transfer
Appliance
USでは利用可能

28. 事前移行
(a) Google Cloud Storage を経由した一括登録(1)
ポイント
● GCS 経由が早い
● 非圧縮ファイルが優位
● GCS-BQ はリージョン影響を
受けにくい(近い GCSを利
用）
Cloud
Storage
Cloud
Functions
BigQuery
DC (On-premise)
DHW
Export
Transfer
Transfer
(Internet or
専用線)
一時保管

29. 事前移行
(a) Google Cloud Storage を経由した一括登録(2)
留意点
● 既存DWHからのエクスポート
が時間的にも媒体接続におい
てもボトルネック
● 専用線が利用できない場合に
は転送速度がボトルネックに
なる（並列で転送を検討） 図：GCS 転送と BQ Load の時間差を最小限に制御

30. 切替移行
(b) Dataflow を利用した BQ 読み込み
ポイント
● レコード単位でクレンジング
等の処理を追加可能
● BigQuery のStreaming機能
でデータ追加が可能
● Java/Pythonで記述( DWH側
のライブラリ必要)
BigQuery
DC (On-premise)
DHW
Export
Transfer
Dataflowから
DWHに接続
Cloud
Dataflow

31. 切替移行
(c) API(Cli)を利用した BQ 読み込み
メリット
● 処理がシンプル
● 端末からの直接データアップ
ロードが可能
BigQuery
DC (On-premise)
DHW
Export
Transfer
Transfer
(Internet or
専用線)

32. 切替移行
(d) Dataprepを利用した BQ 読み込み
メリット
● 学習コストが低い(GUI)
● データソースに対してデータ
加工が可能
● 多重処理が可能 (処理の実
態は Dataflow)
DC (On-premise)
DHW
Cloud
Dataprep
BigQuery
Cloud
Dataflow

33. 切替移行
(e) ETLを利用した BQ 読み込み
メリット
● 恒常的なデータ連携として利
用可能
● GUIで設定可能
● 購入が容易(Marketplaceか
ら提供,SaaSではないため外
部にデータが送信されない）
https://www.matillion.com/

34. データ移行計画
図：システム停止時間後の業務データの反映
● システム移行後の既存DWH
の利用方針を決める
● 停止時間とデータロードの時
間が足りない場合には更に
仕組みを考える
● データソース側の切替計画

35. 3 まとめ

36. まとめ
● オンプレミスDWHから BigQuery に移行するポイント
○ BQ の製品特性を理解してBI製品（分析アプリケーション) の構築
及び選定を行うことで最大限にメリットを享受出来る
● 移行実施する際に検討すべきポイント
○ 全体データ量の棚卸し
○ 静止点におけるデータ量を最小化（移行対象データを利用する業
務部門との調整）

37. 日本情報通信株式会社の取り組み
BigQuery

38. ブース紹介
プリンスパークタワー東京 ブース番号12

39. Thank you.