Help Center
Training
Knowledge Base
Community
Developers
Support

DataSet管理のためのベストプラクティス

Domo University
  • 更新
フォローする

一般的なベストプラクティス

  • DataSetを作成またはインポートしたら、必ずそのDataSetの内容がわかるような具体的な名前と説明をつけるようにします。

  • 重複を避けるためにも、DataSetのタイトル名に使用しているコネクターの名前を含めないようにします。

  • DataSetの名前には日付範囲を追加しないようにします（例えば、「Google Analytics 2016」など）。ほとんどのDataSetは自動的にスケジュールされるため、名前に日付を入れても、すぐに古くなってしまう可能性があります。また、これにより、そのDataSetやその他名前に日付が入っているすべてのDataSetの名前を後から変更する必要がなくなります。

  • DataSetの説明には、どんなデータを取り込んでいるのかがわかるように、支出やインプレッションなど基本的な説明を記述するようにします。更新頻度などを説明に入れることもできます。ただし、一般ユーザーにとってその情報が重要であるかどうかということも関係します。

  • DataSetの所有者は常に指定するようにします。そしてそのユーザーがそのデータに責任を持つようにします。DataSetの作成者が、アップデート責任者となるデータ所有者に対して、データに関する責任を移譲しておかないと、データに不具合が発生した場合、その不具合を修復するべき所有者ではなく、DataSetの作成者にアラートが送信されてしまいます。

  • 将来DataSetやDataFlowに関連する情報を追跡しやすくするために、データ入力と出力セットをDataFlowに追加しておきましょう。また、DataFlowの頻度と、DataFlow実行が自動化されているか、それともスケジュールされているかの情報も追加します。

    • DataFlow DataSetの説明の例

      • 入力DataSet

      • 出力DataSet

      • 実行頻度

  • 計算フィールドを含んでいるDataFlowを作成する場合は、「CALC」などの接頭語や接尾語をつけることで、後からこれを使用するユーザーがDataFlowの中に計算フィールドが含まれていることがわかるようになります。後にDataFlowのトラブルシューティングをする際、計算が存在していることを知っていると判断が簡単になります。

  • DataSetは、次のテンプレートを使用して名前を付ける必要があります。TYPE_ClientInfo_Source_ReportName（例：RAW_Kablinko_Sizmek_Performance_Analytics）

  • 推奨される名前用の接頭語とその意味

    • RAW_：ソースから直接取り込まれる生データファイル。このデータはMagic ETLまたはMySQLを使用して変換されます。

    • INT_：DataFlowの中間DataSet。 通常、データを別のソースとマージする準備をするDataFlowの出力を指します。説明に「PROD DataSet」と記入する

    • DEV_：データが監査中。監査の際には、「PROD」に変更します。

    • PROD_：実稼働環境。最終DataSetに使用されます。これらは、カードを作成できるDataSetです。

    • TEMP_：テスト、開発、アドホックDataSetに使用。これらは定期的に監査を行い、必要性を判断する必要があります。

  • 推奨されるネーミングの接尾語

    • CALC：ETLプロセスで追加された計算フィールド。

  • すべてのDataSetは、列名が正しく解釈されるように、何らかの命名規則に従って列名を付けなければなりません。これはすべてのDataSet（コネクタ、インポート、DataFlow出力など）にも当てはまります。
  • 列の命名規則
    • 列名は、単一引用符、二重引用符、バックティック（いわゆる バッククォート「`」 ）で始まりません。
    • 列名にはサロゲート文字（単一文字を表すために2つのコードポイントを使用する特殊文字）を含めることはできません。
    • 列名は、大文字と小文字を区別せずに一意でなければなりません。言い換えると、大文字と小文字の違いのみで区別する列は許可されません。
    • その他の列名は有効です。

  • Beast Modeの作成の際、「計算を共有」のオプションを選択する前に、このオプションをいつ選択するのが効果的なのかを判断します。計算が多くのユーザーが利用する共有フィールドである場合は、計算を共有することにメリットがあります。1回限りの機能の場合は、共有しない方がよいでしょう。どのようなコンテキストでその計算を使用するべきかわからない他のユーザーで問題が生じる可能性があるからです。

データガバナンス

  • 社内で広範囲なガバナンスモデルを作成する場合は、DataSetのBeast Mode計算にコメントを追加することもできます。このコメントは、Beast Mode計算自体に入れるメタデータです。これを使用することでBeast Mode計算の作成者を特定したり、Beast Modeの日付やその機能の説明を作成したりできます。ユーザーはこの便利な情報にアクセスすることで、それぞれのカードでこれを利用すべきか判断できるようになり、質問があるときに誰に問い合わせればよいのかなどがわかるようになります。

    • Beast Modeで作成者と作成日、簡単な説明を加えたメタデータの例

/* Author:

Created Date:

Description:

  */
 

  • 新しいDataSetで接続テストを行う場合は、自動フィードを設定するのではなく手動でアップデートするように設定します。テスト中のものや問題のあるDataSetは、定期的にアップロードする必要がないためです。

  • 重複したDataSet、カードのないDataSet、接続するDataFlowがゼロのDataSetなどがないようにするため、定期的にMajorDomoまたは重要な関係者などにDataSetを監査してもらうようにします。

  • MajorDomoは、データセンターのカードをカードの数でソートして監査することができます。DataSetの接続がゼロであるカードを発見した場合は、それを削除するか、DataSetの所有者に連絡してDomo内にこのカードがある理由を確認し、必要に応じてDataSetを削除してもらうようにします。

  • 未使用のDataFlowを監査する場合は、その見極めが多少難しいこともあります。1～2ヶ月実行されていないようであれば、それにはスケジュールが組み込まれていないことを示唆しているため削除してもよいかもしれません。あるいは、所有者と共にどうなっているのかを調査します。

  • データガバナンスを設定する場合は、各ツールに個別に割り当てを行います。例えば、Workbenchの監査に1人、全ソーシャルデータに1人、Magic ETLデータに1人、というように割り当てます。各データタイプに所有者がいると、確実にそれらを常に監査することができます。そうしておくことで、DataSetの要件を満たしやすくなり、Center of Excellenceに持ち込まれる問題件数を減らすことができます。

  • ユーザーがそれぞれ以下の手順を実行できるようなプロセスを用意しておきます。

    • データをアップロードする

    • Workbenchまたは別のツールを使用して、データが正しいことを検証する

    • Domoで再度データを検証し、数字が予想どおりになっているかを確認する

    • 手順の各ステップを確認し、データが正しいこと、そしてカードを作成できることを確認する

    • データの検証が終了したら、AnalyzerがDataSetを理解できるかを確認します。

    • カードの作成が完了したら、データ所有者にカードを検証してもらいます。カードを作成した人が、フィルタリングなどに関して見逃したディメンションがあるかもしれないからです。

プロセス全体を通じて検証ステップを設置することにより、数字が期待通りに表示されること、そして複雑なデータ構造で欠けている部分がないこと、意味の通らない計算がないことなどを確認できるようになります。

  • データの監査担当者には、常にエラーのチェックを行い、実行に失敗がないかなどをチェックしてもらうようにします。この担当者たちが認証情報の所有者でない場合は、しかるべき認証情報とアカウントへのアクセス権を持っていることを確認するようにします。

  • 毎月1回データセンターを監査し、重要なDataFlowとDataSetが実行されているのを確認するようにします。また、すべての認証が動作していることを確認し、期限が切れたものは再認証するようにします。

その他のベストプラクティスに関するトピック

その他のDomoのベストプラクティスについては、次のトピックを参照してください。

関連記事

コメント

0件のコメント

サインインしてコメントを残してください。