新しいデータソース

このページでは、データウェアハウスに新しいデータソースを追加するプロセスを詳しく説明します。データチームはデータウェアハウスに新しいデータソースを追加するあらゆるイニシアチブを歓迎します。データは価値につながる可能性があると考えていますが、データウェアハウスに新しいデータを追加することはコストなしには行えません。

開発（データチームからのリソースの割り当て、サポートに関係する他のチームから、そして要求者であるあなた自身）と、データパイプラインを稼働させ続けること（ストレージ、コンピューティングリソース、インシデント管理、モニタリングなど）は時間やお金がかかります。

新しいデータソースの追加を要求する前に、以下の点を考慮してください。

• 有効なビジネスケースがありますか？
  • 規制要件への準拠のためのビジネスケースの場合があります。
  • 投資コストに対して価値の可能性が明確に見えるため、ビジネスケースが明確な場合もあります。
  • 価値が不確かな場合やコストが不確かな場合があるため、定量化が難しい場合がほとんどです。データチームとオープンで率直な議論をすることを遠慮しないでください。私たちは経験があり、正当化を助けることができます。これは必ずしも科学的な計算である必要はありません。
• データウェアハウスにデータが届いたところで作業は終わりではありません。データは raw データレイヤーに「単に」届くだけで、これはデフォルトでは Sisense からアクセスできません。データは dbt を通じてエンタープライズディメンショナルモデル（EDM）に下流に読み込まれる必要があります。フォローアップが必要で、このページで説明されているプロセスの上に追加されます。
  • 下流のモデリングは、私たちのデータプラットフォームへのコントリビューションを歓迎しているため、ビジネスチームが担当することができます。ただし、広範な（dbt-、SQL、データモデリングの知識が必要です）
  • 下流のモデリングはデータチームが担当することもできます。理想的にはデータフュージョンチームによって担当されます。計画を立てて、優先度は会社の優先度に沿って設定されます。これはデータウェアハウスへの新しいデータソースの追加スコープには含まれません。したがって、その後に手配する必要があります。
  • データが複雑な JSON 形式で抽出された場合、データエンジニアがサポートしたり、データを表形式にフラット化して PREP データベースに読み込むことができます。
  • 下流のデータ開発のフォローアップには 3 つの方法があります。
• データウェアハウスへの新しいデータソースの追加は 1 回限りの作業ではありません。データがデータウェアハウスに抽出されるとすぐに、定期的なケイデンス（週 1 回、1 日 1 回、1 日に複数回など）でデータが更新されます。つまり、実装後に何かが起きたり、問題が発生したりする可能性があります。必要な場合にこのプロセスをサポートするために、ソース側（ビジネスおよびテクニカル）の DRI が必要です。
• データは EDM 外でも、例えば機能アナリストによって raw データレイヤーで使用される可能性があります。raw データへのアクセスを取得するには AR を提出してください。
• データが EDM に入ったら、ダッシュボードを作成することで Sisense での作業が必要です。これを行うためにも、いくつかの技術的な知識が必要です。
• データプラットフォームはソースシステムへのアクセスを得る必要があります。これは明らかに聞こえますが、常に簡単ではありません。

新しいデータソース

新しいデータソースを追加するためのワークフローは以下のとおりです（注: これは私たちがすべての作業に使用する既存のワークフローであり、新しいデータソースの追加というコンテキストで明示的に示されています）。

新しいデータソースを追加するプロセス:

workflow::1 - triage

すべての新しいデータソースのリクエストは Issue から始まります。これは既に抽出されているが拡張が必要なデータソースと、まったく新しいデータソースの両方に適用されます。New Data Source テンプレートを使用してください。新しい Issue をManager, Data Platformに割り当ててください。そうすることで、データチームがタイムリーに Issue をトリアージできるようになります。すべての初期情報が要求者から提供され、データチームによって評価されます。データが既にデータウェアハウスに存在しないかどうかの相互確認が行われます。

workflow::2 - validation

完全な作業分解を作成することを目標に、新しいデータソースに関するすべての詳細が整理されます。

データスコープ

要件に基づいて、抽出が必要なデータポイント（つまりどのテーブル）が決定されます。総合的なデータスコープが提供される必要があります。

データ最小化

データプラットフォームでは、データを抽出する際にデータ最小化の原則を採用しています。これはスコープ/ニーズを満たすために必要なデータのみを抽出することを意味します。これを行う理由は以下のとおりです。

• データが少ないほどリソース使用量が少なく、ソースシステム、パイプライン、データプラットフォームへの負荷が軽減されます。
• データが少ないほどメンテナンスが少なく、データソースが変更されてその特定のデータ（セット）を抽出しない場合、おそらく何もする必要がありません。

これはすべて GitLab の効率性という価値の精神です。

データ最小化は以下のレベルで適用されます。

• データソース: 必要なデータソースのみを抽出します。
• テーブル: 抽出内で必要なテーブルのみを抽出します。
• 列: 必要なテーブル内の列のみを抽出します。

データ最小化は以下のレベルでは適用されません。

• 行: データコンシューマーが実際にどのデータを見ているかについての混乱を避けるために、デフォルトでは行にフィルタリングを適用しません（正当な理由（技術的または機能的）がある場合を除く）。

データ最小化のユースケース

データを読み込む際に JSON ファイルに 1 つ以上の列を指定してデータ最小化を行いたい場合、object_insertのプロシージャを使用できます。使用例:

WITH base AS (
    SELECT try_parse_json('{"id":1,
                            "name": "ABC"}'
                                       ) AS json_data)
SELECT object_insert(json_data,'email','[email protected]')
  FROM base;

-- {
--   "email": "[email protected]",
--   "id": 1,
--   "name": "ABC"
-- }

データを読み込む際に JSON ファイルから 1 つ以上の列を削除したい場合、object_deleteのプロシージャを使用できます。使用例:

WITH base AS (
    SELECT try_parse_json('{"id":1,
                            "name": "ABC",
                            "address":{"add1":"1234",
                                       "add2":"XYZ",
                                       "city":"TN",
                                       "apt": 1 }}'
                                       ) AS json_data)
SELECT object_delete(json_data,'id','address')
  FROM base;

-- {"name": "ABC"}

このような状況では、さまざまな理由（RED データ、PII データ、データの価値なし、その他の最小化原則）で処理されるべきでない列を除外することができます。

アクセスリクエスト

データチームにソースシステムへのアクセスを提供することは有用な場合がありますが、今すぐアクセスリクエストを提出することは必須ではありません。

作業分解

バリデーションの最終目標は、DRI とサイズ見積もりが付いたソリューション設計と完全な作業分解を持つことです。実行する必要があるすべての作業が記述されます。各作業アクションが M / 5/8 のイシューポイント以下の Issue に変換できるレベルを目標とします。

MNPI データ

データソース内に MNPI データがあるかどうか、およびこのデータをデータウェアハウスに抽出する予定かどうかを判断する必要があります。データソースに MNPI が含まれてそのデータが抽出される場合は、Issue のラベルを new data source MNPI に変更します。

workflow::3 - scheduling

ビジネスケース、実装の労力、データチームの作業負荷、データチームの優先度に基づいて、実装がスケジュールされます。スケジューリングのために私たちは GitLab データチームのプランニング Drumbeatに従います。つまり、四半期ごとにデータチームは新しいデータソースのリクエストがいつ取り上げられるかを決定します。新しいデータソースのリクエストが scheduling に残っている場合、それがデータチームのレーダーにないことを意味するわけではありません。まだスケジュールされていないことを意味します。その理由は以下のとおりです。

1. 来四半期の OKR の定義がまだ行われていない。四半期に 1 回、データチームは次の四半期の OKR を設定します。
2. ビジネスケース、実装の労力、データチームの作業負荷、データチームの優先度のため、来四半期の OKR には収まらなかった。

workflow::4 - scheduled

新しいデータソースの実装リクエストが来四半期の OKR のスコープに入った場合、リクエストは scheduled になります。Issue が付属したエピックが作成されます。作業分解に基づいて、対応するイシューの重み、ラベル workflow::4 - scheduled、正しいマイルストーン（わかっている場合）が割り当てられてエピックに付属する形で、すべての Issue が作成されます。

workflow::5 - development

作業の実行が始まると、Issue は開発段階に入り、通常の開発ライフサイクルに従います。

開発中、データエンジニアはデータへのアクセスについてすべてのステークホルダーと調整します。データとユースケースによっては、raw スキーマへのデータアクセスが提供される場合があります。

ラベルの作成

まだ抽出されていないアップストリームシステムからデータを抽出する完全に新しいデータパイプラインの場合、GitLab Dataグループに新しいラベルを作成します。例: https://gitlab.com/groups/gitlab-data/-/labels/23453371/edit

workflow::6 - review

作業の実行が完了すると、Issue はレビュー段階に入り、通常の開発ライフサイクルに従います。

workflow::X - blocked

外部からの介入が必要なために実行を続けることができない場合、Issue は blocked になります。明確な問題の記述が必要で、できるだけ早く適切な人員を割り当てる必要があります。

Red データ

GitLab のデータ分類ポリシーによる Red データは、私たちのデータプラットフォーム（Snowflake）に保存することは許可されていません。したがって、ミッションクリティカルなビジネス上の理由がない限り、data_classification: Red のテックスタックにリストされている新しいデータソースを取り込む/接続することはしません。例外プロセスがあり、これによりケースバイケースでニーズを評価することができ、このプロセスには BT/データ VP レベル、セキュリティ、プライバシーからの承認が必要です。ビジネス上の理由の評価と承認の取得は、トリアージプロセスの一部であり、新しいデータソースのテンプレートを通じて管理されます。

注: 例外プロセスは、Red データを持つシステムを接続すること、および/またはそのシステムから Red データ（フィールド）を抽出することの両方に対して満たす必要があります。ただし、Red データ（フィールド）の抽出に関する例外プロセスのビジネスケースは、Red データの抽出なしに Red データシステムを接続するのみを必要とするビジネスケースよりも高い審査基準を必要とします。例外プロセスの下で Red データ（フィールド）の抽出が承認された場合、次のセクションで説明するようにデータプラットフォーム（Snowflake）でマスキングが適用されます。

例外プロセス - リストにないソースまたは Red データソースへの接続

Snowflake に新しいデータを抽出する際に、データソースがリストにないか data_classification: Red とリストされている場合:

• チームメンバーはシステムをデータプラットフォームに接続するためのビジネスケースを述べる必要があります。
• 接続を要求するチームメンバーはデータの分析を実行して、抽出されるデータが Red データではないことを確認します。
  • Snowflake に Red データ（フィールド）を取り込む必要がある場合、抽出時にマスキングが適用されます。
• BT/データ VP レベル、リーガル、セキュリティが実装開始にサインオフする必要があります。

個人データ

データプラットフォーム（Snowflake）への個人データの抽出は許可されていますが、リーガルプライバシーチーム、および該当する場合はピープルチームからの追加レビューが必要です。新しいデータソースの追加を要求する際、上流システム/データソースを要求するチームメンバーは、データソースに個人データが含まれているかどうかと、どのデータ要素が関係しているかを示す責任があります。特定の情報が個人データかどうかを判断するのに十分な知識がないチームメンバーは、サブジェクトマターエキスパート、および必要に応じてデータエンジニアにタグを付ける必要があります。

「仮名化された」データはプライバシー法の下でも個人データであることに注意してください。

上流システム（データソース）に個人データが含まれている場合、データチームは以下のいずれかを行います。

• 抽出物が個人データを保持せずに要求者の目的を果たせる場合、指定された個人データ要素を抽出から除外します。または
• 個人データのデータプラットフォームへの抽出と処理を実行するためにリーガルプライバシーのレビューと承認を取得します。

機密性の高い個人データ

特定の個人データ要素は、さまざまなプライバシー法の下で「機密性が高い」とみなされます。機密性の高い個人データには一般的に、人種的または民族的出自、政治的意見、宗教的または哲学的信条、労働組合への加入、遺伝データ、生体データ、健康に関するデータ、性生活または性的指向に関するデータ、犯罪歴、市民権/移民ステータスが含まれます。

プライバシー法はこれらのタイプのデータ要素の処理を、限られた状況を除いて禁止しています。機密性の高い個人データを含むデータの抽出要求がなされた場合、処理に対して真の同意が得られており、リーガルプライバシーおよび該当する場合はピープルチームがこの処理を承認している場合を除いて、一般的に拒否されます。

Monte Carlo の可観測性

新しいデータソースが raw レイヤーに抽出されると、多くの場合そのデータソースのために新しい別のスキーマが作成されます。新しいデータソースが Monte Carlo によって観測されることを確認するために、Monte Carlo 権限ハンドブックセクションに概説された手順に従ってください。

ドキュメンテーション

新しいデータソースはハンドブックに文書化され、このテンプレートに従います。

ページのソースコードを見る - ページの編集 - please contribute.