Slide 1

Slide 1 text

© 2015 - 2022 Nowcast Inc. データチームの境界を考える 株式会社ナウキャスト 隅田 敦 1

Slide 2

Slide 2 text

© 2013 - 2022 Finatext Ltd. 2 目次 これまでのナウキャストのチーム構造 - データエンジニアが主役となる組織 - チームトポロジー: Stream Aligned Team / Platform Team / チームAPI - Stream Aligned Data Engineering Teamによる効率的な開発 - 課題: チームAPIが整備されていないことによる非効率性 チーム境界とプラットフォームチーム - チームAPIとしてのdbt - Data hub platformに向けた取り組み - Platformチームは中央集権型のデータエンジニアチームではない

Slide 3

Slide 3 text

© 2013 - 2022 Finatext Ltd. 3 これまでのナウキャストのチーム構造

Slide 4

Slide 4 text

© 2013 - 2022 Finatext Ltd. 4 データエンジニアが主役となる組織 データの保有側・利用側の双方に価値を提供するAlternative Dataの Two-Sided Platformを展開

Slide 5

Slide 5 text

© 2013 - 2022 Finatext Ltd. 5 チームトポロジー: Stream Aligned Team / Platform Team / チームAPI ● Stream Aligned Team ○ 価値のデリバリーをend to endで担う ○ 要求探索から本番運用まで他チームへの引き継ぎ無しで行える ● Platform Team ○ Stream Aligned Teamを支援する内部プロダクトの開発を担う ○ インフラなど下位の機能を横断的に抽象化したツールを提供 ● チームAPI ○ チームとやり取りするための方法を記述した仕様 ○ コードであれば, ランタイムのエンドポイント, ライブラリ, UI ○ データの場合はどうか? これを考えるのが本発表の目的

Slide 6

Slide 6 text

© 2013 - 2022 Finatext Ltd. 6 The Bezos Mandate (2002) 私とAWSの15年 あるいはThe Bezos Mandateの話 - NRIネットコムBlog

Slide 7

Slide 7 text

© 2013 - 2022 Finatext Ltd. 7 Stream Aligned Data Engineering Teamによる効率的な開発 ナウキャストのチームの特徴 ● 典型的にはデータソース毎に1つのチーム ○ 1チームだいたい3~6人ほど ● 各チーム内で価値提供に必要な工程が完結 ● Terraformによるインフラの構築 ● Airflow+PythonによるETLの開発/保守 ● Jupyter NotebookによるEDA Stream Alignedなデータエンジニアチーム Stream Alignedであることのメリット ● システムのオーナーシップが向上する ● 各システムが疎結合に保たれる (Conway's law) ● データのドメイン知識が一貫して行き渡る

Slide 8

Slide 8 text

© 2013 - 2022 Finatext Ltd. 8 課題: チームAPIが整備されていないことによる非効率性 各チームの開発したデータには様々な利用者が存在 ● 社内の金融領域に詳しいアナリスト ● 社内の他のデータエンジニアリングチーム ● ナウキャストのデータを購読している社外の顧客 課題: チームAPIが存在しない 以下項目の整備状況/実装方針がバラバラ ● データの置き場所, フォーマット ● 品質保証/バージョン管理/ビジネスメタデータ ● データ更新の締切に関するSLO 認知負荷/コミュニケーションコストの増大

Slide 9

Slide 9 text

© 2013 - 2022 Finatext Ltd. 9 チーム境界とプラットフォームチーム

Slide 10

Slide 10 text

© 2013 - 2022 Finatext Ltd. 10 チームAPIとしてのdbt ● yamlを書くだけでデータのテストとドキュメントが手に入る ● 今はsources [3]だけを使用 htmlに render 宣言的なデータのテスト 任意の項目を 追加可能

Slide 11

Slide 11 text

© 2013 - 2022 Finatext Ltd. 11 Data hub platformに向けた取り組み チームAPIの下でデータをリリースする場所をdata hubと名付 け, 整備中 ● データはs3にparquetで置き, Athenaで参照する ● 各データについてdbtでsourcesを定義 ● データ/sourcesが更新されたらテストを実行 ● renderされたhtmlをs3にホスティング ● dbtのmeta tagでSLOを管理 ○ これを参照して監視システムがSLOをチェック data hubの開発を行うPlatform Teamが必要となる

Slide 12

Slide 12 text

© 2013 - 2022 Finatext Ltd. 12 Platformチームは中央集権型のデータエンジニアチームではない ● 中央集権型はサイロ化やスケーラビリティの低 下に繋がるため望ましくない[2][3][4] ● PlatformチームはData Hubへのリリースを支 援するツールの開発が責務 ○ チームAPIの定義 ○ ビルド/テスト/デプロイ用のスクリプト ○ CI/CD用のツール ○ 監視システム ● 各Sourcesの開発/保守は各Stream Aligned Teamの責務

Slide 13

Slide 13 text

© 2013 - 2022 Finatext Ltd. 13 Reference [1] Team Topologies [2] 私とAWSの15年 あるいはThe Bezos Mandateの話 - NRIネットコムBlog [3] Sources | dbt Docs [4] How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh [5] Data Mesh Principles and Logical Architecture [6] Data Management at Scale

Slide 14

Slide 14 text

© 2013 - 2022 Finatext Ltd. 14 End