Databricks SQLステートメント実行APIの一般提供(GA)を開始しました！

翻訳：Saki Kitaoka.  -  Original Blog Link

本日、AWS および Azure 上で Databricks SQL ステートメント実行 API の一般提供を開始することを発表します。このAPIを利用することで、REST API経由でDatabricks SQLウェアハウスに接続し、Databricks Lakehouse Platformが管理するデータにアクセスして操作することができます。

このブログでは、API の基本を説明し、GA リリースで新たに利用可能になる主要機能について説明し、 Databricks Python SDK を使用してステートメント実行 API を使用したデータアプリケーションを構築する方法を紹介します。Databricksワークスペースに対してコードを実行することで、そのコードを追跡することもできます。その他の例として、前回のブログでは、Statement Execution API と JavaScript を使用してスプレッドシートでデータを活用する方法を紹介しました。

ステートメント実行APIの概要

BI アプリケーションはデータウェアハウスの主要なユースケースの一つであり、Databricks SQL はドライバ、コネクタ、および既存の BI ツールとのネイティブ統合による豊富な接続エコシステムを提供します。とはいえ、Databricks Lakehouse Platform が管理するデータは、eコマースプラットフォーム、CRM システム、SaaS アプリケーション、または顧客が社内で開発したカスタムデータアプリケーションなど、BI 以外のアプリケーションやユースケースにも関連しています。多くの場合、これらのツールは標準的なデータベースインターフェイスやドライバを介して簡単に接続することはできませんが、ほとんどすべてのツールやシステムはREST APIで通信することができます。

Databricks SQLステートメント実行APIを使用すると、HTTP上で標準SQLを使用して、幅広いアプリケーション、テクノロジー、およびコンピューティングデバイスとの統合を構築することができます。この API は、SQL 文を SQL Warehouse に送信して実行し、結果を取得するためのエンドポイント群を提供します。下図は典型的なデータフローの概要です。

 

 

APIを使用して、お好みのツールや言語でカスタムデータアプリケーションを構築できます。例えば、ビジネス・ユーザーがユーザー・インターフェースを通じてクエリ条件を提供し、その結果を可視化、ダウンロード、またはさらに分析するためのウェブ・アプリケーションを構築できます。また、APIを使用して、特定のユースケースやマイクロサービスに適合する特別な目的のAPIを実装したり、選択したプログラミング言語でカスタムコネクタを構築したりすることもできます。これらのシナリオでAPIを使用する場合の大きな利点の1つは、ドライバをインストールしたりデータベース接続を管理したりする必要がないことです。

GAリリースで利用可能な新機能

AWSとAzureでAPIが一般的に利用できるようになるのに伴い、いくつかの新機能と改善が可能になります。

• パラメータ化されたステートメント - 型安全なパラメータを使用して、SQL クエリに動的なリテラル値を安全に適用します。リテラル値はSQLコードとは別に扱われるため、Databricks SQLはユーザーから提供された変数とは別にコードのロジックを解釈し、一般的なSQLインジェクション攻撃を防ぐことができます。
• 結果の保持 - ステートメントの結果を最大 1 時間まで複数回取得できます。以前は、最後のチャンクが読み込まれると結果は利用できなくなり、チャンクを並列にフェッチする際に最後のチャンクを特別に扱う必要がありました。
• 複数の結果フォーマット - JSON_ARRAYとCSVフォーマットがEXTERNAL_LINKS処分で使用できるようになりました。パフォーマンスを最適化するためにArrow を使用することは可能ですが、JSONとCSVはツールやフレームワークでより広くサポートされており、相互運用性が向上しています。
• バイトと行の制限 - 予期しない大きな出力を防ぐために、結果に制限を適用します。APIは、指定された制限を超えるたびに切り捨てフラグを返します。

次のセクションでは、ステートメント実行APIの上にカスタムAPIを構築するために、これらの新機能を使用してさらに詳しく説明します。

 

専用APIの構築

今年の Data+AI Summitでは、この新しいステートメント実行APIを使ってDatabricks Lakehouse Platform上でカスタムAPIを構築する手順を紹介しました。今回は、Acme, Inc.という架空の会社のために、シンプルなウェブサイトとサービスのバックエンドを開発します。最初のステップとして `setup.sh`スクリプトを実行します。

Acme, Inc.は様々な種類の機械部品を販売する100の店舗を持つ中規模企業です。Databricks Lakehouse を活用して各店舗の情報を追跡し、メダリオンアーキテクチャで販売データを処理しています。店舗管理者がゴールドの販売データや店舗情報を簡単に閲覧できるウェブアプリケーションを作成したいと考えています。さらに、店舗管理者が通常のPOSを経由しなかった売上を挿入できるようにしたいと考えています。このシステムを構築するために、カスタムデータAPIを公開するPython Flaskアプリケーションと、そのAPIを呼び出してデータを読み書きするHTML/JQueryフロントエンドを作成します。

全店舗をリストアップするカスタムAPIエンドポイントと、それがバックエンドのステートメント実行APIにどのようにマッピングされるかを見てみましょう。これは引数を取らない単純なGETリクエストです。バックエンドは SQL Warehouse に静的な SELECT 文を呼び出して `stores` テーブルを読み取ります。

 

Acmeには100店舗しかないため、高速なクエリと小さなデータセットのレスポンスを期待しています。そのため、Databricksに同期リクエストを行い、店舗データの行をインラインで返すことにしました。同期リクエストにするために、`wait_timeout` パラメータを設定し、レスポンスが返ってくるまで最大50秒待つことを指定し、それ以上かかる場合はクエリをキャンセルするように `on_wait_timeout` パラメータを設定しました。Databricks からのレスポンスを見ると、デフォルトの結果 `disposition` と `format`  が JSON 配列にインラインでデータを返すことがわかります。Acmeのバックエンドサービスは、そのペイロードをリパッケージしてカスタムAPIの呼び出し元に返すことができます。

このカスタムエンドポイントの完全なバックエンドコードはここにあります。フロントエンドでは、カスタムエンドポイント `/api/1.0/stores` を呼び出してストアのリストを取得し、ここでJSON配列を反復処理することでストアを表示します。この2つで、AcmeはDatabricks SQLに支えられた新しいホームページを持つことになります！

 

また、各店舗について、直近の売上を表示するページを用意し、店舗管理者が店舗データ一式をダウンロードできるようにしたいと考えています。店舗ごとの売上トランザクションの数は、店舗数よりも何桁も多くなる可能性があります。このカスタムAPIエンドポイントの要件は以下の通りです：

• 限られた出力 - 呼び出し側は、すべてのデータを常に取得する必要がないように、返される売上件数を制限できなければなりません。
• マルチフォーマット - 結果をウェブページに簡単に表示したり、エクセルのようなツールでオフライン処理するためにダウンロードできるように、複数のフォーマットで取得できる必要があります。
• 非同期 - 店舗の売上情報を取得するのに時間がかかる可能性があるため、非同期である必要があります。
• 効率的な抽出 - パフォーマンスと安定性の理由から、大きな売上データはバックエンドのウェブサーバから取得するべきではありません。

以下に、Databricks SDK for Pythonを使用してステートメント実行APIを呼び出す方法を示します。全コードはこちらです。

 

最初の2つの要件を満たすために、カスタムAPIから`row_limit` と `format` パラメータを公開し、ステートメント実行APIに渡します。これにより、呼び出し元はクエリが生成する行の総数を制限したり、結果の形式（CSV、JSON、Arrow）を選択したりできるようになります。

カスタムAPIを非同期にするために、ステートメント実行APIの `wait_timeout` パラメータを0秒に設定します。つまり、Databricks はステートメント ID とクエリ状態を即座に応答します。このステートメント ID を `request_id`として、ステートメント状態と共に呼び出し元への応答にパッケージします。クライアントがリクエスト ID と状態を取得すると、同じカスタム API エンドポイントをポーリングして実行状況を確認することができます。エンドポイントは `get_statement` メソッド経由で Databricks SQL Warehouse にリクエストを転送します。クエリが成功すると、API は最終的に `SUCCEEDED` 状態と  `chunk_count` を返します。チャンクカウントは、結果がいくつのパーティションに分割されたかを示します。

効率的な抽出（4番目の要件）を達成するために、EXTERNAL_LINKS dispositionを使用しました。これにより、各チャンクに対して事前に署名されたURLを取得することができ、`request_id` と `chunk_index`.が与えられるとカスタムAPIがそれを返します。

これを使用して、Acme に各店舗のランディングページを作成し、最新の売上を表示することができます。しかし、ページの上部に「ダウンロード」ボタンを追加して、ストアマネージャーがすべての売上の履歴データを引き出せるようにすることもできます。その場合、制限を設けず、CSV形式を活用することで、好きな分析ツールに簡単に取り込むことができます。ブラウザはクエリが成功し、チャンクの総数を取得すると、カスタムAPIを並行して呼び出し、事前に署名されたURLを取得し、クラウドストレージからCSVデータを直接ダウンロードします。EXTERNAL_LINKS処分は、逐次インライン読み取りよりも抽出スループットが12倍向上したCloud Fetchテクノロジーを活用しています。下の例では、500MBを160Mbpsで並行してダウンロードしました。

 

店舗の売上を表示できるようになったので、Acmeチームは新しい売上情報をLakehouseに挿入できるようにする必要があります。そのために、 /api/1.0/stores/storeId/sales endpoint へのPOSTリクエストでバックアップされたシンプルなWebフォームを作成します。フォームのデータをLakehouseに取り込むために、パラメータ化されたSQL文を使用します。

 

And supply the input from the web form to the Statement Execution API using the `parameters` list argument with a name, value, and type for each parameter:

SQL WarehouseエンジンはSQLコードを解析した後、提供されたパラメータをリテラルとしてクエリプランに安全に代入します。これにより、悪意を持って注入されたSQL構文がSQLとして解釈されることを防ぎます。各パラメータの "type "フィールドは、提供された "value "の型の正しさをチェックすることで、さらなる安全性を提供します。悪意のあるユーザが数量フィールドの入力として "100); drop table sales"のような値を提供した場合、INSERT INTO文は以下のエラーとなり、実行されません。

ここでは、 `POST /api/1.0/stores/store_id/sales`エンドポイントの一部として使用するパラメータをどのように配置したかを見ることができます。ウェブフォームへの入力が正しいタイプで有効であれば、ユーザーが "Submit" をクリックした後、売上テーブルが正常に更新されます。

このカスタムAPIを繰り返し使用したり、Databricks Lakehouse Platform上で独自のカスタムデータアプリケーションを構築する足がかりとして使用することができます。この記事で使用したサンプルコードや、サンプルテーブルを作成する`setup.sh` スクリプトをご自身の Databricks 環境で使用するだけでなく、Data+AI Summit でのライブ説明 - 以下のビデオ - もご覧ください。

Databricks SQL ステートメント実行 API の使用を開始するには

Databricks SQL 文実行 API は、Databricks Premium および Enterprise Tier で利用可能です。既に Databricks アカウントをお持ちの場合は、チュートリアル (AWS | Azure)、ドキュメント (AWS | Azure)、またはコードサンプルのリポジトリ(r repository)をご覧ください。まだ Databricks をご利用でない場合は、無料トライアル(free trial)にサインアップしてください。

Try Databricks Now!