Dremio:よりシンプルで高速なデータ分析

Jacques Nadeauは、DremioのCTO兼共同創設者です。

今こそ開発者になる絶好の機会です。過去10年間で、テクノロジーに関する意思決定は、会議室から革新的な開発者に移りました。革新的な開発者は、オープンソースで構築し、ベンダーが提供する商取引関係ではなく、基盤となるプロジェクトのメリットに基づいて意思決定を行います。開発者の生産性を高め、管理と拡張が容易な新しいプロジェクトが登場しました。これは、テクノロジースタックのほぼすべてのレイヤーに当てはまります。その結果、今日の開発者は、新しいテクノロジ、新しいアーキテクチャ、および新しい展開モデルを探索する機会がほぼ無限にあります。

特にデータレイヤーを見ると、MongoDB、Elasticsearch、CassandraなどのNoSQLシステムは、運用アプリケーションの俊敏性、スケーラビリティ、パフォーマンスの面で限界を押し広げており、それぞれが異なるデータモデルとスキーマへのアプローチを備えています。その過程で、多くの開発チームがマイクロサービスモデルに移行し、アプリケーションデータをさまざまな基盤となるシステムに分散させました。

分析の観点から、新旧のデータソースは、従来のデータウェアハウスとデータレイクの組み合わせに組み込まれています。一部はHadoopにあり、その他はAmazonS3にあります。また、Kafkaデータストリーミングプラットフォームの台頭により、データの移動と移動中のデータの分析についてまったく異なる考え方が生まれました。

非常に多くの異なるテクノロジーと基盤となる形式のデータがあるため、最新のデータの分析は困難です。Tableau、Power BI、R、Python、機械学習モデルなどのBIおよび分析ツールは、データが単一の高性能リレーショナルデータベースに存在する世界向けに設計されました。さらに、これらのツールのユーザー(ビジネスアナリスト、データサイエンティスト、機械学習モデル)は、ITに依存することなく、自分でデータにアクセス、探索、分析する機能を求めています。

Dremioデータファブリックの紹介

BIツール、データサイエンスシステム、機械学習モデルは、データが単一の高性能リレーショナルデータベースに存在する場合に最適に機能します。残念ながら、それは今日のデータが存在する場所ではありません。その結果、ITは、カスタムETL開発と独自の製品を組み合わせることでそのギャップを埋めるしかありません。多くの企業では、分析スタックには次のレイヤーが含まれています。

  • データのステージング。データは、さまざまな運用データベースから、Hadoopクラスターやクラウドストレージサービス(Amazon S3など)などの単一のステージング領域に移動されます。
  • データウェアハウス。SQLクエリをHadoopおよびクラウドストレージで直接実行することは可能ですが、これらのシステムは、インタラクティブなパフォーマンスを提供するようには設計されていません。したがって、データのサブセットは通常、リレーショナルデータウェアハウスまたはMPPデータベースにロードされます。
  • キューブ、集計テーブル、およびBI抽出。大規模なデータセットでインタラクティブなパフォーマンスを提供するには、OLAPシステムでキューブを構築するか、データウェアハウスでマテリアライズされた集計テーブルを作成して、データを事前に集計またはインデックス付けする必要があります。

この多層アーキテクチャには多くの課題があります。それは複雑で、壊れやすく、そして遅く、データ消費者が完全にITに依存している環境を作り出します。

Dremioは、セルフサービスデータファブリックと呼ばれるデータ分析の新しい層を導入します。Dremioは、ビジネスアナリストやデータサイエンティストが、場所、サイズ、構造に関係なく、いつでもデータを調査および分析できるようにするオープンソースプロジェクトです。Dremioは、スケールアウトアーキテクチャと列の実行および高速化を組み合わせて、あらゆるデータボリュームでインタラクティブなパフォーマンスを実現すると同時に、IT、データサイエンティスト、およびビジネスアナリストがビジネスのニーズに応じてデータをシームレスに形成できるようにします。

Apache Arrow、Apache Parquet、およびApacheCalcite上に構築

Dremioは、Apache Arrow(メモリ内の列型)とApache Parquet(ディスク上の列型)を搭載した高性能の列型ストレージと実行を利用します。Dremioは、SQL解析とクエリ最適化にもApache Calciteを使用し、ApacheHiveなどの他の多くのSQLベースのエンジンと同じライブラリを構築しています。

Apache Arrowは、列型のメモリ内データ処理と交換を可能にするオープンソースプロジェクトです。ArrowはDremioによって作成され、Cloudera、Databricks、Hortonworks、Intel、MapR、TwoSigmaなどのさまざまな企業のコミッターが含まれています。

Dremioは、ApacheArrowでゼロから構築された最初の実行エンジンです。内部的には、メモリ内のデータはArrow形式でオフヒープに維持され、クエリ結果をArrowメモリバッファとして返すAPIがまもなく登場します。

他のさまざまなプロジェクトでもArrowが採用されています。Python(Pandas)とRはこれらのプロジェクトの中にあり、データサイエンティストがデータをより効率的に操作できるようにします。たとえば、人気のあるPandasライブラリの作成者であるWes McKinneyは、最近、Pythonユーザーが10 GB / sを超える速度でPandasにデータを読み取ることができるようにする方法を示しました。

Dremioがセルフサービスデータを有効にする方法

データセットをインタラクティブに操作する機能に加えて、データエンジニア、ビジネスアナリスト、データサイエンティストは、特定のプロジェクトのニーズに適したデータをキュレートする方法も必要です。これは、データの利用者がデータセットのリクエストを開始し、ITが数週間または数か月後にリクエストを実行するのを待つIT中心のモデルからの根本的な変化です。Dremioは、データの消費者がDremioのデータキュレーション機能を使用して、ITに依存せずにデータを共同で検出、キュレート、高速化、および共有するセルフサービスモデルを可能にします。

これらの機能はすべて、最新の直感的なWebベースのUIからアクセスできます。

  • 発見する。Dremioには、ユーザーが物理データセットと仮想データセットを検出して探索できる統合データカタログが含まれています。データカタログは、新しいデータソースが追加されたとき、およびデータソースと仮想データセットが進化したときに自動的に更新されます。すべてのメタデータは、高性能で検索可能なインデックスでインデックス付けされ、Dremioインターフェイス全体でユーザーに公開されます。
  • キュレート。Dremioを使用すると、ユーザーは仮想データセットを作成してデータをキュレートできます。さまざまなポイントアンドクリック変換がサポートされており、上級ユーザーはSQL構文を利用してより複雑な変換を定義できます。システムでクエリが実行されると、Dremioはデータについて学習し、結合やデータ型変換などのさまざまな変換を推奨できるようにします。
  • Dremioは、ソースシステムのパフォーマンスの最大1000倍までデータセットを高速化できます。ユーザーは、より高速である必要があると考えるデータセットに投票できます。Dremioのヒューリスティックは、加速するデータセットを決定する際にこれらの投票を考慮します。オプションで、システム管理者はどのデータセットを高速化するかを手動で決定できます。
  • Dremioを使用すると、ユーザーは他のユーザーやグループとデータを安全に共有できます。このモデルでは、ユーザーのグループが、特定の分析ジョブに使用される仮想データセットで共同作業を行うことができます。または、Excelスプレッドシートなどの独自のデータをアップロードして、エンタープライズカタログから他のデータセットに参加することもできます。仮想データセットの作成者は、仮想データセットをクエリまたは編集できるユーザーを決定できます。それはあなたのデータのためのグーグルドキュメントのようなものです。

Dremioデータアクセラレーションのしくみ

Dremioは、データリフレクションと呼ばれるソースデータの高度に最適化された物理的表現を利用します。 Reflection Storeは、HDFS、MapR-FS、S3などのクラウドストレージ、または直接接続ストレージ(DAS)上に存在できます。リフレクションストアのサイズは、物理メモリのサイズを超える場合があります。このアーキテクチャにより、Dremioはより多くのデータをより低コストで高速化できるため、従来のメモリのみのアーキテクチャと比較して、キャッシュヒット率がはるかに高くなります。データリフレクションは、クエリ時にコストベースのオプティマイザによって自動的に利用されます。

データリフレクションはエンドユーザーには見えません。OLAPキューブ、集計テーブル、およびBI抽出とは異なり、ユーザーはデータリフレクションに明示的に接続しません。代わりに、ユーザーは論理モデルに対してクエリを発行し、Dremioのオプティマイザーは、オプティマイザーのコスト分析に基づいてクエリに適したデータリフレクションを利用することにより、クエリを自動的に高速化します。

オプティマイザーがクエリを高速化できない場合、Dremioは高性能の分散実行エンジンを利用して、列指向のインメモリ処理(Apache Arrow経由)と基盤となるデータソースへの高度なプッシュダウン(RDBMSまたはNoSQLソースを処理する場合)を活用します。

DremioがSQLクエリを処理する方法

クライアントアプリケーションは、ODBC、JDBC、またはRESTを介してDremioにSQLクエリを発行します。クエリには、異なるデータソースに存在する可能性のある1つ以上のデータセットが含まれる場合があります。たとえば、クエリは、Hiveテーブル、Elasticsearch、および複数のOracleテーブル間の結合である場合があります。

Dremioは、クエリに必要な処理の量を減らすために2つの主要な手法を利用しています。

  • 基になるデータソースへのプッシュダウン。オプティマイザーは、基になるデータソースの機能と相対的なコストを考慮します。次に、ソースまたはDremioの分散実行環境のいずれかでクエリのステージを実行するプランを生成し、可能な限り最も効率的な全体的なプランを実現します。
  • データリフレクションによる加速。オプティマイザは、これが最も効率的な全体計画を作成するときに、クエリの一部にデータリフレクションを使用します。多くの場合、基になるデータソースでクエリを処理するよりも桁違いに効率的であるため、クエリ全体をデータリフレクションから処理できます。

クエリプッシュダウン

Dremioは、処理をリレーショナルおよび非リレーショナルデータソースにプッシュダウンすることができます。非リレーショナルデータソースは通常、SQLをサポートしておらず、実行機能が制限されています。たとえば、ファイルシステムは述語や集計を適用できません。一方、MongoDBは述語と集計を適用できますが、すべての結合をサポートしているわけではありません。Dremioオプティマイザーは、各データソースの機能を理解しています。最も効率的な場合、Dremioは可能な限り多くのクエリを基になるソースにプッシュし、残りは独自の分散実行エンジンで実行します。

運用データベースのオフロード

ほとんどの運用データベースは、書き込みが最適化されたワークロード用に設計されています。さらに、ダウンタイムやパフォーマンスの低下はビジネスに大きな影響を与える可能性があるため、これらの展開では厳格なSLAに対処する必要があります。その結果、運用システムは分析クエリの処理から分離されることがよくあります。このような場合、DremioはData Reflectionsを使用して分析クエリを実行できます。これにより、運用システムへの影響を最小限に抑えながら、可能な限り最も効率的なクエリ処理が提供されます。データリフレクションは、テーブルごとに構成できるポリシーに基づいて定期的に更新されます。

クエリ実行フェーズ

クエリの有効期間には、次のフェーズが含まれます。

  1. クライアントは、ODBC / JDBC / RESTを介してコーディネーターにクエリを送信します
  2. 計画
    1. コーディネーターはクエリを解析してDremioのユニバーサルリレーショナルモデルにします
    2. コーディネーターは、データソースで利用可能な統計を考慮して、クエリプランを作成し、ソースの機能を評価します。
  3. コーディネーターは、使用するクエリプランを書き直します
    1. データリフレクションの順序付け、分割、および配布を考慮した、利用可能なデータリフレクションおよび
    2. データソースの利用可能な機能
  4. 実行
  1. エグゼキュータは、ソースからArrowバッファにデータを並行して読み込みます
    1. エグゼキュータは、書き直されたクエリプランを実行します。
    2. 1人のエグゼキュータが1人以上のエグゼキュータからの結果をマージし、最終結果をコーディネータにストリーミングします
  1. クライアントはコーディネーターから結果を受け取ります

データは、データリフレクションまたは基礎となるデータソースから取得される場合があることに注意してください。データソースから読み取る場合、エグゼキュータは、計画フェーズでオプティマイザによって決定されたネイティブクエリ(MongoDB MQL、Elasticsearch Query DSL、Microsoft Transact-SQLなど)を送信します。

すべてのデータ操作はエグゼキュータノードで実行されるため、システムは、少数のコーディネータノードのみを使用して多数の同時クライアントに拡張できます。

クエリプッシュダウンの例

Data Fabricがデータアーキテクチャにどのように適合するかを説明するために、SQLをサポートしていないソースでSQLクエリを実行する方法を詳しく見てみましょう。

最も人気のある最新のデータソースの1つはElasticsearchです。Elasticsearchには好きなものがたくさんありますが、分析の観点からはSQL(SQL結合を含む)をサポートしていません。つまり、TableauやExcelなどのツールを使用して、このデータストア上に構築されたアプリケーションからのデータを分析することはできません。Elasticsearchで人気のあるKibanaという視覚化プロジェクトがありますが、Kibanaは開発者向けに設計されています。それは実際にはビジネスユーザー向けではありません。

Dremioを使用すると、Tableauを含むSQLベースのツールを使用してElasticsearchのデータを簡単に分析できます。たとえば、JSONに保存されているYelpビジネスデータの次のSQLクエリを見てみましょう。

州、都市、名前、review_countを選択します

elastic.yelp.businessから

どこ

  状態NOTIN( 'TX'、 'UT'、 'NM'、 'NJ')AND

  review_count> 100

ORDER BY review_count DESC、州、市

制限10

Dremioは、Elasticsearchが処理できる式にクエリをコンパイルします。