ビッグデータ処理エンジン–どちらを使用しますか？：パート1

このブログ投稿は、Clouderaとの統合前にHortonworks.comで公開されていました。一部のリンク、リソース、または参照は、正確でなくなる可能性があります。

専門知識を確認して提供してくれたBillPreachukとBrandonWilsonに特に感謝します

はじめに

カラム型ストレージは、今日のビッグデータ処理およびストレージの世界でよく議論されるトピックです。データを保存できる形式、構造、最適化は数百あり、計画していることに応じてデータを取得する方法はさらに多くあります。それと。この多数のオプションは、オンライントランザクション処理（OLTP）ツールを使用してデータをすばやく取り込む必要があるだけでなく、オンライン分析処理（OLAP）を使用してデータをより効率的に消費および分析する必要があるために発生しました。ツール。何千もの異なるユースケースにはそれぞれ固有のニーズがあるため、多くのオプションが浮上しています。たとえば、株式市場のティッカーデータを読み取るには、製造ラインの品質指標を分析するのとはまったく異なる考え方が必要です。これらすべての選択肢があるため、最終目標である自分に合ったツールを選択するときに迷子になりがちです。

HDPには、特定のユースケースに合わせてカスタマイズされた多数のストレージソリューションが組み込まれています。このブログシリーズは、次の3つのツール/エンジンとそれに関連するストレージ形式について説明することから始めたいと思います。

• Apache Hiveは、OLAPとディープSQLクエリ処理の両方のパフォーマンスを可能にする効率的な列型ストレージ形式としてApacheORCを使用します
• Apache Phoenix / Apache HBaseが一緒になってOLTPデータベースを形成し、数十億のレコードを超えるリアルタイムクエリを可能にし、高速のランダムキーベースのルックアップと更新を提供します
• Apache Druidは、イベントストリームのリアルタイムの時系列分析と、非常に低いレイテンシで履歴データのOLAP分析を可能にする高性能データストアです。

この記事では、特定のユースケースに適したツールを明確にし、さまざまなツールを比較対照し、ユースケースに対応する適切なツールまたはツールのセットを選択するための基本的なガイドラインを提供します。

これはテトリスをプレイするのとよく似ています。各ピースには異なるニッチがありますが、それぞれがより大きな構造に独自の価値を追加します

ビッグデータ処理とその類似点

特定の列の合計、平均、またはその他の計算を絞り込もうとしていることが多いため、データはストレージ内の列ごとにグループ化されます。飛行機がドッキングされているときに飛行機に与える燃料の量を理解しようとしている航空会社を想像してみてください。フライトトリップデータのテーブルから、各フライトの平均飛行距離を計算することをお勧めします。これには、単一の列で平均関数を実行する必要があります。ディスクでのシーケンシャル読み取りは高速であるため、このデータを列形式で保存します。この場合、テーブルから1列全体をシーケンシャルに読み取ります（その後、平均計算を実行します）。

これらのエンジンには多くの違いがありますが、選択するデータ処理エンジンに関係なく、いくつかの共通点からメリットが得られます。それらの1つは、キャッシングの共有機能です。これら3つのエンジンはそれぞれ、メモリ内キャッシュと連携して動作し、バックエンドストレージ形式を変更せずに処理のパフォーマンスを向上させ、1秒未満の応答時間を実現します。 HBaseにはBlockCacheがあり、HiveにはLLAP IOレイヤーがあり、Druidにはいくつかのメモリ内キャッシュオプションがあります。多くの場合、クエリの処理にかかる費用のかかる部分には、リクエストを解析し、永続ストアに移動してユーザーが関心のあるデータのサブセットを取得することが含まれます。ただし、多くの列型ストレージ形式と同じようにメモリ内キャッシュメカニズムを使用すると、この手順全体を回避できます。を使用して、プロセスが以前にクエリされたデータのメモリに数分の1秒で到達できるようにします。燃料計算の例に戻りましょう。会社のすべてのフライトの平均飛行距離を尋ねたところですが、国内線の燃料要件は国際線とは大きく異なることに注意してください。次に、WHERE country =’US’（または同等の国コード）句を使用して前のクエリをフィルタリングします。このクエリパターンは、データ探索では非常に一般的です。以前のクエリのデータはすでにメモリにあるため、このクエリの結果は、高価なディスク読み取りを実行しなくても返すことができます。

HiveのLLAPレイヤーの構造–そのメモリスペースの一部はキャッシュに使用され、長期ストレージはHDFSにあります。 HBaseとDruidにも、キャッシュとストレージの同様の概念があります。

別の類似点は、これらのエンジンのそれぞれが、照会されている特定のデータに焦点を合わせるために使用するショートカットに存在します。 HBaseにはHashMapベースのO（1）ランダムアクセスがあり、Druidは反転ビットマップインデックスを使用してどの列値がどの行にあるかを把握し、Hiveテーブルには統計、インデックス、およびショートカットデータアクセスへのパーティション化があります。これらの機能により、エンジンはデータの保存方法とアクセス方法を組み合わせることができ、ハードウェアの効率を最適化し、CPUとRAMを最大限に活用しながら、高速な分析を可能にします。

最後の類似点は、これらの各エンジンのエンタープライズ対応です。データの冗長性の面では、これら3つのエンジンすべてがディープストレージメカニズムとしてHDFSを使用しています。 3xのHDFSレプリケーション係数により、2つのノードに同時に障害が発生した場合でも、データのコピーが他の場所に存在することが保証されます。冗長性を維持するために、データを正常なノードにすぐに再複製できます。クラスタ内のフォールトトレランスのトピックでは、各ツールが何らかの方法でギャップを埋めます。 HBaseはリージョンレプリケーションを提供し、Druidはマスターコンポーネントとワーカーコンポーネントの複製、およびHDFSでのレプリケーション係数の増加を実現し、HiveはYARNフレームワークのフォールトトレラントロジックとともにHDFSを備えています。エンタープライズ対応により、これらのエンジンは障害に対して回復力があり、初日から本番環境で実行できるようになります。

ビッグデータ処理エンジンの違い

データを取り込むための最良の方法は何ですか？データを取り込んだら、どのようにしてデータから洞察をすばやく引き出すことができますか？これらの3つのビッグデータ処理エンジンがこの一連のデータ処理タスクをどのようにサポートしているかを詳しく見ていきましょう

これらのエンジンは、ビッグデータを保存および処理する機能があるため、精神的にバンドルされて同様に考えられることがありますが、後でわかるように、それらのエンジンの長所に特に適したユースケースと目的に合わせて選択されています。 Hortonworks Data Platformに含まれるツールのコレクションは、特にHDP 3.0と導入したリアルタイムデータベース機能を使用して、スローできるビッグデータワークロードに最適であることがわかります。

Hiveは、最も幅広いユースケースを代表するOLAPエンジンであり、最も一般的には、ほぼすべてのタイプのデータのストレージを可能にするストレージレイヤーとしてHadoop分散ファイルシステム（HDFS）を採用しています。非構造化テキストデータ、CSVファイル、XML、半構造化JSON、柱状Parquet、およびその他のさまざまな形式のクエリ、処理、分析を行うことができます。 Hiveは、クラウドストレージ、Isilonなどの代替ストレージメディアもサポートしています。 Hiveの事実上のストレージ標準はORCであり、これは最も効率的に最適化され、列型ストレージのメリットを享受します。 ORCに変換されると、データは圧縮され、テーブルの列はディスクに順番に保存されます。これにより、Hiveのメモリ内キャッシュレイヤーLLAPは、データをディスクから1回プルし、メモリから複数回提供できます。 Hive + LLCの組み合わせは、アドホック分析、大規模な集計の計算、および低遅延レポートに使用されます。 Hiveの優れたユースケースは、ユーザー向けの一連のダッシュボードレポートを毎日実行することです。反復クエリは、LLAPキャッシュを利用するだけでなく、「クエリ結果キャッシュ」機能も利用します。これは、データが変更されていない場合にほぼ瞬時の結果を返します（ただし、クエリ結果キャッシュはHive 3.0で利用可能な機能です–でリリースされました。 HDP 3.0）。それに加えて、Hive Data Warehouseは、Hiveが実行できるアドホック分析の優れた使用法です。ユーザーは、データを結合し、同時クエリを実行し、ACIDトランザクションを実行できます。 Hiveは、その点ですべての業界のSQLジャックであると考えてください。一方、他の2つのエンジンは、特定のニッチなユースケースに対して非常に高速なパフォーマンスを提供します。

2番目のエンジンであるHBaseは、ランダムな読み取り、書き込み、更新、および削除機能を備えた分散型Key-Valueストアです。 HBase（NoSQLバリアント）はOLTPエンジンとして設計されており、大量のトランザクション操作のアーキテクチャを可能にします。ユーザー間で一定のメッセージが交換されたり、金融システムでトランザクションが生成されたりするメッセージングプラットフォームを考えてみてください。 HBaseは、データをすばやく取り込み、保存し、元に戻すのに非常に効率的です。超低遅延のランダムな挿入/更新/削除です。設計されていないのは、データの集約と結合です。この機能は、HBase上のSQLレイヤーおよびエンジンであるPhoenixを介して実現されますが、データが最適な方法で構造化されていないため、大量のデータにはお勧めしません。パフォーマンス（代わりにHiveを使用してください）。要約すると、HBaseは大量のCreate-Update-Delete操作の処理には優れていますが、そのデータを消費可能な形式でユーザーに提示する場合には不十分です。

最後に、Druidは3番目のエンジンであり、低遅延のOLAP時系列ワークロードとストリーミングデータのリアルタイムインデックス作成に適しています。 Druidは、クラスターに対してキューブ速度のOLAPクエリを提供します。ドルイドの時系列の性質は、エンジンの基礎です。時間ベースのデータを分析する場合、時間が主要なフィルターであるため、このように設計されています。旅行を予約するためにフライト時間を分析するときを考えてください。この特定の2週間の時間枠内でイタリアへの最低コストのフライトを知りたいです。 Druidは、データを非常にすばやく取り込み、要求されたときにデータを見つけるというニッチに適合します。一方、ビジネスユーザーやアナリストは、ドルイドと密接に結びついた視覚化レイヤーであるSupersetを介して、データをクエリして理解することもできます。 Druidは、1秒未満で数億または数十億のデータの少数の行を特定するのに優れており、同じ量のデータの集計値を非常に迅速に計算するのにも優れています。ただし、結合は行わないため、分析のためにデータセットを結合するために使用することはできません。 Druidでデータセットの組み合わせを分析する場合は、データをDruidに挿入する前に事前に結合するか、Hive（およびDruidがサポートするHiveテーブル）を使用して結合を実行することをお勧めします。言い換えれば、ドルイドは、データが処理され、ビジネスユーザーがデータにアクセスする方法に変換された後、データの最後のストップとなる役割にうまく適合します。 Druidは、クエリを記述せずにSupersetにログインし、ダッシュボード形式でメトリックを視覚化できるため、ビジネスアナリストに最適です。 GUIを使用して、クエリデータソースとフィルターを選択するだけです。また、クエリ時間が短いため、運用または分析に関係なく、システムダッシュボードのバッキングデータソースとしても最適です。

ワークロードに使用するツールに関する意思決定を分類する1つの方法は次のとおりです。

統合SQL

これまで複数のシステムについて説明してきましたが、それぞれに独自の方法でデータにアクセスできます。これは、ユーザーがこれらすべてのツールの仕組みを知っている場合に最適ですが、ほとんどのアナリストがそうであるように、SQL、SQL、およびその他のSQLの世界から来ている場合、完全な生産性に到達する前に学習曲線に入る可能性があります。これが、この相互作用を可能な限り単純にすることを試みた理由です。 HDP3.0のHive3.0では、HiveのSQLのようなHQL構文を使用して、このスペース内の非常に多くの異なるデータストアと対話できます。 Hiveは、Druid、HBase、およびJDBCインターフェースとドライバーを提供するすべてのものにアクセスして変更するためのポータルとして使用できます。 Hiveを使用して、KafkaをリッスンするDruid取り込みタスクを管理し、リアルタイムの取り込みを簡単に行うことができます。そして最後に、Hiveを使用してすべてをまとめることができます。データを最も意味のある場所に保存し、1か所からアクセスできます。一緒に参加して、その新しい結果を別の場所に保存することもできます。可能性はたくさんありますが、インターフェースが大幅に簡素化されているため、ユーザーベースは別のツールの学習に費やす時間を減らし、ビジネスに価値をもたらすためにより多くの時間を費やすことができます。

結論

以前の分析からわかるように、Hive、Druid、およびHBaseはすべて、データアーキテクチャ内で異なる場所にあります。ただし、これらは補完的なツールです。高速ルックアップを備えたHBaseでトランザクションデータを取り込み、そのデータをDruidに移動して高速なドリルダウン/集計を行い、Hiveに2つを独自のHive管理データと統合させて、ユーザーがどこにいてもデータを組み合わせることができるようにすることができます。単一のビューと豊富な洞察。このアプローチでは、Druidはそれ自体でアクセスできるデータを格納しますが、その機能はHiveによって拡張され、Druidデータを取得して、追加のデータと結合できます。これに、Hive 3.0で機能する主な拡張機能を追加します。特に、マテリアライズドビュー、Druidや他の多くのエンジンとの統合の改善、データウェアハウスのような機能の向上などがあります。ほぼすべてのユースケースを解決できるツールの一覧です。

前述のようなアーキテクチャは、ワークフローを最適化すると同時に、データのみに関心のあるユーザーのために詳細を抽象化するために、各ツールの最良のものをもたらします。アーキテクトはパイプラインを設定し、ユースケースに基づいてデータを所属する場所に配置します。次に、データアナリストは、知識と洞察を得るための単一のインターフェイスとしてHiveを使用します。彼らは、データが保存されている場所を心配したり、データにアクセスするための新しい構文を学習したりすることなく、データ内の興味深いパターンを見つけることができます。これが世界中でどれほど頻繁に見られるかを知って驚かれることでしょう。

この時点で、各ツールの長所、短所、およびベストプラクティスを示しました。何がどこに適合するのかをよりよく理解し、3つすべてを組み合わせて最良の結果を得るという全体像を理解してください。