Uber社は、オープンソースの分散型SQLクエリエンジンであるPrestoを使用して、Apache Hive、Apache Pinot、MySQL、Apache Kafkaなどの複数のデータソースで分析をしている。
パフォーマンス向上のために、Uber社のエンジニアは、クイッククエリ（エクスプレスクエリ）を特定の方法で処理する有効性を探り、Prestoの稼働率と応答時間の両方が改善できることを発見した。
Uber社で分析処理を行うクエリの約半分をエクスプレスクエリ（2分未満で実行されるクエリ）が占めており、Uber社のエンジニアは、エクスプレスクエリとエクスプレスクエリ以外のクエリを同様に処理すると、システムが過負荷にならないようにスロットリングが実施され、システム稼働率の低下や、レイテンシの増大の原因になることを発見している。
エクスプレスクエリにスロットリング制限がかからないようにする最初のステップは、受信クエリがエクスプレスクエリかを予測する必要があった。Uber社のエンジニアは、各クエリに正確なフィンガープリント、すなわちコメント、空白文字、リテラルの値を削除してから算出されたユニークなハッシュ値が割り当てられた履歴データをもとに予測を行った。
わが社では、それぞれ2日間、5日間、7日間のルックバックウィンドウの期間を設定してクエリの正確なフィンガープリントと抽象化されたフィンガープリントを使用し、P90とP95のクエリ実行時間を測定しました。（中略）エクスプレスクエリであるかの予測には、この候補定義を使用しています。フィンガープリント（Z）に基づく過去Y日間のクエリの実行時間（X）が2分未満であるかどうかに着目しました。
この定義を用いて、Uber社のエンジニアは、クエリが2分未満で完了するかの予測精度やカバレッジが 5日間のルックバックウィンドウを設けた抽象化されたフィンガープリントから得られたP90の値を用いたときに、もっとも高くなることを発見した。また、パーセンタイルやルックバックウィンドウの設定日数が異なる場合にも対応できるように、 受信クエリがエクスプレスクエリかを検証するテーブルに十分なデータを保持していた。
こうした案は一見簡単そうに思えるが、設計と実装の間で反復を重ねており、パイプラインでの次のエクスプレスクエリの処理を可能なだけ遅らせるという当初の案から可能な限り早い段階で処理をするという案に変更されている。
当初の設計では、Uber社のエンジニアは、エクスプレスクエリとエクスプレスでないクエリを、ユーザー優先度に基づいて同じキューにキューに割り当てることにしていた。つまり、すべてのクエリが、エクスプレスであるかに関わらず、バッチやインタラクティブといったユーザー優先度に応じたキューに割り当てられた。各キューには専用のPrestoクラスタが割り当てられており、すべてのユーザー/ソースおよびクラスタ制限チェックを実行してから、サブセットがエクスプレスクエリのみを処理していた。
この設計では、Presto高速クラスタの稼働率が低下していた。主な原因は、スロークエリとエクスプレスクエリが同じキューに混在しており、スロークエリが処理速度を決定していたことだ。この処理速度では、エクスプレスクエリがエクスプレスクラスタの上限値に達してしまう。
システム設計の第二の試みとして、Uber社のエンジニアはエクスプレスクエリ専用のキューの使用した。このキューでは、エクスプレスクエリは検証段階を通過してシステムに入ると、すぐにルーティングされる。結果、エクスプレスクエリはが指定されたエクスプレスクラスターによりスピーディーに直接格納されるため、スケジュールされたクエリの75％以上のエンドツーエンドのSLAが桁違いに改善された。
このアプローチにより、クラスタ稼働率とエクスプレスクエリの実行時間が改善されたが、Uber社のエンジニアはさらなる改善方法を検討している。事実、この設計を本番稼動させたところ、エクスプレスクエリが非常に高速でに処理されるため、優先度に応じて異なるキューにルーティングする必要がないことが分かった。
これにより、Uber社のエンジニアは、エクスプレスクエリが専用のサブシステムを採用したさらなる進化的設計に取り組み始めた。この設計では、クラスタ稼働率の向上やルーティングのロジックの簡素化が期待されている。