Atsushi2022の日記

データエンジニアリングに関連する記事を投稿してます

SQL Zooを試してみた ~ More Join

SQL

概要

SQL ZooのMore Joinセクションの難しめの問題の結果のみをメモ。

時間のあるときに他の人の回答と比較してみたいと思う。

10. 1962映画の主演者

SELECT title, name
FROM movie
JOIN casting ON movie.id = movieid
JOIN actor   ON actor.id = actorid
WHERE ord = '1'
  AND yr = '1962'

11. ジョン＝トラボルタが多忙の年

SELECT yr, count(title)
FROM movie
WHERE id IN (SELECT movieid 
             FROM casting
             WHERE actorid = (SELECT id FROM actor WHERE name = 'John Travolta')
            )
GROUP BY yr
HAVING count(title) >= 2

12. ジュリー＝アンドリューズ出演映画

SELECT title, name
FROM actor
  JOIN casting ON actor.id = actorid
  JOIN movie ON movieid = movie.id
WHERE ord = 1 
  AND movieid IN (SELECT id
                  FROM movie
                    JOIN casting ON id = movieid
                  WHERE actorid = (SELECT id FROM actor WHERE name = 'Julie Andrews' )
                  )

13. 主演30本の役者達

SELECT name 
FROM actor
  JOIN casting ON id = actorid
GROUP BY name
HAVING count(movieid) >= 30
ORDER BY name

14. 1978年の映画

SELECT title, count(actorid)
FROM movie
  JOIN casting ON id = movieid
WHERE yr = '1978'
GROUP BY title
ORDER BY count(actorid) DESC, title

15. アート＝ガーファンクルと一緒に

SELECT DISTINCT name
FROM casting
  JOIN actor ON actorid = id 
WHERE movieid IN (SELECT movieid
                  FROM casting
                  WHERE actorid = (SELECT id FROM actor
                                   WHERE name = 'Art Garfunkel' )
                 )
AND actorid <> (SELECT id FROM actor
                 WHERE name = 'Art Garfunkel' )

AirflowがわからなかったのでUdemyで勉強してみた②

Airflow

概要

UdemyのAirflow講座で勉強したことのメモ。

この記事では主に事前設定やコードについて記載。

（事前準備）Dockerが重たいので、Airflow Standaloneで乗り切る

Udemyの講座ではDockerを使って、AirflowだけでなくPostgresSQLなどのコンテナも動かすので、自分の貧弱なPCスペックではメモリがいっぱいになってしまった。

そこで、Airflow Quick Startで利用したairflow standalone コマンドで余計なリソースはいっさい起動しないようにした。

だが、講座で扱うコードの中で、PostgreSQLが登場するので事前にPostgreSQL自体や、PostgreSQL Providerをインストールしておく。

# PostgreSQLをインストール 
sudo apt install postgresql

# libpq-devをインストール
# ！！注意！！：これをインストールしておかないと、PostgresSQLプロバイダーのインストールに失敗した
sudo apt install libpq-dev

# PostgresSQLプロバイダーをインストール
pip install apache-airflow-providers-postgres

# PostgresSQLを起動
sudo service postgresql start

# ユーザー「postgres」になる
sudo -u postgres -i

# PostgreSQLに入る
psql

#  DB「airflow_db」を作成
CREATE DATABASE airflow_db;

PostgreSQLの参考コマンドはこちら。こちらを参考にしてDBが作成されていることを確認する。

qiita.com

Airflow UIでConnectionsの設定

Airflow UIでConnectionsの設定をする。

PostgreSQLの接続情報

上記で作成したPostgreSQLのユーザー、パスワード、DB（Schema）を設定

HTTPの接続情報

Udemy講座内で設定したものとは異なるAPIエンドポイントを使ってます。

Airflowのコードを書く

~/airflow/dags配下にuser_processing.pyを作成する。5分以内にAirflow UIのDAGs viewに表示される。

コードの説明は、コード内のコメントを参照のこと。

user_processing.py

from airflow import DAG
from airflow.providers.postgres.operators.postgres import PostgresOperator
from airflow.providers.http.sensors.http import HttpSensor
from airflow.providers.http.operators.http import SimpleHttpOperator
from airflow.operators.python_operator import PythonOperator
from airflow.hooks.postgres_hook import PostgresHook
from datetime import datetime
from pandas import json_normalize
import json

# タスクの持っている属性値を取り出すには引数にtiと記述する（詳細はよくわかってません）
def _process_website(ti):
    # XCOMでタスク間でメッセージをやり取りする
    # タスク"extract_website"の値を受け取る
    users_from_website = ti.xcom_pull(task_ids="extract_website")
    users = users_from_website[0]
    # JSONに編集する
    processed_user = json_normalize({
        'firstname': users['name'],
        'lastname': users['username'],
        'country': users['address']['city'],
        'username': users['username'],
        'password': users['username'],
        'email': users['email'] })
    # CSVファイルに書き込む
    processed_user.to_csv('/tmp/processed_website.csv', index=None, header=False)


def _store_user():
    # PostgresHookで、CSVファイルから取り出したデータをPostgreテーブルにコピー
    hook = PostgresHook(postgres_conn_id='postgres')
    hook.copy_expert(
        sql="COPY test_table FROM stdin WITH DELIMITER as ','",
        filename='/tmp/processed_website.csv'
    )


# DAGを定義する
# 'user_processing'はDAGのID。Airflowのクラスター内でユニークでなければならない
with DAG('user_processing', start_date=datetime(2022,9,28), schedule_interval='*/1 * * * *',catchup=False) as dag:

    # task_idはDAG内でユニークでなければならない
    # PostgresOperatorでPostgreSQLに接続し、SQLを実行する
    # PostgreSQLの接続情報はAirflow UI上のConnectionsで定義しておく
    # postgres_conn_idで設定した値がConnectionsの識別子となる
    create_table = PostgresOperator(
        task_id="create_table",
        postgres_conn_id="postgres",
        sql='''
            CREATE TABLE IF NOT EXISTS test_table (
                firstname TEXT NOT NULL,
                lastname TEXT NOT NULL,
                country TEXT NOT NULL,
                username TEXT NOT NULL,
                password TEXT NOT NULL,
                email TEXT NOT NULL
            );
        '''
    )

    # HttpSensorはAPIエンドポイントが稼働しているかチェックする
    # HTTPのエンドポイント情報はAirflow UI上のConnectionsで定義しておく
    is_api_available = HttpSensor (
        task_id="is_api_available",
        http_conn_id="user_api",
        endpoint=""      # APIエンドポイントのパスを記述する。今回はパス指定なし
    )

    # こちらのSimpleHttpOperatorではAPIエンドポイントに対してGETした結果をresponse_filterに格納している
    # response_filterでは格納する前に処理できる。ここではJSONに変換している
    extract_website = SimpleHttpOperator(
        task_id="extract_website",
        http_conn_id="user_api",
        endpoint="", # エンドポイントURLのパスを指定する
        method="GET",
        response_filter=lambda response: json.loads(response.text),
        log_response=True
    )

    # PythonOperatorを使って、関数_process_website()を呼び出している
    process_website = PythonOperator(
        task_id='process_website',
        python_callable=_process_website
    )

    # PythonOperatorを使って、関数_store_user()を呼び出している
    store_user = PythonOperator(
        task_id='store_user',
        python_callable=_store_user
    )

    # タスクの実行順序を>>を使って定義している
    create_table >> is_api_available >> extract_website >> process_website >> store_user

AirflowがわからなかったのでUdemyで勉強してみた

Airflow

概要

AirflowのTutorialをやっても、短時間で理解できなさそうだったのでUdemyの講座を試してみました。 英語の講座だったのでちょっとしんどかったので、半分くらいのとこまでしかやってません。 超初歩はなんとなくわかりました。

https://www.udemy.com/course/the-complete-hands-on-course-to-master-apache-airflow

と、いうことで以下ざっくりメモ。理解間違ってたらすみません。

コードは別記事にします。

Airflowのええとこ

  • 全部Pythonで書ける（XMLとか出てこない）
  • スケーラブル
  • UIが良い
  • プラグインで拡張できる

コンポーネント

コアコンポーネントは以下の４つ。

  • Webサーバ：AirflowのUI。Flaskで出来ている。
  • Scheduler：タスクをWorkerに渡す
  • Metastore：SQL AlchemyとコンパティブルなDBであればOK。たとえば、Postgres、MySQL、Oracle DB、SQL Serverなど。メタデータストアには、データパイプラインやタスク、Airflowユーザなどのメタデータが保存される。
  • Triggerer：Triggererは特定のタスクを実行する。詳細は後程。

それ以外のコンポーネント。

  • Executor：K8sクラスタであればK8s用のExecutorが必要だし、Celery(*1)であればCelery用Executorが必要。
  • Queue:：タスクを入れておくためのキュー
  • Worker：タスクを実行する

(*1)：Celeryは分散処理のPythonフレームワークらしい。

Airflowで登場する概念

  • Workflow：DAG、オペレーター、タスクをまとめた概念がワークフロー。ワークフローは1つ以上のDAGから成る（たぶん）。
  • Task / Task instance： Taskは、Operatorを実行する際の呼び名。Task instanceは、よくわからないけれど、Taskが処理されたときに実体化する？
  • Operator：オペレーターには次の3種類がある。
    • Actionオペレーター：例 BashOperator
    • Transferオペレーター：データの移転を行う。例えばMySQLからRedshiftへのデータトランスファーなどを行う。
    • Sensorオペレーター：処理をするのを待ってくれる。例えば、ファイル処理を待つFileSensorなどがある。
  • DAG：タスク間の順序を定義する。

各種アーキテクチャ

シングルノードアーキテクチャ

  • 1つのマシン上でAirflowを動かす最もシンプルなアーキテクチャ。
  • タスクは、マシンのプロセスによって処理される。

マルチノードアーキテクチャ

  • 本番環境ではこちらを使う。冗長性があり、大規模なワークロードも実行できる。
  • マルチノードで処理させるために、CeleryやK8sを使う。
  • 1つ目のノードにはWebサーバ、SchedulerとExecutorがあり、２つ目のノードにMetastoreとQueueがある。さらにWorkerノードがある。
  • ExecutorがタスクをQueueに入れて、各WorkerノードがQueueからタスクをプルする。
  • Celery Executorの場合、QueueにはRabbit MQかReddisを使う。
  • Celery Workerノードは、airflow celery workerコマンドで起動できる。

Airflowの動作

  • SchedulerがDAGを起動すると、RunningステータスのDAG Runオブジェクトが作成される。
  • DAG Runオブジェクトが最初のTaskを実行すると、そのTaskがTask Instanceオブジェクトになる。
  • Task InstanceオブジェクトはまずNoneステータスだが、すぐにScheduledステータスになる。
  • その後、SchedulerがTask InstanceオブジェクトをExecutorのQueueに送る。
  • Queueに追加されたTask InstanceオブジェクトのステータスはQueuedになる。
  • そして、Executorがタスクを実行するためにサブプロセスを作成する。
  • すると、タTask InstanceオブジェクトはRunningステータスになる。
  • タスクが完了すると、Task InstanceオブジェクトのステータスはSuccessまたはFailedとなる。
  • そして、Schedulerは実行すべきタスクがないかを確認して、もしタスクがない＝DAGが完了している場合には、DAG RunオブジェクトがSuccessステータスになる。
  • Web UIでDAG RunオブジェクトとTask Instanceオブジェクトのステータスを確認できる。

DAG Runのステータス遷移

Running → Success / Failed

Task Instanceオブジェクトのステータス遷移

None → Scheduled → Queued → Running → Success / Failed

Airflowコードの配置場所

  • Airflowのコードを.pyファイルで作成したら、dagsフォルダに格納する。
  • 但し、~/airflow/dagsフォルダに入れても、すぐにはAirflow UIに反映されない。
  • Schedulerは5分間隔でDAGフォルダを確認して、.pyファイルがあればパースし、Airflow UIに反映する。
  • また、Schedulerは30秒間隔でファイルの修正をパースするので、Airflow UIに反映されるまで最大で30秒要する。

Airflow UI

各Viewで確認できることについて説明する。

DAGs view

  • トグル：DAGの開始、停止
  • DAG名
  • タグ
  • オーナー
  • Runsステータス：DAG Runsオブジェクトのステータス
  • Schedule：cron風の起動時刻設定（※ Cronとは意味合いが違うので要注意）
  • Last Run：最後にDAGを実行した時間
  • Next Run：次回にDAGを実行する時間
  • Recent Tasks：実行したタスクのステータス
  • Actions：DAGの開始、DAGメタデータの削除
  • Links

Landing view

  • DAG実行に要した時間を日次でプロットしている。
  • DAGの実行時間をどの程度短くなったか（あるいは長くなったか）を評価できる。
  • 例えば、ワーカーインスタンスを増やした結果、どれくらい要した時間が減少したかを確認できる。

Gantt view

  • タスクごとにどれくらい時間を要したかをガントチャート形式で表示。
  • タスクが時間的に重なって実行されている時は、並列処理されていることを示している。
  • ガントチャートが直列処理しているように見える場合には、並列処理になるよう修正が必要。

Code view

  • DAGのコードを表示。
  • 修正したコードが反映されているか確認する。

Graph view

  • タスク間の依存関係がわかる。
  • タスクの枠の色からタスクの実行結果がわかる。

DAG (Directed acyclic graph) 用語

  • Node：タスクを意味する。
  • Edge：タスク間の依存関係を意味する。

Operatorを定義する際の注意

処理とOperatorを1対1で対応させる。

例えば、データクリーニングとデータ加工を同じ1つのPythonオペレーターで処理しようとする場合、データ加工が失敗したのでリトライしようとするが、オペレーターにはデータクリーニングも含まれているので、リトライ時にデータ加工だけでなく処理が成功済みのデータクリーニングも再度実行してしまう。

Providerについて

Airflowはモジュラー・アーキテクチャになっている。

Airflowをインストールした段階では、PythonオペレーターやBashオペレーターといった主要なオペレーターしかインストールされない。

例えば、AWSのオペレーターを利用したい場合には、Amazonプロバイダーをインストールする必要がある。

利用したいプロバイダーをそれぞれインストールしていく。

どんなプロバイダーがあるかは、以下を参考にすると良い。

https://registry.astronomer.io/

Connectionsについて

DBなどの接続情報はAirflow UI上で登録できる。

Airflow UIのAdminタブからConnectionsを選択し、新しく接続情報を登録する。

Sensorについて

Sensor関連の重要パラメータ

poke_interval

  • デフォルトで60秒間隔でSensorが条件を満たしているかチェックする。

timeout

  • デフォルトで7日間に設定されている。7日間待機しても条件を満たさない場合はFailedとなる。

Sensorの例

HTTP Sensor：APIが稼働しているかどうかをチェックする。

Hookについて

外部との接続を抽象化して、簡易に接続ができるようにしてくれる。

オペレーターで接続できない場合は、Hookで接続できないか確認してみるのがよい。

タスク間の依存関係の指定

>> または << を利用して表す。

extract_website >> process_website >> store_user のような感じ。

    extract_website = SimpleHttpOperator(
        ...
    )
 
    process_website = PythonOperator(
        ...
    )
 
    store_user = PythonOperator(
        ...
    )
 
    extract_website >> process_website >> store_user

あるいは、set_upstreamとset_downstreamを使う。

DAGを分岐させるにはBranch Operatorを利用する。こちらを参照のこと。

DAGのスケジュール

DAGを2分間隔で実行したい場合は、/2 * * * のように記述する

dag = DAG("tutorial", ..., schedule_interval="*/2 * * * *")

Backfillingメカニズム

airflow dags backfillコマンドを利用すると、start_date以前の期間に対してDAGを実行してくれる。

Catchupメカニズム

catchup=Trueとすることで、start_date以降で実行していないDAG Runがあれば、遡って実行してくれる。

with DAG('tutorial',..., catchup=True) as dag:

コンフィグ

Executor等を変更するには、airflow.cfgコンフィグファイルの内容を編集する。

コンフィグファイルの内容は環境変数でオーバーライドできる。例えば、環境変数AIRFLOW__CORE__EXECUTOR で、Executorの設定を上書きできる。

Executorの種類

Sequential Executor

1つのタスクのみしか一度に処理できない

LocalExecutor

SQLLiteを使用していると、Sequential Executorしか使えない。

SQLLiteではなく、PostgresSQLやMySQLを使用することで、LocalExecutorを利用できるようになる。

LocalExecutorもSequentialExecutorと同じくWorkerは１つのみだが、マルチプロセスにより複数のタスクを並列で処理ができる。

つまり、LocalExecutorはスケールアップ（スケールアウトではない）により、より多くのタスクを並列処理できるようになる。

LocalExecutorを利用する場合は次のようにコンフィグを設定する。

executor=LocalExecutor
sql_alchemy_conn=postgresql+psycopg2://<user>:<password>@<host>/<db>

CeleryExecutor

Celearyを使って、複数のWorkerでタスクを処理する。

CelearyExecutorの場合、CelearyQueueというのがアーキテクチャのコンポーネントとして存在する。

このCeleary Queueには、BrokerとResultBackendという2種類のDB（？）が存在する。

BrokerはSchedulerからタスクを受け取って、それをWorkerに割り振る。

Workerで処理が終わったら、処理結果をResultBackendに保存する。

CelearyExecutorを利用する場合の設定は次の通り。

executor=CeleryExecutor
sql_alchemy_conn=postgresql+psycopg2://<user>:<password>@<host>/<db>
celery_result_backend=postgresql+psycopg2://<user>:<password>@<host>/<db>
celery_broker_url=redis://@redis:6379/0

豆情報

airflow.cfgでload_examples = Falseとすると、DAGの例がAirflow UIに表示されなくなる。

Sub DAG

【重要】SubDAGは複雑なので、Airflow 2.2で非推奨となった。SubDAGではなく、Task Groupを使う。

SubDAGで複数のタスクを1つのサブDAGとしてまとめることができる。

タスクを１つにまとめることで運用が楽になる。

Subdagを利用するには以下が必要。

  • dagsフォルダの配下にsubdagsフォルダを作成する。
  • subdagsフォルダ内に、.pyファイルを作成し、そこに関数を定義する。
  • 関数の引数はparent_dag_id, child_dag_id, argsの3つ。
  • 関数内にDAGを定義する
with DAG (f"{parent_dag_id}.{child_dag_id}", ...   ) as dag:
... 
return dag
  • メインとなる.pyファイルにSubDAGOperatorでSubDAGを呼び出す。

Task Group

  • dagsフォルダの配下にgroupsフォルダを作成する。
  • groupsフォルダ内に、.pyファイルを作成し、そこに関数を定義する。
  • 関数の引数は不要。
  • 関数内にTaskGroupを定義する
with TaskGroup ("task_group_id", tooltip="hogehoge") as group:
... 
return group
  • メインとなる.pyファイルで、定義した関数を呼び出す。

Airflowを試してみる ～ Quick Start

Airflow

AirflowのQuick Startを参考にして、WSL Ubuntu 20.04上にAirflowをインストールする。

以下はQuick Startからの抜粋。

# Airflow needs a home. `~/airflow` is the default, but you can put it
# somewhere else if you prefer (optional)
export AIRFLOW_HOME=~/airflow

# Install Airflow using the constraints file
AIRFLOW_VERSION=2.4.0
PYTHON_VERSION="$(python --version | cut -d " " -f 2 | cut -d "." -f 1-2)"
# For example: 3.7
CONSTRAINT_URL="https://raw.githubusercontent.com/apache/airflow/constraints-${AIRFLOW_VERSION}/constraints-${PYTHON_VERSION}.txt"
# For example: https://raw.githubusercontent.com/apache/airflow/constraints-2.4.0/constraints-3.7.txt
pip install "apache-airflow==${AIRFLOW_VERSION}" --constraint "${CONSTRAINT_URL}"

# The Standalone command will initialise the database, make a user,
# and start all components for you.
airflow standalone

# Visit localhost:8080 in the browser and use the admin account details
# shown on the terminal to login.
# Enable the example_bash_operator dag in the home page

airflow standaloneを実行した結果、airflow.cfg ファイルが作られる。

ls airflow/
airflow-webserver.pid  airflow.cfg  airflow.db  logs  standalone_admin_password.txt  webserver_config.py

airflow.cfg の先頭50行を抜粋。様々な変数に値が格納されている。環境変数を使用して、デフォルトの値をオーバーライドができるらしい。

You can override defaults using environment variables

変数の詳細やデフォルト値については構成リファレンスを参照する。

[core]
# The folder where your airflow pipelines live, most likely a
# subfolder in a code repository. This path must be absolute.
dags_folder = /home/bluen/airflow/dags

# Hostname by providing a path to a callable, which will resolve the hostname.
# The format is "package.function".
#
# For example, default value "airflow.utils.net.getfqdn" means that result from patched
# version of socket.getfqdn() - see https://github.com/python/cpython/issues/49254.
#
# No argument should be required in the function specified.
# If using IP address as hostname is preferred, use value ``airflow.utils.net.get_host_ip_address``
hostname_callable = airflow.utils.net.getfqdn

# Default timezone in case supplied date times are naive
# can be utc (default), system, or any IANA timezone string (e.g. Europe/Amsterdam)
default_timezone = utc

# The executor class that airflow should use. Choices include
# ``SequentialExecutor``, ``LocalExecutor``, ``CeleryExecutor``, ``DaskExecutor``,
# ``KubernetesExecutor``, ``CeleryKubernetesExecutor`` or the
# full import path to the class when using a custom executor.
executor = SequentialExecutor

# This defines the maximum number of task instances that can run concurrently per scheduler in
# Airflow, regardless of the worker count. Generally this value, multiplied by the number of
# schedulers in your cluster, is the maximum number of task instances with the running
# state in the metadata database.
parallelism = 32

# The maximum number of task instances allowed to run concurrently in each DAG. To calculate
# the number of tasks that is running concurrently for a DAG, add up the number of running
# tasks for all DAG runs of the DAG. This is configurable at the DAG level with ``max_active_tasks``,
# which is defaulted as ``max_active_tasks_per_dag``.
#
# An example scenario when this would be useful is when you want to stop a new dag with an early
# start date from stealing all the executor slots in a cluster.
max_active_tasks_per_dag = 16

# Are DAGs paused by default at creation
dags_are_paused_at_creation = True

# The maximum number of active DAG runs per DAG. The scheduler will not create more DAG runs
# if it reaches the limit. This is configurable at the DAG level with ``max_active_runs``,
# which is defaulted as ``max_active_runs_per_dag``.
max_active_runs_per_dag = 16

# Whether to load the DAG examples that ship with Airflow. It's good to
# get started, but you probably want to set this to ``False`` in a production

airflow.cfg の中にexecutor = SequentialExecutor という記述がある。SequentialExecutorというオプションでは、タスクをシングルインスタンスで実行するらしい。SequentialExecutor 以外にもLocalExecutor, CeleryExecutor, DaskExecutor, KubernetesExecutor, CeleryKubernetesExecutor といったExecutorが存在する。各Executorについては、Executor Types を参照してみるとよさそう。

今回は airflow standalone コマンドでAirflowサーバを起動したため、あくまでスタンドアロン、つまり SequentialExecutor となっている模様。

ちなみに、 airflow standalone コマンドでは、以下のコマンドをまとめて実行してくれているらしい。ざっと見る限り、DBを起動してユーザ作成し、ウェブサーバを起動してスケジューラーを起動しているっぽい。

DBは何に使っているのか？あとスケジューラーは何者？

疑問はいったん脇において、ウェブサーバに入ってみたいと思う。

airflow db init

airflow users create \
    --username admin \
    --firstname Peter \
    --lastname Parker \
    --role Admin \
    --email spiderman@superhero.org

airflow webserver --port 8080

airflow scheduler

ブラウザで http://localhost:8080/login/ にアクセスする。UsernameとPasswordは airflow standalone コマンドを実行したときに出力されていた値を利用する。以下のように出力されているはず。

standalone | Airflow is ready
standalone | Login with username: admin  password: kTBTQWBKZAP2S5Ns
standalone | Airflow Standalone is for development purposes only. Do not use this in production!

ログインすると、次のような画面が表示される。DAGがすでに40件登録されている。

GUI上で、example_bash_operator の▶ボタンをクリックして、DAGを実行してみる。DAGが実行されていることがわかる。

DAGの詳細を見てみる。example_bash_operator は何をやっているのだろう？よくわからない。。。

色々疑問が残ったがとりあえず先にすすもう。

次回は、AirflowのTutorialをやってみようと思う。

Terraform Associateに合格しました

Terraform Terraform Associate

本日（22年9月）、Terraform Associateに合格しました。

 

以前からTerraformを使いたいなと思って色々と試していましたが、試していると色々疑問がでてきて、これは一回体系的に勉強したほうが早いなと思い、せっかくなので試験を受けることにしました。

 

Terraformの本を読んだり、実際にTerraformを試していたこともあって、試験勉強は２週間ほど済みました。知識ゼロからの状態でも１～２か月くらいあれば合格できると思います。

 

主に試験勉強として行ったのはUdemyの動画視聴＆模擬試験受験です。Udemyの講義は英語なのでちょっと大変ですが、順を追って説明してくれるので内容はとてもわかりやすいです。ベストプラクティスとかも紹介してくれるので、実践にも役立ちそうです。ただ、ちょっと古い情報などもあり（例：Providerブロック内のversion引数は現在非推奨）、その辺りはUdemyの模擬試験でキャッチアップしました。

 

３か月前に一読した書籍も勉強になったので、記載しておきます。

 

Udemy

 

書籍

 

時間がなければスキップしても大丈夫です。一読するとUdemyの講義にスムーズに入れると思います。私が読んだときはKindle Unlimeted対象でしたが、どうやら今は違うようです。

 

 

WIN32APIを試したい

WIN32API C++

WIN32APIってなに？

Windows上で動作するアプリを作るには、.NETフレームワークを利用する方法と、WIN32APIを利用する方法の2通りがあります


Windowsプログラミングを行うためには、Windowsが提供している API を操作します。このAPIのことを、WindowsAPIと呼び、現在、WIN32APIとWIN64APIというものもあります


ウィンドウズ上のネイティブアプリを作成するには、通常C言語やC++言語といった言語を使用するケースがほとんどです。しかし、それら言語だけでは、ウィンドウの出力など、WindowsOS固有の処理を行うことができません。そこで必要となるのが、WIN32APIです。


Windowsプログラミングを行う際には、これら言語（注：C言語やC++言語）からWIN32APIを呼び出すことが必要になります。

WIN32APIについて、詳しくはこちらを参照のこと。

C++言語を利用するためコンパイラを準備

WIN32APIはC言語、C++言語で利用できる。今回はC++を利用する。

そこでC++を実行するため、以下を参考にしてMinGWを利用してgccコンパイラをインストールする。

2021年版 C言語/C++ 入門者のための環境構築 (Windows編) - LYNCSブログ

WIN32APIの実行

以下にあるWinMain.cppを実行したい。

一週間で身につくWIN32プログラミングの基本|第１日目：最も基本的なプログラム

そこでVisual Studio Codeでターミナルを開き、以下のコマンドでコンパイルする。すると、WinMain.exe という実行ファイルが出力される。

g++ -o WinMain .\WinMain.cpp

次に実行ファイルを実行する。

./WinMain.exe

プログラムの通り、OKボタンが配置されたメッセージボックスが表示される。 OKボタンをクリックすると、プログラムは終了する。

GCPのAssociate Cloud EngineerとProfessional Data Engineerに合格しました

GCP

GCPのAssociate Cloud Engineer（ACE）とProfessional Data Engineer（PDE）に合格しました。それぞれ22年8月と9月に受験して、無事一度で合格することができました。

 

勉強としては書籍とGoogle Cloudがパートナー会社向けに提供しているオンライントレーニングに加えて、Udemyの模擬試験を利用しました。試験に一番有効だったのは、Udemyの模擬試験でしたが、オンライントレーニングで実際にサービスに触れられたのが知識定着に役立った気がします。

 

学習の流れとしては、まず書籍2冊を一読して自分なりにブログ記事にまとめた後に、ACE、PDEそれぞれに対して、オンライントレーニング受講 → Udemyの模擬試験チャレンジという順番でした。要した時間は、ACEとPDEでそれぞれ1か月、合計で2か月です。ダラダラとやっていたので、集中してやればどちらも2週間くらいで合格できると思います。

 

試験はオンラインでもオフライン（テストセンター）でも受験できますが、オフラインがお勧めです。ACEの試験をオンラインでやったのですが、試験官が遠隔で試験状況をモニターできないということでトラブルシューティングに1時間半くらいかかりました。最終的にWindows PCを諦め、Macbookで受験したらなんとかいけましたが、結構きつかったです。

 

 

書籍

 

Google Cloudのパートナー向けオンライントレーニング

 

Udemy