献本いただいて4周ぐらい読みました。400ページ強あるのでかなり読み応えがあり、ブログにするのが遅くなりました。。。
![Google Cloudではじめる実践データエンジニアリング入門[業務で使えるデータ基盤構築]](https://m.media-amazon.com/images/I/51w8dXNHXbL._SL200_.jpg)
技術評論社 (2021-02-20T00:00:01Z)
￥3,740
読者（私）について
元インフラエンジニアで業務で GCP を触っていましたが、コンピューティング（GCE、ロードバランシングなど）、権限（IAM）、組織・プロジェクト管理・コスト管理をメインに扱っており、データ分析系サービスはハンズオンで触ったことがある程度です。BigQuery とデータポータルは Cloud Billing（料金請求）でコスト計算するために触っていました。どちらかというと AWS に触れている時間の方が多いです。
本書について
「Google Cloudではじめる実践データエンジニアリング入門」は、Google Cloud（以下、GCP）でデータ基盤を構築・運用するために必要なことが書かれています。「業務で使える」とタイトルにあるように、大規模なデータ量に耐えうるだけのデータ基盤の構築や、セキュリティ・コスト、さらには機械学習にまで踏み込んで紹介されています。著者は元も含めて全員 Google Cloud の方々なので、内容的にかなり信頼できるといえます。多くの章では外部公開されているデータを用いて実際に手を動かせるので、より深く学びを得ることができます。
GCPだけに特化しているわけではなく、データ基盤そのものについての説明がされているので、データ分析やデータ基盤に関する知識があまりない私でも理解できて読み進めることができました。
各章について
本書は11章から構成されています。1章はデータ基盤の概要で、2章～10章はデータウェアハウス、データレイクなどデータ基盤構築に関する内容、11章は発展的な内容として地理情報分析・機械学習が取り上げられています。
以下、各章を読んだごく一部の要約と感想を記載しています。自分自身が理解していたり、（今は）重要でないと思った箇所はあえて記載していないこともあるので、説明が足りない箇所があるかもしれません。
1章
本章で分析技術以上にデータ基盤が重要であると記されています。なぜなら、データが適切に管理され、適切な権限のもと、データを自由に利用できる状態でなければデータ活用が十分にすすめることができないからです。データ基盤として「早く、正しく、確実に」データを集める機能に加えて、「適切な権限管理のもとでデータ基盤が開放されている」という状態が重要であると述べられています。
データ基盤の遷移およびデータ基盤に関する用語の説明がされています。
データウェアハウス（以下、DWH）はデータベースの一種ですが、分析を主な目的としたアーキテクチャで目的別や時系列に大量のデータを蓄積できる特徴があります。
データマートは、DWH 上に集められたデータを目的別に事前に集計しておくことで、特定用途に対するクエリのレスポンスを向上させることを目的に構築します。データマートは集約された DWH から特定の条件でフィルタされたデータを集めておいて、アプリや分析から利用されます。データマートの登場で「利用を検討するタイミングで必要とするデータを探して集め始める」から「事前に必要になりそうなデータを集めておく」という変化が起きました。
データ基盤を取り巻く環境が変わっていく中で、DWH の課題が出てきました。そこで登場したのがデータレイクです。データレイクは、規模の大小に関わらず構造化データも非構造化データ（画像や自然言語、音声など表形式で表現できないデータ）も保存できます。また、データを保存する際に整形する必要がなく、データを発生したときのまま保存できます。
2章
2章は BigQuery の基礎知識、内部構造、使い方、クエリ最適化についてです。
BigQuery はマルチテナント方式（Google が事前に巨大なリソースプールを確保して、クエリに必要なリソースを動的に割り当てる）を採用していることから、事前にプロビジョニングすることなく、高速なクエリ実行や低コストを実現しています。
BigQuery はストレージとコンピュート、メモリは分散されていて、それぞれ完全に独立することで、スケーラブルなアーキテクチャを実現しています。分散ストレージとワーカーを分離することで、課金体系がクエリとストレージで分離されたため、クエリをあまり実行しないがストレージ容量が逼迫するためにインスタンスタイプをあげるといったことがなくなります。さらに、メモリを分離し、シャッフル処理をワーカーではなく、巨大な分散インメモリシャッフル基盤で行うことで、従来のシャッフルで課題だった、通信のオーバーヘッドやワーカーの耐障害性が改善されています。
BigQuery はインデックスを持たないことも特徴の一つです。膨大なコンピューティング環境によるデータフルスキャンの高速化でインデックスなしでも高スループットを実現できています。インデックスを必要としないことで、インデックス管理の手間を削減し、どんな分析を行うか読めないデータであっても、高速かつ柔軟なアドホック分析ができるメリットがあります。
BigQuery のクエリを最適化するテクニックとして、取得するカラムの限定、パーティション分割・クラスタ化、キャシュの利用が紹介されています。BigQuery は性能が向上してきており、アンチパターンと呼ばれるクエリを内部で最適なするようなクエリオプティマイザの改善などから、先ほどの方法を試していき、それからマイナーチューニングということで公式ドキュメントを読むのが良いとされています。
BigQuery の内部構造ってマイナーな領域でデータ基盤と関係ないのでは？と思うかもしれません。しかし、内部構造を理解することで、なぜ我々は BigQuery で大量データでも高速にクエリ結果を得ることができるのかを知ることができますし、クエリを最適化するテクニックを知る際に腹落ち感が増します。
ストレージ、コンピュートが分離できていることで、BigQuery をデータレイクとしてデータ保管するのにも一役買っていると思います。BigQuery のストレージは Cloud Storage とあまり変わりないですし、パーティション単位で自動削除もできるので、ストレージコストを最小限に抑えることができます。
BigQuery はインデックスを持たなかったり、クエリチューニングをあまりしなくても高スループットが出せるので、細かいテーブル設計をしなくても済みますし、インデックスを意識しすぎて本来なら実行したいクエリが実行できないということにはならないのが嬉しいと思いました。
3章
3章は BigQuery を DWH として利用するための設計方法についてです。
DWH に求められる要件の一部として、高可用性があります。BigQuery では、自動で複数のゾーンをまたいでレプリケーションされており、マシンレベルでの障害ではクエリは失敗せず、数ミリ秒以下の遅延が発生する程度です。ゾーンレベルで障害が発生してもゾーンの切り替えを高速に行うため、ダウンタイムが発生しません。メンテナンスの際には透過的に行っているためユーザには影響しません。
BigQuery Reservations による性能面の強化およびコスト最適化について紹介されています。BigQuery Reservations によって、スキャン量による従量課金モデルから、処理するコンピュート能力に応じた課金モデルへ切り替えることができます。それによりコストの安定化がされると同時に、スロットスケジューリングによってスロット数を確保することで、分散処理のスループットを増やすことができます。
BigQuery はインデックスをもたず、チューニングの余地が基本的にないため、テーブル設計がパフォーマンス最大化の肝となります。パーティション分割を利用することで、効率的なデータスキャンができます。パーティションごとにデータの有効期限を設けることができるので、ストレージコストを最適化することもできます。他にもクラスタ化やマテリアライズドビューが紹介されています。
オペレーションミスなどによるデータの上書きや削除があった場合、タイムトラベルという機能で、最大7日間（デーブル削除は2日）任意の時間帯に戻すことができます。
BigQuery は OLAP（分析処理）用途のデータベースで、データの追記（INSERT）と読み出し（SELECT）に特化しています。そのため、更新系（UPDATE/DELETE/MERGE）に弱いという面を持ちます。そのため、1つのテーブルに対する頻繁な更新を行うよりも、データの洗い替えを行った方が BigQuery のパフォーマンスを最大限に活かすことができます。
2章からさらに突っ込んで BigQuery を業務で活用するためのノウハウが紹介されています。一昔は BigQuery でクラウド破産があると言われていましたが、BigQuery Reservations によって利用料金が安定化されるようになりました。さらに BigQuery Reservations によってスロット数を確保してスループットを増やすことができるのは知りませんでした。スロットの割当てが今までよく分かっていませんでしたが、本章でイラスト付きで丁寧に解説されているのでじっくり読めば理解できるようになるはずです。
タイムトラベル機能は万が一のオペレーションミスにはとても助かりますね。Amazon Aurora の Backtrack にも同様の機能がありますが、DWH に備えているのが大きいです。
4章
4章はデータレイクです。データレイクとは「流動的に状況が変わり得るビジネスの世界において、企業が必要なときに、必要なデータを取り出して整形加工して分析するために必要なもの」とされています。
GCP におけるデータレイクに利用できるサービスとして、Cloud Storage と BigQuery があります。
Cloud Storage を活用する場合、Dataproc（マネージド Hadoop/Spark サービス）で Spark などのジョブによってCloud Storage 上に Hive パーティションデータを作成し、BigQuery からフェデレーションデータソース機能によってデータロードせずに直接クエリを実行する方法が紹介されています。
BigQuery をデータレイクに活用する場合、BigQuery Storage API を利用して Dataproc にある Spark アプリケーションに対して直接データを読み出す方法が紹介されています。このようにデータレイクと DWH 両方の役割を果たすのを「データレイクウェアハウス」と呼ばれます。
Data Catalog は GCP で構築されたデータ分析基盤のデータを管理し、検索できる、フルマネージドのメタデータ管理サービスです。テクニカルメタデータ・ビジネスメタデータの2種類のメタデータを管理でき、ビジネスメタデータはユーザーが Data Catalog でタグ付けを行い管理します。
データレイクといえば、Cloud Storage と思っていたのですが、BigQuery でデータレイクを実現できるとは考えてもみなかったです。
5章
5章は ETL/ELT です。データレイクに収集したデータを分析するために、ELT または ELT と呼ばれる処理によってデータを整形・加工・集計する必要があります。
ELT（Extract、Transform、Load）とは、あるデータソースからデータを取得（Extract）し、それを変換（Transform）し、その結果をあるデータストレージへ書き込む（Load）という一連の処理のことです。ELT（Extract、Load、Transform）とは、ELTのデータソースへの書き込み（Load）と変換（Transform）の順序が逆になった処理のことです。
BigQuery、Dataflow、Dataproc を利用した ELT 処理（BigQuery の場合は ELT/ETL）する方法が紹介されていて、サンプルコードがあるので手を動かすことができます。また、これらの ETL/ELT サービスの使い分けについても記されています。
BigQuery を DWH として使用する場合は、できる限り ETL ではなく ELT を採用することが推奨されています。それは、BigQuery が DWH としてスケーラブルである点、SQL でデータ変換ができる点、オーバーヘッドなく、すぐに大規模処理として実行できる点からです。
Dataflow は、GCP から提供されているフルマネージドなデータ処理サービスです。Apache Beam の実行環境として、ストリーミング処理とバッチ処理の双方を1つのサービスに統合して提供されているのが特徴の一つです。Dataflow を本番環境で利用する場合に、可用性・スケーラビリティ・コスト最適化の観点から考慮点が紹介されています。
Dataproc は、GCP から提供されているマネージドな Hadoop/Spark サービスです。Dataflow と同様に、Dataproc を本番環境で利用する場合に、可用性・スケーラビリティ・コスト最適化の観点から考慮点が紹介されています。
ETL/ELT 処理は Apache Beam や Spark などのフレームワークが登場し、データエンジニアにとって腕の見せどころだという印象で、専門知識を持たない開発者にとっては敷居が高く感じていましたが、BigQuery上で SQL でデータ加工し、中間テーブルに出力していく方法だと、さきほどのフレームワークを使うことなく SQL のみで実現できるのがいいですね。
6章
6章はワークフロー管理・データ統合です。データ基盤においてデータパイプラインは欠かせません。データパイプラインを構成するのがワークフロー管理とデータ統合です。本章では Cloud Composer と Cloud Data Fusion を使って、5章の ETL 処理のサンプリシナリオをワークフロー管理する例が紹介されています。また、Cloud Composer と Cloud Data Fusion の使い分けについても記されています。
Cloud Composer は、GCP が提供するフルマネージドのワークフロー管理サービスです。オープンソース（OSS）のApache Airflow が活用されています。 また、BigQuery や Dataflow、Dataproc などのサービスとの連携が容易です。
Cloud Data Fusion は、フルマネージドなデータ統合サービスです。OSS のデータパイプライン構築サービス CDAP を活用して構築されています。GCP のサービスや、他クラウドサービスや OSS、SaaS サービスなどと連携するための多くのプラグインが提供されているのが特徴の一つです。
Cloud Data Fusion は Cloud Next'19 で発表されてそのときはサンフランシスコに行っていたので記憶に残っています。Cloud Composer との使い分けが分かっていなかったのですが、連携サービスの多さと GUI による工数の省略化の恩恵を受けられるので活用していきたくなりますね。
7章
7章はセキュリティとコスト管理です。セキュリティには、アクセス制御（誰がどのデータをアクセスできるようにするか）と監査（いつ、誰が、どこから、どのデータにアクセスしたのか）が重要です。GCPではアクセス制御においては IAM と VPC Service Controls があります。
IAM は組織・フォルダ・プロジェクト・リソースといった階層に応じてアクセス制御が可能で、上の階層で設定したIAM の設定が下の階層に継承されます。BigQuery はプロジェクト単位よりも細かい、データセット・テーブル・カラム単位でアクセス制御を行うことができます。カラム単位のアクセス制御は IAM ではなく Data Catalog で設定されます。
VPC Service Controls は、仮想的なセキュリティの境界を定義することでアクセス制御を行うことができます。たとえば、BigQuery に IP アドレス制限をかけたり、データソースをエクスポートする先のプロジェクトを限定することができます。
監査は Cloud Logging によって、監査ログを含む、様々なログを保管、検索、管理できます。監査ログの種類として、管理アクティビティ監査ログ・データアクセス監査ログ・システムイベント監査ログの3種類があります。
BigQuery においては、データアクセス監査ログがデフォルトで有効になっているほか、INFOMATION_SCHEMA.JOBS_BY_* ビューに対してクエリを実行することで、「いつ、誰が、どのようなクエリを実行したのか。どのようなテーブルを参照して、そのクエリの実行結果をどのテーブルへ書き込んだのか」というデータアクセス履歴を取得、確認できます。Cloud Logging は BigQuery または Cloud Storage にエクスポートすることができるので、長期保存や Pub/Sub、Dataflow と連携した異常検知を行うことができます。
他にも Cloud Asset Inventory によるリソースの変更履歴を保管・検索や、Security Command Center による監査ログを利用した自動的に脆弱な設定の検知と対応が行えます。
コスト管理においては、プロジェクト分割のベストプラクティスの紹介や請求先の分離方法が紹介されています。また、Cloud Billing の予算機能、予算アラートが提供されているので、予算を超えた場合にメール通知や Cloud Functions による通知のカスタマイズやリソース停止ができます。
インフラエンジニアだったので、セキュリティとコストはどうしても気になります。Cloud Logging はアクセスログなどの保管に利用していますが、フィルタや検索が簡単にできるのがいいですね。BigQuery は監査ログが充実していていざというときに調査しやすいので安心感があります。いざというときは来てほしくないですが。
8章
8章は BigQuery へのデータ集約について。GCP においてデータ基盤を構築するには、BigQueryにデータを集約することがポイントです。BigQuery にデータを集約することで、ELT によるデータ加工ができたり、BI ツールの連携が行えます。また、ストレージ料金が非常に安価（Cloud Storage とほぼ変わらない）なのもメリットの一つです。
BigQuery へデータを取り込む方法の一つとして、BigQuery Data Transer Service（DTS）があります。BigQuery DTSはコードを書かずに定期的なデータ転送を行うことができます。前処理（データを取り込む前にデータ加工などを行う）ができないため、取り込んだ後にELT処理を行う必要があります。
BigQueryのデータ取り込みには、バルクロード・ストリーミング挿入・外部データソースの3種類に集約されます。BigQuery DTSはバルクロードを利用して大きなデータを高速に読み込みます。バルクロードによるデータ取り込みは利用料金は発生しません。
本書を読むとわかりますが、GCP におけるデータ基盤は BigQuery が中心的であり最も重要なサービスです。BigQuery なしのデータ基盤はありえないです。何らかの手段でひとまずは BigQuery にデータを集約させておけば、データ加工ができますし、マテリアライズドビューによる分析用テーブルへの自動反映もできるので困ることがありません。
9章
9章はビジネスインテリジェンス（BI）です。GCP で提供されている BI ツールは、コネクテッドシート（Google スプレッドシート）、データポータル、Looker の3つです。
コネクテッドシートは、Google スプレッドシートで BigQuery のデータを利用できる機能です。BigQuery にデータ処理を任せることで、Google スプレッドシートで大量のデータを扱うことができます。
データポータルは、分析・レポートツールで、GCP 以外に Google アナリティクスなどのGoogleプロダクトのデータを扱うことができます。
Looker は、エンタープライズデータプラットフォームで、GCP 以外の他のクラウドサービスやデータベースシステムと接続して使用できたり（マルチクラウド）、LookML（ビューとモデルをファイルに記述するための言語）をGitで管理できる、ダッシュボードを任意のサイトに iframe を使って埋め込めるなどの特徴があります。
BigQuery には BI ツールとの連携をより強化する機能として、BigQuery BI Engine とマテリアライズドビューがあります。BI Engine は高速なメモリベースの分析機能で、BigQuery にあるデータを通常のクエリ実行よりも高速に返すことができます。
データポータルは、GUI で簡単にダッシュボードが作成できますし、Docs などと同じように Google Workspace（G Suite）の組織内アカウントで簡単に共有できます。さらに無料なので、社内でダッシュボードを作る時に重宝しました。コネクテッドシートは使いたいのですが、使うためのGoogle Workspaceのプランが限定的なので今は使えないのが個人的に残念です。
10章
10章はリアルタイム分析です。一般的に、データの発生から分析までの時間が、秒単位から分単位をリアルタイム、時間単位や日単位はバッチと呼ばれます。リアルタイム分析はデータ分析基盤として求められる機能性に加えて、収集・メッセージング、ストリーミング処理、データの蓄積、スケーラビリティが求められます。
GCP でリアルタイム分析基盤を構築する際には、収集・メッセージングに Pub/Sub、ストリーミング処理に Dataflow、蓄積・分析に BigQuery があります。
Pub/Sub はメッセージングキューイングを行うマネージドサービスで、パブリッシャ（メッセージ発信者）とサブスクライバ（メッセージ受信者）を仲介するサービスです。Google 広告や Google 検索、Gmail などのサービスで Pub/Sub が使われていて、1秒あたり5億件以上のメッセージ、1TB/秒以上のデータ送信があるそうです。
Pub/Sub は、グローバルに展開されているサービスで、グローバルエンドポイントに対して送信すると、利用できる最も近いリージョンにメッセージが保管されます。ロケーション制限ポリシーを利用することで、特定のリージョンに制限することもできます。
メッセージの信頼性として、At-least-once（最低1回の配信成功）が保証されているため2回以上配信される可能性がありますが、Dataflow と組み合わせてメッセージの重複排除を行うことで Exactly-once（1回限りの処理）を実現することができます。
Dataflow は、バッチとストリーミング両方のパイプラインを構築することができます。ストリーミングデータに対して一定の範囲でデータを分割（ウインドウ）し、集計などの処理を行います。データ遅延について、ウォーターマークと呼ばれる基準値を持つことで、受信したデータのタイムスタンプがウォーターマークより古い場合は遅延データとして扱い、デフォルトでは破棄されます。
Dataflow SQL という、SQL クエリでDataflowのデータ処理ジョブを生成できる機能があり、SQL に慣れている人であればストリーミング処理を書くことができます。
BigQuery のバルクロードはマイクロバッチ（短い間隔かつ高い頻度でバッチ処理を実行）に向いていないため、ストリーミング挿入を利用します。
マテリアライズドビューは、ストリーミング挿入に参照元テーブルがリアルタイムに更新されていても常に最新データが取得できます。欠損データの排除やフィルタなどをマテリアライズドビューで実装することで、常に分析できる状態にしておくことができます。
ストリーミング処理をするためには、Pub/Sub と Dataflow が重要なんですね。Pub/Sub はグローバルサービスだと思っていたのですが、リージョン制限できるとは知りませんでした。
BigQuery はバルクロードによる大きいファイルへのロードに向いていますが、ストリーミング処理をする場合はストリーミング挿入を使います。ただし、取り込むのに料金がかかるので注意が必要です。
11章
11章は発展的な分析として、地理情報分析と機械学習が紹介されています。両方とも BigQuery 上で SQL を使って行うことができます。
地理情報分析では BigQuery GIS（Geographic Information Systems）という位置情報データを操作・分析するための関数とデータ型を利用することで BigQuery 上で地理情報データを分析できます。また、BigQuery Geo Viz というツールで Google マップを背景にデータの可視化をします。
GCP における機械学習系サービスは、AI Building Blocks と AI Platform の2種類に分けられています。AI Building Blocks は、AI や機械学習に関する専門知識を持たない開発者でも機械学習モデルを構築することができます。AI Platform は、本格的に機械学習モデルを構築するための環境を提供されており、データサイエンティストや機械学習エンジニア向けのサービスとなっています。
AI Building Blocks の中で代表的なのが BigQuery ML と AutoML Tables です。BigQuery ML は、SQL を使用して機械学習モデルを構築する一連のプロセスを踏むことができます。BigQuery 上のデータを扱うのでデータソースとデータ分析環境が一体となっているのが特徴です。AutoML Tables は、機械学習の一連のプロセスを自動で行うため、機械学習の深い知識がない開発者も高度な機械学習モデルを構築することができます。ただし、モデルの学習結果を評価し、求める水準のモデルになっているかを判断できるだけの機械学習に関する最低限の知識は必要です。
AutoML Tables では推論（学習済みの機械学習モデルに、新しいデータを適用）する方法として、API の提供によるオンライン予測、バッチ処理によるバッチ予測があります。オンライン予測をするには、AutoML Tables のモデルの画面からモデルをデプロイすることで実現できます。バッチ予測は明示的にモデルをデプロイする必要はありません。
BigQuery MLとAutoML Tablesの使い分けについてそれぞれの特徴と向き・不向きがあることから、機械学習モデル構築におけるベストプラクティスが紹介されています。
BigQuery で機械学習をする BigQuery ML 以外に AutoML Tables、AI Platform が紹介されていました。機械学習未経験者に向けて、機械学習における一連のプロセスが書かれているので、知識がない私でも概要について理解することができました。
最後に
冒頭でも書きましたが、ページ数が400を超えていてかなりのボリュームですが、各 GCP サービスについて詳細に触れているので、GCP サービスを理解したい人にとって間違いのない1冊だといえます。特に BigQuery はどの章にも出てくるぐらい重要なサービスなので、BigQuery をうまく使いこなしたいという方も読まれると良いと思います。また、AWS など他のクラウドサービスを使っているけど GCP についてよく分かっていない人にもオススメできる本です。
