パフォーマンスとコスト改善のために法人データ分析基盤をBigQueryに移行した話

イベントページ：
・TECH PLAY：https://techplay.jp/event/969003
・connpass：https://tech-street.connpass.com/event/342831/

Transcript

1. パーソルキャリア株式会社 リードエンジニア 梅本 誠也 パフォーマンスとコスト改善のために 法人データ分析基盤をBigQueryで構築した話
2. 今後の課題・方針や各種技術・ツールへの言及等は、個人の見解や 知見のシェアを目的としており、組織を代表するものではありません。 会社説明 社名：パーソルキャリア株式会社 設立：1989年6月15日(創業) 従業員数：6,929名（有期社員含む。グループ会社出向中の者は除く。2024年3月1日時点） 参照: https://www.persol-career.co.jp/corporate/overview/ 2
3. 今後の課題・方針や各種技術・ツールへの言及等は、個人の見解や 知見のシェアを目的としており、組織を代表するものではありません。 3 ミッション
4. 今後の課題・方針や各種技術・ツールへの言及等は、個人の見解や 知見のシェアを目的としており、組織を代表するものではありません。 自己紹介 名前：梅本 誠也 X(旧Twitter): @seiyasm18 業務： データエンジニア 法人データ基盤構築、運用 ETLやデータカタログツール選定及び導入のPoC LLMアプリエンジニア 全社向けの生成AIチャットアプリ開発 社員の目標設定を支援する生成AIチャットアプリ開発 LLMOpsチームでのR&D活動 経歴 韓国5年間留学、フィリピン&アメリカ短期留学経験有り 学生時代の研究テーマ： 自動トレード、ラジコンカーの自動走行 趣味： 登山、ランニング、キングダム、Pivot、技術関連のオフ会 好きなプログラミング言語： Go, TypeScript, Python 好きなサービス： Google Cloud Run, Azure AI Foundry 4
5. 今後の課題・方針や各種技術・ツールへの言及等は、個人の見解や 知見のシェアを目的としており、組織を代表するものではありません。 はじめに 結論 目次 今後の課題 まとめ Q&A 5 取り組んだこと
6. • 法人データ分析基盤の概要と課題 • 今回の話の前提 はじめに 6
7. 今後の課題・方針や各種技術・ツールへの言及等は、個人の見解や 知見のシェアを目的としており、組織を代表するものではありません。 法人データ分析基盤の概要 7 • 分析環境/BI環境 • 全社向けの共通基盤。 • 専用のAWSアカウントを発行することで全社員がアクセスできる • 課題点 • 7000人規模の会社で共通管理していることもあり – コンプライアンスチェックに時間がかかる – 実際全てのデータソース(SFDC等)を基盤側に反映できているわけ ではない、、 目的に特化したデータ分析基盤を独自に作り、アジリティを確保したい AWS上に法人データ分析基盤を構築 • 今回は法人に関わるデータの分析基盤を独自に構築 ・ 人事向け等、他にも別プロジェクトで構築済みのものも存在
8. 今後の課題・方針や各種技術・ツールへの言及等は、個人の見解や 知見のシェアを目的としており、組織を代表するものではありません。 既存の法人データ分析基盤の課題 ・導入背景 ・データの物理的な統合を避けるため、仮想化を採用 ・各事業のデータを維持しつつ、統一的な分析環境を提供 Google Cloud基盤への移行の意志決定 ・課題点 ・データ未整備：データソース側の統一基準がないため、プッシュダ ウン最適化が難しい ・クエリの複雑性：オプティマイザの最適化範囲を超えるクエリ構造 ・スケール限界：EC2上のキャッシュ運用の限界 ・コスト問題：ライセンスコストが増大 8
9. 今後の課題・方針や各種技術・ツールへの言及等は、個人の見解や 知見のシェアを目的としており、組織を代表するものではありません。 今回の話の前提 • 法人データ分析基盤の対象ユーザー – クライアントP&M組織のデータマネジメントチーム – 同組織のデータアナリスト・データサイエンティスト • 今後は事業部側の担当チーム • Google Cloudへ基盤を移行済みで、運用を開始している • チーム体制はデータエンジニアチームとデータマネジメントチームの合同体制 9
10. 結論 10 BigQueryでの法人データ分析基盤構築を通して
11. 今後の課題・方針や各種技術・ツールへの言及等は、個人の見解や 知見のシェアを目的としており、組織を代表するものではありません。 BigQueryでの法人データ分析基盤構築を通して 11 構築の背景 旧データ仮想化基盤の課題 弊社データソース側のデータ環境の未整備の問題（結果プッシュダウンがしずづらい）など データ仮想化を現時点では有効活用できていなかったため →上記の背景および現行課題を解消すべく、BigQuery中心のデータ基盤へ再構築を決断 構築の成果 パフォーマンス向上：クエリ実行速度改善 コスト削減：BigQueryの従量課金活用で削減 データ活用促進のアジリティ向上：独自データ分析基盤による恩恵 今後の展望 ・データカタログ整備 ・データ仮想化技術の再検討 ・dbt導入でデータモデリング標準化 →さらなるデータ活用の強化を推進！
12. • BigQueryでの構築背景と課題 • データ基盤の最適化 • クエリ最適化と分析環境の強化 • 運用体制の整備 取り組んだこと 12
13. 今後の課題・方針や各種技術・ツールへの言及等は、個人の見解や 知見のシェアを目的としており、組織を代表するものではありません。 全社基盤を見据えた法人データ分析基盤の構想 なぜ法人データ分析基盤が必要だったのか？ ・背景 ・全社分析基盤に統合されていないデータが存在(例：未連携のSFDCデータ) ・組織横断分析の課題 ・全社分析基盤のデータのみでは分析に必要な情報が不十分 ・事業部ごとの独自データも考慮した基盤が必要 ・データ仮想化とBigQuery構築の背景 ・データソース側の未整備により、プッシュダウンが効かずパフォーマンス劣化 ・データ仮想化の最適化が困難→活用しきれず ・データ仮想化サービスの利用停止を検討し、BigQuery中心の新基盤を構築 13 ・データメッシュとSSoTの考え方 ・SSoTの概念をデータメッシュに統合し、各ドメインで一貫性と正確性を維持 ・事業部側の各データソースはSSoTとして機能 ・今後全社的にはデータメッシュによる統合を目指す
14. 今後の課題・方針や各種技術・ツールへの言及等は、個人の見解や 知見のシェアを目的としており、組織を代表するものではありません。 データ仮想化技術の導入 コンプライアンス観点 ・データを移動せずにリアルタイム統合が可能 ・各部署の独自DB（Salesforce, ERP, RDB, CRMなど）をそのまま活用できる ・SQLベースで統一されたデータアクセスを提供し、Power BI / TableauなどのBIツ ールとシームレスに連携可能 導入の背景と制約 ・全世界的に導入事例が多い ・当時、当該データ仮想化ツールがクラウドネイティブではなく、セルフホスティングの選択肢の みが提供されていた ・社内のコンプライアンス上も、外部SaaSよりも AWS共通基盤でのセルフホスティングが推奨 されていた AWSのEC2上に基盤を構築 14
15. 今後の課題・方針や各種技術・ツールへの言及等は、個人の見解や 知見のシェアを目的としており、組織を代表するものではありません。 データ仮想化技術の課題点 ただ、AWSのEC2上でホスティングしているということもあり、、 1️⃣プッシュダウンの最適化が組織間で調整困難 ・クエリの処理をデータソース側に委ねる「プッシュダウン(※次スライドで補足)」最適化が必要だ ったが、組織的にその連携の難しさが顕在 2️⃣スケール・リアルタイム性の限界 ・業務上ファイル連携が多いが、尚更メモリの消費が多くなり、キャッシュを多用しないとパフォー マンスが維持できないバッチ処理がメインになり、リアルタイム分析ニーズに対応できなくなった 3️⃣コストの問題 ・データ仮想化サービスのライセンス自体のコストの圧迫 (インスタンスを増強できるが、2倍にすると、コストも2倍に、、) 実際バッチ処理が月次でしか行えず、日次で行いたいニーズに添えなくなっていた 上記の主要課題を解消すべく新たな法人データ基盤を構築 15
16. 今後の課題・方針や各種技術・ツールへの言及等は、個人の見解や 知見のシェアを目的としており、組織を代表するものではありません。 補足：プッシュダウンとは 通常のデータ仮想化は、複数のデータソースからデータを取得し、仮想ビューを通じて統合的に扱う。 →プッシュダウンとは、データ仮想化ツールがクエリをデータソース側で実行させる仕組み。 つまり、データを転送してから処理するのではなく、処理をデータソース側で済ませてから結果だけを取得する。 SoR1 SoR2 データ 仮想化層 SoI SoR1 SoR2 データ 仮想化層 SoI プッシュダウンなし プッシュダウンあり 必要以上のデータを 取得するためスルー プットが大きい 事前にグルーピングする ことでスループットを抑え られる データ仮想化層 の負荷が大きい データ仮想化層 の負荷が小さい 16
17. 今後の課題・方針や各種技術・ツールへの言及等は、個人の見解や 知見のシェアを目的としており、組織を代表するものではありません。 新たな法人データ基盤の構築先をどうするか 17 社内で活用実績のあるサービスを検討 DWHとしての移行先候補 ・BigQuery ・Snowflake ・Redshift ・Azure Synapse Analytics BigQueryを有力な選択肢として採用 ・フルマネージド、従量課金、自動スケーリングの要素に加え、隣接していたチームがDataplex & Looker & BigQueryを活用しており、知見を活かしながらスピード感を持って進められることがで きると判断。 ・部署内でもGoogle Cloud基盤でのアプリケーション構築の実績が多く、親和性が高いことが見 込まれる
18. 今後の課題・方針や各種技術・ツールへの言及等は、個人の見解や 知見のシェアを目的としており、組織を代表するものではありません。 補足：なぜBigQueryなのか? 全社基盤という構想の上では、マルチクラウド環境に適したSnowflakeを選択する余地はあるが、部署内での他プロジェクトとの親和性 を考慮すると、Google Cloudと親和性の高いBigQueryを選定する形となった。 また現状はUSリージョンでしか使えないが、 BigQuery Omniによりクロスクラウドの分析が可能になるため、そちらの発展にも期待したい。 18 項目 BigQuery Snowflake Redshift Azure Synapse スケーラビリティ 自動スケール 仮想ウェアハウス単位でスケー ル Redshift Serverlessで自 動スケール サーバーレス SQLプールで自 動スケール コストモデル 従量課金（使った分だけ） 従量課金（クレジット消費） Redshift Serverlessで従 量課金 サーバーレス SQLプールで従 量課金 運用の手軽さ フルマネージド フルマネージド Redshift Serverlessでフルマ ネージド サーバーレス SQLプールでフルマ ネージド Google Cloudとの親和性 Google Cloudネイティブサー ビス Google Cloudリージョンでの Snowflake利用が可能 AWSサービスとし てGoogle Cloudとの直接統合 は限定的 AzureサービスとしてGoogle Cloudとの直接統合は限定的 （他Google Cloud製品と も統合容易） 社内知見の有無 他チームが活用中 知見なし 他チームが活用中 知見なし
19. 今後の課題・方針や各種技術・ツールへの言及等は、個人の見解や 知見のシェアを目的としており、組織を代表するものではありません。 移行にあたっての注意 移行において重要なのは、、 利用ユーザーの既存の業務フローを崩さないこと！ →ある程度の汎用性を維持しつつ可能な限り影響を抑える 業務フローの洗い出しとデータ仮想化サービスの機能との結びつきを整理 Google Cloud上で実現する際の実現法を整理する 優先順位を整理し、フェーズを分けて移行を進める 19
20. 今後の課題・方針や各種技術・ツールへの言及等は、個人の見解や 知見のシェアを目的としており、組織を代表するものではありません。 フェーズ分け→受け入れ条件 ETL・データマネジメントツールの選定 ・Google CloudのETL&データマネジメント製品(Dataproc, Dataplex等)も候補として検討 ・最終的にTroccoを選定した主な理由 ・データマネジメントの使いやすさが優れていた ・データ転送とデータマネジメント機能の統合が可能だった 移行フェーズと受け入れ条件 ・Ph1: データ仮想化で実施していた処理をETL+BigQueryで代替 ・受け入れ条件: データマネジメントチームの検証で、移行後のデータに差分がないことを確認 ・月次更新→日次更新が可能になることを保証 ・Ph2: データカタログの整備(今後の課題) 20 ただし、法人データ基盤構築後の運用面で課題が顕在化 →PoC段階では想定していなかった要件が増え、部分的にGoogle Cloudに切り出すことに （Cloud Run Jobs等）
21. 今後の課題・方針や各種技術・ツールへの言及等は、個人の見解や 知見のシェアを目的としており、組織を代表するものではありません。 業務フローと現状のデータ仮想化基盤における機能の洗い出し Virtual private cloud (VPC) Data Virtualization BI環境 pull (JDBC) push (CSV) AWS Cloud リアルタイムデータ取得 ファイルデータのリアルタイム参照 BI環境へのデータ連携 Private subnet Private subnet Private subnet 旧分析環境 21 ・Redshift(旧分析環境)上のデータをVPC内で JDBC経由でPullし、データを取得 ・EC2内で社内ファイルサーバをマウントし、デー タ仮想化基盤から参照 ・データマネジメントチームが直接アップロードするファイルあり ・他組織から定期的に共有されるファイルあり ・データマートをCSVとして社内BI環境へPushし、 BIツールと連携 pull (ファイル) ※1: 現在は新分析環境としてAzure Databricksへ移行済み
22. 今後の課題・方針や各種技術・ツールへの言及等は、個人の見解や 知見のシェアを目的としており、組織を代表するものではありません。 洗い出した機能要件のフィジビリ検証 BI環境へのデータ連携 ・データマートをCSVとして社内BI環境へPushし、 BIツールと連携 1. 移行前（現状の問題点） リアルタイムデータ取得 ・Redshift(旧分析環境)上のデータをVPC内でJDBC 経由でPullし、データを取得 ファイルデータのリアルタイム参照 ・EC2内で社内ファイルサーバをマウントし、 データ仮想化 基盤から参照 ・データマネジメントチームが直接アップロードするファイルあり ・他組織から定期的に共有されるファイルあり 2. 移行後（Google Cloudでの対応策） AWSのVPCからGoogle Cloudへ移行 ・移行により、AWSのVPC内でのデータ取得が困難に ・新たなデータ連携方式が必要 ファイルデータの連携方式をCloud Storageに変更 ・社内ルールによりCSV連携が必要 → CloudStorageにアップロード ・IAMによるアップロード許可を設定 ・元々ファイルサーバーにアップロードされていたデータを Cloud Storageに統合（合意済み） Cloud Storage → Eventarc → Cloud Workflows で処理 ・Cloud Run Jobsを活用し、確実にデータ転送 ・リアルタイムではないが、近い形で処理可能 （合意済み） プロキシ経由でBigQueryへアクセス ・VPC Service Controls（VPC SC）を利用し、 セキュリティを確保 22
23. 今後の課題・方針や各種技術・ツールへの言及等は、個人の見解や 知見のシェアを目的としており、組織を代表するものではありません。 法人データ基盤構成図 Cloud Storag e Workflows 1. ファイルアップロード 2. トリガー実行 ファイル前処理ジョブ Cloud Run Jobs 3. Workflowsを実行 4. Cloud Run Jobsを起動 Eventarc 5. 前処理後のファイルをアップロード Eventarc 6. トリガー実行 Workflows 7. Workflowsを実行 8. データ転送を実行 （SDKを使っているが、 内部ではbq loadを実行） ファイル転送ジョブ Cloud Run Jobs 9. データセットのテーブル データを更新 分析 基盤 ユーザー 前処理が必要なファイルの場合は ファイル前処理をする 1. Excelファイル 2. Shift-JISのCSVファイル 3. カラムのマッピングが必要なファイル UTF-8のカラムマッ ピングがされたCSV BigQuery ここでデータ更新差分の チェック→slack通知ま で行っている 23
24. 今後の課題・方針や各種技術・ツールへの言及等は、個人の見解や 知見のシェアを目的としており、組織を代表するものではありません。 補足：なぜCloud Run Jobsなのか? 24 前提：CSV連携をトリガーにBigQuery側へデータ転送する →DataprocやDataflowのような分散処理基盤は現状は必要ないと判断し、Cloud Run Jobsでミニマムに構築 →ただ、今後要件次第で部分的に組み込む可能性はある Cloud Run Jobs Dataflow（Apache Beam） Dataproc（Spark） セットアップの容易さ コンテナ実行のみでOK（軽 量） Apache Beam パイプラインの定義 が必要 Spark/Hadoop クラスタのセッ トアップが必要 運用負荷 フルマネージド・ジョブ単発実行 （シンプル） ジョブ監視・パイプライン管理が必要 クラスタのスケーリングや管理が必 要 適したジョブ規模 小〜中規模のバッチ処理向け ストリーミング＆大規模バッチ向け 大規模データの分散処理向け 処理の柔軟性 コンテナ内で自由にコードを記 述可能（言語制約なし） Apache Beam の制約あり（特殊 なAPIが必要） Sparkエンジンの制約あり スケーラビリティ 自動スケール（ジョブ単位で実 行） ストリーミングスケール可能 Spark クラスタで分散処理 コスト 実行中のみ従量課金（アイドルコ ストなし） ジョブワーカーの最低コスト発生 クラスタ維持コストがかかる Eventarc / Workflows との連携 親和性が高く統合しやすい （シンプルなバッチ処理向け） パイプライン管理が複雑 ワークフロー組み込みが難しい ユースケース 軽量・中規模のバッチ処理 （ETL, データ整形, マッピング） ストリーミングデータ処理（ログ分 析, IoT, Big Data） 大規模バッチ（ML, DWH 処理, 分散ETL）
25. 今後の課題・方針や各種技術・ツールへの言及等は、個人の見解や 知見のシェアを目的としており、組織を代表するものではありません。 法人データ基盤全体構成図 SFDC 分析基盤 ＆ 外部連携 Raw Data用 データセット BigQuery BIツール データカタログ データ活用層 加工済み データセット データ連携層 Cloud Run 必要に応じてカスタマイズ データレイクハウス データマート作成
26. 今後の課題・方針や各種技術・ツールへの言及等は、個人の見解や 知見のシェアを目的としており、組織を代表するものではありません。 選定技術 ・開発言語： ・データ転送パイプライン：Go ・ライブラリ： ・バッチ処理：Cobra ・Google Cloud SDK ・インフラ：Google Cloud ・DWH：BigQuery ・自動テスト： ・単体テスト：testify ・CI/CD：Github Actions ・SaaS ・Salesforce ・Trocco 26
27. 今後の課題・方針や各種技術・ツールへの言及等は、個人の見解や 知見のシェアを目的としており、組織を代表するものではありません。 SQLのリファクタリング→データマートの構築 Resources exceeded during query execution: Not enough resources for query planning - too many subqueries or query is too complex 仮想データベース上ではビューで構築できていたものだが、 BigQuery上では中間テーブルで対処。 ※CREATE TEMP TABLE句での対処も可能だが、クエリ実行時の推 定バイト数の計算ができなくなるため、中間テーブルで対処する形とした。 27
28. 今後の課題・方針や各種技術・ツールへの言及等は、個人の見解や 知見のシェアを目的としており、組織を代表するものではありません。 SQLのリファクタリング→データマートの構築 1つのクエリで参照可能なリソースの最大数→1,000個 （一つのデータマート作るのにテーブルやビューを1,000個以上は参照で きないという制約） 元々のクエリの複雑性が生んでいた問題。こちらも同様に中間テーブル を作成することで対処。 28 参照：https://cloud.google.com/bigquery/quotas?hl=ja#query_jobs
29. 今後の課題・方針や各種技術・ツールへの言及等は、個人の見解や 知見のシェアを目的としており、組織を代表するものではありません。 SQLのリファクタリング→データマートの構築 そもそも中間テーブルを作成しても良いのか？ →データ仮想化技術で実現していたリアルタイム更新を BigQuery上でも実現する必要がある。 暫定対応：DLにデータ転送後に、中間テーブルを作成するクエリを実行す ることで、データマート側でのデータ鮮度を担保する形で対処 恒久対応：データマートそのもののリファクタリング 29 参照：https://cloud.google.com/bigquery/quotas?hl=ja#query_jobs
30. 今後の課題・方針や各種技術・ツールへの言及等は、個人の見解や 知見のシェアを目的としており、組織を代表するものではありません。 SQLのリファクタリング→データマートの構築 Cloud Run Jobs(32GB)のメモリ超過 データ転送時の差分検知をCloud Run Jobs上で行っていたが、 10GBを超えるCSVが一部含まれていることで発生 暫定対応：ファイルサイズに上限を設けて、巨大なCSVに対しては差分検 知を行わないように修正 恒久対応：データ分析基盤運用側で連携ファイルのサイズに上限を設けて、 それを超える場合は分割してもらう対応を入れる。 30
31. 今後の課題・方針や各種技術・ツールへの言及等は、個人の見解や 知見のシェアを目的としており、組織を代表するものではありません。 BIで可視化→データリネージ&データカタログの整備 31 Power BIを既存で利用しているため、BigQueryへ移行後もダッシュボード(データマート)の整 合性を確認しながら検証。 データリネージの可視化 ・現状、TROCCOを利用しているが、一部の転送フローとの統合に課題があった。 ・TROCCOは転送処理ベースのデータリネージ機能を提供しており、今回の移行フローでは追加の 工夫が必要であった。 ・Cloud Storage経由の転送が増加する中、現行の運用と調整が求められた。 ・補完的にDataplexを併用し、データリネージの可視化を強化することを検討。 データカタログの最適化 ・データカタログは、これまでTROCCOを利用していたが、 より最適なデータ管理の形を模索している。 ・今後はDataplexを併用し、統合的なデータ管理を実施予定。
32. 今後の課題・方針や各種技術・ツールへの言及等は、個人の見解や 知見のシェアを目的としており、組織を代表するものではありません。 補足：TROCCOの制約とデータ転送の課題 ・Cloud Storageを経由したCSV連携のユースケースが増加する中、 TROCCOの転送設定が手動管理となり、運用負荷が増大する。 ・今後の拡張性を考慮すると、運用面での課題が顕著になった。 ・TROCCOのマネージドデータ転送機能は、一括設定が可能だが、 Cloud Storageのようなストレージには非対応（2025/01/30時点） ・BigQuery Data Transfer Service も同様の制約があり、Cloud Storageへの柔軟な転送が難しい。 ・Cloud StorageでCSV転送時、フォルダ単位での転送設定は可能だが、フォルダ 配下のCSVが単一のBigQueryテーブルに紐づく制約がある。 ・法人データ分析基盤では、フォルダ配下の各ファイルを別々の BigQueryテーブ ルに紐づける運用をしたいため、データパイプラインの実装でカバーする形を取った。 32
33. 今後の課題・方針や各種技術・ツールへの言及等は、個人の見解や 知見のシェアを目的としており、組織を代表するものではありません。 運用体制の整備と管理フロー 33 障害発生時の対応フローを標準化し、エスカレーションルールを整備。 各レイヤーの対応責任者を明確化し、迅速な対応が可能な体制を構築。 オブザーバビリティ：Cloud Monitoring & Cloud Loggingの 組み合わせでログレベルに合わせて閾値を設定し、Slackに通知 Terraformを活用し、データマートの管理を自動化・一元管理。 申請ベースでBigQueryのデータセット・テーブル・権限設定を動的に適用。
34. • データカタログの整備とデータ透明化 • データガバナンス強化とデータ統合の最適化を検討 • 各種ツールについて 今後の課題 34
35. 今後の課題・方針や各種技術・ツールへの言及等は、個人の見解や 知見のシェアを目的としており、組織を代表するものではありません。 データカタログの整備とデータ透明化 35 データカタログの目的は、データのビジネス的な意味を即座に理解できる環 境を提供すること。 →特に新規メンバーがデータを活用しやすくし、業務の属人化を防ぐ。 現状、データの意味を理解するには、担当者への個別問い合わ せが必要なケースが多い。 →事業部ごとに管理ルールが異なり、データの統一的な定義が存在しない →結果として、データ活用が進みにくく、業務効率も低下している。 現在、別プロジェクトでデータモデリングの整備と並行して、データカタログの 統合を進めている。 → OSSのOpenMetadataやDataHub などの活用も検証したい。
36. 今後の課題・方針や各種技術・ツールへの言及等は、個人の見解や 知見のシェアを目的としており、組織を代表するものではありません。 データガバナンス強化とデータ統合の最適化を検討 BigQueryへ移行後も、データの管理・アクセス制御に関する課題が継続している データの複製を抑えつつ、より効率的なデータ統合手法を検討 データ統合技術の選択肢 1️⃣ クラウドネイティブなデータ統合技術の活用を検討 2️⃣BigQuery Omniなどの新しいデータ統合手法の適用可能性を評価 3️⃣ データ管理・統合の柔軟性を高めるためのソリューションを比較 36
37. 今後の課題・方針や各種技術・ツールへの言及等は、個人の見解や 知見のシェアを目的としており、組織を代表するものではありません。 各種ツールについて① データ転送要件の変化に伴い、ツールの最適化を検討 ・カタログ機能の提供形態が変更されたため、運用方法を再評価。 ・ETLツールの選択肢としてFivetranを含めた複数のツールを検討し、状況に応じて Cloud run JobsやDataflow、Dataprocと組み合わせる可能性を模索。 ・データカタログの管理手法として、OSSのOpenMetadataや DataHub、Google CloudのDataplexの選択肢を比較検討。 37
38. 今後の課題・方針や各種技術・ツールへの言及等は、個人の見解や 知見のシェアを目的としており、組織を代表するものではありません。 各種ツールについて② 今回の移行においても導入は検討し、検証入れたが、 既存クエリをリファクタリングするコストが大きすぎた(サブクエリ構造が複雑) ・Jinjaテンプレートエンジンによってコードの再利用性とメンテナンス性を向 上させたい ・データモデリングの知見をデータアナリスト側にも共有できる状態にしたい ・データ品質チェックを一元管理させたい ・DAGのドキュメントを管理したい ・Trocco(今後はCometa)は既存のサブクエリ構造もカラムリネージ化し てくれるところが大きかったが、コストの問題もあるため、新規のモデリングは dbtで管理することを視野に入れている 38 dbtについて
39. 今後の課題・方針や各種技術・ツールへの言及等は、個人の見解や 知見のシェアを目的としており、組織を代表するものではありません。 各種ツールについて③ BIツールの最適化を検討 既存のBIツール(Power BI)を活用しながら、基盤移行を進めた ユーザービリティの向上を目的に、改善の検討が進められている BIツールの選択肢 ・Tableau / Looker / ThoughtSpotなどを比較検討 ・RBACの機能が業務フローやチーム体制に適合するかを評価 ・PoCを通じて適切なツールの選定を進める 39
40. まとめ 40
41. 今後の課題・方針や各種技術・ツールへの言及等は、個人の見解や 知見のシェアを目的としており、組織を代表するものではありません。 まとめ 【取り組んだこと】 ・当初はデータ仮想化を活用し、組織のフェーズに適した基盤を構築 ・しかし、データソース側の未整備により、プッシュダウンの最適化が困難 ・結果として、データ仮想化サービスの活用が難しくなり、BigQuery中心のデータ基盤へ再構築を決 断 ・既存のデータ仮想化がカバーしていた業務フローをGoogle Cloud上で再構築し、業務影響を最小 化 ・Power BIでダッシュボードの整合性を検証し、再構築後の運用を確立 【今後の展望】 ・dbtやデータカタログツールを導入し、データ管理を強化 ・BigQueryのアップデート(BigQuery Omni等)を考慮し、柔軟に最適な構成を検討 ・データ仮想化技術の再検討: 組織フェーズに応じた最適なデータ活用を模索 ・データ分析基盤の運用体制整備: Terraform等を活用し、申請フローと運用管理を更に強化 41
42. Q＆A 42