アドホック分析にPrestoを使用する必要がある理由

プレスト!魔法のトリックの後で聴衆を興奮させるのは呪文であるだけでなく、ビッグデータを解き放つ方法を議論するときにますます使用される名前でもあります。Prestoは実際に多くの展開が行われていますが、このテクノロジ(あらゆる種類のデータソースをサポートする分散SQLクエリエンジン)は、それを使用することでメリットが得られる多くの開発者やデータアナリストにはなじみがありません。

この記事では、Prestoについて説明します。それは、それが何であるか、どこから来たのか、他のデータウェアハウジングソリューションとどのように違うのか、そしてビッグデータソリューションでなぜそれを検討する必要があるのか​​です。

Presto vs. Hive

Prestoは2012年にFacebookで始まりました。2013年にオープンソースであり、Presto Foundation(Linux Foundationの一部)によって管理されているPrestoは、長年にわたって着実に人気が高まっています。今日、いくつかの企業が、PrestoDBベースのアドホック分析サービスを使用して、AhanaなどのPrestoを中心にビジネスモデルを構築しています。

Prestoは、アドホック分析を実行するための膨大なデータセットへのアクセスをエンドユーザーに提供する手段として構築されました。 Prestoの前は、Facebookはこの種の分析を実行するためにHive(これもFacebookによって構築され、Apache Software Foundationに寄付されました)を使用していました。 Facebookのデータセットが大きくなるにつれて、Hiveのインタラクティブ性が不十分であることがわかりました(読み取り:遅すぎる)。これは主に、Hiveの基盤がMapReduceであり、当時、中間データセットをHDFSに永続化する必要があったためです。これは、最終的に破棄されたデータのディスクへの大量のI / Oを意味しました。 

Prestoは、時間を節約するために、これらのクエリを実行するために異なるアプローチを採用しています。Prestoを使用すると、中間データをHDFSに保持する代わりに、すべての中間データセットをディスクに保持する代わりに、データをメモリにプルして、そこでデータに対して操作を実行できます。それがおなじみのように聞こえるなら、MapReduceベースのテクノロジーを効果的に置き換えるための同じ基本概念を持つApache Spark(または他の多くのテクノロジー)について聞いたことがあるかもしれません。Prestoを使用して、データを(Hadoop内、または後で説明するように)存在する場所に保持し、分散システム全体でメモリ内で実行を実行し、必要に応じてサーバー間でデータをシャッフルします。ディスクに触れることを避け、最終的にクエリの実行時間を短縮します。

Prestoのしくみ

従来のデータウェアハウスとは異なり、PrestoはSQLクエリ実行エンジンと呼ばれます。データウェアハウスは、データの書き込み方法、データの常駐場所、およびデータの読み取り方法を制御します。データをウェアハウスに取り込むと、元に戻すのが困難になる可能性があります。Prestoは、データストレージを処理から切り離すことで別のアプローチを取り、以前と同じANSISQLクエリ言語をサポートします。

Prestoは、プラグイン、特にコネクタによって提供されるデータセットに対してクエリを実行します。。コネクタは、Prestoが外部データシステムにデータを読み取る(さらには書き込む)ための手段を提供します。 Hiveコネクタは標準コネクタの1つであり、HDFSまたはAmazonS3とのやり取りに使用するのと同じメタデータを使用します。この接続性により、Prestoは、現在Hiveを使用している組織のドロップイン代替品です。同じデータ形式(ORC、Avro、Parquet、JSONなど)を使用して、同じスキーマとテーブルからデータを読み取ることができます。 Hiveコネクタに加えて、Cassandra、Elasticsearch、Kafka、MySQL、MongoDB、PostgreSQL、およびその他の多くのコネクタがあります。コネクタは常にPrestoに提供されており、Prestoはどこにいてもデータにアクセスできる可能性があります。

この分離されたストレージモデルの利点は、Prestoが、データがどこにあるかに関係なく、すべてのデータの単一のフェデレーションビューを提供できることです。これにより、アドホッククエリの機能がこれまでにないレベルにまで向上し、大規模なデータセットに対してインタラクティブなクエリ時間が提供されます(オンプレミスまたはクラウドでバックアップするインフラストラクチャがある場合)。

Prestoがどのようにデプロイされ、クエリがどのように実行されるかを見てみましょう。PrestoはJavaで記述されているため、起動するにはJDKまたはJREが必要です。Prestoは、1人のコーディネーターと多くのワーカーという2つの主要なサービスとして展開されます。コーディネーターサービスは、事実上、操作の頭脳であり、クライアントからクエリリクエストを受信し、クエリを解析し、実行プランを作成し、多くのワーカーサービスで実行される作業をスケジュールします。各ワーカーはクエリ全体の一部を並行して処理し、需要に合わせてPrestoデプロイメントにワーカーサービスを追加できます。各データソースはカタログとして構成されており、各クエリで必要な数のカタログをクエリできます。

アハナ

PrestoはJDBCドライバーを介してアクセスされ、JDBCを使用してデータベースに接続できる実質的にすべてのツールと統合されます。 Prestoコマンドラインインターフェイス(CLI)は、多くの場合、Prestoの探索を開始する際の開始点です。いずれの場合も、クライアントはコーディネーターに接続してSQLクエリを発行します。そのクエリはコーディネーターによって解析および検証され、クエリ実行プランに組み込まれます。この計画では、Prestoワーカーがクエリを実行する方法について詳しく説明します。クエリプランは(通常)外部データストアからデータを引き出すために、1つ以上のテーブルスキャンから始まります。次に、射影、フィルター、結合、グループ化、注文、およびその他のあらゆる種類の操作を実行する一連の演算子があります。計画は、最終結果セットがコーディネーターを介してクライアントに配信されることで終了します。これらのクエリプランは、Prestoがクエリを実行する方法を理解し、クエリのパフォーマンスを分析して潜在的なボトルネックを見つけるために不可欠です。

Prestoクエリの例

クエリとそれに対応するクエリプランを見てみましょう。SQLデータベースに使用される一般的なベンチマークツールであるTPC-Hクエリを使用します。つまり、TPC-Hは、SQL言語の完全性をテストするためのテーブルとクエリの標準セット、およびさまざまなデータベースのベンチマークを行う手段を定義します。データはビジネスユースケース向けに設計されており、多数のサプライ品から提供できるアイテムの販売注文が含まれています。Prestoは、オンザフライでデータを生成するTPC-Hコネクタを提供します。これは、Prestoをチェックアウトするときに非常に便利なツールです。

選択する

  SUM(l.extendedprice * l.discount)AS収益

FROMラインアイテムl

どこ

  l.shipdate> = DATE '1994-01-01'

   AND l.shipdate <DATE '1994-01-01' + INTERVAL '1' YEAR

   およびl..06-0.01および.06 + 0.01間の割引

   AND l.quantity <24;

これはクエリ番号6で、Forecasting Revenue ChangeQueryとして知られています。 TPC-Hのドキュメントを引用すると、「このクエリは、特定の年に特定の割合の範囲で特定の全社的な割引を排除した結果として生じる収益の増加量を定量化します。」

Prestoは、クエリをフラグメントとも呼ばれる1つ以上のステージに分割し、各ステージには複数の演算子が含まれます。演算子は、スキャン、フィルター、結合、または交換のいずれかで実行されるプランの特定の機能です。交換はしばしば段階を分割します。交換は、データがネットワークを介してPrestoクラスター内の他のワーカーに送信される計画の一部です。これが、Prestoがスケーラビリティとパフォーマンスを提供する方法です。クエリを複数の小さな操作に分割して並行して実行し、データをクラスター全体に再配布して、データセットの結合、グループ化、および順序付けを実行できるようにします。このクエリの分散クエリプランを見てみましょう。クエリプランは下から上に読み取られることに注意してください。

 フラグメント0 [シングル]

     -出力[収益] => [合計:ダブル]       

             収益:=合計   

         --Aggregate(FINAL)=> [sum:double]         

                 sum:= "presto.default.sum"((sum_4))          

             --LocalExchange [SINGLE]()=> [sum_4:double]  

                 --RemoteSource [1] => [sum_4:double]      

 フラグメント1 

     --Aggregate(PARTIAL)=> [sum_4:double]  

             sum_4:= "presto.default.sum"((expr))  

         --ScanFilterProject [table = TableHandle {connectorId = 'tpch'、connectorHandle = "lineitem:sf1.0"、layout = "Optional [lineitem:sf1.0]"}、grouped = false、filterPredicate =((discount BETWEEN(DOUBLE 0.05 )AND(DOUBLE 0.07))AND((quantity)=(DATE 1994-01-01))AND((shipdate)[expr:double]

                 expr:=(extendedprice)*(割引)   

                 extendedprice:= tpch:extendedprice

                 割引:= tpch:discount         

                 shipdate:= tpch:shipdate 

                 数量:= tpch:数量  

このプランには、複数の演算子を含む2つのフラグメントがあります。フラグメント1には2つの演算子が含まれています。ScanFilterProjectはデータをスキャンし、述語を満たすために必要な列(プロジェクションと呼ばれる)を選択し、各ラインアイテムの割引によって失われた収益を計算します。次に、部分集計演算子が部分合計を計算します。フラグメント0には、フラグメント1から部分的な合計を受け取り、最終的な合計を計算するための最終的な集計を受け取るLocalExchange演算子が含まれています。その後、合計がクライアントに出力されます。

When executing the query, Presto scans data from the external data source in parallel, calculates the partial sum for each split, and then ships the result of that partial sum to a single worker so it can perform the final aggregation. Running this query, I get about $123,141,078.23 in lost revenue due to the discounts.

      revenue       

----------------------

 1.2314107822830005E8

As queries grow more complex, such as joins and group-by operators, the query plans can get very long and complicated. With that said, queries break down into a series of operators that can be executed in parallel against data that is held in memory for the lifetime of the query.

As your data set grows, you can grow your Presto cluster in order to maintain the same expected runtimes. This performance, combined with the flexibility to query virtually any data source, can help empower your business to get more value from your data than ever before — all while keeping the data where it is and avoiding expensive transfers and engineering time to consolidate your data into one place for analysis. Presto!

Ashish Tadose is co-founder and principal software engineer at Ahana. Passionate about distributed systems, Ashish joined Ahana from WalmartLabs, where as principal engineer he built a multicloud data acceleration service powered by Presto while leading and architecting other products related to data discovery, federated query engines, and data governance. Previously, Ashish was a senior data architect at PubMatic where he designed and delivered a large-scale adtech data platform for reporting, analytics, and machine learning. Earlier in his career, he was a data engineer at VeriSign. Ashish is also an Apache committer and contributor to open source projects.

New Tech Forumは、前例のない深さと幅で新しいエンタープライズテクノロジーを探索して議論する場を提供します。選択は主観的であり、読者にとって重要で最も興味深いと思われるテクノロジーの選択に基づいています。出版用のマーケティング資料を受け入れず、寄稿されたすべてのコンテンツを編集する権利を留保します。すべてのお問い合わせは[email protected]までお送りください。