BigQueryを使用した分析基盤の運用を進めていく上で見えてきた課題、乗り越えてきた軌跡/20180920-gcn-bigquery

先日登壇した Google Cloud Next '18 in Tokyo の発表資料です。
※Google Cloud Next関係のロゴは削除しています

【概要】
リクルートライフスタイル(RLS)では、じゃらん、ホットペッパーをはじめ、大小 30 以上のサービスを展開おり、それらすべてのデータを集約した分析基盤を構築しています。
柔軟性、強固性、スケーラビリティなど、様々な条件がある中、同社では複数の DWH の共存を選択し、その 1 つとして BigQuery を選びました。
- なぜ BigQuery を選択したのか
- BigQuery を導入・運用して明らかになった課題はどういうものがあるのか
- それらの課題をどう乗り越えたのか
分析基盤全体の構成や、RLS分析基盤の軌跡と共に現場目線でお伝えします。

【発表者】
リクルートライフスタイル 山田 雄さん
SHAKETH 代表 瀧井 伸一

Transcript

1. D2-4-S10 BigQuery を使用した分析基盤の運用を進めて いく上で見えてきた課題、乗り越えてきた軌跡 山田　雄 瀧井　伸一 株式会社リクルートライフスタイル ビッグデータアーキテクト 2018/09/20
2. 山田　雄(Yamada Yu) @nii_yan ビッグデータアーキテクト 好物：BigData周りの技術、データ基盤コンサル、 ビール、日本酒、カップ焼きそば Photo Speaker
3. Agenda • リクルートライフスタイル 会社紹介 • リクルートライフスタイルの分析基盤概要 • BigQueryの運用について • データパイプラインアーキテクチャ • BigQuery基盤で取り組んだ工夫
4. 1 リクルートライフスタイル 会社紹介
5. リクルートのビジネスモデル
6. Title text 一生のうち、数回つかうサービス LIFE EVENT 日常的に、つかうサービス LIFE STYLE
8. 2 リクルートライフスタイル の 分析基盤
9. 202 h
10. 202 h 10 h
11. 分析基盤の変遷
12. 分析基盤の変遷 ✔リクルート分社化に伴い、独自の 分析基盤Hadoop提供スタート ✔Netezza, Redshift導入 2013
13. 課題 1. Hadoop はスケールアウトが辛い 2. Hive はクエリのレスポンスが遅い 3. Hadoop のアップデートが辛い
14. 分析基盤の変遷 2013 2014 ✔Hadoop 除却 ✔TreasureData 導入 ✔Redshiftのノード 拡張 ✔リクルート分社化に伴い、独自の 分析基盤 Hadoop 提供スタート ✔Netezza, Redshift 導入
15. 課題 1. ストレージのキャパシティ管理が辛い 2. オンプレとの通信が辛い
16. 分析基盤の変遷 2013 2014 2015 ✔リクルート分社化に伴い、独自の 分析基盤Hadoop提供スタート ✔Netezza, Redshift導入 ✔オンプレ- AWS 間に専用線導入 ✔Redshift のノード拡張 ✔Netezza のスケール検討 ✔Hadoop 除却 ✔TreasureData 導入 ✔Redshiftのノード 拡張
17. 課題 1. ワークロードの限界 a. データロードと、データマート作成に 1 日かかる 2. クエリ実行性能の低下 a. 常にデータロードが走っているため、クラスタの負荷が高い
18. 分析基盤の変遷 2013 2014 2015 2016 ✔Hadoop 除却 ✔TreasureData 導入 ✔Redshift のノード拡張 ✔リクルート分社化に伴い、独自の 分析基盤 Hadoop 提供スタート ✔Netezza, Redshift 導入 ✔オンプレ- AWS 間に専用線導入 ✔Redshift のノード拡張 ✔Netezza のスケール検討 ✔Netezza のスケールアウト完了 ✔Redshift のノード拡張 ✔Redshift の multi クラスタ導入
19. 課題 1. ワークロードの複雑化 2. 費用対効果の限界 3. 未来への対応
20. 分析基盤の変遷 ✔BigQuery 導入 ✔NetezzaEOSL ✔DataLake 構成導入 ✔Exadata 導入 2013 2014 2015 2016 2017 ✔Hadoop 除却 ✔TreasureData 導入 ✔Redshift のノード拡張 ✔リクルート分社化に伴い、独自の 分析基盤 Hadoop 提供スタート ✔Netezza, Redshift 導入 ✔オンプレ- AWS 間に専用線導入 ✔Redshift のノード拡張 ✔Netezza のスケール検討 ✔Netezza のスケールアウト完了 ✔Redshift のノード拡張 ✔Redshift の multi クラスタ導入
21. 課題 1. 非効率なマルチプラットフォーム構成 2. 解決しないワークロードの負荷 3. ユーザ教育のコスト増
22. 分析基盤の変遷 2013 2014 2015 2016 2017 2018 ✔TreasureData を一部 BQ へ移行 ✔RedshiftSpectrum 導入 ✔Redshift を一部 BQ へ移行 ✔BigQuery 導入 ✔NetezzaEOSL ✔DataLake 構成導入 ✔Exadata 導入 ✔Hadoop 除却 ✔TreasureData 導入 ✔Redshift のノード拡張 ✔リクルート分社化に伴い、独自の 分析基盤 Hadoop 提供スタート ✔Netezza, Redshift 導入 ✔オンプレ- AWS 間に専用線導入 ✔Redshift のノード拡張 ✔Netezza のスケール検討 ✔Netezza のスケールアウト完了 ✔Redshift のノード拡張 ✔Redshift の multi クラスタ導入
23. S3 分析基盤の概要 Amazon Redshift Spectrum Oracle Exadata SPSS Treasure Data aginity CHEETAH DIGITAL Adobe Analytics CSV 外部データ アクセスログ アプリログ HPB JLN HPG 事業データ BigQuery IBM Watson Campaign Automation
24. 課題 1. インフラメンテナンスの限界 　　DWH のみならず、ファイルストレージ、バッチ処理サーバ、 　　開発者、バッチアカウントの管理が煩雑化し、人的管理の限界 　　運用コストが高くなっている
25. 課題解消のために据えた目標
26. 課題解消のための目標 • 性能劣化しない基盤
27. 課題解消のための目標 • インフラ運用からの解放
28. 課題解消のための目標 • キャパシティ管理からの解放
29. 課題解消のための目標 • データ活用の民主化が進む基盤
30. 課題解消のための目標 • 構造を把握しやすい基盤
31. 課題解消のための目標 • 性能劣化しない基盤 • インフラ運用からの解放 • キャパシティ管理からの解放 • データ活用の民主化が進む基盤 • 構造を把握しやすい基盤
32. Why BigQuery?
33. Why BigQuery • キャパシティプランニング不要
34. Why BigQuery • フルマネージド
35. Why BigQuery • ロード処理とクエリ処理が分離されて いる
36. Why BigQuery • データの受け渡しが容易
37. Why BigQuery • 定額料金での使用が可能
38. Why BigQuery • 他の Google 製品との親和性
39. Why BigQuery • キャパシティプランニング不要 • フルマネージド • ロード処理と、クエリ処理が分離 • データの受け渡しが容易 • 定額料金での使用が可能 • 他の Google 製品との親和性 ▪課題解消のための目標 性能劣化しない基盤 インフラ運用からの解放 キャパシティ管理からの解放 さらなるデータ活用の民主化が進む基盤 構造を把握しやすい基盤 インフラをコード化 (terraform) する事で解消
40. 3 BigQuery の運用について
41. BigQuery 運用 • slots ◦ subreservation で 大事なバッチを確保
42. BigQuery 運用 • 権限管理 ◦ google group を 使用して管理
43. BigQuery 運用 • ユーザ教育 ◦ 教育動画や 勉強会を開催
44. BigQuery 運用 • メタデータ管理 ◦ BQ だけではなく、 他の DB も一元的 に管理
45. BigQuery 運用 • DataLake 構成
46. • 他の DWH とのデータ連携 ◦ bot を用意して、ユーザでも データの移動が出来るように Slack Redshift S3 BigQuery 運用
47. 4 リクルートライフスタイル BigQuery データパイプライン アーキテクチャ 取り組んだ工夫
48. 瀧井　伸一 株式会社フォスターネット SHAKETH 代表(フリーランス) ビッグデータアーキテクト SIer 等を経て、ゴルフダイジェスト・オンラインや GREE で、Web アナリスト業務、アクセス解析システム、 DWH、BI、SFAの構築を主導。 現在は、フリーランス で、DMP 構築を中心に携わる。 Speaker
49. ① リクルートライフスタイル BigQuery 規模 ② データパイプライン アーキテクチャ ③ BigQuery 基盤で取り組んだ工夫
50. リクルートライフスタイル BigQuery の規模
51. リクルートライフスタイル BigQuery の規模 ※ 2018 年 8 月時点 ユーザー数 750 人
52. リクルートライフスタイル BigQuery の規模 ※ 2018 年 8 月時点 テーブル数 4,000 個
53. リクルートライフスタイル BigQuery の規模 ※ 2018 年 8 月時点 レコード数 6,000 億件
54. リクルートライフスタイル BigQuery の規模 ※ 2018 年 8 月時点 ストレージ 550 TB
55. リクルートライフスタイル BigQuery の規模 ※ 2018 年 8 月時点 連携 データベース Amazon Redshift Adobe Analytics Oracle Server Log
56. リクルートライフスタイル BigQuery の規模 ※ 2018 年 8 月時点 Server Log Amazon Redshift Adobe Analytics Oracle ユーザー数 テーブル数 レコード数 ストレージサイズ 連携データベース 750 4,000 6,000 550 人 個 億件 TB (開発テスト環境含む : 650 TB)
57. リクルートライフスタイル BigQuery データパイプライン アーキテクチャ
58. Google プロダクト連携 それ以外 の連携
59. Google プロダクト連携 BigQuery
60. Google プロダクト連携 BigQuery BigQuery Export 設定
61. Google プロダクト連携 BQプロジェクト選択 GAビュー選択 連絡先選択 ストリーミング設定 リクエスト確認 Google Analytics → BigQuery
62. 超簡単!!!
63. 全部 Google に乗っかればいいのに…
64. 現実は違う
65. 今日の本題 事業データ、Web ログ等の データ連携システムアーキテクチャ
66. 設計思想 イベントドリブン & 疎結合
67. 設計思想 : イベントドリブン & 疎結合 • ファイル出力イベントをトリガーに BigQuery 連携 • データ連携パイプラインを各段階で切り分けて、 独立したプロセスで稼働
68. 設計思想 : イベントドリブン & 疎結合 • ファイル出力イベントをトリガーに BigQuery 連携 • データ連携パイプラインを各段階で切り分けて、 独立したプロセスで稼働 • システム間の連携時間調整を大幅に削減 • 変化に柔軟、迅速なデプロイが可能 • 障害が起きても、影響を小さい単位に切り分けられる
69. プロダクト : マルチクラウド Kubernetes Engine Cloud Storage Compute Engine AWS SQS S3 Stackdriver
70. Data Pipeline Update job check Kubernetes Engine Load job check Kubernetes Engine Data Lake AWS On-premises / Cloud データパイプライン システム概要図 Server Log S3 File copy Kubernetes Engine Data store Cloud Storage DDL Parse & BigQuery Load Kubernetes Engine S3 Notification SQS Load start SQS Load check SQS Update start SQS Table update Kubernetes Engine SQS auto scaler Kubernetes Engine Update check SQS Data warehouse BigQuery Oracle Amazon Redshift Adobe Analytics Slack Logging & Alert Stackdriver
71. Data Pipeline Update job check Kubernetes Engine Load job check Kubernetes Engine Data Lake AWS On-premises / Cloud データパイプライン システム概要図 Server Log S3 File copy Kubernetes Engine Data store Cloud Storage DDL Parse & BigQuery Load Kubernetes Engine S3 Notification SQS Load start SQS Load check SQS Update start SQS Table update Kubernetes Engine SQS auto scaler Kubernetes Engine Update check SQS Data warehouse BigQuery Oracle Amazon Redshift Adobe Analytics Slack Data warehouse Logging & Alert Stackdriver
72. Data Pipeline Update job check Kubernetes Engine Load job check Kubernetes Engine Data Lake AWS On-premises / Cloud データパイプライン システム概要図 Server Log S3 File copy Kubernetes Engine Data store Cloud Storage DDL Parse & BigQuery Load Kubernetes Engine S3 Notification SQS Load start SQS Load check SQS Update start SQS Table update Kubernetes Engine SQS auto scaler Kubernetes Engine Update check SQS Data warehouse BigQuery Oracle Amazon Redshift Adobe Analytics Slack Data File Store Logging & Alert Stackdriver
73. Data Pipeline Update job check Kubernetes Engine Load job check Kubernetes Engine Data Lake AWS On-premises / Cloud データパイプライン システム概要図 Server Log S3 File copy Kubernetes Engine Data store Cloud Storage DDL Parse & BigQuery Load Kubernetes Engine S3 Notification SQS Load start SQS Load check SQS Update start SQS Table update Kubernetes Engine SQS auto scaler Kubernetes Engine Update check SQS Data warehouse BigQuery Oracle Amazon Redshift Adobe Analytics Slack Data Pipeline System Logging & Alert Stackdriver
74. Data Pipeline Update job check Kubernetes Engine Load job check Kubernetes Engine Data Lake AWS On-premises / Cloud データパイプライン システム概要図 Server Log S3 File copy Kubernetes Engine Data store Cloud Storage DDL Parse & BigQuery Load Kubernetes Engine S3 Notification SQS Load start SQS Load check SQS Update start SQS Table update Kubernetes Engine SQS auto scaler Kubernetes Engine Update check SQS Data warehouse BigQuery Oracle Amazon Redshift Adobe Analytics Slack Data Pipeline System キュー管理 データ処理プロセス Logging & Alert Stackdriver
75. データパイプライン システム特徴 ① イベントドリブン ② オートスケール ③ ジョブ開始・チェック プロセス分離
76. Data Pipeline Update job check Kubernetes Engine Load job check Kubernetes Engine Data Lake AWS On-premises / Cloud データパイプライン システム特徴 Server Log S3 File copy Kubernetes Engine Data store Cloud Storage DDL Parse & BigQuery Load Kubernetes Engine S3 Notification SQS Load start SQS Load check SQS Update start SQS Table update Kubernetes Engine SQS auto scaler Kubernetes Engine Update check SQS Data warehouse BigQuery Oracle Amazon Redshift Adobe Analytics Slack ① イベントドリブン S3 バケット通知イベント SQS メッセージを起点に、 各処理もすべて SQS によるキュー管理で連携処理を実行
77. Data Pipeline Update job check Kubernetes Engine Load job check Kubernetes Engine Data Lake AWS On-premises / Cloud データパイプライン システム特徴 Server Log S3 File copy Kubernetes Engine Data store Cloud Storage DDL Parse & BigQuery Load Kubernetes Engine S3 Notification SQS Load start SQS Load check SQS Update start SQS Table update Kubernetes Engine SQS auto scaler Kubernetes Engine Update check SQS Data warehouse BigQuery Oracle Amazon Redshift Adobe Analytics Slack ① イベントドリブン S3 バケット通知イベント SQS メッセージを起点に、 各処理もすべて SQS によるキュー管理で連携処理を実行
78. Data Pipeline Update job check Kubernetes Engine Load job check Kubernetes Engine Data Lake AWS On-premises / Cloud データパイプライン システム特徴 Server Log S3 File copy Kubernetes Engine Data store Cloud Storage DDL Parse & BigQuery Load Kubernetes Engine S3 Notification SQS Load start SQS Load check SQS Update start SQS Table update Kubernetes Engine SQS auto scaler Kubernetes Engine Update check SQS Data warehouse BigQuery Oracle Amazon Redshift Adobe Analytics Slack ② オートスケール ファイルコピー、BigQuery へのロードプロセス等が、 SQS メッセージの増減に応じてオートスケール
79. Data Pipeline Update job check Kubernetes Engine Load job check Kubernetes Engine Data Lake AWS On-premises / Cloud データパイプライン システム特徴 Server Log S3 File copy Kubernetes Engine Data store Cloud Storage DDL Parse & BigQuery Load Kubernetes Engine S3 Notification SQS Load start SQS Load check SQS Update start SQS Table update Kubernetes Engine SQS auto scaler Kubernetes Engine Update check SQS Data warehouse BigQuery Oracle Amazon Redshift Adobe Analytics Slack ③ ジョブ開始・チェック プロセス分離 ロード / テーブル更新処理は、 ジョブの開始と完了チェックを分離することで、 少ないプロセス数で、多くの並列処理をこなせる ロード 完了チェック ロード ジョブ開始 テーブル更新 完了チェック テーブル更新 ジョブ開始
80. リクルートライフスタイル BigQuery 基盤は マルチクラウド Why Multi-Cloud?
81. RLS-BigQuery データ基盤 利用プロダクト AWS SQS S3 Kubernetes Engine Cloud Storage Compute Engine Stackdriver
82. 文化的背景 歴史的背景
83. 文化的背景 リクルートライフスタイルには、 自分たちにとって 生産的 で 合理性 があれば、 マルチプラットフォームを選ぶ文化が根付いている 過去から現在まで、Redshift, TreasureData, Exadata と 複数 DWH プラットフォームを導入・併用してきた背景でもある
84. 歴史的背景 Redshift を始めとし、 AWS 環境 で積極的に整備してきた 既存インフラ資産 がある すべてを即座に GCP / BigQuery へ 移行する選択肢は現実的ではなかった
85. キュー管理に SQS を採用した理由 SQS のデッドレターキューが便利だった • デッドレターキュー とは 正常に処理できなかった問題となるメッセージを別の場所に退避してくれるもの ◦ インシデントの調査やリカバリが容易になる ◦ 障害検知を実装しやすい (CloudWatch Alert) 用途が単純なメッセージ連携のため、利便性の観点から AWS SQS を採用した ※ Cloud Pub/Subでも独自実装は可能
86. リクルートライフスタイル BigQuery 基盤で 取り組んだ工夫
87. ① GCP プロジェクト設計 企業固有の配慮 • リクルートライフスタイルは、31のサービスを展開する • サービス(事業)ごとに分社化しても、 データ基盤に大きな変更を加えることなく、 ガバナンスが機能する設計にしておきたかった
88. 用途 プロジェクト データセット 説明 データストア 事業テーブル 7 個 46 個 • 事業単位にプロジェクトを分割 • データ連携元サービス単位にデータ セットを分割 ログ 2 個 8 個 • Adobe Analytics, Google Analytics でプロジェクト分割 データマート 1 個 11 個 • 事業・サービス単位にデータセットを 分割 ユーザー加工テーブル保存 1 個 3 個 システム用 1 個 23 個 ユーザクエリ実行 2 個 - • アドホック分析, BI ツール実行 ① GCP プロジェクト設計 : 事業・用途 単位で分割 ※ 2018 年 8 月時点
89. ② エンドユーザー権限管理 権限管理対象は、 ① IAM ② BigQuery データセット の 2 つある ざっくり言えば、最大で 14 プロジェクト × 750 人 = 10,500 68 データセット × 750 人 = 51,000 これだけの権限を設定・管理する必要 そして、今後も増加する…
90. ② エンドユーザー権限管理 数万の権限設定をメンテ?
91. ② エンドユーザー権限管理 Google グループが使える!!!
92. ② エンドユーザー権限管理 Google グループ で権限管理を集約 横断 参照ユーザー エンドユーザー権限管理 限定 参照ユーザー GCP プロジェクト管理者 エンジニア権限管理 GCP 開発者
93. ③ 連携元スキーマ変換 連携元テーブル定義から、BigQuery テーブル スキーマ定義に変換 • Oracle, MySQL, Redshift の差異を吸収する必要がある ◦ データ型 ◦ CREATE TABLE 文 • 数千テーブルのスキーマ定義を変換する必要がある
94. ③ 連携元スキーマ変換 数千テーブルを人手で変換?
95. ③ 連携元スキーマ変換 変換モジュールを作ってしまえ!!!
96. ③ 連携元スキーマ変換 DDL 構文解析 & BigQuery JSON スキーマ定義変換 Python パッケージを開発 CREATE TABLE Sample_Table ( ID integer PRIMARY KEY, NAME varchar(100) NOT NULL, TOTAL bigint NOT NULL, AVG decimal(5,1) NOT NULL, CREATED_AT date, UNIQUE (NAME) ); [ {"name": "ID", "type": "INTEGER", "mode": "REQUIRED"}, {"name": "NAME", "type": "STRING", "mode": "REQUIRED"}, {"name": "TOTAL", "type": "INTEGER", "mode": "REQUIRED"}, {"name": "AVG", "type": "FLOAT", "mode": "REQUIRED"}, {"name": "CREATED_AT", "type": "DATE", "mode": "NULLABLE"} ] DDL Parse Convert to BQ JSON https://github.com/shinichi-takii/ddlparse/ https://pypi.org/project/ddlparse/ PyPI
97. ④ クエリ作成の生産性 向上 BigQuery WebUI は、 誰でもカンタンに利用できる優れたUI しかし、 クエリや関数等の入力補助、 エディタの使い勝手が欲しい
98. ④ クエリ作成の生産性 向上 https://atom.io/packages/language-sql-bigquery パッケージ を作成 language-sql-bigquery
99. ⑤ 大規模テーブルの参照 ログのような大規模データは、分割 (パーティション) テーブルに保存 問題 • パーティション絞り込みせずクエリ実行される • 大量のテーブルフルスキャンが発生 ◦ オンデマンド契約だと、高額な金額になり得る ◦ FlatRate 契約では、性能限界(Slots)を気にする必要性がある
100. ⑤ 大規模テーブルの参照 ログのような大規模データは、分割 (パーティション) テーブルに保存 解決策 • パーティションフィルタ必須オプション (require partition filter) が 2018 年 3 月 に追加された • テーブルにオプションを設定し、フルスキャンを強制的に抑制
101. ⑥ ロード機能が “エスケープ文字” 非対応 • BigQuery 読み込みジョブは、エスケープ文字に非対応
102. ⑥ ロード機能が “エスケープ文字” 非対応 • BigQuery 読み込みジョブは、エスケープ文字に非対応 RFC 4180 (CSV仕様) には準拠
103. ⑥ ロード機能が “エスケープ文字” 非対応 • BigQuery 読み込みジョブは、エスケープ文字に非対応 • Redshift UNLOAD ファイルと相性が悪い ◦ \”, \\, \t, \改行 (\n ではない) が解釈できない RFC 4180 (CSV仕様) には準拠
104. ⑥ ロード機能が “エスケープ文字” 非対応 • BigQuery 読み込みジョブは、エスケープ文字に非対応 • Redshift UNLOAD ファイルと相性が悪い ◦ \”, \\, \t, \改行 (\n ではない) が解釈できない • Redshift UNLOAD ファイルのクレンジング処理を入れた RFC 4180 (CSV仕様) には準拠 ◦ \” ◦ \\ ◦ \t ◦ \改行 → ”” → \ → TAB char → LF char
105. ⑥ ロード機能が “エスケープ文字” 非対応 • BigQuery 読み込みジョブは、エスケープ文字に非対応 • Redshift UNLOAD ファイルと相性が悪い ◦ \”, \\, \t, \改行 (\n ではない) が解釈できない • Redshift UNLOAD ファイルのクレンジング処理を入れた RFC 4180 (CSV仕様) には準拠 ◦ \” ◦ \\ ◦ \t ◦ \改行 → ”” → \ → TAB char → LF char 処理が重いのが悩みのタネ
106. ⑦ データマート更新 • DML(insert/update/delete/merge) は、裏でテーブルを再作成する • 割り当てポリシー(実行回数上限)よりも、テーブル再作成による パフォーマンス影響を気にした方が良い
107. ⑦ データマート更新 • DML(insert/update/delete/merge) は、裏でテーブルを再作成する • 割り当てポリシー(実行回数上限)よりも、テーブル再作成による パフォーマンス影響を気にした方が良い • できるだけ、DML 発行回数を減らせる処理設計 • 分割(パーティション)テーブルにして、更新対象を減らす
108. ⑧ テーブル作成の生産性 向上 : 従来 ① WebUI ② CLI : bq mk コマンド ~ ❯❯❯ bq mk \ --description "description" \ --schema "table_schema.json" \ --time_partitioning_field='sample_partition' \ --require_partition_filter=true \ project_id:dataset_id.table_name
109. ⑧ テーブル作成の生産性 向上 : 新機能 DDL (Data Definition Language) Beta - Jan. 2018, GA - Jul. 2018 #standardSQL CREATE TABLE `project_id.dataset_id.table_name` (purchase_datetime TIMESTAMP, order_id STRING, amount INT64) PARTITION BY DATE(purchase_datetime) OPTIONS ( description = "description", require_partition_filter = true )
110. ⑨ ユーザー加工テーブル保存制限 前提 データ活用民主化の観点から、 自由なユーザー加工データ保存環境の提供は必須 課題 無尽蔵にテーブルを作成されては、 BigQuery ストレージ料金が膨れあがるリスクがある
111. ⑨ ユーザー加工テーブル保存制限 解決策 : テーブル有効期限を設定 データセットにデフォルトの テーブル有効期限パラメータを設定 テーブル作成時に 有効期限が設定される
112. ⑨ ユーザー加工テーブル保存制限 未解決 : テーブルサイズの制限 ユーザーや、テーブルなどの単位で、 テーブルサイズの上限を設定できるとうれしい 今後の BigQuery に期待
113. 5 まとめ
114. まとめ • BigQuery は、フルマネージド で、 大量データを無限に集積できて、 最高性能を安価に 入手できるプラットフォーム • Google プロダクト連携 を考えれば、BigQuery 一択 • ロード処理がクエリ性能に影響を与えないので、 イベントドリブンでの大量データ連携 は非常に敷居が低い • 足りないものは 自らモジュール開発 することで、障壁をクリア
115. まとめ • 課題 GCP(BigQuery) に詳しいエンジニアがいない 採用が難しい
116. 一緒にGCPを学びたいエンジニア募集中！！
117. Thank you.