1.データソースレイヤー：従来のデータベース、データウェアハウス、分散データベース、NOSQLデータベース、半構造化データ、非構造化データ、クローラー、ログシステムなどが、ビッグデータプラットフォームのデータ生成メカニズムです。
2.データソーティングレイヤー：データクリーニング、データ変換、データ処理、データ関連付け、データ注釈、データ前処理、データロード、データ抽出などを含みます。このレイヤーの役割は、生データを処理して製品データにすることです。
3.データストレージレイヤー（データセンター）：メタデータ、ビジネスデータベース、モデルデータベースなど、運用システムで使用できるクリーンなデータを格納します。このレイヤーは、アプリケーションシステムに直接向き、高い信頼性、高い同時実行性、および高い精度。
4.データモデリングおよびマイニングレイヤー：このレイヤーは、データのディーププロセッシングを実装します。ビジネスニーズに応じて、ビジネスに適した統計分析モデルを確立し、ビッグデータ操作および処理プラットフォームを確立し、データ分析、データマイニング、ディープラーニングなどのアルゴリズムを使用します。生産データは、データの本質的な価値を掘り下げ、ビジネスシステムにデータと意思決定のサポートを提供します。
5.業界アプリケーション層：業界データの特性の詳細な分析、業界データ製品のニーズの調査、およびさまざまな業界に適したデータアプリケーション製品の確立。
6.データの視覚化：インテリジェントレポート、特別レポート、BIディスプレイ、プラットフォームインターフェイスなど、さまざまな方法でデータ表示およびデータ共有サービスを提供します。
ビッグデータプラットフォームアーキテクチャの階層的な分割に関する標準はありません。以前は、アプリケーションの分類も垂直方向と水平方向にあり、明確で理解しやすい「使用可能な」原則を反映しているため、ビッグデータアプリケーションの計画も非常に複雑になっています。ビッグデータプラットフォームは「5つの水平型と1つの垂直型」に分かれています。
詳細については、以下の例を参照してください。この図は、より古典的であり、妥協の結果です。インターネット上の多くのビッグデータアーキテクチャ図にマッピングできます。
データの流れによれば、下から上に5つの層に分かれています。実際には、従来のデータウェアハウスと非常によく似ています。データシステムは概念的に接続されています。データシステムは、データ取得層、データ処理層、データ分析層、データアクセス層、およびアプリケーションです。レイヤー。
同時に、ビッグデータプラットフォームのアーキテクチャは、同じレベルで従来のデータウェアハウスとは異なります。さまざまなシナリオに対応するために、100の花の特性を反映するために、より多くの技術コンポーネントが使用されます。これは困難です。
データ収集層：従来のETLオフライン収集、リアルタイム収集、インターネットクローラー分析などが含まれます。
データ処理層：さまざまなデータ処理シナリオに従って、HADOOP、MPP、ストリーム処理などに分割できます。
データ分析レイヤー：主に、データマイニング、機械学習、ディープラーニングなどの分析エンジンが含まれています。
データアクセス層：主に、読み取りと書き込みの分離を実現し、アプリケーション指向のクエリ機能と、リアルタイムクエリ、多次元クエリ、従来のクエリ、その他のアプリケーションシナリオを含むコンピューティング機能を取り除きます。
データアプリケーションレイヤー：企業の特性に応じて、さまざまなタイプのアプリケーションが分割されます。たとえば、オペレーターの場合、精密マーケティング、カスタマーサービスの苦情、基地局分析など、ロケーションベースの旅客フロー、ラベルベースの広告アプリケーションなどがあります。
データ管理：これは垂直的であり、主にデータの管理と運用および保守を実現するために、複数の層にまたがって統合管理を実現します。
1.データ収集層
オフラインバッチコレクションは、現在のストリームラインコレクションのメインストリームエンジンとなっているHADOOPを使用しています。このプラットフォームに基づいて、データコレクションアプリケーションまたはツールを展開する必要があります。
たとえば、BATは独自に開発した製品です。一般企業は商用バージョンを使用できます。現在、Huawei BDIなど、このタイプには多くのオプションがあります。多くの企業は技術的な強みを持っていますが、最初はアプリケーションシナリオについて十分に理解しておらず、詳細に取り組んでいます。非常に貧弱であり、BATとは非常に異なる統計機能の欠如など、製造された製品の要件を満たすことが困難になります。従来の企業は、そのような製品を購入するときに注意する必要があります。
製品を作って作ることができるかどうかは2つの領域の問題です。もちろん、小規模のインターネット企業も有用な収集ツールを自分で作ることができますが、実際の製品を抽象化して作成することは困難です。BATの自己研究は実際に巨大なアドバンテージ。
現在、リアルタイムデータ収集はビッグデータプラットフォームで標準となっています。主流はFLUME + KAFKAであり、ストリーム処理+インメモリデータベースと組み合わせられると推定されています。このテクノロジーは確かに信頼できますが、このようなオープンソースの機能は優れていますが、問題が発生すると多くの場合、解決サイクルは長くなります。
FLUMEの使用に加えて、ORACLEデータベーステーブルのリアルタイム収集を実現するために、OGG / DSGおよびその他のテクノロジーを使用して、リアルタイムログ収集を実現することもできます。これにより、従来のデータウェアハウスの負荷の問題を解決して、フルスケールで描画できます。
インターネット上の新しいデータは主にそれに依存しているため、クローラーは徐々に多くの企業が収集する標準になっています。Webページの分析、世論分析、Webサイトのランキングなどから多くのオンライン情報を得ることができます。すべての企業が企業を設立することをお勧めしますビッグデータプラットフォームの計画に含まれていない場合は、それについて考えることができます。データを取得できない場合は、言うまでもありません。
企業レベルのクローラーセンターの構築は、クローラーだけでなく、URLとアプリケーションの知識ベースの確立、中国語の単語のセグメンテーション、逆ソート、およびWebページテキストに基づくテキストマイニングも必要になるため、非常に困難です。このセットは非常に困難です。現在、solr、lucent、Nutch、ESなど、多くのオープンソースコンポーネントがありますが、それをうまく使用するには、長い道のりです。
もう1つは、可能であれば、データ収集プラットフォームをデータ交換プラットフォームにアップグレードすることを推奨します。これは、実際には、一方向のデータ収集だけでなく、ORACLEの必要性など、大量のデータ交換も行われるためです。 GBASEにデータを注ぐ、HBASEからASTERにデータを注ぐ、など。アプリケーションの場合、この値は非常に便利です。
データ収集とデータ交換は非常によく似た多くの機能を持っているので、統合して統合管理にも便利なのはなぜでしょうか。多くの企業データ交換はアプリケーション主導であり、インターフェース管理は面倒で、これも私の提案です。
一般に、ビッグデータ収集プラットフォームを構築することは非常に困難であり、顧客の観点からは、少なくとも次の3つの要件を満たす必要があります。
多様なデータ収集機能：リアルタイムの増分データ収集（Flume、メッセージキュー、OGGおよびその他のテクノロジを使用）およびバッチデータ分散収集機能（SQOOP、FTP VOER HDFS）をサポートして、テーブル、ファイル、メッセージなどの複数のデータを収集します。従来のETLに比べてパフォーマンスが大幅に向上しています。これは基本的なことです。
視覚的なクイック構成機能：グラフィカルな開発とメンテナンスのインターフェースを提供し、コードの記述なしでグラフィカルなドラッグアンドドロップ開発をサポートし、収集の難しさを軽減します。各構成データのインターフェースは、人件費を削減するために短時間で済みます。
統合スケジューリング管理および制御機能：収集タスクの統合スケジューリングを実現するために、Hadoopの複数の技術コンポーネント（MapReduce、Spark、HIVEなど）、リレーショナルデータベースストアドプロシージャ、シェルスクリプトなどをサポートし、複数のスケジューリング戦略（時間/インターフェース通知/マニュアル）。
2.データ処理層
HadoopのHIVEは、従来のデータウェアハウスの分散型代替手段です。従来のETLで使用されているデータクリーニング、フィルタリング、変換、直接要約などのシナリオが適していますが、データ量が多いほど、コストパフォーマンスが高くなります。しかし、これまでのところ、サポートされるデータ分析シナリオも限られています。単純なオフラインの大規模な分析と計算が得意です。そのため、複雑な相互相関操作の速度は非常に遅くなります。
たとえば、ある程度、企業顧客の統合ビューワイドテーブルは、マルチパーティデータの統合を伴うため、HIVEでは比較的非効率的ですが、不可能ではありません。最も遅くても、バランスを取る必要があります。
HadoopはX000クラスタの規模をサポートできませんでした。現在、多くの企業のデータ量はこの量を超えるはずです。Aliなどの企業と独自のR＆D機能（ODPSなど）に加えて、ビジネスに応じて分割されたHadoopクラスタに移行する必要がありますか？ Zhejiang Mobileなどの道路は、固定ネットワーク、モバイルネットワーク、イノベーションなどの複数のHadoopクラスタを分割しています。
Hadoop SPARKは機械学習の反復に非常に適していますが、それを大規模なデータ相関分析に適用できるかどうか、ある程度MPPを置き換えることができるかどうかを確認するための練習が必要です。
MPPは、分散アーキテクチャを使用する従来のデータウェアハウスに代わる最良の選択肢であると言えます。結局のところ、MPPは実際にはさまざまなリレーショナルデータベースです。SQLを完全にサポートしています。HIVEの変換分析後、データウェアハウスの融合モデリングはそれをパフォーマンスに使用するのに十分であり、そのコストパフォーマンスは従来のDB2よりも優れています。たとえば、実際の使用後、Gbase30-40クラスターは2つのトップマウントIBM 780を超える可能性があります。
現在、MPPには多くの製品があり、長所と短所を判断することは困難ですが、実際の結果は言うことができます。GBASEは優れており、同社のシステムの多くはその上で実行されており、主に国内向けであり、技術サービスの保証は比較的信頼できます。いくつかのアルゴリズムライブラリを導入することにはいくつかの利点があります。
現在、MPPは最終的にHadoopフレームワークに置き換えられると言われています。結局、SPARKなどは徐々に安定して成熟していますが、短期的にはまだ非常に信頼できると思います。データウェアハウスでプログレッシブエボリューション方式を採用する場合は、MPPは確かに良い選択です。
現在、China MobileやeBAYなどの多くの企業がこの種のマッシュアップ構造を採用して、さまざまなアプリケーションシナリオに適応しています。これは明らかに自然な選択です。
ストリーム処理にはビッグデータプラットフォームのトロイカが欠かせません。
多くの企業にとって、それは明らかに核兵器のような存在であり、多数のアプリケーションシナリオがそれを必要とするため、構築する必要があります。たとえば、IOE時代では想像できないリアルタイムおよび準リアルタイムのデータウェアハウスシナリオは、ストリーム処理で非常に重要になりました。シンプルで、かつてはリアルタイムインジケーターを数えるのが面倒でしたが、現在は詐欺対策リアルタイムシステムなど、1日での展開が進んでいます。
私はSTORMとIBM STREAMのみを試しました。IBMSTREAMをお勧めします。これは商用バージョンですが、その処理能力はSTORMに比べてわずかです。STORMは基本的に更新されていないと言われていますが、データ量は多くありません。見方としては、IBMなどの商用バージョンが適切な選択であり、さまざまなリアルタイムアプリケーションシナリオをサポートするには十分です。
ストリーム処理クラスターは、リアルタイムおよび準リアルタイムのデータ処理のために、インメモリーデータベースと組み合わせたストリーム処理テクノロジーを使用します。IBMStreamsストリーム処理クラスターは、会社のリアルタイムビジネスを実行します。
3.データ分析層
最初に言語について話しましょう。RとPythonは、データマイニングのオープンソース分野における現在の友人のペアです。私が選択したいのであれば、それは言えません。たとえば、Pythonはエンジニアリングに傾倒しているように感じます。たとえば、単語のセグメンテーションとRの描画は直接サポートされています。能力は非常に強力です。しかし、以前はサンプル統計に焦点を合わせていたため、大規模データのサポートは制限されています。
SPARKはオプションです。SPARK+ scalaを使用することをお勧めします。結局のところ、SPARKはscalaで記述されており、多くのネイティブ機能をすばやくサポートできます。
TDのMPPデータベースASTERにも多くのアルゴリズムが組み込まれています。これは並列アーキテクチャに基づいて最適化する必要があります。これはオプションのようです。過去に数度の通信を行ったことがあります。速度は確かに非常に高速ですが、データの使用はまれです。外国人も必要です。サポート。
従来のデータマイニングツールが不本意だった後、SPSSにビッグデータのハドープのサポートを強化するIBM SPSS Analytic Serverが導入され、ビジネススタッフのフィードバックは良好です。
おそらく、将来の機械学習でもハイエンドユーザーとローエンドユーザーの混合が形成され、ハイエンドユーザーはSparkを使用し、ローエンドユーザーはSPSSを使用するだけでなく、さまざまなアプリケーションシナリオに適応します。
いずれの場合も、ツールは単なるツールであり、最終的にモデリングエンジニアの制御能力に依存します。
4.データオープンレイヤー
一部のエンジニアは、HIVEをクエリとして直接出力します。これは不合理ですが、計算とクエリにはまったく異なる技術的能力が必要であることも示しています。クエリの分野でも、異なるシナリオに従って異なるテクノロジを選択する必要があります。
HBASEは非常に使いやすく、列のストレージに基づいており、クエリ速度はミリ秒の範囲であり、一般的な数百億のレコードクエリのレバーでもあります。一定の高可用性を備えています。本番環境での詳細なリストクエリとインデックスライブラリクエリは非常に優れています。アプリケーションのシナリオ。ただし、データの読み取りはキーまたはキー範囲による読み取りのみをサポートしているため、rowkeyを設計する必要があります。
RedisはKVデータベースであり、読み取りおよび書き込み速度はHBASEよりも高速です。ほとんどの場合、HBASEは実行できますが、Redisも実行できますが、Redisはメモリに基づいており、主にキー値メモリキャッシュで使用されるため、データが失われる可能性があります。タグのリアルタイムクエリに使用されます。協力しているほとんどのインターネットまたは広告会社がこのテクノロジーを使用していますが、データが大きくなる場合は、HBASEが唯一のオプションです。
さらに、IMPALAが提供するインターネットログに基づくリアルタイムのオンラインクエリアプリケーションは、SQLFireとGemFireを使用して、マーケティングプラットフォームに分散メモリベースのSQL相関分析を実装するためにも使用されています。速度は向上しますが、バグは多数ありますが、導入と変換のコストは比較的大きくなります。 。
Kylinは現在、hadoop / SPARKの多次元分析に基づいたキラーツールですが、多くのアプリケーションシナリオがあり、それを使用する機会が欲しいです。
5.データアプリケーション層
各企業は、実際の状況に応じて独自のアプリケーションを計画する必要があります。実際、アプリケーションブループリントを開発することは困難です。ビッグデータアーキテクチャの上位層が高いほど、変更が速すぎるため、不安定になります。参考図：
6.データ管理
ビッグデータプラットフォームの管理は、アプリケーション管理とシステム管理に分かれています。たとえば、アプリケーションの観点から、11のビッグデータテクノロジーコンポーネントに対応し、さまざまな技術コンポーネントの透過性を実現できるDACPビジュアル管理プラットフォームを確立しました。同時に、プラットフォームを介して機能にアクセスし、データ設計から開発、データ破壊までのライフサイクル管理全体を実現します。また、標準、品質ルール、およびセキュリティ戦略は、プラットフォーム上で強化され、管理前、プロセス内制御、監査後の監査、監査を実現します。包括的な品質管理と安全管理。
もちろん、スケジュール管理、メタデータ管理、品質管理などの他のものも、開発のソースが制御されているため、データ管理の複雑さが大幅に軽減されます。
システム管理の観点から、同社はビッグデータプラットフォームを統合クラウド管理プラットフォーム管理（プライベートクラウド）に組み込んでいます。クラウド管理プラットフォームには、ワンクリックデプロイメントとインクリメンタルデプロイメントをサポートする視覚的な操作とメンテナンスツール、およびマルチテナント指向のコンピューティングリソース管理と制御システムが含まれています。 （マルチテナント管理、セキュリティ管理、リソース管理、負荷管理、クォータ管理、メータリング管理）および包括的なユーザー権利管理システムは、エンタープライズレベルのビッグデータプラットフォームの運用および保守管理機能のサポートを提供します。もちろん、このような野心的な目標を達成する必要があります。一日の仕事。
ビッグデータプラットフォームの革新的な価値を要約します。
ビッグデータの時代では、ほとんどの企業のアーキテクチャは必然的に分散され、スケーラブルで多様化されます。いわゆる長期的な分離は、もはや世界を支配することのできるテクノロジではありません。これは、集中型企業の従来のテクノロジーアウトソーシングモデルに影響を与えます。巨大です。
ビッグデータとクラウドコンピューティングの時代には、非常に多くの技術コンポーネントがあり、新しい技術を採用する必要があります。機会とリスクは共存します。
ビッグデータプラットフォームの商用バージョンの場合、企業はパートナーのサービスに追いつくことができません。開発が速すぎるため、オープンソースバージョンの場合、企業は独自の運用および保守機能と技術機能、自律機能のより実用的な要件の課題に直面しています。高い。
現在、BAT、Huawei、新しいインターネットなどの企業は才能を駆使しています。オペレーターなどの才能への挑戦は巨大ですが、同時に機会も含まれています。実際、ビッグデータに取り組んでいる人にとっては一方で、企業は変革を遂げている一方で、データ量は十分に大きく、テクノロジーを支配する機会が多いため、事業者や他の企業と関わることも良い選択です。
