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
740
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.3k
Other Decks in Technology
See All in Technology
さくっと実践!Postmanを活用した高品質で持続可能なAPI管理
yokawasa
5
360
VueとViteで作るUIコンポーネントライブラリ ~デザインシステムとプロダクトの理想的な分離を目指して~ / 20241019_cloudsign_VueFesJapan2024_1
bengo4com
8
4.5k
多数のWebサービスをECS/Fargate構成で効率よく構築・運用するなら copilot-cli
interu
2
170
Demystifying Vite Internals
nozomuikuta
3
760
XSS攻撃から考察するAWS設定不備の恐怖/20241012 Hironobu Otaki
shift_evolve
0
150
20241017_俺たちは雰囲気で scope をやっているけどもうちょっとなんとかならんのか?
tokai235
0
360
プログラミング写経のすすめ
natsutan
0
170
AWS Lambda と Amazon SQS で「わかった気になれる」FreeRTOS 入門
soracom
PRO
2
150
全社を巻き込んだ業務オペレーション改善と、それは事業成長に貢献しているのか?を実感した話
marroooon
0
150
塩野義製薬様のAWS統合管理戦略:Organizations設計と運用の具体例
tkikuchi
0
320
俺とVSCode Python Debugger Extension
sat
PRO
1
150
テクニカルライターのチームで「目標」をどう決めたか / MVV for a Team of Technical Writers
lycorptech_jp
PRO
3
160
Featured
See All Featured
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
48k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
9
630
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
Into the Great Unknown - MozCon
thekraken
31
1.4k
A Modern Web Designer's Workflow
chriscoyier
692
190k
Embracing the Ebb and Flow
colly
84
4.4k
KATA
mclloyd
29
13k
Unsuck your backbone
ammeep
668
57k
What's new in Ruby 2.0
geeforr
342
31k
Building Your Own Lightsaber
phodgson
102
6k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9k
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