ビッグデータ開発と運用（ビッグデータ開発プロセスと仕様）

ビッグデータの開発プロセスと仕様

ビッグデータの時代において、標準化されたデータ資産管理は、インターネット、ビッグデータ、人工知能、実体経済の深い統合を促進するための必須条件となっています。ビジネス特性に近く、各研究開発段階の要点を考慮した研究開発基準は、研究開発の効率を効果的に向上させ、データ研究開発作業が秩序正しく実行されるようにすることができます。不完全な研究開発プロセスは研究開発の効率を低下させ、コストとリスクを増加させます。

データR&D仕様は、データ開発者と管理者に標準化されたR&Dプロセスガイダンス方法を提供するように設計されており、日常の作業プロセスを簡素化および標準化し、作業効率を向上させ、非効率的で冗長な作業を削減し、企業と政府がビジネスデータの大幅な増加に対処するためにより強力なデータ制御を実現し、それによってより多くの人的および財務的リソースを解放してビジネスイノベーションに集中できるようにすることを目的としています。

日常的なデータ ウェアハウス開発作業の概要と導入を考慮して、データ ウェアハウス開発プロセスは次のポイントに抽象化されます。

1. 需要段階: データ製品マネージャーは変化するビジネスニーズにどのように対応すべきか。

2. 設計段階: データ製品マネージャーとデータ開発者は、データをより適切に整理して保存するために、パフォーマンス、コスト、効率、品質などの要素をどのように総合的に考慮する必要がありますか?

3. 開発段階: データ開発者がコーディング作業を効率的かつ標準化された方法で実行する方法。

4. テストフェーズ: 出力品質を向上させるために、テスターはどのようにしてコードの問題とプロジェクトのリスクを正確に明らかにすべきか。

5. リリースフェーズ：リリース条件を満たしたプログラムを、いかにスムーズに安定したオンライン出力にリリースするか。

6. 運用・保守段階: 運用・保守担当者は、データ出力の適時性と安定性をどのように確保すべきでしょうか?

1. 要件: 運用製品の要件について話し合います。ビジネス側は要件を JIRA に提出し、製品側とコミュニケーションをとりました。

2. PRD レビュー: 製品レビュー PRD ドキュメント。

3. 技術的な解決策の議論: 担当者が最初に予備的な解決策を伝え、その後全員で議論するのが最適です (担当者の経験に基づくと、直接のブレインストーミングよりも効率的である可能性があります)。それからみんなで話し合います。

4. 技術設計レビュー: 設計レビューはテストと呼ばれます。

5. 設計レビューの原則:レビュー会議は、全員が基本的に設計計画に同意するという前提に基づいて行われ、その後、計画が文書化されます。

6. インターフェースの設計: 入力と出力を正確に記述することに重点を置きます。

7. フィールドの設計: 要件に応じてフィールドを定義し、フィールドインジケーターと取得ソースを決定し、データ辞書を確立します。

8. 開発: ブランチを開いてコードを記述します。適切なテストケースを作成して、自分でテストしてください。

9. コードレビュー: テスターと他の開発者を招待してレビュー結果を提示してもらいます。目的は、他の学生にロジックの確認を手伝ってもらうことです。

10. テストの提出: テストポイントのリストを含むテストレポートを提供します。

11. オンライン化：事前に運用保守部門に通知し、マシンリソースを事前に申請し、業務に基づいて CPU、ストレージ、帯域幅などのリソースを見積もります。

12. ドキュメント: 開発が完了すると、ドキュメントにプロセスが記録され、再構築を容易にするためにデータ テーブル フィールドの説明が提供されます。

各役割の責任

このプロセスはプロジェクト開発を目的としています。プロジェクト開始時には、それぞれの役割の責任を明確にし、複数の役割との調整を行う必要があります。データ開発者は、さまざまな役割を調整し、やり取りする必要があります。

• 製品に対する需要の合理性と、既存の技術スタックが需要をサポートできるかどうかを評価する必要があります。たとえば、企業がリアルタイム データ ダッシュボードを作成したい場合、リアルタイム データ ウェアハウス アーキテクチャがなければこの要求を満たすことはできません。開発が確定したら、開発リソース、設備リソースなどのリソースを調整する必要があります。

• ビジネス関係者や製品関係者とともにデータの実現可能性を評価する必要があります。データ開発のためのデータ ソースは、どこからともなく現れるものではありません。既存のデータが需要開発をサポートできるかどうかをビジネス関係者と明確にする必要があります。データが欠落している場合は、欠落したデータを抽出するための別の計画を立てる必要があります。

• 技術的な実現可能性を自分で評価する必要があります。データ開発には、データ転送、データ同期、ETL、リアルタイム開発、オフライン開発などが含まれる場合があります。データ ソースの取得からデータの表示までの一連のプロセスの実現可能性を評価する必要があります。たとえば、データ ソースが複数の場所で生成される場合、binlong から取得し、Kafka を読み取り、ビジネス ライブラリを同期し、HDFS を読み取るなどの操作が必要になることがあります。データの出力先も、mysql、hive、ES、Kafka、redis などの複数のストレージなど、さまざまな場所になる場合があります。開発前にデータ処理全体を決定する必要があります。

• セキュリティとコンプライアンスの要件が満たされているかどうかを判断する必要があります。機密データをどのように扱うかは、非常に重要な要素です。データ開発者として、多くのデータに触れる機会があるかもしれませんが、どのデータが表示できるか、どのデータは感度を下げて表示できるか、どのデータは実装できないかなど、わからない場合があります。また、データフローのプロセス中に、データのセキュリティ、実装できるかどうか、転送できるかどうかなどにも注意を払う必要があります。

• ユニット テストを容易にするために、データ処理ロジックをテスターと同期し、いくつかの論理 SQL を文書化する必要があります。配信テストの前に、コードを自己テストして、テスト実行フェーズに流入するコードが特定の品質基準を満たしていることを確認する必要があります。同時に、テスターがテスト環境とプレリリース環境でテストできるように、構成を通じてコードをさまざまな環境間で切り替えられるようにすることが最善です。テストに合格すると、同じコードセットを直接オンラインにすることができます。

1. オンラインになる前に

01. 要件レビュー

要望伝達と要望検討会議。会議にはデータアナリスト、プロダクトマネージャー、データプロダクトマネージャーが参加しました。クライアントまたはサーバーの追跡が必要かどうか、および追跡する学生が参加する必要があるかどうかを決定します。サービスインターフェース、オンラインクラウドパッケージなどのデータAPIの場合は、サーバー学生も会議に参加する必要があります。会議では、ビジネスの背景と利点、データ モデルと調整、スケジュール、潜在的な危険とリスク ポイントの 3 つの側面に焦点が当てられました。

02. データ調査

データの探索とデータの研究。データ ソースについては、主に、クライアント側トラッキング、サーバー側トラッキング、および DB データの binlog の生成、分析、統合の完全なリンクに精通している必要があります。特に、要件を受け取ったり、主題ドメインモデルを設計する前に、どのようにデータを探索するか（データ調査、データ調査）は、次の点から行うことができます。

• 1. 大きさ。埋もれたデータであれば、重複しているか、報告不足かを直接推測できます。 db データの場合、これにより、データ統合が全量を増やすための抽出戦略であるかどうかを効果的に評価できます (db データは binlog に均一に保存することをお勧めします)。

• 2.スキーマ。フィールドの意味、ビジネスの説明、列挙値の説明、空室率、単位など。json や struct などの複雑なデータ型の構造とキーには特に注意してください。

• 3. 主キー。通常、DB データの主キーには問題はありませんが、サーバーによって報告されるデータには特別な注意を払う必要があります。

• 4. 一貫性。例えば、供給側と消費側の一貫性、B エンドと C エンドの一貫性などです。

  
  

データ品質を完全に保証し、問題を適時に検出して損失を阻止し、データ障害のリスクを軽減するために、上記をデータ ガバナンス DQC で設定し、毎日自動的に監視することをお勧めします。

03. パブリックモデル

パブリックモデルの設計と開発。 dwd dws dim 一般的なデータ モデル、既存のモデルを再利用できるかどうか、モデルが閉じられているかどうか。特に一部の大企業向けに、需要重視で既存モデルを拡充します。新規ビジネスの場合は、ビジネスプロセス図、CDM、ドメインモデルを整理する必要もあるかもしれません。次元インジケーター マトリックスを整理し、血統の依存関係をモデル化します。同時に、複数のモデルを設計し、次元をどのように表現するか、粒度をどのように変更するか、凝集性が高く結合度が低いか、再利用性があるかなどを検討します。

特に、パブリック モデルはオンライン ビジネス ロジックに結合されてはなりません。

04. アプリケーションモデル

アプリケーション層のデータ開発。比較的簡単ですが、油断しないでください。露出の形式、大きさ、粒度、べき等性、キューブが必要かどうかなどを考慮する必要があります。

05. モデルレビュー

モデルレビュー。この点を補足すると、開発前にモデルのレビューが必須となります。気づいていなかったモデル設計上の問題をタイムリーに発見して回避できるだけでなく、他の同僚が関連するモデルやビジネスを迅速に理解できるようにもなります。会社が大きくなればなるほど、A および B の役割であっても、より多くのレビューが必要になります。

ちょっとしたエピソード: 職場では、概念やアイデアをモデル化する上で同僚やリーダーとの意見の相違に遭遇することがよくあります。これは、ビジネス上の視点や出発点が異なることが原因である可能性があります。これは仕事では非常に一般的で普通のことです。職場でこれに遭遇しても、心理的な負担を感じる必要はありません。対処方法はいくつかあります:

• 公平になりなさい。感情に訴え、理性で動かします。

• 第1巻。徳が地位にふさわしくない場合は、交代される。

• 空洞。広い心を持ちながら、物事を形式的に行う。

• シンク。決してそれに慣れず仕事を辞めてください。

もちろん、その輪は本当に小さく、いつかまた同僚になれるかどうかはわかりませんので、冷静に対処して最善の解決策を見つけるのが最善です。

06. 標準化された検証

標準化された検証。モデル設計、フィールド名、テーブル名、パフォーマンス、ライフサイクルなどが仕様を満たしているかどうかを再度確認します。

プロジェクトベースの開発に加えて、データ開発者は、過去 6 か月間の販売データやユーザー アクセス データの取得など、製品によって発生する一時的なデータ要件に直面することがよくあります。データ サポートのこの部分では、バックエンドの連携は必要なく、テストも必要ない場合があります。代わりに、明確なデータ指標に基づいて、定期的または不定期にデータレポートを提供します。この部分のデータ開発モデルは比較的単純かつ高速ですが、明確にする必要もあります。

• データ要件テンプレート、一般要件申請書などを明確にします。要件フォームを提供する目的は、特に既存のデータ指標に関して、長いコミュニケーションを避けることです。製品に詳細なデータ要件フォームを提供するよう依頼し、要件フォームのテンプレートに従ってデータを提供するだけです。テンプレートは次のとおりです。

指標の要件には通常、以下の表の合意された項目が含まれます。合意した項目をカスタマイズする必要がある場合は、カスタム形式の列に入力できます。

• 必要な指標の意味、必要なフィールドの詳細、統計サイクル、開発サイクルなどを明確にします。

• 要件レビューが完了した後、要件に変更または反復がある場合は、要件が追跡不能にならないように、反復/変更要件申請フォームまたは JIRA を提供する必要があります。

• いくつかの重要な指標の定義については、文書に記載されている場合でも、製品で確認する必要があります。たとえば、製品が過去 6 か月間のすべての売上を必要とする場合、この売上に返金が含まれているかどうか、取引時間または支払い時間に基づいて計算されているかどうかなどを明確にする必要があります。二次開発につながる可能性のあるデータ指標の不一致を回避します。

• 開発プロセスでは、ドキュメントを標準化する必要があり、開発の前に設計を行う必要があり、システムを構築するときは、グローバルなビジョンを持ち、特定の点に限定してはなりません。リリースが完了したら終わりではありません。コード開発の完了は最初のステップにすぎません。その後のドキュメント構築、コードレビュー、データ監視、データアラーム、安定性などはすべて最初に計画する必要があります。

• 開発プロセス中にタイムリーなフィードバックを提供します。どの段階であっても、遅延のリスクを回避するために、プロジェクト期間中は毎日、フロントエンドとバックエンドの進行状況を同期する必要があります。

• 障害処理: プログラムのインストール後、目的またはコード上の理由によりバグが発生する場合があります。障害処理ソリューションはそれぞれ異なりますが、次回同じバグが発生しないように、障害の確認と記録に注意してください。

障害レベルの定義:

P0\P1 レベルの問題が指定時間内に解決できない場合、問題の研究開発エンジニアは、問題のコメントに指定時間内に解決できない合理的な理由を説明し、問題の具体的な解決時間を通知して電子メールで説明する必要があります。

著者: CIO Houseの友人 出典: インターネットから収集

CIOホーム www.ciozj.com WeChatパブリックアカウント: imciow