Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

2,231 views

Published on

BigQuery の仕組みを深掘りします。BigQuery をどう使うのがベストなのか?クラウドのメリットを生かしたマネージド DWH としての魅力と運用におけるベストプラクティスを説明します。

Published in: Technology
  • Be the first to comment

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

  1. 1. Cloud Onr Cloud OnAir Cloud OnAir BigQuery の仕組みから ベストプラクティスまでのご紹介 2018 年 9 月 6 日 放送
  2. 2. Agenda Cloud OnAir 1 3 2 4 BigQuery とは? BigQuery の仕組み BigQuery & Data ベストプラクティス Enterprise Data Warehouse としての BigQuery
  3. 3. Cloud OnAir Cloud OnAir BigQuery とは?
  4. 4. Cloud OnAir 1 PB はどれくらい大きいのか ? 4G モバイル回線で ダウンロード すると 27 年かかる 27 years フロッピーディスクを積み上 げると、六本木ヒルズ 森タワー の およそ20 倍 x20 アメリカ議会図書館 100 個分 100 Twitter のこれまでの ツイートすべてを 合わせた量の50 倍 x50
  5. 5. Cloud OnAir では、1 PB はどれくらい ”小さい” のか ? YouTube にアップロードされる 動画の1日分 2 マイクログラムの DNA 200 台のサーバーが 毎秒 50 の エントリをロギングして 3 年分
  6. 6. Cloud OnAir 経済的: 支払いは使用するクエリ 処理とストレージに対してのみ フルマネージドのデータウェアハウス: オ ペレーション担当者不要、 ペタバイト規模 信頼性: Google データセンターに おけるサポート 1 2 3 BigQuery はペタバイト規模のデータ分析ウェアハウス
  7. 7. Cloud OnAir スケーラブル: 高度な並列処理 モデルによってクエリを高速化 セキュリティ: ACL、データは トランスポート層で暗号化されて保存 監査可能: すべてのトランザクションはログ に記録され、クエリ可能 4 5 6 BigQuery はペタバイト規模のデータ分析ウェアハウス
  8. 8. Cloud OnAir 一般公開データセット : 実際のデータセット で演習(NOAA、IRS、GitHub、NYC Taxi な ど) フレキシブル: 複数のデータセットをま たいでデータをマッシュアップ 使いやすい: 使い慣れた SQL、インデックス不要 7 8 9 BigQuery はペタバイト規模のデータ分析ウェアハウス
  9. 9. Cloud OnAir BigQuery の歴史 2006 2012
  10. 10. Cloud OnAir 2002 2004 2005 2006 2008 2010 2012 2014 2015 GFS Map Reduce BigTable PubSub Flume Java Millwheel Tensorflow Google Papers DataflowDremel 10 年以上にわたるビッグデータへの取り組み
  11. 11. Cloud OnAir Dremel Google が自社のビッグデータを扱う為に開発した技術 = Dremel が BigQuery の元になっている Dremel ● 大規模並列クエリインフラ ○ Dremel: 2006 年より社内運用開始 ○ BigQuery: 2012年リリース ● 高速な検索 ○ 数百億件のフルスキャンが       数十秒で完了 ● インデックス不要 ○ すべてフルスキャン ○ アドホックな分析
  12. 12. Cloud OnAir Cloud OnAir BigQuery の仕組み
  13. 13. Cloud OnAir BigQuery Analysis Google 独自の内部 Dremel クエリエンジンテ クノロジーに基づく高速で 大規模な並列SQL エンジ ン BigQuery マネージド ストレージ Google のサービス (Ads や Gmail など)の データを格納しているのと同じテ クノロジーを 基盤とするフルマネージドのス ケーラブルなデータ ストレージ BigQuery は実際には 2 つのサービスが一体化されたもの
  14. 14. Cloud OnAir BigQuery のストレージはカラム指向ストレージ Relational database BigQuery Storage ● 各列は個別の圧縮された暗号化ファイルに 保存され、各ファイルは複製される ● インデックス、キーまたはパーティションは不要 ● レコード指向のストレージ ● トランザクションの更新をサポート
  15. 15. Cloud OnAir SQL:2011 Compliant 高速ネットワーク(Jupiter) BigQuery 高可用性 クラスタコンピュート(Dremel) ストリーミング インサート バルク ロード 分散ストレージ REST API Client Libraries In 7 languages Web UI, CLI分散メモリシャッフ ル ストレージとコンピュートを分離して柔軟性を確保 アーキテクチャ
  16. 16. Cloud OnAir パフォーマンスの最大化 シャッフルする仕組み Worker Worker GROUP BY state COUNT(*) SELECT state Worker Worker Worker WHERE year... SHUFFLE BY state ● 複雑なクエリのパフォーマンスの向 上 ● 多くのデータを JOIN ● スケーラビリティの確保 分散ストレージ 処理スピードとクエリパフォーマンスの最大化 コンテナ クラスタ コンテナ クラスタ
  17. 17. Cloud OnAir マネージドストレージ 自動バックアップによる耐久性と永続的なストレージ 3 2 1 3 21 3 2 1 Table 1 Table 2 Table 3 Zone A Zone B Zone C Region ● テーブルは最適化された カラムナー形式で格納 ● 各テーブルは圧縮され、ディス ク上で暗号化される ● 各テーブルはデータ センター間で複製
  18. 18. 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州の リストを生成。 各州別の内訳を表示。
  19. 19. 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 サンプルクエリの処理 : クエリの並行処理
  20. 20. 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 ) をもつ
  21. 21. Cloud OnAir 階層構造 - Dataset Dataset (organization, access control) Job (query, import, export, copy) Project (billing, top-level container) Table (data with schema) ● Table や View の集合を持つ ● データセットのすべての tables/views にアク セスコントロールが適用 ● ACLs は Readers, Writers と Owners Project のメンバー以外にアクセス権を 与えることが可能
  22. 22. Cloud OnAir Dataset (organization, access control) Job (query, import, export, copy) Project (billing, top-level container) Table (data with schema) ● 行と列の集合 ○ マネージドストレージにデータ格納 ○ スキーマを持つ ● Views をサポート ○ SQL クエリで Virtual tables を定義 ● テーブルは外部に持てる (federated) ○ Google Cloud Storage 等を 直接クエリできる 階層構造 - Table
  23. 23. Cloud OnAir Dataset (organization, access control) Job (query, import, export, copy) Project (billing, top-level container) Table (data with schema) ● 長時間実行の可能性があるものに使われる ● Examples: ○ クエリ ○ データのインポート、エクスポート ○ データのコピー ● キャンセル可能 階層構造 - Job
  24. 24. Cloud OnAir ユーザインタフェース ● GUI BigQuery 管理コンソール ● CLI(bqコマンド) ● Cloud Datalab ● Google Data Studio ● 3rd パーティツール (Tableau, Qlikview, R etc. ) ● API (RESTful API + 各種言語ライブラリ)
  25. 25. Cloud OnAir bq コマンド ● Python ベースのコマンドラインツール ● Google Cloud SDK にバンドル ● bq コマンドの主な機能 ○ cp : テーブルのコピー ○ extract : ファイル出力 ○ insert : 行の挿入 ○ load : ファイルのロード ○ query: クエリの実行 ○ rm: テーブルの削除 $ bq query ‘select count(*) from publicdata:samples.shakespeare’
  26. 26. Cloud OnAir API クライアントライブラリ
  27. 27. Cloud OnAir Cloud OnAir BigQuery & Data ベストプラクティス
  28. 28. Cloud OnAir Cloud OnAir Best Practice データの取り込み
  29. 29. Cloud OnAir データの取り込み - データソース ● Google Cloud Storage (GCS) ● アップロード (POST request) ● Google Cloud Datastore のバックアップ ● Google Analytics Premium ● Stackdriver Logging からのログエクスポート ● Firebase <POST>
  30. 30. Cloud OnAir データの取り込み - 手法 Data Loading ● データをジョブでまとめて取り込む Streaming Insert ● リアルタイムに近い方式でデータを取り込む 共通のポイント ● 両者ともクエリ実行環境とはリソース分離 ● データ取り込み/クエリ実行のパフォーマンスは互いに影響しない
  31. 31. Cloud OnAir データの取り込み - 手法 [ Consistency | Availability | Speed | Cost ]はトレードオフ: Consistency Availability Speed Cost Data Loading スループット最適化 強整合性 Load Jobが完了し たらすぐ使える ジョブが完了しない と読み込めない Free Streaming Insert レイテンシー最適化 結果整合性 Insert から分析 まで数 ms 秒 リアルタイム $0.05/GB*month
  32. 32. 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 を利用してキューイング、スロットリング
  33. 33. Cloud OnAir 大規模データの取り込み - クォータ 変更できないクォータはアーキテクチャ設計で対応 ● ロードジョブの最大サイズ : ○ ファイルを分割 or 制限のより大きな形式に変更 ○ Avro: block size で 16 MB, CSV: row と cell で 2 MB ● すべてのテーブルクォータ: ○ ストリーミングインサート ■ 1 秒あたりの最大行数 (1万行) / table ■ 1 秒あたりの最大バイト数 (100MB)/ table ○ ロードジョブ ■ 1日あたりの最大ロードオペレーション数 (1000) / table / day
  34. 34. Cloud OnAir 大規模データの取り込み - クォータ クォータ変更のリクエスト: API Managerより実施
  35. 35. 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
  36. 36. Cloud OnAir データのフォーマット データフォーマット ● CSV ● JSON ● Apache Avro 圧縮の有無 ● 非圧縮 ● gzip [Avro は対象外] エンコードについての制約もあり {JSON} CSV
  37. 37. Cloud OnAir データフォーマットのベストプラクティス ロードの高速化: ● Avro はロードが 10 倍程度高速 ● CSV の場合は Encode を UTF-8 にする ○ ISO-8859-1 などの場合、BigQuery で変換処理が行われるので遅くなる ● 非圧縮でロードする ○ gzip はロードパフォーマンスが落ちる
  38. 38. 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
  39. 39. Cloud OnAir Cloud OnAir Best Practice マスタデータの更新 外部データソースの解析
  40. 40. Cloud OnAir マスターデータ更新のベストプラクティス 3つの選択肢 ● BigQuery のテーブルをdelete して再度ロード ○ データ更新が多い際に利用 ● Data Loading を利用して追加 ○ WRITE_APPEND モードで、追記してロード ○ 更新されたマスタのレコードをtimestamp 付きで Loading ○ Timestamp が最新のマスタを表示するView を作る ● DML で更新 ○ DML の Quota にかからないか確認して設計
  41. 41. Cloud OnAir 外部データソースの解析 フェデレーション データソース ● BigQuery 自身のストレージではない場所に格納されたデータをクエリできる機能 ● データ取り込みの必要なく手軽に分析 ● 対象ソース ○ Google Cloud Storage ○ Google ドライブ ○ Cloud BigTable ● 制限 ○ クエリ実行速度はネイティブより遅い ○ クエリ実行中にデータの整合性が保証されない
  42. 42. Cloud OnAir Cloud OnAir Best Practice パフォーマンスの最適化
  43. 43. 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`
  44. 44. 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
  45. 45. Cloud OnAir データの非正規化 ● スタースキーマは避ける ● BigQuery は JOIN を サポートするが、 JOIN を 実行するのは、小規模な ディメンション テーブルを 処理する場合に限定する ほうが良い 45 非正規化スキーマを使用した場合と、 SELF JOIN を使用した場合のパフォーマンスの比較
  46. 46. Cloud OnAir キャッシュの利用 46 ● クエリには通常キャッシュが有効 ● キャッシュにヒットするとクエリが無料|高速 ● キャッシュ無効になる一例: ○ Streaming Insert のバッファが残っている ○ CURRENT_TIMESTAMP() や NOW() を利用 ○ ワイルドカードを利用し複数テーブルを参照 ○ キャッシュが切れている (一般的に 24 時間) ○ 明示的にキャッシュを無効化している
  47. 47. Cloud OnAir 中間テーブルの作成 : ● JOIN が多い場合や、共通した処理を 行う場合は中間テーブルを 作成することが有効 ● BigQuery のクエリ結果はすべて内部でテー ブルとして保管される ○ SQLを書いて、非常に高速に 新規テーブルを生成可能 ● 例えば、左図のような BigQuery 内での3層 構造も取れる。 BigQuery Storage 中間テーブルの作成とビュー Raw Data 加工した 中間テーブル 参照用 テーブル
  48. 48. 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 中間テーブルの作成とビュー
  49. 49. Cloud OnAir ● 中間テーブルの生成依存関係はCloud Composerで管理可能 ● ComposerはApache Airflowベースのマネージド・サービス 中間テーブルの作成とビュー CloudComposer
  50. 50. Cloud OnAir スロットという概念 ● スケジューリングの単位 ● 論理的には 1 つの並列 “作業単位” ● パフォーマンスではなく、スループットが指標 ● リソース サイズ(RAM や CPU の量)に対応 ● 遅い / 失敗した場合はリスタート可能 ● 不要になったらキャンセル可能
  51. 51. Cloud OnAir スロットのスケジューリング ● デフォルトのスロット割り当て : プロジェクトあたり 2,000 ● プロジェクト内のクエリ間でフェアスケジューリング ● プロジェクト間でフェアスケジューリング ● スロットはクエリのステージごとにスケジューリングされる ● スロットの利用度はデータの内部表現と転送状況に依存 Project A Project B Query A-1 Query A-2 Query B-1 Total: 900 Demand: 1500, Allocate: 200 Demand: 100, Allocate: 100 Demand: 1000, Allocate: 300 Project C Query C-1 Query C-2 Demand: 500, Allocate: 100 Demand: 500, Allocate: 100 Query C-3 Demand: 500, Allocate: 100 ある一瞬におけるスロットの スケジューリング例 (通常スロットはクエリの中でも瞬間的に 上下するため、この状態が続くわけではない) 300 allocated 300 allocated 300 allocated
  52. 52. Cloud OnAir Cloud OnAir Enterprise Data Warehouse としての BigQuery
  53. 53. Cloud OnAir Enterprise-focused feature ● カラムベースパーティショニング ● クラスタリング(Beta) ● Customer Managed Encryption Key ● Authorized View New Feature Innovation-focused feature ● BigQuery ML (Beta) ● BigQuery GIS (alpha)
  54. 54. 画像を配置後 左側の図形とフッターロゴを 被せて下さい https://goo.gl/uHwh8Y Cloud OnAir パーティショニングは もっと改善の余地がある Cloud OnAir お客様からのフィードバック
  55. 55. 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
  56. 56. 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
  57. 57. 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
  58. 58. 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
  59. 59. 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
  60. 60. 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
  61. 61. Cloud OnAir クラスタリング ● 連続性の高いフィールドでフィルタ ● 費用削減効果: ○ クラスタキーでスキャンしたブロックにのみ費用が発生する ● より良いパフォーマンス: ○ データはパーティション内でソートされて保持される ● 管理が容易: ○ テーブルをマニュアルでシャードする必要はない
  62. 62. 画像を配置後 左側の図形とフッターロゴを 被せて下さい https://goo.gl/uHwh8Y Cloud OnAir 列レベルで セキュリティを かけれないか? Cloud OnAir お客様からのフィードバック
  63. 63. 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
  64. 64. Cloud OnAir 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 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 列、行レベルのセキュリティ - Authorized Views
  65. 65. Cloud OnAir 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 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 ... 列、行レベルのセキュリティ - Authorized Views
  66. 66. 画像を配置後 左側の図形とフッターロゴを 被せて下さい https://goo.gl/uHwh8Y Cloud OnAir 自社管理の 暗号化キーで 暗号化できませんか? Cloud OnAir お客様からのフィードバック
  67. 67. 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 ユーザにて管理されているキーでの暗号化
  68. 68. Cloud OnAir Demo CMEKで暗号化したテーブルの作成
  69. 69. Cloud OnAir Cloud OnAir まとめ
  70. 70. Cloud OnAir リアルタイム インサイト データ転送の 自動化 データ操作の 簡素化 AIデータ 管理基盤 ビジネスデータの 保護 分析基盤のコアとして BigQuery の活用を! BigQuery はパフォーマンス以外の面でも、 エンタープライズレベルで利用出来るDWHです。 本日ご紹介した様々な機能、使い方を活用頂き、 よりビジネスインパクトをもたらすインサイトの獲得を実現しましょう! インサイトの 民主化

×