初めまして、カケハシのデータ基盤チームでデータエンジニアしている大木と申します。 この度カケハシでは、全社的なデータ活用基盤のプラットフォームとしてDatabricksを採用し、2022/07より本格導入することとなりました。 当記事では、カケハシがDatabricksを採用するに至った技術選定の背景について紹介させていただきます。
※カケハシのデータ基盤の組成のお話はこちらの記事で詳しく紹介されておりますので良ければご覧ください。
カケハシのデータ基盤アーキテクチャと課題
まずカケハシのデータ基盤のアーキテクチャと抱えている課題について紹介します。
Databricks導入に伴い現在は一部変更が入りつつあるのですが、導入前のアーキテクチャとしては以下のような構成になっていました。
- 様々なデータソースから収集した生データをAWSのS3に集約
- Glue、Athena等のETLサービス、分散処理エンジンを用いて分析可能な内容に加工
- BIツールのRedashを入り口として社内に公開
- 顧客向けの機械学習、データ分析用プロダクトのデータとしても活用
- ワークフローエンジンにはAWSのマネージドAirflowを利用
データソースは、カケハシが提供するMusubiを始めとする各種サービスに加えて、薬局のレセプトコンピューター、Salesforce等の外部SaaSまで多岐に渡ります。 ETL処理も定期実行バッチ、ストリーミング処理等様々です。
データ基盤の構築当初はこの構成で利用者の要件を満たせておりましたが、社内での活用が進むにつれて以下のような課題が顕在化してきました。
- 解消し切れていないデータサイロ
- Redash上でのデータソースを横断したデータのJOINが困難。また、SQLの構文がデータソースによって異なる。
- 分析に適さないデータストア、データ構造によるクエリ性能の限界、SQLの複雑化
- データ基盤チームの開発速度と利用側の期待値の乖離（データ基盤チームを中心にした中央集権的組織構造の限界）
- エンジニア不足による開発速度低下、溜まり続ける開発依頼チケット
- 基盤チーム側のドメイン知識の不足
- 開発時のコミュニケーションコストの増大
課題は技術面だけでなく、データ基盤を持続可能な状態で維持・運用するための運用組織体制の面も大きかったので、それらを踏まえたアーキテクチャの改善と技術選定が重要と考えました。
データ基盤の課題の分類
まずは課題を技術面と運用組織体制面に分類しました。それぞれ見ていきます。
技術面の課題
データサイロに起因する課題は技術面に分類出来ます。 これらは、企業が全社的なデータ活用を目指す際に向き合う課題として一般的かと思います。 解決策としては専用のDWH製品等を導入し、データを適切な形で一元管理できる基盤を構築することが解決に繋がると判断しました。
運用組織体制面の課題
続いて、運用組織体制面の課題ですが、個人的にはこの課題への向き合い方が今後のカケハシの事業戦略の面でも重要になるという認識がありました。 技術課題が表面上解決したとしても、データ基盤を品質高く維持し続けられるようになったわけではありません。
以下に挙げるように、データ基盤の準備・整備の工程には継続的なエンジニアリングが必要不可欠であると一般的に言われています。
- 事業環境の変化へ対応するためのデータの追加開発
- 利用者からのフィードバックを基にしたデータの継続的な見直し
- 誤った意思決定を防ぐためのデータの品質の確保
ここに安定してエンジニアリソースを投入できない場合、データは徐々に陳腐化し価値を失っていきます。
課題の解像度を上げるために、現状のカケハシのデータ基盤運用組織の構造について掘り下げてみます。
カケハシでは、データ基盤チームが中央集中的にデータの収集、加工等の開発・整備を担う運用組織になっています。 したがって、組織のデータ活用が進み利用者やユースケースの増加に伴って基盤チームのエンジニアリソースもスケールし続ける必要があることに加えて、各利用者の要件に応じた適切なソリューションを提供するためのドメイン知識も求められます。
私が入社した時点でのチーム体制としては専任の開発ディレクターが一人、専任のエンジニアは私一人でした（他チームとの兼務等でフルタイムで開発に入れないエンジニアが+2名） データエンジニアの採用も苦戦している状況で、いずれエンジニアリソースが頭打ちになることは自明でしたので、チーム規模はこれ以上の大幅なスケールはしない前提でデータ基盤を運用していくための組織構造を考える必要がありました。
ここで参考にしたのがデータメッシュの考え方です。 ※データメッシュとはZhamak Dehghani氏が提唱したデータ基盤アーキテクチャの原則。データメッシュでは各開発ドメインチームが各々のドメインのデータのオーナーシップを持ち、開発を担うことを原則としている。
データ基盤の開発において、データ毎のオーナーシップを各ドメインチームに分散していくデータメッシュのアプローチは合理的であり、実際に導入を考える上でもカケハシのように潤沢なエンジニアリソースの確保が難しい一方で、組織構造の変化への柔軟性を持つようなスタートアップ企業には相性が良いと感じました。
今まではデータ基盤に関する開発オーナーシップを決定する上で技術的な専門性やシステムアーキテクチャを境界として整理することが多く、結果的にデータ基盤チームに集中する構造になっていましたが、今後はビジネスドメインのコンテキストを境界としてオーナーシップを分散し、組織としてのスケーラビリティを確保していくことを目指していければと考えました。
技術選定のポイント
前述した課題を踏まえた上で、カケハシにおけるデータ基盤のプラットフォームの技術選定を行う上で重視したいポイントとしては「将来的にデータメッシュの思想に近い形でデータ基盤と運用組織を変革していくことを視野に入れつつ、顕在化している技術的な課題も解決できるサービスを採用すること」と整理しました。
Databricksの評価ポイント
結論としてDatabricksを採用することを決めたのですが、決め手となったポイントをまとめると、大きく分けて以下になります。
- Databricksが提唱しているデータレイクハウスのアーキテクチャ、Databricksの優れた開発体験は課題解決に大きく寄与する
- 既存のカケハシの開発人員のスキルセット、開発資産との親和性が高い
データレイクハウスアーキテクチャについて
データレイクハウスとは、データレイクの柔軟性、経済性、スケーラビリティとデータウェアハウスのデータ管理や ACID トランザクションの機能を取り入れたオープンで新たなデータ管理アーキテクチャで、あらゆるデータにおけるビジネスインテリジェンス（BI）と機械学習（ML）を可能にします。 （引用：Data Lakehouse）
Databricksのデータレイクハウスのアーキテクチャでは、Delta Lake, Apache Sparkといったオープンな仕様の技術をベースに、AWS S3等のオブジェクトストレージ上でファイルベースのデータ基盤を構築することできます。 ストレージやクエリの処理エンジンが工程を通じて統一されるため、従来のデータレイク + データウェアハウスのようにデータパイプラインの工程毎にシステムが分離されるアーキテクチャと比較した場合、システムの複雑性の排除、開発コスト削減、データのガバナンス・マネジメントコストの削減に繋がると期待しました。
※データレイクハウスの思想に関しては、社内の有志による勉強会にてレイクハウスアーキテクチャの論文の読み合わせを行っていたという経緯もあり、技術選定の際はより解像度高く評価できました。
Databricksの開発体験
技術選定の際はDatabricks以外にも複数のデータ基盤プラットフォームを実際に触ってPoCを行いましたが、Databricksで得られる開発体験は魅力的でした。
DatabricksではDWHとしての機能だけでなく、ワークフローエンジン、クエリエンジン、Notebook、BIツール、機械学習モデルの管理等、データ基盤を構成する技術要素をオールインワンで提供しており、ほぼ標準機能で基盤構築を完結できます。
データソースから抽出したデータをデータレイクに格納した後は、データの加工、ロード、ダッシュボード作成まで全てDatabricks上で実装が可能になり、データパイプラインを実装する際にAWSやGCPなどのパブリッククラウドサービスの機能を自前で組み合わせるケースもかなり減らせるため、アーキテクチャをシンプルに出来ます。
その結果として、社内におけるデータエンジニアリングのスキルセットの大部分を標準化することが可能になり、中長期的に以下のような効果が見込めると考えています。
- 社内でのデータエンジニアリングの知見の蓄積・共有による生産性の向上
- 開発メンバーの学習コストの削減、チームを越境したエンジニアリソースの流動性の確保
- 共通ロジックの再利用性の向上
上記に加えて、Gitリポジトリーとの連携機能やGUI操作での簡単なNotebook環境のプロビジョニングが可能である事、Notebookを実装する言語をPython, Scala, SQL, Rから自由に選択できる事などもPoCに参加してくれた現場のエンジニアからも好評でした。
これらの優れた開発体験を通じて、各自が本質的な関心事に集中しやすい環境を整えることで今後より専門性を発揮する事に期待が持てます。
また、前項で触れた運用組織構造の変革の観点でも期待できる点が多いです。
前提としてカケハシでは、各開発ドメインチーム毎にAWSアカウントを分離するインフラ管理のアーキテクチャになっており、各チームがオーナーシップを持ってAWS環境を管理する形をとっています。
DatabricksではWorkspaceという単位で環境を細かく分割し、ホストするAWSアカウントも個別に選択できるようになっているため、今後ドメイン毎のデータのオーナーシップを渡していくことを考える上で、既存のAWSインフラ管理と近い形でシステムインフラの設計と運用ができます。
一方で、個別に環境が分かれデータとインフラの管理の主体を分散させていくことと同時に各チームのデータに相互運用性を持たせること、横断的なガバナンスを効かせること等も考慮する必要があります。
その点でもDatabricksの機能はそれらを補助してくれる要素が多いと感じます。
例えばUnity Catalog機能では、システム上分離された各Workspace環境を横断したデータの共有が可能になります。 各チームの個別のAWSアカウント上で収集したデータを、個別のチームのDatabricks環境でETL処理を行い、最終的に全社共通のデータストアで社内の全員に共有する。といったアーキテクチャが構築可能で、システムの物理的な境界を強く意識せずに各チームで実装が可能になります。
また、Unity CatalogではWorkspaceを横断した全ての環境からのアクセスコントロールの一元管理が可能で、カケハシのデータ基盤上に存在する生データ->加工済みデータ->ユースケース毎に集計されたデータに至るまでの横断的な権限管理、セキュリティ確保、アクセスログ、リネージュの追跡が可能になると見込んでいます。
（引用： Unified Data Access on the Lakehouse）
既存の開発人員のスキルセット、開発資産との親和性
既存のデータ基盤のアーキテクチャを刷新する上で考慮したいことの一つに移行コストがあります。
技術選定を行う上で既存人員のスキルセット、既存の開発資産との兼ね合いを考える必要がありますが、その点でもDatabricksはカケハシとの親和性が高かったと言えます。
まずエンジニアのスキルセットで言うと、既存のデータ基盤周辺の開発資産のメインのプログラミング言語はPython、データ処理エンジン・フレームワークはApache Spark on AWS Glue、データフォーマットはParquet等の構成で実装するケースが多く、Databricks移行後もそのまま使える技術とデータ資産があり、他のプラットフォームと比較して親和性が高い結果になりました。
また、BIツールには元々Redashを採用していたため、DatabricksのSQL機能、BI機能と高い互換性がありました（Redash自体が現在はDatabricks傘下であり、UIや機能面でベースはかなり近い）
この記事の中では開発者目線での話がほとんどでしたが、データは現場で活用されて初めて価値が生まれるため、ユーザー体験も損なわずに違和感なく環境を移行できることも選定時の観点に含まれます。
結果的にDatabricksに乗り換えることで既存のRedash環境から使用感が大きく変わることなく、機能としては上位互換に位置するためその辺も高評価でした。
Databricks導入後のアーキテクチャ
最後に、まだ構築段階ではありますがDatabricks導入後のカケハシのデータ基盤のアーキテクチャのイメージも紹介します。
- AWS環境にDatabricksのWorkspaceを作成し、Delta Lake, Apache Sparkを利用してS3上にデータレイクハウスを構築
- レイクハウス上のデータをメダリオンアーキテクチャの設計思想を参考に、データの抽象度に応じてBronze, Silver, Goldと論理的に3つのレイヤーに分けて格納
- Redashの代替としてDatabricks SQL機能で利用者はデータにアクセス
まとめ
今回Databricks採用に至った背景と技術選定の話をご紹介しましたが、正式に導入が決まり利用開始したのは7月のことで実はまだ2ヶ月程度しか経っておりません。 社内での本格導入に向けてようやく走り出せたタイミングです。 今後も実際に運用して得られた知見、詳細なアーキテクチャ、データ基盤の現在地をブログを通じて発信していければと思います。
また、カケハシではデータ基盤を一緒に開発してくださる仲間を募集しております。 今回の記事で少しでも興味を持っていただいた方のご応募お待ちしております。
