いま注目のオープンソース (5) データと ML パイプライン

• はじめに — スケジューラ一つで終わっていた時代は過ぎた
• スナップショット
• 取り込みと変換
• オーケストレーション — 何を管理単位とみなすか
• 実行エンジン
• モデルのライフサイクル
• 検索ストア
• 導入前の確認
• リンク

はじめに — スケジューラ一つで終わっていた時代は過ぎた

データパイプラインを作るという言葉は、長いあいだスケジューラにジョブを登録するという意味でした。いまでは、その一文が六つの決定に分かれます。ソースをどう取り込むか、どこで変換するか、何を管理単位とするか、演算をどのエンジンに載せるか、モデルのバージョンをどう追跡するか、埋め込みをどこに置くか。

それぞれの決定に別のプロジェクトが定着し、互いに競合関係ではない場合も多くあります。以下は順位ではなく、担当する区間ごとの地図です。

スナップショット

いずれも 2026-08-12 時点です。

取り込みと変換

dlt-hub/dlt は、ソースからデータを取り出して宛先に取り込む部分を Python ライブラリとして扱います。スキーマ推論と変更への対応、増分ロードを引き受けてくれるので、ソースごとに似たようなコードを繰り返し書いていた作業を減らせます。別のサービスを立てずに既存のコードベースの中に入れられるという点が、実務では大きな差を生みます。

dbt-labs/dbt-core は、ウェアハウス内での変換を SQL と依存グラフで管理する方式を、標準に近いところまで押し上げました。テストとドキュメントが一緒に付いてくることが本質です。ただし、ウェアハウスの外での演算やリアルタイム処理はこのツールの領域ではなく、オープンソースのコアと商用マネージド製品の境界も確認しておくほうがよいでしょう。

オーケストレーション — 何を管理単位とみなすか

dagster-io/dagster と PrefectHQ/prefect は、同じ位置を別の観点で埋めます。

Dagster は 成果物を管理単位 とします。どのテーブルがどの入力から生まれたのかが構造に表れるので、リネージの追跡と部分的な再実行が自然です。そのかわり、まず概念を学ぶ必要があります。

Prefect は、既存の Python 関数に印を付けてフローにするほうに近いです。参入障壁が低く、すでにあるスクリプトを素早く移せます。

どちらも導入そのものが目的になってはいけません。ジョブが数個しかなく依存関係が単純なら、cron とよく書かれたスクリプトが依然として正解であり得ます。

実行エンジン

pola-rs/polars は、データフレーム処理を書き直したライブラリです。遅延実行でクエリプランを立ててから最適化して実行するので、単一マシンで扱えるデータ規模の上限が目に見えて上がります。

# 例: 遅延実行で大きな CSV を絞り込んで集計
import polars as pl

q = (pl.scan_csv("events.csv")
       .filter(pl.col("status") == "ok")
       .group_by("country")
       .agg(pl.len().alias("n")))
print(q.collect().head())

apache/datafusion は、エンドユーザー向けのツールではなく、クエリエンジンを作るための部品です。自分たちでデータ製品を作るチームでなければこのプロジェクトを選ぶことは少なく、そのかわり、あなたが使っているツールの中にすでに入っている可能性があります。

ray-project/ray は、Python の処理を複数のマシンに分散します。学習、チューニング、バッチ推論のように一台を超えるワークロードで使われます。逆に、単一マシンで十分な処理にクラスタを載せると、デバッグの難度だけが上がります。

モデルのライフサイクル

mlflow/mlflow は、実験の記録とモデルレジストリにおいて事実上の既定値に近い存在です。どのデータとどのパラメータで作ったモデルがいま本番で動いているのかに答えられないチームにとって、まず最初に必要なツールです。

bentoml/BentoML は、そのモデルをサービスとして包む側を担います。確認時点の最終プッシュは 2026-08-03 で、リストの他のプロジェクトより少し間が空いていました。問題があるという意味ではありませんが、リリース周期とイシューへの応答を自分の目で見て判断することをおすすめします。

検索ストア

qdrant/qdrant は、フィルタとベクトル検索を一緒に扱うベクトルデータベースです。メタデータの条件が組み合わさる検索が多いなら強みが表れます。

lancedb/lancedb は、サーバーなしでファイル形式の上で動くほうを選びました。組み込み構成で始められるので初期コストが低いです。

ただし、データがすでにリレーショナルデータベースにあって規模も大きくないなら、専用のストアを導入する前に、既存データベースのベクトル拡張を先に試すほうが合理的です。システムを一つ増やす決定は元に戻しにくいものです。

導入前の確認

ライセンスの全文を自分で確認し、商用導入は法務レビューを通してください。この記事は法律アドバイスではありません。

このリストはすべて寛容なライセンスに見えますが、データ系のツールはオープンソースのコアと商用マネージド製品を併せ持つ会社が多くあります。ドキュメントで見た機能がリポジトリの中にある機能なのかを確認する習慣が必要です。そして、パイプラインのツールは一度入ると長く残ります。いまのチーム規模に合った、いちばん単純な構成から始めてください。

リポジトリの情報（スター数・ライセンス・最近の活動）は 2026-08-12 に GitHub で直接確認した時点の値です。数値と状態は変わります。

リンク

シリーズ: 前の記事 — 可観測性とセキュリティ · 次の記事 — オープンソースプロジェクトを評価する方法

このブログの関連記事:

• データプラットフォームとレイクハウスの全体像
• MLOps のフィーチャーストアと Feast
• ベクトルデータベースの比較

ツール: CSV と JSON の変換 · SQL プレイグラウンド