データベースの保護と構成が完了したら、データベースを Looker に接続する準備ができました。
[管理] パネルの [データベース] セクションで [接続] を選択します。[接続] ページで、[接続を追加] ボタンをクリックします。Lookerに[Connection Settings]ページが表示されます。
接続設定にユーザー属性を適用する方法の詳細については、ユーザー属性ドキュメント ページの接続セクションをご覧ください。
このページでは、Looker の [接続設定] ページに表示される共通フィールドについて説明します。[Connection Settings] ページに表示される具体的なフィールドは、ダイアレクト設定によって異なります。
こちらから、Looker のドキュメントの言語固有の手順へのリンクをご覧ください。
- Actian Avalanche
- AlloyDB for PostgreSQL
- Amazon Aurora PostgreSQL
- Amazon Athena
- Amazon Aurora MySQL
- Amazon RDS for MySQL
- Amazon RDS for PostgreSQL
- Amazon Redshift
- Apache Druid
- Apache Hive 2.3 以降と 3.1.2 以降
- Apache Spark 3 以降
- ClickHouse
- Cloudera Impala 3.1+
- Databricks
- DataVirtuality
- Denodo
- Dremio
- Exasol
- Firebolt
- Google BigQuery Legacy SQL
- Google BigQuery Standard SQL
- Google Cloud SQL for MySQL
- Google Cloud SQL for PostgreSQL
- Google Spanner
- Greenplum
- AS400 上の IBM DB2
- LUW 上の IBM DB2
- MariaDB
- Microsoft Azure Synapse Analytics
- Microsoft Azure SQL Database
- Microsoft Azure PostgreSQL
- Microsoft SQL Server(MSSQL)
- BI 用の MongoDB コネクタ
- MySQL
- Oracle
- Oracle ADWC
- PostgreSQL
- PrestoDB
- SAP HANA
- SingleStore(旧 MemSQL)
- Snowflake
- Teradata
- Trino
- Vector
- Vertica
データベース接続設定を入力したら、[接続設定] ページの [テスト] ボタンを選択して接続をテストし、正しく構成されていることを確認できます。[テスト] をクリックして、接続が成功したことを確認します。トラブルシューティング情報については、データベース接続のテストのドキュメント ページをご覧ください。Looker に [接続可能] と表示されたら、[接続] を押して接続を作成します。これで、データベース接続が Looker の [接続] 管理ページのリストに追加されます。
全般設定
名前
接続に付ける名前です。 このデータベース接続名は、LookML モデルの connection
パラメータで使用するために必要です。データベース接続名は、Looker の [接続] 管理ページで接続が識別される仕組みでもあります。この設定にはフォルダの名前を使用しないでください。この値は、データベース内の値に一致する必要はありません。Name
は、Looker UI 内でこの接続を識別するラベルです。
接続スコープ
接続をすべてのプロジェクトで使用できるか、1 つのプロジェクトのみで使用するかを選択します。
次の権限とともにこのオプションを使用して、接続管理とモデル構成を委任します。
方言
接続に一致する SQL 言語。適切な接続オプションが表示され、LookMLがSQLに適切に変換されるよう、必ず正確な値を選択してください。
課金プロジェクト ID
Google BigQuery 接続の場合のみ、課金プロジェクト ID は Google Cloud プロジェクト ID になります。
ホスト
Looker がデータベース ホストに接続するために使用するデータベース ホスト名。
Looker アナリストと共同でデータベースへの SSH トンネルを構成した場合は、[ホスト] フィールドに「"localhost"
」と入力します。
ポート
Looker がデータベース ホストに接続するために使用するデータベース ポート。
Looker アナリストと共同でデータベースへの SSH トンネルを構成した場合は、データベースにリダイレクトするポート番号を [ポート] フィールドに入力してください。このポート番号は担当の Looker アナリストから入手します。
Database
ホスト上のデータベースの名前。 たとえば、my-instance.us-east-1.redshift.amazonaws.com
というホスト名に sales_info
というデータベースがあるとします。このフィールドに「sales_info
」と入力します。同じホスト上に複数のデータベースがある場合、それらを使用するには複数の接続を作成する必要があります(MySQLの場合は例外で、「データベース」という言葉は、ほとんどのSQLダイアレクトとは意味が少し異なります)。
スキーマ
スキーマが設定されない場合に使用されるデフォルトのスキーマです。 これは、SQL Runnerを使用しているとき、LookMLプロジェクトの生成中、およびテーブルをクエリするときに適用されます。
Authentication
Snowflake と Google BigQuery の接続の場合、Looker がデータベースのアクセスに使用する認証タイプを選択します。
- Google BigQuery 接続では、OAuth または Looker でデータベースに対する認証を行うためのサービス アカウントを構成できます。
- Snowflake 接続では、必要に応じて、OAuth または Looker でデータベースに対する認証を行うためのデータベース アカウントを構成できます。
OAuth を使用する場合、ユーザーは Looker からクエリを発行するためにデータベースにログインする必要があります。OAuth の構成手順については、Google BigQuery ページまたは Snowflake ページをご覧ください。
ユーザー名
Looker でデータベースに接続するために使用できる、データベース上のユーザー アカウントのユーザー名。
パスワード
Looker でデータベースに接続するために使用できる、データベース上のユーザー アカウントのパスワード。
オプションの設定
SSH サーバー
[SSH Server] オプションは、インスタンスが Kubernetes インフラストラクチャにデプロイされており、さらに Looker インスタンスに SSH サーバー構成情報を追加する機能が有効になっている場合に限り利用できます。このオプションが Looker インスタンスで有効になっておらず、有効にしたい場合は、Google Cloud セールス スペシャリストにお問い合わせいただくか、サポート リクエストを開いてください。
SSH サーバーは、自動で localhost ポートを選択します。localhost ポートを指定することはできません。localhost ポートを指定する必要がある SSH 接続を作成する必要がある場合は、サポート リクエストを開いてください。
SSH トンネルを使用してデータベースに接続するには、切り替えボタンをクリックして、プルダウン リストから [SSH サーバー構成] を選択します。
ローカルポート
デフォルトでの Looker は、SSH トンネルに使用できるローカルポートを自動的に選択します。ローカルポートを手動で選択するには、[Manual Entry] を選択して、[Custom Local Port] フィールドにポート番号を入力します。インスタンスで、ローカルポートが使用できることを確認します。
永続的な派生テーブル(PDT)
PDT を有効にする
永続的な派生テーブル(PDT)を有効にするには、[PDT を有効にする] 切り替えボタンをオンにします。PDT が有効になると、追加の PDT フィールドと [PDT オーバーライド] セクションが [接続] ウィンドウに表示されます。Looker では、データベース言語が PDT の使用をサポートしている場合にのみ、[PPDT を有効にする] 切り替えボタンが表示されます。
PDTについて、次の点に注意してください。
- PDT は OAuth を使用する Snowflake 接続ではサポートされていません。
- 接続で PDT を無効にしても、PDT に関連付けられたデータグループは無効になりません。PDTを無効にしても、既存のデータグループは引き続きデータベースに対して
sql_trigger
クエリを実行します。データグループがデータベースに対してsql_trigger
クエリを実行しないようにするには、LookML プロジェクトからdatagroup
パラメータを削除またはコメントアウトする必要があります。または、Looker による PDT およびデータグループのチェックの頻度が非常に低くなるようにするか、あるいはまったくチェックが行われないように、その接続の [データグループと PDT のメンテナンス スケジュール] 設定を更新することもできます。 - Snowflake 接続の場合、Looker は
AUTOCOMMIT
パラメータの値をTRUE
(Snowflake のデフォルト値)に設定します。Looker が PDT 登録システムを維持するために実行する SQL コマンドには、AUTOCOMMIT
が必須です。
Temp Database
「一時データベース」に対して、データベース名またはスキーマ名を入力します(どちらを入力するかは、ご利用の SQL 言語によって異なります)。この名前は、Looker で永続的な派生テーブルを作成するために使用されます。このデータベースまたはスキーマには、適切な書き込み権限を前もって設定しておく必要があります。 データベース構成の手順のドキュメント ページで、データベース言語を選択して、その言語の手順を確認します。
接続ごとに専用の一時データベースまたはスキーマが必要です。接続間で共有することはできません。
PDTビルダーの最大接続数
PDT ビルダーの最大接続数の設定では、Looker リジェネレータがデータベース接続に対して同時に開始できるテーブルのビルド数を指定できます。[PDT ビルダーの最大接続数] 設定は、Looker リジェネレータが再ビルドを開始するテーブルのタイプにのみ適用されます。
- トリガー永続テーブル(永続的な派生テーブルと
datagroup_trigger
またはsql_trigger_value
永続化戦略を使用する集約テーブル)。 persist_for
戦略を使用する永続テーブル。ただし、persist_for
テーブルが、datagroup_trigger
またはsql_trigger_value
永続戦略を使用するテーブルによって依存されている派生テーブルのカスケードの一部である場合に限る。この場合、Looker リジェネレータはpersist_for
テーブルを再構築します。これは、カスケード内の別のテーブルを再構築するために必要であるためです。それ以外の場合、リジェネレータはpersist_for
テーブルのビルドを開始しません。
[PDT ビルダーの最大接続数] 設定のデフォルトは 1 ですが、10 まで設定できます。ただし、この値を [ノードあたりの最大接続数] フィールドで設定された値や Looker の起動オプションで設定された per-user-query-limit
より大きくすることはできません。
この値を設定するときには注意してください。 値が大きすぎると、データベースの負荷が高くなります。 値が小さいと、長期実行PDTまたは集計テーブルが原因で他の永続的なテーブルの作成が遅れるか、その接続の他のクエリが遅くなります。 マルチテナンシーに対応するデータベース(BigQuery、Snowflake、Redshift など)は、並列クエリビルドをより効率的に処理できます。
[PDTビルダーの最大接続数] 設定の値を大きくする場合は、経験則として1ずつ増やします。予期しない動作が発生した場合は、デフォルトの「1」に戻します。または、クエリのパフォーマンスに影響がない場合は、設定を 1 ずつ増やし、増分ごとのパフォーマンスを確認してから、設定を増やします。
[PDTビルダーの最大接続数] 設定については、次の点に注意してください。
- [PDTビルダーの最大接続数] 設定は、テーブルの再構築に必要な接続にのみ適用され、トリガーのチェックに必要な接続には適用されません。トリガーチェックとは、テーブルの永続性戦略がトリガーされたかどうかを確認するためのクエリであり、これは常に順番に実行されるため、[PDTビルダーの最大接続数] 設定は適用されません。
- クラスタ化された Looker インスタンスでは、リジェネレータはメインノードでのみ実行されます。[PDT ビルダーの最大接続数] 設定はメインノードにのみ適用されるため、クラスタ全体の上限を設定します。
- [PDT ビルダーの最大接続数] 設定は、次のタイプのテーブルには適用されません。以下のタイプのテーブルは順番に構築されます。
- テーブルが
persist_for
パラメータによって永続化されている(datagroup_trigger
またはsql_trigger_value
戦略を使用するテーブルに依存していない場合)。 - 開発モードのテーブル。
- テーブルが派生テーブルと実行を再ビルドするオプションで再構築されている。
- 依存関係内の別のテーブルに依存するテーブル。 テーブルを依存するテーブルと同時に構築することはできません。 たとえば、
table_B
がtable_A
に依存している場合、table_B
で再構築を開始できるようになる前に、table_A
が再構築を完了する必要があります。
- テーブルが
データグループと PDT のメンテナンス スケジュール
Looker 再生ツールは、データグループと sql_trigger_value
に基づいた永続テーブル(集約テーブルと永続的な派生テーブルの両方)を確認します。Looker リジェネレータは、これらのチェックに基づいて、データベースのスクラッチ スキーマから永続テーブルを再構築または削除します。
[データグループと PDT のメンテナンス スケジュール] の値は、Looker リジェネレータの cron
間隔を設定します。Looker リジェネレータは、リジェネレータ サイクルを開始して、cron
間隔でデータグループと永続テーブルを確認します。Looker リジェネレータ サイクルが次の cron
間隔で進行中の場合、Looker リジェネレータは進行中の再生成サイクルを完了し、次の cron
間隔まで待機してその次の再生成サイクルを開始します。
[データグループと PDT のメンテナンス スケジュール] 設定は、cron
式を受け入れます。デフォルト値は */5 * * * *
です。つまり、前の再生成サイクルが完了している場合、Looker リジェネレータ サイクルは 5 分間隔でサイクルを開始します。前の再生成サイクルが完了していない場合、Looker リジェネレータはサイクルが完了した後、次の 5 分間隔を開けて開始されます。
デフォルトの 5 分は、[Datagroup と PDT のメンテナンス スケジュール] でサポートされている最も頻度の高い間隔です。Looker では、[データグループと PDT のメンテナンス スケジュール] に最大間隔が適用されません。つまり、cron
式で指定可能な限り、Looker リジェネレータ サイクルの間隔を延長できます。Looker リジェネレータ サイクルが長いと、キャッシュと永続テーブルのデータの鮮度に悪影響を及ぼす可能性があります。
Looker リジェネレータは、すべてのチェックと PDT の再ビルドをサイクルで完了すると、次の cron
間隔を待機し、その次のサイクルを開始します。長時間実行される PDT ビルドがある場合は、Looker の再生成サイクルの間隔が長い可能性があります。Looker の派生テーブルページの永続テーブルの実装に関する重要な考慮事項セクションで説明されているように、他の要因がテーブルの再構築に必要な時間に影響を与える可能性があります。
データベースが24時間稼働していない場合は、稼働時にのみにチェックすることもできます。その他の cron
式は次のとおりです。
cron 式 |
定義 |
---|---|
*/5 8-17 * * MON-FRI |
データグループとPDTを、月曜から金曜の営業時間に5分ごとにチェック |
*/5 8-17 * * * |
データグループとPDTを、毎日、営業時間に5分ごとにチェック |
0 8-17 * * MON-FRI |
データグループとPDTを、月曜から金曜の営業時間に1時間ごとにチェック |
1 3 * * * |
データグループとPDTを、毎日午前3時01分にチェック |
cron
式を作成する際は、次の点に留意してください。
- Looker は parse-cron v0.1.3 を使用します。これは
cron
式では?
をサポートしていません。 cron
式は、Looker アプリケーションのタイムゾーンを使用して、チェックが行われるタイミングを決定します。- PDT が構築されていない場合は、cron 文字列をデフォルトの
*/5 * * * *
にリセットします。
cron
文字列の作成に役立つリソースを以下に示します。
- https://crontab.guru -
cron
文字列の編集とテストをサポートします。 - http://www.crontab-generator.org - 時間設定を選択すると、生成ツールによって対応する
cron
文字列が作成されます。
失敗した PDT ビルドを再試行する
[Retry failed PDT builds] 切り替えボタンは、Looker リジェネレータが前のリジェネレータ サイクルで失敗したトリガー永続テーブルの再作成方法を構成します。Looker リジェネレータは、[データグループと PDT のメンテナンス スケジュール] 接続設定で構成された間隔に従って、トリガー永続テーブル(PDT と集計テーブル)を再構築するプロセスです。[Retry Failed PDT Builds] 切り替えボタンをオンにすると、Looker リジェネレータは、PDT のトリガー条件が満たされない場合でも、前のリジェネレータ サイクルで失敗した PDT の再構築を試みます。この設定が無効にされている場合、Lookerリジェネレーターは、PDTのトリガー条件が満たされた場合のみ、前に失敗したPDTの再ビルドを試みます。[Retry Failed PDT Builds] はデフォルトで無効になっています。
Looker リジェネレータの詳細については、Looker の派生テーブルのドキュメント ページをご覧ください。
PDT API 制御
[PDT API 制御] 切り替えボタンで、start_pdt_build
、check_pdt_build
、stop_pdt_build
API 呼び出しをこの接続に使用できるかどうかを指定します。[PDT API 制御] 切り替えボタンが無効になっている場合、この接続で PDT を参照していると、API 呼び出しは失敗します。[PDT API 制御] 切り替えボタンは、デフォルトで無効になっています。
PDT オーバーライド
データベースが永続的な派生テーブルをサポートしていて、接続設定の [永続的な派生テーブル] 切り替えボタンをオンにしている場合、Looker で [PDT オーバーライド] セクションが表示されます。[PDT オーバーライド] セクションには、PDT プロセスに固有の個々の JDBC パラメータ(ホスト、ポート、データベース、ユーザー名、パスワード、スキーマ、追加パラメータ、接続後のステートメント)を入力できます。これは次のような理由で非常に重要です。
- PDT プロセス用に個別のデータベース ユーザーを作成することで、データベース認証情報にユーザー属性を割り当てる場合や、データベース接続に OAuth を使用する場合でも、Looker プロジェクトで PDT を使用できます。
- PDTプロセスは、優先度の高い別のデータベースユーザーによって認証できます。 このようにして、データベースは重要度の低いユーザーのクエリよりも、PDTジョブを優先することができます。
- 書き込みアクセス権限は標準的なLookerデータベース接続に対して無効にし、PDTプロセスが認証に使用する特別なユーザーにのみ付与することができます。 ほとんどの組織で、これはより安全なセキュリティ戦略です。
- Snowflake などのデータベースの場合、PDT プロセスは他の Looker ユーザーとは共有されていない、より強力なハードウェアにルーティングできます。こうして、高コストなハードウェアをフルタイムで実行するコストを回避し、PDTをすばやく構築できます。
例えば、以下の設定は、ユーザー名フィールドとパスワードフィールドがユーザー属性に設定されている接続を示しています。 こうすると、各ユーザーが個別の資格情報を使用してデータベースにアクセスできます。 [PDT オーバーライド] セクションでは、独自のパスワードを使用して個別のユーザー(pdt_user
)を作成します。pdt_user
アカウントは、PDT の作成と更新に適切なアクセスレベルを使用して、すべての PDT プロセスに使用されます。
タイムゾーン
データベースのタイムゾーン
時間に基づく情報をデータベースで保管するときのタイムゾーンです。 Lookerは、ユーザーのために時間の値を変換するため、この値が必要です。これにより、時間ベースのデータをユーザーが理解して使用しやすくなります。 詳しくは、タイムゾーン設定の使用のドキュメント ページをご覧ください。
クエリのタイムゾーン
[クエリのタイムゾーン] オプションは、[ユーザー固有のタイムゾーン] を無効にしている場合にのみ表示されます。
ユーザー固有のタイムゾーンが無効になっている場合、クエリのタイムゾーンは、ユーザーが時間ベースのデータをクエリするときに表示されるタイムゾーンであり、Looker はこのタイムゾーンに、データベースのタイムゾーンから時間ベースのデータを変換します。
詳しくは、タイムゾーン設定の使用のドキュメント ページをご覧ください。
追加の設定
その他の JDBC パラメータ
必要に応じて、クエリに Java Database Connectivity(JDBC)パラメータを追加することもできます。
JDBC パラメータでユーザー属性を参照するには、Liquid テンプレート構文_user_attributes['name_of_attribute']
を使用します。例:
my_jdbc_param={{ _user_attributes['name_of_attribute'] }}
ノードごとの最大接続数
Lookerがデータベースと確立できる最大接続数を設定できます。 ほとんどの場合、Lookerがデータベースに対して実行できる同時クエリ数を設定します。 また、クエリの強制終了用に、最大3つの接続を予約します。 接続プールが非常に小さい場合は、予約される接続数も少なくなります。
この値を設定するときには注意してください。 値が大きすぎると、データベースの負荷が高くなります。 値が低すぎると、複数のクエリがわずかな接続数を共用しなければなりません。 クエリは、前のクエリが返されるのを待たなければならないため、ユーザーには遅く感じることがあります。
一般に、まずデフォルト値(SQLダイアレクトによって異なる)を使用することをお勧めします。 ほとんどのデータベースには、受け入れる最大接続数について独自の設定もあります。 データベース構成が接続を制限する場合は、[ノードごとの最大接続数] の値がデータベースの上限以下になるようにしてください。
Connection Pool Timeout(接続プールタイムアウト)
ユーザーが [ノードごとの最大接続数] 設定よりも多くの接続をリクエストすると、リクエストは他のリクエストが完了するまで待機してから実行されます。要求が待つ最大時間はここで設定します。 デフォルトの設定は 120 秒です。
この値は注意深く設定する必要があります。 値が低すぎると、他のユーザーのクエリが完了する十分な時間がないことから、ユーザーのクエリはキャンセルされる場合があります。値が高すぎると、多数のクエリが作成され、ユーザーは長い時間待たされる場合があります。一般に、まずデフォルト値を使用することをお勧めします。
SSL
データがLookerとデータベース間で渡される際に、データを保護するためにSSL暗号化を使用するかどうかを選択します。 SSL はデータの保護に使用できる唯一のオプションです。その他のセキュアなオプションについては、セキュアなデータベースアクセスを可能にするドキュメント ページをご覧ください。
SSL を確認
接続で使用されるSSL証明書の確認を求めるかどうかを選択します。 確認が必要な場合は、SSL証明書に署名したSSL認証局(CA)が、クライアントの信頼できるソースのリストに含まれていなければなりません。CAが信頼できるソースではない場合、データベース接続は確立されません。
このボックスが選択されていない場合、接続でSSL暗号化は使用されますが、SSL接続の確認は要求されません。そのため、CAがクライアントの信頼できるソースのリストにない場合でも接続を確立できます。
SQL Runner プリキャッシュ
SQL Runnerでは、ユーザーが接続とスキーマを選択するとすぐに、テーブル情報が事前にロードされます これにより、SQL Runner ではテーブル名をクリックすると即座にテーブル列が表示されるようになります。ただし、多くのテーブルや大規模なテーブルが関係する接続とスキーマの場合は、SQL Runnerですべての情報を事前にロードしないようにすることをお勧めします。
SQL Runner でテーブルが選択されている場合にのみテーブル情報を読み込む場合は、[SQL Runner Precache] オプションをオフにすると、接続での SQL Runner のプリロードが無効になります。
SQL書き込み用のフェッチ情報スキーマ
一部の SQL 書き込み機能(集約テーブルの自動認識など)では、Looker はデータベースの情報スキーマを使用して SQL 書き込みを最適化します。情報スキーマがキャッシュに保存されていない場合、Looker は、情報スキーマを取得できるようにデータベースへの SQL 書き込みをブロックすることがあります。Hadoop 分散ファイル システム(HDFS)を使用する言語では、情報スキーマのフェッチにかなりの時間がかかることがあるため、Looker クエリのパフォーマンスに大きな影響を及ぼす可能性があります。情報スキーマが低速であることがわかっている場合は、接続の [SQL 書き込み用のフェッチ情報スキーマ] オプションを無効にできます。この機能を無効にすると、特定の機能に対する Looker の SQL 最適化の一部が妨げられるため、接続の情報スキーマが特に遅いことがわかっている場合を除き、[SQL 記述時に情報スキーマを取得] オプションを有効にする必要があります。
費用の見積もり
[費用の見積もり] の切り替えは、次のデータベース接続にのみ適用されます。
- Snowflake
- Amazon Redshift
- Amazon Aurora
- PostgreSQL、Google Cloud SQL for PostgreSQL、Microsoft Azure PostgreSQL
[費用の見積もり] 切り替えボタンを使用すると、接続で次の機能が有効になります。
詳細については、Looker でのデータの探索のドキュメント ページをご覧ください。
Database Connection Pooling
データベース接続プールをサポートする言語の場合、この機能により、Looker は JDBC ドライバを介して接続のプールを使用できます。データベース接続プールにより、クエリのパフォーマンスが向上します。新しいクエリでデータベース接続を新しく作成する必要はありません。接続プールにある既存の接続を使用できます。接続プール機能により、クエリの実行後に接続がクリーンアップされ、クエリの実行の終了後に接続が再利用できるようになります。 詳細については、データベース接続プールのページをご覧ください。
接続設定のテスト
接続設定は、Looker UI のいくつかの場所からテストできます。
- [接続設定] ページの下部にある [テスト] ボタンを選択します。
- 接続のドキュメント ページの説明に従って、[接続] 管理ページの接続リストの横にある [Test] ボタンを選択します。
接続設定を入力したら、[テスト] をクリックして情報が正しいことと、データベースに接続できることを確認します。
接続が 1 つ以上のテストに合格しない場合は、次のトラブルシューティングをお試しください。
- データベース接続のテストに関するドキュメント ページに記載されているトラブルシューティングの手順をお試しください。
- Atlas で Mongo バージョン 3.6 以前を使用していて、通信リンクに障害が発生した場合は、Mongo コネクタのドキュメントをご覧ください。
- 一時スキーマとPDTに関する正常接続のメッセージを受け取るには、Lookerデータベースをセットアップする際にその機能を有効にする必要があります。 これを行う手順については、データベースの構成手順のドキュメント ページをご覧ください。
それでも障害が続く場合は、Lookerサポートに連絡してください。
ユーザーとしてテストする
1 つ以上の接続パラメータの値をユーザー属性に設定している場合、[テスト] ボタンの上に [ユーザーとしてテスト] オプションが表示されます。ユーザーを選択して [テスト] をクリックし、データベースに接続でき、このユーザーとしてクエリを実行できることを確認します。
次のステップ
データベースを Looker に接続したら、ユーザーのログイン オプションの構成を開始できます。