PhoenixAI バージョン 4.0

v4.0 は長期サポート（LTS）リリースです。2025年10月17日に最初にリリースされ、それ以降継続的にメンテナンスされています。最新のパッチである 4.0.16 は 2026年9月30日にリリースされました。

このページでは、パッチごとではなく 4.0 系列全体について説明します。4.0 のリリース当初から 4.0 を使用しているクラスターと、現在 4.0.16 にアップグレードするクラスターとでは確認すべき項目が異なるため、アップグレードと互換性 セクションでは、4.0 に移行する際に変わる内容と、4.0 系列の中で後から変わった内容とを分けて記載しています。それ以外の内容は機能別に整理しています。4.0.0 で導入され、その後のパッチで拡張された機能は、完成した形で 1 回だけ記載しています。

アップグレードと互換性

4.0 にアップグレードする前に

ダウングレードには制限があります。 v4.0 にアップグレードした後は、v3.5.0 または v3.5.1 に直接ダウングレードしないでください。メタデータに互換性がなく、FE がクラッシュします。代わりに v3.5.2 以降にダウングレードしてください。これとは別に、v4.0.2 以降から v4.0.1、v4.0.0、または v3.5.2～v3.5.10 にダウングレードする前には SET GLOBAL enable_rewrite_simple_agg_to_meta_scan = false; を実行し、再度アップグレードした後に true に戻してください。

Data Cache の設定が統合されました。 datacache_mem_size と datacache_disk_size が有効になり、storage_page_cache_limit、block_cache_mem_size、block_cache_disk_size は非推奨になりました。BE のメタデータキャッシュとデータキャッシュは、個別にチューニングされる 2 つのプールではなく、1 つのアダプティブなサイズ設定戦略のもとに統合されています。そのため、非推奨となった項目を設定してチューニングしていたクラスターは、残る 2 つの項目に基づいて再チューニングする必要があります。

Azure Blob Storage または Data Lake Storage Gen2 上の共有データクラスターでは、アップグレード時に Data Cache が失われます。 キャッシュは自動的に再ロードされますが、アップグレード直後のクエリはオブジェクトストレージから読み込まれます。それを踏まえてアップグレードの時間帯を計画してください。

4.0 へのアップグレード時に変更されるデフォルト

以下の変更は、特別な操作をしなくても自動的に有効になります。

• Flat JSON がデフォルトで有効になりました。 JSON カラムは、頻繁にアクセスされるフィールドを型付きのサブカラムとして抽出した形で格納されます。個々の JSON フィールドを読み取るクエリは大幅に高速化されます。その代わりに書き込み時の処理が増え、ストレージレイアウトも変わるため、JSON を多用するテーブルのストレージ使用量や書き込みスループットは、3.x の値とそのまま比較することはできません。

• マテリアライズドビューのクエリ書き換えにおける集計プッシュダウンがデフォルトで有効になりました。 enable_materialized_view_agg_pushdown_rewrite のデフォルトは false から true に変わります。より多くのクエリがマテリアライズドビューを使用するように書き換えられ、それらのクエリのプランの形が変わります。

• 自動バケット化テーブルのデフォルトのバケットサイズは、4 GB から 1 GB に縮小されました。 新しいテーブルでは、より小さなタブレットがより多く作成されるため、並列度とリソース使用率が向上します。既存のテーブルは再分散されません。

• Hive および Iceberg のメタデータキャッシュは、メモリ量によって制限され、TTL は 24 時間になりました。 新しい Catalog プロパティにより、各キャッシュが使用できるメモリの上限を設定します。Hive では remote_file_cache_memory_ratio、Iceberg では iceberg_data_file_cache_memory_usage_ratio と iceberg_delete_file_cache_memory_usage_ratio で、いずれもデフォルトは 0.1（10%）です。事実上無制限のメタデータキャッシュに依存していた環境では、キャッシュミスが増える可能性があります。その場合は比率を引き上げて補ってください。

• 部分更新（Partial Update）のモードはシステムによって選択されるようになりました。 モードは設定のみで固定されるのではなく、関連するセッション変数と INSERT 文のカラム数から導出されます。

• split_part は、区切り文字が一致しない場合に NULL を返すようになりました。 一致しなかった結果から導出された値は返されません。

• CTAS と CREATE MATERIALIZED VIEW は、固定長の CHAR ではなく STRING を生成するようになりました。 ソース式から固定長を推定すると長さを誤ることがあり、後になってマテリアライズドビューのリフレッシュ失敗として表面化していました。この方法で作成したテーブルやビューのカラム型は 3.x とは異なります。

• SHOW DATA DISTRIBUTION は、マテリアライズドインデックスごとに報告するようになりました。 同じバケットシーケンス番号を共有するすべてのマテリアライズドインデックスの統計情報はマージされなくなります。これまでバケットごとに 1 行だった出力は、バケットごと・インデックスごとに 1 行になります。

• information_schema.fe_tablet_schedules の構成が変更されました。 TABLET_STATUS は SCHEDULE_REASON に、CLONE_SRC は SRC_BE_ID に、CLONE_DEST は DEST_BE_ID にそれぞれ名前が変更され、CREATE_TIME、SCHEDULE_TIME、FINISH_TIME は DOUBLE から DATETIME に変わります。このビューに対する監視クエリはすべて更新が必要です。

• information_schema.materialized_views の一部のカラム型が、格納するデータに合わせて変更されました。 また、いくつかの FE メトリクスに is_leader ラベルが追加されるため、メトリクスのスクレイプで返されるラベルの組み合わせが変わります。

• auto_partition_refresh_number は、自動と手動の両方のマテリアライズドビューのリフレッシュでリフレッシュされるパーティション数を制限するようになりました。 これまでは自動リフレッシュにのみ適用されていました。

4.0 系列内でクエリ結果が変わる可能性のある変更

以下はいずれも、誤っていた動作を修正するものです。以前の結果は誤っていたため、出力が変わるクエリはそれまで誤った答えを返していたことになります。ただし変更自体は目に見えるものであり、以前の出力をもとに構築したレポートや後続のジョブは確認が必要です。

• タイムゾーンなしとして書き込まれた Parquet の INT64 タイムスタンプは、シフトされなくなりました（4.0.12）。 isAdjustedToUTC=false の場合、これまで SELECT FROM FILES() や Broker Load、Stream Load ではセッションのタイムゾーンオフセット分だけ値がシフトされていたため、セッションのタイムゾーンが UTC 以外の場合はデータがずれていました。このようなタイムスタンプは、Trino、Spark、Impala と同様に、ウォールクロック値として読み取られるようになります。

• 定数オペランドに対する LIKE のエスケープは MySQL 8 に準拠するようになりました（4.0.13）。 SELECT 'a\\b' LIKE 'a\\\\b' は 1 を返し、SELECT 'a\\b' LIKE 'a\\b' は 0 を返すようになります。以前の MySQL 非互換のエスケープセマンティクスを前提に書かれたクエリは、異なる行を返します。

• 除数が定数でない除算式は、単調（monotonic）として扱われなくなりました（4.0.14）。 Zone Map によるプルーニングで、10 DIV c のような述語を満たす行が除外されてしまうことがありました。このようなクエリは、より多くの行を返す可能性があります。c DIV 10 のような単調な形式は、引き続きプルーニングの恩恵を受けます。

• GIN 転置インデックスに対する NOT MATCH は、NULL の行を返さなくなりました（4.0.14）。 これにより、SQL の三値論理と整合するようになります。影響を受けるクエリが返す行は少なくなります。

• リストパーティションのプルーニングで、値リストに NULL が含まれていることを理由にパーティションが除外されなくなりました（4.0.16）。 !=、NOT IN、IS NOT NULL の述語（プランナーが結合キーから導出する IS NOT NULL を含む）は、これまで値の中に NULL が含まれていると、複数値パーティション全体を除外していました。これらの NULL 以外の行が再び返されるようになります。

• NULL の数を実際より少なく報告する Parquet の null_count は、信頼されなくなりました（4.0.16）。 古いバージョンの parquet-mr で書き込まれたファイルでは、デコードやプルーニングの際に破損した値が返されたり、行が黙って除外されたりすることがありました。

• 挿入専用（insert-only）の ACID Hive テーブルに対するクエリは、結果を返すのではなく拒否されるようになりました（4.0.10）。 このようなテーブルに対する INSERT OVERWRITE が認識されていなかったため、クエリが実際に可視である行よりも多くの行を黙って返すことがありました。影響を受けるテーブルは、明示的なエラーを返すようになります。

• ARRAY、MAP、STRUCT 内にネストされた VARBINARY 値は、MySQL の結果セットでバイナリエンコードされるようになりました（4.0.9）。 これまでは生のバイトがそのまま出力されていたため、NULL バイトや印字不可能な文字でテキストプロトコルの解析が失敗していました。ネストされた型の中の VARBINARY を解析するクライアントやツールは、調整が必要になる場合があります。

• VARCHAR(N) の長さが CTAS で保持されるようになりました（4.0.12）。 ソースが明示的なユーザー指定の長さ（Catalog のカラム参照、CAST AS VARCHAR(N)、または文字列リテラル）を持つ場合、VARCHAR(1048576) に拡張されなくなります。これにより長さの制約が引き続き適用され、生成される DDL が dbt のスキーマコントラクトと一致します。マテリアライズドビューのマテリアライズでは、これまでどおりカラムが拡張されます。

4.0 系列内で文が失敗する原因となる可能性のある変更

• 複雑なスカラー式が解析時に拒否される場合があるようになりました（4.0.3）。 max_scalar_operator_flat_children（デフォルトは 10000）は、これまで CASE WHEN によって構築された式のみを制限していましたが、オプティマイザが書き換えるすべてのスカラー式を制限するようになり、ノード数はキャッシュされるのではなく書き換えのたびに再計算されます。以前は実行できたクエリが Expression too complex. Current nodes: N, Limit: M. で失敗することがあります。これは典型的には、ビュー、CTE、またはサブクエリのインライン展開によって式ツリーが膨らんだ場合に発生します。式を簡略化するか、動的に変更可能なこの上限を引き上げてください。

• ARRAY および MAP のコンストラクタは、データを破損させる代わりに失敗するようになりました（4.0.14）。 フラット化した結果が 1 つのチャンクで扱えるバイト数の上限を超えるコンストラクタは、CTAS、INSERT、またはマテリアライズドビューのリフレッシュによって永続化されうる破損した値を黙って返すのではなく、CapacityLimitExceed を発生させるようになります。chunk_size を小さくするか、式を分割してください。

• これまで適用されていなかった箇所でも sql_mode が適用されるようになりました（4.0.8）。 DIVISION_BY_ZERO または FAIL_PARSE_DATE を設定している場合、ゼロ除算や str_to_date/str2date の解析失敗は無視されるのではなくエラーを返します。FORBID_INVALID_DATE を設定している場合、INSERT ... VALUES 内の無効な日付は素通りするのではなく拒否されます。

• Iceberg または Hive テーブルへの INSERT における静的パーティション句は、対象カラムリストが指定されている場合でも検証されるようになりました（4.0.14）。 パーティションカラム以外のカラムを指定した句は、黙って無視されるのではなく、明確なエラーで拒否されます。以前受け付けられていた INSERT の形式は、すべて引き続き受け付けられます。

• Routine Load は、リトライ不可能なエラーで一時停止するようになりました（4.0.9）。 たとえば主キーのサイズ上限を超える行などがある場合に、無期限にリトライし続けることはなくなります。これまで実行中のように見えながら処理が進んでいなかったジョブは、停止してエラーを報告するようになります。

• pipeline_enable_large_column_checker がデフォルトで有効になりました（4.0.11）。 そのため、サイズが過大なカラムを生成するクエリは、そのまま処理を続けるのではなく検出されるようになります。

• Iceberg ビュー上にマテリアライズドビューを作成することはできなくなりました（4.0.7）。

4.0 系列内のその他の運用上の変更

• AWS SDK 自体の HTTP クライアントが再び使用されるようになりました（4.0.16）。 enable_poco_client_for_aws_sdk のデフォルトは false です。以前のクライアントに戻すには true に設定してください。
• jemalloc の専用の oversize アリーナがデフォルトで有効になりました（4.0.16）。 そのため、大きなメモリ割り当てが呼び出し元スレッドの CPU ごとのアリーナに配置されることはなくなります。これにより大きなバッファの再利用が改善されて断片化が減少し、BE および CN のメモリがアリーナ間でどのように配分されるかが変わります。
• HDFS ファイルは、クローズ前に hsync されなくなりました（4.0.16）。 この hsync は、別の変更ですでに修正済みのクラッシュを回避するためのもので、クローズのたびにすべての DataNode レプリカで fsync() を強制していました。
• vended credentials を使用する Iceberg REST Catalog は、再びテーブルメタデータキャッシュを使用するようになりました（4.0.13）。 以前のキャッシュバイパスにより、すべての getTable() が REST Catalog に送信され、AWS Lake Formation で Rate exceeded エラーが発生していました。キャッシュされたテーブルはリフレッシュサイクルのたびに認証情報を更新し、REST Catalog のテーブルキャッシュの有効期限は最大 3000 秒に制限されます。
• 古くなったパーティションを多数持つテーブルで、統計情報の健全性が 1.0 付近に張り付いたまま報告されることはなくなりました（4.0.16）。 そのため、auto-ANALYZE が本来トリガーされるべきタイミングでトリガーされます。これまで健全とみなされていたテーブルが、アップグレード後に再度 ANALYZE される場合があります。
• paimon.option.cache-enabled = false で、再び Paimon のメタデータキャッシュを無効にできるようになりました（4.0.16）。 また、Paimon Catalog のバックグラウンドでのメタデータリフレッシュは、サイクルごとにウェアハウス全体を列挙するのではなく、最近アクセスされ変更されたテーブルのみを対象とするようになります。

新機能

エンタープライズ限定の機能

以下の機能は PhoenixAI で利用でき、オープンソースの StarRocks では利用できません。これらは、4.0 のうちこれまでリリースノートで取り上げられていなかった部分です。

• 手動クラスタースナップショット

  4.0 より前は、クラスターが保持できるのは、システムのスケジュールで取得される自動スナップショット 1 つだけでした。障害からの復旧にはそれで十分ですが、計画的な変更を保護するには不十分です。移行や大量削除を実行しようとしていても、戻ることのできる正常な時点を固定しておく方法がなく、次の自動スナップショットによって保持しておきたいスナップショットが上書きされてしまいました。4.0 からは、クラスタースナップショットを手動で作成・削除でき、自動スナップショットとは別に複数のスナップショットを同時に保持できます。クラスターが保持できる手動スナップショットの数には上限があります。

  自動スナップショット側にも、同じ系列の中で独自の制御機能が追加されました。自動スナップショットのスケジュールは、固定の周期で実行されるのではなく間隔を指定できるようになりました。ADMIN SHOW AUTOMATED CLUSTER SNAPSHOT は現在のステータスとスケジュールを報告するため、保護が実際に機能していることを確認できます。また、各スナップショットには snapshot_meta.json マーカーが含まれるようになり、復元の開始前に検証されます。そのため、不完全なスナップショットは復旧の途中ではなく、事前に検出されます。

• Compute Node Group

  4.0.0 から、ウェアハウスを Compute Node Group に分割できるようになりました。グループはウェアハウスとその Compute Node の間に位置する管理レイヤーであり、ウェアハウスの境界よりも細かい粒度でウェアハウス内のコンピューティングリソースを分離します。これにより、ウェアハウスの可用性が向上します。監視やキャパシティ計画のために、CN Group に関する専用のメトリクスセットも提供されます。

• Databricks Unity Catalog: Service Principal 認証と vended credentials

  これまで Databricks Unity Catalog には、Personal Access Token でしかアクセスできませんでした。これは個人に紐づいた認証情報であり、ローテーションが面倒で、サービス用途には適していません。4.0 からは、代わりに Service Principal（OAuth マシン間認証）を使用できます。

  vended credentials も 4.0 からサポートされ、デフォルトで有効になっています。Catalog が基盤となるオブジェクトストアの認証情報を提供するため、PhoenixAI が常設のストレージ認証情報を自前で保持する必要はありません。AWS S3 では aws.s3.region のみを指定し、Azure Blob Storage、Azure Data Lake Storage Gen2、Google Cloud Storage ではストレージ認証情報を一切指定する必要はありません。

• ウェアハウスの運用

  複数のウェアハウスを持つクラスターにおける運用上のいくつかの不足点が、この系列を通じて解消されました。CURRENT_WAREHOUSE() はセッションが実際に使用しているウェアハウスを報告します。db_admin はクラスターレベルのロールなしでウェアハウスのプロパティを設定できます。Compute Node や Backend は、ウェアハウスを指定しなくても削除できます。Backend のリソース統計とパイプライン並列度（DOP）はクラスター全体ではなくウェアハウスごとに計算されるため、あるウェアハウスの負荷が別のウェアハウスの並列度を歪めることはなくなります。マテリアライズドビューのメトリクスには warehouse_name ラベルが付きます。information_schema に対するクエリが、アイドルチェック中にウェアハウスを稼働状態のまま保つことはなくなります。そして、一時停止中のウェアハウスが Backend のハートビート失敗でログを埋め尽くすこともなくなります。

  ライセンスについては、スケールアウトの猶予期間は変更が要求された時点ではなく、キャパシティが実際に増加した時点から開始されるようになり、FE のメトリクスエンドポイントはライセンスの残り日数を報告するようになりました。

レイクハウス

• Iceberg テーブルのメンテナンスとレイアウトの制御

  コンパクションは rewrite_data_files プロシージャで実行できるため、書き込み側が多数の小さなファイルを生成するテーブルを、外部ジョブではなく SQL から統合できます。隠しパーティション（hidden partition）は、テーブルの作成、書き込み、読み取りのすべてでサポートされ、テーブル作成時にソートキーを設定できます。パーティション仕様は ALTER TABLE ADD/DROP PARTITION COLUMN でその場で変更でき、パーティションカラムはカラムリストの末尾だけでなく任意の位置に宣言できます。また、パーティション変換では PARTITION BY (bucket(k1, 3)) のように括弧を使用できます。

• Iceberg の書き込み性能

  Iceberg シンクには、大規模なオペレーターのスピル、グローバルシャッフル、ローカルソートが追加されました。これらを組み合わせることで、幅広い並列書き込みによって発生しがちな小さなファイルの問題に対処します。グローバルシャッフルは、事前に設定するのではなく、データの分布に基づいて動的に有効化できます。また、connector_sink_sort_scope によってホストレベルのソートを利用でき、データレイアウトを整理してその後の読み取りを高速化できます。バケットを考慮した実行により、バケット化されたテーブルでの並行性が向上します。

• Iceberg の読み取りとプランニングの性能

  COUNT、MIN、MAX クエリは、データファイルをスキャンせずに Iceberg のメタデータから回答されます。これは、カラム数が多くパーティション化されたテーブルでは大きな違いになります。統計情報のメタデータファイルは繰り返しではなく 1 回だけ解析され、フォアグラウンドでの行数推定はすべてのデータファイルを列挙するのではなくマニフェストのメタデータから計算されます。また、位置削除（position delete）を持つテーブルの読み取りも高速化されています。Iceberg および Delta Lake テーブルの統計情報は、バケットや truncate のパーティション変換を使用するテーブルを含め、デフォルトでメタデータから収集されます。

• BE メタデータ向けのページキャッシュとデータキャッシュの統合

  BE のメタデータキャッシュとデータキャッシュは、同じメモリ予算に対して個別にサイズ設定される 2 つのプールではなく、アダプティブなサイズ設定戦略を持つ 1 つのプールから提供されます。これによって置き換えられる設定項目については、アップグレードと互換性 を参照してください。

• Paimon

  TIME データ型と、ARRAY、MAP、STRUCT カラムがサポートされます。これまでは、複合型の Paimon カラムをクエリすると BE がクラッシュすることがありました。SHOW CREATE TABLE と DESC は、Paimon 外部テーブルの主キーカラムを表示します。スキャンスプリットの計算時に connector_max_split_size が反映されるため、スキャンの並列度をチューニングできます。また、バンドルされている Paimon のバージョンは 1.3.1 になります。

• Iceberg 1.10.0 がバンドルされ、Iceberg ビューをプロパティ付きで作成できるようになりました。プロパティは SHOW CREATE VIEW の出力に表示されます。

ストレージ、データロード、クラスター管理

• 共有データクラスター向けの File Bundling

  共有データクラスターは、ロード、コンパクション、publish のたびに 1 組ずつ、多数の小さなファイルを書き込みます。そして、そのそれぞれがオブジェクトストアに対する API 呼び出しのコストを発生させます。書き込み頻度が高い場合、データ量ではなくこれらの呼び出しが主なコストになります。File Bundling は、これらの操作で生成されるファイルを書き込み前にまとめます。4.0 以降で作成されたテーブルではデフォルトで有効になっており、既存のテーブルには影響しません。この系列のその後のパッチでは、バンドリングが有効な場合のバキューム時のリモートストレージへのアクセスが削減され、最新のバンドル済みタブレットメタデータがキャッシュされるようになり、バンドルの書き込みがタブレットローカルのアグリゲーターに移されたため、ノードをまたいだシャードの参照が不要になりました。

• 複数テーブルにまたがる書き込みトランザクション

  複数のテーブルにまたがる INSERT、UPDATE、DELETE を、Stream Load と INSERT INTO の両方でアトミックにコミットできます。これは、ETL ジョブや CDC パイプラインが関連する一連のテーブルを互いに整合した状態に保つために必要な機能です。これまでは各テーブルが個別にコミットされていたため、読み取り側からは、あるテーブルは更新済みで別のテーブルは未更新という状態が見えることがありました。複数文の Stream Load は、すべてのテーブルごとのチャネルをディスパッチしてから完了を待つため、1 つのラベルで多数のテーブルに書き込むパイプラインのコミット時間が短縮されます。

• 共有データのメタデータに対するチェックサム保護

  共有データクラスターのタブレットメタデータとトランザクションログにはチェックサムが付与されるため、破損は後になって原因不明のクエリ失敗として表面化するのではなく、メタデータの読み取り時に検出されます。

• リソースグループのメモリプール

  リソースグループ属性 mem_pool を使用すると、複数のリソースグループで 1 つのメモリプールを共有し、共通の上限で管理できます。各グループが他のグループからは使用できない予約領域を保持する必要はなくなります。この変更は後方互換性があり、mem_pool を指定していないグループは default_mem_pool を使用します。

• Routine Load が Kafka 4.0 をサポートします。

• 共有なしクラスターにおける 主キーテーブルの全文転置インデックス。

• 集計テーブルの集計キーを変更 できます。テーブルを再作成する必要はありません。

• Catalog、データベース、テーブル、ビュー、マテリアライズドビューの名前の大文字小文字を区別しない処理 を有効にできます。

• 共有データクラスターでは、Backend と同様に Compute Node をブラックリストに登録 できるようになりました。

• グローバル接続 ID により、FE ごとではなくクラスター全体で接続を識別できます。

• Information Schema の recyclebin_catalogs ビューは、削除されたもののまだ復元可能なメタデータを表示します。

クエリ実行と性能

• DECIMAL256

  DECIMAL の精度が 38 桁から 76 桁に拡張されます。DECIMAL128 は、大規模な集計や高次の算術演算（長い財務時系列の合計や、複数の高精度の項の積など）でオーバーフローします。その回避策としては、意図的に精度を落とすか、計算をデータベースの外に移すのが一般的でした。256 ビットの DECIMAL により、財務や科学計算のワークロードにおけるこの上限がなくなります。

• SQL Plan Manager (Preview)

  クエリにクエリプランをバインドできるため、その背後にあるデータや統計情報が変わってもプランは変わりません。目的は速度ではなく予測可能性です。プランが安定しているクエリは、ANALYZE が実行されたりパーティションが大きくなったりしたことで、ある日突然性能が低下することはありません。4.0 ではプレビュー機能です。

• Flat JSON V2

  Flat JSON には、V1 の仕組みを維持したまま、ページレベルおよびセグメントレベルのインデックス（ZoneMap と Bloom フィルタ）、遅延マテリアライゼーションを伴う述語プッシュダウン、辞書エンコーディング、低カーディナリティのグローバル辞書との統合が追加されました。グローバルにだけでなく、テーブルごとに設定することもできます。これらを組み合わせることで、クエリの観点では JSON フィールドが実カラムにかなり近づきます。Flat JSON は 4.0 ではデフォルトで有効です。アップグレードと互換性 を参照してください。

• パーティション単位のスピル可能な集計

  スピル可能な集計オペレーターと DISTINCT オペレーターはパーティション単位で動作するようになり、ソート済み集計に基づく実装を置き換えます。メモリに収まらない高カーディナリティの GROUP BY では、スピルの読み書きのオーバーヘッドが大幅に削減されます。

• Fast Schema Evolution v2

  メタデータのみを変更するスキーマ変更は、データを書き換えることなく完了します。4.0 では、FE が TableSchemaService を通じて Compute Node にオンデマンドでスキーマを提供するため、共有データクラスターがすべてのスキーマをあらゆる場所に伝播させる必要はありません。過去のスキーマは、それに依存するすべてのデータ取り込みジョブが完了するまで保持されます。これにより、実行中のロードがすでに破棄されたスキーマを参照してしまう可能性のあった期間が解消されます。マテリアライズドビューは 4.0.16 から Fast Schema Evolution をサポートします。

• クエリスケジューリング

  オペレーターとドライバーは並列に準備され、単一ノードのクエリはフラグメントを 1 つのバッチでデプロイします。Java UDAF のインスタンスはクエリごとに 1 回だけロードされ、パイプラインドライバー間で再利用されるため、pipeline_dop に比例して増加していたオーバーヘッドがなくなります。

• オプティマイザ

  結合と集計のオペレーター、およびその下にある基本的なオペレーターが高速化されました。Grouping Sets のプッシュダウンは、MAX、MIN、SUM に加えて AVG と COUNT にも拡張され、4 レベル以上の ROLLUP、CUBE、GROUPING SETS クエリが高速化されます。フレーム指定のウィンドウ内で、DISTINCT に対する COUNT、SUM、AVG がサポートされます。部分的な TopN が事前集計フェーズにプッシュされ、ネットワークトラフィックが削減されます。マテリアライズドビューによる書き換えでは、候補となるビューの中から選択する際に、ベーステーブルの分散キーとソートキーが考慮されます。

• STRING カラムに対するアダプティブな ZoneMap インデックス作成 により、ZoneMap は一律にではなく、効果が見込める場所に構築されます。

• table_query_timeout による テーブルレベルのクエリタイムアウト。セッション、テーブル、クラスターの順に解決されます。

セキュリティと認証

• JWT の ID が Iceberg に引き継がれるようになりました

  Iceberg REST Catalog で JWT 認証を使用する場合、ユーザーのログイン情報が REST Session Catalog を通じて Iceberg に転送されます。そのため、Iceberg レイヤーでのデータアクセスは、共有された単一のサービス ID ではなく、そのユーザーとして認可されます。

• Iceberg Catalog 向けの vended credentials により、ストレージへのアクセスには、クラスターが保持する常設の認証情報ではなく、テーブルごとに発行される短期間有効でスコープが限定された認証情報が使用されます。

• 内部ロールを外部グループに付与 できるようになりました。外部グループは Group Provider を通じて取得されます。これにより、既存のディレクトリグループを PhoenixAI のロールに対応付けることができ、メンバーシップを二重に管理する必要がなくなります。

• 外部テーブルに対する REFRESH 権限 により、テーブルのメタデータをリフレッシュする権限を、読み取りや変更の権限から分離できます。

• DN パターンによる LDAP の直接バインド により、シングルテナントの LDAP 環境では管理者用の検索アカウントが不要になります。保持してローテーションしなければならない特権認証情報が 1 つ減ります。

• Iceberg REST Catalog 向けの OAuth2 および JWT 認証 が拡張されました。

• INSERT INTO FILES のエラーでクラウドストレージの認証情報がマスクされる ようになったため、シークレットがエラーログや SHOW LOAD の出力に含まれることはありません。

SQL と関数

• 新しい関数: bitmap_hash64、bool_or、strpos、to_datetime と to_datetime_ntz、regexp_count、tokenize、format_bytes、encode_sort_key、column_size と column_compressed_size。
• 構文: SELECT での EXCLUDE。集計関数での FILTER（条件付き集計が読みやすくなり、CASE WHEN 形式よりも低コストになります）。CREATE ANALYZE FULL TABLE での IF NOT EXISTS。STRUCT 値に対する ORDER BY。SQL 標準のセマンティクスに準拠した FULL OUTER JOIN ... USING。
• Java UDF: UDAF および UDTF での STRUCT 型の引数と戻り値、スカラー UDF での STRUCT 型の引数、DATE 型と DATETIME 型、ネストされた ARRAY/MAP 型。
• INSERT INTO FILES による CSV エクスポートで csv.enclose と csv.escape がサポートされます。
• ngram_search は定数でない検索文字列を受け付けるため、検索語にカラム式を使用できます。
• VARBINARY が COUNT DISTINCT 系の集計でサポートされます。Trino ダイアレクトで map_agg がサポートされます。Trino ダイアレクトの INSERT に対して EXPLAIN と EXPLAIN ANALYZE が使用できます。

オブザーバビリティ

• EXPLAIN ANALYZE の出力がオペレーター別および実行グループ別にグループ化される ようになったため、大きなプランでもカウンターが平坦に並ぶだけにならず、読みやすくなります。
• すべての FE にわたってクエリプロファイルを取得できる ようになり、QueryDetailActionV2 と QueryProfileActionV2 は JSON を返します。そのため、どの FE がクエリを実行したかを知らなくてもプロファイルを取得できます。
• 監査ログには、各クエリが参照したテーブルとビュー、およびデータキャッシュのヒット率が記録されます。
• SHOW PROCESSLIST には Catalog とクエリ ID が含まれます。クエリキューは実行中と待機中の状態を報告します。
• Data Cache の監視 に、メモリとディスクのクォータおよび使用量のメトリクス、api/datacache/stat エンドポイントでのページキャッシュ統計、ネイティブテーブルのヒット率統計が追加されました。
• FE のメモリは /api/memory_usage で確認できる ようになりました。また、FE のメモリ推定では、サンプリングした内容だけでなく、マップやコレクションの内部オーバーヘッドも計上されるため、重みで上限が設定されたキャッシュは実際のフットプリントを報告します。
• サーバーレベルのスピルメトリクス は、スピル可能なすべてのオペレーターにわたるスピル処理を、ローカルとリモートのバックエンド別に集計します。
• リーダー FE の max_journal_replay_lag は、最も遅れている Follower または Observer が、リプレイ済みのジャーナル ID でどれだけ遅れているかを報告します。これは「遅れている FE はあるか」という問いに直接答えるものです。
• jemalloc の内部状態を実行時に観測でき、一部はチューニングも可能 になりました。dirty ページと muzzy ページのメトリクス、extent メタデータと rtree の内訳、be.INFO での stats.mapped と stats.retained、/memz によるアリーナごと・サイズクラスごとの詳細、jemalloc_conf で確認できる起動時オプション、そして再起動なしで変更できる dirty_decay_ms や muzzy_decay_ms などの変更可能なオプションが利用できます。
• クエリが例外に遭遇した場合やタイムアウトした場合にクエリプランがダンプされ、タイムアウト時にはパイプラインの状態もダンプされます。
• Iceberg のメタデータテーブルに対するクエリとタイムトラベルクエリには、それぞれ独自のメトリクスカテゴリがあります。共有なしクラスターのメトリクスセットに合わせて、共有データクラスターでも starrocks_fe_tablet_num が報告されます。新しいメトリクスは、Catalog のごみ箱のサイズ、バキュームのバッチサイズとリトライ、FE の publish 待ちの最大時間、StarOS のシャード情報キャッシュのフォールバックを対象としています。

改善点

16 のパッチリリースには、さらに数百件の改善が含まれています。ワークロード上で特に体感しやすいと考えられるテーマは、以下のとおりです。

• FE のロック競合

  LocalMetastore、InformationSchemaDataSource、およびフロントエンドサービス全体で、データベースレベルのロックがテーブル単位のロックに置き換えられました。INSERT OVERWRITE 中に保持されるロックは、フェーズごとに緩和または短縮されます。DDL 中のタブレット削除はバッチ化され、タブレットメタデータの書き込みロックはバッチごとに 1 回だけ取得されます。Routine Load の Broker RPC はジョブごとの書き込みロックの外に移されました。共有データのスキーマ変更ジョブのロックはテーブル単位になりました。そして、INSERT ... SELECT によってトリガーされる外部テーブルのメタデータリフレッシュは、FE のメタデータロックを保持したまま実行されることはなくなりました。この効果は、同時に多数の DDL やメタデータ操作が行われるクラスターで最も顕著に現れます。

• オプティマイザのコストと統計情報

  DP による結合順序の並べ替えでは、コストの高い候補プランをより早い段階で枝刈りし、より少ないメモリ割り当てでパーティションを列挙し、アトム数に上限を設けます。統計情報の推定では、Statistics オブジェクトを繰り返し再構築することを避け、述語カラムの収集をスキップします。ヒストグラムのバケットごとの異なり数は HyperLogLog またはサンプリングによって推定され、述語や結合に対してより正確な NDV が得られます。ヒストグラムの MCV は cast(k as bigint) + 10 のようなセマンティクス上安全な式を通じて伝播されるため、偏りの検出が改善されます。また、偏りの処理には、ヒストグラムベースおよび NULL ベースの戦略が追加されました。推定精度の向上は、多くの場合、より適切な結合順序という形で現れます。

• 共有データのメタデータとバキューム

  物理プランニング中のタブレットの場所の参照はバッチ化され、プランナーのクリティカルセクションでタブレットごとに StarOS RPC を発行することはなくなりました。Lake のセグメントメタデータキャッシュの参照は、プロセス全体のロックを経由しなくなりました。ロードのスピルファイルはトランザクション ID をキーとするフラットなディレクトリ構成に移され、トランザクション ID に基づくバキューム処理で回収されます。これにより一括削除が書き込みパスから切り離され、BE のクラッシュ後もバキュームでクリーンアップできるようになります。バキュームのリトライには相関のないジッターが付与され、リトライストームを回避します。また、コンパクションとレプリケーションでは、ロウセットのアーカイブ時に一度も読み取られない delete_predicate を破棄するため、タブレットメタデータの肥大化が発生源で解消されます。

• メモリ

  FE のメモリ推定では、サンプリングした内容だけでなくコレクションのオーバーヘッドも計上されるため、メモリ比率で上限が設定されたキャッシュは実際のフットプリントに基づいてエビクションを行います。オブジェクトストレージクライアントのキャッシュサイズは、ハードコードされた容量ではなく、変更可能な BE 設定項目になりました。終了した Spark または Flink コネクタのリーダーが残した期限切れの外部スキャンコンテキストは、回収時にそのパイプラインフラグメントをキャンセルするようになり、バッファされたスキャン用のメモリをクエリのタイムアウトまで保持し続けるのではなく、キープアライブの期間内に解放します。arm64 では、64K 版に加えて 4K ページ版の jemalloc もビルドされ、実行時に選択されます。これにより、4K ページのカーネル上で 64K ページ粒度によるメモリのオーバーヘッドが発生するのを回避します。

• 圧縮とストレージレイアウト

  "compression" = "zstd" の場合、Flat JSON のサブカラムと、ARRAY、MAP、STRUCT カラムの合成 NULL サブカラムおよびオフセットサブカラムが圧縮されるようになりました。これらはこれまで生のページとして書き込まれていたため、ZSTD のテーブルが LZ4 の同じテーブルよりもディスク上で大きくなることがありました。影響を受けるのはアップグレード後に書き込まれたセグメントのみであるため、既存のテーブルはセグメントが書き換えられるにつれて徐々に小さくなります。

• セキュリティ関連の依存関係のアップグレード

  この系列全体を通じて、Thrift は 0.24.0、Netty は 4.1.136.Final、PostgreSQL JDBC ドライバーは 42.7.12、Tomcat は 9.0.118、jackson-databind は 2.21.4、hadoop-client は 3.4.3、lz4 は 1.10.0 にそれぞれアップグレードされました。また、脆弱性のある推移的依存関係が削除されました。削除されたのは、bcprov-jdk15on、サポートが終了した OkHttp 2.x 系、avro-ipc（jQuery 1.4.2 を同梱）、Jetty のクライアントおよびセキュリティ関連の jar、そして Hadoop の依存関係ツリーに含まれる org.jline:jline です。