メインコンテンツへスキップ

​
はじめに

DataSet履歴を管理する： DataSet履歴の管理APIは、利用可能なデータバージョンに関する情報を提供します。使用方法については、 デベロッパーポータル を参照してください。

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

  • DataSetを作成またはインポートしたら、必ずそのDataSetの内容が分かるような具体的な名前と説明をつけるようにします。
  • 重複を避けるためにも、DataSetのタイトル名に使用しているコネクターの名前を含めないようにします。
  • DataSetの名前には日付範囲を追加しないようにします（例えば、「Google Analytics 2021」など）。ほとんどの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は、Data Centerのカードをカードの数でソートして監査することができます。DataSetの接続がゼロであるカードを発見した場合は、それを削除するか、DataSetの所有者に連絡してDomo内にこのカードがある理由を確認し、必要に応じてDataSetを削除してもらうようにします。
  • 未使用のDataFlowを監査する場合は、その見極めが多少難しいこともあります。1～2ヶ月実行されていないようであれば、それにはスケジュールが組み込まれていないことを示唆しているため削除してもよいかもしれません。あるいは、所有者とともにどうなっているのかを調査します。
  • データガバナンスを設定する場合は、各ツールに個別に割り当てを行います。例えば、Workbenchの監査に1人、全ソーシャルデータに1人、Magic ETLデータに1人、というように割り当てます。各データタイプに所有者がいると、確実にそれらを常に監査することができます。そうしておくことで、DataSetの要件を満たしやすくなり、Center of Excellenceに持ち込まれる問題件数を減らすことができます。
  • ユーザーがそれぞれ以下の手順を実行できるようなプロセスを用意しておきます。
    • データをアップロードする
    • Workbenchまたは別のツールを使用して、データが正しいことを検証する
    • Domoで再度データを検証し、数字が予想通りになっているかを確認する
    • 手順の各ステップを確認し、データが正しいこと、そしてカードを作成できることを確認する
    • データの検証が終了したら、AnalyzerがDataSetを理解できるかを確認します。
    • カードの作成が完了したら、データ所有者にカードを検証してもらいます。カードを作成した人が、フィルタリングなどに関して見逃したディメンションがあるかもしれないからです。
プロセス全体を通じて検証ステップを設置することにより、数字が期待通りに表示されること、そして複雑なデータ構造で欠けている部分がないこと、意味の通らない計算がないことなどを確認できるようになります。
  • データの監査担当者には、常にエラーのチェックを行い、実行に失敗がないかなどをチェックしてもらうようにします。この担当者たちが認証情報の所有者でない場合は、しかるべき認証情報とアカウントへのアクセス権を持っていることを確認するようにします。
  • 四半期に1回Data Centerを監査し、重要なDataFlowとDataSetが実行されているのを確認するようにします。また、すべての認証情報が機能していることを確認し、期限が切れたものは再認証するようにします。

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

その他のDomoのベストプラクティスについては、次のトピックを参照してください。 このページのトップへ 日本語