BIエンジニアでもデータウェアハウスを構築したい with Databricks

Azure DBXでデータウェアハウスを構築

結論：Azure DBX環境では、BIエンジニアでもSQL文を駆使したデータウェアハウスを構築できる。

構築したデータテーブルをデータソースとしたBIツール（PowerBI Desktop、PowerBI Service）の連携、可視化も問題なく機能しました。

以下、検証を通じて特に感じた3つのメリットについて記します。

(1) AIアシスタントの機能が秀逸

Azure DBXはDatabricks Assistantと呼ばれる開発者向けのAIアシスタントを標準機能として搭載しており、SQL文の生成やエラー修正に特化した支援ツールとして日本語の自然言語にも対応しています。

提案されたSQL文はそのままUnity Catalogに取り込んで編集ができるので、SQL文のコピーアンドペーストも不要です。

以下のサンプルは、売上に関するデータテーブル生成において、Databricks Assistantに自然言語でSQL文の作成支援を求めた際の画面イメージとなります。

SQL文を満足に書けないBIエンジニアにとっては非常にありがたい機能でした。

本機能で概観を掴んだ後に細部を修正していく過程でSQL文の知識も徐々に習得できました。

あらかじめノーコード/ローコードツールにおけるデータクレンジングの経験やスキルセットを有していれば、十分に実用的であると感じています。

(2) テーブル生成の処理速度が高速

今回の検証で使ったデータソースは、合計容量が約1.2GB・レコード数が約70万行でそこから1つのテーブルを作成しました。

そこまで大きなテーブルではありませんが、Power Queryでテーブルを作成する処理速度と比較すると、かなり速い印象（体感で3分の1程度）を持ちました。

Azure DBXは並列処理を得意とするSpark SQLを採用しているので、データソースやテーブルが複数になることで、より顕著な差になることが期待されます。

実際にテーブル作成までのリードタイムが短いことで、ストレス少なくトライアンドエラーができました。

(3) データ参照範囲（権限）を柔軟に制御可能

アクセス権限とロールの管理はデータウェアハウスの重要な機能です。

Azure DBXは、列レベルの権限と行レベルのアクセス許可（RLS）の2つの機能で参照範囲を制御します。

以下のサンプルは、売上に関するデータテーブルに対し、列・行それぞれのレベルで権限を付与する際の画面イメージとなります。

列レベルの権限については、任意のテキストに加えて正規表現の書換えも可能です。

組織の役割、例えば財務部門には“メールアドレスすべて”を、マーケティング部門には“ドメインだけ”を表示させるといった制御も可能です。

行レベルのアクセス許可だけでは難しかった、かゆい部分に手が届く制御を実現する一助となります。

おわりに

このように、BIエンジニアでもAzure DBXを使ってデータウェアハウスをSQL文で構築することができました。

高度なデータクレンジングと構造化に興味のあるBIエンジニアの方は一度Azure DBXに触れてみてはいかがでしょうか。

Azure DBXの生成AIについては弊社で利用者向けの記事も提供しているので、ぜひご覧ください。

※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。