プロジェクトのチェックリストとベストプラクティス#

#目的

プロジェクトを開始し、プロジェクトを立ち上げました！素晴らしいです！

次に何をすればよいでしょうか？どこから始めればよいでしょうか？

当プラットフォームの最初のユーザーとして、私たちはこれまで数年間にわたりデータプロジェクトを実施してきました。これらの経験を通じて、私たちはこれまでのサービス実績から得たベストプラクティスのリストをまとめました。それを皆様と共有できることを楽しみにしています。

Data Platform 上のプロジェクトでは、チームを編成し、同じデータプロジェクトで一緒に作業することができます。 基本的なファイルアップロードから始め、スムーズにほぼリアルタイムのデータ処理に切り替えることができます。方法論を維持し、プロジェクトが成長するにつれて簡単にスケールアップできます。 したがって、プロジェクトをステップバイステップで開始し、反復し、成長させることができます。プロジェクトは、成長するニーズに応えることができます。

典型的なプロジェクトは、通常、次の主要なマイルストーンを経て進みます。

• ユースケースとプロジェクトの範囲についてのチェックリスト
• チームメンバーにアクセス権を付与
• 必要に応じて反復的に実行する:
  • プロジェクトリソースを必要に応じて調整する
  • データソースを定義する
  • テーブルを設計する
  • データを処理するアクションとワークフローを構築する
  • クエリとダッシュボードを構築し、データを可視化する
  • アプリ＆APIを構築する
  • エンドユーザーにアクセス権を付与
  • ジョブとデプロイメントを監視
  • フィードバックを得る

#チェックリスト

離陸前に、ユースケースの範囲とアジェンダについて、私たちが共有するいくつかの基本的なチェックを以下に示します。

• データソース
  • どのデータが必要ですか？
  • データは利用可能ですか？どのように？データの履歴は利用可能ですか？
  • ストレージのサイズ: このプロジェクトにはどれくらいのデータ量とコンピューティングが必要ですか？
  • どのくらいの頻度で更新する必要がありますか？
• あなた自身のデータブックを説明する:
  • 「データストーリー」: それはどこから来ていますか？どのように生成されましたか？データフローの履歴は？
  • データフィールド: それは何を意味しますか？それは何のためですか？
  • 詳細なビジネスルール（データについて）
  • KPI: それらはどのように計算されますか？それらは何を意味しますか？
• 何を生成する必要がありますか？
  • UXストーリーボード
  • 外部使用のためのAPI
  • ファイルのエクスポート
• リスクの検出と軽減
  • 何がうまくいかない可能性がありますか？プロジェクトで複雑なことは何ですか？
  • ボトルネックや障害の可能性を特定/予測する
• 短い反復を特定し、活用する
  • データをできるだけ早く確認する
  • 早期リリース、頻繁にリリースする！

#ユーザー管理

プロジェクトでは、チームでプロジェクトに取り組むことが簡単です。チーム管理には2つのレベルがあります。

• メンバーは、Data Platform組織のチームメンバーです。彼らはData Platformアカウントを作成しました
• ユーザーは、このプロジェクトで作業するチームメンバー、またはAPIとアプリのエンドユーザーです
  • 組織のメンバーは、その組織内のすべてのプロジェクトで自動的にユーザーとして追加されます。管理者以外のユーザーには、手動で権限を付与する必要があります。

チームを組織に追加した後、各プロジェクトのIdentity Access Managerで、スキルと権限に応じてアクセス権を付与する方法を確認してください。

エンドユーザーのアクセス権も、Identity Access Managerで管理されます。

#リソースの管理

プロジェクトは、データプロジェクトの要件が進化するにつれて簡単にスケールアップできるように設計されています。必要に応じて、プロジェクト内の任意のコンポーネントを水平および垂直にスケールアップできます。例えば、アプリなどです。

プロジェクト内の各コンポーネントは、ジョブまたはデプロイメントを通じてアクティブに実行されているときにリソースを消費します。

↪ リソース消費についてさらに詳しく

#データの収集

利用可能なコネクタを確認し、インターフェースを通じてまだ可能でないことを実行するには、常にカスタムアクションを記述できることを忘れないでください。

プロジェクト内でファイルを管理する必要がある場合は、Lakehouse Managerバケットを使用することをお勧めします。

• バケットをトピック (参照情報など)、処理の種類 または プロバイダー によって整理する
• バケット内では、フォルダー を使用してファイルをより良く整理できます
• ソースを定義する際に、Data Platform Buckets コネクタを使用すると、バケットを選択し、ソースとしてファイルを選択できます
• 同じバケット/フォルダー内に複数のファイルがある場合:
  • 各ファイルが異なる場合は、それらを個別に分析し、Data Processing Engineアクションのソースとして使用できます
  • すべてのファイルを同じ方法で処理する必要がある場合: 1つを分析するために選択するだけでよいです。それをソースとして使用し、ファイルセットに対するセグメンテーションを使用してそれらを処理します
• S3¹-互換ツールを使用してファイルをバケットに送信する方法を確認し、自社のプロセスに統合します

#データの分析とブループリントルールの設計

ソースを設定したら、時間をかけてそれらを分析し、基本的なソースクリーニングルールであるブループリントルールを設定します。これにより、次のような一般的な問題を解決するのに役立ちます。

• 日付形式
• 数値形式
• 文字列のクリーンアップ
• 不完全な行のスキップ
• ... そしてさらに多く

長期的には、このステップは多くの時間を節約できます！

#データを整理する

Tables ページ は、データベース スキーマを準備する場所です。

#テーブル

• データの種類に応じてプレフィックスを使用することをおすすめします：
  • ref_：参照データや安定したデータ、時間情報のないデータ
  • raw_：最小限の変更でそのままインポートされたデータ。データの問題を追跡するために使用できます
  • prm_：raw_からの改善された品質のデータ、つまり主テーブル
  • fct_：複数のprim_とref_からのfactsを共通のscaleに統合
  • agr_：異なるscale（例えばdatetimeからdateまたはdateからyear）でデータを集約
    • 通常、クエリを最適化するために設計されています
    • スケール粒度ごとに1つのagr_テーブルを構築し、必要なすべての属性を追加
    • 粒度を示す属性名（agr_station_yearmonth、agr_movie_date）を追加
  • tmp_：処理に使用される一時的なテーブル（クエリ不可とマーク）
  • mlm_：機械学習モデルで使用されるテーブル
• 1行のデータが何を表すかを明確に説明する名前を付ける
• データ操作を高速化するためにインデックスを定義する

#属性

Attributes タブ を使用して、すべての属性を確認し、それらがどのテーブルで使用されているか、どのDPEアクションがそれを使用しているかなどを確認します。

以下は、属性（表のフィールド名）に関するベストプラクティスです：

• 使用する属性は、データの意味を明確に表すものにしてください。

• 属性名には、大文字と小文字を区別しないようにしてください。

• 属性名には、スペースや特殊文字を使用しないでください。

• 属性名には、予約語を使用しないでください。

• 属性名には、一貫性のある命名規則を使用してください。

• 属性名には、可能な限り短く、記憶しやすいものにしてください。

• 属性名には、可能な限り説明的なものにしてください。

• 属性名には、可能な限り一意のものにしてください。

• 属性の種類: 次元 または 測定値 のいずれかを選択します

  • 次元: スケーリング、フィルタリングなどが可能ですが、合計はできません。
  • 測定値: ほとんどの場合、合計、カウント、平均などが可能です。

• 属性の命名:

  • 接頭辞 を使用して区別します (例: client_, fb_, site_)
  • measure 属性は、時間的なウィンドウを示唆するように命名します:
    • _nb_ : その日の数値
    • _total_ : 今日の値
    • _diff_ : 前日との差
    • ...
  • 明確に何であるかを示します (例: _amount_, _ticket_, _fans_)
  • 明らかでない場合は単位を示します (例: _g, _kg, _wh, _kwh, _eur, _usd)

#エクスプローラー

Explorer を使用して、テーブルの内容を素早く確認します。

#データを処理する

The Data Processing Engine (DPE) は、物理的なデータフローの核心となる actions を構築するために使用されます。これらは単独で実行されるか、workflows と呼ばれるグループに組織化することができます。

#アクション

提供されたアクションの種類をよくご確認ください。

さらに進める必要がある場合は、カスタムアクションを作成し、Python または PySpark を使用して、SDKを活用してプロジェクトの残りの部分と相互作用するようにしてください。

• Aggregate Actionsについて：
  • scale：目的のテーブルの主キーと同じ粒度でなければなりません
  • テーブルの結合ルールを二重確認してください：これはエラーの主な原因です
• ライフサイクル中にログレベルを適切に設定してください（必要に応じてdebugを使用し、そうでない場合はinfoを使用してください）
• Auto flush allを使用して、すべてのキャッシュをフラッシュし、アクションによってデータセットにもたらされた更新を可視化してください

#リポジトリとバージョンを使用する

プロジェクトが成長するにつれて、必要に応じてバージョンを使用してリポジトリ内のアクションを整理できることを忘れないでください。

#セグメンテーションを使用する

Data PlatformのDPEの全力を活用するには、Segmentationを使用して、アクションレベルで計算タスクを並列化します。

#ペリメーターを使用する

アクションやワークフローをデータのサブセットに限定するには、例えば過去30日間のデータに限定する場合は、Perimeter オプションを使用します。

#クエリを記述する

Use folders and repositories to organize saved queries in the Analytics Manager.

例えば：

• データ品質: データ品質を確認するためのクエリ
• データ分析: 基本的な特徴を確認するためのクエリ
• App-xxx: アプリケーション内で使用するためのクエリを準備
  • これにより、データベーススキーマとクエリを更新するために新しいアプリバージョンをデプロイする必要がありません
  • クエリには明確で説明的な名前を付けてください

#クエリエンジン

• 複数のデータベースにわたる統一されたSQLエンジン
• Lakehouse ManagerのExplorer
• ダッシュボードの構築と公開
• PowerBIなどのツールからのアクセス

#アプリケーションを構築する

Take the time to understand Application Services and the possible settings.

#便利なヒント

• プロジェクトを開始する前にストーリーボードを設計します
• 必要なすべてのテーブルにdynamic parametersが存在することを確認します
• テーブル内のオブジェクトのラベルを使用して自動翻訳を実行します
• フォーマッターと翻訳を活用します
• スタイルテンプレートを活用してアプリ開発を効率化します

典型的なアプリケーション開発ライフサイクルは以下の通りです：

1. データソースの接続
2. データの取り込み
3. データの変換
4. データの分析
5. 結果の表示

このライフサイクルは、データを使用して価値を生み出すための一般的なプロセスです。

1. ストーリーボードを設計します

• データが利用可能か確認します
• dynamic parametersを特定します
• 必要なチャートとカスタムコンポーネントを特定します

2. Analytics Manager: 必要なクエリを準備し、確認します
3. UIで最初のバージョンを実装します

• dynamic parametersを設定します
• dashboardsとmenusを設定します
• 必要に応じて利用可能なchartsを設定します
• dictionaries、formatters、translationsを設定します

4. そのバージョンを改善します

• 必要に応じてCSSを調整します
• スタイルテンプレートを活用します
• 必要に応じて独自のカスタムチャートまたはカスタムコンポーネントを実装します

5. テストし、再度反復します
6. より多くのユーザーにアクセス権を付与します

#アプリケーションをさらにカスタマイズする

アプリケーションはReactJSフレームワークに基づいています。私たちのアドバンスドアプリカスタマイゼーションガイドをご覧になることを強くお勧めします。

#Gitリポジトリ

通常は、アプリケーションをGitリポジトリと同期させることをおすすめします。そして、2つのアプリケーションをデプロイします。

• my-develop: あなたの develop ブランチと同期されています
• my-master: あなたの master ブランチと同期されています

#カスタムドメイン名

デフォルトでは、アプリケーションは以下のURLで利用可能です：

https://my-project.eu.dataplatform.ovh.net/my-develop-app/

簡単に変更することができます。アプリの設定で以下のように設定します：

https://my-beautiful-app.eu.dataplatform.ovh.net/

さらにカスタマイズが必要な場合は、独自のドメインを登録し、独自のSSL証明書を提供することができます：

https://my-beautiful-app.example.com/

#アプリケーションへのアクセス権を付与する

Application Services で作成した Application は、デフォルトで Identity Access Manager に対応するものがあります。

• Application Services
  • インスタンスをデプロイして実行する管理を行います
  • Identity Application Manager の Application にリンクされています
  • Auth Providers、Users などの IAM App 構成を使用します
• Identity Access Manager では、以下を定義できます
  • ロゴ
  • アプリケーションタイトル
  • 許可された認証プロバイダー

認証プロバイダー（会社に SSO プロバイダーがある場合）を使用して、アプリケーションにアクセスするすべての エンドユーザー を追加し、ロール と グループ を使用してデータアクセス制御を管理します。

#Front API

デフォルトの Front API は、認証を確認し、動的パラメータ を追加して ACLs を実装 することで、アプリケーションのリクエストを処理します。

以下は、カスタム API が必要なシナリオの例です。

• トランスフォーマーを実装する
• カスタム「進化」を実装する
• 複雑な ACL を実装する

#モニタリング

Control Center では、以下にアクセスできます。

• モニタリング：リソース使用量とヘルス状態
• すべてのデプロイメントとジョブのログ
• デプロイメントとジョブに対するアラートの作成
• プロジェクトおよび組織レベルのすべての ジョブ実行とスケジューリング の完全なビュー

#プロジェクトのバックアップ

#プロジェクト構成

プロジェクト構成のバックアップと復元方法 について詳しく学びます。

#データのエクスポート

Data Processing Engine カスタムアクション を使用して、Lakehouse Manager の バケット にすべてのデータをエクスポートできます。

#さらに詳しく

トレーニングや技術的なサポートを受けるには、営業担当者にお問い合わせください、または Professional Services ページを訪れて、見積もりをリクエストし、専門家がプロジェクトを分析するようにしてください。

Data Platform を構築するチームと直接やり取りし、質問をしたり、フィードバックを送信したり、専用の Discord チャネル で参加できます。

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

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

¹: S3 は Amazon Technologies, Inc. の商標です。OVHcloud のサービスは、Amazon Technologies, Inc. によってスポンサーされ、推奨され、またはその他の方法で提携していません。