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

#目的

このチュートリアルでは、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 ページに切り替えます。このページでは、データモデル内のすべての物理的およびバーチャル属性と、プロジェクト内のラインナージを一覧表示できます。

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

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

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

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

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

#アクション

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

Click on the Actions menu of your Data Processing Engine. You should see the two Load actions that were automatically generated in the previous step:

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

#さらにアクションを作成

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

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

新しいアクションをクリックし、Platform Storeから集約アクションテンプレートを選択します。

アグリゲートアクションを設定するには、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

↪ Aggregate actionsについてさらに詳しく学ぶ

作成をクリックします。

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

↪ アクションについての製品ドキュメントでさらに詳しく学ぶ

#ワークフロー

ワークフローは、アクションを実行する順序を定義します。

ワークフロー内では、アクションは連続したステージに組織化されます。ステージ内では、すべてのアクションが並列で実行されますが、ステージは常に連続して実行されます。同じアクションは、同じワークフロー内で複数回使用することができます。ワークフローは、アクションと同様に、手動で起動したり、スケジュールに基づいて実行したり、APIコールを通じてトリガーを設定したりすることができます。

最初のワークフローを作成するには、ワークフロー タブに移動し、新しいワークフロー をクリックしてください。設定またはヘッダー名をダブルクリックして、新しい名前 Chicagoデータのインポート を設定します。

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

ワークフローを作成した後（作成）に、再生をクリックします。

ワークフローが実行中の場合、トリガーを使用して毎日実行するようにスケジュール設定することができます。

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

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

確認 ボタンをクリックして、任意の名前を付けた新しいトリガーイベントを作成し、トリガーイベントテーブルにデフォルトで表示されている エンドポイントの起動 の下に追加します。

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

#Jobs

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

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

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

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

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

#Go further

トレーニングや技術的なサポートを受けて、当社のソリューションを実装する場合は、営業担当者にお問い合わせください、またはProfessional Servicesページをご覧ください。見積もりをリクエストし、当社の専門家にプロジェクトを分析してもらうことができます。

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

OVHcloudサービスについてサポートが必要な場合は、Help Centreでリクエストを作成してください。

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