Apache Calcite: A Foundational Framework for Optimized Query Processing Over Heterogeneous Data Sources (2018)
March 10, 2024Michael StonebrakerとUğur Çetintemelは、2005年にOne size fits allで、データウェアハウスとストリーミング処理をとりあげ、すべてのデータをRDBMSで管理する時代の終わりを主張した。 組織はデータベースを特定の用途ごとに使い分けるようになった。 しかし同時に、データベースの開発者は、どんなデータベースでも必要な仕組みをデータベースごとに実装しなければならなくなった。 どのようなクエリ言語を採用するデーターベースにもクエリ最適化が求められる。 一方、組織は複数のデータベースに分散したデータを統合しなければならなくなった。
Apache Calciteは、SQLの解釈、最適化、実行のためのフレームワークであり、複数のデータベースに分散したデータへのANSI標準のSQLでの問い合せを実現する。 データが複数のデータベースに分散していても、クライアントはデータが1つのRDBMSにあるかのようにSQLでCalciteに問い合せられる。
Calcite自体はデータを保存するストレージをもたない。
かわりに、モデルとよばれるファイルで指定した外部のデータベースからデータを取得し、クライアントには各データベースがRDBMSのスキーマのように見せる。
以下にCalciteのTutorialにあるモデルの例を示す。
クライアントからは、salesディレクトリにあるCSVファイルがsalesスキーマにあるテーブルのように見える。
モデルで指定されるfactoryは、SchemaFactoryを実装したクラスであり、RDBMSのスキーマの役割をもつShcemaのインスタンスを生成する。
{
version: '1.0',
defaultSchema: 'SALES',
schemas: [
{
name: 'SALES',
type: 'custom',
factory: 'org.apache.calcite.adapter.csv.CsvSchemaFactory',
operand: {
directory: 'sales'
}
}
]
}
集合に対する操作は演算子 (Operator) とよばれる。 たとえばfilter, project, joinなどがある。 Schemaが参照するテーブルクラスはレコードをスキャンする演算子を実装し、SQLクエリは演算子の式に変換される。 物理演算子には、トレイトとよばれる属性が定義されている。 データを処理するバックエンドを指定する仕組みはトレイトが担っており、たとえば、spark convention, jdbc-mysqlトレイトをもつ演算子はSparkやMySQLでデータを処理する。
Optimizerは、もとのクエリの式の意味を保存したまま、より高速に実行できる別の式への変換をくりかえす。 ある式を別の式に変換する規則をplanner rulesといい、独自のplanner ruleを定義することができる。 Optimizerはトレイトをもとに実行計画のコストを評価する。 たとえば、トレイトから操作対象のデータが特定のバックエンドのみにあるとわかれば、そのバックエンド上で操作を実行するように式を変換する。