編集者の推奨言語：
IT技術とビッグデータ、機械学習では、アルゴリズムは、事前に進み、ますます多くの企業が、既存のデータの価値を認識しており、貴重な資産管理などのデータ自体を、掘ることを学ぶビッグデータと機械の使用、資産データを使用して、同定。この記事では、ヘルプ事業へのデータプラットフォームの設計アプローチのいくつかはデータ開発の難しさと痛みのポイントを減らすことについて説明します。
次の資料では、インターネット技術、著者劉沿江VIVOています
インターネット技術とドライサロン生体シェア、最新の業界動向や人気のミーティングをお勧めします。
近年、ITは、アルゴリズムの継続的な開発の機械方向を技術とビッグデータを学ぶとともに、より多くの企業は、既存のデータの値を実現した、データ自体貴重な資産管理など、ビッグデータと機械学習の使用データ資産を使用して、識別するために、掘る能力。効果的なデータの欠如は、全体的な赤字の建築設計または一部が、ビジネス層をリードする場合は直接ビッグデータビッグデータを活用することは困難である、ビッグデータおよびビジネスは大きなギャップがビジネスに割れ目のリードが登場していた大規模なデータの使用中に発生しましたデータに依存しない、需要は、達成することは困難で共有するデータやその他の問題に困難であり、この記事では、ヘルプ事業へのデータプラットフォームの設計アプローチのいくつかはデータ開発の難しさと痛みのポイントを減らすことについて説明します。
この記事では、次のとおりです。
-
ビッグデータインフラストラクチャコンポーネントおよび関連知識を紹介するこの記事の最初の部分。
-
第二部は、カッパおよびラムダアーキテクチャのアーキテクチャについて説明します。
-
第3のセクションは、カッパ下一般的なアーキテクチャの大きなデータとラムダアーキテクチャパターンを記述する
-
パートIVは、困難や痛みのポイントの下で裸エンドのデータ・アーキテクチャ・データ・システムを説明しています。
-
大規模なデータアーキテクチャのセクションV優れた全体的なデザイン
-
第五部分からこれらの大規模なデータコンポーネントにプラットフォームや部品の様々なを介してデータの導入で、業務システムの効率を改善するために、事業展開を効率的、ユーザーフレンドリーなデータプラットフォームを作成するために組み合わせる、そのためには、複雑なデータの開発コンポーネントを恐れていないです基本的な実装を意識することなく、あなただけがそのデータがもはやであることをビッグデータのエンジニアがスキルを持って、完全なデータは、リフロー、ワンストップの開発を完了するために、SQLを使用する必要があります。
まず、ビッグデータ・テクノロジー・スタック
ビッグデータ全体のプロセスは、各モジュールは、より複雑で、多くのモジュールが含まれ、リストモジュールとコンポーネント、ならびにそれらの機能特性以下の図は、フォローアップなどのデータ収集、データ伝送などのナレッジ・モジュールの詳細、の分野に関連するトピックを紹介し、リアルタイムシステムが存在します、オフライン計算、大規模なデータ記憶装置および他の関連モジュール。
二、ラムダとカッパアーキテクチャアーキテクチャ
今、基本的にすべてのビッグデータアーキテクチャは、ラムダとカッパアーキテクチャに基づいており、企業のデータアーキテクチャを満たすように設計されたこれらの二つのアーキテクチャ・パターンの異なる企業。ラムダアーキテクチャは、開発者は、大規模な分散型データ処理システムを構築することを可能にします。これは、優れた柔軟性と拡張性を持っていますが、ラムダアーキテクチャに関しては、インターネット上の多くの関連記事を見つけることができても、ハードウェア障害やヒューマンエラーのために良いフォールトトレランスを持っています。カッパアーキテクチャアドレスシステムを処理する2つのデータセットは、現在、研究の統合の流れの方向を承認され、コストの様々な、につながる、ラムダ・アーキテクチャを存在し、多くの企業は、このより高度なアーキテクチャを使用して開始しています。
ラムダアーキテクチャ
カッパアーキテクチャ
第三に、カッパおよびラムダアーキテクチャアーキテクチャでのビッグデータアーキテクチャ
大手企業は、基本的にはカッパまたはラムダアーキテクチャアーキテクチャモデルを使用している現在では、大規模なデータのこの2つのモードは、全体的なアーキテクチャは、開発の初期段階で次のようになります。
第四に、痛みのエンドポイントデータ
上記のアーキテクチャは、統合管理を実現するために一緒にリンクされたデータ要素の多種多様になりますが、連絡先データの開発、人々はより強烈に感じますが、裸のアーキテクチャ、ビジネス・データこのような開発は、基礎となる機器の使用、実際のデータの開発に多くの注目を必要とします次の側面の一部では、特に多くの痛みのポイントと困難があります。
-
全体のデータリンクの開発を管理するためのデータの開発IDEの欠如、長期的なプロセスは、それを管理することはできません。
-
異なるデータ・エンジニアが得られませ標準データ・モデリング・システムは、口径の間違った計算異なる指標を理解しないように。
-
大型高データコンポーネント開発要件、直接のHBase、ESおよびその他のテクノロジコンポーネントを使用するための一般的なビジネスは、さまざまな問題を生成します。
-
基本的に、すべての企業ビッグデータのチームは、多くの分野を含む、担当対応する人物を見つけるのは難しい見つけるのが困難な問題は非常に複雑になります。
-
困難なデータのサイロを壊すために、クロスチーム部門間のデータ共有が困難であり、彼らはどのようなお互いのデータを知りません。
-
モデル計算と流量計算を計算バッチの二組を維持する必要性は、開発を始めるために、バッチSQL均一のストリームを提供する必要が難しいです。
-
企業レベルのメタデータシステムの計画の欠如、リアルタイムとオフラインの再利用困難な計算では、同じデータ、開発のさまざまなタスクを梳綿、それぞれがあるべき。
基本的にはほとんどのデータ管理プラットフォーム上で企業やオープン容量に上記のすべての問題や痛みのポイントを提供します。複雑なデータ構造では、パーティーに適したデータは、機能のあらゆる面がクリアまたは非友好的ではない、それはより複雑なリンクを変更するには複雑になります。これらの痛みのポイントを解決したい、データベースを照会するためにSQLを書くようなビジネスは、端から端までのデータを使用するなど、簡単なようであるので、あなたは、慎重にシームレスにすべての側面、トップ技術コンポーネントを研磨する必要があります。
ファイブ優れた全体的なビッグデータアーキテクチャの設計
ヘルプデータプラットフォームに提供するプラットフォームやさまざまなツールを：プラットフォームのデータソースをデータ収集、データの同期、データ品質およびモデリングプラットフォーム用のキープラットフォーム、メタデータシステム、統一されたデータ・アクセス・プラットフォーム、リアルタイムおよびオフラインのコンピューティングプラットフォーム、リソースのスケジューリングプラットフォーム、ワンストップの開発IDE。
第六に、メタデータ - ビッグデータシステムの礎石
メタデータは、生産から消費までの完全なリンクデータを記録し、オープンデータソース、データウェアハウス、データアプリケーション、です。メタデータは、静的なテーブル、列、パーティション情報（メタストア）が含まれています。動的タスク依存のマッピング関係テーブル、およびETLスケジューリング情報、入力と出力メタデータ管理、基本的なデータ・コンテンツ、データアプリケーションであり、モデルは、データウェアハウス、データのライフサイクルを定義します。リソース消費量を計算し、BU個人や資産管理、DAGのタスクの依存関係、スケジューリングタスクの実行順序;ビルドタスクイラスト、品質管理タスクたとえば、タスクのメタデータ、テーブル、列、ユーザー間での地図データを用いて構築概要など。
全体の大規模なデータ・フローは、メタデータの管理に依存していると考えることができ、メタデータ設計のない完全なセットが存在しない、上記のデータを追跡することは困難があるだろう、権限は、共有データへの困難などのリソースを管理するために、困難な制御が困難です。
多くの企業は、メタデータを管理しますが、個人的に開発の特定の段階ではまだアーキテクチャに関連するメタデータと一致するように、独自のプラットフォームを構築する必要があると考えるようにハイブ頼っています。
メタデータは、空腹それの実際の数を参照することができます。
https://www.jianshu.com/p/f60b2111e414
七、フロー計算バッチ統合
FLINKを計算する二つのそのようなスパークオフラインコンピューティングなどのコンピューティングエンジン、リアルタイム性を維持した場合、ユーザは多大な苦痛の原因となります、流量計算を学ぶための両方のニーズもバッチコンピューティングの知識の知識が必要です。スパークやHadoopの持つリアルタイムた場合は、別のコンピューティング・エンジンに合わせて、構文のカスタムDSL言語記述を開発することができ、ユーザーは、上基本となる実装の詳細に焦点を当てる必要はありません、だけでオフラインDSL FLINKで言語を習得する必要がある、あなたは、Sparkを完了することができますそして、のHadoop計算エンジンのようなアクセスとFLINK。
八、リアルタイムおよびオフラインETLプラットフォーム
すなわちETL抽出・変換・ロード、抽出（抽出物）を介して送信元端末から宛先プロセスへの変換（変換）、荷重（負荷）データを説明します。この用語は、より一般的にデータウェアハウスETLに使用されるが、オブジェクトは、データウェアハウスに限定されるものではありません。データクレンジング、データフォーマット変換、データ完了、データの品質管理における一般的なETLプラットフォームでは、それは非常に重要な役割を持っています。重要な中間層のデータクリーニングとしては、一般的なETLは、少なくとも次のいくつかの機能を持っています：
-
等メッセージシステム、ファイルシステム、などの複数のデータソースをサポート
-
支持複数のオペレータ、フィルタリング、分割、変換、出力データソースクエリ機能補数オペレータ合同
-
このような非ストップサービスを提出する前述のオペレータのような動的論理的な変化を、サポートすることは掲示することによって行うことができジャーダイナミックの方法を変更します。
九、インテリジェントな統一された検索プラットフォーム
ほとんどのデータクエリが需要によって駆動され、需要が一つまたは複数のインターフェイス、インターフェイス書かれた文書を、開発するビジネスパーティの呼び出しに開いて、このモデルビッグデータシステム内の多くの問題があります。
-
このアーキテクチャは簡単ですが、インターフェイスは非常に粗い粒度で、柔軟性が高く、貧しいスケーラビリティ、再利用率ではありません。増加のビジネスニーズに合わせて、インターフェース、高いメンテナンスコストの数が大幅に増加。
-
一方、開発効率が膨大な量のデータのためのシステムは明らかに開発の重複の多くの原因となる、高いものではない、ロジックとデータが厳しく適用経験のビジネス面を減らし、多重化を達成することは困難です。
-
直接のHBaseや他の図書館サービスにさらさ統一検索プラットフォームが存在しない場合は、フォローアップのデジタル著作権管理運用・保守のアクセス大規模なデータ・コンポーネントがより困難になり、適用業務側にも同様に痛みがあり、わずかなミスが様々な問題を生じてしまいます。
インテリジェントのセットを介してデータのクエリの痛みポイントの大きな問題を解決するためのクエリ
テン、ビン標準システムのモデリングの数
ビジネスは資源の異なる廃棄物のデータコールおよびコピーを混乱させ、複雑さと規模データを増加させたとして、指標のデータ定義の重複をもたらした曖昧さ、しきい値を増やし、データの使用状況をもたらしました。埋没実際のビジネスといくつかの倉庫の使用にI証人は、例えば、いくつかのフォームフィールドと商品名は、いくつかのと呼ばれるSPU_IDをgood_idされ多大な苦痛の原因となりますこれらのデータを利用したい、他の多くの名前は、あります。だから、システムのモデリング、大規模なデータのない完全なセットが存在しない、データガバナンスは、以下の分野では特に、大きな困難をもたらすでしょう。
-
データ標準は、さえ同じ名前矛盾しているが、口径の定義は一貫していません。例えば、唯一のダースの定義があり、そのような指標をUV。問題が原因で発生します。すべてのUV、私は何でしょうか？データは同じではありませんなぜ、UVいますか？
-
膨大な研究開発費は、各エンジニアのニーズは、最初から最後まで開発プロセスのすべての詳細を知っているし、同じ「ピット」みんなのための研究開発人件費に時間とエネルギーの無駄が生じ、再び戻って辞任しました。これはまた、著者遭遇した問題の目的で、開発者は難しい実際のデータを抽出したいです。
-
統一標準仕様管理は、ダブルカウントなどの資源の無駄が生じ、ありません。その重複したストレージも深刻であるようにデータ・テーブル・レベルは、粒子サイズは、明確ではありません。
したがって、いくつかの大規模なデータ・ウェアハウス・テーブルの設計の開発は、アリババOneData体として、不合理抑制するように設計されたデザイン、データプラットフォームの開発プラットフォームの原則を遵守しなければなりません。一般に、開発者は、次のガイドラインに従ってデータを通過する必要があります：
アリババOneData設計システムを参照することができます興味があります。
XI、キー統合プラットフォーム
単純なデータ収集プラットフォームキーへの各種データ、データのETLのシームレスなインターネットへのインターネットを介してデータ伝送することができます。その後、データが変換されるオープン標準化スキーマ定義を通ってメタデータプラットフォームETLは、分割計算を完了するために開発作業にのみアプリケーションメタデータテーブル権限、オフラインデータとリアルタイム処理のための任意の後続の、リアルタイムおよびオフラインコンピューティングプラットフォームに流れ込みます。データソースのデータ取得支援複数種類、バイナリログ例えば、ログ収集、フロントエンド埋め込み、カフカメッセージキュー
十二、データ展開IDE-効率的なエンド・ツー・ツール
効率的なワンストップソリューションデータ開発ツール、リアルタイムの計算は、IDEとオフラインのコンピューティングタスクの開発を介して行うことができ、これらすべてのプラットフォームを介して取得しますワンストップソリューションを提供しています。データ開発IDEは、ワンストップの開発及び管理インターフェース、データIDE完全なデータ伝送、変換および統合操作を、当該製品およびサービスの全範囲として、データ統合、データの開発、データ管理、データ品質およびデータ・サービスを提供します。異なる着信データからデータを格納、および形質転換及び開発、そして最終的に他のデータ同期システムに処理されたデータを送信します。基本的にエンジニアがビッグデータは、上記複数のプラットフォームを組み合わせる能力を様々な痛みのポイントをマスクすることができ作る効率的な大規模データの開発IDEによって、開発者はSQLを書きやすいように大きなデータを作ることができます。
開発ツールは、データアリクラウドDataWorksを参照することができます。
また、いくつかの他の補助容量を終了するアドレス末尾に必要な困難は、説明し、興味のある学生が自分で勉強することができなくなりました。
XIII。その他
完全なR＆Dデータシステムは、もはやそれを議論することが継続し、中心を監視警報、派遣センターのリソース、コンピューティングリソースを単離し、データ品質試験、システム処理ワンストップデータを含みません。
