表示されているのは Looker のドキュメントです。Looker Studio のドキュメントについては、https://support.google.com/looker-studio をご覧ください。

Lookerをデータベースに接続

データベースの保護と構成が完了したら、データベースを Looker に接続する準備ができました。

[データベースを Looker に接続する] ページで、Looker でデータベース接続を作成します。[データベースを Looker に接続する] ページを開くには、次の 2 つの方法があります。

[管理] パネルの [データベース] セクションで [接続] を選択します。[Connections] ページで、[Add Connection] ボタンをクリックします。
左側のナビゲーションパネルで [作成] ボタンをクリックし、[接続] メニュー項目を選択します。

接続設定にユーザー属性を適用する方法の詳細については、ユーザー属性ドキュメントページの接続セクションをご覧ください。

このページでは、Looker で [データベースを Looker に接続する] ページに表示される一般的なフィールドについて説明します。ページに表示される具体的なフィールドは、ダイアレクト設定によって異なります。

こちらから、Looker のドキュメントの言語固有の手順へのリンクをご覧ください。

データベース接続設定を入力したら、[データベースを Looker に接続する] ページで [テスト] ボタンを選択して、接続をテストし、正しく構成されていることを確認します。[テスト] をクリックして、接続が成功したことを確認します。トラブルシューティング情報については、データベース接続のテストのドキュメントページをご覧ください。Looker に [接続可能] と表示されたら、[接続] を押して接続を作成します。これで、データベース接続が Looker の [接続] 管理ページのリストに追加されます。

全般設定

名前

接続に付ける名前です。このデータベース接続名は、LookML モデルの connection パラメータで使用する必要があります。データベース接続名は、Looker の [接続管理] ページで接続が識別される仕組みでもあります。この設定にはフォルダ名を使用しないでください。この値は、データベース内の値に一致する必要はありません。Name は、Looker UI 内でこの接続を識別するラベルです。

接続スコープ

接続をすべてのプロジェクトで使用できるか、1 つのプロジェクトのみで使用するかを選択します。

すべてのプロジェクト: インスタンス上のすべての LookML プロジェクトが接続にアクセスできるため、そのプロジェクトのモデルファイルの connection パラメータで接続名を指定できます。
選択したプロジェクト: インスタンス上の 1 つの LookML プロジェクトのみが接続にアクセスできます。このオプションを選択すると、[接続] 画面にインスタンスのプロジェクトのプルダウンメニューが表示されます。この接続にアクセスできるプロジェクトを選択します。

次の権限とともにこのオプションを使用して、接続管理とモデル構成を委任します。

方言

接続に一致する SQL 言語。適切な接続オプションが表示され、LookMLがSQLに適切に変換されるよう、必ず正確な値を選択してください。

課金プロジェクト ID

Google BigQuery 接続の場合のみ、課金プロジェクト ID は Google Cloud プロジェクト ID になります。

ホスト

Looker がデータベースホストに接続するために使用するデータベースホスト名。

Looker アナリストと共同でデータベースへの SSH トンネルを構成した場合は、[ホスト] フィールドに「"localhost"」と入力します。

ポート

Looker がデータベースホストに接続するために使用するデータベースポート。

Looker アナリストと共同でデータベースへの SSH トンネルを構成した場合は、データベースにリダイレクトするポート番号を [ポート] フィールドに入力してください。このポート番号は担当の Looker アナリストから入手します。

データベース

ホスト上のデータベースの名前。たとえば、ホスト名が my-instance.us-east-1.redshift.amazonaws.com で、そこに sales_info というデータベースがあるとします。このフィールドに「sales_info」と入力します。同じホスト上に複数のデータベースがある場合、それらを使用するには複数の接続を作成する必要があります（MySQLの場合は例外で、「データベース」という言葉は、ほとんどのSQLダイアレクトとは意味が少し異なります）。

スキーマ

スキーマが設定されない場合に使用されるデフォルトのスキーマです。これは、SQL Runnerを使用しているとき、LookMLプロジェクトの生成中、およびテーブルをクエリするときに適用されます。

認証

Google BigQuery、Snowflake、Trino、Databricks に接続する場合、Looker でデータベースへのアクセスに使用する認証の種類を選択します。

Google BigQuery 接続では、OAuth または Looker でデータベースに対する認証に使用するサービスアカウントを構成できます。
Snowflake、Trino、Databricks 接続では、OAuth または Looker でデータベースに対する認証に使用するデータベースアカウントを構成できます。

OAuth を使用する場合、Looker からクエリを発行するためにユーザーはデータベースにログインする必要があります。Looker への接続での OAuth の設定の詳細については、Google BigQuery、Snowflake、Trino、Databricks の接続手順をご覧ください。

ユーザー名

Looker でデータベースに接続するために使用できる、データベース上のユーザーアカウントのユーザー名。

パスワード

Looker でデータベースに接続するために使用できる、データベース上のユーザーアカウントのパスワード。

オプションの設定

SSH サーバー

[SSH Server] オプションは、インスタンスが Kubernetes インフラストラクチャにデプロイされており、さらに Looker インスタンスに SSH サーバー構成情報を追加する機能が有効になっている場合に限り利用できます。このオプションが Looker インスタンスで有効になっておらず、有効にしたい場合は、Google Cloud セールススペシャリストにお問い合わせいただくか、サポートリクエストを開いてください。

SSH サーバーは、自動で localhost ポートを選択します。localhost ポートを指定することはできません。ローカルホストポートを指定する必要のある SSH 接続を作成する必要がある場合は、サポートリクエストを開きます。

SSH トンネルを使用してデータベースに接続するには、切り替えをオンにして、プルダウンリストから SSH サーバー構成を選択します。

ローカルポート

デフォルトでの Looker は、SSH トンネルに使用できるローカルポートを自動的に選択します。ローカルポートを手動で選択するには、[手動入力] を選択し、[Custom Local Port] フィールドにポート番号を入力します。インスタンスで、ローカルポートが使用できることを確認します。

永続的な派生テーブル（PDT）

PDT を有効にする

永続的な派生テーブル（PDT）を有効にするには、[PDT を有効にする] 切り替えボタンをオンにします。PDT が有効になると、追加の PDT フィールドと [PDT オーバーライド] セクションが [接続] ウィンドウに表示されます。Looker では、データベース言語が PDT の使用をサポートしている場合にのみ、[PPDT を有効にする] 切り替えボタンが表示されます。

PDTについて、次の点に注意してください。

OAuth を使用する Snowflake 接続では PDT はサポートされていません。
接続で 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 戦略を使用するテーブルに依存している場合を除く）。
- Development Mode のテーブル。
- テーブルが派生テーブルと実行を再ビルドするオプションで再構築されている。
- 依存関係内の別のテーブルに依存するテーブル。テーブルを依存するテーブルと同時に構築することはできません。たとえば、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 に接続] ページの [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ですべての情報を事前にロードしないようにすることをお勧めします。

テーブルが1つ選択されているときだけ SQL Runner がテーブル情報を読み込むようにするには、[SQL Runner Precache] オプションの選択を解除して、その接続における SQL Runner の事前読み込みを無効にします。

SQL書き込み用のフェッチ情報スキーマ

一部の SQL 書き込み機能（集約テーブルの自動認識など）では、Looker はデータベースの情報スキーマを使用して SQL 書き込みを最適化します。情報スキーマがキャッシュに保存されていない場合、Looker は、情報スキーマを取得できるようにデータベースへの SQL 書き込みをブロックすることがあります。Hadoop Distributed File System（HDFS）を使用する原語の場合、情報スキーマの取得に時間がかかり、Looker クエリのパフォーマンスに大きな影響を与える可能性があります。情報スキーマに時間を要することが分かっている場合、接続の [SQL 記述時に情報スキーマを取得] オプションを無効にできます。この機能を無効にすると、特定の機能に対する Looker の SQL 最適化の一部が妨げられるため、接続の情報スキーマが特に遅いことがわかっている場合を除き、[SQL 記述時に情報スキーマを取得] オプションを有効にする必要があります。

費用の見積もり

[費用の見積もり] の切り替えは、次のデータベース接続にのみ適用されます。

[費用の見積もり] 切り替えにより、接続で次の機能が有効になります。

詳細については、Looker でのデータの探索のドキュメントページをご覧ください。

Database Connection Pooling

データベース接続プーリングをサポートする言語の場合、この機能により、Looker は JDBC ドライバを介して接続のプールを使用できます。データベース接続プールにより、クエリのパフォーマンスが向上します。新しいクエリでデータベース接続を新しく作成する必要はありません。接続プールにある既存の接続を使用できます。接続プール機能により、クエリの実行後に接続がクリーンアップされ、クエリの実行の終了後に接続が再利用できるようになります。詳細については、データベース接続プーリングのドキュメントページをご覧ください。

接続設定のテスト

接続設定は、Looker UI のいくつかの場所でテストできます。

[接続設定] ページの下部にある [テスト] ボタンを選択します。
接続のドキュメントページの説明に従って、[接続] 管理ページの接続リストの横にある [Test] ボタンを選択します。

接続設定を入力したら、[テスト] をクリックして情報が正しいことと、データベースに接続できることを確認します。

接続が 1 つ以上のテストに合格しない場合は、次のトラブルシューティングオプションを使用できます。

データベース接続のテストに関するドキュメントページに記載されているトラブルシューティングの手順をお試しください。
Atlas で Mongo バージョン 3.6 以前を実行していて、通信リンクの障害が発生した場合は、Mongo コネクタのドキュメントページをご覧ください。
一時スキーマとPDTに関する正常接続のメッセージを受け取るには、Lookerデータベースをセットアップする際にその機能を有効にする必要があります。設定方法については、データベースの構成に関する手順のドキュメントページをご覧ください。

それでも障害が続く場合は、Lookerサポートに連絡してください。

ユーザーとしてテストする

1 つ以上の接続パラメータの値をユーザー属性に設定している場合、[ユーザーとしてテスト] オプションが表示されます。ユーザーを選択して [テスト] をクリックし、データベースに接続でき、このユーザーとしてクエリを実行できることを確認します。

次のステップ

データベースを Looker に接続したら、ユーザーのログインオプションを構成できるようになります。