Cloud Architect（Googleプロ認定資格）合格への道：第２回ビッグデータの取得と保存

どうも、末岐碧衣です。

7月に Data Engineer 取ったばかりですが、9月末に今度は Cloud Architect に挑戦することになりました。

ということで、あと2週間切ってますが（！）、前回合格できた Professional Data Engineer の時と同じ手順で、お金をかけず、短期間で勝負を決めたいと思います。

私は技術畑をずっと歩いてきたエンジニアではないので、文系だったりあんまりI Tに自信ないけど、Google Cloud Certified プロ認定試験に挑戦して、資格取りたい！という方には参考にしていただける内容になると思います。

なお、このGoogleの教育プログラムなどに一切お金を使わず、2週間で集中学習する手順は、模試の受験が必須です。まだの方は、まずは模試を受験してみてください。その辺の手順は第１回の記事で詳しく記載しています。

今回のメインテーマ：ビッグデータの取得と保存

模試でいうと、１問目です。

模試：１問目

暗記ポイント① BigQuery へのデータのストリーミング

BigQuery へのデータのストリーミングとは？

BigQuery にデータを読み込むジョブを使用する代わりに tabledata.insertAll メソッドを使用して、一度に 1 レコードずつ BigQuery にデータをストリーミングできます。このアプローチを使用すると、読み込みジョブの実行遅延を発生させることなく、データのクエリを実行できます。

要は、リアルタイムでBigQueryに直接データを流し込む方法。

ただし、リアルタイムなのでその分料金もお高いし、あまりにも大量のデータな場合は不向きですよ、と。

途中で停電とか起きてストリーミングが中断されたらどうなるんだろう、という疑問が湧いてきましたが、以下に回答がありました。最悪、スキップされてもログから追えるようにはなっています。

ストリーミングされたデータは、テーブルへの最初のストリーミング挿入から数秒以内にリアルタイム分析に使用可能になります。まれに（停電時など）、ストリーミングバッファ内のデータが一時的に使用できなくなることがあります。データが使用可能でなくてもクエリは正常に動作し続けますが、ストリーミングバッファに残っている一部のデータはスキップされます。

ただ、データ送信元とBigQueryとの間の通信状態によっては、送信元が何度もデータ送信をしてしまったりします。「再試行シナリオ」といい、その辺は以下で対応してください、と提案されています。

トラブルシューティング：ベストエフォート型の重複排除

すごいシンプルですが、insertIdを使ってチェックしましょう、って話みたい。１分間なら、通信エラーでデータ送信が何度も再試行されても、耐えられますよと。

挿入された行に対して insertId を指定した場合、BigQuery はこの ID を使用して、ベストエフォート型の重複排除を最大 1 分間サポートします。つまり、その期間内に同じ insertId の同じ行を同じテーブルに複数回ストリーミングしようとすると、BigQuery はその行の複数のオカレンスを重複排除して、それらのオカレンスの 1 つだけを保持する可能性があります。

ただし、１分間という制限つきだし、データの重複がないことを保証するものではない、と公式にも乗っていました。

（こういうのは試験に出そう）

絶対にデータの重複は許されない、という場合はBigQueryではなくCloud Datastoreを使えとあります。

BigQuery の重複排除はベストエフォート型であり、データの重複がないことを保証するメカニズムとしての使用には適していません。さらに、データの高い信頼性と可用性を保証するために、BigQuery はベストエフォート型の重複排除の品質を低下させる可能性があります。

データの重複排除に関して厳密な要件がある場合は、Google Cloud Datastore がトランザクションをサポートする代替サービスとなります。

どんな時に使うべき？

非トランザクショナルなデータを集計したい時。つまり、行数が大量で、継続的に追加される。

重複が発生する、データが一時的に利用できなくなるといったケースが稀に発生してもアプリにとって許容できる。

例えば、大量のデータをリアルタイムに収集するアプリなどは、ストリーミング挿入が有効な選択肢となります。大容量のイベントロギングの一例として挙げられるのが、イベント追跡です。

アプリ管理者は、例えば、それらのデータを分析して、全体的な傾向（やりとりや問題の多い領域など）を判断したり、エラーの状態をリアルタイムにモニタリングしたりすることができます。

暗記ポイント② Cloud Dataproc

Cloud Dataprocとは？

Hadoop や Apache Spark のGCP版。

「オンプレで Hadoop や Apache Spark を使ってたけど、いい加減クラウドに移行したいね？」って時に、Hadoop や Apache Spark の代わりになる。Hadoop や Apache Spark のジョブをGCP上にそのまま移行して使いまわせるステキ仕様。

Cloud Dataproc の仕組み↓

この辺は、DataEngineer の試験勉強の時に散々やったので、この辺は割愛しますが、要はそれだけわかってりゃ大体OK。

Cloud Dataproc は短時間のジョブ限定クラスタ用に最適化されている（※）ため、大容量の HDFS ストレージを使用してクラスタを長時間実行すると、コストがかさむ可能性があります。

※Cloud Dataprocの主な差別化要因は、約90秒で一時的なジョブスコープのクラスターを作成するように最適化されていることです。この展開のスピードは、単一のジョブが、ジョブの実行に必要なリソースのみを含む専用クラスターを持つことができ、ジョブの完了時にシャットダウンされることを意味します。

Dataproc を使う時の基本的な考え方

データは Cloud Storage に持たせる
エフィメラル（一時的な）クラスタで処理させる（クラスタに永続的なHDFSを配置することは非推奨！）
クラスタはジョブ固有にすることを推奨
ジョブは小規模に分割して、できるだけ分散させる

オンプレでよく使われているHadoopは、大規模、多目的なクラスタ構成になっていますが、イマドキのクラウド仕様に最適化するなら発想の転換が求められる感じですね。

オンプレの Hadoop → GCP の Dataproc に移行する時のまとめ

Apache Phoenix のコプロセッサやSQL機能が必要ない場合、HBase → Cloud Bigtable に移行する
SQL機能が必要な場合は、Hive → BigQuery に移行する
scikit-learn で Apache Spark を使用している場合は、Cloud Machine Learning Engine に移行する

長時間実行されるCloud Dataprocクラスタを構築するための10のヒント

前述してきたように、Dataproc のクラスタは短時間ジョブ用に最適化されているのですが、どうしても長時間使わなきゃならん、という時はどうするかというヒントも提案されています。

HDFS ではなくCloud Storage にデータを置いて使う
クラスタの構成ファイル（スクリプト）を用意して、再利用させる
ソース管理メカニズムを特定する
Cloud SQLでHiveメタストアデータベースを外部化する
クラウド認証および承認ポリシーを使用する
Stackdriverの使い方を理解する
YARNキューをワークフローテンプレートに変換する
小規模から始めて自動スケーリングを有効にする
複数のクラスター間でジョブ履歴を統合する
GCPサービスを利用する

たぶん１、２、４、８くらいがわかってればいい気がする。他のは読んでみたけど、ちょっと試験に出すにはマニアックすぎる内容だったり、フワッとしてたりするのであんま気にしなくて良さそう。

それぞれ詳細な説明を読みたい人は、以下をご参照ください。

https://cloud.google.com/blog/products/data-analytics/10-tips-for-building-long-running-clusters-using-cloud-dataproc

暗記ポイント③ Cloud Storage

Cloud Storage は Google が提供する中で最もバイト単価の低いストレージ。

「コストを抑えたい」と言われたらまずこのプロダクトを思い浮かべる。

意味不明だったキーワード

ストリーミング

YouTubeの動画再生を思い浮かべてもらえるとわかりますが、数時間の動画でもすぐに再生が始まりますよね。アレは、端末にダウンロードとかせずに、サーバー側（YouTubeならGoogleの超超でかいコンピューター）で動画データの再生をやっていて、端末ではそれをネットを介して見るだけなので、すぐに再生できるんですね。

ご存知のように、処理（YouTubeの場合は動画の再生）を実行しているのはサーバーなので、端末からはネットに繋がっていないとアクセスできないし、端末にデータが残ることもありません。

さて、ここまで理解したところで「BigQueryへのデータのストリーミング」とはなんぞや、と考えていきます。

通常、BigQueryへのデータ読み込みは、Cloud Storageにファイルを格納しておいて、それを読み込ませたりします。

対してストリーミングでは、BigQueryに対してネットを介してIoT端末などから直接、リアルタイムでデータをアップロード・更新すること、と言えます。

要するに、リアルタイムでネットを介して直接サーバーと端末がやり取りするので、一回どっかにファイルにして保存とかする手間とかタイムラグがなくて便利な機能なのです。

ただ、１秒間にウン万件のビッグデータとかでやったら通信量ハンパねぇ感じになります。

模試１問目のフィードバックにもある通り、BigQuery へのデータのストリーミングには、次の上限が適用されます。