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

#目的

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

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

当プラットフォームの最初のユーザーとして、これまで数年間にわたりデータプロジェクトを実施してきました。これらの年月を通じて、サービス実績から学んだベストプラクティスをまとめました。それを皆様と共有できることを嬉しく思います。

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¹互換ツールを使用してファイルをバケットに送信する方法を確認し、社内プロセスに統合します

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

ソースを設定したら、分析し、ブループリントルールと呼ばれる基本的なソースクリーニングルールを構成する時間を取ってください。これにより、次のような一般的な問題を解決するのに役立ちます。

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

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

#データを整理する

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

#テーブル

• データの種類に応じてプレフィックスを使用することをおすすめします：
  • 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アクションがそれを使用しているかなどを確認します。

以下に、属性（表のフィールド名）に関するベストプラクティスをいくつかご紹介します：

• 属性の種類: dimension または measure のいずれかを選択してください
  • dimension: スケーリングやフィルタリングが可能ですが、合計はできない定性的な情報です。
  • measure: ほとんどの場合、合計、カウント、平均などが可能な数値情報です。
• 属性の命名:
  • 区別するために接頭辞を使用してください（例: 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 オプションを使用します。

#クエリを作成する

Analytics Manager では、フォルダーとリポジトリを使用して保存したクエリを整理します。

例えば：

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

#クエリエンジン

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

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

Application Services と利用可能な設定について、時間をかけて理解してください。

#有用なヒント

• プロジェクトを開始する前にストーリーボードを設計してください
• 必要なすべてのテーブルに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のアプリケーション にリンクされています
  • Auth Providers、Users などの IAM App 構成を使用します
• Identity Access Manager, では以下を定義できます:
  • ロゴ
  • アプリケーションタイトル
  • 許可された認証プロバイダー

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

#フロントAPI

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

カスタムAPIが必要なシナリオをいくつか紹介します。

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

#モニタリング

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

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

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

#プロジェクト構成

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

#データのエクスポート

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

#さらに詳しく

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

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

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

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

¹: S3 は Amazon Technologies, Inc. の商標です。OVHcloud のサービスは、Amazon Technologies, Inc. によって後援、承認されたものではなく、また同社と提携関係にあるものでもありません。