こんにちは、データスペシャリストのS.Y.です。
本記事では、データ分析基盤チーム組成の背景や立ち上げ初期に行ったこと、そして現在の取り組みについてご紹介いたします。

背景

弊社では以前からデータアナリストおよびそのチームは存在していたものの、分析業務が属人化していました。
そのような事態に陥ってしまった原因は、いくつかあります。

・事業の数に対して、データアナリストが足りていなかったこと
・評価が個人のアウトプットにフォーカスされがちであったこと
・ドキュメントを残す文化がなかったこと
・データ分析基盤がなかったこと
等

自身も当時、そのデータアナリストの一人であり、上記の課題を感じていました。
特に、データ分析基盤がないことで不便に感じることは多くありました。
そのため、その状況を改善するために主務以外の時間でデータ分析基盤の構築を試みましたが、スキル的にも時間的にも足りておらず、なかなか思うように進めることができませんでした。

そのような課題を抱える中、2023年に思わぬ好機が訪れました。それは、全システムのクラウド移行プロジェクトです。
今までオンプレサーバー上にMySQLを立てて、そこに直接アクセスしていましたが、それらを廃止しました。
それに伴い、データ分析の手法を再考することになりました。
クラウド移行にある程度時間がかかることはビジネスサイドも理解していたため、十分な時間を確保することができ、今までやりたかったデータ分析基盤の構築に着手することができました。
今思うと、データ分析基盤の構築は片手間ではできないので、このタイミングで時間を確保できたことがその後に大きく影響したように思います。

また、同時に「データエンジニアリングチーム」というその分野に注力する専任チームができました。
厳密には、これまで形式的にチームとして集まっていたものが、1つの目的のもと機能する組織に生まれ変わりました。

少し長くなりましたが、このような背景からデータ分析基盤構築チームが組成されました。
次に、実現までの流れを紹介します。

立ち上げ初期に行ったこと

初期に行ったことは、大きく分けると3つあります。
・データ分析基盤に関するインプット
・要件定義&サービス選定
・データアーキテクチャ

データ分析基盤に関するインプット

なにはともあれ、まずはデータ分析基盤について一定の理解をする必要がありました。
そのため、チーム全員で様々なテックイベントに参加したり、サイトを見たりしてインプットしていきました。
他社事例を見ることで解像度が上がり、大まかに構想していた「データレイク」「データウェアハウス」「データマート」案を、当社の文化や組織体制に合った形に具体化させることができました。

要件定義&サービス選定

データ分析基盤

一定の理解が進んだ後は、要件定義およびサービス選定に取り組みました。
もし、データ分析基盤構築プロジェクトを単体で動かすのであれば、要件の洗い出しと精査、そして対象となりうるサービスの比較検討フェーズが必要です。しかし、今回はクラウド移行の方針に沿うことが最優先であったため、正直なところ細かな検討はしていません。

クラウド移行プロジェクトでは、クラウドサービスを「Google Cloud」に1本化することが決定したため、必然的にデータ分析基盤には「BigQuery」を使用することが決まりました。
BigQueryは、他社事例でもよく目にしていたツールであり、記事なども豊富であったため、まさに願ったり叶ったりでした。

実際にサービスを活用し始めて、大幅なランニングコストの削減に繋がっていることを実感しています。
マルチクラウドは冗長性を考慮するなら必要かと思いますが、複雑になりがちであるため、初期段階では選択肢から外すべきだと思います。

データパイプライン

データ分析基盤の核となるサービスが決定した後は、データパイプラインの構築です。
つまり、どのような流れでBigQueryにデータを持ってくるか、ということです。
データ分析基盤は、特に熟考することなくBigQueryに決定しましたが、データパイプラインに関しては正直悩みました。
当時、Google Cloudにおけるデータパイプラインサービス（≒ETLツール）は複数存在しており、各サービスの位置付けを正しく把握できるほどの知見もなかったため、サービスを選定するのは困難でした。
そこで、データパイプラインに関しては、「クリティカルな要件を満たすサービスの選定さえできれば、多少本来の用途と異なるなどの問題があったとしても許容する」という方針に変更しました。

弊社のデータパイプラインにおけるクリティカルな要件というのは、「リアルタイムのデータ更新」と「コスト」でした。

・リアルタイムのデータ更新
弊社では営業系のトランザクションデータが多く、そのデータをいかに素早く分析して戦略を立てるかが事業成長の鍵となるため、リアルタイムでのデータ更新が必要不可欠です。
このようなニーズに応えてくれるサービスは、変更データキャプチャ（CDC）サービスと呼ばれています。そして、Google Cloud でCDCサービスといえば、「Dataflow」と「Datastream」があります。

本記事では、両サービスの細かい比較はしませんが、別記事にて「データパイプライン」の技術的な内容を書く予定ですので、そちらをご覧いただければと思います。

・コスト
以下の事項を考慮しながら、開発から運用・保守・監視に至るまでのトータルコストを抑える構成を検討しました。
・数人で開発から運用・保守まで行えること※チーム組成時の人数は数人
・全体的に年齢が浅くて経験が浅くても対応できること
・数多くのデータパイプライン開発依頼を処理できること
・様々なデータソースに対応できること

これらの観点で考えたとき、残念ながら全てを網羅するサービスはなかったため、コストが最も抑えられそうなDatastreamを最有力候補としつつ、それだけで対応できない場合は他のサービスを使い分けるというハイブリットな方法を採用しました。

結果的に、以下のような構成図に落ち着きました。

現在の取り組み

現在は、「対応可能なデータソースを増やすこと」と「既存のデータパイプラインの見直し」をメインに取り組んでいます。

対応可能なデータソースを増やすこと

クラウド移行に伴い、大半のデータは「Cloud SQL」で管理できましたが、一部例外は残っています。
その例外データに対応したデータパイプライン構築の優先度が高まってきたため、「Embulk」やその他サービスの利用の検証を始めています。
当該プロジェクトは、分析に必要なデータの整備をすることが前提ですが、その一方で、チーム全体のデータエンジニアリング力の向上も目的としています。
どのデータソースにも対応できるようになれば、データエンジニアとしての活躍の幅が広がるため、この動きは続けていく予定です。

既存のデータパイプラインの見直し

立ち上げ期に定めた方針（「クリティカルな要件を満たすサービスの選定さえできれば、本来の用途と異なるなど多少選択を誤ったとしても許容する」）は、当初の状況を考えると結果的に最善でした。
しかし、ノウハウがある程度身についた今、当初の方針のまま運用していくわけにはいきません。適切なサービスの活用やコスト最適化など課題があるため、それらの改善に少しずつ着手しています。

具体的には、現在一部のデータパイプラインで、「Cloud Composer」をETLプロセスの実行ツールとして活用しているものがあります。これは学習コストを最小限に抑えることを重視した結果ですが、Cloud Composerはあくまでもオーケストレーションツールであり、本来はETLジョブを構成するタスクを管理するのに適したサービスであるため、当該用途での使用は適切ではありません。
適切な活用方法としては、Cloud ComposerのタスクとしてDataflowなどのETLツールを呼び出して実行することが挙げられます。
このように、現在既存のデータパイプラインの見直しをしています。

まとめ

チーム立ち上げの背景および現在の活動内容についてご紹介しました。
データ分析基盤は、データメッシュや権限管理など、まだまだやるべきことが多くあります。
今回ご紹介したのは、ほんの一部に過ぎません。
今後の記事で、私や同じチームのメンバーが様々な角度でデータ分析基盤についてご紹介していくことになると思いますので、ご興味のある方はチェックしていただけますと幸いです。