BlazingSQLは、NVIDIA RAPIDSエコシステム上に構築されたGPUアクセラレーションSQLエンジンです。様々なETL大規模データセット向けのSQLインターフェースを提供し、完全にGPU上で動作します。先日、開発チームはBlazingSQLがApache 2.0ライセンスの下で完全にオープンソース化されたことを発表しました。

オープンソースプロジェクトのアドレス:

https://github.com/blazingdb/pyBlazing/

BlazingSQL は、NVIDIA RAPIDS エコシステム上に構築された GPU アクセラレーション SQL エンジンです。RAPIDS には、GPU 上でエンドツーエンドのデータサイエンス計算と分析パイプラインを実行するためのソフトウェアライブラリセット (BlazingSQL、cuDF、cuML、cuGraph) が含まれています。RAPIDS は Apache Arrow 列指向ストレージ形式をベースとしており、cuDF はデータの読み込み、結合、集計、フィルタリング、操作を行う GPU DataFrame ライブラリです。BlazingSQL は cuDF への SQL インターフェイスであり、大規模なデータサイエンス ワークフローとエンタープライズ データセットをサポートする幅広い機能を提供します。

公式の説明によると、BlazingSQLは（ほぼ）あらゆるデータを処理できるとのことです。以前はBlazingDBという名前でしたが、データベースではなかったため、開発チームによってBlazingSQLに改名されました。

BlazingSQL の主な機能:

• 外部ストレージ データのクエリ: Amazon S3 などのリモート ストレージ ソリューションを登録するには、1 行のコードだけが必要です。
• シンプルな SQL: 非常に使いやすく、SQL クエリを実行するだけで GPU DataFrames (GDF) クエリの結果を取得できます。
• 相互運用性: どの RAPIDS ライブラリでも、クエリされた GDF にアクセスし、あらゆるデータ サイエンス ワークロードに使用できます。

• 高価:大規模なデータ サイエンスの研究では、通常、数千台のサーバーのクラスターが必要ですが、BlazingSQL + RAPIDS では、同じワークロードを実行するのに必要なインフラストラクチャのほんの一部しか必要ありません。
• 速度が遅い:大規模なデータセットでワークロードとクエリを実行すると、数時間から数日かかることがありますが、GPU アクセラレーションを備えた BlazingSQL + RAPIDS では数秒で結果を生成できるため、データ サイエンティストは新しいモデルを迅速に反復できます。
• 複雑さ：データサイエンスのワークロードは、多くの場合、小規模なデータセットに基づいてプロトタイプを作成し、その後、分散システム向けに再構築されます。BlazingSQL + RAPIDS を使用すると、ユーザーはコードを一度記述するだけで、わずか 1 行のコードで分散クラスターのサイズを動的に変更できます。

開発チームは、SQL がこれまですべての主要な分析エコシステムの基礎であり、RAPIDS が次世代の分析エコシステムであり、BlazingSQL が RAPIDS の SQL 標準であると考えています。

BlazingSQLはcuDFとcuIOをベースに構築されており、これらのプロジェクトの新機能はBlazingSQLの機能とパフォーマンスに直接影響を与えます。さらに、BlazingSQLはGDF上で動作するため、すべてのRAPIDSライブラリと100%相互運用可能です。

RAPIDS を使用している場合、または RAPIDS の使用を検討している場合、BlazingSQL は次のようなさらなる利便性を提供します。

• コードの複雑さを軽減: SQL ステートメントは非常にシンプルで、数十から数百の cuDF 関数呼び出しを 1 つのステートメントに置き換えることができます。
• データ レイクに接続:他のデータベースを同期する必要がなくなり、BlazingSQL はクラウドまたはネットワーク ファイル システム内の任意の生のファイルをクエリできます。
• RAPIDS の高速化:より高度な SQL オプティマイザーにより、RAPIDS テクノロジー スタックがよりスマートに実行されます。

現在、BlazingSQL+RAPIDS は Google Colab で利用可能です。開発チームは GCP 上に、Spark 用と BlazingSQL 用の 2 つの同価格帯のクラスタを構築しました。これらのクラスタ上で、データレイクから ETL/特徴量エンジニアリング、そして XGBoost トレーニングに至るまで、エンドツーエンドのデータ分析ワークロードを実行し、Spark と BlazingSQL のパフォーマンス比較テストを実施しました。

開発者たちは、2,000万行を超えるNetflowデータに対して、同じワークロードを2回実行しました。まずBlazingSQL + RAPIDSを実行し、次にPySpark (Spark 2.4.1)を使用して再度実行したところ、以下の結果が得られました。

Google ドライブから CSV をそれぞれの DataFrame にロードするのにかかる時間を考慮すると、 BlazingSQL は Spark よりも 71 倍高速です。

ETL 時間だけを見ると、 BlazingSQL と Rapids は Spark よりも 100 倍高速です。

次の Colab デモを実行して、無料の NVIDIA T4 GPU リソースを使用して同じテストを実行し、BlazingSQL の実際のパフォーマンスを確認します。

https://colab.research.google.com/drive/1EbPE9FwFur7fE2054BH9s23Kd0FiUgGo

報道によると、BlazingSQLのパフォーマンス向上の大部分は、チームの内部エンジンプロジェクトによるものです。BlazingSQLチームのエンジニアは、「SIMD Expression Interpreter」と呼ばれる、GPU DataFrames（GDF）専用に構築されたGPU実行カーネルの開発を目指しました。開発チームは、いくつかの重要なステップを通じてパフォーマンス向上を実現するSIMD Expression Interpreterの詳細を公開しました。

1. GDF 列やリテラルを含む複数の入力を受け入れ、近い将来に関数がサポートされる予定です。
2. これらの入力をロードするときに、SIMD 式インタープリタは GPU レジスタの割り当てを最適化し、GPU スレッドの使用率を最適化してパフォーマンスを向上させることができます。
3. 仮想マシンはこれらの入力を処理し、複数の出力を生成します。次のSQLクエリがあるとします。

テーブルAからcolA + colB * 10 、sin(colA) - cos(colD)を選択します。 

現在、SIMD 式インタープリターは BlazingSQL でフィルタリングと投影をサポートしているため、多くの主流の SQL クエリに影響を与えています。

BlazingSQL を使用して Amazon S3 内の CSV ファイルをクエリするためのサンプル コード:

 BlazingsqlからBlazingContextをインポートする
bc = ブレイジングコンテキスト() 
 
 bc.s3( 'dir_name' , bucket_name= 'bucket_name' , access_key_id= 'access_key' , secrect_key= 'secret_key' ) 
 
 # CSVからテーブルを作成する
bc.create_table( 'タクシー' , '/dir_name/taxi.csv' ) 
 
 # クエリ
結果 = bc.sql( 'SELECT count(*) FROM taxi GROUP BY year(key)' ).get()
 result_gdf = 結果.列
 
 #GDF を印刷
印刷(result_gdf)

BlazingSQL のその他の操作方法については、以下を参照してください。

GitHub プロジェクト リンク: https://github.com/blazingdb/pyBlazing/

公式サイト: https://docs.blazingdb.com/docs/using-blazingsql