[2020年7月] Google Cloud Certified – Professional Data Engineer日本語版(プロ認定):暗記ポイント、意味不明単語リストの解説など(2)

どうも、すえきあおいです。

前回に引き続き、Professional Data Engineer日本語版の模試を受けて、勉強して理解したことや暗記ポイントと思われる箇所を、私なりに噛み砕いてピックアップしております。

ちなみに、私が遠隔監視(オンライン)で本番試験を受けるのは2020年7月29日。

これを書いているのは7月13日(月)ですが、当記事は予約投稿なので、記事が公開された当日、私は試験を受けている真っ最中でございます。みんな、オラに元気を分けてくれ!

 

さてさて。余談が過ぎましたね。

アウトプットを意識するだけで学習効率が跳ね上がるし、ブログも更新できて勉強にもなったら一石二鳥なので、みなさんも時間に余裕があるならやってみるといいと思います!

 

試験の概要、模試の受け方などは以下の過去記事をご参照ください。

[2020年7月] Google Cloud Certified – Professional Data Engineer日本語版(プロ認定):遠隔監視(オンライン)試験の申し込み方

[2020年7月] Google Cloud Certified – Professional Data Engineer日本語版(プロ認定):模擬試験の受け方

 

それでは本編行ってみよう!

模擬試験の解説を読んでわかった暗記ポイント(続き)

CloudComposer

GCP版のApache Airflow(ワークフロー管理やスケジューリングを行うためのプラットフォーム)。

 

Airflowのbigquery_operator

Airflowのcontrib(contribution=貢献)モジュール。つまり、ユーザから寄贈されたモジュール。

この場合、GCPのBigQueryとAirflowの連携を容易にするために作られたオペレータ。例えばこんなのがある。

  • GoogleCloudStorageToBigQueryOperator:Google Cloud StorageからBigQueryへの読み込みジョブを実行します。
  • BigQueryCreateExternalTableOperator:Google Cloud Storageのデータを使用して、データセットに新しい外部テーブルを作成します。

他にも、BigQueryではなくDataprocとの連携用にこんなのもある。

DataProcSparkOperator:Cloud DataProcクラスターでSparkジョブを開始する。

 

Cloud Dataflow

GCP のサービスのひとつです。 入力データを取り込み、加工し、出力することに特化したもので、いわゆる ETL(Extract/Transform/Load) と呼ばれるものです。

 

 

意味不明単語リストの解説(続き)

DAG

Airflow ではワークフロー内のタスクの依存関係を DAG (Directed Acyclic Graph, 有向非巡回グラフ) と呼ばれる閉路を持たない有向グラフで定義することができます。

タスクCはタスクAとタスクBが成功した場合にのみ実行される例。

 

BashOperator

Apache Airflowで使うタスクファンクション。(オペレーターファンクション)。こんな感じで使う。

t1 = BashOperator(
    task_id='print_date',
    bash_command='date',
    dag=dag)

 

append=追加する

英語できなくてつらい。全部addに統一して欲しいw

 

DML

Data Manipulation Languageの略。データ操作言語。SQLでいうとSELECT、INSERT、UPDATE、DELETE

 

DDL

Data Definition Languageの略。データ定義言語。SQLでいうとCREATE、DROP、ALTER

 

DCL

Data Control Languageの略。データ制御言語。SQLでいうとBEGIN、COMMIT、ROLLBACK

 

bqコマンドのグローバルフラグ

bqコマンドには「global flag」という各コマンド共通で利用できるオプションのフラグがある。

こんな感じで使う。

%bq --api:APIを呼び出す
%bq --bigqueryrc:コマンドラインツールの構成ファイルへのパス
%bq --bigqueryrc:コマンドラインツールの構成ファイルへのパス
%bq --dataset_id:リクエストに使用するデフォルトのデータセット

などなど。

 

ファイル形式(ORC、AVRO)

ORC、Parquet(パーケイ)はカラムナフォーマット(カラムナ=列指向)。

CSVやJSONはテキストフォーマット。

AVRO(アブロ)は行指向フォーマット。

余談ですが、 Parquet の読み方がずっと分からなくてパークエットだと思っていました。w

 

カラムナフォーマット(Parquet)のファイルフォーマット

カラムナフォーマットでは、分散処理を行うことが前提とされている。

なので、MapReduce(並列分散処理用のフレームワーク)の単位で処理しやすいようにデータが分割配置されている。

 

カラムナフォーマットにおける符号化方式

カラムナフォーマットでは、型が同じデータが並んだり、規則的にインクリメントするデータが並ぶなど、符号化によるデータ圧縮が効きやすいというメリットがあります。

  • Null Suppression:null値を埋め込む代わりに、どこにいくつnullが存在するかの情報を保持することでデータサイズを圧縮する技術。
  • Dictionary Encording:辞書情報を作成して符号化し、データサイズを圧縮する技術。ただしカーディナリディ度が高いと圧縮率が下がる。

  • RLE(Run-Length Encording):繰り返し項目を保存する

  • Delta Encording:参照値と、それ以外のブロックに分け、参照値と各データの差分をとって標準化し、最後にビット数に直す。
  • Dremelのデータモデル:BigQueryで使われている。rが反復レベル、dが定義レベル。

 

Capacitor の列型(BigQuery のストレージ形式)

上記Dremelのデータモデル参照。

すべての列には、その値に加えて、2つの数値(定義レベルと繰り返しレベル)も格納されます。このエンコーディングにより、要求された列のみを読み取ることでレコードの全体または一部の構造を再構築でき、親列を読み取る必要がなくなります

だから、超高速で検索できる、的な話だと思います。深追いすると時間がかかるので、このくらいのザックリ理解で次へ進みます。

興味ある人はこちらの公式ドキュメントをどうぞ。

 

カーディナリティ

カーディナリティ度が低いとは、カラムの値の種類がレコード数に比べて少ないことをあらわす。(縦長の表)

 

BigQueryのExternal テーブル(外部テーブル)

データの実態は外部ストレージ(例えば、Google CloudStorageなど)に格納されている。BigQueryでクエリを実行して、BigQueryの外にあるデータを検索する。当たり前だけど、普通のテーブルに比べてクエリ速度は落ちる。

Storageに触りたくないデータセットを安全な場所(外部ストレージ)に格納しておいて、BigQueryから参照して複製を作って色々触りたい時とかに使う。

 

パイプライン

パイプラインは、入力データの読み取り、そのデータの変換、出力データの書き込みに関連する、一連の計算全体をカプセル化したものです。

 

ParDo

ParDo は、Apache Beam SDK のコア並列処理オペレーションです。入力 PCollection の各要素に対してユーザー指定の関数を呼び出します。ParDo は、0 個以上の出力要素を 1 つの出力 PCollection に収集します。ParDo 変換は、要素を個別に、場合によっては並行して処理します。

 

ParDo 変換、Combine 変換

ParDo では、ユーザー定義コードはすべての要素に適用するオペレーションを指定し、Combine では、値の結合方法を指定します。

 

ランナー

ランナーは、パイプラインを受け入れて実行するソフトウェア。

ほとんどのランナーは、超並列ビッグデータ処理システムへの変換装置またはアダプタです。

 

BigtableIO / BigQueryIO

Pub/SubでPCollectionを二箇所に同時配信したい場合(同じデータに対して2つの異なるユースケースがあり、2つの異なるストレージエンジンを使用する必要がある)に使う。

1)大規模なSQL集計を実行し、

2)TB(テラバイト)のデータから少数の行を取得する

PCollectionは不変であるため、同じ変換に複数の変換を適用できます。

例:

#Create branches by applying multiple transforms to the same PCollection:
PCollection myCollection = {}..
myCollection.apply(BigQueryIO.write)
myCollection.apply(BigtableIO.write)

 

PoC(ピー・オー・シー)

Proof of Conceptの略。概念実証。

 

Cloud Dataflow SideInput(副入力)

DataflowではSideInput(副入力)というオプションがある。

大量のデータと、少量のマスタがあって、 それを結合したい場合などに少量のマスタを副入力として扱う。 例えば

ID,タイムスタンプ,店舗ID,売上金額

という大量の売上データがあるとして、 さらに BigQuery などに 店舗ID,店舗名 という店舗マスタがあり、 最終的に

ID,タイムスタンプ,店舗ID,店舗名,売上金額

というふうに「店舗名」カラムを追加して出力したい場合、 店舗マスタを副入力として扱うとよい。

 

CoGroupBy

Dataflowの集約オペレーション一つ。

他にもGroupByKey、CoGroupByKey、Combine 変換がある。

 

DoFn

ParDoへの引数。ParDo 処理をする場合は、 DoFn を実装する必要がある。DoFn は1度に PCollection の1要素を処理する。 DoFn には型パラメータとして入力・出力の型を指定する。

使用例:

  PCollection lines = ... ;
  PCollection words =
      lines.apply(ParDo.of(new DoFn<String, String>()) {
          @ProcessElement
          public void processElement(ProcessContext c, BoundedWindow window) {
            ...
          }}));

 

Gson

JavaオブジェクトをJSONにシリアライズおよびデシリアライズするオープンソースのJavaライブラリ。

 

Tuple(タプル)

リストや辞書型といった複数の要素を管理するデータ型の一種。ただし、要素を追加・削除・変更できない点で、リストや辞書とは違う。

 

REST

これ、何回調べても頭に入らんのよね…www

Representational State Transfer (REST):分散システムにおいて複数のソフトウェアを連携させるのに適した設計原則の一つ。

 

Persistent Disk

CloudStorageの高パフォーマンス版。高速バックアップ、同時読み取りなどに対応。レイテンシ・高スループットを重視する場合はCloudStorageの代わりにこれを使う。

 

ランダム アクセス ワークロード

ディスクアクセスがきわめてランダムな処理にかかる負荷。

シーケンシャルアクセス(連続してデータにアクセスする)場合に比べて大きい。

 

バルク スループット

バルクロード(bulk load)とは「何かをどこかにまとめてロード(読み込み)しなさい」な命令。

なのでまぁ、まとめて処理(バッチ処理?)する単位時間あたりの量のこと。

 

セカンダリインデックス

Cloud Spannerで使える機能。第二のインデックス。キー列以外の列に対する範囲クエリに対応できるようにデータを最適化したい時に使う。

セカンダリ インデックスを列に追加すると、その列のデータをより効率的に検索できるようになる。

ちなみに、主キー列は自動でインデックスに登録される。

(第一の)インデックスの例:

CREATE INDEX zelda ON fighter_play_count_20_index(zelda);
CREATE INDEX pikachu ON fighter_play_count_20_index(pikachu);

セカンダリインデックスの例:ゼルダからピカチューまで。

CREATE INDEX zelda_to_pikachu ON fighter_play_count_32_multi_column_index(zelda, marth, sonic, snake, rockman, murabito, inkling, kirby, mario, donkey_kong, link, samus, yoshi, fox, pikachu);

 

BigQueryにおける「行キー」

インデックスのこと。(だったらインデックスって書けやぁぁぁぁぁぁ

  • 最も効率の高い Cloud Bigtable クエリは、行キー、行プレフィックス、または行範囲を使用してデータを取得する
  • 読み取りと書き込みは(テーブルの行スペース全体に)均等に分散されるのが理想的です。

 

BigQueryにおける「行プレフィックス」

prefix:接頭辞。

 

アトミック

atomic:不可分(ふかぶん)。

  1. 全操作が完了するまで、他のプロセスはその途中の状態を観測できない。
  2. 一部操作が失敗したら組合せ全体が失敗し、システムの状態は不可分操作を行う前の状態に戻る。

Cloud Bigtable では、すべての操作は行レベルでアトミックに実行されます。

 

スパース

sparse :スカスカ。

Cloud Bigtable テーブルはスパースです。空の列は領域を消費しません。このため、大半の行で大部分の列が空であっても、多数の列を作成することは多くの場合、合理的です。

 

BigTableで行キーのホットスポット化を回避する方法

ホットスポット化した状態↓

この例では、携帯電話の電池のステータスをテーブルに保存していて、行キーが「BATTERY」とタイムスタンプで構成されている場合、その行キーは次々と増え続けます。

Cloud Bigtable では、隣接する行キーは同じサーバーノードに保存されるため、すべての書き込みはノードがいっぱいになるまで 1 つのノードに集中し、いっぱいになった時点で書き込みはクラスタ内の次にノードに移動します。

これが、ホットスポット化です。

ホットスポット化を解決するために、行キーがより均等に分散されるようにします。

解決策1:フィールドプロモーション

例:行キーにUser列を追加。

 

解決策2:ソルティング

例:タイムスタンプのハッシュ値を算出し、それを 3 で割ってその剰余を行キーに追加。( 3 はノード数)

公式はこちら

 

長くなったので続きは次回

それでは!

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