BigQueryクエリの処理の流れ

Transcript

1. BigQueryクエリの 処理の流れ Jordan Tigani BigQuery Software Engineer

2. ゴール：BigQueryクエリの一連の処理手順を追う 注：ここに記されたアーキテクチャの内容や役割は、 - すぐ古くなったり - 詳細は端折られてたり - いずれ変更されたり*します *これがBigQueryの大きなメリットです。見えないところでつねに 改善が続けられています

3. 最近のアーキテクチャ改善の例 シャッフルのスループットが4倍に クラスタサイズが5倍に クラスタが追加 ディスク保存のフォーマットを変更 （ColumnIOからの置き換え） ディスク保存のエンコード形式を変更 （耐久性の向上、サイズの縮小） 残念ながら、詳細は紹介できません

4. クエリを実行してみよう SELECT language, SUM(views) as views FROM ( SELECT title,

   language, MAX(views) as views FROM [helixdata2:benchmark.Wiki100B] WHERE REGEXP_MATCH(title, "G.*o.*") GROUP EACH BY title, language ) GROUP EACH BY language ORDER BY views desc

5. 1000億行に対する複雑なクエリ実行時の性能 実行時間：21秒 - 4 TBのデータを読み込み - 1000億行に対する正規表現の適用 - 278 GBのデータをシャッフル

   並列処理しなかったら： - 4 TBのディスク読み込みに11.6時間（100 MBpsの場合） - 1000億行の正規表現処理に27時間（1行あたり1 μsecの場合） - 278 GBのシャッフルに37分（1Gbpsの場合）

6. curlでクエリを実行する curl -H "$(python auth.py)" \ -H "Content-Type: application/json" \

   -X POST \ -d {'jobReference': { \ 'jobId': 'job_1429217599', \ 'projectId': 'bigquery-e2e'}, \ 'configuration': { \ 'query': { \ 'query': 'SELECT ...’}}} \ "https://www.googleapis.com/bigquery/v2/projects/bigquery-e2e/jobs"

7. リクエストの中身は... POST /bigquery/v2/projects/bigquery-e2e/jobs HTTP/1.1 User-Agent: curl/7.30.0 Host: www.googleapis.com Accept: */*

   Authorization: Bearer <redacted> Content-Type: application/json Content-Length: 126 {'jobReference': {'jobId': 'job_1429217599', 'projectId': 'bigquery-e2e'}, 'configuration': {'query': {'query': 'SELECT 17'}}}

8. Client HTTP POST GFE JSON API frontend HTTP JSON HTTP

   BigQuery API Server protobuf gRPC ジョブの投入

9. リクエストがBigQueryに届くまで... GFE - GoogleネットワークへのHTTP接続を受け付け - DoS対策 - 一般的なHTTPヘッダの処理 Google API

   Frontend - JSONとProtocol Buffer間の変換 - HTTPとStubby/gRPC間の変換 - リクエスト認証

10. HTTP POST クエリジョブの状態変化 HTTP Error HTTP OK OK? OK? OK?

    PENDING RUNNING DONE w/ errorResult DONE no no no yes yes yes

11. Client HTTP POST GFE 200 OK API Frontend HTTP 200

    OK HTTP BigQuery API Server protobuf gRPC Spanner 新規ジョブ Stubby ジョブ投入の完了

12. レスポンスヘッダ HTTP/1.1 200 OK Cache-Control: no-cache, no-store, max-age=0, must-revalidate Pragma:

    no-cache Vary: X-Origin Content-Type: application/json; charset=UTF-8 Server: GSE Accept-Ranges: none Vary: Origin,Accept-Encoding Transfer-Encoding: chunked

13. レスポンスデータ { "kind": "bigquery#job", "id": "bigquery-e2e:job_1429217599", "jobReference": {"projectId": "bigquery-e2e", "jobId":

    "job_1429217599"}, "configuration": {...} "status": { "state": "RUNNING" }, "statistics": { "creationTime": "1429217642957", "startTime": "1429217643549" }, "user_email": "jtigani@gmail.com" }

14. レスポンスデータ（configuration） "configuration": { "query": { "query": "SELECT ...", "destinationTable": {

    "projectId": "bigquery-e2e", "datasetId": "_0e32b38e1117b2fcea992287c138bd53acfff7cc", "tableId": "anon6163a05d4704b78c589f41813708f340a2df2d1f" }, "createDisposition": "CREATE_IF_NEEDED", "writeDisposition": "WRITE_TRUNCATE" } }

15. 新しいジョブの開始 1. 確認フェーズ： - 認証チェック - クオータのチェック - 入力内容の検証 -

    キャッシュのチェック - 出力テーブルの用意 2. ジョブをメタデータストアに保存 3. リクエスト元に正常開始を伝える

16. ところで：BigQueryのキャッシュの動き 以下のSHA-1ハッシュ値をとる： - データ更新時間 - 参照テーブル 以下の場合はキャッシュを使わない： - 値が変化する関数を使用（NOW()など） -

    固定の出力テーブルを指定 - 参照テーブルがストリーミングバッファを使用 SHA-1ハッシュ値が出力テーブル名となる ユーザー単位でキャッシュされる

17. BigQuery APIサーバ Spanner テーブル メタデータ Dremel ゲー トウェイ Dremel クエリ

    Dremelクラスタ us-central-1-a Dremelクラスタ us-central-2-a Dremel クエリ Dremelクエリの開始

18. Dremelゲートウェイ アクセス可能なレプリカを検索 以下に基づき、クエリの実行に最適な場所を決定： - データからの距離 - クラスタの負荷状況 データは部分的にレプリケーションされる場合もある

19. ところで：BigQueryのレプリケーション 地理的に離れた複数のゾーン間でレプリケーション - 可用性の向上 - ディザスタリカバリ データセンター内でのレプリケーション - 永続性の向上 -

    リード性能の向上 - リードソロモンに似たエンコーディングを使用 小さなテーブルはメタデータ内に保存

20. ところで：BigQueryのStreaming insert Streaming insertされたデータはBigtable上にバッファ ワーカによって定期的にColossusに保存 Dremelクエリ実行時はBigtable上のバッファも読み込み バッファ内容はdurableだが、大きな障害時には一時的に読み 込みできなくなる

21. Dremel ゲー トウェイ Dremel Root Mixer Dremel クエリ Dremel Mixer-1

    Dremel Mixer-1 Dremel Mixer-1 Dremel Shard Dremel Shard Dremel Shard Dremel Shard Dremel Shard Dremel Shard Dremelクエリの実行ツリー

22. Dremel Root Mixer クエリプランの構築 - クエリを複数のステージに分割 - 処理内容を並列タスクに分割 クエリのスケジューリング -

    利用可能なスロットを各ユーザーに分配 - クエリの割り込み クエリを下位のmixer/shardに転送

23. Dremel Shard 実行中のクエリの一部分を実行 ソースからデータを読み込み 通常はColossusから （Streaming時の）Bigtable、またはCloud Storage 集約処理を部分的に実行

24. Dremel Shard Dremel Shard Dremel Shard CFS CFS CFS CFS

    CFS CFS 分散メタデータ 分散ファイル 分散 ストレージ データの読み込み Streaming BigTable

25. ストレージ階層 Colossusメタデータ - ディレクトリ構造 - ACLs Colossusファイル - ほとんどフラットな構造 -

    一部のACLs - 暗号化 分散ストレージ - ディスクエンコード（RAID的なもの） - クラスタ内でレプリケーション

26. カラムストレージ

27. ColumnIO データを行単位ではなくカラム単位で保存 圧縮効率が向上 分散ファイルシステムを利用 - ローカルディスクではシークが多すぎる 不要なカラムをスキップ - クエリの多くはテーブル内の一部のカラムのみ参照 制約ヘッダ

    - 各カラムのレンジとカーディナリティを保持 - ファイルのスキップが可能に

28. Dremel Shard CFS CFS CFS CFS WHERE REGEXP_MATCH( title, "G.*o.")

    フィルタリングの実行 CFS CFS Drmel Shard

29. Dremel Shard Dremel Shard Dremel Shard データのシャッフル Dremel Shard Dremel

    Shard Dremel Shard

30. データのシャッフル ハッシュ値でデータをパーティション分割 - 個々のshardで集約が可能 大きなパーティションはディスクにあふれる パーティションのばらつきも起こりうる - 例：3億のユニークユーザーIDのうち10%がユーザーID＝0

31. Dremel Shard Dremel Shard Dremel Shard CFS CFS CFS CFSr

    CFS CFS データのマテリアライズ

32. 結果の出力 シャッフルした結果はshardに出力 - shard内で集約されたデータ - 大規模な結果も出力可能 シャッフル不要の結果はmixerに返す - mixerで集約を実行 -

    出力可能なサイズは128MBまで

33. BigQuery APIサーバ Spanner テーブル メタデータ Dremel ゲー トウェイ クエリス テータス

    Dremelクラスタ us-central-1-a クエリス テータス クエリ結果の保存

34. クエリ結果の保存 保存処理はACID特性を持つ - クエリ結果はすべてが返されるか、全く返されないか - クエリ結果は次のクエリですぐ利用できる 小さなクエリ結果はメタデータ内部に保存される 保存時に以下も可能： - CREATE_IF_NEEDED指定時のテーブル作成

    - WRITE_TRUNCATE指定時のテーブルまるめ - ジョブのステータスをDONEに

35. jobs. getQueryResu lts() GFE APIフロ ントエン ド BigQuery APIサーバ Spanner

    ジョブ 結果のポーリング

36. 結果のポーリング jobs.getQueryResults() - サーバ側でGETをホールド - Jobs.insert()のジョブIDを指定 - ジョブステータス＝DONEを待つ - タイムアウトしたらリトライ

    1回に1ページごと結果を返す

37. curlでクエリ結果を取得 RESULTS_URL=${JOBS_URL}/${JOB_ID}/results curl -H "$(python auth.py)" \ -H "Content-Type: application/json"

    \ -X GET \ "${RESULTS_URL}"

38. Questions? Thank you! Contact info: e-mail: tigani@google.com twitter: @jrdntgn g+:

    +JordanTigani