[論文レビュー] Starling: A Scalable Query Engine on Cloud Function Services
Starling は、AWS Lambda などのクラウド関数プラットフォーム上で構築されたサーバess query エンジンであり、クラウドに保存されたデータに対するインタラクティブな分析を低コストかつ高スケーラビリティで実現する。細粒度の並列処理、オブジェクトストレージを活用した最適化されたデータシャッフル、および遅延関数の影響低減技術を活用することで、低〜中程度のクエリワークロードにおいて、プロビジョニング済みシステムと同等の遅延を実現しながらも、より低いコストを実現している。
Much like on-premises systems, the natural choice for running database analytics workloads in the cloud is to provision a cluster of nodes to run a database instance. However, analytics workloads are often bursty or low volume, leaving clusters idle much of the time, meaning customers pay for compute resources even when unused. The ability of cloud function services, such as AWS Lambda or Azure Functions, to run small, fine granularity tasks make them appear to be a natural choice for query processing in such settings. But implementing an analytics system on cloud functions comes with its own set of challenges. These include managing hundreds of tiny stateless resource-constrained workers, handling stragglers, and shuffling data through opaque cloud services. In this paper we present Starling, a query execution engine built on cloud function services that employs number of techniques to mitigate these challenges, providing interactive query latency at a lower total cost than provisioned systems with low-to-moderate utilization. In particular, on a 1TB TPC-H dataset in cloud storage, Starling is less expensive than the best provisioned systems for workloads when queries arrive 1 minute apart or more. Starling also has lower latency than competing systems reading from cloud object stores and can scale to larger datasets.
研究の動機と目的
- クラウドにおけるバースト型または低ボリュームの分析ワークロードに対して、固定クラスタをプロビジョニングする方法の非効率性を解消すること。
- 独自フォーマットや専用クラスタへの事前データロードなしで、インタラクティブなクエリパフォーマンスを実現すること。
- サーバーヲス関数の細粒度かつオンデマンド実行モデルを活用して、クエリあたりのコストを削減すること。
- サーバーレス環境におけるステートレスワーカー、不透明なデータシャッフル、および遅延関数の影響といった課題を克服すること。
- 一時的な分析クエリにおけるコストとパフォーマンスのトレードオフを調整可能にすること。
提案手法
- クエリオペレータをサーバーレス関数の呼び出しにマップすることで、細粒度の並列処理とオンデマンドスケーリングを可能にする。
- 中間結果の転送に、クラウドオブジェクトストレージ(例:Amazon S3)をシャッフルの媒体として使用する。
- リクエスト課金モデル下でのストレージコスト低減とスルーレット向上を実現するため、中間結果のフォーマットを最適化する。
- 遅延関数の影響を低減するための検出および緩和モデルを実装する。
- クエリ段階ごとの関数呼び出し回数を制御可能なパラメータを提供することで、コストまたは遅延の最適化を可能にする。
- Redshift をベースにしたクエリ最適化ツールを活用し、効率的なジョイン順序の選択と全体的な計算コストの低減を実現する。
実験結果
リサーチクエスチョン
- RQ1サーバーレスクエリエンジンは、低〜中程度のクエリワークロードにおいて、プロビジョニング済みシステムよりも低コストかつインタラクティブな遅延を達成できるか?
- RQ2ステートレスでリソース制限のあるクラウド関数上で、シャッフルや集計のようなステートフルな処理をどのように効率的に実装できるか?
- RQ3不透明で高遅延なストレージバックエンドを備えたサーバーレス環境において、遅延関数の影響をどの程度低減できるか?
- RQ4サーバーレス関数上で構築されたシステムは、一時的なクエリにおいて、既存のクラウドネイティブ分析データベースをコスト効率面で上回れるか?
- RQ5サーバーレスプラットフォームの「実行ごとの課金モデル」と、クラスタベースのモデルとを比較した場合、合計コア秒数の消費量はどのようになるか?
主な発見
- クラウドオブジェクトストレージに保存された1TBのTPC-Hデータセットに対して、クエリが1分以上間隔で到着する場合、Starlingは最良のプロビジョニング済みシステムよりも低コストである。
- Starling は、16ノードのPrestoクラスタ(presto-16)よりも、ほとんどのクエリで合計コア秒数を低く抑え、計算効率が優れていることが示された。
- Starling のクエリ遅延は、データを事前にロードしない状態でクラウドストレージから直接読み込んでも、プロビジョニング済みシステムと同等の性能を示した。
- 明示的なプロビジョニング意思決定やクラスタ管理を必要とせず、大規模なデータセットに対してもスケーラブルであることが実証された。
- 遅延関数の影響低減技術により、エンドツーエンドのクエリ遅延に与える影響が顕著に低減された。
- オブジェクトストレージ上での最適化された中間結果フォーマットの使用により、ストレージコストを低減しながらも、高い集約スルーレットを維持できた。
より良い研究を、今すぐ始めましょう
論文の読解から最終レビューまで、研究時間を劇的に削減しましょう。
クレジットカード登録不要
このレビューはAIが作成し、人間の編集者が確認しました。