$30 off During Our Annual Pro Sale. View Details »

データガバナンスの視点から見たデータメッシュアーキテクチャ / data mesh architecture

kakehashi
September 21, 2023

データガバナンスの視点から見たデータメッシュアーキテクチャ / data mesh architecture

kakehashi

September 21, 2023
Tweet

More Decks by kakehashi

Other Decks in Business

Transcript

  1. Copyright © KAKEHASHI Inc. All Rights Reserved.
    データガバナンスの視点から見たデータメッシュアーキテクチャ
    株式会社 カケハシ 東 浩稔

    View Slide

  2. © KAKEHASHI Inc. 2
    株式会社カケハシ
    データ基盤 プロダクトマネージャー
    東 浩稔(あずま ひろとし)
    大手金融機関系列のシステムインテグレーター、ヤ
    フー株式会社、アマゾンウェブサービスジャパン合同
    会社を経て 2023年7月に株式会社カケハシにジョイ
    ン。
    データ基盤のプロダクトマネージャーとして全社の
    データ活用やデータガバナンスを推進。
    自己紹介
    写真

    View Slide

  3. © KAKEHASHI Inc.
    目次
    1. カケハシの事業とプロダクトのご紹介
    2. データメッシュ化の背景とDatabricksの導入
    3. データメッシュにおけるデータガバナンス
    4. データガバナンスとDatabricksの統合事例
    5. 今後の展望

    View Slide

  4. © KAKEHASHI Inc.
    目次
    1. カケハシの事業とプロダクトのご紹介
    2. データメッシュ化の背景とDatabricksの導入
    3. データメッシュにおけるデータガバナンス
    4. データガバナンスとDatabricksの統合事例
    5. 今後の展望

    View Slide

  5. © KAKEHASHI Inc.
    目次

    View Slide

  6. Vision
    明日の医療の基盤となるエコシステムの実現。

    View Slide

  7. © KAKEHASHI Inc.
    カケハシのこれまでの歩み
    積極的な資金調達を背景に、プロダクトリリースおよびM&Aを駆使したサービス拡大を実施
    創業
    2016 2017 2018 2019 2020
    Musubi
    リリース
    Series A
    8.6億円調達
    Series B
    26.6億円調達
    Musubi
    Insight
    Pocket
    Musubi
    リリース
    Series B+
    17.5億円調達
    2021
    医薬品二次流通
    事業のM&A
    Musubi AI在庫管理
    リリース
    2022
    市場シェア
    10%獲得
    ハイブリッド融資
    23億円調達
    2023
    Series C
    94億円調達

    View Slide

  8. © KAKEHASHI Inc.
    プロダクトのご紹介 - Musubi

    View Slide

  9. © KAKEHASHI Inc.
    プロダクトのご紹介 - Musubi Insight

    View Slide

  10. © KAKEHASHI Inc.
    プロダクトのご紹介 - Musubi Insight

    View Slide

  11. © KAKEHASHI Inc.
    プロダクトのご紹介 - Musubi Insight

    View Slide

  12. © KAKEHASHI Inc.
    事業内容
    薬局DXを推進し、医療体験の向上を支援するサービスラインナップ

    View Slide

  13. © KAKEHASHI Inc.
    目次
    1. カケハシの事業とプロダクトのご紹介
    2. データメッシュ化の背景とDatabricksの導入
    3. データメッシュにおけるデータガバナンス
    4. データガバナンスとDatabricksの統合事例
    5. 今後の展望

    View Slide

  14. © KAKEHASHI Inc. 14
    カケハシのデータ基盤は、2022年10月にアーキテクチャが変わる
    カケハシのデータ基盤の変遷
    2019年〜2022年9月
    データレイクアーキテクチャ
    2022年10月〜
    データメッシュアーキテクチャ
    提供元 利用者
    提供元
    提供元 利用者
    利用者
    提供元 利用者
    提供元
    提供元 利用者
    利用者

    View Slide

  15. © KAKEHASHI Inc. 15
    2019年〜2022年のカケハシのデータ基盤
    2019年に、データに基づいた意思決定で各プロダクトの改善を行い、お客様に高い
    付加価値を届けるために、データ基盤と担当するチームが設立される
    2019年〜2022年のデータ基盤アーキテクチャ

    View Slide

  16. © KAKEHASHI Inc. 16
    2019年〜2022年のカケハシのデータ基盤
    データ基盤を構築後、社内のデータ活用は順調に進む
    主な活用例
    ● 社内データ分析、可視化のケース
    ○ プロジェクト管理、KPI、NSMの計測
    ○ ヘルススコアの導出
    ○ システムのSLA、SLO監視
    ○ 人事採用進捗、実績の可視化
    ● プロダクトでの利用ケース
    ○ 機械学習
    ○ 事業の実証結果分析
    ○ BIレポーティング

    View Slide

  17. © KAKEHASHI Inc. 17
    2019年〜2022年のカケハシのデータ基盤
    運用開始後、徐々に課題が顕在化
    顕在化した課題
    ● 中央組織であるデータ基盤チームがボトルネックになり、利活用
    までのリードタイムが延びる

    View Slide

  18. © KAKEHASHI Inc. 18
    2019年〜2022年のカケハシのデータ基盤
    運用開始後、徐々に課題が顕在化→ドメインチームからの依頼が増えはじめたこと
    が要因
    顕在化した課題
    ● 中央組織であるデータ基盤チームがボトルネックになり、利活用
    までのリードタイムが延びる
    要因
    ● ドメインチームからのデータ作成依頼の増加
    ● 各プロダクトの新しいチャレンジや、改善サイクルの短縮化

    View Slide

  19. © KAKEHASHI Inc. 19
    構造的な問題
    ● 複数のドメインチームに対して、1つのデータ基盤チームという
    関係性(N:1の関係)
    ● コミュニケーションコストの高さ
    ○ ドメインチームの専門的なデータエンジニアリングの知識不足
    ○ 基盤チームのドメイン知識不足
    2019年〜2022年のカケハシのデータ基盤
    運用開始後、徐々に課題が顕在化→ 構造的な課題は中央集権のアーキテクチャと組
    織と特定。
    顕在化した課題
    ● 中央組織であるデータ基盤チームがボトルネックになり、利活用
    までのリードタイムが延びる
    要因
    ● ドメインチームからのデータ作成依頼の増加
    ● 各プロダクトの新しいチャレンジや、改善サイクルの短縮化

    View Slide

  20. © KAKEHASHI Inc. 20
    解決手段
    ● データエンジニアの専門スキルをドメインチームへ展開
    ● 中央集権型のアーキテクチャから分散型アーキテクチャへの移行
    (再掲)構造的な問題
    ● 複数のドメインチームに対して、1つのデータ基盤チームという関係性
    ● コミュニケーションコストの高さ
    ○ ドメインチームの専門的なデータエンジニアリングの知識不足
    ○ 基盤チームのドメイン知識不足
    考察
    ● データ基盤チームの人員を増やすことで対応力を向上させる方法も考えられたが、当社は患者様、薬局様を
    中心に、複数プロダクトでご支援するエコスシステムを構築していくため、今後もプロダクトが増えること
    は予想される。将来的に同様の問題が発生すると見込まれ現実的ではない。
    ● 受発注の関係性ではなく、負荷を平準化する方が全体最適につながる。
    中央管理のデータ基盤から、分散管理のデータ基盤へ

    View Slide

  21. © KAKEHASHI Inc. 21
    データメッシュとは
    「複雑かつ大規模な環境において、組織内または組織横断的に分析データを共有、
    アクセス、管理するための新しい分散型アプローチ」※
    分散型アーキテクチャであるデータメッシュとは?
    分散型アーキテクチャであるデータメッシュの導入
    ※出典 オライリー Data Mesh

    View Slide

  22. © KAKEHASHI Inc. 22
    複数のプロダクトを展開する当社と照らし合わせた結果、柔軟性、拡張性、迅速さに優位性がある分散型を採用
    中央集権型と分散型アーキテクチャの比較
    中央集権型(データレイク) 分散型(データメッシュ)
    概要 データの形式問わず一元化されたデータリポジトリに保存し、一つ
    の中央チームが加工・集計することが多い。
    分散された各事業や組織が主体となり信頼できるデータを作成し相
    互に連携する。ルールやガバナンスは中央組織で行う。
    イメージ
    柔軟性/拡張性/迅
    速さ
    中央組織が各組織と調整する。中央組織がボトルネックになりがち
    である。受発注関係になり優先度等の理由で迅速さに欠ける。
    各組織間で自律して動き、変更に対して柔軟性がある。
    基本的には2つの組織間の調整になるため、迅速である。
    アーキテクチャの
    複雑さ
    一元化されたアーキテクチャのためシンプル 各組織間のパス毎にデータ連携が必要になるため複雑
    ガバナンス 一元化されたデータリポジトリと中央組織のため、統制の難易度は
    低い
    分散化されたデータリポジトリと、各組織でデータを管理するため統
    制の難易度が高い
    提供元 利用者
    提供元
    提供元 利用者
    利用者
    提供元 利用者
    提供元
    提供元 利用者
    利用者

    View Slide

  23. © KAKEHASHI Inc. 23
    カケハシのデータメッシュアーキテクチャ(論理アーキテクチャ)
    カケハシのデータメッシュアーキテクチャ
    データガバナンス担当
    ドメインチーム 中央組織(データ基盤チーム)
    データ利用者
    データ提供(Data Producer) データ利用(Data Consumer)
    加工
    加工
    加工
    加工

    View Slide

  24. © KAKEHASHI Inc. 24
    データメッシュには4つの原則がある
    データメッシュ4つの原則
    原則 概要 目的
    1
    ドメインオーナー
    シップ
    データの所有権を、データ
    に最も近いビジネスドメイ
    ンに分散
    ● 組織の成長に合わせて、スケールアウト可能
    ● ドメインオーナーと利用者間のコミュニケーション改善
    2
    プロダクトとしての
    データ
    データをプロダクトとして
    扱い、利用者と直接共有
    ● データはチームが共有するプロダクトになり、データサイ
    ロを防ぐ(従来の中央集権のように、別のシステムで収集
    して加工することがない。)
    ● 境界を明確にすることで、変更に対する影響を最小化
    3
    セルフサービス型
    データ基盤
    ドメインチームがデータを
    共有できるようにするセル
    フサービス型のデータプ
    ラットフォームサービス
    ● データの分散所有にかかる総コストを削減
    ● データ管理の複雑さを抽象化し、ドメインチームの負荷を
    軽減
    4 連合型ガバナンス
    各専門家でチームを構成し
    データガバナンスモデルを
    構築します
    ● 分散データ製品のメッシュ全体に、セキュリティ、プライ
    バシー、法令順守などの横断的なガバナンス要件を組み込

    View Slide

  25. © KAKEHASHI Inc. 25
    セルフサービス型データ基盤
    カケハシのデータメッシュアーキテクチャ
    データメッシュアーキテクチャの4つの原則に照らし合わせる
    データガバナンス担当
    ドメインチーム 中央組織(データ基盤チーム)
    原則3
    セルフサービス
    型データ基盤
    原則1
    ドメイン
    オーナーシッ

    原則4
    横断的なデータ
    ガバナンス
    データガバナンス機能
    原則4
    連合型ガバナン

    データ提供(Data Producer) データ利用(Data Consumer)
    データ利用者
    加工
    加工
    加工
    加工
    原則2
    プロダクトとしてのデータ

    View Slide

  26. © KAKEHASHI Inc. 26
    セルフサービス型データ基盤
    データ提供(Data Producer) データ利用(Data Consumer)
    データ利用者
    加工
    加工
    加工
    加工
    カケハシのデータメッシュアーキテクチャ
    原則3:セルフサービス型データ基盤の検討
    データガバナンス担当
    ドメインチーム 中央組織(データ基盤チーム)
    原則3
    セルフサービス
    型データ基盤

    View Slide

  27. © KAKEHASHI Inc. 27
    分散型アーキテクチャは複雑になりやすい → 新しいデータ基盤製品の検討が必要
    【再掲】:中央集権型と分散型アーキテクチャの比較
    中央集権型(データレイク) 分散型(データメッシュ)
    概要 データの形式問わず一元化されたデータリポジトリに保存し、一つ
    の中央チームが加工・集計することが多い。
    分散された各事業や組織が主体となり信頼できるデータを作成し相
    互に連携する。ルールやガバナンスは中央組織で行う。
    イメージ
    柔軟性/拡張性/迅
    速さ
    中央組織が各組織と調整する。中央組織がボトルネックになりがち
    である。受発注関係になり優先度等の理由で迅速さに欠ける。
    各組織間で自律して動き、変更に対して柔軟性がある。
    基本的には2つの組織間の調整になるため、迅速である。
    アーキテクチャの
    複雑さ
    一元化されたアーキテクチャのためシンプル 各組織間のパス毎にデータ連携が必要になるため複雑
    ガバナンス 一元化されたデータリポジトリと中央組織のため、統制の難易度は
    低い
    分散化されたデータリポジトリと、各組織でデータを管理するため統
    制の難易度が高い
    提供元 利用者
    提供元
    提供元 利用者
    利用者
    提供元 利用者
    提供元
    提供元 利用者
    利用者

    View Slide

  28. © KAKEHASHI Inc. 28
    データメッシュとDatabricks
    現状
    ● 今日のデータ基盤は、データレイク、データ
    ウェアハウス、データマートで構成すること
    が多い。
    ● また、それぞれを別のサービスや製品で組
    み合わせる事が多い。(得手不得手がある
    ため最適なデータベースを選択するのは正
    しい。)
    セルフサービス型データ基盤製品の選定の要件
    ドメインオーナーシップを実践するにあたり、可能な限りデータエンジニアリングの専門性を下げることが必要
    考察
    ● データベース製品を組み合わせて使うこと
    で、それぞれスキル獲得が必要になり高い
    専門性が要求される。
    ● データベース製品間のデータを同様の状態
    に保つ運用コストは大きく、データ移動のた
    めのELTも複雑になる傾向がある。
    ● データベース製品を分けずに統一プラット
    フォームを検討する。
    結論
    ● Databricksのレイクハウスプラットフォーム
    は単一プラットフォーム上で、データレイク、
    データウェアハウスを統合して管理が可能。
    ● レイクハウスによりデータのサイロを防ぎ、
    運用コストを下げる
    ● ETL、ストレージ、処理、ガバナンス、
    AI、BI
    等が同一プラットフォームで利用可能
    アーキテクチャ選定の根拠
    データ製品やデータ自体のサイロ化を減らせる点、獲得するスキルを最小限に抑えることができる点、様々なワークロー
    ドを同一プラットフォーム上で実装できる点から、Databricksのレイクハウスプラットフォームを選定。

    View Slide

  29. © KAKEHASHI Inc. 29
    カケハシのデータメッシュアーキテクチャ
    カケハシのデータメッシュアーキテクチャ(物理アーキテクチャ)
    ドメインチームアカウント
    Workspace
    ドメインチームアカウント
    Workspace
    ドメインチームアカウント
    Workspace
    ドメインチームアカウント
    Workspace
    データ基盤アカウント
    Unity Catalog
    下記を管理
    ・各ドメインのデータ
    ・Workspace
    ・コスト
    データ提供(Data Producer) データ利用(Data Consumer)
    データガバナンス

    View Slide

  30. © KAKEHASHI Inc.
    目次
    1. カケハシの事業とプロダクトのご紹介
    2. データメッシュ化の背景とDatabricksの導入
    3. データメッシュにおけるデータガバナンス
    4. データガバナンスとDatabricksの統合事例
    5. 今後の展望

    View Slide

  31. © KAKEHASHI Inc. 31
    データガバナンス※とは?
    「データ資産の管理(マネジメント)に対して、職務権限を通して統制(コント
    ロール)する」
    統制(コントロール)※とは?
    「計画を立て、実行を監視し、徹底させること」
    データガバナンスの定義
    ※ 出典:データマネジメント知識体系ガイド第二版
    解釈すると
    「データの品質、セキュリティ、プライバシー等を保証し、データを適切に管理す
    るためのプロセスやルールを定義、監視、改善すること」

    View Slide

  32. © KAKEHASHI Inc. 32
    データガバナンスの目的
    データ品質の確保
    - 正確なデータが良質な意思決定をサポートする
    セキュリティの強化とリスク軽減
    - 適切なアクセス制御とセキュリティ対策で、データの漏洩や不正アクセス等のリスクを下げる
    規制とプライバシーの対応
    - データ保護の規制や業界基準に準拠し、個人情報、プライバシーを保護する枠組みを作る
    データ利活用の最大化
    - データの適切な管理と整備により、効果的な分析や新しい洞察を引き出し、ビジネス価値を最大
    化させる
    信頼性と透明性の向上
    - データの信頼性と透明性を上げることで、ステークホルダーとの信頼を築くことができる

    View Slide

  33. © KAKEHASHI Inc. 33
    分散型アーキテクチャのガバナンスは難易度が高い → 当社の取り組みをご紹介します
    【再掲】:中央集権型と分散型アーキテクチャの比較
    中央集権型(データレイク) 分散型(データメッシュ)
    概要 データの形式問わず一元化されたデータリポジトリに保存し、一つ
    の中央チームが加工・集計することが多い。
    分散された各事業や組織が主体となり信頼できるデータを作成し相
    互に連携する。ルールやガバナンスは中央組織で行う。
    イメージ
    柔軟性/拡張性/迅
    速さ
    中央組織が各組織と調整する。中央組織がボトルネックになりがち
    である。受発注関係になり優先度等の理由で迅速さに欠ける。
    各組織間で自律して動き、変更に対して柔軟性がある。
    基本的には2つの組織間の調整になるため、迅速である。
    アーキテクチャの
    複雑さ
    一元化されたアーキテクチャのためシンプル 各組織間のパス毎にデータ連携が必要になるため複雑
    ガバナンス 一元化されたデータリポジトリと中央組織のため、統制の難易度は
    低い
    分散化されたデータリポジトリと、各組織でデータを管理するため統
    制の難易度が高い
    提供元 利用者
    提供元
    提供元 利用者
    利用者
    提供元 利用者
    提供元
    提供元 利用者
    利用者

    View Slide

  34. © KAKEHASHI Inc. 34
    データが、複数の場所で分散配
    置されるため、複雑な構成にな
    りやすく難易度が高い。
    データメッシュにおけるデータガバナンス
    分散型アーキテクチャでデータガバナンスが困難な理由
    複雑な構成 アクセス制御の煩雑さ 不安定な品質と理解が困難
    アプリ
    データの連携先や、利用者が多
    岐にわたるため、アクセス制御
    が煩雑になりやすい。
    各ドメインでデータを管理する
    ため、データ品質を保証する仕
    組みがバラバラになりやすい。
    また、データが分散配置され、
    流通し共有されるので、データ
    の所在、流通経路、内容の理解
    が困難である。

    View Slide

  35. © KAKEHASHI Inc. 35
    データメッシュにおけるデータガバナンスの対応方針
    データメッシュにおけるデータガバナンスは、下記のとおり人、プロセス、テクノ
    ロジーを組み合わせて実践する。
    データガバナンスが困難な理由 対応方針
    実施内容
    人 プロセス テクノロジー
    複雑な構成
    データが、複数の場所で分散さ
    れ管理され、複雑な構成で難易
    度が高い。
    ①ポリシーとプロセスの
    明確化
    ・データガバナンス担当
    ・ドメインチーム
    ・データメッシュに合わ
    せたポリシーとルールを
    策定し、ドメインチーム
    が運用
    ・レビューやガイドライ
    ン、相談会による支援
    ・ワークスペースの分離
    ・Infra as Code
    アクセス制御
    の煩雑さ
    データの連携先や、利用者が多
    岐にわたるため、アクセス制御
    が煩雑になりやすい。
    ②権限委譲と一元化され
    たアクセス制御
    ・データガバナンス担当
    ・データスチュワード、
    データオーナー
    データアクセスポリシー
    およびルールを策定し、
    データ共有と公開の権限
    を委譲し、ドメインチー
    ムが運用
    ・アクセス制御管理
    ・アクセス記録の監査
    ・データ要求と承認記録
    不安定な品質
    と理解が困難
    各ドメインでデータを管理するた
    め、データ品質を保証する仕組みが
    バラバラになりやすい。
    また、データが分散配置され、流通
    し共有されるので、データの所在、
    流通経路、内容の理解が困難であ
    る。
    ③製品の機能を利用した
    品質、メタデータの管理
    ・データガバナンス担当
    ・ドメインチーム
    データ品質のポリシーお
    よびルールを策定し、ド
    メインチームが運用
    ・データ品質管理
    ・データリネージ
    ・メタデータ管理

    View Slide

  36. © KAKEHASHI Inc.
    目次
    1. カケハシの事業とプロダクトのご紹介
    2. データメッシュ化の背景とDatabricksの導入
    3. データメッシュにおけるデータガバナンス
    4. データガバナンスとDatabricksの統合事例
    5. 今後の展望

    View Slide

  37. © KAKEHASHI Inc. 37
    データ提供(Data Producer) データ利用(Data Consumer)
    データ利用者
    加工
    加工
    加工
    加工
    原則4:横断的なデータガバナンスを実現する事例のご紹介
    カケハシのデータメッシュアーキテクチャ
    データガバナンス担当
    ドメインチーム 中央組織(データ基盤チーム)
    原則4
    横断的なデータ
    ガバナンス
    データガバナンス機能
    原則4
    連合型データガ
    バナンス

    View Slide

  38. © KAKEHASHI Inc. 38
    再掲:データメッシュにおけるデータガバナンス
    データガバナンスが困難な理由 対応方針
    実施内容
    人 プロセス テクノロジー
    複雑な構成
    データが、複数の場所で分散さ
    れ管理され、複雑な構成で難易
    度が高い。
    ①ポリシーとプロセスの
    明確化
    ・データガバナンス担当
    ・ドメインチーム
    ・データメッシュに合わ
    せたポリシーとルールを
    策定し、ドメインチーム
    が運用
    ・レビューやガイドライ
    ン、相談会による支援
    ・ワークスペースの分離
    ・Infra as Code
    アクセス制御
    の煩雑さ
    データの連携先や、利用者が多
    岐にわたるため、アクセス制御
    が煩雑になりやすい。
    ②権限委譲と一元化され
    たアクセス制御
    ・データガバナンス担当
    ・データスチュワード、
    データオーナー
    データアクセスポリシー
    およびルールを策定し、
    データ共有と公開の権限
    を委譲し、ドメインチー
    ムが運用
    ・アクセス制御管理
    ・アクセス記録の監査
    ・データ要求と承認記録
    不安定な品質
    と理解が困難
    各ドメインでデータを管理するた
    め、データ品質を保証する仕組みが
    バラバラになりやすい。
    また、データが分散配置され、流通
    し共有されるので、データの所在、
    流通経路、内容の理解が困難であ
    る。
    ③製品の機能を利用した
    品質、メタデータの管理
    ・データガバナンス担当
    ・ドメインチーム
    データ品質のポリシーお
    よびルールを策定し、ド
    メインチームが運用
    ・データ品質管理
    ・データリネージ
    ・メタデータ管理
    データメッシュにおけるデータガバナンスは、人、プロセス、テクノロジーを組み
    合わせて実践する。

    View Slide

  39. © KAKEHASHI Inc. 39
    Databricksの統合事例 - ①ポリシーとプロセスの明確化 / テクノロジー
    メダリオンアーキテクチャ※1
    メダリオンアーキテクチャを元に、ワークスペースを分離し各ドメインの境界を明確にする
    レイクハウスのデータを論理的に整理するために用いられ
    る。当社ではSilverを提供側と利用の境界線として定義
    データ提供者
    公開
    Raw
    データ利用者
    目的別
    目的別
    ワークスペースの分離
    Domain Account1
    Domain Account2
    ドメイン単位にワークスペース(AWSアカウント)を分けて
    管理
    ※1 出典:メダリオンアーキテクチャ
    Workspace
    Workspace
    データ基盤アカウント
    Unity Catalog
    各ドメイン間で
    共有するデータ
    は公開

    View Slide

  40. © KAKEHASHI Inc. 40
    Repository
    コードリポジトリ
    ドメインチームアカウント
    Databricksの統合事例 - ①ポリシーとプロセスの明確化 / テクノロジー
    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

    View Slide

  41. © KAKEHASHI Inc. 41
    レビュー、ガイドライン、個別相談等の取り組みによりドメインチームを支援
    支援形態 概要 目的 参加者
    アーキテクチャー
    レビュー
    プロダクト横断のデータ連携、および接続の
    際には、接続方式(バッチ/ストリーム/API
    等)の妥当性を確認、および一貫性を保つた
    めに、中央組織※1によるレビューを実施し、
    大まかな設計の方向性を示す。
    プロダクト横断の連携方式の妥当
    性、一貫性を保ち、全社視点で技
    術負債を抱えないこと。
    ※なお、API接続等では、
    Databricksを使用しない場合もあ
    りえる。
    レビューイー
    ● ドメインチーム
    レビューアー
    ● プラットフォームチーム
    ● データ基盤チーム
    ガイドラインの提示
    Databricksでの設計、開発のポイント、実装
    方法、その他注意点等を提示し、ドメイン
    チームが困らないようにガイドする。
    開発の指針やベストプラクティス
    を提示することで、開発速度の向
    上、データ基盤チームの労力の省
    力化を目指す
    データ基盤チーム
    (ドキュメントの更新)
    個別相談
    ガイドラインでカバーしきれない個別具体な
    課題や相談事項等を、レクチャーする
    開発スピードを止めないこと、
    データ基盤チームのナレッジを蓄
    積し、ガイドラインに反映し形式
    知として公開する
    ● ドメインチーム
    ● データ基盤チーム
    Databricksの統合事例 - ①ポリシーとプロセスの明確化 / プロセス

    View Slide

  42. © KAKEHASHI Inc. 42
    データガバナンスが困難な理由 対応方針
    実施内容
    人 プロセス テクノロジー
    複雑な構成
    データが、複数の場所で分散さ
    れ管理され、複雑な構成で難易
    度が高い。
    ①ポリシーとプロセスの
    明確化
    ・データガバナンス担当
    ・ドメインチーム
    ・データメッシュに合わ
    せたポリシーとルールを
    策定し、ドメインチーム
    が運用
    ・レビューやガイドライ
    ン、相談会による支援
    ・ワークスペースの分離
    ・Infra as Code
    アクセス制御
    の煩雑さ
    データの連携先や、利用者が多
    岐にわたるため、アクセス制御
    が煩雑になりやすい。
    ②権限委譲と一元化され
    たアクセス制御
    ・データガバナンス担当
    ・データスチュワード、
    データオーナー
    データアクセスポリシー
    およびルールを策定し、
    データ共有と公開の権限
    を委譲し、ドメインチー
    ムが運用
    ・アクセス制御管理
    ・アクセス記録の監査
    ・データ要求と承認記録
    不安定な品質
    と理解が困難
    各ドメインでデータを管理するた
    め、データ品質を保証する仕組みが
    バラバラになりやすい。
    また、データが分散配置され、流通
    し共有されるので、データの所在、
    流通経路、内容の理解が困難であ
    る。
    ③製品の機能を利用した
    品質、メタデータの管理
    ・データガバナンス担当
    ・ドメインチーム
    データ品質のポリシーお
    よびルールを策定し、ド
    メインチームが運用
    ・データ品質管理
    ・データリネージ
    ・メタデータ管理
    再掲:データメッシュにおけるデータガバナンス
    データメッシュにおけるデータガバナンスは、人、プロセス、テクノロジーを組み
    合わせて実践する。

    View Slide

  43. © KAKEHASHI Inc. 43
    Unity CatalogでManaged TableとExternal Tableへの
    アクセスを一元管理
    Databricksの統合事例 - ②権限委譲とアクセス制御/監査
    ロールベースのアクセス制御(RBAC)で運用 + Unity Catalogで一元管理
    ロールベースアクセス制御
    リソースをレベル分けし、レベルに応じてグループ
    (ロール)からアクセス
    ※1 現在は、データ基盤担当が権限付与を行っている。
    Unity Catalogで一元管理
    Managed Table
    Unity Catalog
    External Table
    (S3等)
    MODIFY
    SELECT
    グループ 権限
    リソース
    操作
    データオーナー※1
    ユーザをグループに追加

    View Slide

  44. © KAKEHASHI Inc. 44
    再掲:データメッシュにおけるデータガバナンス
    データメッシュにおけるデータガバナンスは、人、プロセス、テクノロジーを組み
    合わせて実践する。
    データガバナンスが困難な理由 対応方針
    実施内容
    人 プロセス テクノロジー
    複雑な構成
    データが、複数の場所で分散さ
    れ管理され、複雑な構成で難易
    度が高い。
    ①ポリシーとプロセスの
    明確化
    ・データガバナンス担当
    ・ドメインチーム
    ・データメッシュに合わ
    せたポリシーとルールを
    策定し、ドメインチーム
    が運用
    ・レビューやガイドライ
    ン、相談会による支援
    ・ワークスペースの分離
    ・Infra as Code
    アクセス制御
    の煩雑さ
    データの連携先や、利用者が多
    岐にわたるため、アクセス制御
    が煩雑になりやすい。
    ②権限委譲と一元化され
    たアクセス制御
    ・データガバナンス担当
    ・データスチュワード、
    データオーナー
    データアクセスポリシー
    およびルールを策定し、
    データ共有と公開の権限
    を委譲し、ドメインチー
    ムが運用
    ・アクセス制御管理
    ・アクセス記録の監査
    ・データ要求と承認記録
    不安定な品質
    と理解が困難
    各ドメインでデータを管理するた
    め、データ品質を保証する仕組みが
    バラバラになりやすい。
    また、データが分散配置され、流通
    し共有されるので、データの所在、
    流通経路、内容の理解が困難であ
    る。
    ③製品の機能を利用した
    品質、メタデータの管理
    ・データガバナンス担当
    ・ドメインチーム
    データ品質のポリシーお
    よびルールを策定し、ド
    メインチームが運用
    ・データ品質管理
    ・データリネージ
    ・メタデータ管理

    View Slide

  45. © KAKEHASHI Inc. 45
    一定のルールで、データ品質をチェック。
    - Delta Live Table(DLT):DLTの機能で品質チェック
    - DLT以外のジョブ:Deltalakeテーブル、
    または、Deequでデータ品質をチェック
    Databricksの統合事例 - ③品質管理、メタデータ管理
    データの品質を担保するため、一定のルールでチェック、データ間連携を可視化
    データ品質管理 データリネージ
    データ間の関連性を可視化し、データの源泉を確認する。
    ブロンズ、シルバー、ゴールド間のデータを可視化。

    View Slide

  46. © KAKEHASHI Inc. 46
    Databricksの統合事例 - ③品質管理、メタデータ管理
    データを扱いやすいように、意味や使用方法などメタデータを整備
    メタデータ管理
    ビジネスメタデータとして、テーブルのコメントに、意味や
    使用方法を記載する。

    View Slide

  47. © KAKEHASHI Inc.
    目次
    1. カケハシの事業とプロダクトのご紹介
    2. データメッシュ化の背景とDatabricksの導入
    3. データメッシュにおけるデータガバナンス
    4. データガバナンスとDatabricksの統合事例
    5. 今後の展望

    View Slide

  48. © KAKEHASHI Inc. 48
    ● 中央集権型のデータ基盤で運用しているETLの移行を支援
    - 技術支援
    - ガイドライン整備
    ● データガバナンスの強化
    - データ品質のポリシーの見直し
    - メタデータのガイドライン策定
    - Unity Catalogのタグ付ルール方針策定
    ● MLFlowの実装支援
    - データサイエンス/MLチームの支援
    今後の展望
    データメッシュや、Databricksを利用開始してから1年弱(約10ヶ月)が経過し、
    基礎的な仕組みは出来た。
    今後は下記の取り組みを進め、データ利活用を通して患者様の医療体験の向上を目
    指します。

    View Slide

  49. View Slide