gcp

GCPでAirflow をマネージドサービスで使えるサービスで Cloud Composer が存在する。 BigQueryやBigTable, PubSub などGCPの各サービスをDAGとして定義してジョブを定期実行できるので非常に便利だが、その代わりDAGを実行するまで結果がわからないので、CloudComposer を一度実行するしか無いのでデバッグが困難になる傾向がある。 また、GitHubのリポジトリにDAGを保存して、CIでCloud Composerを更新するようしていると PRを都度作ってマージされないと確認できないという場合もある。 ローカルでDocker で走らせれば良いのじゃないかというツッコミがあると思いますが、結局 Cloud Composer 上での動作を確かめないといけないので、今回の記事を書くことにしました。 NOTE: 自分が使用しているComposerのversionはcomposer-1.8.0-Airflow-1.10.3 です。基本的にやれることは一緒だと思います。また、dev, prodで同一のDAGが走るCloud Composer を運用しているという前提です。 アプローチは２つ logger.info() を仕込んで、DAGのなかで何が起こっているかを理解する 1 2 3 4 5 import logging logger = logging.getLogger(__name__) logger.info() loggerをDAGを記述した Pythonファイルに仕込んで、内部で何が起こっているかを把握する。 各DAGのlogは、 GCPのCloud ComposerのページにアクセスしてAirflow webserver 列のボタンをクリックしてAirflowのWeb applicaiton にログイン 確認したいDAGをクリック DAG内のtask をクリックして表示されるモーダル内の View Logをクリックすると、loggerの情報が確認できる gstuil rsync コマンドでのGCSへのDAGの同期 gstuil rsyncコマンドを使うことで、リポジトリのDAGファイルをGCSに格納されている開発環境上のCloudComposer のDAGファイルに直接同期してPull Request マージ後のDAGの挙動を確認できる。 Cloud Composer のDAGは、自動作成されたGoogle Cloud Storage(GCS)に格納されており、GCSをCloud Composerが定期的に監視してCloud Composerを更新している。 つまり、GCS上のDAGファイルを直接更新してやるとそれがCloud Composerに反映される。 体感として2-3分に一度は監視されているので、ほぼ待ち状態がない状態で確認できて便利です。...

gcloud commands で PubSub に json ファイルをメッセージとして公開 (Pusblish) する jq コマンドが必要になるが、一番簡単に実現できるのは 1 $ gcloud pubsub topics publish {PUBSUB_TOPIC_NAME} --message "$(cat {FILE_NAME} | jq -c)" jq コマンドの -c オプションは compact-output を意味している。デフォルトだと pretty-prints になってしまう。 それを避けるために-cオプションを使用している。 ref Publishing messages to topics Read a txt file JSON data to publish the messages in Cloud Pub Sub

Python のアプリケーションで、Cloud logger にログを出力したいときに 標準の Python logging モジュールを利用して、ログを出力する Python Cloud Logging package を使用する 上記の２つの方法があります。 不必要にパッケージを増やしたくはないので、1 の標準モジュールで Cloud Logger へ出力できないか試してみました。 標準の Python logging モジュールを試す 標準の logging モジュールでログを出力したいときに 1 2 3 4 5 6 import logging logger = logging.getLogger(__name__) def hoge(): logger.info('logging Start 2021') と、logging.info() を仕込んで、Cloud logger にログを出力してみると、logger.info() で出しているはずなのに、Cloud logger 上ではすべてエラーとして扱われてしまっています。 原因を特定するために、logger のログを見てみると logger.info() がすべて stderr標準エラーストリームへ出力されてしまっています。 1 2 3 4 5 6 7 8 9 10 11 12 { "textPayload": "2021-02-20 21:26:51,012 - root:predict:36 - INFO: logging Start\n", ....

pandas.read_gbq 便利ですよね。 クレデンシャルファイルを認証画面からコピペすれば Jupyter Notebook 上で簡単に認証され、Google BigQuery が実行されてその結果がそのままデータフレームとして扱えます。 Jupyter Notebook と Google BigQuery を連携させたいときは愛用していました(過去形)。 問題点 そこそこ大きなデータを持ってこようとすると、めちゃくちゃ遅くてストレスが凄い 解決方法として、Google BigQuery で巨大なデータをダウンロードする方法について書きます。 実は Google の公式ドキュメントでも推奨されています。 https://cloud.google.com/bigquery/docs/pandas-gbq-migration https://cloud.google.com/bigquery/docs/bigquery-storage-python-pandas 方法は以下の２つ。 google-cloud-bigquery をインストールして、マジックコマンドで Google BQ を実行 BQ 実行 →BigQuery table として保存 →GCS へ保存 → gsutil でマシンへコピー 1 番目は、Jupyter 上でマジックコマンドで Google BQ が実行できて、速度も pandas.rad_gbq よりも高速です 2 番目はそもそも実行結果が巨大な場合で、目安としては1GB以上なら 2 番目の方法を使えば楽です。 1, google-cloud-bigquery をインストールして、Jupyter Notebook のマジックコマンドで Google BQ を実行 1 pip install --upgrade google-cloud-bigquery[bqstorage,pandas] magic command を実行...

1. Generate SSH config file using gcloud command line 1 gcloud compute config-ssh https://cloud.google.com/sdk/gcloud/reference/compute/config-ssh You cant get ssh config for your Google Compute Engine project! Notice: you need choose target GCP project before run below command. 1 gcloud config set project <your-project-id> 2. Install Remote SSH extention in Visual Studio Code. https://code.visualstudio.com/blogs/2019/07/25/remote-ssh 3. Press ⇧⌘P & Select target connection in Visual Studio Code! Finaly you can connect in Visual Studio Code....