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
890
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.8k
Other Decks in Technology
See All in Technology
OAuth/OpenID Connectで実現するMCPのセキュアなアクセス管理
kuralab
5
820
Navigation3でViewModelにデータを渡す方法
mikanichinose
0
200
データプラットフォーム技術におけるメダリオンアーキテクチャという考え方/DataPlatformWithMedallionArchitecture
smdmts
5
550
AIにどこまで任せる?実務で使える(かもしれない)AIエージェント設計の考え方
har1101
3
1.2k
BrainPadプログラミングコンテスト記念LT会2025_社内イベント&問題解説
brainpadpr
0
150
20250625 Snowflake Summit 2025活用事例 レポート / Nowcast Snowflake Summit 2025 Case Study Report
kkuv
1
170
Amazon S3標準/ S3 Tables/S3 Express One Zoneを使ったログ分析
shigeruoda
2
380
監視のこれまでとこれから/sakura monitoring seminar 2025
fujiwara3
10
2.8k
Azure AI Foundryでマルチエージェントワークフロー
seosoft
0
140
Windows 11 で AWS Documentation MCP Server 接続実践/practical-aws-documentation-mcp-server-connection-on-windows-11
emiki
0
670
エンジニア向け技術スタック情報
kauche
0
110
Definition of Done
kawaguti
PRO
6
460
Featured
See All Featured
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Building Applications with DynamoDB
mza
95
6.5k
Building Adaptive Systems
keathley
43
2.6k
Agile that works and the tools we love
rasmusluckow
329
21k
Statistics for Hackers
jakevdp
799
220k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3k
Building an army of robots
kneath
306
45k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.4k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
Music & Morning Musume
bryan
46
6.6k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
130
19k
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