Webエンジニアのためのデータエンジニアリング概説

ya8 2024 登壇資料
2024-03-15 @ココネリホール
https://hachiojipm.connpass.com/event/304403/

Transcript

1. Webエンジニアのための データエンジニアリング概説 ya8 2024 2024-03-15 Makoto Toriyama(@to-lz1)
2. 今日話すこと データエンジニアリングとは何か Web開発との共通項を考えてみる 　・その１：レイヤー 　・その２：テスト
3. 今日伝えたいこと データエンジニアって何やってる人なの？ データエンジニアリングって何が面白いの？
4. 今日話さないこと 機械学習にまつわるトピック ・モデル管理などのMLOps分野 ・LLMに関する話題 個別のOSS, SaaSに関する詳細な説明
5. 自己紹介 鳥山　誠（Toriyama Makoto）@to-lz1 Classi株式会社 データエンジニア https://twitter.com/to_lz1 https://github.com/to-lz1 職歴 SIer -> データエンジニア -> (SWE|SRE|チームリーダー) -> データエンジニア
6. データエンジニアリングとは？ 「組織内外で日々生成されるデータを蓄積し分析するための データシステムを構築し維持管理すること」 データエンジニアリングの基礎 ―データプロジェクトで失敗しないために https://www.oreilly.co.jp//books/9784814400652/
7. いわゆる「データ基盤」 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
8. 「データ基盤」の用途 ・データ分析と意思決定 　・社内外へのレポーティング 　・チーム内でのモニタリング ・これらの目的のために統計的な解析や集計・可視化が必要なことがある ・プロダクトへの活用 　・機械学習プロダクト（レコメンド、予測） 　・既存のプロダクトの一機能としてのデータ提供（ダッシュボード等） 　・データ自体を販売するような新規ビジネス・新規プロダクト
9. データパイプライン これらの用途のためには、 ・必要なデータを漏れなく収集する（上流） ・適切に整理し、加工し、提供する（下流） ・それらを「システム」として継続運用する ことが必要 → 配管の比喩を用いてしばしばパイプラインと呼ばれる
10. データエンジニアリングとは？（再掲） 「組織内外で日々生成されるデータを蓄積し分析するための データシステムを構築し維持管理すること」 データエンジニアリングの基礎 ―データプロジェクトで失敗しないために https://www.oreilly.co.jp//books/9784814400652/
11. 自分なりに言い換えると データが事業に資する形でスムーズに流れるような パイプラインと周辺プロダクトを設計・開発・運用すること
12. 自分なりに言い換えると データが事業に資する形でスムーズに流れるような パイプラインと周辺プロダクトを設計・開発・運用すること → （広く言うと） ソフトウェアエンジニアリング
13. 一般的なWeb開発との 類似点や相違点を見てみたい
14. 共通項その１：レイヤー
15. Web Application 共通項その１: レイヤー 「レイヤードアーキテクチャにおける『関心事の分離』の概念は、アーキテクチャの中で効 果的な役割と責任のモデルを構築することを容易にする」 『ソフトウェアアーキテクチャの基礎　エンジニアリングに基づく体系的アプローチ』 p.139 Presentation Layer Business Logic Layer Persistence Layer Database Layer
16. オニオンアーキテクチャ https://jeffreypalermo.com/2008/07/the-onion-architecture-part-1/
17. クリーンアーキテクチャ https://blog.tai2.net/the_clean_architecture.html 「一番外側の円は、低レベルで具体的な詳細だ。内側に移るにつれて、 ソフトウェアは抽象的になっていき、高レベルの方針をカプセル化する」
18. そしていつしか https://twitter.com/hyuki/status/1006583907985182720
19. 閑話休題、我々はなぜ「層」を作るのか？ ・責務を分離するため 　・アプリケーションの全要素を一度に考える認知負荷は高い 　　関心事が分離されていないコードはバグの温床になる ・チームメンバー同士に共通認識を築くため 　・チームメンバーの間でアプリケーションがどう構成されているか 　　認識が揃っていないと変更やレビューは難しい 　・「これはxx層である」という名付けは共通認識に繋がりやすい → つまるところ、「変更容易性」のため 　（もっと言うと、変更が容易であることが競争力を産むため）
20. データ基盤における「層」の例 「データセットを3層構造で管理して、それぞれに対応するという設計思想」 https://yuzutas0.hatenablog.com/entry/2018/12/02/180000
21. データ基盤における「層」の例 「データがアーキテクチャの 3 つのレイヤー（ブロンズ → シルバー → ゴールドのテーブル）を流れる際 に、データの構造と品質を増分的かつ漸次的に向上させることを目的としています。」 https://www.databricks.com/jp/glossary/medallion-architecture
22. 発表者の見解 ・層を設けることで、蓄積と加工の責務を分離できるメリットは大きい 👍 　・ETL(Extract - Transform - Load) から ELTへ、なんて言われたりもする ・同様に、メンバーに認識を共有できるメリットも大きい 👍 ・一方、後者のアナロジー (Bronze -> Silver -> Gold)には懐疑的 🤔 　・データに加工を「重ねる」ことで品質が上がることは経験上ほとんどない 　・むしろどの層でどの加工をしているかわからないことで問題になりがち ... ・いずれにせよ、レイヤーがもたらす「変更容易性」が重要
23. 多すぎる層の悲劇 in データ基盤 「『過去作られていた加工テーブル』のロジックを将来にわたって引き継ぐことは難しく、さらにそれに対す る加工クエリを書いていると、何かデータに問題があったときに『どのレイヤで不具合が起きているのか』 から調査することになります。 これはかなり辛い調査になることが多いです」 https://www.m3tech.blog/entry/data-platform-design-pattern
24. 実装例: Classiのデータ基盤構成
25. 実装例: Classiのデータ基盤構成 ここ（データ基盤の中核）を抜粋すると ...
26. 実装例: Classiのデータ基盤構成（抜粋） データレイク（蓄積する層） DWH（社内活用する層） Reverse ETL （プロダクトにデータを返す層）
27. 実装例: Classiのデータ基盤構成（抜粋） データレイク（蓄積する層） DWH（社内活用する層） Reverse ETL （プロダクトにデータを返す層） ・赤い矢印はデータの流れ。根本が「上流」 ・各層で責務と影響範囲は分かれている
28. 共通項その２：テスト
29. 分析系システムのテスト ・データをロードするツールがGoで書かれてる... ・よし、テストを書こう 👍 ・データを加工してCSVで出力するPythonスクリプトがあるんだよね... ・ダミーデータ必要だけど、テスト書けそう 👍
30. なんだ、Web開発のテストと同じじゃん！🥳
31. そんなある日...
32. 隣の部署の人 「分析用の加工テーブル作ってもらったけど、 なんか数値がおかしいみたいで...」
33. 鬼門「データそのもののテスト」 ・プログラム単体では済まないから、必然的に中規模以上（実行が遅い） ・実際にクエリを流して、できたデータを人が眺める...ということになりがち
34. 我々はなぜ自動テストを書くのか ・自動化されたテストは手動テストよりも圧倒的に速い ・何度も繰り返し同じ手順で実行できるし、人間がやらなくても良い ・システムに変更を加えても自動テストがあれば効率的にバグが検出できる ・つまり、開発者体験も品質も上がる 🙆
35. だから、 SQLや加工テーブルだって自動テストがしたい
36. でも、何を「検証」する？
37. データの”品質”とは.......... 「データ品質とは、データを意思決定に使える状態になっているかという点を、 　様々な角度から評価したものです」 ・追跡可能性 ・可用性 ・正確性 ・アクセシビリティ ・ユーザビリティ データ品質の5つの分類と品質管理プロセス https://techblog.kazaneya.com/20231218-dataquality/
38. 「正確性」は自動テストのターゲットになりうる 例えば... ・欠損している区分はないか？ ・意図しない値が紛れ込んでいないか？ ・意図通りのID（または、IDの組み合わせ）で本当に一意になっているか？ ・人数が入るはずの列にマイナスの値などが入ってないか？
39. 現実解とツールの例 dbt: yamlに記載した宣言的な内容を元に、 テスト用のSQLを自動で実行 例: unique, not_null, accepted_values, relationships（特定のテーブルとちゃんと紐づくか） など https://docs.getdbt.com/docs/build/data-tests
40. 現実解とツールの例 Google Cloud Dataplex: テーブルに対するルールを定義し、 スケジュールまたは オンデマンドで検証 例: RangeExpectation, NonNullExpectation, RegexExpectationなど https://cloud.google.com/dataplex/docs/auto-data-quality-overview?hl=ja
41. 発表者の見解 ・自動テストの知恵と恩恵は、確実にデータ基盤領域にも届き始めている 　・このビッグウェーブに乗らない手はない ・だがこれは「正確性」のテストに過ぎない。他のデータ品質は他の手段が必要 ・例えば、「テーブルが分析に使いやすいか」という点は自動テストが困難 　・ユーザビリティは、一定から先は人間との対話で磨くしかない...！ 　・でもこれってWeb開発でも同じですよね？
42. まとめ
43. 共通点と相違点 ・Web開発もデータエンジニアリングも、 　洗練された「層」や「テスト」を必要としている ・複雑さを飼い慣らし、変更しやすくて品質も高いシステムを作りたい ・一方で、性質的な違いももちろんある ・設計はパイプラインアーキテクチャになることが多い ・恐らくWeb開発の世界ではマイナー 　　・「データ品質」という概念について、改めて考える必要がある
44. 個人的に考えるデータエンジニアリングの面白み ・データは、技術力と同様の、時にはそれ以上の価値の源泉になりうる 　・→ サービスの運用が長くなればなるほど増えるもの 　・→ ドメイン独自のデータの蓄積は、他社には簡単に真似できない ・データエンジニアとSWEのスキルの掛け合わせは、親和性が高い（かも） 　・→ 今までにない設計観点を手に入れることができる 　・→ 今までにない品質観点を手に入れることができる
45. Thank you for listening!
46. We are hiring! https://hrmos.co/pages/classi/jobs/0601