FAQ

Supersetはどれくらいの大きさのデータセットを扱えますか？

Supersetは巨大なデータベースでも動作します。Supersetは、すべての処理を行う基盤となるデータベースまたはデータエンジンの上の薄いレイヤーとして機能します。Supersetは、クエリの結果を視覚化するだけです。

Supersetで許容できるパフォーマンスを実現するための鍵は、データベースがクエリを実行し、ユーザーが許容できる速度で結果を返すことができるかどうかです。Supersetでパフォーマンスが遅い場合は、データウェアハウスをベンチマークして調整してください。

Supersetを実行するために必要なコンピューティング仕様は何ですか？

Supersetのインストールの仕様は、データのサイズではなく、ユーザー数とユーザーのアクティビティによって異なります。コミュニティのSuperset管理者は、中規模のインスタンスを実行するには8GBのRAM、2vCPUが適切であると報告しています。Supersetを開発する（例：コードのコンパイルまたはイメージのビルド）には、より多くのパワーが必要になる場合があります。

リソースの使用状況を監視し、必要に応じて増減してください。Supersetの使用は、たとえば、会議の全員が同じダッシュボードを一度にロードした場合など、急増する傾向があることに注意してください。

Supersetのアプリケーションメタデータは、保存するために非常に大きなデータベースを必要としませんが、ログファイルは時間の経過とともに大きくなります。

一度に複数のテーブルを結合/クエリできますか？

ExploreまたはVisualization UIではできません。Superset SQLAlchemyデータソースは、単一のテーブルまたはビューのみにすることができます。

テーブルを使用する場合、解決策は、おそらくスケジュールされたバッチ処理によって、分析に必要なすべてのフィールドを含むテーブルを作成することです。

ビューは、任意のSQLクエリを仮想テーブルとして抽象化する単純な論理レイヤーです。これにより、複数のテーブルを結合およびユニオンしたり、任意のSQL式を使用していくつかの変換を適用したりできます。Supersetがクエリ（ビュー）の上にクエリを効果的に実行するため、データベースのパフォーマンスに制限があります。良い方法は、メインの大きなテーブルを1つまたは複数の小さなテーブルにのみ結合し、可能な場合は *GROUP BY* の使用を避けることです。Superset自体が *GROUP BY* を実行し、2回作業するとパフォーマンスが低下する可能性があるためです。

テーブルを使用するかビューを使用するかに関わらず、パフォーマンスはデータベースがSupersetと対話するユーザーに結果をどれだけ早く配信できるかによって異なります。

ただし、SQL Labを使用している場合、そのような制限はありません。データベースアカウントがテーブルにアクセスできる限り、SQLクエリを記述して複数のテーブルを結合できます。

独自の可視化を作成するにはどうすればよいですか？

可視化プラグインの作成の手順を読むことをお勧めします。

CSVデータをアップロードして可視化できますか？

もちろんです！CSVのアップロードを有効にして使用する方法については、こちらの手順をお読みください。

クエリがタイムアウトするのはなぜですか？

長時間実行されるクエリがタイムアウトする理由はたくさんあります。

Sql Labから長時間クエリを実行する場合、デフォルトでは、SupersetはCeleryによって強制終了されるまで最大6時間実行できます。クエリ実行時間を長くする場合は、構成でタイムアウトを指定できます。例:

SQLLAB_ASYNC_TIME_LIMIT_SEC = 60 * 60 * 6

ダッシュボードまたはExploreスライスの読み込み時にタイムアウト（504 Gateway Time-out）が発生する場合は、おそらくゲートウェイまたはプロキシサーバー（Nginxなど）の背後にいます。Supersetサーバー（長時間クエリを処理している）からタイムリーな応答を受信しなかった場合、これらのWebサーバーはクライアントに直接504ステータスコードを送信します。Supersetには、この問題に対処するためのクライアント側のタイムアウト制限があります。クエリがクライアント側のタイムアウト（デフォルトでは60秒）以内に戻らなかった場合、Supersetはゲートウェイタイムアウトメッセージを回避するために警告メッセージを表示します。ゲートウェイタイムアウト制限が長い場合は、superset_config.pyでタイムアウト設定を変更できます。

SUPERSET_WEBSERVER_TIMEOUT = 60

地理空間可視化でマップが表示されないのはなぜですか？

Mapbox.comで無料アカウントを登録し、APIキーを取得して、.envのキーMAPBOX_API_KEYに追加する必要があります。

MAPBOX_API_KEY = "longstringofalphanumer1c"

ダッシュボードの定期的な更新を制限するにはどうすればよいですか？

デフォルトでは、ダッシュボードの定期的な更新機能を使用すると、設定されたスケジュールに従ってダッシュボード上のすべてのスライスを自動的に再クエリできます。ただし、場合によっては、一部のデータがゆっくり移動している場合や、重いクエリを実行する場合など、すべてのスライスを更新したくない場合があります。定期的な更新プロセスから特定のスライスを除外するには、timed_refresh_immune_slicesキーをダッシュボードのJSONメタデータフィールドに追加します。

{
   "filter_immune_slices": [],
    "expanded_slices": {},
    "filter_immune_slice_fields": {},
    "timed_refresh_immune_slices": [324]
}

上記の例では、ダッシュボードに定期的な更新が設定されている場合、324を除くすべてのスライスはスケジュールに従って自動的に再クエリされます。

スライスの更新も、指定された期間にわたって段階的に行われます。stagger_refreshをfalseに設定してこの段階的な実行をオフにし、stagger_timeをJSONメタデータフィールドのミリ秒単位の値に設定して、段階的な実行期間を変更できます。

{
    "stagger_refresh": false,
    "stagger_time": 2500
}

ここでは、定期的な更新がオンの場合、ダッシュボード全体が一度に更新されます。2.5秒の段階的な実行時間は無視されます。

開始時に「flask fab」またはsupersetがフリーズ/ハング/応答しない（ホームディレクトリがNFSマウントされている）のはなぜですか？

デフォルトでは、Supersetは~/.superset/superset.dbにSQLiteデータベースを作成して使用します。SQLiteは、NFSでのファイルロックの実装が壊れているため、NFSで使用すると適切に機能しないことが知られています。

SUPERSET_HOME環境変数を使用して、このパスを上書きできます。

別の回避策は、superset_config.pyに以下を追加して、supersetがsqliteデータベースを保存する場所を変更することです。

SQLALCHEMY_DATABASE_URI = 'sqlite:////new/location/superset.db?check_same_thread=false'

構成ファイルを使用したSupersetのカスタマイズの詳細については、こちらを参照してください。

テーブルスキーマが変更された場合はどうなりますか？

テーブルスキーマは進化し、Supersetはそれを反映する必要があります。ダッシュボードのライフサイクルでは、新しいディメンションまたはメトリックを追加したいのが一般的です。Supersetに新しい列を検出させるには、Data -> Datasetsに移動し、スキーマが変更されたデータセットの横にある編集アイコンをクリックして、ColumnsタブからSync columns from sourceをクリックするだけです。バックグラウンドで、新しい列がマージされます。その後、テーブルを再度編集して[Columns]タブを設定し、適切なボックスをチェックして再度保存する必要がある場合があります。

Supersetのバックエンドとして使用できるデータベースエンジンは何ですか？

明確にするために、データベースバックエンドは、ユーザーのリストやダッシュボードの定義などの内部情報をSupersetが保存するために使用するOLTPデータベースです。Supersetは、データ *ソース* としてさまざまなデータベースをサポートしていますが、OLTPバックエンド/メタデータストアとして使用できるデータベースエンジンはごくわずかです。

Supersetは、MySQL、PostgreSQL、およびSQLiteバックエンドを使用してテストされています。本番環境では、これらのデータベースサーバーのいずれかにSupersetをインストールすることをお勧めします。他のOLTPデータベースでのインストールは機能する可能性がありますが、テストされていません。Microsoft SQL ServerはSupersetバックエンドとして機能しないと報告されています。カラムストアの非OLTPデータベースは、このタイプのワークロード向けに設計されていません。

OAuth認証と認可を構成するにはどうすればよいですか？

このFlask-AppBuilder 構成例をご覧ください。

ダッシュボードに特定の色を強制的に使用させる方法はありますか？

label_colorsキーを使用してJSONメタデータ属性にラベルと色のマッピングを提供することで、ダッシュボードごとに可能になります。完全な16進カラー、red、coral、lightblueなどの名前付きカラー、または現在のカラーパレットのインデックス（最初の色は0、2番目の色は1など）を使用できます。例

{
    "label_colors": {
        "foo": "#FF69B4",
        "bar": "lightblue",
        "baz": 0
    }
}

Supersetは[ここにデータベースエンジンを挿入]で動作しますか？

サポートされているデータベースの概要については、データベースへの接続セクションをご覧ください。このページに記載されていないデータベースエンジンも動作する可能性があります。この知識ベースはコミュニティの貢献に依存しています。

SQLAlchemyコネクターを介してSupersetでデータベースエンジンをサポートするには、Python互換のSQLAlchemyダイアレクトと、定義されたDBAPIドライバーが必要です。SQLサポートが限られているデータベースも動作する可能性があります。たとえば、Druidは結合とサブクエリをサポートしていませんが、SQLAlchemyコネクターを介してDruidに接続することは可能です。データベースをサポートするためのもう1つの重要な要素は、Supersetのデータベースエンジン仕様インターフェースです。このインターフェースにより、SQLAlchemyとDBAPIの範囲を超えるデータベース固有の構成とロジックを定義できます。これには、次のような機能が含まれます。

• タイムシリーズクエリを実行する際に、Supersetが異なる時間粒度でデータを取得できるようにする日付関連のSQL関数
• エンジンがサブクエリをサポートするかどうか。falseの場合、Supersetは制限を補うために2段階のクエリを実行することがあります。
• ログの処理とクエリの完了率を推測する方法
• ドライバーが標準のDBAPIではない場合に、カーソルと接続を処理する方法に関する技術的な詳細

SQLAlchemyコネクターに加えて、Supersetを拡張して独自のコネクターを作成することも可能ですが、より複雑になります。現在、この例はDruidコネクターのみですが、DruidのSQLサポートの成長と、最近DBAPIおよびSQLAlchemyドライバーが利用可能になったことにより、置き換えられようとしています。統合を検討しているデータベースに何らかのSQLサポートがある場合は、SQLAlchemyルートを使用するのがおそらく望ましいでしょう。ネイティブコネクターを可能にするには、データベースがOLAPタイプのクエリの実行をサポートし、基本的なSQLで一般的な操作を実行できる必要があります。

• データの集計
• フィルターの適用
• HAVINGタイプのフィルターの適用
• スキーマを認識し、カラムと型を公開すること

Supersetは公開APIを提供していますか？

はい、公開REST APIがあり、そのAPIサーフェスは着実に拡大しています。このAPIの詳細を読み、Swaggerを使用して対話するには、こちらをご覧ください。

/api/v1以下のエンドポイントのコレクションに関する当初のビジョンの一部は、SIP-17で最初に規定され、より多くのユースケースをカバーするために絶え間ない進歩が遂げられています。

利用可能なAPIはSwaggerを使用して文書化されており、superset_config.pyで次のフラグを有効にすることで、/swagger/v1でドキュメントを利用できるようにすることができます。

FAB_API_SWAGGER_UI = True

Supersetとプログラムで対話するための、文書化されていない[プライベート]な方法も他にもありますが、保証はなく、推奨されませんが、一時的にユースケースに合う可能性があります。

• ORM（SQLAlchemy）を直接使用する
• 内部FAB ModelView APIの使用（Supersetでは非推奨になる予定）
• フォークでソースコードを変更する

使用状況統計（例：月間アクティブユーザー数）を確認するにはどうすればよいですか？

この機能はSupersetには含まれていませんが、Supersetのアプリケーションメタデータを抽出して分析することで、どのようなアクションが発生したかを確認できます。デフォルトでは、ユーザーアクティビティはSupersetのメタデータデータベースのlogsテーブルに記録されます。ある企業が、Supersetの使用状況を分析した方法（サンプルクエリを含む）に関する記事を公開しています。

データセット編集ビューの「時間オフセット」は何をしますか？

データセット編集ビューで、時間オフセットを指定できます。このフィールドでは、時間カラムに対して加算または減算する時間数を構成できます。たとえば、UTC時間をローカル時間に変換するために使用できます。

Supersetはテレメトリーデータを収集しますか？

SupersetはデフォルトでScarfを使用して、Supersetのインストール時や実行時に基本的なテレメトリーデータを収集します。このデータは、SupersetのメンテナーがSupersetのどのバージョンが使用されているかをより良く理解し、パッチ/マイナーリリースとセキュリティ修正に優先順位を付けるのに役立ちます。コンテナレジストリの前にはScarf Gatewayを使用し、npmのインストールを追跡するためにscarf-jsパッケージを使用し、Supersetのページビューに関する匿名分析を収集するためにScarfピクセルを使用します。ScarfはPIIを消去し、集計された統計を提供します。Supersetユーザーは、こちらとこちらに記載されているさまざまな方法で、分析を簡単にオプトアウトできます。Supersetのメンテナーは、Supersetコンテナ（またはSuperset/webpackが実行されている場所）でSCARF_ANALYTICS環境変数をfalseに設定することにより、テレメトリーデータの収集をオプトアウトすることもできます。Dockerユーザー向けの追加のオプトアウト手順は、Dockerインストールページにあります。

Supersetには、ユーザーが削除されたアセットを復元できるアーカイブパネルまたはゴミ箱がありますか？

いいえ。現在、UIから削除されたSupersetダッシュボード/チャート/データセット/データベースを復元する方法はありません。ただし、そのような機能の実装については議論が進行中です。

したがって、メタデータデータベースの定期的なバックアップを作成することをお勧めします。復旧については、バックアップされたDBのコピーがアタッチされたSupersetサーバーの復旧インスタンスを起動し、Superset UIの[ダッシュボードのエクスポート]ボタン（またはsuperset export-dashboards CLIコマンド）を使用できます。次に、.zipファイルを取得し、現在のSupersetインスタンスにインポートします。

または、プログラムでアセットの定期的なエクスポートをバックアップとして実行することもできます。