Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Data Meshと私
Search
JDSC
August 24, 2021
Technology
0
220
Data Meshと私
JDSCでの勉強会時のスライドです。
JDSC
August 24, 2021
Tweet
Share
More Decks by JDSC
See All by JDSC
JDSC採用ページⅡ
jdsc
0
3.6k
JDSC採用ページ
jdsc
1
75k
Kubeflowで作る共通データ基盤 (道半ば編)
jdsc
1
280
家電製品の異常検知 (Case Study)
jdsc
0
530
鉄道省エネに向けた車上データ活用事例の紹介
jdsc
0
750
InterpretMLと Explainable Boosting Machineのススメ
jdsc
1
2.8k
Google Cloud Build とAI Platformではじめる軽量MLOps pipelineとAlphaSQL
jdsc
0
480
JDSCの事業・技術
jdsc
0
18k
JDSCの人・カルチャー
jdsc
0
18k
Other Decks in Technology
See All in Technology
オブザーバビリティと育てた ID管理・認証認可基盤の歩み / The Journey of an ID Management, Authentication, and Authorization Platform Nurtured with Observability
kaminashi
1
1.1k
OTEPsで知るOpenTelemetryの未来 / Observability Conference Tokyo 2025
arthur1
0
310
Okta Identity Governanceで実現する最小権限の原則
demaecan
0
170
webpack依存からの脱却!快適フロントエンド開発をViteで実現する #vuefes
bengo4com
4
3.6k
AWSが好きすぎて、41歳でエンジニアになり、AAIを経由してAWSパートナー企業に入った話
yama3133
1
130
ラスベガスの歩き方 2025年版(re:Invent 事前勉強会)
junjikoide
0
470
IoTLT@ストラタシスジャパン_20251021
norioikedo
0
140
AI駆動で進める依存ライブラリ更新 ─ Vue プロジェクトの品質向上と開発スピード改善の実践録
sayn0
1
330
書籍『実践 Apache Iceberg』の歩き方
ishikawa_satoru
0
190
SOTA競争から人間を超える画像認識へ
shinya7y
0
600
ハノーファーメッセ2025で見た生成AI活用ユースケース.pdf
hamadakoji
1
500
Azure Well-Architected Framework入門
tomokusaba
1
140
Featured
See All Featured
Producing Creativity
orderedlist
PRO
347
40k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
36
6.1k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
127
54k
We Have a Design System, Now What?
morganepeng
53
7.8k
Optimizing for Happiness
mojombo
379
70k
Product Roadmaps are Hard
iamctodd
PRO
55
11k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
34
2.5k
Navigating Team Friction
lara
190
15k
Building Better People: How to give real-time feedback that sticks.
wjessup
369
20k
Mobile First: as difficult as doing things right
swwweet
225
10k
[RailsConf 2023] Rails as a piece of cake
palkan
57
5.9k
Build The Right Thing And Hit Your Dates
maggiecrowley
38
2.9k
Transcript
Data と Mesh と私 株式会社JDSC エンジニア 秋山 悟志
自己紹介 秋山 悟志 System Engineer(新卒)-> Web Application Engineer-> Data Scientist ->
Data Engineer(今ここ) SEとWAEの間にイラストレータとかもやっていました。
脳が溶けるようなデータパイプラインを設計することになっ た... - 週次運用 ×3(月曜と火曜水曜で処理違う)+日次運用のコンボ - 数理最適モジュール+UI表示モジュール+機械学習モジュール+顧 客側のデータ基盤をそれぞれ連携させる をAirflowといったワークフローエンジンで管理しちゃおう!
今はワンオペ体制なので逆に管理はできるけど.... (いやこれワンオペって...) - 人員や各モジュールをスケールした際に一元管理ってできるか? - BigQueryやらGCSやらで扱うデータモデルが無限に増えると思う。 lake->warehouse->martと いったアーキテクチャで管理できるか? - 複雑化、肥大化するほど、1元管理する人材の負担は計り知れなく増大するし、非効率
それぞれのモジュールは本当は性質が違うはず。 けど現在は Appと顧客データ基盤と私(弊データ基盤) というドメインの切り方でデータフロー図を作ってしまっている。
Data Meshという考え方 Data Meshとは:それぞれのデータ保持するモジュールをマイクロサービス(Service Mesh)とし て捉え、モノリス化したデータ基盤を切り崩していく。 Data Meshの四原則: 1. ドメイン志向で分散型のデータオーナシップとアーキテクチャ
2. プロダクトとしてのデータ 3. セルフサービス型データインフラストラクチャ・アズ・ア・プラットフォーム 4. 連合型(federate)の計算ガバナンス
サイロ化を許容してでもData Meshする? そもそも、サイロ化とは? 他者がデータへアクセスする際にとてつもなくコストがかかる、もしくは不可能である状態をさす。 しかし加工の段階(lake->warehouse->mart)によってドメインを分ける やり方こそが、それぞれの連携を希薄化させるのではないか? 結論:自ドメインのデータをプロダクトとして、責任をもって提 供しよう。
やろうとしていること - datalake->datawarehouse->datamartのアーキからの脱却 - 今までwarehouseでの一元管理を行なった結果、どれだけ用途不明のテーブルが堆積していっただろう か... - 各データエンティティがどのドメインに所属しているか、はっきりさせていきたい。 - それぞれのドメインが提供するデータのバージョニング
- 欲しいスキーマのデータを常に受け取れるように(GlaphQLのような仕組みがあればいいなぁ...) ただし、これらを初手で導入するとなると多分頓挫する。 標準のプロトコルや標準の規約などを実装した上で段階的にこなしていけばいいと考えて いる。 (普通のマイクロサービスだって、初手で導入するよりモノリスだったサービスをリアーキテククトする文脈で 使われることが多いですよね?)
Data Meshにベストプラクティスは(まだ)ない。 - 実ケースに基づくデータのパイプラインを管理するのなら、結局一元管理できた方が良いと思 う - データのガバナンスも含めてこの思想を反映したプラットフォームや実例はない。 俺がベスプラになってやるんだよ!!という気持ち
ご清聴ありがとうございました! 参考: データメッシュの原則と論理アーキテクチャの定義: https://www.infoq.com/jp/news/2021/02/data-mesh-architecture/ Data Mesh Principles and Logical Architecture
https://martinfowler.com/articles/data-mesh-principles.html メルカリが「マイクロサービス」に本気で取り組む理由(前編) https://www.sbbit.jp/article/cont1/35635