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

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

Transcript

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