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

Transcript

1. Copyright © KAKEHASHI Inc. All Rights Reserved. データガバナンスの視点から見たデータメッシュアーキテクチャ 株式会社 カケハシ 東 浩稔
2. © KAKEHASHI Inc. 2 株式会社カケハシ データ基盤 プロダクトマネージャー 東 浩稔（あずま ひろとし） 大手金融機関系列のシステムインテグレーター、ヤ フー株式会社、アマゾンウェブサービスジャパン合同 会社を経て 2023年7月に株式会社カケハシにジョイ ン。 データ基盤のプロダクトマネージャーとして全社の データ活用やデータガバナンスを推進。 自己紹介 写真
3. © KAKEHASHI Inc. 目次 1. カケハシの事業とプロダクトのご紹介 2. データメッシュ化の背景とDatabricksの導入 3. データメッシュにおけるデータガバナンス 4. データガバナンスとDatabricksの統合事例 5. 今後の展望
4. © KAKEHASHI Inc. 目次 1. カケハシの事業とプロダクトのご紹介 2. データメッシュ化の背景とDatabricksの導入 3. データメッシュにおけるデータガバナンス 4. データガバナンスとDatabricksの統合事例 5. 今後の展望
5. © KAKEHASHI Inc. 目次
6. Vision 明日の医療の基盤となるエコシステムの実現。
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億円調達
8. © KAKEHASHI Inc. プロダクトのご紹介 - Musubi
9. © KAKEHASHI Inc. プロダクトのご紹介 - Musubi Insight
10. © KAKEHASHI Inc. プロダクトのご紹介 - Musubi Insight
11. © KAKEHASHI Inc. プロダクトのご紹介 - Musubi Insight
12. © KAKEHASHI Inc. 事業内容 薬局DXを推進し、医療体験の向上を支援するサービスラインナップ
13. © KAKEHASHI Inc. 目次 1. カケハシの事業とプロダクトのご紹介 2. データメッシュ化の背景とDatabricksの導入 3. データメッシュにおけるデータガバナンス 4. データガバナンスとDatabricksの統合事例 5. 今後の展望
14. © KAKEHASHI Inc. 14 カケハシのデータ基盤は、2022年10月にアーキテクチャが変わる カケハシのデータ基盤の変遷 2019年〜2022年9月 データレイクアーキテクチャ 2022年10月〜 データメッシュアーキテクチャ 提供元 利用者 提供元 提供元 利用者 利用者 提供元 利用者 提供元 提供元 利用者 利用者
15. © KAKEHASHI Inc. 15 2019年〜2022年のカケハシのデータ基盤 2019年に、データに基づいた意思決定で各プロダクトの改善を行い、お客様に高い 付加価値を届けるために、データ基盤と担当するチームが設立される 2019年〜2022年のデータ基盤アーキテクチャ
16. © KAKEHASHI Inc. 16 2019年〜2022年のカケハシのデータ基盤 データ基盤を構築後、社内のデータ活用は順調に進む 主な活用例 • 社内データ分析、可視化のケース ◦ プロジェクト管理、KPI、NSMの計測 ◦ ヘルススコアの導出 ◦ システムのSLA、SLO監視 ◦ 人事採用進捗、実績の可視化 • プロダクトでの利用ケース ◦ 機械学習 ◦ 事業の実証結果分析 ◦ BIレポーティング
17. © KAKEHASHI Inc. 17 2019年〜2022年のカケハシのデータ基盤 運用開始後、徐々に課題が顕在化 顕在化した課題 • 中央組織であるデータ基盤チームがボトルネックになり、利活用 までのリードタイムが延びる
18. © KAKEHASHI Inc. 18 2019年〜2022年のカケハシのデータ基盤 運用開始後、徐々に課題が顕在化→ドメインチームからの依頼が増えはじめたこと が要因 顕在化した課題 • 中央組織であるデータ基盤チームがボトルネックになり、利活用 までのリードタイムが延びる 要因 • ドメインチームからのデータ作成依頼の増加 • 各プロダクトの新しいチャレンジや、改善サイクルの短縮化
19. © KAKEHASHI Inc. 19 構造的な問題 • 複数のドメインチームに対して、1つのデータ基盤チームという 関係性（N:1の関係） • コミュニケーションコストの高さ ◦ ドメインチームの専門的なデータエンジニアリングの知識不足 ◦ 基盤チームのドメイン知識不足 2019年〜2022年のカケハシのデータ基盤 運用開始後、徐々に課題が顕在化→ 構造的な課題は中央集権のアーキテクチャと組 織と特定。 顕在化した課題 • 中央組織であるデータ基盤チームがボトルネックになり、利活用 までのリードタイムが延びる 要因 • ドメインチームからのデータ作成依頼の増加 • 各プロダクトの新しいチャレンジや、改善サイクルの短縮化
20. © KAKEHASHI Inc. 20 解決手段 • データエンジニアの専門スキルをドメインチームへ展開 • 中央集権型のアーキテクチャから分散型アーキテクチャへの移行 (再掲)構造的な問題 • 複数のドメインチームに対して、1つのデータ基盤チームという関係性 • コミュニケーションコストの高さ ◦ ドメインチームの専門的なデータエンジニアリングの知識不足 ◦ 基盤チームのドメイン知識不足 考察 • データ基盤チームの人員を増やすことで対応力を向上させる方法も考えられたが、当社は患者様、薬局様を 中心に、複数プロダクトでご支援するエコスシステムを構築していくため、今後もプロダクトが増えること は予想される。将来的に同様の問題が発生すると見込まれ現実的ではない。 • 受発注の関係性ではなく、負荷を平準化する方が全体最適につながる。 中央管理のデータ基盤から、分散管理のデータ基盤へ
21. © KAKEHASHI Inc. 21 データメッシュとは 「複雑かつ大規模な環境において、組織内または組織横断的に分析データを共有、 アクセス、管理するための新しい分散型アプローチ」※ 分散型アーキテクチャであるデータメッシュとは？ 分散型アーキテクチャであるデータメッシュの導入 ※出典 オライリー Data Mesh
22. © KAKEHASHI Inc. 22 複数のプロダクトを展開する当社と照らし合わせた結果、柔軟性、拡張性、迅速さに優位性がある分散型を採用 中央集権型と分散型アーキテクチャの比較 中央集権型（データレイク） 分散型（データメッシュ） 概要 データの形式問わず一元化されたデータリポジトリに保存し、一つ の中央チームが加工・集計することが多い。 分散された各事業や組織が主体となり信頼できるデータを作成し相 互に連携する。ルールやガバナンスは中央組織で行う。 イメージ 柔軟性/拡張性/迅 速さ 中央組織が各組織と調整する。中央組織がボトルネックになりがち である。受発注関係になり優先度等の理由で迅速さに欠ける。 各組織間で自律して動き、変更に対して柔軟性がある。 基本的には2つの組織間の調整になるため、迅速である。 アーキテクチャの 複雑さ 一元化されたアーキテクチャのためシンプル 各組織間のパス毎にデータ連携が必要になるため複雑 ガバナンス 一元化されたデータリポジトリと中央組織のため、統制の難易度は 低い 分散化されたデータリポジトリと、各組織でデータを管理するため統 制の難易度が高い 提供元 利用者 提供元 提供元 利用者 利用者 提供元 利用者 提供元 提供元 利用者 利用者
23. © KAKEHASHI Inc. 23 カケハシのデータメッシュアーキテクチャ（論理アーキテクチャ） カケハシのデータメッシュアーキテクチャ データガバナンス担当 ドメインチーム 中央組織（データ基盤チーム） データ利用者 データ提供（Data Producer） データ利用（Data Consumer） 加工 加工 加工 加工
24. © KAKEHASHI Inc. 24 データメッシュには4つの原則がある データメッシュ4つの原則 原則 概要 目的 1 ドメインオーナー シップ データの所有権を、データ に最も近いビジネスドメイ ンに分散 • 組織の成長に合わせて、スケールアウト可能 • ドメインオーナーと利用者間のコミュニケーション改善 2 プロダクトとしての データ データをプロダクトとして 扱い、利用者と直接共有 • データはチームが共有するプロダクトになり、データサイ ロを防ぐ（従来の中央集権のように、別のシステムで収集 して加工することがない。） • 境界を明確にすることで、変更に対する影響を最小化 3 セルフサービス型 データ基盤 ドメインチームがデータを 共有できるようにするセル フサービス型のデータプ ラットフォームサービス • データの分散所有にかかる総コストを削減 • データ管理の複雑さを抽象化し、ドメインチームの負荷を 軽減 4 連合型ガバナンス 各専門家でチームを構成し データガバナンスモデルを 構築します • 分散データ製品のメッシュ全体に、セキュリティ、プライ バシー、法令順守などの横断的なガバナンス要件を組み込 む
25. © KAKEHASHI Inc. 25 セルフサービス型データ基盤 カケハシのデータメッシュアーキテクチャ データメッシュアーキテクチャの4つの原則に照らし合わせる データガバナンス担当 ドメインチーム 中央組織（データ基盤チーム） 原則3 セルフサービス 型データ基盤 原則１ ドメイン オーナーシッ プ 原則4 横断的なデータ ガバナンス データガバナンス機能 原則4 連合型ガバナン ス データ提供（Data Producer） データ利用（Data Consumer） データ利用者 加工 加工 加工 加工 原則2 プロダクトとしてのデータ
26. © KAKEHASHI Inc. 26 セルフサービス型データ基盤 データ提供（Data Producer） データ利用（Data Consumer） データ利用者 加工 加工 加工 加工 カケハシのデータメッシュアーキテクチャ 原則3:セルフサービス型データ基盤の検討 データガバナンス担当 ドメインチーム 中央組織（データ基盤チーム） 原則3 セルフサービス 型データ基盤
27. © KAKEHASHI Inc. 27 分散型アーキテクチャは複雑になりやすい → 新しいデータ基盤製品の検討が必要 【再掲】：中央集権型と分散型アーキテクチャの比較 中央集権型（データレイク） 分散型（データメッシュ） 概要 データの形式問わず一元化されたデータリポジトリに保存し、一つ の中央チームが加工・集計することが多い。 分散された各事業や組織が主体となり信頼できるデータを作成し相 互に連携する。ルールやガバナンスは中央組織で行う。 イメージ 柔軟性/拡張性/迅 速さ 中央組織が各組織と調整する。中央組織がボトルネックになりがち である。受発注関係になり優先度等の理由で迅速さに欠ける。 各組織間で自律して動き、変更に対して柔軟性がある。 基本的には2つの組織間の調整になるため、迅速である。 アーキテクチャの 複雑さ 一元化されたアーキテクチャのためシンプル 各組織間のパス毎にデータ連携が必要になるため複雑 ガバナンス 一元化されたデータリポジトリと中央組織のため、統制の難易度は 低い 分散化されたデータリポジトリと、各組織でデータを管理するため統 制の難易度が高い 提供元 利用者 提供元 提供元 利用者 利用者 提供元 利用者 提供元 提供元 利用者 利用者
28. © KAKEHASHI Inc. 28 データメッシュとDatabricks 現状 • 今日のデータ基盤は、データレイク、データ ウェアハウス、データマートで構成すること が多い。 • また、それぞれを別のサービスや製品で組 み合わせる事が多い。（得手不得手がある ため最適なデータベースを選択するのは正 しい。) セルフサービス型データ基盤製品の選定の要件 ドメインオーナーシップを実践するにあたり、可能な限りデータエンジニアリングの専門性を下げることが必要 考察 • データベース製品を組み合わせて使うこと で、それぞれスキル獲得が必要になり高い 専門性が要求される。 • データベース製品間のデータを同様の状態 に保つ運用コストは大きく、データ移動のた めのELTも複雑になる傾向がある。 • データベース製品を分けずに統一プラット フォームを検討する。 結論 • Databricksのレイクハウスプラットフォーム は単一プラットフォーム上で、データレイク、 データウェアハウスを統合して管理が可能。 • レイクハウスによりデータのサイロを防ぎ、 運用コストを下げる • ETL、ストレージ、処理、ガバナンス、 AI、BI 等が同一プラットフォームで利用可能 アーキテクチャ選定の根拠 データ製品やデータ自体のサイロ化を減らせる点、獲得するスキルを最小限に抑えることができる点、様々なワークロー ドを同一プラットフォーム上で実装できる点から、Databricksのレイクハウスプラットフォームを選定。
29. © KAKEHASHI Inc. 29 カケハシのデータメッシュアーキテクチャ カケハシのデータメッシュアーキテクチャ（物理アーキテクチャ） ドメインチームアカウント Workspace ドメインチームアカウント Workspace ドメインチームアカウント Workspace ドメインチームアカウント Workspace データ基盤アカウント Unity Catalog 下記を管理 ・各ドメインのデータ ・Workspace ・コスト データ提供（Data Producer） データ利用（Data Consumer） データガバナンス
30. © KAKEHASHI Inc. 目次 1. カケハシの事業とプロダクトのご紹介 2. データメッシュ化の背景とDatabricksの導入 3. データメッシュにおけるデータガバナンス 4. データガバナンスとDatabricksの統合事例 5. 今後の展望
31. © KAKEHASHI Inc. 31 データガバナンス※とは？ 「データ資産の管理（マネジメント）に対して、職務権限を通して統制（コント ロール）する」 統制（コントロール）※とは？ 「計画を立て、実行を監視し、徹底させること」 データガバナンスの定義 ※ 出典：データマネジメント知識体系ガイド第二版 解釈すると 「データの品質、セキュリティ、プライバシー等を保証し、データを適切に管理す るためのプロセスやルールを定義、監視、改善すること」
32. © KAKEHASHI Inc. 32 データガバナンスの目的 データ品質の確保 - 正確なデータが良質な意思決定をサポートする セキュリティの強化とリスク軽減 - 適切なアクセス制御とセキュリティ対策で、データの漏洩や不正アクセス等のリスクを下げる 規制とプライバシーの対応 - データ保護の規制や業界基準に準拠し、個人情報、プライバシーを保護する枠組みを作る データ利活用の最大化 - データの適切な管理と整備により、効果的な分析や新しい洞察を引き出し、ビジネス価値を最大 化させる 信頼性と透明性の向上 - データの信頼性と透明性を上げることで、ステークホルダーとの信頼を築くことができる
33. © KAKEHASHI Inc. 33 分散型アーキテクチャのガバナンスは難易度が高い → 当社の取り組みをご紹介します 【再掲】：中央集権型と分散型アーキテクチャの比較 中央集権型（データレイク） 分散型（データメッシュ） 概要 データの形式問わず一元化されたデータリポジトリに保存し、一つ の中央チームが加工・集計することが多い。 分散された各事業や組織が主体となり信頼できるデータを作成し相 互に連携する。ルールやガバナンスは中央組織で行う。 イメージ 柔軟性/拡張性/迅 速さ 中央組織が各組織と調整する。中央組織がボトルネックになりがち である。受発注関係になり優先度等の理由で迅速さに欠ける。 各組織間で自律して動き、変更に対して柔軟性がある。 基本的には2つの組織間の調整になるため、迅速である。 アーキテクチャの 複雑さ 一元化されたアーキテクチャのためシンプル 各組織間のパス毎にデータ連携が必要になるため複雑 ガバナンス 一元化されたデータリポジトリと中央組織のため、統制の難易度は 低い 分散化されたデータリポジトリと、各組織でデータを管理するため統 制の難易度が高い 提供元 利用者 提供元 提供元 利用者 利用者 提供元 利用者 提供元 提供元 利用者 利用者
34. © KAKEHASHI Inc. 34 データが、複数の場所で分散配 置されるため、複雑な構成にな りやすく難易度が高い。 データメッシュにおけるデータガバナンス 分散型アーキテクチャでデータガバナンスが困難な理由 複雑な構成 アクセス制御の煩雑さ 不安定な品質と理解が困難 アプリ データの連携先や、利用者が多 岐にわたるため、アクセス制御 が煩雑になりやすい。 各ドメインでデータを管理する ため、データ品質を保証する仕 組みがバラバラになりやすい。 また、データが分散配置され、 流通し共有されるので、データ の所在、流通経路、内容の理解 が困難である。
35. © KAKEHASHI Inc. 35 データメッシュにおけるデータガバナンスの対応方針 データメッシュにおけるデータガバナンスは、下記のとおり人、プロセス、テクノ ロジーを組み合わせて実践する。 データガバナンスが困難な理由 対応方針 実施内容 人 プロセス テクノロジー 複雑な構成 データが、複数の場所で分散さ れ管理され、複雑な構成で難易 度が高い。 ①ポリシーとプロセスの 明確化 ・データガバナンス担当 ・ドメインチーム ・データメッシュに合わ せたポリシーとルールを 策定し、ドメインチーム が運用 ・レビューやガイドライ ン、相談会による支援 ・ワークスペースの分離 ・Infra as Code アクセス制御 の煩雑さ データの連携先や、利用者が多 岐にわたるため、アクセス制御 が煩雑になりやすい。 ②権限委譲と一元化され たアクセス制御 ・データガバナンス担当 ・データスチュワード、 データオーナー データアクセスポリシー およびルールを策定し、 データ共有と公開の権限 を委譲し、ドメインチー ムが運用 ・アクセス制御管理 ・アクセス記録の監査 ・データ要求と承認記録 不安定な品質 と理解が困難 各ドメインでデータを管理するた め、データ品質を保証する仕組みが バラバラになりやすい。 また、データが分散配置され、流通 し共有されるので、データの所在、 流通経路、内容の理解が困難であ る。 ③製品の機能を利用した 品質、メタデータの管理 ・データガバナンス担当 ・ドメインチーム データ品質のポリシーお よびルールを策定し、ド メインチームが運用 ・データ品質管理 ・データリネージ ・メタデータ管理
36. © KAKEHASHI Inc. 目次 1. カケハシの事業とプロダクトのご紹介 2. データメッシュ化の背景とDatabricksの導入 3. データメッシュにおけるデータガバナンス 4. データガバナンスとDatabricksの統合事例 5. 今後の展望
37. © KAKEHASHI Inc. 37 データ提供（Data Producer） データ利用（Data Consumer） データ利用者 加工 加工 加工 加工 原則4:横断的なデータガバナンスを実現する事例のご紹介 カケハシのデータメッシュアーキテクチャ データガバナンス担当 ドメインチーム 中央組織（データ基盤チーム） 原則4 横断的なデータ ガバナンス データガバナンス機能 原則4 連合型データガ バナンス
38. © KAKEHASHI Inc. 38 再掲：データメッシュにおけるデータガバナンス データガバナンスが困難な理由 対応方針 実施内容 人 プロセス テクノロジー 複雑な構成 データが、複数の場所で分散さ れ管理され、複雑な構成で難易 度が高い。 ①ポリシーとプロセスの 明確化 ・データガバナンス担当 ・ドメインチーム ・データメッシュに合わ せたポリシーとルールを 策定し、ドメインチーム が運用 ・レビューやガイドライ ン、相談会による支援 ・ワークスペースの分離 ・Infra as Code アクセス制御 の煩雑さ データの連携先や、利用者が多 岐にわたるため、アクセス制御 が煩雑になりやすい。 ②権限委譲と一元化され たアクセス制御 ・データガバナンス担当 ・データスチュワード、 データオーナー データアクセスポリシー およびルールを策定し、 データ共有と公開の権限 を委譲し、ドメインチー ムが運用 ・アクセス制御管理 ・アクセス記録の監査 ・データ要求と承認記録 不安定な品質 と理解が困難 各ドメインでデータを管理するた め、データ品質を保証する仕組みが バラバラになりやすい。 また、データが分散配置され、流通 し共有されるので、データの所在、 流通経路、内容の理解が困難であ る。 ③製品の機能を利用した 品質、メタデータの管理 ・データガバナンス担当 ・ドメインチーム データ品質のポリシーお よびルールを策定し、ド メインチームが運用 ・データ品質管理 ・データリネージ ・メタデータ管理 データメッシュにおけるデータガバナンスは、人、プロセス、テクノロジーを組み 合わせて実践する。
39. © KAKEHASHI Inc. 39 Databricksの統合事例 - ①ポリシーとプロセスの明確化 / テクノロジー メダリオンアーキテクチャ※1 メダリオンアーキテクチャを元に、ワークスペースを分離し各ドメインの境界を明確にする レイクハウスのデータを論理的に整理するために用いられ る。当社ではSilverを提供側と利用の境界線として定義 データ提供者 公開 Raw データ利用者 目的別 目的別 ワークスペースの分離 Domain Account1 Domain Account2 ドメイン単位にワークスペース（AWSアカウント）を分けて 管理 ※1 出典：メダリオンアーキテクチャ Workspace Workspace データ基盤アカウント Unity Catalog 各ドメイン間で 共有するデータ は公開
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
41. © KAKEHASHI Inc. 41 レビュー、ガイドライン、個別相談等の取り組みによりドメインチームを支援 支援形態 概要 目的 参加者 アーキテクチャー レビュー プロダクト横断のデータ連携、および接続の 際には、接続方式（バッチ/ストリーム/API 等）の妥当性を確認、および一貫性を保つた めに、中央組織※1によるレビューを実施し、 大まかな設計の方向性を示す。 プロダクト横断の連携方式の妥当 性、一貫性を保ち、全社視点で技 術負債を抱えないこと。 ※なお、API接続等では、 Databricksを使用しない場合もあ りえる。 レビューイー • ドメインチーム レビューアー • プラットフォームチーム • データ基盤チーム ガイドラインの提示 Databricksでの設計、開発のポイント、実装 方法、その他注意点等を提示し、ドメイン チームが困らないようにガイドする。 開発の指針やベストプラクティス を提示することで、開発速度の向 上、データ基盤チームの労力の省 力化を目指す データ基盤チーム （ドキュメントの更新） 個別相談 ガイドラインでカバーしきれない個別具体な 課題や相談事項等を、レクチャーする 開発スピードを止めないこと、 データ基盤チームのナレッジを蓄 積し、ガイドラインに反映し形式 知として公開する • ドメインチーム • データ基盤チーム Databricksの統合事例 - ①ポリシーとプロセスの明確化 / プロセス
42. © KAKEHASHI Inc. 42 データガバナンスが困難な理由 対応方針 実施内容 人 プロセス テクノロジー 複雑な構成 データが、複数の場所で分散さ れ管理され、複雑な構成で難易 度が高い。 ①ポリシーとプロセスの 明確化 ・データガバナンス担当 ・ドメインチーム ・データメッシュに合わ せたポリシーとルールを 策定し、ドメインチーム が運用 ・レビューやガイドライ ン、相談会による支援 ・ワークスペースの分離 ・Infra as Code アクセス制御 の煩雑さ データの連携先や、利用者が多 岐にわたるため、アクセス制御 が煩雑になりやすい。 ②権限委譲と一元化され たアクセス制御 ・データガバナンス担当 ・データスチュワード、 データオーナー データアクセスポリシー およびルールを策定し、 データ共有と公開の権限 を委譲し、ドメインチー ムが運用 ・アクセス制御管理 ・アクセス記録の監査 ・データ要求と承認記録 不安定な品質 と理解が困難 各ドメインでデータを管理するた め、データ品質を保証する仕組みが バラバラになりやすい。 また、データが分散配置され、流通 し共有されるので、データの所在、 流通経路、内容の理解が困難であ る。 ③製品の機能を利用した 品質、メタデータの管理 ・データガバナンス担当 ・ドメインチーム データ品質のポリシーお よびルールを策定し、ド メインチームが運用 ・データ品質管理 ・データリネージ ・メタデータ管理 再掲：データメッシュにおけるデータガバナンス データメッシュにおけるデータガバナンスは、人、プロセス、テクノロジーを組み 合わせて実践する。
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 ユーザをグループに追加
44. © KAKEHASHI Inc. 44 再掲：データメッシュにおけるデータガバナンス データメッシュにおけるデータガバナンスは、人、プロセス、テクノロジーを組み 合わせて実践する。 データガバナンスが困難な理由 対応方針 実施内容 人 プロセス テクノロジー 複雑な構成 データが、複数の場所で分散さ れ管理され、複雑な構成で難易 度が高い。 ①ポリシーとプロセスの 明確化 ・データガバナンス担当 ・ドメインチーム ・データメッシュに合わ せたポリシーとルールを 策定し、ドメインチーム が運用 ・レビューやガイドライ ン、相談会による支援 ・ワークスペースの分離 ・Infra as Code アクセス制御 の煩雑さ データの連携先や、利用者が多 岐にわたるため、アクセス制御 が煩雑になりやすい。 ②権限委譲と一元化され たアクセス制御 ・データガバナンス担当 ・データスチュワード、 データオーナー データアクセスポリシー およびルールを策定し、 データ共有と公開の権限 を委譲し、ドメインチー ムが運用 ・アクセス制御管理 ・アクセス記録の監査 ・データ要求と承認記録 不安定な品質 と理解が困難 各ドメインでデータを管理するた め、データ品質を保証する仕組みが バラバラになりやすい。 また、データが分散配置され、流通 し共有されるので、データの所在、 流通経路、内容の理解が困難であ る。 ③製品の機能を利用した 品質、メタデータの管理 ・データガバナンス担当 ・ドメインチーム データ品質のポリシーお よびルールを策定し、ド メインチームが運用 ・データ品質管理 ・データリネージ ・メタデータ管理
45. © KAKEHASHI Inc. 45 一定のルールで、データ品質をチェック。 - Delta Live Table(DLT)：DLTの機能で品質チェック - DLT以外のジョブ：Deltalakeテーブル、 または、Deequでデータ品質をチェック Databricksの統合事例 - ③品質管理、メタデータ管理 データの品質を担保するため、一定のルールでチェック、データ間連携を可視化 データ品質管理 データリネージ データ間の関連性を可視化し、データの源泉を確認する。 ブロンズ、シルバー、ゴールド間のデータを可視化。
46. © KAKEHASHI Inc. 46 Databricksの統合事例 - ③品質管理、メタデータ管理 データを扱いやすいように、意味や使用方法などメタデータを整備 メタデータ管理 ビジネスメタデータとして、テーブルのコメントに、意味や 使用方法を記載する。
47. © KAKEHASHI Inc. 目次 1. カケハシの事業とプロダクトのご紹介 2. データメッシュ化の背景とDatabricksの導入 3. データメッシュにおけるデータガバナンス 4. データガバナンスとDatabricksの統合事例 5. 今後の展望
48. © KAKEHASHI Inc. 48 • 中央集権型のデータ基盤で運用しているETLの移行を支援 - 技術支援 - ガイドライン整備 • データガバナンスの強化 - データ品質のポリシーの見直し - メタデータのガイドライン策定 - Unity Catalogのタグ付ルール方針策定 • MLFlowの実装支援 - データサイエンス/MLチームの支援 今後の展望 データメッシュや、Databricksを利用開始してから1年弱（約10ヶ月）が経過し、 基礎的な仕組みは出来た。 今後は下記の取り組みを進め、データ利活用を通して患者様の医療体験の向上を目 指します。