• 使用を開始する
  • 関連ドキュメント

Atlassian Data Lake のデータ モデルについて理解する

Each app has its own set of tables and columns in the Atlassian Data Lake. If you choose to include all data for your apps, more columns are added to each of those tables.

現時点では、Jira、Jira Service Management、Jira Product Discovery、Confluence、Focus、ゴール、Atlassian プロジェクトのデータのみが、Atlassian Data Lake で利用できます。今後、より多くのアプリ用のデータが利用可能となる予定です。

The app tables capture app data in a star schema, meaning some tables refer to other tables. Because of this, you may need to join multiple queries to get the data you need in Atlassian Analytics.

データ共有のデータ モデル

データ共有を使用すると、Atlassian Data Lake を組織の環境またはサードパーティ ツールに接続できます。ただし、データ共有のデータ モデルは、Atlassian Analytics で利用できるものとは異なります。データ共有のデータ モデルの詳細をご確認ください。

データの鮮度

For most tables, it can take an average of 90 minutes for changes in your apps to reflect in the Data Lake. This makes them especially useful for custom analysis, or when having the most up-to-date information is important.

However, the following tables take about 5 to 8 hours for app changes to reflect:

  • goal_hierarchy

  • jira_issue

  • jira_issue_cycle_time

  • jira_issue_field

  • jira_issue_status_history

  • jira_project

ライブ Jira テーブル

上記の Jira テーブル (jira_issue_cycle_time を除く) には対応する「ライブ」テーブルもあり、変更が反映されるまで最大 90 分かかります。

  • jira_issue_live

  • jira_issue_field_live

  • jira_issue_status_history_live

  • jira_project_live

これらのテーブルはより新しいデータを保持しますが、クエリのパフォーマンスが大幅に低下することに注意してください。これは、事前に計算されたデータのスナップショットを使用する、対応する非「ライブ」テーブルとは異なり、データが照会されるたびにテーブルが計算されるためです。

Data Lake の日付とタイムスタンプ

日付とタイムスタンプのを含む列 (created_atupdated_at、など) はすべて UTC タイムゾーンであることに注意してください。これらを変換して別のタイムゾーンを使用するには、ワークスペース設定でワークスペースのタイムゾーンを変更するか、ダッシュボードの設定で個々のダッシュボードのタイムゾーンを変更します。

命名規則

テーブルと列の SQL 名に、特定の目的を示す特定の単語が含まれる場合があります。

テーブル名

_mapping

SQL 名にこのサフィックスが付いているテーブルには、その他のテーブルへの外部キーが格納されています。このテーブルの主な機能は、分析してインサイトを得るためにテーブルを横断してデータを組み合わせることです。

たとえば、Opsgenie スキーマの opsgenie_alert_responder_mapping テーブルは、どの対応者タイプがアラートに応答したかを表示するためのものです。このテーブルには、opsgenie_teamopsgenie_scheduleopsgenie_escalationatlassian_account、の各テーブルへの外部キーがあります。

_history または _history_

SQL 名に history が付いているテーブルには、特定のオブジェクトに関する現在までのすべての更新が格納されます。これに対応して、ほとんどの履歴テーブルには、そのオブジェクトの最新情報のみが格納される履歴なしテーブルがあります。

For example, the jira_issue_history table captures an update whenever Jira sends us any new data for the same work item (indicated by its ID). This is usually done on some particular event or state change like when the work item transitions to a different status. All of those events for the particular work item are stored in the history table. The non-history table, jira_issue, only stores the latest update to the work item.

列の名前

_id

このサフィックスは主キーと外部キー専用です。これらの列を使用してテーブルを結合します。

For example, in the jira_issue table, issue_id is the primary key for a work item object, and project_id is a foreign key that can be used to join this table to the jira_project table.

_by または account_id または _account_id

このサフィックスは、列が account テーブルの外部キーであることを示します。列には、アカウントが実行したアクションのアカウント識別子が格納されます。

たとえば、confluence_page テーブルの created_by にある値は、ページを作成したユーザーのアカウント ID です。

唯一の例外は、account テーブルの account_id 列です。これはそのテーブルの主キーです。

_at または _until

これらのサフィックスは、値がタイムスタンプになることを示します。たとえば、confluence_page テーブルのcreated_atopsgenie_alert テーブルの snoozed_until などです。

_ref

This suffix indicates the values will be in-app identifiers for a specific object—for example, issue_ref in the jira_issue table. This is not the same as the object’s ID (_id suffix), which is a unique identifier in the Data Lake and should be used for joins.

さらにヘルプが必要ですか?

アトラシアン コミュニティをご利用ください。