このドキュメントでは、クエリサービスに関するよくある質問への回答と、クエリサービスの使用時によく見られるエラーコードのリストを示します。Adobe Experience Platform の他のサービスに関する質問やトラブルシューティングについては、Experience Platform のトラブルシューティングガイドを参照してください。
よくある質問に対する次の回答のリストは、次のカテゴリに分類されています。
この節には、パフォーマンス、制限、プロセスに関する情報が含まれます。
いいえ。オートコンプリート機能のオフは、現在、エディターでサポートされていません。
1 つの潜在的な原因はオートコンプリート機能です。この機能は、特定のメタデータコマンドを処理するので、クエリの編集中にエディターの速度が遅くなることがあります。
はい、Postman(無料のサードパーティアプリケーション)を使用して、すべての Adobe API サービスを視覚化し、操作できます。Adobe Developer Console でプロジェクトを設定し、Postman で使用するために必要な資格情報をすべて取得する手順については、Postman 設定ガイドをご覧ください。 Postman コレクションの開始、実行、共有に関するガイダンスの公式ドキュメントを参照してください。
はい、明示的な制限が外部で指定されていない限り、クエリサービスは内部的に 50,000 行の制限を適用します。詳しくは、インタラクティブクエリの実行に関するガイダンスを参照してください。
バッチクエリでは、データセット内の行の更新はサポートされていません。
いいえ。データサイズに制限はありませんが、インタラクティブセッションからのクエリタイムアウトは 10 分間に制限されています。クエリがバッチ CTAS として実行される場合、10 分間のタイムアウトは適用されません。詳しくは、インタラクティブクエリの実行に関するガイダンスを参照してください。
出力行数の制限を回避するには、クエリで「LIMIT 0」を適用します。以下に例を示します。
SELECT * FROM customers LIMIT 0;
クエリがタイムアウトした場合に備えて、次の解決策の 1 つ以上をお勧めします。
いいえ。クエリサービスには、自動スケーリング機能があり、同時クエリがサービスのパフォーマンスに大きな影響を与えないようにします。
ORDER
、GROUP BY
、WHERE
、DISTINCT
など、列名として使用できない特定の予約済みキーワードがあります。これらのキーワードを使用する場合は、これらの列をエスケープする必要があります。
次の手順では、UI を使用してデータセットの表形式表示を表示する方法について説明します。これには、ネストされたすべてのフィールドと列がフラット化された形式で表示されます。
クエリエディターまたはサードパーティのクライアントを使用して、ネストされたデータ構造を操作する方法の完全なガイダンスについては、ドキュメントを参照してください。
非常に小さなデータセットでクエリに時間がかかる場合は、カスタマーサポートにお問い合わせください。
処理中にクエリが停止する理由はいくつか考えられます。正確な原因を特定するには、ケースバイケースで詳細な分析が必要です。この処理を行うには、アドビのカスタマーサポートにお問い合わせください。
アドビのカスタマーサポートの電話番号の完全なリストは、アドビのヘルプページで入手できます。または、次の手順を実行してオンラインでヘルプを見つけることもできます。
「ヘルプとサポート」セクションを含むドロップダウンバナーが表示されます。「お問い合わせ」を選択してアドビカスタマーケアバーチャルアシスタントを開くか、 エンタープライズサポート を選択して大規模組織向けの専用ヘルプを入手してください。
カスタム属性を実装する方法は 2 つあります。
はい、準備済み文を使用してクエリをテンプレート化できます。準備済みステートメントは、パフォーマンスを最適化でき、クエリの再解析の繰り返しを回避できます。詳しくは、準備済みステートメントのドキュメントを参照してください。
特定のクエリのエラーログを取得するには、最初にクエリサービス API を使用してクエリログの詳細を取得する必要があります。HTTP 応答には、クエリエラーの調査に必要なクエリ ID が含まれています。
複数のクエリを取得するには、GET コマンドを使用します。API を呼び出す方法については、サンプル API 呼び出しのドキュメントを参照してください。
応答から、調査するクエリを特定し、その id
値を使用して別の GET リクエストを行います。詳細な手順については、ID によるクエリの取得に関するドキュメントを参照してください。
リクエストが成功した場合は、HTTP ステータス 200 が返され、応答に errors
配列が含まれています。ここでは、簡潔にするために、応答は短縮されています。
{
"isInsertInto": false,
"request": {
"dbName": "prod:all",
"sql": "SELECT *\nFROM\n accounts\nLIMIT 10\n"
},
"clientId": "8c2455819a624534bb665c43c3759877",
"state": "SUCCESS",
"rowCount": 0,
"errors": [{
'code': '58000',
'message': 'Batch query execution gets : [failed reason ErrorCode: 58000 Batch query execution gets : [Analysis error encountered. Reason: [sessionId: f055dc73-1fbd-4c9c-8645-efa609da0a7b Function [varchar] not defined.]]]',
'errorType': 'USER_ERROR'
}],
"isCTAS": false,
"version": 1,
"id": "343388b0-e0dd-4227-a75b-7fc945ef408a",
}
クエリサービス API リファレンスドキュメントでは、使用可能なすべてのエンドポイントについて詳しく説明しています。
「スキーマの検証エラー」メッセージは、システムがスキーマ内のフィールドを見つけることができないことを意味します。クエリサービスでのデータアセットの整理のベストプラクティスドキュメントを参照した後、Create Table As Select クエリのドキュメントを参照してください。
次の例は、CTAS 構文と struct データ型の使用方法を示しています。
CREATE TABLE table_name WITH (SCHEMA='schema_name')
AS SELECT '1' as _id,
STRUCT
('2021-02-17T15:39:29.0Z' AS taskActualCompletionDate,
'2020-09-09T21:21:16.0Z' AS taskActualStartDate,
'Consulting' AS taskdescription,
'5f6527c10011e09b89666c52d9a8c564' AS taskguide,
'Stakeholder Consulting Engagement' AS taskname,
'2020-09-09T15:00:00.0Z' AS taskPlannedStartDate,
'2021-02-15T11:00:00.0Z' AS taskPlannedCompletionDate
) AS _workfront ;
SNAPSHOT
句を使用すると、スナップショット ID に基づいて、テーブルのデータを増分的に読み取ることができます。これは、最後の読み込み実行以降に作成または変更されたデータセット内の情報のみを処理する増分読み込みデザインパターンで使用するのに最適です。その結果、処理効率が向上し、ストリーミングデータ処理とバッチデータ処理の両方で使用できます。
プロファイルダッシュボードに表示される数値は、最後のスナップショットの時点で正確です。プロファイル書き出しテーブルで生成される数値は、書き出しクエリに完全に依存します。その結果、特定のセグメントに適格なプロファイルの数をクエリしていることが、この不一致の一般的な原因となっています。
クエリには履歴データが含まれるのに対して、UI には現在のプロファイルデータのみが表示されます。
最も可能性の高い原因は、クエリの範囲が狭すぎることです。データが表示されるようになるまで、WHERE
句のセクションを系統的に削除してください。
次のような小さなクエリを使用して、データセットにデータが含まれていることを確認することもできます。
SELECT count(1) FROM myTableName
この機能は、現在開発中です。詳しくは、リリースノートを参照してください。機能のリリース準備が整った時点で、Platform UI ダイアログを通じて使用可能になります。
クエリサービスには、SQL 機能を拡張するビルトイン SQL ヘルパー関数がいくつか用意されています。クエリサービスでサポートされている SQL 関数の完全なリストについては、ドキュメントを参照してください。
まだ、すべてのオープンソースの Spark SQL 関数がデータレイクデータでテストされているわけではありません。テストして確認すると、サポート対象のリストに追加されます。特定の関数を確認するには、サポート対象の Spark SQL 関数のリストを参照してください。
データセキュリティの考慮事項により、UDF のカスタム定義は許可されていません。
まず、ログを調べてエラーの詳細を確認します。 ログ内のエラーの検索に関する FAQ の節では、これを行う方法について詳しく説明しています。
また、UI でのスケジュール済みクエリの実行と API を使用したスケジュール済みクエリの実行の方法については、ドキュメントを参照してください。
Query Editor を使用する場合にスケジュール済みクエリについて考慮すべき事項を以下に列挙します。Query Service API には適用されません:
既に作成、保存、実行されたクエリにのみスケジュールを追加できます。
パラメーター化クエリにスケジュールを追加することはできません。
スケジュールされたクエリに匿名ブロックを含めることはできません。
UI を使用してスケジュールできるクエリテンプレートは 1 つだけです。クエリテンプレートにスケジュールを追加する場合は、API を使用する必要があります。 API を使用してスケジュールが既に追加されている場合、UI でスケジュールを追加することはできません。
「セッション制限に達しました」とは、組織で許可されているクエリサービスセッションの最大数に達したことを意味します。 組織の Adobe Experience Platform 管理者に連絡してください。
クエリサービスは、クエリ履歴を削除しません。 つまり、削除されたデータセットを参照するクエリが結果として、「有効なデータセットがありません」を返します。
ゼロ行を返すクエリを実行して、応答のメタデータのみを取得できます。 この例のクエリは、指定したテーブルのメタデータのみを返します。
SELECT * FROM <table> WHERE 1=0
一時テーブルを作成して、クエリを素早く繰り返し実験してから、使用するクエリをマテリアライズできます。 また、一時テーブルを使用して、クエリが機能しているかどうかを検証することもできます。
例えば、新しいテーブルを作成できます。
CREATE temp TABLE temp_dataset AS
SELECT *
FROM actual_dataset
WHERE 1 = 0;
次に、一時テーブルを次のように使用できます。
INSERT INTO temp_dataset
SELECT a._company AS _company,
a._id AS _id,
a.timestamp AS timestamp
FROM actual_dataset a
WHERE timestamp >= TO_TIMESTAMP('2021-01-21 12:00:00')
AND timestamp < TO_TIMESTAMP('2021-01-21 13:00:00')
LIMIT 100;
Adobe Experience Platform はデータを UTC(協定世界時)タイムスタンプ形式で保持します。 UTC 形式の例は 2021-12-22T19:52:05Z
です
クエリサービスは、指定されたタイムスタンプを UTC 形式に変換したり、UTC 形式から変換したりするための組み込みの SQL 関数に対応しています。 to_utc_timestamp()
メソッドと from_utc_timestamp()
メソッドのどちらとも 2 つのパラメーター(タイムスタンプとタイムゾーン)を指定します。
パラメーター | 説明 |
---|---|
タイムスタンプ | タイムスタンプは、UTC 形式または単純な {year-month-day} 形式で記述できます。時間を指定しない場合、指定した日の午前 0 時がデフォルト値になります。 |
タイムゾーン | タイムゾーンは {continent/city}) 形式で記述されます。パブリックドメイン TZ データベースにある、認識されているタイムゾーンコードのいずれかである必要があります。 |
この to_utc_timestamp()
メソッドは指定されたパラメーターを解釈し、UTC 形式のローカルタイムゾーンのタイムスタンプに変換します。 例えば、韓国のソウルのタイムゾーンは、UTC/GMT +9 時間です。 日付のみのタイムスタンプを指定すると、メソッドではデフォルト値の午前 0 時が使用されます。 タイムスタンプとタイムゾーンは、UTC 形式(その地域の時刻からローカル地域の UTC タイムスタンプ)に変換されます。
SELECT to_utc_timestamp('2021-08-31', 'Asia/Seoul');
クエリは、ユーザーのローカル時間のタイムスタンプを返します。 この場合、ソウルは 9 時間先なので、前日の午後 3 時になります。
2021-08-30 15:00:00
別の例として、指定されたタイムスタンプが Asia/Seoul
タイムゾーンの 2021-07-14 12:40:00.0
である場合、返される UTC タイムスタンプは 2021-07-14 03:40:00.0
になります
クエリサービス UI で提供されるコンソール出力は、人間が読みやすい形式になっています。
8/30/2021, 3:00 PM
この from_utc_timestamp()
メソッドは、指定されたパラメーターをローカルタイムゾーンのタイムスタンプから解釈し、目的の地域の同等のタイムスタンプを UTC 形式で提供します。 次の例では、時間はユーザーのローカルタイムゾーンの午後 2 時 40 分になります。 変数として渡されるソウルのタイムゾーンは、ローカルタイムゾーンの 9 時間前です。
SELECT from_utc_timestamp('2021-08-31 14:40:00.0', 'Asia/Seoul');
クエリは、パラメーターとして渡されたタイムゾーンのタイムスタンプを UTC 形式で返します。 結果は、クエリを実行したタイムゾーンより 9 時間早くなります。
8/31/2021, 11:40 PM
時系列データに対するクエリを実行する場合は、可能な限りタイムスタンプフィルターを使用して、より正確な分析を行う必要があります。
日付文字列は yyyy-mm-ddTHH24:MM:SS
の形式である必要があります。
タイムスタンプフィルターの使用例を以下に示します。
SELECT a._company AS _company,
a._id AS _id,
a.timestamp AS timestamp
FROM dataset a
WHERE timestamp >= To_timestamp('2021-01-21 12:00:00')
AND timestamp < To_timestamp('2021-01-21 13:00:00')
CAST
演算子を正しく使用して SQL クエリのタイムスタンプを変換する方法を教えてください。CAST
演算子を使用してタイムスタンプを変換する場合は、日付および時間の両方を含める必要があります。
例えば、以下に示すように、時間コンポーネントが見つからない場合、次のエラーが発生します。
SELECT * FROM ABC
WHERE timestamp = CAST('07-29-2021' AS timestamp)
CAST
演算子の正しい使用法を以下に示します。
SELECT * FROM ABC
WHERE timestamp = CAST('07-29-2021 00:00:00' AS timestamp)
ワイルドカードを使用して行からすべてのデータを取得することはできません。クエリサービスは従来の行ベースのストアシステムではなく、列ストアとして扱われる必要があるためです。
NOT IN
を使用する必要がありますか?NOT IN
演算子は、他のテーブルや SQL 文に見つからない行を取得する場合によく使用されます。この演算子を使用するとパフォーマンスが低下する可能性があるほか、比較対象の列に NOT NULL
が指定されていたり、大量のレコードが存在したりする場合、予期せぬ結果が返されることがあります。
NOT IN
を使用する代わりに、NOT EXISTS
または LEFT OUTER JOIN
の使用を推奨します。
例えば、次のテーブルを作成したとします。
CREATE TABLE T1 (ID INT)
CREATE TABLE T2 (ID INT)
INSERT INTO T1 VALUES (1)
INSERT INTO T1 VALUES (2)
INSERT INTO T1 VALUES (3)
INSERT INTO T2 VALUES (1)
INSERT INTO T2 VALUES (2)
NOT EXISTS
演算子を使用して次のクエリを実行すれば、NOT IN
演算子を使用せずに同じ機能を実行できます。
SELECT ID FROM T1
WHERE NOT EXISTS
(SELECT ID FROM T2 WHERE T1.ID = T2.ID)
あるいは、LEFT OUTER JOIN
演算子を使用して次のクエリを実行しても、NOT IN
演算子を使用せずに同じ機能を実行できます。
SELECT T1.ID FROM T1
LEFT OUTER JOIN T2 ON T1.ID = T2.ID
WHERE T2.ID IS NULL
test_table_001
。いいえ。これは、クエリサービスを含むすべてのアドビサービスに適用される、Experience Platform 全体にわたる意図的な制限です。スキーマ名とデータセット名にはアンダースコアを 2 つ入れることができますが、データセットのテーブル名には 1 つしか入れられません。
バッチクエリがバックエンドジョブとして実行されるので、クエリの同時実行制限はありません。ただし、クエリのタイムアウト制限は 24 時間に設定されています。
クエリのアクティビティとステータスを確認するための監視機能と警告機能があります。詳しくは、クエリサービス監査ログの統合およびクエリログに関するドキュメントを参照してください。
現在、ロールバックやそのような更新はサポートされていません。
システムはデータベースではないのでインデックスを持っていませんが、データストアに関連付けられた他の最適化方法が用意されています。次のオプションを使用して、クエリを調整できます。
クエリサービスは、「すべて許可かすべて禁止」のソリューションです。部分的なアクセス権限は提供できません。
可能です。読み取り専用アクセス権限を持つデータセットのみにクエリ実行対象を制限できます。
アクセスを制限する方法は 3 つあります。次の 3 つです。
はい。SSL モードはサポートされています。使用可能な SSL モードの分類とその保護レベルについて詳しくは、SSL モードのドキュメントを参照してください。
はい。 転送中のデータはすべて HTTPS に準拠しています。現在サポートされているバージョンは TLS1.2 です。
はい、ポート 80 で確立された接続では SSL を使用します。 また、ポート 5432 を使用することもできます。
はい。設定に応じて、属性ベースのアクセス制御が適用されます。 詳しくは、属性ベースのアクセス制御の概要を参照してください。
いいえ、クエリサービスは「INSERT OVERWRITE INTO」コマンドをサポートしていません。
この節では、データの書き出しと制限について説明します。
はい。 クエリサービスからデータを抽出でき、SQL コマンドを使用して結果を CSV 形式で保存するオプションもあります。
PSQL クライアントを使用する場合、クエリの結果を保存する方法は 2 つあります。 COPY TO
コマンドを使用するか、次の形式を使用してステートメントを作成できます。
SELECT column1, column2
FROM <table_name>
\g <table_name>.out
COPY TO
コマンドの使用に関するガイダンスは、SQL 構文リファレンスドキュメントに記載されています。
いいえ。現在、取り込んだデータを抽出する機能はありません。
この問題の一般的な原因は、時間フィルターを使用せずに時系列データをクエリすることです。 以下に例を示します。
SELECT * FROM prod_table LIMIT 1;
次のように記述する必要があります。
SELECT * FROM prod_table
WHERE
timestamp >= to_timestamp('2022-07-22')
and timestamp < to_timestamp('2022-07-23');
この節では、サードパーティのツール(PSQL や Power BI など)の使用に関する情報を示します。
はい。複数のサードパーティ製デスクトップクライアントをクエリサービスに接続できます。 使用可能なクライアントと、それらをクエリサービスに接続する方法の詳細については、ドキュメントを参照してください。
はい。有効期限のない資格情報を 1 回設定するだけで、サードパーティ製デスクトップクライアントをクエリサービスに接続できます。 許可されたユーザーが有効期限のない資格情報を生成し、ローカルマシンに自動的にダウンロードされる JSON ファイルで受信できます。 有効期限のない資格情報の作成とダウンロード方法に関する完全なガイダンスはドキュメントに記載されています。
有効期限のない資格情報の値は、設定 JSON ファイルから取得した technicalAccountID
と credential
からの連結引数です。パスワードの値は {{technicalAccountId}:{credential}}
形式で指定します。
資格情報を使用して外部クライアントに接続する方法について詳しくは、ドキュメントを参照してください。
PSQL または Postgres クライアントに準拠したサードパーティ製の SQL エディターであれば、クエリサービスエディターに接続できます。 使用可能な手順のリストについては、クエリサービスへのクライアントの接続のドキュメントを参照してください。
はい、Power BI をクエリサービスに接続できます。 Power BI デスクトップアプリをクエリサービスに接続する手順については、ドキュメントを参照してください。
クエリサービスに接続されている場合、システムはインタラクティブまたはバッチ処理エンジンに接続されています。その結果、処理されたデータを反映するための読み込み時間が長くなる可能性があります。
ダッシュボードの応答時間を改善する場合は、Business Intelligence(BI)サーバーを、クエリサービスと BI ツールの間のキャッシュレイヤーとして実装する必要があります。 通常、ほとんどの BI ツールには、サーバー用の追加のオファリングがあります。
キャッシュサーバーレイヤーを追加する目的は、クエリサービスからのデータをキャッシュし、それをダッシュボードで利用して応答を高速化することです。 実行されるクエリの結果が毎日 BI サーバーにキャッシュされるので、この処理が可能です。 次に、キャッシュサーバーは、同じクエリを使用するすべてのユーザーにこれらの結果を提供し、待ち時間を短縮します。 この設定の説明については、使用しているユーティリティまたはサードパーティツールのドキュメントを参照してください。
いいえ、pgAdmin 接続には対応していません。 使用可能なサードパーティクライアントの一覧と、それらをクエリサービスに接続する方法については、ドキュメントを参照してください。
次の表に、PSQL エラーコードと考えられる原因を示します。
エラーコード | 接続状態 | 説明 | 考えられる原因 |
---|---|---|---|
08P01 | なし | メッセージの種類がサポートされていません。 | メッセージの種類がサポートされていません。 |
28P01 | 起動 - 認証 | パスワードが無効です。 | 認証トークンが無効です。 |
28000 | 起動 - 認証 | 認証タイプが無効です。 | 認証タイプが無効です。AuthenticationCleartextPassword である必要があります。 |
42P12 | 起動 - 認証 | テーブルが見つかりません。 | 使用するテーブルが見つかりません。 |
42601 | クエリ | 構文エラー。 | コマンドが無効であるか、構文にエラーがあります。 |
42P01 | クエリ | テーブルが見つかりません。 | クエリで指定されたテーブルが見つかりませんでした。 |
42P07 | クエリ | テーブルが存在します | 同じ名前のテーブルが既に存在します(CREATE TABLE) |
53400 | クエリ | LIMIT が最大値を超えています。 | ユーザーが LIMIT 句で 100,000 を超える行数を指定しました。 |
53400 | クエリ | ステートメントがタイムアウトになりました。 | 送信されたステートメントの処理時間が最大値の 10 分を超えました。 |
58000 | クエリ | システムエラー。 | 内部システム障害が発生しています。 |
0A000 | クエリ/コマンド | サポートなし | クエリ/コマンドの機能はサポートされていません |
42501 | DROP TABLE クエリ | クエリサービスで作成されていないテーブルの削除中 | 削除中のテーブルは、CREATE TABLE 文を使用してクエリサービスで作成されたものではありません |
42501 | DROP TABLE クエリ | 認証済みユーザーが作成していないテーブル | 削除中のテーブルは、現在ログインしているユーザーによって作成されたものではありません |
42P01 | DROP TABLE クエリ | テーブルが見つかりません。 | クエリで指定されたテーブルが見つかりませんでした |
42P12 | DROP TABLE クエリ | dbName のテーブルが見つかりません。dbName を確認してください |
現在のデータベースにテーブルが見つかりませんでした |
history_meta()
メソッドを使用して、データセットからスナップショットにアクセスします。 以前は、Azure Data Lake Storage(ADLS)の空のデータセットに対してクエリを実行すると、データセットが存在しないことを示す 58000 エラーコードが表示されていました。 古いシステムエラーの例を以下に示します。
ErrorCode: 58000 Internal System Error [Invalid table your_table_name. historyMeta can be used on datalake tables only.]
クエリに戻り値がないために、このエラーが発生しました。 この動作が修正され、次のメッセージが返されるようになりました。
Query complete in {timeframe}. 0 rows returned.
次の表に、HTTP エラーコードと考えられる原因を示します。
HTTP ステータスコード | 説明 | 考えられる原因 |
---|---|---|
400 | Bad request | クエリの形式が不正であるか、不正なクエリです。 |
401 | Authentication failed | 認証トークンが無効です。 |
500 | Internal server error | 内部システム障害が発生しています。 |