クエリサービスとデータDistillerに関するよくある質問

クエリがタイムアウトした場合に備えて、次の解決策の 1 つ以上をお勧めします。

• クエリを CTAS クエリに変換し、実行をスケジュールします。実行のスケジュールは、UI または API を使用して設定できます。
• 追加のフィルター条件を適用して、より小さいデータチャンクに対してクエリを実行します。
• EXPLAIN コマンドを実行して、詳細を収集します。
• データセット内のデータの統計を確認します。
• クエリを簡略化された形式に変換し、準備済み文を使用して再実行します。

次の手順では、UI を使用してデータセットの表形式表示を表示する方法について説明します。これには、ネストされたすべてのフィールドと列がフラット化された形式で表示されます。

• Experience Platform にログインした後、UI の左側のナビゲーションで「データセット」を選択して、データセットダッシュボードに移動します。
• データセットの「参照」タブが開きます。検索バーを使用して、使用可能なオプションを絞り込むことができます。表示されたリストからデータセットを選択します。

• データセットアクティビティ画面が表示されます。「データセットをプレビュー」を選択して、XDM スキーマのダイアログと、選択したデータセットからフラット化されたデータの表形式表示を開きます。詳しくは、データセットのプレビューに関するドキュメントを参照してください

• スキーマから任意のフィールドを選択して、フラット化された列にその内容を表示します。列の名前は、ページの右側の内容の上に表示されます。この名前をコピーして、このデータセットのクエリに使用する必要があります。

クエリエディターまたはサードパーティのクライアントを使用して、ネストされたデータ構造を操作する方法の完全なガイダンスについては、ドキュメントを参照してください。

非常に小さなデータセットでクエリに時間がかかる場合は、カスタマーサポートにお問い合わせください。

処理中にクエリが停止する理由はいくつか考えられます。正確な原因を特定するには、ケースバイケースで詳細な分析が必要です。この処理を行うには、アドビのカスタマーサポートにお問い合わせください。

Adobe カスタマーサポートの電話番号の完全なリスト ​ は、Adobeのヘルプページで入手できます。 または、次の手順を実行してオンラインでヘルプを見つけることもできます。

• Web ブラウザーで https://www.adobe.com/ に移動します。
• 上部のナビゲーションバーの右側にある「ログイン」を選択します。

• Adobe ライセンスに登録されている Adobe ID とパスワードを使用します。
• 上部のナビゲーションバーから「ヘルプとサポート」を選択します。

「ヘルプとサポート」セクションを含むドロップダウンバナーが表示されます。「お問い合わせ」を選択してアドビカスタマーケアバーチャルアシスタントを開くか、  エンタープライズサポート  を選択して大規模組織向けの専用ヘルプを入手してください。

匿名ブロック機能を使用すると、順に実行される 1 つ以上の SQL 文を連結できます。また、例外処理のオプションも使用できます。

詳しくは、匿名ブロックのドキュメントを参照してください。

カスタム属性を実装する方法は 2 つあります。

1. 既存の Adobe 定義関数の組み合わせを使用して、使用例のニーズが満たされているかどうかを特定します。
2. 前の提案が使用例を満たさない場合は、ウィンドウ関数を組み合わせて使用する必要があります。ウィンドウ関数は、シーケンス内のすべてのイベントを調べます。また、履歴データを確認でき、任意の組み合わせで使用することもできます。

特定のクエリのエラーログを取得するには、まず Query Service 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 ;

プロファイルダッシュボードに表示される数値は、最後のスナップショットの時点で正確です。 プロファイル書き出しテーブルで生成される数値は、書き出しクエリに完全に依存します。その結果、特定のオーディエンスに適格なプロファイルの数をクエリしていることが、この不一致の一般的な原因となっています。

最も可能性の高い原因は、クエリの範囲が狭すぎることです。 データが表示されるようになるまで、WHERE 句のセクションを系統的に削除してください。

次のような小さなクエリを使用して、データセットにデータが含まれていることを確認することもできます。

SELECT count(1) FROM myTableName

まず、ログを調べてエラーの詳細を確認します。 ログ内のエラーの検索に関する FAQ の節では、これを行う方法について詳しく説明しています。

また、UI でのスケジュール済みクエリの実行と API を使用したスケジュール済みクエリの実行の方法については、ドキュメントを参照してください。

Query Editor を使用する場合、既に作成および保存されたクエリにのみスケジュールを追加できます。 これは、Query Service API には適用されません。

ゼロ行を返すクエリを実行して、応答のメタデータのみを取得できます。 この例のクエリは、指定したテーブルのメタデータのみを返します。

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 タイムスタンプに変換

この 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

UTC タイムスタンプからの変換

この from_utc_timestamp() メソッドは、指定されたパラメーターを​ ローカルタイムゾーンのタイムスタンプから ​解釈し、目的の地域の同等のタイムスタンプを UTC 形式で提供します。 次の例では、時間はユーザーのローカルタイムゾーンの 2:40PM です。 変数として渡されるソウルのタイムゾーンは、ローカルタイムゾーンの 9 時間前です。

SELECT from_utc_timestamp('2021-08-31 14:40:00.0', 'Asia/Seoul');

クエリは、パラメーターとして渡されたタイムゾーンのタイムスタンプを UTC 形式で返します。 結果は、クエリを実行したタイムゾーンより 9 時間早くなります。

8/31/2021, 11:40 PM

時系列データをフィルタリングするにはどうすればよいですか？

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 演算子を使用してタイムスタンプを変換する場合は、日付 および時間 両方を含める必要があります。

例えば、以下に示すように、時間コンポーネントが見つからない場合、次のエラーが発生します。

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 演算子は、他のテーブルや 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

システムはデータベースではないのでインデックスを持っていませんが、データストアに関連付けられた他の最適化方法が用意されています。 次のオプションを使用して、クエリを調整できます。

• timeseries データの時系列でのフィルタリング。
• 構造体データタイプのプッシュダウンの最適化。
• 配列とマップのデータタイプのコスト面およびメモリ面におけるプッシュダウンの最適化。
• スナップショットを使用した増分処理。
• 一貫性のあるデータ形式。

アクセスを制限する方法は 3 つあります。 次の 3 つです。

• SELECT ステートメントのみを使用し、データセットに読み取り専用アクセス権限を付与します。また、クエリ管理権限も割り当てます。
• SELECT／INSERT／CREATE ステートメントを使用して、データセットに書き込みアクセス権限を付与します。また、クエリ管理権限を割り当てます。
• 上に提示した方法で統合アカウントを使用するとともに、クエリ統合権限を割り当てます。

開発用サンドボックスと実稼動用サンドボックスの両方でクエリを実行すると、同様のパフォーマンスが期待できます。 どちらの環境も、同じレベルの処理能力を提供するように設計されています。 ただし、処理するデータの量やクエリ実行時の全体的なシステムアクティビティによって、計算時間の違いが生じる場合があります。

Experience Platform UI の ​ ライセンス使用状況ダッシュボード ​ でコンピューティング時間の使用状況を追跡します。

はい。クエリサービスからデータを抽出でき、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');

システムがクエリサービスに接続されると、インタラクティブまたはバッチ処理エンジンに接続されます。 その結果、処理されたデータを反映するための読み込み時間が長くなる可能性があります。

ダッシュボードの応答時間を改善する場合は、Business Intelligence（BI）サーバーを、クエリサービスと BI ツールの間のキャッシュレイヤーとして実装する必要があります。 通常、ほとんどの BI ツールには、サーバー用の追加のオファリングがあります。

キャッシュサーバーレイヤーを追加する目的は、クエリサービスからのデータをキャッシュし、それをダッシュボードで利用して応答を高速化することです。 実行されるクエリの結果が毎日 BI サーバーにキャッシュされるので、この処理が可能です。 次に、キャッシュサーバーは、同じクエリを使用するすべてのユーザーにこれらの結果を提供し、待ち時間を短縮します。 この設定の説明については、使用しているユーティリティまたはサードパーティツールのドキュメントを参照してください。

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.