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
170
Data Meshと私
JDSCでの勉強会時のスライドです。
JDSC
August 24, 2021
Tweet
Share
More Decks by JDSC
See All by JDSC
JDSC採用ページⅡ
jdsc
0
1.4k
JDSC採用ページ
jdsc
1
32k
Kubeflowで作る共通データ基盤 (道半ば編)
jdsc
1
170
家電製品の異常検知 (Case Study)
jdsc
0
460
鉄道省エネに向けた車上データ活用事例の紹介
jdsc
0
630
InterpretMLと Explainable Boosting Machineのススメ
jdsc
1
2.1k
Google Cloud Build とAI Platformではじめる軽量MLOps pipelineとAlphaSQL
jdsc
0
370
JDSCの事業・技術
jdsc
0
18k
JDSCの人・カルチャー
jdsc
0
18k
Other Decks in Technology
See All in Technology
実務における脅威モデリングを考えよう
nikinusu
0
640
App Router を実プロダクトで採用して見えてきた勘所をちょっとだけ紹介
marokanatani
1
930
技術的負債解消の取り組みと専門チームのお話
bengo4com
0
340
どこよりも遅めなWinActor Ver.7.5.0 新機能紹介
tamai_63
0
210
Developer Experienceを向上させる基盤づくりの取り組み事例集
coconala_engineer
0
150
たった1人からはじめる【Agile Community of Practice】~ソース原理とFearless Changeを添えて~
ktc_corporate_it
1
480
Envoy External AuthZとgRPC Extensionを利用した「頑張らない」Microservices認証認可基盤
andoshin11
0
250
AIで変わるテスト自動化:最新ツールの多様なアプローチ/ 20240910 Takahiro Kaneyama
shift_evolve
0
240
JEP 480: Structured Concurrency
aya_ebata
0
130
PdMはどのように全てのスピードを上げられるか ~ 非連続進化のための具体的な取り組み ~
sansantech
PRO
4
1.3k
グイグイ系QAマネージャーの仕事
sadonosake
0
340
The XZ Backdoor Story
fr0gger
0
3.6k
Featured
See All Featured
Building a Modern Day E-commerce SEO Strategy
aleyda
36
6.8k
Building a Scalable Design System with Sketch
lauravandoore
459
32k
Debugging Ruby Performance
tmm1
72
12k
How GitHub Uses GitHub to Build GitHub
holman
472
290k
Designing for Performance
lara
604
68k
The Language of Interfaces
destraynor
153
23k
What's in a price? How to price your products and services
michaelherold
242
11k
Music & Morning Musume
bryan
46
6k
VelocityConf: Rendering Performance Case Studies
addyosmani
322
23k
Mobile First: as difficult as doing things right
swwweet
221
8.8k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
26
2k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
29
2.6k
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