Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Databricksで築く未来のデータメッシュ組織/The Datamesh Organization Built with Databricks

kakehashi
January 16, 2024

Databricksで築く未来のデータメッシュ組織/The Datamesh Organization Built with Databricks

kakehashi

January 16, 2024
Tweet

More Decks by kakehashi

Other Decks in Business

Transcript

  1. © KAKEHASHI Inc. 株式会社カケハシ データ基盤チーム データエンジニア 松田 健司 • 2014年、新卒としてヤフー株式会社にて

    広告配信のためのDMP開発に従事。 • 2016年、株式会社カケハシに入社し、 薬歴システム「Musubi」の開発。 • 2019年、薬局経営ダッシュボード 「Musubi Insight」チームの立ち上げ。 • 2022年、全社横断のデータ基盤チームを立 ち上げ、7月にDatabricksを導入。 自己紹介
  2. © KAKEHASHI Inc. © KAKEHASHI Inc. テクノロジーで、 薬局をあるべき形に。 全国に、コンビニエンスストアより多い約 6万店が存在する調剤薬

    局。その経営や薬剤師の業務、患者さんとの関係性など、薬局の あり方そのものをアップデートし、薬局 DX(デジタルトランスフォー メーション)を推進する、独自のプロダクトを展開しています。
  3. © KAKEHASHI Inc. 5 解決手段 • データエンジニアの専門スキルをドメインチームへ展開 • 中央集権型のアーキテクチャから分散型アーキテクチャへの移行 問題

    • 複数のドメインチームに対して、1つのデータ基盤チームという関係性 • コミュニケーションコストの高さ ◦ ドメインチームの専門的なデータエンジニアリングの知識不足 ◦ 基盤チームのドメイン知識不足 考察 • データ基盤チームの増員も考えられたが ◦ バーティカルSaaSのため今後もプロダクトが増える ◦ データエンジニアの採用難 • 受発注の関係性ではなく、負荷を平準化する方が全体最適につながる。 中央管理のデータ基盤から、分散管理のデータ基盤へ
  4. © KAKEHASHI Inc. 6 セルフサービス型データ基盤 カケハシのデータメッシュアーキテクチャ データメッシュアーキテクチャの4つの原則 データガバナンス担当 ドメインチーム 中央組織

    (データ基盤チーム) 原則3 セルフサービス型 データ基盤 原則1 ドメイン オーナー シップ 原則4 横断的なデータガバナンス データガバナンス機能 データ提供(Data Producer) データ利用(Data Consumer) データ利用者 加工 原則2 データのプロダクト化 加工 加工 加工
  5. © KAKEHASHI Inc. 8 Repository コードリポジトリ ドメインチームアカウント Databricksの利用事例 - IaCとモノレポ

    Infra as Code(IaC)とモノレポ化により、各ドメインチームの生産性を上げ、開発難易度を下げる。 実行環境 GitHub Actions(CI/CD) データガバナンスアカウント (データ基盤アカウント) Test terafform (apply) CI/CDパイプライン Terraform コード モノレポ化 モノレポ化により理解しや すい構成とする。 統一されたビルド/デプロイ のパイプラインを用意し生 産性を上げる。 Terraformにて、Databricks のコンポーネントを抽象化 されたオブジェクトとして 定義し、開発難易度を下げ る。 Workspace Storage Account Cluster Workspace Cluster Storage Storage Account Console Metastore UnityCatalog
  6. © KAKEHASHI Inc. 9 Databricksの利用事例 - メダリオンアーキテクチャとワークスペース分離 メダリオンアーキテクチャ※1 メダリオンアーキテクチャを元に、ワークスペースを分離し各ドメインの境界を明確にする レイクハウスのデータを論理的に整理するために用いられ

    る。当社ではSilverを提供側と利用の境界線として定義 データ提供者 公開 Raw データ利用者 目的別 目的別 ワークスペースの分離 Domain Account1 Domain Account2 ドメイン単位にワークスペース(AWSアカウント)を分けて 管理 ※1 出典:メダリオンアーキテクチャ Workspace Workspace データ基盤アカウント Unity Catalog 各ドメイン間で 共有するデータ は公開
  7. © KAKEHASHI Inc. 10 Unity CatalogでManaged TableとExternal Tableへの アクセスを一元管理 Databricksの利用事例

    - RBACとUnity Catalog ロールベースのアクセス制御(RBAC)で運用 + Unity Catalogで一元管理 ロールベースアクセス制御 リソースをレベル分けし、レベルに応じてグループ (ロール)からアクセス ※1 現在は、データ基盤担当が権限付与を行っている。 Unity Catalogで一元管理 Managed Table Unity Catalog External Table (S3等) MODIFY SELECT グループ 権限 リソース 操作 データオーナー※1 ユーザをグループに追 加
  8. © KAKEHASHI Inc. 11 一定のルールで、データ品質をチェック。 - Delta Live Table(DLT):DLTの機能で品質チェック -

    DLT以外のジョブ:Deltalakeテーブル、 または、Deequでデータ品質をチェック Databricksの利用事例 - DLTとデータリネージ データの品質を担保するため、一定のルールでチェック、データ間連携を可視化 データ品質管理 データリネージ データ間の関連性を可視化し、データの源泉を確認する。 ブロンズ、シルバー、ゴールド間のデータを可視化。
  9. © KAKEHASHI Inc. 12 Databricksの利用事例 - メタデータと利用状況洞察 データを扱いやすいようにメタデータ管理と管理者が利用状況を簡易に把握可能 メタデータ管理 ビジネスメタデータとして、テーブルのコメントに、

    意味や使用方法を記載する。 利用状況洞察 当該テーブルに頻繁にアクセスしているユーザ、ノート ブック、ダッシュボード、実行クエリーを一覧する。
  10. © KAKEHASHI Inc. 13 簡易にモデルを開発することができる。 モデルを開発者間でナレッジを共有したり、 ガバナンスを構築することができる。 Databricksの利用事例 - MLflow

    MLflowを利用により、開発体験の向上とMLサービス開発の迅速化 モデル開発・管理 実験の追跡・デプロイ 簡易にモデルの実験と結果を共有できる。 結果に応じて迅速にデプロイできる。