Amazon Athena

このポストについて データ基盤移行について書いていくシリーズです。 シリーズ一覧はこちらから。 前回 Part 6. メタデータ編ではメタデータの運用開始と移行について書きました。 今回は最も苦労してようやく最近終わった ELT 処理の移行について記載します。 この移行については Part 3. アーキテクチャ編でも触れているのですが、今回はもう少し詳細に書きます。 ELT 処理の移行の概要 このデータ基盤移行では Amazon Athena を中心とした構成の旧データ基盤から、Databricks で構成された新データ基盤への移行を行いました。 ELT 処理まわりについて、移行前は Glue Job (PySpark) と Athena クエリを Apache Airflow から回すというような形になっていました。 移行後は処理エンジンは Databricks SQL に統一し、それを dbt から回すという形にしました。 なぜこうしたのかについては Part 3. アーキテクチャ編をご覧ください。 一方でそっちには書いていなかったのですが、table 間の依存関係の管理を Apache Airflow から dbt に変更することによってかなり開発・運用の手間が減ったという面があります。 Aiflow はいろいろなことができ、また UI も使いやすく worfklow orchestration の仕組みとして悪いものではありません。 しかし DAG 上で task 間の関係として依存関係を管理するのはそれなりに手間がかかります。 dbt の場合は下流 model の定義において {{ ref('upstream_model') }} のように上流 model 名を指定して参照するだけで依存関係を表現できます。 これはかなり楽でした。 ...

このポストについて このポストは Distributed computing Advent Calendar 2023 の3日目の記事になります。 1日目、2日目に続いて Apache Iceberg について書きますが、このポストでは Iceberg の実用例を書きます。 AWS DMS による CDC の結果を Apache Iceberg 形式にして Amazon Athena でクエリできるようにするという内容になります。 やっていることとしては Perform upserts in a data lake using Amazon Athena and Apache Iceberg | AWS Big Data Blog で紹介されている内容と近いですが、実務としての背景や工夫したところなどを書いていきます。 背景 私の所属する事業会社では日々プロダクトから様々なデータが発生しており、プロダクトの分析やレポーティング、ML など様々な用途で利用されている。 それを支える基盤としてデータ基盤が存在している。 データ基盤ではクエリエンジンとして Amazon Athena を使っている。 ストレージとしては S3 を使用しており、主に分析用として Parquet 形式でデータが置かれる。 ここに業務用の operational な database から日次でデータを取り込んでいる。 データソースは RDS (Aurora MySQL) であり、比較的大きなデータとなっている。 これまではこの RDS -> S3 のデータ取り込みには RDS の S3 snapshot export という機能を利用していた。 この機能では比較的簡単な設定により、バックアップ用のスナップショットの内容を S3 に export することができる。 ちなみに対象 database のスナップショットのサイズは数十 TB ある。 ...