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

Slide 1

Slide 1 text

Webエンジニアのためのデータエンジニアリング概説 ya8 2024 2024-03-15 Makoto Toriyama(@to-lz1)

Slide 2

Slide 2 text

今日話すことデータエンジニアリングとは何か Web開発との共通項を考えてみる　・その１：レイヤー　・その２：テスト

Slide 3

Slide 3 text

今日伝えたいことデータエンジニアって何やってる人なの？データエンジニアリングって何が面白いの？

Slide 4

Slide 4 text

今日話さないこと機械学習にまつわるトピック・モデル管理などのMLOps分野・LLMに関する話題個別のOSS, SaaSに関する詳細な説明

Slide 5

Slide 5 text

自己紹介鳥山　誠（Toriyama Makoto）@to-lz1 Classi株式会社データエンジニア https://twitter.com/to_lz1 https://github.com/to-lz1 職歴 SIer -> データエンジニア -> (SWE|SRE|チームリーダー) -> データエンジニア

Slide 6

Slide 6 text

データエンジニアリングとは？「組織内外で日々生成されるデータを蓄積し分析するためのデータシステムを構築し維持管理すること」データエンジニアリングの基礎 ―データプロジェクトで失敗しないために https://www.oreilly.co.jp//books/9784814400652/

Slide 7

Slide 7 text

いわゆる「データ基盤」 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

Slide 8

Slide 8 text

「データ基盤」の用途・データ分析と意思決定　・社内外へのレポーティング　・チーム内でのモニタリング・これらの目的のために統計的な解析や集計・可視化が必要なことがある・プロダクトへの活用　・機械学習プロダクト（レコメンド、予測）　・既存のプロダクトの一機能としてのデータ提供（ダッシュボード等）　・データ自体を販売するような新規ビジネス・新規プロダクト

Slide 9

Slide 9 text

データパイプラインこれらの用途のためには、・必要なデータを漏れなく収集する（上流）・適切に整理し、加工し、提供する（下流）・それらを「システム」として継続運用することが必要 → 配管の比喩を用いてしばしばパイプラインと呼ばれる

Slide 10

Slide 10 text

データエンジニアリングとは？（再掲）「組織内外で日々生成されるデータを蓄積し分析するためのデータシステムを構築し維持管理すること」データエンジニアリングの基礎 ―データプロジェクトで失敗しないために https://www.oreilly.co.jp//books/9784814400652/

Slide 11

Slide 11 text

自分なりに言い換えるとデータが事業に資する形でスムーズに流れるようなパイプラインと周辺プロダクトを設計・開発・運用すること

Slide 12

Slide 12 text

自分なりに言い換えるとデータが事業に資する形でスムーズに流れるようなパイプラインと周辺プロダクトを設計・開発・運用すること → （広く言うと）ソフトウェアエンジニアリング

Slide 13

Slide 13 text

一般的なWeb開発との類似点や相違点を見てみたい

Slide 14

Slide 14 text

共通項その１：レイヤー

Slide 15

Slide 15 text

Web Application 共通項その１: レイヤー「レイヤードアーキテクチャにおける『関心事の分離』の概念は、アーキテクチャの中で効果的な役割と責任のモデルを構築することを容易にする」『ソフトウェアアーキテクチャの基礎　エンジニアリングに基づく体系的アプローチ』 p.139 Presentation Layer Business Logic Layer Persistence Layer Database Layer

Slide 16

Slide 16 text

オニオンアーキテクチャ https://jeffreypalermo.com/2008/07/the-onion-architecture-part-1/

Slide 17

Slide 17 text

クリーンアーキテクチャ https://blog.tai2.net/the_clean_architecture.html 「一番外側の円は、低レベルで具体的な詳細だ。内側に移るにつれて、ソフトウェアは抽象的になっていき、高レベルの方針をカプセル化する」

Slide 18

Slide 18 text

そしていつしか https://twitter.com/hyuki/status/1006583907985182720

Slide 19

Slide 19 text

閑話休題、我々はなぜ「層」を作るのか？・責務を分離するため　・アプリケーションの全要素を一度に考える認知負荷は高い　　関心事が分離されていないコードはバグの温床になる・チームメンバー同士に共通認識を築くため　・チームメンバーの間でアプリケーションがどう構成されているか　　認識が揃っていないと変更やレビューは難しい　・「これはxx層である」という名付けは共通認識に繋がりやすい → つまるところ、「変更容易性」のため　（もっと言うと、変更が容易であることが競争力を産むため）

Slide 20

Slide 20 text

データ基盤における「層」の例「データセットを3層構造で管理して、それぞれに対応するという設計思想」 https://yuzutas0.hatenablog.com/entry/2018/12/02/180000

Slide 21

Slide 21 text

データ基盤における「層」の例「データがアーキテクチャの 3 つのレイヤー（ブロンズ → シルバー → ゴールドのテーブル）を流れる際に、データの構造と品質を増分的かつ漸次的に向上させることを目的としています。」 https://www.databricks.com/jp/glossary/medallion-architecture

Slide 22

Slide 22 text

発表者の見解・層を設けることで、蓄積と加工の責務を分離できるメリットは大きい 👍 　・ETL(Extract - Transform - Load) から ELTへ、なんて言われたりもする・同様に、メンバーに認識を共有できるメリットも大きい 👍 ・一方、後者のアナロジー (Bronze -> Silver -> Gold)には懐疑的 🤔 　・データに加工を「重ねる」ことで品質が上がることは経験上ほとんどない　・むしろどの層でどの加工をしているかわからないことで問題になりがち ... ・いずれにせよ、レイヤーがもたらす「変更容易性」が重要

Slide 23

Slide 23 text

多すぎる層の悲劇 in データ基盤「『過去作られていた加工テーブル』のロジックを将来にわたって引き継ぐことは難しく、さらにそれに対する加工クエリを書いていると、何かデータに問題があったときに『どのレイヤで不具合が起きているのか』から調査することになります。これはかなり辛い調査になることが多いです」 https://www.m3tech.blog/entry/data-platform-design-pattern

Slide 24

Slide 24 text

実装例: Classiのデータ基盤構成

Slide 25

Slide 25 text

実装例: Classiのデータ基盤構成ここ（データ基盤の中核）を抜粋すると ...

Slide 26

Slide 26 text

実装例: Classiのデータ基盤構成（抜粋）データレイク（蓄積する層） DWH（社内活用する層） Reverse ETL （プロダクトにデータを返す層）

Slide 27

Slide 27 text

実装例: Classiのデータ基盤構成（抜粋）データレイク（蓄積する層） DWH（社内活用する層） Reverse ETL （プロダクトにデータを返す層）・赤い矢印はデータの流れ。根本が「上流」・各層で責務と影響範囲は分かれている

Slide 28

Slide 28 text

共通項その２：テスト

Slide 29

Slide 29 text

分析系システムのテスト・データをロードするツールがGoで書かれてる... ・よし、テストを書こう 👍 ・データを加工してCSVで出力するPythonスクリプトがあるんだよね... ・ダミーデータ必要だけど、テスト書けそう 👍

Slide 30

Slide 30 text

なんだ、Web開発のテストと同じじゃん！🥳

Slide 31

Slide 31 text

そんなある日...

Slide 32

Slide 32 text

隣の部署の人「分析用の加工テーブル作ってもらったけど、なんか数値がおかしいみたいで...」

Slide 33

Slide 33 text

鬼門「データそのもののテスト」・プログラム単体では済まないから、必然的に中規模以上（実行が遅い）・実際にクエリを流して、できたデータを人が眺める...ということになりがち

Slide 34

Slide 34 text

我々はなぜ自動テストを書くのか・自動化されたテストは手動テストよりも圧倒的に速い・何度も繰り返し同じ手順で実行できるし、人間がやらなくても良い・システムに変更を加えても自動テストがあれば効率的にバグが検出できる・つまり、開発者体験も品質も上がる 🙆

Slide 35

Slide 35 text

だから、 SQLや加工テーブルだって自動テストがしたい

Slide 36

Slide 36 text

でも、何を「検証」する？

Slide 37

Slide 37 text

データの”品質”とは.......... 「データ品質とは、データを意思決定に使える状態になっているかという点を、　様々な角度から評価したものです」・追跡可能性・可用性・正確性・アクセシビリティ・ユーザビリティデータ品質の5つの分類と品質管理プロセス https://techblog.kazaneya.com/20231218-dataquality/

Slide 38

Slide 38 text

「正確性」は自動テストのターゲットになりうる例えば... ・欠損している区分はないか？・意図しない値が紛れ込んでいないか？・意図通りのID（または、IDの組み合わせ）で本当に一意になっているか？・人数が入るはずの列にマイナスの値などが入ってないか？

Slide 39

Slide 39 text

現実解とツールの例 dbt: yamlに記載した宣言的な内容を元に、テスト用のSQLを自動で実行例: unique, not_null, accepted_values, relationships（特定のテーブルとちゃんと紐づくか）など https://docs.getdbt.com/docs/build/data-tests

Slide 40

Slide 40 text

現実解とツールの例 Google Cloud Dataplex: テーブルに対するルールを定義し、スケジュールまたはオンデマンドで検証例: RangeExpectation, NonNullExpectation, RegexExpectationなど https://cloud.google.com/dataplex/docs/auto-data-quality-overview?hl=ja

Slide 41

Slide 41 text

発表者の見解・自動テストの知恵と恩恵は、確実にデータ基盤領域にも届き始めている　・このビッグウェーブに乗らない手はない・だがこれは「正確性」のテストに過ぎない。他のデータ品質は他の手段が必要・例えば、「テーブルが分析に使いやすいか」という点は自動テストが困難　・ユーザビリティは、一定から先は人間との対話で磨くしかない...！　・でもこれってWeb開発でも同じですよね？

Slide 42

Slide 42 text

まとめ

Slide 43

Slide 43 text

共通点と相違点・Web開発もデータエンジニアリングも、　洗練された「層」や「テスト」を必要としている・複雑さを飼い慣らし、変更しやすくて品質も高いシステムを作りたい・一方で、性質的な違いももちろんある・設計はパイプラインアーキテクチャになることが多い・恐らくWeb開発の世界ではマイナー　　・「データ品質」という概念について、改めて考える必要がある

Slide 44

Slide 44 text

個人的に考えるデータエンジニアリングの面白み・データは、技術力と同様の、時にはそれ以上の価値の源泉になりうる　・→ サービスの運用が長くなればなるほど増えるもの　・→ ドメイン独自のデータの蓄積は、他社には簡単に真似できない・データエンジニアとSWEのスキルの掛け合わせは、親和性が高い（かも）　・→ 今までにない設計観点を手に入れることができる　・→ 今までにない品質観点を手に入れることができる