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
Webエンジニアのためのデータエンジニアリング概説
Search
to_lz1
March 14, 2024
Technology
6
820
Webエンジニアのためのデータエンジニアリング概説
ya8 2024 登壇資料
2024-03-15 @ココネリホール
https://hachiojipm.connpass.com/event/304403/
to_lz1
March 14, 2024
Tweet
Share
More Decks by to_lz1
See All by to_lz1
スケーラブルなデータ収集と活用の舞台裏 / scalable data infrastructure of M3
mtoriyama000
0
9.5k
Other Decks in Technology
See All in Technology
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
6
56k
talk_about_wasmwasi
junkishigaki
0
100
アーキテクチャわからん、の話
shirayanagiryuji
0
270
ビジネスと現場活動をつなぐソフトウェアエンジニアリング~とあるスタートアッププロダクトの成長記録より~
mizunori
0
120
Creative Pair
kawaguti
PRO
1
150
High Performance PHP
cmuench
0
120
Classmethod AI Talks(CATs) #14 司会進行スライド(2025.01.31) / classmethod-ai-talks-aka-cats_moderator-slides_vol14_2025-01-31
shinyaa31
0
100
実践!OpenTelemetry
oracle4engineer
PRO
0
180
20250130_『SUUMO』の裏側!第2弾 ~機械学習エンジニアリング編
recruitengineers
PRO
1
520
The 5 Obstacles to High-Performing Teams
mdalmijn
0
220
地方企業がクラウドを活用するヒント
miu_crescent
PRO
1
120
MC906491 を見据えた Microsoft Entra Connect アップグレード対応
tamaiyutaro
1
110
Featured
See All Featured
KATA
mclloyd
29
14k
The Power of CSS Pseudo Elements
geoffreycrofte
75
5.4k
Measuring & Analyzing Core Web Vitals
bluesmoon
6
230
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
2k
Practical Orchestrator
shlominoach
186
10k
Unsuck your backbone
ammeep
669
57k
Designing Experiences People Love
moore
139
23k
Visualization
eitanlees
146
15k
The World Runs on Bad Software
bkeepers
PRO
67
11k
Done Done
chrislema
182
16k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
39
1.9k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
59k
Transcript
Webエンジニアのための データエンジニアリング概説 ya8 2024 2024-03-15 Makoto Toriyama(@to-lz1)
今日話すこと データエンジニアリングとは何か Web開発との共通項を考えてみる ・その1:レイヤー ・その2:テスト
今日伝えたいこと データエンジニアって何やってる人なの? データエンジニアリングって何が面白いの?
今日話さないこと 機械学習にまつわるトピック ・モデル管理などのMLOps分野 ・LLMに関する話題 個別のOSS, SaaSに関する詳細な説明
自己紹介 鳥山 誠(Toriyama Makoto)@to-lz1 Classi株式会社 データエンジニア https://twitter.com/to_lz1 https://github.com/to-lz1 職歴 SIer ->
データエンジニア -> (SWE|SRE|チームリーダー) -> データエンジニア
データエンジニアリングとは? 「組織内外で日々生成されるデータを蓄積し分析するための データシステムを構築し維持管理すること」 データエンジニアリングの基礎 ―データプロジェクトで失敗しないために https://www.oreilly.co.jp//books/9784814400652/
いわゆる「データ基盤」 https://techblog.zozo.com/entry/data-infrastructure-replacement https://buildersbox.corp-sansan.com/entry/2023/12/16/000000 https://tech.dely.jp/entry/rewards_data_infrastructure https://www.m3tech.blog/entry/data-platform-design-pattern
「データ基盤」の用途 ・データ分析と意思決定 ・社内外へのレポーティング ・チーム内でのモニタリング ・これらの目的のために統計的な解析や集計・可視化が必要なことがある ・プロダクトへの活用 ・機械学習プロダクト(レコメンド、予測) ・既存のプロダクトの一機能としてのデータ提供(ダッシュボード等) ・データ自体を販売するような新規ビジネス・新規プロダクト
データパイプライン これらの用途のためには、 ・必要なデータを漏れなく収集する(上流) ・適切に整理し、加工し、提供する(下流) ・それらを「システム」として継続運用する ことが必要 → 配管の比喩を用いてしばしばパイプラインと呼ばれる
データエンジニアリングとは?(再掲) 「組織内外で日々生成されるデータを蓄積し分析するための データシステムを構築し維持管理すること」 データエンジニアリングの基礎 ―データプロジェクトで失敗しないために https://www.oreilly.co.jp//books/9784814400652/
自分なりに言い換えると データが事業に資する形でスムーズに流れるような パイプラインと周辺プロダクトを設計・開発・運用すること
自分なりに言い換えると データが事業に資する形でスムーズに流れるような パイプラインと周辺プロダクトを設計・開発・運用すること → (広く言うと) ソフトウェアエンジニアリング
一般的なWeb開発との 類似点や相違点を見てみたい
共通項その1:レイヤー
Web Application 共通項その1: レイヤー 「レイヤードアーキテクチャにおける『関心事の分離』の概念は、アーキテクチャの中で効 果的な役割と責任のモデルを構築することを容易にする」 『ソフトウェアアーキテクチャの基礎 エンジニアリングに基づく体系的アプローチ』 p.139 Presentation Layer
Business Logic Layer Persistence Layer Database Layer
オニオンアーキテクチャ https://jeffreypalermo.com/2008/07/the-onion-architecture-part-1/
クリーンアーキテクチャ https://blog.tai2.net/the_clean_architecture.html 「一番外側の円は、低レベルで具体的な詳細だ。内側に移るにつれて、 ソフトウェアは抽象的になっていき、高レベルの方針をカプセル化する」
そしていつしか https://twitter.com/hyuki/status/1006583907985182720
閑話休題、我々はなぜ「層」を作るのか? ・責務を分離するため ・アプリケーションの全要素を一度に考える認知負荷は高い 関心事が分離されていないコードはバグの温床になる ・チームメンバー同士に共通認識を築くため ・チームメンバーの間でアプリケーションがどう構成されているか 認識が揃っていないと変更やレビューは難しい ・「これはxx層である」という名付けは共通認識に繋がりやすい → つまるところ、「変更容易性」のため
(もっと言うと、変更が容易であることが競争力を産むため)
データ基盤における「層」の例 「データセットを3層構造で管理して、それぞれに対応するという設計思想」 https://yuzutas0.hatenablog.com/entry/2018/12/02/180000
データ基盤における「層」の例 「データがアーキテクチャの 3 つのレイヤー(ブロンズ → シルバー → ゴールドのテーブル)を流れる際 に、データの構造と品質を増分的かつ漸次的に向上させることを目的としています。」 https://www.databricks.com/jp/glossary/medallion-architecture
発表者の見解 ・層を設けることで、蓄積と加工の責務を分離できるメリットは大きい 👍 ・ETL(Extract - Transform - Load) から ELTへ、なんて言われたりもする
・同様に、メンバーに認識を共有できるメリットも大きい 👍 ・一方、後者のアナロジー (Bronze -> Silver -> Gold)には懐疑的 🤔 ・データに加工を「重ねる」ことで品質が上がることは経験上ほとんどない ・むしろどの層でどの加工をしているかわからないことで問題になりがち ... ・いずれにせよ、レイヤーがもたらす「変更容易性」が重要
多すぎる層の悲劇 in データ基盤 「『過去作られていた加工テーブル』のロジックを将来にわたって引き継ぐことは難しく、さらにそれに対す る加工クエリを書いていると、何かデータに問題があったときに『どのレイヤで不具合が起きているのか』 から調査することになります。 これはかなり辛い調査になることが多いです」 https://www.m3tech.blog/entry/data-platform-design-pattern
実装例: Classiのデータ基盤構成
実装例: Classiのデータ基盤構成 ここ(データ基盤の中核)を抜粋すると ...
実装例: Classiのデータ基盤構成(抜粋) データレイク(蓄積する層) DWH(社内活用する層) Reverse ETL (プロダクトにデータを返す層)
実装例: Classiのデータ基盤構成(抜粋) データレイク(蓄積する層) DWH(社内活用する層) Reverse ETL (プロダクトにデータを返す層) ・赤い矢印はデータの流れ。根本が「上流」 ・各層で責務と影響範囲は分かれている
共通項その2:テスト
分析系システムのテスト ・データをロードするツールがGoで書かれてる... ・よし、テストを書こう 👍 ・データを加工してCSVで出力するPythonスクリプトがあるんだよね... ・ダミーデータ必要だけど、テスト書けそう 👍
なんだ、Web開発のテストと同じじゃん!🥳
そんなある日...
隣の部署の人 「分析用の加工テーブル作ってもらったけど、 なんか数値がおかしいみたいで...」
鬼門「データそのもののテスト」 ・プログラム単体では済まないから、必然的に中規模以上(実行が遅い) ・実際にクエリを流して、できたデータを人が眺める...ということになりがち
我々はなぜ自動テストを書くのか ・自動化されたテストは手動テストよりも圧倒的に速い ・何度も繰り返し同じ手順で実行できるし、人間がやらなくても良い ・システムに変更を加えても自動テストがあれば効率的にバグが検出できる ・つまり、開発者体験も品質も上がる 🙆
だから、 SQLや加工テーブルだって自動テストがしたい
でも、何を「検証」する?
データの”品質”とは.......... 「データ品質とは、データを意思決定に使える状態になっているかという点を、 様々な角度から評価したものです」 ・追跡可能性 ・可用性 ・正確性 ・アクセシビリティ ・ユーザビリティ データ品質の5つの分類と品質管理プロセス https://techblog.kazaneya.com/20231218-dataquality/
「正確性」は自動テストのターゲットになりうる 例えば... ・欠損している区分はないか? ・意図しない値が紛れ込んでいないか? ・意図通りのID(または、IDの組み合わせ)で本当に一意になっているか? ・人数が入るはずの列にマイナスの値などが入ってないか?
現実解とツールの例 dbt: yamlに記載した宣言的な内容を元に、 テスト用のSQLを自動で実行 例: unique, not_null, accepted_values, relationships(特定のテーブルとちゃんと紐づくか) など
https://docs.getdbt.com/docs/build/data-tests
現実解とツールの例 Google Cloud Dataplex: テーブルに対するルールを定義し、 スケジュールまたは オンデマンドで検証 例: RangeExpectation, NonNullExpectation,
RegexExpectationなど https://cloud.google.com/dataplex/docs/auto-data-quality-overview?hl=ja
発表者の見解 ・自動テストの知恵と恩恵は、確実にデータ基盤領域にも届き始めている ・このビッグウェーブに乗らない手はない ・だがこれは「正確性」のテストに過ぎない。他のデータ品質は他の手段が必要 ・例えば、「テーブルが分析に使いやすいか」という点は自動テストが困難 ・ユーザビリティは、一定から先は人間との対話で磨くしかない...! ・でもこれってWeb開発でも同じですよね?
まとめ
共通点と相違点 ・Web開発もデータエンジニアリングも、 洗練された「層」や「テスト」を必要としている ・複雑さを飼い慣らし、変更しやすくて品質も高いシステムを作りたい ・一方で、性質的な違いももちろんある ・設計はパイプラインアーキテクチャになることが多い ・恐らくWeb開発の世界ではマイナー ・「データ品質」という概念について、改めて考える必要がある
個人的に考えるデータエンジニアリングの面白み ・データは、技術力と同様の、時にはそれ以上の価値の源泉になりうる ・→ サービスの運用が長くなればなるほど増えるもの ・→ ドメイン独自のデータの蓄積は、他社には簡単に真似できない ・データエンジニアとSWEのスキルの掛け合わせは、親和性が高い(かも) ・→ 今までにない設計観点を手に入れることができる ・→
今までにない品質観点を手に入れることができる
Thank you for listening!
We are hiring! https://hrmos.co/pages/classi/jobs/0601