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
180
Data Meshと私
JDSCでの勉強会時のスライドです。
JDSC
August 24, 2021
Tweet
Share
More Decks by JDSC
See All by JDSC
JDSC採用ページⅡ
jdsc
0
1.9k
JDSC採用ページ
jdsc
1
37k
Kubeflowで作る共通データ基盤 (道半ば編)
jdsc
1
180
家電製品の異常検知 (Case Study)
jdsc
0
470
鉄道省エネに向けた車上データ活用事例の紹介
jdsc
0
650
InterpretMLと Explainable Boosting Machineのススメ
jdsc
1
2.1k
Google Cloud Build とAI Platformではじめる軽量MLOps pipelineとAlphaSQL
jdsc
0
390
JDSCの事業・技術
jdsc
0
18k
JDSCの人・カルチャー
jdsc
0
18k
Other Decks in Technology
See All in Technology
Application Development WG Intro at AppDeveloperCon
salaboy
0
190
テストコード品質を高めるためにMutation Testingライブラリ・Strykerを実戦導入してみた話
ysknsid25
7
2.7k
Oracle Cloud Infrastructureデータベース・クラウド:各バージョンのサポート期間
oracle4engineer
PRO
28
13k
Adopting Jetpack Compose in Your Existing Project - GDG DevFest Bangkok 2024
akexorcist
0
110
BLADE: An Attempt to Automate Penetration Testing Using Autonomous AI Agents
bbrbbq
0
320
B2B SaaSから見た最近のC#/.NETの進化
sansantech
PRO
0
880
CDCL による厳密解法を採用した MILP ソルバー
imai448
3
120
強いチームと開発生産性
onk
PRO
35
11k
DynamoDB でスロットリングが発生したとき/when_throttling_occurs_in_dynamodb_short
emiki
0
250
Amazon CloudWatch Network Monitor のススメ
yuki_ink
1
210
DynamoDB でスロットリングが発生したとき_大盛りver/when_throttling_occurs_in_dynamodb_long
emiki
1
430
【Startup CTO of the Year 2024 / Audience Award】アセンド取締役CTO 丹羽健
niwatakeru
0
1.3k
Featured
See All Featured
Rails Girls Zürich Keynote
gr2m
94
13k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
329
21k
Imperfection Machines: The Place of Print at Facebook
scottboms
265
13k
Facilitating Awesome Meetings
lara
50
6.1k
Gamification - CAS2011
davidbonilla
80
5k
Why You Should Never Use an ORM
jnunemaker
PRO
54
9.1k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
KATA
mclloyd
29
14k
YesSQL, Process and Tooling at Scale
rocio
169
14k
Building Flexible Design Systems
yeseniaperezcruz
327
38k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
16
2.1k
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