データモデルの作成と構築 - 外部データセット#

#目的

このチュートリアルでは、Lakehouse Managerを使用して「はじめに」チュートリアルの2番目のステップ、データ処理エンジンを使用して3番目のステップを行う方法を説明します。

#データをテーブルで整理する

#プライマリスキーマを作成する

#データモデルにテーブルを追加する

メタデータを抽出したら、次は Tables ダッシュボード に移動します。ここでは、すべてのデータの 統合されたクエリ可能なビューを構築 します。

空の Tables ページは次のように表示されます。

All tables タブでは、すべてのデータにアクセスできます。 New View タブでは、データの一部のみを表示するビューを作成できます。これにより、大規模なチームでの協力が容易になります。このチュートリアルはシンプルなものなので、 All tables タブで作業してください。

次に、プライマリテーブルとその属性を作成することに集中しましょう。

まず、画面の左側にある青い ➕ アイコンの上にカーソルを合わせます。これにより、作成オプションが表示されます。

• ファイルをアップロード
• コネクタソースから作成
• 空のテーブルを作成

コネクタソースから作成 をクリックすると、前のステップで表示されたソースのリストが表示されます。追加したいソースをクリックし、 次へ をクリックして進みます。ここで、作成した外部データセットのいずれかを選択できます。ここでは、他のデフォルト設定を変更する必要はありません。

作成 をクリックし、同じ手順を2番目のテーブルでも繰り返します。

この段階で、Tables ページは次のように表示されます。

テーブル内の一部の属性が 太字 で表示されていることに気づくかもしれません。プラットフォームは、それらが プライマリキー であったことを自動的に検出しました。つまり、テーブル内の各データ行を一意に識別するために使用される属性（または属性のセット）です。

#テーブルを結合する

Lakehouse Manager に、テーブル間の関係を伝える必要があります。

親/子関係にあるテーブルを結合します。 親 は、特定の主題についての詳細情報を持つテーブルです。例えば、シカゴの特定の日付の天気です。 子 テーブルは、複数の親テーブルを参照します。別の言い方をすれば、子テーブルは親テーブルから値を継承します（現実の子供のように、ただし子供は2人以上の親を持つことができます!）。

テーブル stations_rides は子テーブルです。日付と駅ごとの乗車情報を含みます。しかし、日付についての詳細情報は含まれていません。両方のテーブルに date がプライマリキーとしてあります。したがって、 chicago_calendar_full 親テーブルを stations_rides 子テーブルにリンクすると、1年間の各日の乗車情報に天気情報が自動的に追加されます。

まず、 chicago_calendar_full 親テーブルをクリックして選択し、次にテーブルの下部にある白い円をクリックします。

子テーブル stations_rides に矢印をドラッグして、ドロップ/クリック解除します。画面は次のように表示されます。

#集約テーブルを作成する

次に、ソース（主に乗車、日付、温度）からすべての重要なデータを1つのテーブルに集約します。このテーブルは、最終アプリケーションで使用されます。集約テーブルは、複数のソーステーブルからデータを統合します。

最初の集約テーブルを作成するには、青い ➕ アイコンをクリックします。 空のテーブルを作成 を選択すると、新しいテーブル構成が表示され、名前（例: dataset_history）を設定して保存できます。

次に、ソーステーブル stations_rides から date と station_id をテーブル dataset_history にドラッグアンドドロップし、これらの属性をプライマリキーとして設定します。

以下の属性を dataset_history に移動し、キーとして設定しないでください（これらは各行の単純なデータであり、一意ではないため）。

最後に、数値温度データを理解できるカテゴリ（寒い、暑いなど）に変換するのに役立つ新しい属性を作成する必要があります。

まず、テーブル dataset_history をクリックすると、上部に ➕ アイコンが表示されます。これで、テーブル内で属性を作成または編集できます。

属性を次のように定義します。

Tables についてさらに学ぶ

#ビルドを完了する

次に、青い ➕ アイコンの下にある Build アイコンをクリックして、実際にテーブルと属性をデータセットに作成/更新します。これにより、データがテーブルに読み込まれるわけではありません（これは次の記事で行われます）。これは、基盤となるデータセット内のテーブルと属性に論理スキーマを適用するだけです。

このチュートリアルのビルドタスクは、数分で完了するはずです。完了したら、次に進むことができます。

#バーチャル属性で関連するメトリクスを追加する

このモデルへのデータの物理的な処理（ETL/ELT）に進む前に、後で分析に使用する追加のメトリクスを準備しましょう。このチュートリアルに従って構築している最終アプリケーションには、特定の駅での1日の乗車数 を示すチャートが含まれています。

ただし、このチャートをプライマリソースに直接構築するための必要なデータはありません。特定の駅の1日の平均乗車数を示すメトリクスが必要です。このメトリクスは、クエリとダッシュボードで使用できます。

しかし、プラットフォームを使用してそれをどのように計算しますか? その方法の1つは、バーチャル属性 を作成することです。バーチャル属性を使用すると、SQL式を計算できます。これらは オンデマンドで計算 され、データベースに保存されません。最終ダッシュボードのクエリまたはチャートで使用できます。

Attributes ページに切り替えます。このページには、データモデル内のすべての物理的およびバーチャル属性と、プロジェクト内のラインナージが表示されます。

新しい属性 ボタンをクリックして、バーチャル属性を作成します。

作成ウィンドウでは、領域として Virtual を選択していることを確認します。

次に、これらの2つの属性とそれぞれのSQLコードを追加します。

yearmonth 属性は、 yyyy-mm 形式の年と月を提供します。後で使用します。

• 新しい物理属性を追加すると、ストレージを使用し、Data Processing Engine で物理的に定義する必要がありますが、これにより、データモデル全体を変更せずに、その仕様を編集できるため、より厳密になります。
• バーチャル属性は、スケーリング時に修正する必要がある場合、管理が難しくなる可能性がありますが、素早く簡単に設定できます。

#Actions

アクション は、データに対する単一の物理操作です。アクションは、ワークフロー と呼ばれる自動化されたデータ処理パイプラインを生成するために、ステージに組織化できます。

Data Processing Engine の Actions メニューをクリックしてください。前のステップで自動的に生成された 2 つの Load アクションが表示されるはずです。

これらの Load アクションは、Lakehouse Manager で作成したスキーマに従って、ソースからデータを物理的に抽出し、データウェアハウスに読み込みます。

#さらに多くのアクションを作成する

カスタムアクションについてさらに詳しく。

このチュートリアルでは、前の部分で作成した dataset_history テーブルにデータを集約するために使用されるアクションを作成します。

New action をクリックし、Platform Store から Aggregate action テンプレートを選択します。

集約アクションを構成するには、2 つの簡単なステップがあります。

• (1) ソーステーブルを選択します: stations_rides
• (2) 宛先テーブルを選択します: dataset_history

数秒後、Data Processing Engine は自動的にすべての必要な結合条件を見つけ、属性をマッピングします。

ドロップダウンメニューを使用して、結合条件を INNER join に変更します。これにより、dataset_history テーブルのレコードに null フィールドがないことを確保できます。

属性は自動的にマッピングされています。属性 rides を見つけ、これは集約したいメトリクスです。これを SUM 関数に切り替えます。その他の場所では、MAX 関数をそのままにしておいてください:ほとんどの DBMS では、GROUP BY 句の一部ではない属性に集約句を適用する必要があります。

最後に、以前に作成したカテゴリ属性 cat_temperature を定義します。下に示すように、青いオプションのドロップダウンで < map > (「マッピング」の略) オプションをクリックし、< sql > に切り替えます。

以下の SQL コマンドをコピーして貼り付けます。

CASE 
WHEN MAX(chicago_calendar_full.temperature)<40 THEN 'very cold'
WHEN MAX(chicago_calendar_full.temperature)<48 THEN 'cold'
WHEN MAX(chicago_calendar_full.temperature)<55 THEN 'medium'
WHEN MAX(chicago_calendar_full.temperature)<62 THEN 'hot'
ELSE 'very hot'
END

集約アクションについてさらに詳しく。

右上の Create をクリックします。

これで、このチュートリアルに必要なすべてのアクションを生成しました。

製品ドキュメントで Actions についてさらに詳しく。

#Workflows

ワークフローは、アクションを... アクションにするための映画の脚本のようなものです。 🎬

ワークフロー内では、アクションが連続したステージに組織化されます。ステージ内では、すべてのアクションが並列で実行されますが、ステージは常に前のステージの後に実行されます。同じアクションを、同じワークフロー内で複数回使用できます。ワークフローは、アクションと同様に、手動で実行したり、スケジュールで実行したり、API 呼び出しでトリガーしたりできます。

最初のワークフローを作成するには、Workflow タブに移動し、New Workflow をクリックします。好みの設定に移動するか、ヘッダー名をダブルクリックして、新しい名前 Import Chicago Data を設定します。

まず、Add a stage をクリックして、2 つの異なるステージを定義します。次に、各ステージにアクションを追加するには、ドロップダウン検索セレクターを使用します。各ステージのガイドとして、提供されたスクリーンショットに従います。

ワークフローを作成 (create) した後、Play をクリックします。

ワークフローが実行されている間、トリガーを使用して 毎日実行するようにスケジュール することができます。

ワークフローの Preferences タブに移動し、左下のトリガーウィジェットを下にスクロールします。 +Add をクリックします。

トリガーの種類を CRON に、モードを Simple に選択します。 Daily タブに移動し、下の画像に示すように、オプションのリストから Every 1 day(s) を選択します。

Confirm ボタンをクリックして、任意の名前で新しいトリガーイベントを作成し、デフォルトで Trigger イベントテーブルに表示される Launch Endpoint の下に追加します。

実行好みの設定についてさらに詳しく。

#ジョブ

このセクションを締めくくるために、Data Processing Engineコンポーネントの最後のタブであるジョブについて、いくつかの言葉を紹介します。

ジョブタブは、Data Processing Engineでトリガーされたすべての実行をまとめ、高度なメトリクスレポートを含みます。ジョブは、実行中、キューイング中、過去の実行の3つの主要なカテゴリにリストされます。最後に実行されたジョブを確認することで、たった今起動したワークフローの状態を確認できます。

これで、Getting Started チュートリアルのData Engineeringセクションは完了しました 🌟

データが正しく読み込まれたかどうかを確認する良い方法は、Lakehouse Managerに戻り、テーブルに読み込まれた行数を確認することです。リストビューモードを開き、rows列を確認してください。フィールドに数字が表示されている場合（読み込まれた行数を示す）は、すべてうまく動作しました。

Getting Startedチュートリアルを続ける場合は、step-4: the Analytics Managerに直接進むことができます。

#さらに詳しく

当社のソリューションを実装するためのトレーニングや技術サポートが必要な場合は、営業担当者にお問い合わせください、またはこのリンクをクリックして見積もりを依頼し、当社のプロフェッショナルサービスの専門家にプロジェクトのカスタム分析を依頼してください。

Data Platformを構築するチームと直接質問し、フィードバックを共有し、交流するには、専用のDiscordチャネルに参加してください。

OVHcloudサービスについてサポートが必要な場合は、当社のヘルプセンターでリクエストを作成してください。

当社のユーザーコミュニティに参加してください。