Uber社は、Apache Pinotのクエリアーキテクチャを再設計し、実行の簡素化、より豊かなSQLのサポート、内部分析ワークロードの予測可能性の向上を図った。従来のNeutrinoシステムは、PrestoとPinotを重ねたものであったが、軽量なプロキシ「Cellar」に置き換えられ、Pinotのマルチステージエンジンライトモードを使用することになった。この再設計は、複雑さを軽減し、実行制限を強化し、複数のテナントに対するより強固な隔離を提供することを目的としている。
従来、Neutrinoは、Prestoのコーディネーターとワーカーのプロセスを組み合わせたステートレスなマイクロサービスとして運用されていた。ユーザーが送信したPrestoSQLクエリは、一部がPinotSQLとしてPinotにプッシュダウンされ、残りのクエリロジックはNeutrino内で実行されていた。各クエリには、フルテーブルスキャンのリスクを軽減するために、デフォルトまたはユーザー定義の制限が含まれていた。しかし、これらの安全策にもかかわらず、層状のアーキテクチャは複雑なセマンティクスを生み出し、クエリプランの解釈を難しくし、同じプロキシを共有するテナント間の隔離を制限していた。
UberのNeutrinoのクエリアーキテクチャ(出典:Uberブログ記事)
UberのApache Pinotテーブルは、数百テラバイトに達し、数十億のレコードを持つことができ、クエリレートは1桁から数千QPSに及ぶ。これほどの規模のマルチステージクエリは、リソースやレイテンシの期待を容易に超える可能性がある。Pinot 1.4では、マルチステージエンジンライトモードが導入され、設定可能なリーフステージのレコード制限が適用され、スキャッター・ギャザー方式が使用される。リーフステージはPinotサーバー上で実行され、他のオペレーターはブローカー上で実行されるため、複雑なクエリに対して予測可能なパフォーマンスが確保される。
新しいアーキテクチャでは、クエリを直接Pinotブローカーに転送する軽量プロキシ「Cellar」が導入された。基本的なワークロードに対しては、Pinotのシングルステージクエリエンジンが実行を担当し、高度なSQL機能にはUberがマルチステージエンジンのライトモードを使用する。MSEライトモードでは、リーフステージで設定可能な最大レコード制限が適用され、過剰なリソース使用を防ぎ、これらの制限は透明性を持たせるために説明プランに表示される。スキャッター・ギャザー実行は維持され、データノード上でリーフステージが実行され、ブローカー上で集約が行われる。また、制御された条件下での結合やウィンドウ関数もサポートされる。Uberはさらに、MSEライトモードに監視およびログ記録の強化を追加し、エンジニアリングチームがクエリパフォーマンスを追跡し、高レイテンシのリクエストをより効率的にトラブルシューティングできるようにしている。
高レベルのCellarクエリアーキテクチャ(出典:Uberブログ記事)
Cellarには、テナントがプロキシをバイパスしてPinotブローカーに直接接続できるダイレクト接続モードも含まれている。Uberはまた、Cellarを通じてM3QLをサポートするタイムシリーズプラグインを統合した。再構築されたアーキテクチャは、トレーシング、ログ検索、セグメンテーションなどの内部分析ワークロードを支えている。公開時点で、Cellarは従来のNeutrinoのクエリボリュームの約20%を処理しており、今後の採用拡大とNeutrinoの段階的廃止を計画している。
Cellarのダイレクトモード接続による完全な隔離(出典:Uberブログ記事)
Uberは、Cellarとのインタラクションを簡素化するために、JavaおよびGoのモノレポ用の公式クライアントライブラリも提供している。これらのクライアントは、Pinotのレスポンスフォーマットを処理し、警告付きの部分結果をサポートし、タイムアウトやリトライを強制し、レイテンシ、クエリ成功、警告に関するメトリクスを出力する。新しいユーザー向けには、Grafanaダッシュボードが標準で運用の可視性を提供している。
Uberのエンジニアリングチームによると、再設計はOLAPシステムの進化を反映しており、高いQPSとサブセカンドのレイテンシをサポートしつつ、隔離性と予測可能性を維持することを目指している。彼らは、MSEライトモードを今年後半にユーザーにリリースし、さらに改善する計画である。