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
210
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
67k
Kubeflowで作る共通データ基盤 (道半ば編)
jdsc
1
270
家電製品の異常検知 (Case Study)
jdsc
0
520
鉄道省エネに向けた車上データ活用事例の紹介
jdsc
0
740
InterpretMLと Explainable Boosting Machineのススメ
jdsc
1
2.6k
Google Cloud Build とAI Platformではじめる軽量MLOps pipelineとAlphaSQL
jdsc
0
470
JDSCの事業・技術
jdsc
0
18k
JDSCの人・カルチャー
jdsc
0
18k
Other Decks in Technology
See All in Technology
実践アプリケーション設計 ①データモデルとドメインモデル
recruitengineers
PRO
5
1.3k
AWSで推進するデータマネジメント
kawanago
0
720
7月のガバクラ利用料が高かったので調べてみた
techniczna
3
800
JuniorからSeniorまで: DevOpsエンジニアの成長ロードマップ
yuriemori
2
340
Grafana Meetup Japan Vol. 6
kaedemalu
1
190
ガチな登山用デバイスからこんにちは
halka
1
180
ヘブンバーンズレッドにおける、世界観を活かしたミニゲーム企画の作り方
gree_tech
PRO
0
410
DeNA での思い出 / Memories at DeNA
orgachem
PRO
6
1.9k
異業種出身エンジニアが気づいた、転向して十数年経っても変わらない自分の武器とは
macnekoayu
0
250
見てわかるテスト駆動開発
recruitengineers
PRO
6
2.3k
オブザーバビリティが広げる AIOps の世界 / The World of AIOps Expanded by Observability
aoto
PRO
0
190
新規案件の立ち上げ専門チームから見たAI駆動開発の始め方
shuyakinjo
0
630
Featured
See All Featured
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
61k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
Agile that works and the tools we love
rasmusluckow
330
21k
Building Adaptive Systems
keathley
43
2.7k
Optimizing for Happiness
mojombo
379
70k
Rails Girls Zürich Keynote
gr2m
95
14k
Bash Introduction
62gerente
614
210k
The Invisible Side of Design
smashingmag
301
51k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
126
53k
The Cult of Friendly URLs
andyhume
79
6.6k
Why Our Code Smells
bkeepers
PRO
339
57k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
44
2.5k
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