LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

Apache Supersetの基本構成とSQL Lab

Apache Superset^*1とは、Apache Software Foundationが開発するオープンソース（OSS。ソースコードが公開され改変・再配布が可能なソフトウェア）のデータ可視化・データ探索プラットフォームを指します。SQLを直接実行できるSQL Labと、ノーコードでチャートを組み立てる画面の両方を備え、エンジニアとビジネス部門の双方が同じ基盤でデータに触れられる点が特徴です^*1。

SQL Labは、接続済みのデータベースに対してSQL文を実行し、結果をその場で確認できるクエリエディタです^*2。ここで実行した単発クエリはチャートやダッシュボードのフィルタ条件を引き継がないため、あくまで調査・検証用の位置づけになります^*2。SQL Labで書いたクエリはそのまま保存し、後述するデータセットの定義に転用できます。

チャートを作成する前に、Supersetではデータセットを用意する必要があります^*3。データセットは最も単純な形ではデータベース内の1テーブルを指しますが、計算列を追加したり、複数テーブルを参照する複雑なSQL文からデータセットを作成することも可能です^*3。データセットの列定義がチャート作成時の選択肢（ディメンション・メトリクス）に反映される仕組みです。

チャートは、データセットに対して集計方法・グラフ種別・フィルタなどを設定して作った可視化の単位です^*4。Superset内部ではチャートを「スライス」と呼び、クエリ・グラフ種別・選択したオプション・名称などの情報をひとまとめに保存します^*4。複数のチャートを1画面に配置したものがダッシュボードで、フィルタを画面全体に適用したり、レイアウトを自由に組んだりできます。

対応データソースと接続の仕組み

Supersetの強みの一つは、対応するデータソースの幅広さです。公式ドキュメントでは81種類のデータベースへの接続実績が案内されており、Presto・Trino・Apache Hive・Apache Spark SQLといった分散SQLクエリエンジン、Databricks、PostgreSQL（Aurora PostgreSQL・Google AlloyDB・Supabase・Neon等の互換サービスを含む）などが例示されています^*5。Pythonのデータベースドライバ（DB-API）とSQLAlchemyダイアレクトが存在するデータストアであれば、原理的に接続対象になります^*5。

接続作業は大きく2段階です。第一に、対象データベース用のドライバをインストールします。Docker環境では`requirements-local.txt`に追記し、それ以外の環境では`pip install`コマンドでドライバを追加します^*5。第二に、管理画面の「Settings」からデータベース接続を新規作成し、SQLAlchemy URI（接続文字列）を入力して接続テストを行います^*5。

なお、Superset自体の管理情報（ユーザー・ダッシュボード定義・権限設定など）を保存するメタデータベースと、可視化対象の分析用データベースは別の概念です。メタデータベースはMySQL・PostgreSQL・SQLiteでのテスト実績があり、本番運用ではこれらのいずれかを使う想定になっています^*6。分析対象のDWH（データウェアハウス）と管理用DBを混同しないよう、構築時に切り分けて設計する必要があります。

チャートとダッシュボードの作成手順

チャート作成では、まずデータセットを選び、画面左側に表示される列・メトリクスの一覧から可視化に使う項目を選びます^*4。グラフ種別（棒グラフ・折れ線・ピボットテーブルなど多数のプリセットから選択）を決めたら、下部のデータプレビューで集計結果を確認しながら調整していく流れです^*4。この段階でフィルタや期間指定を加えれば、ダッシュボードに配置したときの初期表示も定まります。

個々のチャートが完成したら、ダッシュボード画面でドラッグ＆ドロップにより配置します。タブ分割やクロスフィルタ（1つのチャートでの選択が他のチャートにも反映される仕組み）も設定可能で、経営層向けの単一画面から現場向けの詳細画面まで、用途に応じた画面構成を組めます。ここまでの操作はノーコードで完結しますが、集計ロジックが複雑な場合はデータセット側でSQLをカスタマイズする判断が必要になり、SQLとBIツールの双方の知識が要求される場面です。

行レベルセキュリティと権限ロール設計

Apache Supersetとは、部署やクライアントごとに閲覧できる行を制限する仕組みも備えたBIツールを指し、これを行レベルセキュリティ（Row Level Security、RLS）と呼びます^*7。RLSはデータセットの単位で適用され、ユーザーが紐づくロールに応じてSQLのWHERE句が自動的に追加される仕組みです^*7。同一テーブルを参照する複数のダッシュボードであっても、ロールが異なれば見える行が変わります。

複数のRLSルールが同じロールに適用された場合は、それぞれのWHERE句がAND条件で結合されます^*7。たとえば「client_id=4」と「client_id=5」という2つのルールを同じロールに設定すると、両方を同時に満たす行は存在しないため結果が常に空になってしまう点は、設計時に留意が必要な仕様です^*7。

権限管理はロールベースで行われ、標準ロールとしてAdmin・Alpha・Gammaの3種類が用意されています^*8。Adminは他ユーザーへの権限付与・剥奪を含むすべての操作が可能です^*8。Alphaは全データソースにアクセスできデータソースの追加・変更も行えますが、他ユーザーへの権限付与はできません^*8。Gammaはアクセスを許可されたデータソースのみを閲覧できる、主に閲覧者向けのロールです^*8。Alpha・Gammaともにデータベース単位でのアクセス許可が個別に必要で、Adminのようにすべてのデータベースへ自動的にアクセスできる訳ではありません^*8。これらの標準権限は`superset init`コマンド実行時に同期される仕組みです^*8。

埋め込み（Embedded）機能で自社サービスに統合

Supersetのダッシュボードは、`@superset-ui/embedded-sdk`というSDKを使って自社サービスの画面内にiframeとして組み込めます^*9。ホスト側のアプリケーションで`embedDashboard`関数を呼び出し、ダッシュボードID・Supersetのドメイン・マウント先・ゲストトークンを取得する関数を指定する構成です^*9。

埋め込みを使うには、管理画面で`EMBEDDED_SUPERSET`という機能フラグを有効にする必要があります^*9。認証にはゲストトークンという専用のトークンを使い、エンドユーザーがSuperset自体にログインしなくても閲覲できる仕組みです^*9。ゲストトークンはサーバー側から`POST /security/guest_token`エンドポイントを呼んで発行し、クライアント側コードから直接呼び出さないことが前提になっています^*9。ゲストトークンには有効期限があり、リクエスト時に行レベルセキュリティのルールを含めることも可能です^*9。自社SaaS（Software as a Service。ソフトウェアをサービス形式で提供する形態）にダッシュボード機能を持たせたい場合に使う選択肢の一つです。

商用BIツールとの使い分け

Superset^*1のようなOSS BIと、商用のBIツールとでは、コスト構造・運用責任の所在・拡張性の考え方が異なります。どちらを選ぶかは、社内にSQLとインフラの両方を扱える体制があるかどうかで変わってくる判断です。以下に主な違いを整理します。

セルフホスト運用で発生する作業

Supersetはソフトウェア自体が無償である一方、動かすためのサーバー・データベース・認証基盤は自社で用意する前提です。本番運用では、Webサーバー層・非同期処理を担うワーカー・キャッシュ層・メタデータベースなど、複数のコンポーネントを組み合わせて構成します。構成要素が増えるほど、監視対象やバージョンアップ時の確認範囲も広がります。

セルフホストを内製で担うには、SupersetのPython/Flaskベースのアプリケーション構成の理解、コンテナ運用やインフラ構築の知識、そしてSQL・データモデリングの知識という複数領域の専門性が必要です。加えて、行レベルセキュリティやロール設計を業務要件に合わせて詰める工程では、業務側のアクセス権限ルールをヒアリングしながらSQL条件に落とし込む調整力も求められます。

運用フェーズでの見落としを甘く見ると、想定外の影響が生じます。たとえば行レベルセキュリティの設定を誤ると、閲覧範囲が意図せず広がって機密性の高いデータが他部署から見える状態になったり、逆に条件が競合して該当ロールの利用者に何も表示されなくなったりする可能性があります^*7。バージョンアップ時に設定の互換性を確認せずに適用すると、ダッシュボードが正しく表示されなくなる事態も想定しておく必要があります。

外注と内製の判断軸

Apache Supersetを内製で構築・運用する場合と、外部パートナーに委託する場合とでは、必要になる体制が異なります。内製で完結させるには、インフラ構築・SQLモデリング・権限設計・障害対応を横断して担える人員を継続的に確保する必要があります。特定の担当者に知識が集中すると、退職や異動の際に運用が止まるリスクも抱えることになるでしょう。

外部パートナーに委託する場合は、要件定義からデータセット設計、RLSを含む権限設計、埋め込み実装まで一括して依頼できる点が違いです。運用フェーズにおいても、監視・バージョンアップ対応・障害時の切り戻しといった業務を継続的に任せられます。委託先の選定では、OSS BIのセルフホスト構築実績があるか、行レベルセキュリティのような業務要件を伴う設定の経験があるかを具体的に確認するのが妥当な進め方です。

LASSIC IT事業部では、元請（プライムベンダー）としてシステムの受託開発・保守運用を担う体制を整えています。BIダッシュボードの新規構築だけでなく、既存の可視化基盤の運用保守や、権限設計・埋め込み実装といった個別工程の切り出し委託にも対応可能です。自社のデータ活用体制と照らして、どこまでを内製で担い、どこから外部に委ねるかを整理する材料として、まずは現状の構成を相談することをおすすめします。

まとめ：Superset構築を判断する3つの軸

本稿では、Apache SupersetによるBIダッシュボード構築の基本構成と、商用BIとの違い、外注・内製の判断軸を整理しました。要点は3つに集約できます。第一に、SQL Lab・データセット・チャート・ダッシュボードという一連の流れを理解することが構築の出発点になります。第二に、行レベルセキュリティやロール設計、埋め込み機能はいずれも業務要件と直結する重要な設定であり、誤設定時の影響範囲を踏まえた慎重な設計が欠かせません。第三に、セルフホスト運用は複数領域の専門性を要するため、社内の体制と委託先の実績を踏まえて内製・外注の線引きを決める必要があります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Apache Software Foundation「Apache Superset Documentation – Introduction」
2. *2　出典：Apache Software Foundation「SQL Templating – Apache Superset」
3. *3　出典：Apache Software Foundation「Exploring Data in Superset」
4. *4　出典：Apache Software Foundation「Creating Your First Dashboard – Apache Superset」
5. *5　出典：Apache Software Foundation「Connecting to Databases – Apache Superset」
6. *6　出典：Apache Software Foundation「Configuring Superset」
7. *7　出典：Apache Software Foundation「Security Configurations – Apache Superset」
8. *8　出典：Apache Software Foundation「STANDARD_ROLES.md – apache/superset」
9. *9　出典：Apache Software Foundation「Embedding Superset – Apache Superset」

Tweet