[2020年9月] Cloud Architect(Googleプロ認定資格)合格への道:第2回 ビッグデータの取得と保存

どうも、末岐碧衣です。

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

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

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

 

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

 

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

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

模試:1問目

 

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

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

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

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

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

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

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

 

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

 

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

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

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

ただし、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 のクラスタは短時間ジョブ用に最適化されているのですが、どうしても長時間使わなきゃならん、という時はどうするかというヒントも提案されています。

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

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

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

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端末などから直接、リアルタイムでデータをアップロード・更新すること、と言えます。

 

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

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

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

  • 1 秒あたりの最大バイト数: 1 GB
  • 1 秒あたりの最大行数: 10 万行
  • 1 秒あたりの最大バイト数: 100 MB
  • 行の最大サイズ: 5 MB
  • HTTP リクエストのサイズの上限: 10 MB
  • リクエストあたりの最大行数: リクエストごとに 10,000 行
  • insertId フィールドの長さ: 128

他にも上限はいろいろあるので、細かく知りたい人は以下へどうぞ。

Quotas and limits  |  BigQuery  |  Google CloudBigQuery limits the maximum rate of incoming requests and enforces appropriate quotas on a per-project basis. Specific policies vary depending on resource availability, user profile, service usage history, and other factors, and are subject to change without notice.
Quotas and limits  |  BigQuery  |  Google Cloud cloud.google.com
Quotas and limits  |  BigQuery  |  Google Cloud

 

Hiveメタストア

Hiveメタストアは、スキーマや場所などのHiveテーブルに関するメタデータを保持します。

Cloud SQL(MySQLまたはPostgreSQLをサポートするフルマネージドデータベースサービス)を使用すると、MySQLベースのHiveバックエンドを簡単に設定、維持、管理、管理できます。

 

Hive

Apache Hive のこと。

Hadoop上で動作するソフトウェア。Hadoop用のSQLを実行するためのソフト。みたいな。

 

Apache Phoenix

Apache HBaseをバッキングストアとして使用するHadoop向けのOLTPをサポートする、オープンソースの超並列リレーショナルデータベースエンジン。

 

OLTP

OnLine Analytical Processingの略。オンライントランザクション処理。

いつも思うけど、この業界、略しすぎてて付いていけない(涙)

 

次回に続く!

それでは!

末岐 碧衣
  • 末岐 碧衣
  • フリーランス のシステムエンジニア。独立後、一度も営業せずに月収 96 万円を達成。1986年大阪生まれ。早稲田大学理工学部卒。システムエンジニア歴 12年。
    2009年、ITコンサルティング企業に入社。3年目でコミュ障が爆発し人間関係が崩壊。うつにより休職するも、復帰後はコミュ障の自覚を持ち、「チームプレイ」を徹底的に避け、会社組織内においても「一人でできる仕事」に専念。社内外から評価を得た。
    無理に「チームプレイ」するよりも「一人でできる仕事」に専念した方が自分も周囲も幸せにできることを確信し、2015年フリーランスとして独立。