[Cloud OnAir] BigQuery の仕組みからベストプラクティスまでのご紹介 2018年9月6日放送

Cloud Onr
Cloud OnAir
Cloud OnAir
BigQuery の仕組みから
ベストプラクティスまでのご紹介
2018 年 9 月 6 日放送

Agenda
Cloud OnAir
1
3
2
4
BigQuery とは？
BigQuery の仕組み
BigQuery & Data ベストプラクティス
Enterprise Data Warehouse としての BigQuery

Cloud OnAir
Cloud OnAir
BigQuery とは？

Cloud OnAir
1 PB はどれくらい大きいのか ?
4G モバイル回線で
ダウンロード
すると 27 年かかる
27 years
フロッピーディスクを積み上
げると、六本木ヒルズ
森タワーのおよそ20 倍
x20
アメリカ議会図書館
100 個分
100
Twitter のこれまでの
ツイートすべてを
合わせた量の50 倍
x50

Cloud OnAir
では、1 PB はどれくらい ”小さい” のか ?
YouTube にアップロードされる
動画の1日分
2 マイクログラムの DNA 200 台のサーバーが毎秒 50 の
エントリをロギングして 3 年分

Cloud OnAir
経済的: 支払いは使用するクエリ
処理とストレージに対してのみ
フルマネージドのデータウェアハウス: オ
ペレーション担当者不要、
ペタバイト規模
信頼性: Google データセンターに
おけるサポート
1
2
3
BigQuery はペタバイト規模のデータ分析ウェアハウス

Cloud OnAir
スケーラブル: 高度な並列処理
モデルによってクエリを高速化
セキュリティ: ACL、データは
トランスポート層で暗号化されて保存
監査可能: すべてのトランザクションはログ
に記録され、クエリ可能
4
5
6

Cloud OnAir
一般公開データセット : 実際のデータセット
で演習（NOAA、IRS、GitHub、NYC Taxi な
ど）
フレキシブル: 複数のデータセットをま
たいでデータをマッシュアップ
使いやすい:
使い慣れた SQL、インデックス不要
7
8
9

Cloud OnAir
BigQuery の歴史
2006 2012

Cloud OnAir
2002 2004 2005 2006 2008 2010 2012 2014 2015
GFS Map Reduce BigTable PubSub Flume Java Millwheel Tensorflow
Google Papers
DataflowDremel
10 年以上にわたるビッグデータへの取り組み

Cloud OnAir
Dremel
Google が自社のビッグデータを扱う為に開発した技術 = Dremel が
BigQuery の元になっている
Dremel
● 大規模並列クエリインフラ
○ Dremel: 2006 年より社内運用開始
○ BigQuery: 2012年リリース
● 高速な検索
○ 数百億件のフルスキャンが
　　　　　数十秒で完了
● インデックス不要
○ すべてフルスキャン
○ アドホックな分析

Cloud OnAir
Cloud OnAir
BigQuery の仕組み

Cloud OnAir
BigQuery
Analysis
Google 独自の内部
Dremel クエリエンジンテ
クノロジーに基づく高速で
大規模な並列SQL エンジ
ン
BigQuery
マネージドストレージ
Google のサービス
(Ads や Gmail など)の
データを格納しているのと同じテ
クノロジーを
基盤とするフルマネージドのス
ケーラブルなデータ
ストレージ
BigQuery は実際には 2 つのサービスが一体化されたもの

Cloud OnAir
BigQuery のストレージはカラム指向ストレージ
Relational database BigQuery Storage
● 各列は個別の圧縮された暗号化ファイルに
保存され、各ファイルは複製される
● インデックス、キーまたはパーティションは不要
● レコード指向のストレージ
● トランザクションの更新をサポート

Cloud OnAir
SQL:2011
Compliant
高速ネットワーク(Jupiter)
BigQuery 高可用性
クラスタコンピュート(Dremel)
ストリーミング
インサート
バルク
ロード
分散ストレージ
REST API
Client
Libraries
In 7
languages
Web UI, CLI分散メモリシャッフ
ル
ストレージとコンピュートを分離して柔軟性を確保
アーキテクチャ

Cloud OnAir
パフォーマンスの最大化
シャッフルする仕組み
Worker
Worker
GROUP BY
state COUNT(*)
SELECT
state
Worker
Worker
Worker
WHERE year...
SHUFFLE BY state
● 複雑なクエリのパフォーマンスの向
上
● 多くのデータを JOIN
● スケーラビリティの確保
分散ストレージ
処理スピードとクエリパフォーマンスの最大化
コンテナ
クラスタ
コンテナ
クラスタ

Cloud OnAir
マネージドストレージ
自動バックアップによる耐久性と永続的なストレージ
3
2
1
3
21 3
2
1
Table 1 Table 2 Table 3
Zone A Zone B Zone C
Region
● テーブルは最適化された
カラムナー形式で格納
● 各テーブルは圧縮され、ディス
ク上で暗号化される
● 各テーブルはデータ
センター間で複製

Cloud OnAir
サンプルクエリの処理
SELECT
state,
COUNT(*) as babyCount
FROM [publicdata:samples.natality]
WHERE
year >= 1980 AND year < 1990
GROUP BY state
ORDER BY babyCount DESC
LIMIT 10
1980年から1990年の
間に生まれた赤ちゃんの
数が最も多い10州の
リストを生成。
各州別の内訳を表示。

Cloud OnAir
● このクエリでは、2つの
フィールドだけを読み込む必要が
ある（州と年）。
● 分散ファイルシステムでは、
シャードはデータのチャンクを
並行して読み込む。
● 各シャードはローカルで
集約したデータを中間シャードに
渡すだけで良いため、データ量は
50 States に削減される。
● ルートマスターは、最終的な集約、
ソート、制限、およびクライアントへのデータ
の返却を行う。SELECT state, year
~138M Rows
COUNT(*)
GROUP BY state
WHERE year >= 1980 and year < 1990
~3.5K Rows
LIMIT 10
ORDER BY count_babies DESC
COUNT(*)
GROUP BY state
COUNT(*)
GROUP BY state
Distributed Storage
Shard Shard ShardShard
Shard ShardShard Shard
Master
50 States
サンプルクエリの処理 : クエリの並行処理

Cloud OnAir
階層構造 - Project
Dataset (organization, access control)
Job (query, import, export, copy)
Project (billing, top-level container)
Table (data with schema)
● オブジェクトの Root Namespace
● 課金管理、ユーザ管理、ユーザ権限管理
● 1 つ以上の Dataset を持つ
● Job を持つ
● ACL ( Access Control List ) をもつ

Cloud OnAir
階層構造 - Dataset
● Table や View の集合を持つ
● データセットのすべての tables/views にアク
セスコントロールが適用
● ACLs は Readers, Writers と Owners
Project のメンバー以外にアクセス権を
与えることが可能

Cloud OnAir
● 行と列の集合
○ マネージドストレージにデータ格納
○ スキーマを持つ
● Views をサポート
○ SQL クエリで Virtual tables を定義
● テーブルは外部に持てる (federated)
○ Google Cloud Storage 等を
直接クエリできる
階層構造 - Table

Cloud OnAir
● 長時間実行の可能性があるものに使われる
● Examples:
○ クエリ
○ データのインポート、エクスポート
○ データのコピー
● キャンセル可能
階層構造 - Job

Cloud OnAir
ユーザインタフェース
● GUI BigQuery 管理コンソール
● CLI（bqコマンド)
● Cloud Datalab
● Google Data Studio
● 3rd パーティツール (Tableau, Qlikview, R etc. )
● API (RESTful API + 各種言語ライブラリ）

Cloud OnAir
bq コマンド
● Python ベースのコマンドラインツール
● Google Cloud SDK にバンドル
● bq コマンドの主な機能
○ cp : テーブルのコピー
○ extract : ファイル出力
○ insert : 行の挿入
○ load : ファイルのロード
○ query: クエリの実行
○ rm: テーブルの削除
$ bq query ‘select count(*) from
publicdata:samples.shakespeare’

Cloud OnAir
API クライアントライブラリ

Cloud OnAir
Cloud OnAir
BigQuery & Data
ベストプラクティス

Cloud OnAir
Cloud OnAir
Best Practice
データの取り込み

Cloud OnAir
データの取り込み - データソース
● Google Cloud Storage (GCS)
● アップロード (POST request)
● Google Cloud Datastore のバックアップ
● Google Analytics Premium
● Stackdriver Logging からのログエクスポート
● Firebase
<POST>

Cloud OnAir
データの取り込み - 手法
Data Loading
● データをジョブでまとめて取り込む
Streaming Insert
● リアルタイムに近い方式でデータを取り込む
共通のポイント
● 両者ともクエリ実行環境とはリソース分離
● データ取り込み/クエリ実行のパフォーマンスは互いに影響しない

Cloud OnAir
データの取り込み - 手法
[ Consistency | Availability | Speed | Cost ]はトレードオフ:
Consistency Availability Speed Cost
Data Loading
スループット最適化
強整合性
Load Jobが完了し
たらすぐ使える
ジョブが完了しない
と読み込めない
Free
Streaming Insert
レイテンシー最適化
結果整合性
Insert から分析
まで数 ms 秒リアルタイム $0.05/GB*month

Cloud OnAir
大規模データの取り込み
Data Loading
● Google Cloud Storage (GCS) を経由してロード
○ BigQuery の Loading Job は Upload と Table への挿入の 2 要素
○ どちらかが失敗すると Upload からやり直しになるので、 GCS を経由することが推奨される
○ 同リージョンの GCS - BigQuery のロードは Upload よりも非常に高速
Streaming Insert
● 10 万行/秒 * Project, 1 万行 / 秒 * Table のクォータを超えないよう設計
● Cloud Pub/Sub を利用してキューイング、スロットリング

Cloud OnAir
大規模データの取り込み - クォータ
変更できないクォータはアーキテクチャ設計で対応
● ロードジョブの最大サイズ :
○ ファイルを分割 or 制限のより大きな形式に変更
○ Avro: block size で 16 MB, CSV: row と cell で 2 MB
● すべてのテーブルクォータ:
○ ストリーミングインサート
■ 1 秒あたりの最大行数 (1万行） / table
■ 1 秒あたりの最大バイト数 (100MB)/ table
○ ロードジョブ
■ 1日あたりの最大ロードオペレーション数 (1000) / table / day

Cloud OnAir
大規模データの取り込み - クォータ
クォータ変更のリクエスト: API Managerより実施

Cloud OnAir
データの取り込み
On Premise
Other Cloud Service
BigQuery
Stream Insert
Data Load
Loading
Storage and Databases
Cloud
Storage
Server
Instance
Cloud
Storage
SQL
Database
Cloud
Pub/Sub
Bq
Command,
3rd pary tools
etc.
Storage
Transfer
Service
Cloud
Dataflow

Cloud OnAir
データのフォーマット
データフォーマット
● CSV
● JSON
● Apache Avro
圧縮の有無
● 非圧縮
● gzip [Avro は対象外]
エンコードについての制約もあり
{JSON}
CSV

Cloud OnAir
データフォーマットのベストプラクティス
ロードの高速化:
● Avro はロードが 10 倍程度高速
● CSV の場合は Encode を UTF-8 にする
○ ISO-8859-1 などの場合、BigQuery で変換処理が行われるので遅くなる
● 非圧縮でロードする
○ gzip はロードパフォーマンスが落ちる

Cloud OnAir
データを加工してからの BigQuery へのデータ取り込み
Pub/Sub 等からのロード, ETL 処理を行いたい
● Cloud Dataflow , Cloud Dataprep を利用
Cloud Dataflow
● Batch, Streaming 処理を Apache Beam のコードで記述可能な
マネージドサービス
● Cloud Pub/Sub より BigQuery への挿入を行うためにも利用できる
● BigQuery UDF で並列実行できる数にヒットする場合にも検討
● 複数のテンプレートが準備されている
Cloud Dataprep
● GUI で利用できるデータ加工ツール
● レシピを作成し、Engine として Dataflow がバッチで動作する
Cloud
Dataflow

Cloud OnAir
Cloud OnAir
Best Practice
マスタデータの更新
外部データソースの解析

Cloud OnAir
マスターデータ更新のベストプラクティス
3つの選択肢
● BigQuery のテーブルをdelete して再度ロード
○ データ更新が多い際に利用
● Data Loading を利用して追加
○ WRITE_APPEND モードで、追記してロード
○ 更新されたマスタのレコードをtimestamp 付きで Loading
○ Timestamp が最新のマスタを表示するView を作る
● DML で更新
○ DML の Quota にかからないか確認して設計

Cloud OnAir
外部データソースの解析
フェデレーションデータソース
● BigQuery 自身のストレージではない場所に格納されたデータをクエリできる機能
● データ取り込みの必要なく手軽に分析
● 対象ソース
○ Google Cloud Storage
○ Google ドライブ
○ Cloud BigTable
● 制限
○ クエリ実行速度はネイティブより遅い
○ クエリ実行中にデータの整合性が保証されない

Cloud OnAir
Cloud OnAir
Best Practice
パフォーマンスの最適化

Cloud OnAir
必要なカラムのみクエリする
● BigQuery はカラム指向ストレージ
● 指定されたカラムは上から下までフルスキャンされる
● パフォーマンス、コストの観点から必要なカラムのみクエリをする
SELECT id, cost FROM table
SELECT GKGRECORDID FROM
`gdelt-bq.hathitrustbooks.1800`
id name cost date
SELECT * FROM
`gdelt-bq.hathitrustbooks.1800`

Cloud OnAir
分割テーブル (PARTITIONED TABLE)
● テーブルをパーティションに分割する
● データが挿入された日付で分割がされる日付分割
● 最新のデータ(7 日間)のみ取得するビューを作るなど、
スキャン対象データを絞れる
#standardSQL
SELECT
*
FROM
mydataset.partitioned_table
WHERE
_PARTITIONTIME BETWEEN
TIMESTAMP_TRUNC(TIMESTAMP_SUB(CURRENT_TIMES
TAMP(), INTERVAL 7 * 24 HOUR),DAY)
AND
TIMESTAMP_TRUNC(CURRENT_TIMESTAMP(),DAY);
#Caluculate the cost for today
#standardSQL
SELECT service.description, SUM(cost)
FROM
`playground.billing_dashboard.gcp_billing_exp
ort_v1_00AFE2_6C3561_890001`
WHERE
_PARTITIONTIME = TIMESTAMP("2017-10-13")
GROUP BY service.id, service.description
LIMIT
1000

Cloud OnAir
データの非正規化
● スタースキーマは避ける
● BigQuery は JOIN を
サポートするが、 JOIN を
実行するのは、小規模な
ディメンションテーブルを
処理する場合に限定する
ほうが良い
45
非正規化スキーマを使用した場合と、
SELF JOIN を使用した場合のパフォーマンスの比較

Cloud OnAir
キャッシュの利用
46
● クエリには通常キャッシュが有効
● キャッシュにヒットするとクエリが無料|高速
● キャッシュ無効になる一例:
○ Streaming Insert のバッファが残っている
○ CURRENT_TIMESTAMP() や NOW() を利用
○ ワイルドカードを利用し複数テーブルを参照
○ キャッシュが切れている (一般的に 24 時間)
○ 明示的にキャッシュを無効化している

Cloud OnAir
中間テーブルの作成 :
● JOIN が多い場合や、共通した処理を
行う場合は中間テーブルを
作成することが有効
● BigQuery のクエリ結果はすべて内部でテー
ブルとして保管される
○ SQLを書いて、非常に高速に
新規テーブルを生成可能
● 例えば、左図のような BigQuery 内での3層
構造も取れる。
BigQuery
Storage
中間テーブルの作成とビュー
Raw Data
加工した
中間テーブル
参照用
テーブル

Cloud OnAir 4848
Dataset C
Dataset B
● ビューはマテリアルビューではなく通常ビュー
○ 開くたびに裏ではクエリが走る
○ 中間テーブルと使い分けることが重要
○ (最後のユーザが見る部分のみ View を利用し、
その他は中間テーブルを利用する、等)
● Authorized view を利用して、権限分離にも
利用できる
48
Dataset A
View
View
必要な Column のみ
SELECT,
必要な raw のみ WHERE し
VIEW にアクセス権を付与
Analyst
Group B
Analyst
Group C

Cloud OnAir
● 中間テーブルの生成依存関係はCloud Composerで管理可能
● ComposerはApache Airflowベースのマネージド・サービス
CloudComposer

Cloud OnAir
スロットという概念
● スケジューリングの単位
● 論理的には 1 つの並列 “作業単位”
● パフォーマンスではなく、スループットが指標
● リソースサイズ（RAM や CPU の量）に対応
● 遅い / 失敗した場合はリスタート可能
● 不要になったらキャンセル可能

Cloud OnAir
スロットのスケジューリング
● デフォルトのスロット割り当て : プロジェクトあたり 2,000
● プロジェクト内のクエリ間でフェアスケジューリング
● プロジェクト間でフェアスケジューリング
● スロットはクエリのステージごとにスケジューリングされる
● スロットの利用度はデータの内部表現と転送状況に依存
Project A
Project B
Query A-1
Query A-2
Query B-1
Total: 900
Demand: 1500, Allocate: 200
Project C
Query C-1
Query C-2
Query C-3 Demand: 500, Allocate: 100
ある一瞬におけるスロットの
スケジューリング例
（通常スロットはクエリの中でも瞬間的に
上下するため、この状態が続くわけではない）
300
allocated
300
allocated
300
allocated

Cloud OnAir
Cloud OnAir
Enterprise Data Warehouse
としての BigQuery

Cloud OnAir
Enterprise-focused feature
● カラムベースパーティショニング
● クラスタリング(Beta)
● Customer Managed Encryption Key
● Authorized View
New Feature
Innovation-focused feature
● BigQuery ML (Beta)
● BigQuery GIS (alpha)

画像を配置後
左側の図形とフッターロゴを
被せて下さい
https://goo.gl/uHwh8Y
Cloud OnAir
パーティショニングは
もっと改善の余地がある
Cloud OnAir
お客様からのフィードバック

Cloud OnAir
カラムベースパーティショニング
2018-01-01
c1 c2 c3 eventDate c5
SELECT c1, c3 FROM ...
WHERE eventDate BETWEEN “2018-01-03” AND “2018-01-05”
2018-01-02
2018-01-03
2018-01-04
2018-01-05

Cloud OnAir
クラスタリング
2018-01-01
c1 userId c3 eventDate c5
SELECT c1, c3 FROM ... WHERE userId BETWEEN 52 and 63
AND eventDate BETWEEN “2018-01-03” AND “2018-01-05”
2018-01-02
2018-01-03
2018-01-04
2018-01-05

Cloud OnAir
クラスタリング
● 連続性の高いフィールドでフィルタ
● 費用削減効果:
○ クラスタキーでスキャンしたブロックにのみ費用が発生する
● より良いパフォーマンス:
○ データはパーティション内でソートされて保持される
● 管理が容易:
○ テーブルをマニュアルでシャードする必要はない

画像を配置後
被せて下さい
Cloud OnAir
列レベルで
セキュリティを
かけれないか？
Cloud OnAir

Cloud OnAir
列、行レベルのセキュリティ - Authorized Views
206-555-1212
orderId price phone # userId
202-555-1212
212-555-1212
401-555-1212
617-555-1212
123
234
345
456
999
priv.orders
Table

Cloud OnAir
206-555-1212
202-555-1212
212-555-1212
401-555-1212
617-555-1212
123
234
345
456
999
priv.orders
Table
safe.orders View
orderId price hash_phone userId
123
234
345
456
BwbGVhc2Ug
ZG9uJ3QgdX
NlIGl0IGFz
IHN1Y2gTW9
SELECT orderId, price, userId, SHA1_HASH(phone)
as hash_phone
FROM priv.orders
View Definition

Cloud OnAir
206-555-1212
202-555-1212
212-555-1212
401-555-1212
617-555-1212
123
234
345
456
999
priv.orders
Table
safe.orders View
orderId price hash_phone userId
123
234
345
456
BwbGVhc2Ug
ZG9uJ3QgdX
NlIGl0IGFz
IHN1Y2gTW9
SELECT orderId, price, userId, SHA1_HASH(phone)
as hash_phone
FROM priv.orders
View DefinitionPriv ACL
ALLOW VIEW safe.orders
ALLOW ...

画像を配置後
被せて下さい
Cloud OnAir
自社管理の
暗号化キーで
暗号化できませんか？
Cloud OnAir

Cloud OnAir
Manage your own Encryption Keys (CMEK)
BigQuery
API
Cloud KMS
Colossus
Table
Metadata
Query
Key
Name
Query
Master
Query Shard
Query
Key Name
File Name
Wrapped
Key
Wrapped
Key
Decrypt
Key Name
ユーザにて管理されているキーでの暗号化

Cloud OnAir
Demo
CMEKで暗号化したテーブルの作成

Cloud OnAir
Cloud OnAir
まとめ

Cloud OnAir
リアルタイム
インサイト
データ転送の
自動化
データ操作の
簡素化
AIデータ
管理基盤
ビジネスデータの
保護
分析基盤のコアとして BigQuery の活用を！
BigQuery はパフォーマンス以外の面でも、
エンタープライズレベルで利用出来るDWHです。
本日ご紹介した様々な機能、使い方を活用頂き、
よりビジネスインパクトをもたらすインサイトの獲得を実現しましょう！
インサイトの
民主化

[Cloud OnAir] BigQuery の仕組みからベストプラクティスまでのご紹介 2018年9月6日放送

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie [Cloud OnAir] BigQuery の仕組みからベストプラクティスまでのご紹介 2018年9月6日放送

Ähnlich wie [Cloud OnAir] BigQuery の仕組みからベストプラクティスまでのご紹介 2018年9月6日放送 (20)

Mehr von Google Cloud Platform - Japan

Mehr von Google Cloud Platform - Japan (20)