DEV Community: Atsumi

"Unable to find current origin/master revision in submodule path" error at Github Action "actions/checkout@v2"

Atsumi — Thu, 20 May 2021 14:34:41 +0000

When I run following actions (that checkout repository with submodules and update),

- name: Checkout
  uses: actions/checkout@v2
  with:
    ref: ${{ github.head_ref }}
    submodules: 'recursive'
    token: ${{ secrets.MY_PAT }}

following error has occurred.

Unable to find current origin/master revision in submodule path

This issue was fixed by fetch-depth: 0 option at checkout action.

GNU timeを知った

Atsumi — Wed, 17 Jun 2020 10:15:49 +0000

High Performance Python 2nd Editionを読む中で、
timeはGNU版と簡易版の二つがあることを知った。

time（シェル組み込み）

bashやzshのプロンプトでパスが通っている timeはシェル組み込みのtimeで、簡易版らしい。

# zsh
$ time sleep 1
sleep 1  0.00s user 0.00s system 0% cpu 1.004 total

GNU time

/usr/bin/timeにインストールされたコマンドはGNU版で、上記よりもリッチな情報を出すことができる。

macの場合はbrew install gnu-timeでgtimeとしてインストール可能。

$ gtime --verbose sleep 1
        Command being timed: "sleep 1"
        User time (seconds): 0.00
        System time (seconds): 0.00
        Percent of CPU this job got: 0%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 0:01.00
        Average shared text size (kbytes): 0
        Average unshared data size (kbytes): 0
        Average stack size (kbytes): 0
        Average total size (kbytes): 0
        Maximum resident set size (kbytes): 612
        Average resident set size (kbytes): 0
        Major (requiring I/O) page faults: 0
        Minor (reclaiming a frame) page faults: 297
        Voluntary context switches: 0
        Involuntary context switches: 17
        Swaps: 0
        File system inputs: 0
        File system outputs: 0
        Socket messages sent: 0
        Socket messages received: 0
        Signals delivered: 0
        Page size (bytes): 4096
        Exit status: 0

Major (requiring I/O) page faultsは、スワップの発生を意味しており注意すべきメトリクスである。

MLflowに入門してみる

Atsumi — Tue, 09 Jun 2020 10:40:16 +0000

MLflowとは

公式ドキュメントのトップページによると以下。

オープンソースで、機械学習の一連のサイクルを管理するためのソフトウェア。
MLflowはPython, R, JavaのAPIを持つ他、REST APIやCLIもあるので様々なライブラリや言語と合わせて利用することができる。
以下４つの機能を持つ。
- MLflow tracking
  - 学習に利用するコードやパラメータ、学習の結果を記録することで、過去の学習記録を簡単にトラッキングできるようにする。
- MLflow Projects
  - コードを再利用可能にする仕組み。
- MLflow Models
  - 機械学習モデルをパッケージングし、様々なプラットフォームで利用な可能な形式で提供することを可能にする
- MLflow Model Registry
  - 機械学習モデルを保存するレジストリ。バージョンや学習の情報などを提供する。

Tutorial

https://www.mlflow.org/docs/latest/tutorials-and-examples/tutorial.html

このチュートリアルの内容

線形回帰モデルを学習
コードをパッケージングし再利用可能な状態にする
モデルをHTTPで利用可能な形でデプロイする

実践

# 環境構築
pipenv install "mlflow[extras]"

学習を実行（MLflow Tracking）

以下を写経
https://github.com/mlflow/mlflow/blob/master/examples/sklearn_elasticnet_wine/train.py

# 実行
## ハイパーパラメータを適当に変えていくつか作ってみる
$ pipenv run python sklearn_elasticnet_wine_train.py
$ pipenv run python sklearn_elasticnet_wine_train.py 0.6 0.6
$ pipenv run python sklearn_elasticnet_wine_train.py 0.4 0.4

# mlrunsというディレクトリができる

学習を結果を確認

# UIを起動
pipenv run mlflow ui

モデルの作成時刻やハイパーパラメータ、学習結果などを閲覧可能。
モデルごとの比較が可能

モデルをパッケージングする（MLflow Projects)

基本的なディレクトリを作る

mkdir sklearn_elasticnet_wine
mv sklearn_elasticnet_wine.py sklearn_elasticnet_wine/train.py

Projectsファイルを作成

こちらに記載のある二つのファイルを作成する。

https://www.mlflow.org/docs/latest/tutorials-and-examples/tutorial.html#packaging-training-code-in-a-conda-environment

※ conda.yamlは、UIのモデル詳細にあったのでコピペした

実行

condaは使いたくないので --no-condaを利用

pipenv run mlflow run sklearn_elasticnet_wine -P alpha=0.42 --no-conda

MLProjectsの実行環境は、conda, Docker, System Environment (今回)の３つを選択可能。

これで、モデル生成に利用したコードと実行環境を別環境でも再現できるようになった。

モデルをサーブする(MLflow Model)

生成されたモデルアーティファクト

モデル作成のステップで作成された mlruns/0/ハッシュ値/artifacts/model/ディレクトリに必要なものが格納されている。

MLmodel: モデルに関するメタ情報
model.pkl: 学習済みモデルをシリアライズしたもの

ちなみに、MLProjectsで利用したconda.yamlもここに入っている。

web APIとしてデプロイ

こちらも、condaを入れたくないので --no-condaで動かす

pipenv run mlflow models serve -m mlruns/0/2ca121e400654d5898de9f4f9e1fe928/artifacts/model -p 1234 --no-conda

リクエストできた。

curl -X POST -H "Content-Type:application/json; format=pandas-split" --data '{"columns":["alcohol", "chlorides", "citric acid", "density", "fixed acidity", "free sulfur dioxide", "pH", "residual sugar", "sulphates", "total sulfur dioxide", "volatile acidity"],"data":[[12.8, 0.029, 0.48, 0.98, 6.2, 29, 3.33, 1.2, 0.39, 75, 0.66]]}' http://127.0.0.1:1234/invocations

[4.479576972663602]

BigQueryベストプラクティス (パフォーマンス:3)

Atsumi — Mon, 01 Jun 2020 00:30:04 +0000

公式ドキュメントに記載のある「BigQuery best practices」をまとめてみるシリーズ。

今回は「Managing query outputs」をまとめます。

イタリック体はドキュメントに記載のない追加コメント

クエリアウトプットに関するベストプラクティス

原文

Avoid repeatedly joining the same tables and using the same subqueries.

繰り返し、同じテーブルや同じサブクエリをジョインすることを避ける。

何度も同じテーブルをJOINする場合は、ネストされたカラムを利用して非正規化する。
何度も同じサブクエリを使う場合は、サブクエリをテーブルとしてマテリアライズする。

Carefully consider materializing large result sets to a destination table. Writing large result sets has performance and cost impacts.

巨大な結果セットを書き込む場合、パフォーマンスとコストに影響があるので注意する。

キャッシュされた結果セットの上限は10GB程度なので、これを越すと Response too largeエラーに繋がる
避けるには、以下の手段を用いる
- 適切にフィルターする
- ORDER BY を利用する場合は LIMIT を利用する
- 出力テーブルを指定する
巨大なテーブルを作成する場合は、有効期限を設定するなどしてコスト管理する。

If you are sorting a very large number of values, use a LIMIT clause.

巨大なデータセットをそーとする場合、 LIMIT を利用しよう

巨大なデータセットに ORDER BY をすると、 Resource exceeded が発生する。これは、ソートの最終ステージは一つのスロットのみで行われるため、スロットの容量を超えてしまうことで発生する。

AI Platform Pipelinesを触ってみる

Atsumi — Sun, 31 May 2020 06:35:43 +0000

AI Platform Pipelinesとは

Kubeflow pipelinesを、GCP上に簡単にセットアップしてくれるGCPサービス。

Kubeflow Pipelinesとは

Kubeflowは、機械学習にまつわるワークフロー（前処理、モデルビルド、デプロイなど）をKubernetes上で管理するための一連のソフトウェア。

Kubeflow PipelinesはKubeflowが提供するコンポーネントの一つで、機械学習にまつわるジョブの流れ（パイプライン）を管理する。

TFXとの関係

TFX Pipelinesのオーケストレーターの一つのオプションとしても利用できるらしい
- https://www.tensorflow.org/tfx/guide/kubeflow?hl=ja）
元々は、TFX PipelinesをKubernetesで簡単に動かすためのGoogle内部ツールだったらしい
- https://en.wikipedia.org/wiki/Kubeflow
他のオーケストレーターとしてはApache beam, airflowがある。

パイプラインの構成

パイプラインは、複数のコンポーネントのDAGから成る。

出典は公式ドキュメント

コンポーネントは、

コンテナイメージ
インプットパラメータ
アウトプット

から成る。

出典は公式ドキュメント

Getting Started!

環境構築

公式ドキュメントの通りに実施。

インストールされたコンポーネント

$ kubectl get deploy
NAME                              READY   UP-TO-DATE   AVAILABLE   AGE
cache-deployer-deployment         1/1     1            1           10m
cache-server                      1/1     1            1           10m
metadata-envoy                    1/1     1            1           10m
metadata-grpc-deployment          1/1     1            1           10m
metadata-writer                   1/1     1            1           9m59s
minio                             1/1     1            1           9m59s
ml-pipeline                       1/1     1            1           10m
ml-pipeline-persistenceagent      1/1     1            1           10m
ml-pipeline-scheduledworkflow     1/1     1            1           10m
ml-pipeline-ui                    1/1     1            1           10m
ml-pipeline-viewer-crd            1/1     1            1           10m
ml-pipeline-visualizationserver   1/1     1            1           10m
mysql                             1/1     1            1           9m59s
proxy-agent                       1/1     1            1           10m
workflow-controller               1/1     1            1           10m

$ kubectl get cm
NAME                            DATA   AGE
cache-configmap                 4      10m
gcp-default-config              3      10m
inverse-proxy-config            3      10m
metadata-grpc-configmap         2      10m
metadata-mysql-configmap        3      10m
workflow-controller-configmap   1      10m

$ kubectl get crd
NAME                                           CREATED AT
applications.app.k8s.io                        2020-05-31T05:19:02Z
backendconfigs.cloud.google.com                2020-05-31T05:19:12Z
capacityrequests.internal.autoscaling.k8s.io   2020-05-31T05:18:57Z
managedcertificates.networking.gke.io          2020-05-31T05:19:05Z
releaserollbacks.app.gke.io                    2020-05-31T05:19:03Z
releasetracks.app.gke.io                       2020-05-31T05:19:02Z
scalingpolicies.scalingpolicy.kope.io          2020-05-31T05:18:59Z
scheduledworkflows.kubeflow.org                2020-05-31T05:23:14Z
storagestates.migration.k8s.io                 2020-05-31T05:19:07Z
storageversionmigrations.migration.k8s.io      2020-05-31T05:19:06Z
updateinfos.nodemanagement.gke.io              2020-05-31T05:19:09Z
viewers.kubeflow.org                           2020-05-31T05:23:14Z
workflows.argoproj.io                          2020-05-31T05:23:14Z

非常に多くのコンポーネントがインストールされています。手動でのインストールは大変そうですね・・・。

実際、Kubeflowの公式インストール手順は多くのステップがあります。クラウドの恩恵を感じます。
https://www.kubeflow.org/docs/gke/deploy/

argo workflowsがインストールされており、kubeflow pipelinesのジョブはargoのジョブとして実際には起動されているようです。

サンプルジョブを動かす

いくつかのサンプルが用意されています。ドキュメントの通り、「[Tutorial] Data passing in python components」を動かします。

ビューからは、パイプラインの状況やログ、IN/OUTなどを確認できます。リトライやジョブ介ジューリグもあり、ジョブフローとして一通りのものは揃っており、完成度は高そうに感じます。単純にairflowの代替としての利用もありえるのではないかなと思いました。

あとはスケジュール実行ジョブの設定を、airflowのように一覧でみられるビューがあればなお良さそう。

サンプルジョブの中身を拝見

動かすだけではつまらないので、サンプルジョブのソースコードを見てみます。

kfpというPythonライブラリを利用して作られている。
具体的には、kfp.func_to_container_opというデコレータを利用して、関数をKubeflow pipelinesのコンポーネントとして登録している
上記をkfp.compiler.Compiler.compileすることで、これらのPythonコードをkubeflowで実行可能なyamlに変換している。
- Pythonコードはyamlの中にベタガキにする、Dockerイメージとしてまとめる、のオプションがある
DAGの依存関係については、パラメータの受け渡しから自動的に算出されてるぽいので、airflowのようにマニュアルに管理しなくて良いのがよさそう
今回のサンプルはkfpだけで完結していますが、tfxを使ってDAGを定義することもできるようです。機械学習モデルを作成するための様々な便利ライブラリが用意されているので、実運用ではtfxを多く利用することになりそうと感じました。
- https://github.com/kubeflow/pipelines/blob/9c16e12ba01962668b15fc19efa69b5ba78f618d/samples/core/iris/iris.py

まとめ

一旦はここまで。argo workflowsの力もあってか、ジョブフローエンジンとしての完成度がとても高く感じました。また、使いやすそうなSDKも良い。kubeflowのその他様々なコンポーネントとどのくらいシームレスに繋がれるのか確認してみたいと思います。

BigQueryベストプラクティス (パフォーマンス:2)

Atsumi — Thu, 21 May 2020 01:38:29 +0000

公式ドキュメントに記載のある「BigQuery best practices」をまとめてみるシリーズ。

今回はパフォーマンスのプラクティス後半をまとめます。

イタリック体はドキュメントに記載のない追加コメント

クエリの計算量に関するベストプラクティス

[原文](https://cloud.google.com/bigquery/docs/best-practices-performance-compute

If you are using SQL to perform ETL operations, avoid situations where you are repeatedly transforming the same data.

何度も同じ変換処理を繰り返す場合は、マテリアライズなどで効率化する。

Avoid using JavaScript user-defined functions. Use native UDFs instead

JavaScriptユーザー定義関数は避け、ネイティブのユーザー定義関数を使う。

JavaScriptユーザー定義関数はサブプロセスを起動するため、パフォーマンスインパクトがある。

If your use case supports it, use an approximate aggregation function

可能であれば近似集計関数を利用する

正確な値が不要ならば、APPROX_COUNT_DISTINCTやHyperLogLog（HLL_COUNT）のような近似集計関数を利用することでパフォーマンスを向上させられる。

Use ORDER BY only in the outermost query or within window clauses (analytic functions). Push complex operations to the end of the query

ORDER BYは、極力データを絞ったあとに利用しよう。

ソートはパフォーマンスに大きな影響を与えるが、クエリの最後や、window関数内にORDER BYを配置すれば効率化可能。
正規表現などの関数についても、データを絞った後に実施すればパフォーマンス向上が狙える。

For queries that join data from multiple tables, optimize your join patterns. Start with the largest table.

JOINをするときは、サイズの大きなテーブルを先に記述しよう

小さなテーブルが後にくると、効率の良いブロードキャストジョインが行われる。（小さなテーブルの全データを各スロットにばらまくためシンプル）
これに関してはオプティマイザーが効くこともあるが、今のところはユーザーも気をつけた方が良い。

When querying a partitioned table, use the _PARTITIONTIME pseudo column to filter the partitions

パーティション分割テーブルにクエリをするときは、_PARTITIONTIMEカラムでフィルタをする

クエリのアウトプットに関するベストプラクティス

[原文」(https://cloud.google.com/bigquery/docs/best-practices-performance-output)

Avoid repeatedly joining the same tables and using the same subqueries

繰り返しのJOINやサブクエリは避ける

JOINが繰り返し必要ならば、ネストされたフィールドを利用することで非正規化をすることでパフォーマンスが向上できる
同じサブクエリが複数回登場する場合、マテリアライズすることでパフォーマンスが改善できる。ストレージコストはかかるが、多くの場合はパフォーマンス改善効果がコストを上回るはず。

Carefully consider materializing large result sets to a destination table. Writing large result sets has performance and cost impacts

大きなサイズの結果セットを作る場合は、コストとパフォーマンスに注意しよう。

BigQueryはだいたい10GBの結果キャッシュを持っているが、大きな結果セットを生み出してしまうと容易にその制限を超えてしまう。
大きすぎると Response too large というエラーにより失敗してしまう。
回避するプラクティス
- WHEREなどにより、結果セットを適切に小さくする
- LIMITを利用して結果セットを小さくする。ORDER BYを利用するときにも効果がある
- 結果セットをテーブルに書き込む
大きすぎる結果セットをテーブルに書き込む場合、パフォーマンスやコストへのインパクトがある。有効期限を設定することで、大きすぎるテーブルが残らないようにするのも良い。

If you are sorting a very large number of values, use a LIMIT clause.

大きな結果セットをソートする場合、LIMITを利用する。

ORDER BYはResource exceededエラーを発生させることがある。これは、ORDER BYは最終的には1スロットでソート処理を実施しなければならないが、結果セットサイズが1スロットへの割り当て上限をオーバーしてしまうため。
上記は、LIMITを利用することで回避可能

SQLアンチパターン

原文

以下のSQLアンチパターンを避けることで、パフォーマンス向上が狙える。

Avoid self-joins. Use a window function instead.

セルフジョインは避け、可能な限りwindow関数を利用する。

セルフジョインはレコード数が２倍に膨れ上がり、パフォーマンス劣化につながる

If your query processes keys that are heavily skewed to a few values, filter your data as early as possible

特定のキーにデータが偏っている場合、できるだけ早くデータをフィルタリングする

スロット間でパーティションを共有することはできないため、特定のパーティションサイズが大きくなると、それが原因で遅くなったり、resource exceeded エラーになってしまう。
例えばユーザーテーブルで、匿名ユーザーを同じIDで登録している場合、匿名ユーザーIDのレコードが圧倒的に大きくなる
query planをみた時に、avgとmaxが大きく乖離している場合はこの事象が発生している可能性がある。
APPROX_TOP_COUNT を利用することでこの事象が起きているか確認できる。
JOINした結果、各キーのデータの偏りが出ることもあるため、事前にフィルタリングするなどをした方が良い。

Avoid joins that generate more outputs than inputs. When a CROSS JOIN is required, pre-aggregate your data.

インプットよりも大きなアウトプットを生み出すクエリを避ける。

CROSS JOINをする場合は事前に集計をすることでデータ量を減らす。
GROUP BY やWindow関数を利用してデータ量を減らす

Avoid point-specific DML statements (updating or inserting 1 row at a time). Batch your updates and inserts

DMPクエリを実行する場合は、１行ずつではなくまとめて行う。

１行ずつの更新が必要な場合、BigQueryは用途にあっていないのでCloudSQLなどOLTPに向いたものを利用する。
もしくは、ストリーミングインサートを利用する。
ステートメントのサイズにも制限があるので、大量のUPDATEがある場合は、１行ずつクエリを並べるのではなくまとめて更新されるようなクエリを書く。

BigQueryベストプラクティス (パフォーマンス:1)

Atsumi — Thu, 30 Apr 2020 01:15:23 +0000

公式ドキュメントに記載のある「BigQuery best practices」をまとめてみるシリーズ。

今回はパフォーマンスのプラクティスをまとめます。

イタリック体はドキュメントに記載のない追加コメント

ベストプラクティス

データソースに関するベストプラクティス

原文

Control projection — Query only the columns that you need

SELECT *を避けようという話。既出のため割愛。

When querying a partitioned table, use the _PARTITIONTIME pseudo column to filter the partitions

分割テーブルは _PARTITIONTIME 列でフィルタをする。

BigQuery performs best when your data is denormalized

スキーマの非正規化を行う。

正規化によるストレージ容量の節約効果は薄い
正規化してJOINする場合、通信等のオーバーヘッドがあるが、非正規化する場合は個別のスロットで並列化されるためパフォーマンスが向上する。
非正規化した上でリレーションを保つには、nested field（REPEATEDやSTRUCT）を利用する。
ただし、以下のような場合は非正規化を避ける
- スタースキーマにおいてディメンジョンの変更頻度が高い
- OLTPとしての利用（そもそもBigQuery自体が適していないと思うが）

If query performance is a top priority, do not use an external data source

パフォーマンスが大事なら、外部データソースは利用しない。

Cloud StorageやGoogle Driveをデータソースとして利用できるが、BigQueryにデータを格納するよりもパフォーマンスは悪くなる
外部データソースは以下のケースで利用する
- ETL
- 頻繁に変更されるデータ
- 定期的なデータ取り込み

When querying wildcard tables, use the most granular prefix possible

複数テーブルに対してワイルドカードを用いたクエリをする場合は、できる限り絞り込んだ表現を利用する。

例えばdata_2010のような末尾が年度になっているテーブルがあるとして、2010年台のデータのみが欲しいのであれば、FROM data_201*は、FROM data_*よりも対象テーブルが少ないため好ましい。

スロット間のデータ移動（shuffle）に関するベストプラクティス

原文
中身は少しタイトルとあっていないかも。JOINとシャーディングの話が中心

Reduce the amount of data that is processed before a JOIN clause

JOINの前に、データ量を削減する

JOINはshuffle（データの移動とマージ）が行われるため、shuffleが実行される以前にデータ量をwhere区などで削減することでパフォーマンス改善につながります。

Use WITH clauses primarily for readability

With句はリーダビリティのためだけに利用する。マテリアライズされるわけではないので、参照するたびにクエリが実行されます。

Do not use tables sharded by date (also called date-named tables) in place of time-partitioned tables

日付ごとにテーブルを作るのではなく、パーティション分割テーブルを利用する。

日付ごとにテーブルを作るアプローチは、以下のオーバーヘッドがある。
- 個別のテーブルごとにメタデータを保持する
- クエリ実行時に個別のテーブルごとに権限を確認する必要がある
_ちなみに、日付分割されたテーブルで、読み込むテーブルを緻密に絞るには_TABLE_SUFFIX擬似列を利用する。

Avoid creating too many table shards. If you are sharding tables by date, use time-partitioned tables instead.

１個上で紹介したものと同じ。)

BigQueryベストプラクティス (コスト管理)

Atsumi — Thu, 23 Apr 2020 01:36:35 +0000

公式ドキュメントに記載のある「BigQuery best practices」をまとめてみるシリーズ。
今回はコスト管理のプラクティスをまとめます。

イタリック体はドキュメントに記載のない追加コメント

TL;DR

SELECT *ではなく、必要なカラムのみを指定することで、読み込むデータ量を減らす
データを試しに見たいだけならpreviewr利用する。
クエリ実行前にコストを確認する
LIMIT句ではコストを絞ることができない。
請求データを可視化しコストを管理する
パーティショ分割テーブルを利用する
複数のステージがあるクエリ（SELECTした結果を別のクエリで参照するなど）は中間結果を保存する
サイズの大きなテーブルを作る時は、有効期限を設定する。
ストリーミングインサートはすぐに利用したいデータにのみ利用する。

ベストプラクティス

Query only the columns that you need.

SELECT *ではなく、必要なカラムのみを指定することで、読み込むデータ量を減らす

全カラムに対してフルスキャンが行われる
データを実験的に眺めたいだけならpreviewやbq headを利用しよう
LIMITでは読み込むデータ量を減らすことはできない。LIMITなくてもLIMIT 1でも全く同じデータ量が処理される。INFORMATION_SCHEMA.JOBS_BY_XXX.total_bytes_processedで確認可能。
SELECT * EXCEPT(...)は有効なので、一部のカラムのみ除外したい場合は利用しよう
行を絞って全カラムを読み込みたい時は、そのサブセットのみを持った新しいテーブルを作るか、パーティション分割テーブルを利用しよう

Don't run queries to explore or preview table data.

データを試しにみるのならpreviewr利用する。
（既出のため割愛）

Before running queries, preview them to estimate costs.

クエリ実行前にコストを確認する

BigQueryコンソールは、処理予定のデータ量をクエリ実行前に表示してくれる
CLIならbq query --dry_runで取得可能
データ量からコストを計算するには、Pricing Calculatorが利用可能

Use the maximum bytes billed setting to limit query costs.

Maximum bytes billedを指定することで高額なクエリ実行を抑制する

Maximum bytes billedを設定すれば、それ以上のデータ量を処理するクエリは実行できなくなるので、意図せぬ事故を防ぐことができる。

Do not use a LIMIT clause as a method of cost control.

LIMIT句ではコストを絞ることができない。
（既出のため割愛）

Create a dashboard to view your billing data so you can make adjustments to your BigQuery usage. Also consider streaming your audit logs to BigQuery so you can analyze usage patterns.

ダッシュボードでコストを管理する

請求データをエクスポートして、BigQueryにロードすることでコストダッシュボードを作ることができる
データ量の監視であれば、 INFORMATION_SCHEMA.JOBS_BY_XXX.total_bytes_processedを事前準備なしで使える。

Partition your tables by date

パーティショ分割テーブルを利用する
（既出のため割愛）

If possible, materialize your query results in stages

複数のステージがあるクエリ（SELECTした結果を別のクエリで参照するなど）は中間結果を中間テーブルに保存する

複数のステージがあるクエリ（SELECTした結果を別のクエリで参照するなど）の場合、毎回全クエリが実行される。
効率化するには、中間結果テーブルを作る

If you are writing large query results to a destination table, use the default table expiration time to remove the data when it's no longer needed.

サイズの大きなテーブルを作る時は、有効期限を設定する。

クエリだけでなくストレージにもコストが発生するので、一時的にしか利用しない大きなテーブルには有効期限を設定する。

Use streaming inserts only if your data must be immediately available

ストリーミングインサートはすぐに利用したいデータにのみ利用する。

LOAD jobによるデータロードは無料で実行可能だが、ストリーミングインサートには費用が発生する。

Data Catalog Tagについて調べた（2020/04/10）

Atsumi — Sun, 12 Apr 2020 15:53:24 +0000

調査の意図

カラムの統計値など、メタデータの拡充と管理がしたい
LyftのamundsenやLinkedinのdatahubのようなものはデカすぎるかつ、将来的にはGCPのData Catalogが同等の機能を有するので、できれば避けたい
- コチラに詳しくまとめられていた。ありがたい
data catalogのtagを使うと任意のメタデータを設定できそうなので調べてみる

Tag template

templateを作った上で、tableもしくはcolumnに付与する
複数のテンプレートを付与できる
テンプレートはあとでフィールド追加・削除可能
テンプレートはあとでREQUIRED制約を外すことが可能
- 逆は不可能
削除は、テンプレート付与済みのテーブル・カラムにも影響を与える
設定した値は、catalogの対象テーブル上でのみ閲覧可能。グラフ化などもないので、可視化はかなり弱い
APIで操作可能

一旦の結論

Data Catalogを、LyftのamundsenやLinkedinのdatahubのような本格的なメタデータ管理として使うのはまだ難しそう。
Data Catalogにメタデータを集中しつつ、メタデータクローラーとビューアを簡易なもので別建てで作るのが妥当か

GoogleのProfessional Data Engineer資格を取得するまでの記録

Atsumi — Thu, 26 Mar 2020 04:18:50 +0000

受験者（私）の経験値について

仕事でGCPを3年ほど利用している
主に利用しているのはGKE / GAE / Datastore / Cloud Storage / Firebase Realtime Database / Pubsub / CloudSQL / BigQuery / IAMあたり。
AWSも2,3年ほど経験しており、EMRでSparkジョブを利用したりk-meansを使った簡単な機械学習処理を経験
Spark Streaming、Kafka、HBaseあたりは検証で経験したくらい
Apache BeamはStrataに行った時に１日集中セッションみたいなやつを受けたのでなんとなくコンセプトは理解している

総じて、データを利用したアプリケーションには馴染みがある経歴です。とはいえ、ものすごく精通しているわけではないですし、ML系の経験は薄いです。

勉強期間

だいたい2週間くらい。
平均したら1日1,2時間程度？

試験概要

コチラ。
- https://cloud.google.com/certification/data-engineer?hl=ja
試験時間：2時間
問題：選択式で50問

今年に入って試験内容が若干変わったらしく、ケーススタディがなくなってます。（勉強期間中は古いページがまだ見える状態だったが、今は見えなくなっている）

勉強方法・内容

情報収拾

以下を眺めて概要を把握します。

公式サイト（上記）
過去に受験した方々が残してくれた記録

学習ツール

主に利用したのは以下。

qwiklab
公式ドキュメント
スケーラブルデータサイエンスデータエンジニアのための実践Google Cloud Platform
模擬試験

「courseraがいい」という情報もありましたが、私は利用しませんでした。
その代わり、qwiklabの1ヶ月サブスクリプションを利用しました。手軽に手を動かしながら学べそうだったからです。

qwiklabについて

30分〜90分くらいで終わる学習テーマが数多く用意されています。
サービスの基本や、サービスを組み合わせた発展的なものなど、様々なコースが用意されています。
- （例）「Cloud ML Engine: Qwik Start」
利用を開始すると、そのコースの制限時間だけ有効になるGCPアカウントが発行されますので、実際に手を動かしながら学ぶことができます。

私はMonthly Subscriptionのプラン（$55）を利用しました。最初はサブスクの存在に気づかず、コースごとに料金を払っていたので勿体無いことしました・・。

qwiklabで利用したコース

実際に動かしながら学べるのは良いですね！Dataprepはすげーなと思いました。

公式ドキュメント

各サービスの「コンセプト」の欄をしっかり読み込む。（これ一番大事かも）
サービス同士・機能同士の比較をきっちり理解しておく。
実際にどのように利用するかイメージを作るためにユースケースを見ておく。
- データライフサイクル
- 小売業向けのリアルタイムインベントリシステムの構築
- その他、このページから色々探せます

スケーラブルデータサイエンスデータエンジニアのための実践Google Cloud Platform

GCPの細かい使い方を解説した本ではないのですが、データを収集し、分析し、システムに組み込む、という一連の流れをGCPのスタックを利用して行うという内容であるため、実際にどう使うのかのイメージが付けれると思います。
受験対策としてはマストではないと思いますが、データ活用を学ぶ上で非常に良い本です。

模擬試験

https://cloud.google.com/certification/practice-exam/data-engineer?hl=ja

20問の模擬試験が受けられます。
本試験に比べると簡単です。
終了後、回答ともに参考リンクを示してくれます。

私は勉強を始めた頃に行い、半分ちょっとくらいの正解率でした。

試験当日

30分前には会場についているようにしましょう
- 周囲から慎重さに定評のある（はず）の私ですが、電車を乗り間違えるという失態を犯しましたw
- 早めに到着するスケジュールで動いていたため、ことなきを得ました。慣れない場所に行くときは気をつけましょう。
身分証や受験者IDを忘れないようにしましょう
持ち込みは一切できません
問題は結構細かいことも聞かれて難しかったです。絶対の自信を持って回答できたのは半分ちょっとくらい。全然検討つかない、という問題はほぼなかったです。
秋葉原の試験センターには、雑音シャットアウト用のヘッドホンがありましたが、サイズがきつく頭が痛くなったので外しました
試験終了後、すぐに「合格」という結果が出ました。3日後くらいにメールでも来ました。
景品としてパーカーかリュックが頂けるようですが、パーカーは在庫切れでした。

以上です！