著者紹介:
ゆずたそ（1章）令和元年創業・東京下町のITコンサルティング会社「風音屋」代表。日本におけるDataOpsの第一人者。慶應義塾大学経済学部にて計量経済学を専攻。
渡部徹太郎(2章) 東京工業大学大学院 情報理工学研究科にてデータ工学を研究。
株式会社MobilityTechnologies(旧JapanTaxi株式会社)にてMLOpsやデータプラットフォームを担当している。
伊藤徹郎(3章) 大学卒業後、大手金融関連企業にて営業、データベースマーケティングに従事。 現在は、国内最大級の学習支援プラットフォームを提供するEdTech企業「Classi(クラッシー)」の開発本部長とデータAI部部長を兼任し、エンジニア組織を統括している。

はじめに

・昨今、データ基盤の整備に取り組む企業が増えているが、その背景にはデータアナリストやデータサイエンティストによるデータ活用のPoC（ProofofConcept：概念実証）を終え、継続的にデータから価値を引き出すフェイズに移行した影響がある。
・ITベンダ各社はデータ基盤をつくるための製品を市場に投入してきている。例えば、データを集めるための「ETL製品」、データを蓄積し分析するための「DWH製品」、可視化したりレポートにまとめ上げる「BI製品」などがあるが、これらのツールを組み合わせて意味のあるアウトプットを出すには、「段階的かつ継続的な」改善が必要である。
・この課題に対して本書は、「データ」「システム」「ヒト」の３つの観点で解説する。(3章（ヒト）はデータサイエンティストの採用法と活用方法なので割愛。)

第1章データ活用のためのデータ整備

この章はデータスチュワードの観点から「データ」について書かれている。
・データの一連の流れを把握するには、データソース（入口）→ユースケース（出口）までの流れをCRUD表に書き出すのが良い。
　C(Create):データを生成する
　R(Read): データを参照する
　U(Update): データを更新する
　D(Delete): データを削除する
また、データを扱う主体が、社内（どの部門）or社外（どの組織）なのかまでマッピングされている必要がある。つまり、誰がどのようにデータを使うか、５W1Hで考える（ユースケース）。
・データの生成過程を知り、ユースケースの目的を考えることで、どのデータソースを「正しいデータソース」として扱うべきか判断できるようになる。だから、データソースに問題がある時は、下流（データ利用者）から上流（データ生成者）に対してフィードバックすることが重要である。
データ生成の現場をイメージするには、
　・ロール: 生成する主体（ヒトorシステム）
　・オペレーション: ロールがとる行動
　・アプリケーション: ロールが行動する際に使う道具
　・ストレージ: データの保存場所
この4つの階層に分解して整理すると良い（筆者は造語で業務レイヤと呼んでいる。）
・上記のフィードバックが、部門間の利害の対立によってスムーズに行われていない場合は、インセンティブ設計を見直す必要がある。
・データソースからデータレイクへとデータを転送する際に、主にETL（Extract：データ抽出、Transform：データ整形、Load：データ出力）ツールと呼ばれるソフトウェアを活用することが多い。
・データレイクは、何も加工していない、ただのコピーであることが重要。仮にデータの中身に誤りがあったとしても、修正や加工をせず、そのまま集約するのが望ましい。なぜなら、初期段階ではデータ活用者が「この加工方法で問題ない」と合意しても、データ活用が進むうちに「こういった観点でもデータを分析したい」と考えが変わり、問題に発展するからだ。
・本書におけるデータウェアハウスとは、共通指標となるデータ、ならびにそのデータの置き場を指す。複数のデータを統合・蓄積して、意思決定に活用できるように整理したデータが置かれる。（担当現場によって定義が違う場合は、そちらに合わせる）
・自社にとっての共通指標が決まっていない段階で、データウェアハウスを作るべきではない。まずは、「データソース→データレイク」（データソースのコピー）、「ユースケース→データマート」（ユースケースからの逆算）を充実させ、データの活用施策を成功させることで共通指標を明確にする必要がある。
・本書におけるデータマートとは、「特定の利用者」「特定の用途」向けに加工・整理したデータ、ならびにそのデータの置き場を指す。データマートはユースケースと一対一の関係にある。
・また、データソースとデータレイクが一対一の関係にある。データレイクとデータウェアハウスとデータマートの依存関係が1つのワークフローエンジンで管理されている。
・メタデータは「このデータはどのようなデータなのか」を知るために付与される情報である。
データ作成者にとっては既知のことでも、データ利用者にとっては１%でも個人情報が入っていれば気軽に参照できない。調査コストの削減のためにメタデータに記録されているべきである。
・メタデータの整備には時間が掛かるが、まずはデータ生成者がDBに説明文を書くところから始めるべきである。間違っても、専門部隊を結成するなど生成者以外の人間を入れるべきではない。
・ITシステムはITサービスの一つの要素に過ぎない。適正なサービスレベルをデータ利用者と考えることで、使われないシステムは減り、意味のあるアウトプットに繋がる。

第2章データ基盤システムのつくり方

この章はデータエンジニアの観点から「システム」について書かれている。
•多くの企業がデータ分析を行っており、それを支えるデータ基盤の利用も一般的になった。その背景には、ハードウェア面ではパブリッククラウドが普及したこと、ソフトウェア面ではApache Hadoopをはじめとした分散処理ソフトウェアが簡単に利用できるようになったことがある。
•100MByte～1TByte程度のデータを扱うのであればSQLでも可能。それ以上であれば分散処理のできるDWH製品を導入し、複数のコンピュータを制御して分散処理を行う必要がある。分散処理は集計だけでなく、データ収集やデータ蓄積においても必要になる。
•データ収集は、データ基盤の中で最も取り扱いの難しいコンポーネントである。
•データ収集の対象の多くがファイルデータである。データソース側で生成したファイルをファイルシステムに配置し、配置の完了をイベントとしてキューに投入する。ファイルシステムやキューは、データ基盤の内側と外側で管理するケースがある。
•ファイル収集でよく問題となるのは、ファイルの中身が想定と変わってしまうことである。これを回避するためには、データの中身だけでなくデータの構造も一緒に収集する方法が考えられる。JSON SchemaやXML Schemaなどを用いて、収集対象ごとにデータ構造を定義する。
•よりデータ構造を厳格に管理したい場合は、Apache AVROを採用する。AVROは一言で言えばデータ構造に厳格なJSONである。
•収集するデータ量が膨大で減らしたい場合は、Apache Parquetが有効である。データの型に合わせてデータをバイナリで表現するため、データサイズがテキストより小さい。デメリットは、AVROと同様、バイナリフォーマットなのでデータの中身の確認が困難。
•APIからデータを収集するには、APIキーを利用する。利用回数や有効期限に注意すること。
•SQLを利用したDBへのデータ収集は、対象のテーブルサイズが数GByte程度であればSELECT文で取得、格納が可能。だがテーブルサイズが100GByteを超える場合はカーソル（テーブルの中の特定の行を示すデータ）を利用する。
•取得対象のテーブルが大きく、データ収集が予定時間内に終わらない場合は、テーブルの一部を収集orデータウェアハウス内に一時領域を確保し、そこに更新後のテーブルを構築し、更新対象テーブルと交換する方法がある。
•SQLによる収集は高機能で敷居が低いというメリットがあるが、DBへの負荷を考える必要がある。例えば、ECサイトの取引データを扱っているDBを考えると、ユーザーのリクエストの妨げになる。
•負荷を回避したい場合は、オンラインリクエストを処理するデータベースとは別に、データを取得するためのレプリカと呼ばれるDBを用意する。
•レプリカ複製の代替手段として、データをファイルにエクスポートしてファイル経由でデータを収集する方法や、ダンプファイルを利用する方法がある。
•データではなく、更新ログを収集することで負荷を減らす方向がある。

ETLについて

•ETLの製品は、①提供形態（オープンソース,有償,クラウド）、②複雑な加工が可能か、③ソースコードレベルのデバッグの容易さ で分けられる。
（DataSpiderは①有償, ②複雑な加工が可能,③GUIでETL処理が可能）
•フェデレーションという機能が利用できれば、分析用DBからデータソースのDBを直接クエリできる。データソースにあるデータとデータウェアハウスにあるデータの両方を掛け合わせて（例えばJOINして）結果を応答することが可能。例えば、Redshiftの横串検索や BigQueryのCloud SQL 連携クエリがある。