Databricks登壇資料_aws_startup

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Copyright © KAKEHASHI Inc. All Rights Reserved. 松田健司 @ken_3ba 経歴 2014年、新卒でヤフー株式会社に入社。広告配信のための DMP開発に従事。 2016年、株式会社カケハシに 6人目のメンバーとして入社。薬歴システム「Musubi」の開発をした後に、開発ディレクターとしてチーム改善に従事。 2019年、薬局経営ダッシュボード「 Musubi Insight」のチームを立ち上げる。 2022年、全社横断のデータ基盤チームを立ち上げ、 7月にDatabricksの導入。

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Copyright © KAKEHASHI Inc. All Rights Reserved. 2016年 2017年 2018年 2019年 2020年 Musubi 正式リリースシード資金調達創業プレSeries A調達 Series A調達 Series B調達 9 億 0.7 億 1.6 億 26 億 2  6  6  8  12  15  19  28  36  44  65  79  84  88  18 億 Extension 調達 9 96  105  ✔ 創業6年 ✔ 累計131億円の資金調達 ✔ 社員数314人（2023年1月時点） 2021年 114  126  126  130  153  314 180  192  2022年 214  * 2022年10月時点 241  264  これまでのカケハシの歩み

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Copyright © KAKEHASHI Inc. All Rights Reserved. 2019~2021 社内でのデータ活用は順調に進んだ ● 社内データ分析、可視化のケース ○ プロジェクト管理、KPI、NSMの計測 ○ ヘルススコアの導出 ○ システムのSLA、SLO監視 ○ 人事採用進捗、実績の可視化 ● プロダクトでの利用ケース ○ 機械学習 ○ 事業の実証結果分析 ○ BIレポーティングカケハシデータ基盤の歩み

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Copyright © KAKEHASHI Inc. All Rights Reserved. 顕在化した課題 ● 解消し切れていないデータサイロ ○ Redash上でのデータソースを横断したデータのJOINが困難 ○ SQLの複雑化、クエリ性能の限界 ● データ基盤チームの開発速度と利用側の期待値の乖離 ○ エンジニア不足による開発速度低下、溜まり続ける開発依頼チケット ○ 基盤チーム側のドメイン知識の不足 ○ 開発時のコミュニケーションコストの増大

Slide 15

Slide 15 text

Copyright © KAKEHASHI Inc. All Rights Reserved. ● 解消し切れていないデータサイロ ○ Redash上でのデータソースを横断したデータのJOINが困難 ○ SQLの複雑化、クエリ性能の限界 ● データ基盤チームの開発速度と利用側の期待値の乖離 ○ エンジニア不足による開発速度低下、溜まり続ける開発依頼チケット ○ 基盤チーム側のドメイン知識の不足 ○ 開発時のコミュニケーションコストの増大顕在化した課題技術課題：データサイロ運用組織課題：中央集権的組織構造の限界

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Copyright © KAKEHASHI Inc. All Rights Reserved. 中央集権的組織構造の改善のためのアプローチ ● 初期のデータ基盤立ち上げフェーズで中央集権的組織構造になるのは自然な流れではある ● 一方で急速に進む会社事業の拡大に合わせて増加するデータ活用ニーズに合わせて社内のデータ基盤運用組織の拡張性も確保する必要があるデータメッシュの原則を参考にし、ビジネスドメインを境界とした分散オーナーシップ型データ基盤運用組織を目指す

Slide 21

Slide 21 text

Copyright © KAKEHASHI Inc. All Rights Reserved. ● データメッシュとは ○ データ基盤における中央集権的組織構造の拡張性等の課題解消のために近年登場した概念 ● データメッシュの4つの原則 ○ Domain Ownership ■ データに対して最も専門性を持つドメインチームが、データの開発オーナーシップを持つ ○ Data as a product ■ データもプロダクトとして管理し、ドメインの内外にいるデータ利用者に高品質のデータを提供できるようにする ○ Self-serve data platform ■ 各ドメインのデータプロダクトの開発に集中するためのデータインフラが必要 ○ Federated computational governance ■ ドメインと中央組織の間で責任範囲を分担したガバナンスの仕組みが必要中央集権的組織構造の改善のためのアプローチ

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Copyright © KAKEHASHI Inc. All Rights Reserved. 中央集権的組織構造の改善のためのアプローチ ● 分散オーナーシップ型の組織で期待すること ○ データ基盤の運用組織としての拡張性を確保 ○ 最も専門性を有するドメインチームが開発を担うことで、利用者に向けてより質の高いソリューションを提供 ○ DataOpsの加速 ■ データ関連の開発がドメインチームで完結するため、データの収集〜分析〜得られた洞察をビジネスに活かすまでの一連のサイクルを高速に回すためのシステムと組織の構造を実現

Slide 24

Slide 24 text

Copyright © KAKEHASHI Inc. All Rights Reserved. 中央集権的組織構造の改善のためのアプローチ ● システムアーキテクチャを最適化する上でも有効 ○ ドメインを境界にすることでコンウェイの法則がシステムアーキテクチャに対して良い方向に作用する ○ データ品質の本質的な向上施策はデータの最上流からの改善が必要 ■ Garbage In, Garbage Out ■ データパイプライン上でオーナーシップが分断されている場合、チーム間のコミュニケーションコスト、パワーバランス、開発優先度調整等が絡んでくる

Slide 25

Slide 25 text

Copyright © KAKEHASHI Inc. All Rights Reserved. 中央集権的組織構造の改善のためのアプローチ ● カケハシの組織構造とも相性良い ○ 事業ドメイン毎にサービス開発のチームが分割され自走する構造 ○ 各チーム内にエンジニア、データサイエンティスト、 PdM、PMM、ドメインエキスパート等、サービスを開発、運用する上で必要なロールのメンバーが所属 ○ データ活用も開発チームに閉じたユースケースが多く、一部では既に実質的にオーナーシップを渡している部分もある

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Copyright © KAKEHASHI Inc. All Rights Reserved. Databricks採用の決め手、期待したこと要約するとDatabricksのアーキテクチャコンセプトがカケハシの要件に合致していた決め手となった点は： ● データレイクハウスアーキテクチャのメリット ● 強固なデータエンジニアリング組織の実現 ● 横断的なデータマネジメントを技術面でサポート ● 分散オーナーシップ型組織の実現をサポート

Slide 29

Slide 29 text

Copyright © KAKEHASHI Inc. All Rights Reserved. ● データレイク〜ウェアハウスまで共通したデータストア・クエリエンジン ● ファイルベースの基盤でSpark Read, Writeを繋げるシンプルなデータフロー ● 未連携のRawデータへのアクセスが容易データレイクハウスアーキテクチャのメリットデータ基盤のアーキテクチャが非常にシンプルになり、開発コストや運用コストが削減可能

Slide 30

Slide 30 text

Copyright © KAKEHASHI Inc. All Rights Reserved. ● Databricksの標準機能でデータ基盤を構築可能 ○ ETL処理, ワークフローエンジン , BI, 機械学習に至るまでの要素をオールインワンで提供しているため、基本的に標準機能でデータ基盤を構築可能 ○ 自前で各種サービスを組み合わせるケースも減らせるデータレイクハウスアーキテクチャのメリットデータ基盤構築例）

Slide 31

Slide 31 text

Copyright © KAKEHASHI Inc. All Rights Reserved. ● 組織内のスキルを標準化 ○ Apache Spark, Delta Lake, MLflow等のOSSベースの機能を会社のデータエンジニアリング、機械学習における標準技術に強固なデータエンジニアリング組織の実現 ● データエンジニアリングの知見の蓄積・共有による生産性の向上に繋がる ○ 概念レベルでのデータエンジニアリングの知見を全社横断的に共有可能 ○ チームを越境したデータエンジニアリソースの流動性を確保 ○ 既存人材のデータ領域への進出のための教育コストを削減

Slide 32

Slide 32 text

Copyright © KAKEHASHI Inc. All Rights Reserved. ● オープンな仕様 ○ 個人のスキルセットのベンダロックイン回避 ○ 組織の開発資産、データのベンダロックイン回避 ○ Python、Scalaを操るエンジニアも広くデータエンジニアリングへ招待 ○ 採用市場の人材への訴求効果 ● 豊富な言語選択肢 ○ Notebookの言語をPython, Scala, R, SQLから選択可能 ○ 多様なバックグラウンドを持つメンバーが得意な言語で実装可能強固なデータエンジニアリング組織の実現

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Copyright © KAKEHASHI Inc. All Rights Reserved. 横断的なデータマネジメントをサポート ● 横断的なデータマネジメントの施策が実施可能 ○ データ基盤がDatabricks上でほぼ完結でき、メタデータ情報の捕捉範囲の網羅性が高くなる ○ メタデータの情報は網羅性が重要になってくるが、捕捉対象が限定的であったり収集先の対象が増えるとその分ガバナンスコストが膨れ上がる各種マネジメント、監視が必要これらの全てのデータ、処理、操作がマネジメント対象になり得る

Slide 35

Slide 35 text

Copyright © KAKEHASHI Inc. All Rights Reserved. 横断的なデータマネジメントをサポート ● 標準機能の充実 ○ データカタログ機能や、 Unity Catalogによるデータリネージュの自動収集、統合的なデータアクセス権限管理の機能は基盤チームの負荷を軽減 ○ 開発リソースが潤沢であれば自作したり OSSツールを別途導入するという選択肢もありだが、状況的に厳しいデータリネージュ例

Slide 36

Slide 36 text

Copyright © KAKEHASHI Inc. All Rights Reserved. 分散オーナーシップ型の組織をサポート ● Workspace環境の分離 ○ 個別の開発ドメインチーム単位で環境を分離可能 ○ ETL環境を各自のAWSアカウント上にホストし、責任分界点を明確にして自走する環境を提供可能 ○ Domain Ownership, Data as a product, Self-serve data platformの面を支援 ● Unity Catalogでのデータ共有、アクセス権限の管理 ○ 分散したWorkspace間のデータを統合したデータストアとして会社全体で共有できる ○ 個別に環境は分離しているが、データストアに対しては横串でのアカウントの権限の管理が可能 ○ データ基盤チームによるガバナンスコストを削減 ○ Federated computational governanceの面を支援

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Copyright © KAKEHASHI Inc. All Rights Reserved. 分散オーナーシップ型の組織をサポート分散オーナーシップ型のシステムアーキテクチャイメージ図データメッシュ原則 - Domain Ownership - Data as a product - Self-serve data platform - データメッシュ原則 - Federated computational governance

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Copyright © KAKEHASHI Inc. All Rights Reserved. ● データエンジニアの開発効率向上 ○ データパイプラインの開発体験向上 ○ アカウント発行~権限付与のDevOpsの自動化 ○ データアクセス権限の一元管理 ● データ・AIの民主化の加速 ○ データサイエンティストによる探索的データ分析作業の効率向上 ○ データアナリストによる ETL処理の実装 ● ガバナンスの強化 ○ データオブジェクトの権限管理 ● 組織内での知見共有 ○ コードベースのモノレポ化の実現 ○ 既存設計パターンを他チームでも活用 Databricks導入により得られた効果

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Copyright © KAKEHASHI Inc. All Rights Reserved. ● 分散オーナーシップ組織化を漸進的に進める ○ チーム間の責任分界点を明確化 ○ 各チーム内で必要なロールの明確化、ロールチェンジ、採用計画への反映等 ○ Workspace環境を適切な範囲に分離 ■ ※当面はモノリシックな環境で運用予定 ● データ基盤チームは横断的なデータマネジメントに注力 ○ データ基盤全体向けのガイドラインやポリシーの制定、ドメインチームの開発支援活動に徐々にシフト ○ 法務、SRE、情シス等の横断的チームとも協力する体制を構築しガバナンスを強化 ○ データ利用者向けのデータ活用の手助け、文化の醸成の活動にも注力今後のアーキテクチャ、組織設計の構想

Slide 43

Slide 43 text

Slide 44

Slide 44 text