PostgreSQLをIcebergレイクハウスの“入口”にする ~ pg_lakeを検証して分かったことメモ~
この記事は さくらインターネット Advent Calendar 2025 と Distributed Computing Advent Calendar 2025 の16日目の記事です。
12/16って言ったら12/16なんです。
今回は、この記事を読んで pg_lake に興味が湧いたので触ってみました。
では、始める前に、想定読者と前提は以下の通りです。
- Iceberg大好きっ子
- Docker Compose / Docker イメージ作成は一通り分かる人
- PostgreSQLを利用したことがある人
- pg_lakeは 1/22時点の
4bc1a58のものを前提とする - 実行環境は PC端末上のWSL2のUbuntu環境とする
ハンズオンでは、最終的に以下が出来る事を目指します。
- pg_lakeの実行環境をビルドする
- Docker Composeでpg_lakeを起動(S3互換ストレージには、さくらのオブジェクトストレージを利用)
- pg_lakeの外から、SparkとTrinoを使ってpg_lakeのIcebergテーブルを参照する
では、以下の目次の流れで進めていきます。
- pg_lakeの面白さ
- pg_lakeのざっくり全体像
- アーキテクチャ
- コンポーネント
- デカいIcebergテーブルを読んだら即OOMなんじゃ?
- PostgreSQLテーブルの型とIcebergテーブルの型の対応状況は?
- Icebergテーブルのメンテナンス
- ハンズオン
- 環境説明
- pg_lake環境の構築
- pg_lakeのイメージのビルド
- pg_lakeの外から接続出来るようにする
- オブジェクトストレージをlocalstackからさくらのオブジェクトストレージに変更する
- Docker Composeファイルの変更
- ケース0:Icebergテーブルを作成してみる
- ケース1:PostgreSQLとして内部的にIcebergテーブルを参照
- TrinoからPostgreSQLとしてpg_lakeに接続してクエリ
- SparkからPostgreSQLとしてpg_lakeに接続してSQLクエリ
- ケース2:Icebergカタログ(JDBC)としてSparkやTrinoからクエリ
- SparkからIcebergカタログとしてpg_lakeに接続してクエリ
- TrinoからIcebergカタログとしてpg_lakeに接続してクエリ
- ケース3:S3上のファイルを直接参照したり、テーブルをS3に吐く
- バケット上にあるParquetファイルをテーブルとして参照する
- ParquetファイルをIcebergテーブルにImportする
- Icebergテーブルのクエリ結果をS3に出力する
- ケース4:PostgreSQLってことはrollbackできるの?
- おまけ:もしかして、2PC(分散トランザクション)っていける?
- 使いどころ(ユースケース)を考えてみる
- 「PostgreSQL中心でやりたい」組織のレイクハウス基盤
- Iceberg 中心のデータ基盤に「PostgreSQLの窓口」を付けたい
- S3上のファイルを“そのまま”分析したい
- "軽量な"データパイプライン・ETLの代替
- 地理空間データのレイクハウス化
- 「開発向け運用分析」基盤
- pg_lake を“使わない方がいい”ケース
- 落とし穴と運用Tips
- 公式Docker Composeはdownしたら揮発する
- Iceberg JDBCカタログ互換は限定的
- 2PC不可(1PCのみ)
- Small FilesとVACUUM競合
- pgduck_serverはメモリ無限ではない
- まとめ
- 最後に
Spark Operator特集・2日目 ハンズオン編:kubeflow/spark-operatorでSparkアプリをK8sにデプロイする
この記事は Distributed Computing Advent Calendar 2025 の8日目の記事です。
今回は、 Spark Operator特集・1日目「まずはSpark on K8sのおさらい」 - やっさんメモ の続きです。
- Spark on Kubernetes を理解する(理解編) ※前回
- Spark Kubernetes Operatorを動かしてみる(実践編) ※今回の記事
始める前に、想定読者と前提は以下の通りです。
- kubectl / Helm / Docker イメージ作成は一通り分かる人
- Spark自体の基本は理解している人(前回 12/1記事を参照)
- 利用環境は2025/12時点での最新
- Spark
- https://github.com/apache/spark (対象バージョン: v4.0.1)
- Kubernetes Operator
- https://github.com/kubeflow/spark-operator (対象バージョン: v2.4.0)
- https://github.com/apache/spark-kubernetes-operator (対象バージョン:v0.6.0)
- Spark
ハンズオンでは、最終的に以下が出来る事を目指します。
- k3dでマルチノードのSpark用Kubernetesクラスタを立てる
- Spark OperatorをHelmで入れる
- 独自のSparkアプリをPySparkとしてKubernetes上で実行する
今回の実践編は、以下の目次の流れで進めていきます。
- Spark の Kubernetes Operator のおさらい
- Spark on K8s視点での利点
- SparkのKubernetes Operator視点での利点
- SparkのKubernetes Operatorのこれまで(歴史の話)
- kubeflow/spark-operator(元祖Spark Operator)
- kubeflow/spark-operatorを利用する際の大事なポイント
- Spark Operator専用のCLI sparkctl がなくなっている(過去から使っている人向け)
- Sparkアプリの再起動を設定を入れる
- 実行が終わったSparkApplicationを自動削除する設定を入れる
- S3を利用する場合の導入先に注意
- .spec.sparkConf と .spec.sparkConfigMap は同居出来ないので注意
- kubeflow/spark-operator を使ってSparkアプリを起動する
- 手元で起動するKubernetesクラスタをk3dで用意する
- Spark Operatorのインストール
- 本番を想定した場合の大事なポイント
- ハンズオン向けの簡単な設定でインストール
- Sparkアプリの起動
- PySparkアプリの起動
- Spark Connectを使ってクラスタの外からPySparkアプリを実行してみる
- まとめ
「実践 Apache Iceberg」と「Apache Iceberg活用入門」は両方「今」読むとお得な2冊。
全国に数多いるIceberg愛好家の皆さん、こんにちは。
この記事は Iceberg - Qiita Advent Calendar 2025 - Qiita の2日目の記事です。
今年も Open Table Format(以降、OTF)は盛り上がりを見せ、今年は特にバッチ領域のデータレイクから、ストリーミング領域への適用がより進んできました。
とりわけ国内は、Icebergに関する本が2冊出版されました。こちらの2冊について、著者・出版社から献本を受けました。
また、とても嬉しいことに「Apache Iceberg活用入門」については、翻訳レビューアとして貴重な機会を得ました。
本来は個別に紹介記事を書くのが筋なのかもしれないのですが、あえて1本の記事にしました。
私はIceberg自体は2023年4月頃からハマりだし、PoCから本番運用含め2年近くの経験を踏まえ、この2冊について、Iceberg 導入を検討中 または 導入済みで運用設計を強化したいデータエンジニア・プラットフォーム責任者向けに紹介していきます!
Spark Operator特集・1日目「まずはSpark on K8sのおさらい」
この記事は Distributed Computing Advent Calendar 2025 の1日目の記事です。
今年もアドカレの季節がやってきました🎄
今回は、Apache Spark(以降、Spark)のKubernetes Operatorについて取り上げます。
Sparkは大規模データ処理には欠かせないミドルウェアで、Apache Iceberg の実行エンジンとしても利用されています。また、SparkのKubernetes Operatorは、Kubernetes上でSparkジョブのデプロイ・管理・スケーリングを自動化するためのOperatorです。
他にもストリーム処理の実行エンジンの代表格の Apache Flink にも、Kubernetes Operatorはありますが、これについては去年取り挙げたので興味があれば参照ください。 yassan.hatenablog.jp
さっそくSpark の Kubernetes Operatorの話をする前に、以下の構成に分けて解説していきます。
- Spark on Kubernetes を理解する(理解編) ※今回の記事
- Spark Kubernetes Operatorを動かしてみる(実践編)
- k3d を使ってマルチノードの環境でSpark on K8sを手元で試してみる
では、理解編を始めていきます。
また、ここでは、 Sparkは、 v4.0.1 を前提とします。
- なぜ今Spark on K8sか?
- Sparkアプリケーションの仕組みについて
- Sparkアプリ=Driver × 1 + Executor × N の集合
- DriverやExecutorのリソースの管理は Cluster Manager にて行う
- デプロイモードは 2 種類
- 実行・監視まわりの基本
- 補足
- Spark on Kubernetesの仕組み
- Sparkアプリ開発者視点で整理する
- Kubernetesクラスタ管理者視点で整理する
- 本番運用を想定した場合の課題
- Sparkのカスタムコンテナイメージの作成がめんどい
- Spark on Kubernetes の「3 大ややこしポイント」
- ポイント1:Driver / Executor のサイズ決め(JVM と K8s の辻褄合わせ)
- TL;DR
- まず「合計メモリ」を合わせる
- ⚠️オマケ:CPUとメモリの値のフォーマットに注意
- 設定のしかたはユースケースで考える
- Executor サイズを決める際の指針
- Kubernetes 側は「QoS を落とさない」が基本
- 最低限これだけはチェックしておく
- ポイント2:Executor の数を人力で決めるのはやめたい(DRA)
- TL;DR
- Kubernetes で DRA を ON にするときの必須セット
- パターン1:ExecutorのDecommission + シャッフル追跡
- パターン2:ExecutorのDecommission + ShuffleDataIO
- Decommission は「縮退時のクッション」
- Stage Level Scheduling(SLS)は「使いどころ限定だけど強い武器」
- ポイント3:ESS無しでシャッフルとどう付き合うか
- TL;DR
- 3-1. まずは「デフォルト構成 + ちょっと厚め」の構成
- 3-2. 「シャッフルがとにかく重いジョブ」向けの厚め構成
- 3-3. さらに先:Celeborn / Uniffle などのRemote Shuffle Serviceを使う構成
- 複数のSparkアプリケーションリソースを良い具合に制御したい
- 次回予告:Kubernetes Operatorを使ったSparkアプリケーションのデプロイ
- まとめ と 次回予告
- 参考
シンプルってどっちの話してますか?
一言に「シンプル」と言った場合、どっちの話をしているのかを共有出来てないと、あさっての議論になるので、認識合わせが非常に需要。
自分でも見失っていたり、議論する際に認識合わせが出来てなくいて困ることがあるのでメモっておく。
ちょいちょい誰かがまとめてたりするけど、自分用のメモです。
TL;DR
単純化としてのシンプルさ
- 余分な情報を削ぎ落とし、“分かりやすさ”や“使いやすさ”を重視する
- マニュアル、UI、料理などで「簡素化」や「わかりやすさ」を追求する際に使われる
抽象化としてのシンプルさ
- 形や要素を削ぎ落として“本質を浮き彫りにする”
- ロゴデザイン、抽象画、ミニマル建築などで“洗練”や“エッセンスの強調”を目的に使われる
🐿️ Apache Flinkの最新事情とv2.0の話:RKE2で始めるFlink on K8s
この記事は MicroAd Advent Calendar 2024 と Distributed computing (Apache Spark, Hadoop, Kafka, ...) Advent Calendar 2023 の25日目の記事です。
12/25は終わってしまっていますが、、25日目の記事です。25日目といったら25日目なんです。
遅れた理由は色々とあるのですが、本題いきましょう1。
今回は、ずっとSpark Structure Streamingで良いんちゃう?って事で横目で見続けてきた、この子。

Flinkについてやっていきます。
Sparkは処理するデータの範囲が決まっているバッチ領域から発展して、常にデータが流れ込んでくるストリーム領域をマイクロバッチって観点で広げていった経緯があります。一方、Flinkはその逆で、ストリームからバッチへ対応領域を広げていった経緯があります。どこの世界もバッチもストリームもすべて対応する明るい未来(?)に向けて切磋琢磨しています。
今回はFlinkの話に触れてから、実際にKubernetesにはRKE2 2 を使ってクラスタをササッと用意してそこにFlinkの環境をいれてサンプル起動してみる流れでハマりどころを補足しながら紹介していきます。 うちはProxyがあってね、、、って方も大丈夫です。
前提(というか今回の環境)
- Ubuntu v22以降
- RKE2 (Kubernetes v1.31)
- Apache Flink v1.20
- Apache Flink Kubernetes Operator v1.10
- 前提(というか今回の環境)
- Flinkの最新情報とv2.0の話
- 今年のFlinkを振り返り
- Flink v2.0の話
- Breaking Changes
- ストリーミング機能強化:Disaggregated State Management
- Materialized Table
- Adaptive Batch Execution
- Streaming Lakehouse
- RKE2を使ってFlink on Kubernetesを始める
- RKE2でKubernetesクラスタの構築
- Control Plane(RKE2 Server Node)の構築
- Node(RKE2 Agent Node)の構築
- Kuibeconfigの準備
- Flink Kubernetes Operatorのセットアップ
- cert-managerのインストール
- S3に対応するためイメージを変更
- S3クレデンシャルの追加
- Flink Kubernetes Operatorのインストール
- Flinkジョブの実行
- RKE2でKubernetesクラスタの構築
- 最後に
-
言い訳
色々調べていくうちに面白くなって調べすぎて時間を結構そこに取られたのと、当初はZooKage使ってRancher Desktop環境にOzoneやHDFS立ち上げてS3バケットやHDFS用意して、そこにFlinkの環境を入れて、、とかやる予定だったんですが、、、記事書くためのブラウザ多数とDesktopのKubernetes環境だと、うちのマシンが非力すぎてメモリが足りなくなってしまい、Swap用意して逃したりもしたんですが、やってられんってことでやめました。。
Zookageはほんと簡単に手元で環境を簡単にスピンアップ出来るのでとっても便利なので、みんな使って欲しい。 kustomization.yaml で使わないものをコメントアウトして./bin/upするだけで立ち上がってきます。
ただし、Desktop環境を前提としてるのでPVCはローカルホストのパスを直接使ったりするのでDocker DesktopやRancher DesktopなどのDesktop環境以外ではそのまま使えないので注意です。
ブラウザ開き過ぎマンなのでメモリは32GBか64GBは欲しいですね。ブラウザでメモリごっそり持っていかれるのが辛い。。 zookage.github.io↩ -
Certified Kubernetes DistributionとしてCNCFに取り上げられている公式のKubernetesディストリビューション。流れさえ分かれば簡単にスピンアップ出来る便利なやつです(K3sも導入はだいぶ似てます)。Rancher必須でもないし、SUSEだからSUSEのOSじゃないとダメってこともないので安心して使って欲しい。
こまかい導入な話は2022のアドカレで記事にしてるのでそちらも是非、、
yassan.hatenablog.jp↩
お前はもうプロキシを突破している〜CI向きなK3dとK3sで始めるクラスタ構築〜
この記事は MicroAd Advent Calendar 2024 と Kubernetes Advent Calendar 2024 の4日目の記事です。
今回は、K3dをProxy環境下で利用する際にハマったのでその解消法について、 CloudNative Days Winter 2024 では、Rancherの中の人と勘違いされてたやっさんから紹介します。
(´-`).。oO( export HTTP_PROXY で終わりでは、、 )
って思うやん?違うんです。。。
では始めていきます。
はじめに
K3dは、Dockerコンテナ内でKubernetesの軽量版のK3sのクラスタをシングルノードまたはマルチノードで動かすためのツールです。K3sでKubernetesクラスタを構成することもあって省スペース&リソースで稼働するので、CIでシングルノードだけでなくマルチノードで構成したい際にオススメです(Helmチャートのテストとか)。
また、K3dで構築されるK3sクラスタにはローカルストレージプロバイダーが付属していてK3dコマンドを実行するノード時のローカルストレージをPVとして払い出してくれるPVCがデフォルトで付属するので非常に便利です1。
ネットワーク周りについては、K3d側にサービス公開用の機能として、traefik(とらふぃっく)を使ったIngressやNodePortが利用できるようになっています2。
K3d自体のインストールも簡単で、ローカル端末なら Homebrew 、Chocolatey、Scoop に対応しています。またサーバ用途ならインストールスクリプトも用意しているので以下で一発です3。
curl -s https://raw.githubusercontent.com/k3d-io/k3d/main/install.sh | bash または curl -s https://raw.githubusercontent.com/k3d-io/k3d/main/install.sh | TAG=v5.7.5 bash
インストールが完了すると、k3dコマンドが利用できるようになります。
❯ k3d --help https://k3d.io/ k3d is a wrapper CLI that helps you to easily create k3s clusters inside docker. Nodes of a k3d cluster are docker containers running a k3s image. All Nodes of a k3d cluster are part of the same docker network. Usage: k3d [flags] k3d [command] Available Commands: cluster Manage cluster(s) completion Generate completion scripts for [bash, zsh, fish, powershell | psh] config Work with config file(s) help Help about any command image Handle container images. kubeconfig Manage kubeconfig(s) node Manage node(s) registry Manage registry/registries version Show k3d and default k3s version Flags: -h, --help help for k3d --timestamps Enable Log timestamps --trace Enable super verbose output (trace logging) --verbose Enable verbose output (debug logging) --version Show k3d and default k3s version Use "k3d [command] --help" for more information about a command.
上記のヘルプにもあるように、completionにも対応してるので補完が効くのでとても便利です。
それでは本題のProxy環境下でのハマりポイントの解決の話の前に、、、、
K3sの紹介を軽く触れるので、「K3sの話はいいよ」って方は目次から飛んでください。
- はじめに
- K3s・K3dとは何か?
- 🙃ハマりポイント:クラスタ構築
- 🙃ハマりポイント:コンテキストが行方不明になる問題
- 🙃ハマりポイント:K3sクラスタノードにどうやってはいったらよいの?
- 最後に
- 補足
-
K3dというよりはK3sの機能ですいが詳細はこちらを参照ください
docs.k3s.io↩ -
詳細は以下を参照ください
docs.k3s.io↩ -
詳細なインストール方法については、以下を参照ください
https://k3d.io/v5.7.5/#releases↩
