Fundamentals of Data Engineering (English Edition) 輪読会資料 2023/7/31開催

1. 今回範囲
4
以降、
（著者の記載と区別できるように）
この⻩⾊の吹き出しに
担当者の⾜した、
まとめを書いています。

2. Data accountability
• データアカウンタビリティ（説明責任）は、
データの⼀部分を統治するために個⼈を割り当てることを意味する。もし、その対象
のデータについてだれも責任を持たないのであれば、データクオリティを管理することは
難しい。
注︓データについて責任を持つひとは、データエンジニアである必要はない。責任者
（accountableのほう）はソフトウェアエンジニアかプロダクトマネージャーかもしれない
し、またはほかの役割に仕えてるかもしれない。データクオリティをメンテナンスするため
に必要なリソースのすべては持っていないことが⼀般的なので関連するひとたち（デー
タエンジニアを含む）と協⼒する。
• データアカウンタビリティは様々なレベルで発⽣しうる。（補⾜のセミコロン）。アカウン
タビリティは、テーブルまたはログストリームのレベルで発⽣するが、複数テーブルにまた
がって発⽣するシングルフィールドのエンティティと同じくらい、きめ細かくなり得る。
イチ個⼈が、複数システムにまたがるカスタマーIDの管理について、責任を持つかもし
れない。企業のデータマネジメントにとって、データドメインとは、与えられたフィールドタ
イプにおいて発⽣する可能性のあるすべての値の、集合である（このIDの例のよう
に）。これは、とてつもなくお役所的で、⼏帳⾯すぎるようにも思われるが、著しくデー
タクオリティに、作⽤する。
5
だれかが責任を持つ必要がある
とっても⼤変だけど、クオリティに直結するのでちゃんと取り組む価値がある。
accountability can happen at the level of a table or a log stream
but could be as fine‐grained as a single field entity that occurs across many tables.

3. Data quality 1/3
• このデータを信⽤できるのか︖(Can I trust this data?)
そのビジネスの全員(Everyone in the business)
Data qualityは、望ましい状態に向かうデータの最適化であり、「期待するものと⽐べ
てなにを得るか」という質問の周りをまわる。データは、ビジネスメタデータにおける予
測・期待に沿うべき。データはそのビジネスにより、同意された定義にマッチするか︖
• データエンジニアは、データエンジニアリングライフスタイル全体にわたるData qualityを
保証する。これは、Data qualityテストの実施と、スキーマ想定・データ完全性・精度
への、データの規格適合性の保証を含む。
• 『Data Governance: The Definitive Guide』によると、Data qualityはみっつの主
な特徴から定義される。
Accuracy（正確性） 集められたデータは、実際に正しいか（誤っていないか）︖
重複した値はないか︖数値は正確か︖
Completeness（完全性） レコードは完全か（⽋けていないか）︖すべての要
求されるフィールドは、有効な値を含むか︖
Timeliness（適時性、タイムリーさ） レコードは適宜、利⽤可能な状態か︖ 6
つねに、このような検討をしてData qualityを維持・⾼めていく。
「Can I trust this data?」をより具体的にみるとこんな観点

4. Data quality 2/3
• これら特徴それぞれは、かなり、ニュアンスによるもの。
例えば、ボットとウェブスクレイパー（スクレイピングするもの）がWebイベントデータを
扱うときのことを、私たちはどのように考えるか。
もし、カスタマジャーニー（消費者の⾏動）を分析しようとするなら、わたしたちは、機
械から⽣成されたトラフィックから、⼈間（の⽣成したトラフィック）を分離することをじ
ぶんたちに、できるようにするプロセスを、私たちは持たなければいけない。
⼈間として誤って分類された、ボットから⽣成されたイベントは、データ正確性の問題
を提起する、逆もまたしかり（逆ー＞ボットとして誤って分類された、⼈間から⽣成さ
れたイベント）
• completenessとtimelinessに関しては、様々な興味深い問題がでてくる。
Googleのデータフローモデルを紹介する論⽂では、著者らは、広告を表⽰するオフラ
インビデオプラットフォームの例をだしている。そのプラットフォームは、接続しているあい
だ、ビデオと広告をダウンロードし、ユーザにそれらをオフラインの間にもみることをできる
ようにし、そして、再度接続されたら、広告ビューデータをアップロードする。このデータ
は、広告が⾒られたかなり後に遅れて届くかもしれない。このプラットフォームは広告に
ついての課⾦をどのように、管理するだろうか︖
• 基本的には、この問題は、純粋な技術的な意味では、解決できない。むしろ、エンジ
ニアは、遅れて届くデータのためのじぶんたちの標準を決定し、これらに⼀律に適⽤す
る必要があるだろう、できる限り、様々な技術的ツールの助けとともに。
7
というような興味深い問題
さっきのData qualityにまつわる疑問の具体的な検討例(特にAccuracy)
この種の問題には、標準の整備とかそういう取組が必要（ツールはあくまでも助け）

5. https://static.google
usercontent.com/m
edia/research.goog
le.com/en//pubs/ar
chive/43864.pdf
8

6. MASTER DATA MANAGEMENT
• マスターデータは、
ビジネスエンティティ（従業員、カスタマ、製品、場所）についてのデータである。組織
は、有機的成⻑（organic growth）と企業買収を通じて、よりおおきくより複雑に
成⻑し、ほかのビジネス（会社︖）と共同するにつれて、エンティティと識別情報の
⼀貫した絵（a consistent picture of entities and identities）をメンテナンスする
ことは、ますます⼤変な課題になっている。
• MDMは、golden recordsとして知られる⼀貫したエンティティ定義を構築するための
プラクティスである。golden recordsはエンティティデータを組織において調和させ、か
つ、そのパートナーとも調和させる。
MDMは、テクノロジーツールの構築および開発によって促進されたビジネスオペレー
ションプロセスである。例えば、あるMDMチームは、住所のための標準フォーマットを決
め、そして、⼀貫した住所をリターンするためのAPIを作り、カスタマレコードを部⾨をま
たがってマッチする際に住所データを使うシステムを構築するために、データエンジニアと
作業するかもしれない。
• MDMは、データサイクルまるまるを通じて、operational databaseにたどりつく。それ
は、データエンジニアリングの範囲内に直接⼊るかもしれないが、しばしば、組織内で
働く専任チームの割り当てられた責任にもなる。たとえ、MDMをもっていないとしても、
MDMイニシアティブに共同で取り組むようなことがあるかもしれないので、データエンジ
ニアは常にMDMを意識しなければいけない。
9
データベースのフィールドの形を変えないと等︖
MDMは、マスターデータを管理することについてのプラクティスのひとつ

7. Data quality 3/3
• Data quality は、⼈間と技術の境界線の問題に向かい合って座っている。
データエンジニアは、利⽤可能な⼈間のフィードバックを集めるために堅牢なプロセスを
必要とし、品質の問題をダウンストリームのユーザがそれらに気づく前にさきんじて検知
するために、テクノロジーツールを使う。わたしたちは、これらのコレクションプロセスにつ
いて、本書を通して適切な章で扱う。
10
ツール（モニタリングツール、可視化ツールなど︖︖）
を使って、品質の問題を検知、そこから検討・解消、等で
Data qualityに取り組んでいこう

8. Data modeling and design 1/2
• データから、ビジネス分析とデータサイエンスを通じて、
ビジネスの洞察を引き出すために、データは使⽤可能な形態になっていなければいけ
ない。データを使⽤可能な形態に変換するためのプロセスは、Data modeling and
designとして知られている。わたしたちは伝統的に、Data modeling をDB管理者や
ETL開発者の問題として思い浮かべる⼀⽅で、Data modeling は組織のなかのほ
とんどどこででも発⽣する可能性がある。ファームウェアエンジニアはIoTデバイスのため
にレコードのデータフォーマットを開発し、または、Webアプリケーション開発者はAPI
コールに対するJSONレスポンスやMySQLテーブルスキーマを設計する、これらは、す
べて、Data modeling and design の例である。
• 様々な新しいデータソースやユースケースによってData modelingはよりチャレンジング
になってきている。たとえば、厳格な正規化はイベントデータに対してはうまく効かない。
幸運にも、データツールの新世代は、メジャー、次元、属性、階層の論理的分割を
保ちながら、データモデルの柔軟性を向上させている。クラウドデータウェアハウスは、
⼀般的なData modelingパターン（Kimball・Inmon・Data Vaultなど）を依然とし
てサポートしながら、⾮正規化で半構造化(denormalized and semistructured)
のデータの莫⼤な量のingestion（取得）をサポートする。Sparkなどのデータプロ
セッシングフレームワークは、データのスペクトラム全体（フラット構造リレーショナルレ
コードから、⽣の構造化されていないテキストまで）を取得できる。私たちは、これらの
Data modelingと変形パターンについて、８章でより詳細に議論する。 11
DB管理者やETL開発者に限らず、いろんなところで
ので、ひと⼯夫必要

9. Data modeling and design 2/2
• エンジニアが対処しなければいけない多種多様なデータに伴い、
お⼿上げ状態でData modelingをあきらめたくなる誘惑にかられる。
これは、ひとびとが、WORNアクセスパターンについてぶつぶつ⾔うときか、data
swampを参照したときに、明⽩にされる悲惨な結果を伴う、恐ろしい発想である。
データエンジニアは、適切なレベルを適⽤するための柔軟性およびデータソースとユー
スケース向けのモデリングのタイプを開発するのと同時に、モデリングのベストプラクティ
スを理解する必要があります。
12
This is a terrible idea with harrowing consequences, made evident when people murmur of the
write once, read never (WORN) access pattern or refer to a data swamp.
※Write Once Read Many（WORM、一度書き込んだデータを消去・変更できない追記型の記憶方式)という形式があるようで
それをもじって、書き込んで二度と読めない？
※data swamp
データの沼地、データレイクとの対比の表現
どこにどんなデータがあるかわからず、
欲しいデータを捉えることができない状態を
データスワンプと呼び、
どこにどんなデータがあるかがはっきりわかり、
欲しいデータを捉えることができる状態をデータレイク
（参照）
https://www.nttdata‐value.co.jp/glossary/data‐swamp
あきらめたくなるほどややこしくなってる
昨今、ベストプラクティスを学んで対
処していく必要がある

10. Data lineage
• データが、そのライフサイクルを通して、
移動していくなかで、それが順番に渡され、変換されていき、どのシステムがデータに影
響したか、そのデータがなにから構成されているかをどのように知るだろうか︖
Data lineageはデータのライフサイクルを通した、データの監査証跡を記録を⽰し、
データを⽣成するシステムと、そのシステムが影響を受けるアップストリームデータの両
⽅の履歴を追跡する。
• Data lineageは「エラートラッキング」「説明責任」「データとそれを⽣成するシステムの
デバッグ」を⾏う⼿伝いをする。それはデータライフサイクルのための監査証跡を与える
という明らかな利点を持ち、法令遵守の⼿伝いをする。例えば、もし、ユーザがデータ
がシステムから消されることを望むなら、そのデータのリネージュを持っていることによって、
そのデータの保管されている場所と、そのデータの依存関係を、あなたは知ることがで
きる。
• Data lineageは⻑い間、厳しい法令順守基準をもつ、より⼤きい企業とともにあった。
しかし、データマネジメントが主流になることによって、いまは、より⼩さい企業において
も、より幅広く適⽤されていっている。また、Andy PetrellaのDODDというコンセプト
は密接にData lineageと関係していることを、わたしたちは注釈として記載する。
DODDは、データをそのリネージュに沿って、すべて観察する。品質と期待への⼀致を
提供するために、開発、テスト、ついには、製造の間も、このプロセスは適⽤される。
13
データリネージュの有⽤さ
DODDというコンセプトの紹介 https://www.kensu.io/blog/a-guide-to-
understanding-data-observability-driven-development

11. Data integration and interoperability
• Data integration and interoperabilityは、
ツールとプロセスをまたがる、データ統合のプロセスである。シングルスタックでの分析へ
のアプローチから、異種混同のクラウド環境（そこでは様々なツールが必要に応じ
データを⽣成している）に、私たちが引っ越すことにつれて、integration and
interoperability はデータエンジニアの仕事の、絶えず広がり続ける⻑い列を占める
（occupy an ever-widening swath）
• ますます、Integrationは、カスタムデータベースコネクションよりもむしろ、汎⽤APIを通
して起きている。例えば、データパイプラインは、Salesforce APIからデータをプルして、
それをAmazon S3に保管して、テーブルにそれを読み出すためにSnowflake APIを
呼んで、クエリを実⾏するために再度APIを読んで、そしてそれから、結果をSparkが
その結果を消費できる場所であるS3に、エクスポートするかもしれない。
• この活動すべては、⽐較的シンプルなPythonコードで管理できる（データを直接操
作するというよりも、データシステムと会話する形のコード）。データシステムとの対話
形式の複雑さは減少してきてはいるけれども、システムの数およびパイプラインの複雑
さは、劇的に上昇している。ゼロから作り始めるエンジニアは、すぐに、特注のスクリプト
の機能を超えておおきくなり、オーケストレーションの必要性につまづく。オーケストレー
ションはわたしたちのアンダーカレント（our undercurrents）のひとつであり、「オーケ
ストレーション」のところで詳細について議論する。
14
汎⽤APIが提供されるようになって、ひとつひとつのシステムとの連携は楽になってきてるけ
ど、システムが増えすぎてるので、それでも⼤変。そこで、オーケストレーションが求められる。
環境の変化により、統合と相互運⽤性が
仕事の⼤部分を占めるようになる︖

12. Data lifecycle management 1/2
• データレイクの出現は、
データアーカイブとデータ破棄を無視することを、組織に奨励した。簡単により多くのス
トレージを無限に追加できるときに、なぜデータを捨てるのだろう（捨てなくていいだろ
うさ。）ふたつの変化 は、データエンジニアリングライフサイクルの終わりにおきているこ
とに、より多くの注意を払うべく、エンジニアに奨励している。
• ひとつめ。データはますます、クラウドの保管されていっている。これは、わたしたちが、オ
ンプレミスデータレイクのための先⾏投資型⽀出の代わりに、⼤規模な従量課⾦のス
トレージコストを持つこと意味する。毎⽉のAWS明細にすべてのバイト(every byte)
が現れた際は、CFO（最⾼財務責任者）は費⽤節約のチャンスを⾒出す。クラウ
ド環境は、データアーカイブするのに、⽐較的容易なプロセスを作ってくれる。
主要なクラウドベンダは、とんでもなく安い価格で⻑期間のデータ保管を可能にする
アーカイブ向けのオブジェクトストレージクラスを提供しており、これは⾮常にまれにしか
起こらないアクセスを想定したものになっている（データ検索はそんなに安くないことは
注釈されるべきだが、それは別の会話にて）。これらストレージクラスはまた、アクシデ
ントまたは故意による決定的なアーカイブの削除を防ぐための、追加のポリシー制御を
サポートする。
15
データレイクの出現などのビッグイベントで、管理⽅法⾃体も再考察される。
at the end of the data engineering lifecycle. ー＞データ破棄と思われる
ポチポチでいけるような︖出来合いの︖
Amazon S3 Glacier ストレージクラスといったものがある様⼦

13. Data lifecycle management 2/2
• ふたつめ。
プライバシーおよびデータ保持の法律（GDPRやCCPA）は、ユーザの忘れられる権
利を尊重するために、データエンジニアに、活発にデータ破棄をすることを要求する。
データエンジニアは、どんな消費者データを保持しているかを知らなければいけないし、
リクエストおよび法令順守の要求に対して即座に反応してデータを破壊できるように、
⼿順を持っていなければいけない。
• Data destruction（データ破棄）は、クラウドデータウェアハウスにおいては簡単。
SQL semantics（SQL⽂の⽂法︖）は「WHERE節」に従って⾏削除を可能に
する。 Data destructionはデータレイクにおいては、よりチャレンジングになった（デー
タレイクにおいては、write-once, read-manyがデフォルトストレージパターン）。Hive
ACIDやDelta Lakeといったツールは、⼤規模な削除処理の簡単な管理を可能にす
る。メタデータ管理、データリネージ、カタロギングツールの新世代は、データエンジニア
リングライフサイクルの終わりを、合理的、能率的にするだろう。
16
クラウドデータウェアハウスだと簡単なデータ破棄は、
データレイクだと、若⼲難易度が上がる、ので、いろんなツールが
出てきている。

14. Ethics and privacy 1/2
• 最近の数年間の、
データ漏洩、誤送信、データの操作ミス、はひとつのことを明らかにした。
データは⼈々に影響を与える（data impacts people.）。
データは昔は、(⽶国開拓時代の)⻄部地⽅に住んでいた（ようなものだ）、まるで、
野球選⼿カードのように⾃由に集められ、取引されていた。そうした⽇々はとっくに過
ぎ去った。データの倫理上道徳上とプライバシー的な影響は、かつてはセキュリティの
ように、「あると良いもの」としてみなされていたのに対して、それらは現在、データライフ
サイクル全体の中⼼にある。データエンジニアはほかにだれもみていないときにも、正し
いことをする必要がある、それは、みながいつの⽇か⾒るから（because everyone
will be watching someday.）。より多くの組織が、良いデータの倫理とプライバシー
のカルチャーを奨励することを、わたしたちは期待する。
17
かつてはそんなに重要なもの、致命的なものとは
みなされてなかったが、今は全く違う状況。

15. Ethics and privacy 2/2
• 倫理とプライバシーは、データエンジニアリングライフサイクルに、どのように影響するだろ
うか︖データエンジニアは、データセットが個⼈情報とその他のセンシティブな情報を隠
していることを保証する必要がある。（補⾜セミコロン）
それらは変換されるなかで、データセットにおいて、バイアスは識別され追跡される。
規定からの要求事項と法令順守のペナルティは増⼤している(only growing)。あな
たのデータ資産は、数が増えていくデータ規則（GDPRやCCPA）に従っていること
を確実にしなければいけない。これは真剣に受け⽌めてください。わたしたちは、あなた
が倫理とプライバシーをデータエンジニアリングライフサイクルに焼き付けることを確実に
するために、この本を通じて、役⽴つ情報を提供します。
18
bias can be identified and tracked in datasets as they are transformed.
セキュリティとはまた少し違う部分の
気をつけなければいけないところ。