分散SQLビッグデータクエリエンジンの開発

導入

大まかに見ると、多くのデータおよび分析ソリューションは長年にわたって同じ方法で構築されてきました。つまり、これはさまざまな統合プロセスで構成され、すべてのデータを中央の場所にロードします。これは、今後のデータ モデリングと分析のユース ケースの唯一の真実のソースです。以前は、これらの中央の場所は主に高価で柔軟性に欠ける、密に結合されたハードウェア/ソフトウェア システムでしたが、今日では、コンピューティングとストレージの分離を含むクラウドと分散アーキテクチャを活用するのが一般的です。しかし、近年の驚異的な技術進歩にもかかわらず、データを最も効果的に活用し、適切なデータ管理を実践するには、データを一元管理する総合的なアプローチが最も明白な方法であることに変わりはありません。

[[354288]]

中央集権化

では、この集中型アプローチの何が問題なのでしょうか?そもそも分散クエリ エンジンとどのように関係しているのでしょうか?

まず、反対する点は何もありません。実際には、まったく逆のことが真実です。多くの場合、すべてのデータをクリーンで最新の状態で 1 か所にまとめた大規模なデータ ウェアハウスまたはデータ レイクを構築することが、一貫性を確保して全員が同じ定義を使用する唯一の方法です。この点において、特に Microsoft の Azure Data Lake Storage や Amazon Web Service の S3 などのクラウド データ レイク サービスは、あらゆる種類の大量のデータを非常に柔軟かつ安価に保存できるため、集中化の利点をさらに高めるという興味深い工夫が施されています。

予防

しかし、すべてのデータを一元管理することがますます困難になっている理由は数多くあります。データ ソースの数は増加しており、そのデータに依存するさまざまなビジネス領域の増加に対応するために必要なデータ セットの汎用性も高まっています。多くの場合、ビジネス ユーザーは、静的で事前に構築されたデータ セットではなく、より高い柔軟性を必要とするデータに近づいています。高度な分析のユースケースでも同様であり、多くの場合、生の未変換データにメソッドを適用する必要があります。さらに、場合によっては、内部または外部の規制により、組織がデータの移行を禁止されることもあります。他のケースでは、集中化されたデータの上にパイプラインが存在し、それを下流のシステムにさらにロードして、すべての分析要件を満たすことができます。これにより、従来のオンプレミス システムと同じようなロックインが発生する可能性もあります。あるいは、データを一元管理するだけでは作業に見合わない場合や、データが大きすぎて移動に時間がかかりすぎる場合などにも使用できます。等々…

では、このような状況ではどうすればいいのでしょうか?

連邦政府

今日、分析ソリューションとそのデータ管理に関しては多くの選択肢があります。さまざまなプロバイダーが提供するサービスだけでなく、テクノロジーの多様性も圧倒的で、テクノロジーの進歩はかつてないほど速く進んでいます。どちらが勝者かは明らかではありませんが、間違いなく、より多くのデータカロリーを有用なものに変えるのに役立つでしょう。その点については疑いの余地はありません。しかし、データの爆発的な増加に対処するのに役立つ SQL ベースの分散クエリ エンジンへの傾向が明確に現れているようです。これにより、既存のデータおよび分析サービス プロバイダーの製品ラインナップと最新の開発状況も確認できます。これらはすべて、コスト効率の高いクラウド ストレージをシームレスに統合し、まったく同じクエリ エンジンを使用してインタラクティブな SQL クエリを実行できるようにしようとしています。そのため、前述の不足しているギャップを埋めることができ、成熟した企業は、真実の中核となる情報源を維持することで組織とプラットフォームの安定性を維持しながら、拡張されたビッグデータ機能を実現できます。

データ仮想化

分散クエリ エンジンの基本的な考え方は、データの仮想化と、さまざまなデータ ソース間でデータ アクセスを提供する抽象化レイヤーを作成するという試みに他なりません。従来のデータ仮想化ソフトウェア (Linked Server、DBLink など) との違いは、スケールアウト方式でリレーショナル データと非リレーショナル データを一緒にクエリして、クエリ パフォーマンスを向上できることです。したがって、「分散」という言葉は、クエリ自体だけでなく、計算とストレージも指します。これらは基本的に集中的な OLAP クエリ用に設計されているため、パフォーマンスの点ではそれほど脆弱で一貫性がありません。

Hadoop 上の SQL

この目的で使用されるテクノロジーは、もともと SQL-on-Hadoop と呼ばれていましたが、現在でもよく呼ばれており、MPP (超並列処理) エンジンに依存しています。使い慣れた SQL のような言語を使用して HDFS (Hadoop Distributed File System) に保存されたデータをクエリおよび分析できるため、MapReduce/Tez の複雑さが隠され、データベース開発者にとってアクセスしやすくなります。 Hive は Hadoop 上の最初の SQL エンジンであると言っても過言ではありません。長年にわたって非常に強力であることが証明されているため、Hive は現在でもバッチ形式のデータ処理に広く使用されています。 Hive は SQL クエリを複数のステージに変換し、中間結果をディスクに保存します。同時に、Impala などの他の専用ツールも Hadoop エコシステムでネイティブに開発されており、データ ソースとしての HBase の使用もサポートしています。 Hive と比較すると、メモリとキャッシュ技術を活用し、長時間実行されるバッチ ジョブよりもインタラクティブな分析に適しています。このカテゴリの別の例としては、SparkSQL があります。これらすべてには、ビューや外部テーブルなどの読み取りスキーマとも呼ばれる事前に作成されたメタデータ定義が必要です。この定義は、Hive メタストアなどの集中ストレージに保存されます。

あらゆるものに対するSQL

テクノロジーが進化するにつれて、よりオープンな環境が必要となり、Hadoop に厳密に縛られることなく、他の多くの種類のデータベースを疎結合でサポートする必要性が高まっています。これにより、クエリ エンジンは、広範な前提条件や準備を必要とせずに、大量のデータに対してプラグ アンド プレイ検出を実行できるようになります。さらに、標準の ANSI SQL がインターフェースとして提供されているため、データ アナリストや開発者が簡単にアクセスできます。同時に、スキーマを事前に定義する必要はなく、一部のエンジンではプッシュダウン クエリ (Drill など) を通じて元のストレージ レイヤーでスキーマを自動的に解決することもできます。この分野におけるもう一つの先駆的なツールは Presto で、Kafka や Redis からのリアルタイムのストリーミング データをクエリすることもできます。 Presto は、この需要に応え、さまざまなデータ セットにわたるインタラクティブな分析を可能にするために Facebook によって開発された、メモリ内分散 SQL クエリ エンジンです。 Netflix、Twitter、Airbnb、Uber などの企業にとって、これは日常業務に不可欠であり、そうでなければペタバイト単位のデータを処理および分析することはできません。 Presto は、Power BI、Looker、Tableau、Superset、その他の ODBC および JDBC 準拠ツールなど、さまざまな BI ツールで使用できます。この文脈において、「SQL-on-Anything」という名前が初めて生まれました。

データレイクエンジン

データ レイク エンジンの技術的なアプローチもそれほど変わりません。結局のところ、それは単にデータの仮想化と、さまざまなソースからのデータの結合にすぎません。通常、データ モデリング、データ変換、データ行数、データ セキュリティに関するより多くの機能を提供する点が異なります。これらは通常、よりクラウド指向であり、豊富なユーザー インターフェイスを備えていると考えられており、技術に詳しくないユーザーにデータのセルフ サービスの感覚をもたらします。このアプローチにより、パブリック クラウドのデータの集中化を最大限に活用し、クラウドの価格弾力性により、ロックイン リスクなしに低コストでインタラクティブな分析が可能になります。データ レイク エンジンも、必ずしもより多くのデータ ソースをサポートしているわけではありませんが、後から登場したため、最新のテクノロジーを徹底的に活用できます。たとえば、Databricks は最近、Delta エンジンを搭載し、データ レイク上の Delta Lake テーブルを直接クエリできる SQL Analytics をリリースしました。さらに、データ探索用の SQL ネイティブ インターフェイスを提供し、ダッシュボードを相互に共有できます。この点で非常に有望なもう 1 つのツール (そして私のお気に入りの 1 つ) は Dremio です。これは主にオープン ソースですが、同名の会社によってサポートされており、いくつかの追加機能を備えた商用エンタープライズ バージョンを提供しています。

従来の多層アーキテクチャとは対照的に、Dremio は BI ツールとクエリ対象のデータ ソース システムの間に直接の橋渡しを構築します。舞台裏で使用されている主なテクノロジーは、ドリル、アロー、方解石、寄木細工です。この組み合わせにより、さまざまなデータ ソースに対してスキーマフリーの SQL が提供され、プッシュダウン機能と簡単なクエリ マテリアライゼーションを備えた列指向のメモリ内分析実行エンジンによってクエリ パフォーマンスが向上します。ちなみに、Arrow はメモリ プロファイリングの事実上の標準と見なされています。

結論は

結局のところ、データを物理的に集中させるかどうかはユースケースによって完全に決まり、このようなエンジンはデータが実際にどこに存在するかを照会することで代替ソリューションを提供します。同様に、このようなクエリ エンジンがすべてのソリューションに適合しているように見えても、そのままでは解決できず、マイクロサービス アーキテクチャに基づく一時データはもちろんのこと、データ統合プロセスと適切なデータ モデリングが必要となるユース ケースが依然として存在します。また、古い分散クエリ エンジンは Hive ほど急速には廃止されず、既存の多くのデータ アーキテクチャとうまく連携し、ほとんどの最新テクノロジとシームレスに統合されることにも留意することが重要です。将来がどうなるか見てみましょう。