データの品質「Data Quality」をテーマにした本だよ
Qualityが低いとなぜ困るのか、どんな方法・ツール・メトリクス・コミュニケーションでQuality向上できるかの説明があるよ
個々のツールの説明は多くはないよ
Qualityを向上させるロードマップの検討・提案・説得などに使えそう（Quality低いとこれだけ困ります、こんな方法があります等）
- 逆に個々のパイプライン・テーブルのQuality向上には、読む時間・コストに見合うか微妙かも（具体的なツールのドキュメント読んで実装した方が良い気もします）

なんで読んだの

最近、データパイプラインの品質管理・監視（Data Testing、Data Monitoring、Data Qualityとか呼ばれる領域）に興味があり、Great Expectations試したりしてました。

2022/9に出版されたこの本は、データパイプラインの品質管理・監視にフォーカスした珍しい本なので、読んでみました。

そもそもData Qualityなんやねん

この本では、Data Qualityを

For the purpose of this book, we define data quality as the health of data at any stage in its life cycle. Data quality can be impacted at any stage of the data pipeline, before ingestion, in production, or even during analysis.

と定義しています。

「health of data」という用語が曖昧さがあります（QualityをHealthに言い換えただけでは）が、別の「Data Downtime」という概念の説明で使われている、「missing, inaccurate, or otherwise erroneous」が「health of data」の意図するところでしょうか。

Data downtime refers to periods of time where data is missing, inaccurate, or otherwise erroneous, and it manifests in stale dashboards, inaccurate reports, and even poor decision making.

この本で紹介されていること

Data Qualityの大切さ
- Webサービスに例えて（昔はダウン気にしてなかったが普及にしたがって、ダウンの監視や改善が重要になった）、データのダウン「Data Downtime」のインパクトで大切さを説明
コストインパクトの計算方法
Building blocks
- DataLake、DWH、Data Catalog
収集->変換->Cleaning->テストの流れ
- Cleaningは外れ値・欠損値の対応や、型の変換などです
テスト・モニタリング
- 典型的なテスト項目（データ量、NULL、分布、一意性、不変性（利益が収益-コストになってるとか））
- dbt、Great Expectations、Deequのメリット・デメリット、簡単なコード例
- Airflowでの例（SQLCheckOperator、「Circuit Breaker」（データ品質が期待以下の場合DAGを失敗させる））
異常検知
- テストだけだと「Unknown unknown」に対応できない
- SQL+惑星データでデータの分布を可視化して、異常値検知
Data Quality
- SLA・SLOと、メトリクスの例（TTD、TTR、NPS、incident数、更新頻度…）
- DAMAのsix dimesion
Data Incidentの対応の例
データリネージュのメリット、例、ケーススタディ（FOX Network）
「Data as Product」
- 概念の説明
- 関係者との調整
- Data Discovery・Catalog大事だよ
- Case Study（Toastの例）
「Data Mesh」
将来の展望（よりプロアクティブ、自動化、分散）

この本で（あまり）紹介されていないこと

機械学習のモデルのQuality（学習した後に劣化するとかの話）
個別のツール・サービスの（詳しい）話
- この本の著者はMonte Carlo（Data QualityのSaaS）の人ですが、特にMonte Carloの説明はありません
- Deequ、dbt、Great Expectations、Airflowについては、少し説明があります
「Data」でないQuality（ソフトウェアのテスト等）

他の本

（Early Releaseの本も含めると）最近Data Quality系の本がいくつか出版されているようです。

learning.oreilly.com

2022-09-12

Data Engineering with Apache Spark, Delta Lake, and Lakehouse読んだ

learning.oreilly.com

tl;dr

LakeHouseアーキテクチャの本だよ
全体像を知るのは良いかも。個々の技術（Spark、DeltaLake、Azure）はそこまで詳しい記載はないよ

なんで読んだの

LakeHouseやDeltaLakeという単語聞いたことありますが、よく知らないなーというのがありました。

O'Reillyのサブスク（Safari）でこの本を見つけて、流行り言葉だし知っておこうかという事で読みました。

この本で紹介されていること

データエンジニアリングの概要
- データの種類とか利用の例とか
アーキテクチャ
- 従来（DataLake、Lambda、Kappa）の概要
- LakeHouse Architecture
Azureのデータエンジニアリング関係のサービスの概要
データパイプライン
- 構成要素（入力、変換、出力、Workflow、監視）
- 作成のフェーズ（Discovery、Design、Development、Deployment）
LakeHouseのレイヤー（Bronze、Silver、Gold）毎のハンズオン
- SQLServerからData Factory使ってAzure Blob Storageへの書き込み（Brozne）
- Azure Blob StorageからDeltaLake・Databricks使って、データの標準化（Silver）
開発後の話
- IaC
- CI/CD
- Monitoring
データエンジニアリングのチャレンジ（難問のニュアンス？）
- Schema Evolution
- データ共有
- データガバナンス（カタログ）

この本では（あまり）紹介されていないこと

Azureのデータ関連サービスの記載ありますが、さらっとした記載です。あくまでこの本のハンズオンを行うための記載と割り切った方が良さそうです
- （というかハンズオンを理解するのも怪しいかも）
- データに関係ないAzureサービスの説明は、なおのことありません
DeltaLakeの説明はありますが、機能（タイムトラベル、トランザクション）の説明のみで、仕組みの話や同じカテゴリーの製品（e.g. Hudi、Iceberg）の比較はほぼありません
- 私はここらへんを知りたかったので残念

その他

ハンズオンに通貨両替のAPI使いますが、対象APIの無料公開が停止しているようです。ただし、APIなくても大半のハンズオンは実行できます
ハンズオンでリソース名を指定する箇所がありますが、Azureのリソースのいくつかはグローバルでユニークである必要があるらしく、そのままでは動きません。何箇所か名前を変えて実行する必要があります
DataFactoryのハンズオン辛い…GUIツールはコピペができないのが辛いですね

2022-08-28

今月読んだ本（2022/8）

読み終わった

booklog.jp

読んでまとめました。特に技術選定の部分が勉強になりました。

not-rogue.hatenablog.com

booklog.jp二回目。Goで写経中。

booklog.jp

そういえばDjangoあまり知らないなーというので読みました。

booklog.jp

クライアントの通りにしているだけでは訴えられる可能性があるので、プロとして頑張りましょうという話が多いですかね。

booklog.jpいわゆるミクロネーション（自称独立国家）の話が多いですが、傀儡国家や

モレネみたいな都市国家的な何かなどが雑多に記載されています。

booklog.jp

読んでる

booklog.jp

2022-08-27

Fundamentals of Data Engineering読んだ

learning.oreilly.comFundamentals of Data Engineeringという本を読みました。

どんな本か

2022年に出版された、名前の通りData Engineering入門の本です。具体的には、

データの流れ（後述のData Engineering Lifecycle）に沿った、仕事・ベストプラクティスの説明
データ基盤のアーキテクチャを考える時の観点
技術選定する時の観点
他の職種の人とのかかわり
データウェアハウスのデータモデリングの概要
流行り言葉の説明

などが説明されています。

構成は、

一部はData Engineeringの一般論（定義や歴史）、全体的なアーキテクチャ・技術の選び方
二部はデータの流れ（後述のData Engineering Lifecycle）に沿った、仕事・ベストプラクティスの説明
三部はセキュリティと、Data Engineeringの未来
- （一部にまとめられたのでは？と思わなくもないです）

の三構成からなっています。特に一部のアーキテクチャ・技術選定の章（3、4章）が私には印象に残っています。

なお、著者のお二人はTernary Dataというコンサルタント会社の方です

どんな本ではないか

基本的に特定・具体的なツール・製品の話には踏み込みません。例えば、一般論としてのData warehouseの説明はありますが、具体的な製品（例えば、SnowflakeやBigQuery）は名前の紹介に留まります。

そのため、この本を読んでもデータ基盤を作ったり使えるようにはなりません。

（それらのツール・製品の理解はしやすくなるでしょうが）

また、Data EngineeringはData Science・Machine Learningの隣接分野ですが（かつ一部オーバーラップや混同される分野）、その説明はほとんどありません。

Data Engineering Lifecylecyle

この本では「Data Engineering Lifecycle」という概念を紹介しており、本文中（特に二章）では、それに沿って話が進みます。

Data Engineering Lifecyleは本文中では

The data engineering lifecycle comprises stages that turn raw data ingredients into a useful end product, ready for consumption by analysts, data scientists, ML engineers, and others

と定義されています。元データをエンドユーザ（データサイエンティスト等）が利用できるようにするまでの一連の流れで、

元データの生成（Generation）
挿入（Ingestion）
変換（Transformation）
提供（Seving）
保存（Storage）

をライフサイクルとしています。

また、「undercurrent」（適当な訳が難しい…）として、

セキュリティ
Data Management
DataOps
Data Architecture
Orchestration
Software Engineering

など、データエンジニアリングを支える横断的な考えについて、都度説明があります。

アーキテクチャ・技術の選び方

3、4章のアーキテクチャ・技術選定の章が特に印象に残っています。

本書では色々書いていますが、

要件ちゃんと考えろ

というのが核で、

過度に複雑にするな
新しいってだけで技術を選ぶな
将来変わりうる所はフレキシブル・スケールする

などが、よく陥る罠に対する注意点なのかなーと思いました。

技術選定関係で印象に残った言葉

データエンジニアリングの領域は新しいツールやバズワードが多いので、その警鐘が多い気がします。

focus on the fundamentals to understand what’s not going to change;

t-wadaさんの技術の審美眼にも似た話あったなーと思い出しました（t-wadaさんの方は変わった部分は変わる要因に注目しようという話だと思いますが）。

speakerdeck.com

Enterprise architecture is the design of systems to support change in the enterprise, achieved by flexible and reversible decisions reached through careful evaluation of trade-offs.

reversible（後からやり直せる）な決定はflexibleな決定に繋がり（やり直せる分柔軟に試せる・戻せる）、flexibleな決定は環境の変化に追随しやすいので良いと繋がります。

There’s also a temptation to do resume-driven development, stacking up impressive new technologies without prioritizing the project’s ultimate goals

We sometimes see small data teams read blog posts about a new cutting-edge technology at a giant tech company and then try to emulate these same extremely complex technologies and practices.