Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

© KAKEHASHI Inc. 目次

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

© 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億円調達

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

© KAKEHASHI Inc. 25 セルフサービス型データ基盤 カケハシのデータメッシュアーキテクチャ データメッシュアーキテクチャの4つの原則に照らし合わせる データガバナンス担当 ドメインチーム 中央組織(データ基盤チーム) 原則3 セルフサービス 型データ基盤 原則1 ドメイン オーナーシッ プ 原則4 横断的なデータ ガバナンス データガバナンス機能 原則4 連合型ガバナン ス データ提供(Data Producer) データ利用(Data Consumer) データ利用者 加工 加工 加工 加工 原則2 プロダクトとしてのデータ

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

© 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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

© 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 ユーザをグループに追加

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

No content