ディレクトリ
（A）一般的なフレームワークの概要
エンジン層、データ分析およびデータ可視化層層を算出し、データソース、データ収集層、データ記憶層、リソース管理及びサービス連携の層：7層の一般的な枠組みの下でボトムアップ、OSIと同様、大規模なデータシステム。次のように示します：
（II）データ収集層
データ・ソースに直接当接データ収集層は、分散、一般化された属性を有する、製品の使用中に生成されたログを収集する責任があります。実際の場面ので、データソースのほとんどはそれほど大きな一緒に収集するために、困難散乱されるので、設計は、次のような特徴を持っている必要があります。
スケーラビリティ：異なるさまざまなデータソースを構成することができ、ピークが発生し、システムのボトルネックになっていないとき。
信頼性：データが伝送（特に財務データ）の間に失われることはできません。
セキュリティ：機密データが送信（パスワード、お金、など）中に暗号化されるために、
低遅延：データソースのサイズが大きい、通常はログ収集であるため、ストレージシステムにできるだけ早く収集しなければならないので、バックログを生成することはできません。
次のようにオープンソース・フレームワークで表されるためのHadoop /スパークでは、典型的には、データ収集方式選択のいくつかの層を有します。
Sqoop：導入のための一般的なリレーショナルデータベースの合計量の比較。
運河：インクリメントのためのより一般的なリレーショナルデータベース導入。
水路：そのようなテキストログなどの比較的一般的な非リレーショナルログ収集については、
カフカ：高分散フォールトトレラント機能を持つ、データチャネルの概念に類似したメッセージキューを、配布しました。
（III）データ記憶層
従来のリレーショナルデータベースなどの分散、スケーラビリティと高可用性の面でいくつかのボトルネックがあり、それがビッグデータシーンに適応することは困難であるプライマリストレージとコンピューティングシステムとして推奨されていません。データ記憶層は、リレーショナルおよび非リレーショナルデータを含むデータの着陸及び貯蔵のために責任があり、集中ディスパッチシステムを有しています。データ記憶層は、主に以下の特徴を有します。
スケーラビリティ：メインキャリアランディングデータとして、データ成長は長期タスクであるため、一定期間内にクラスタの運搬能力は、常にボトルネックが到達します。したがって、データ記憶層は、機械の膨張容量を考慮する必要があります。
場合は、コストの考慮の、データ記憶層は、1つまたは複数の機械で一般的に複数のマシンので、それ自体が優れた耐障害性を持つシステムを必要とし、比較的安価な設備で構築する必要があり、失敗です：フォールトトレランスこれは、データの損失は発生しません。
ストレージモデル：したがって、データの多様性に起因して、データの構造化、非構造化、二つのタイプをサポートするためのデータ記憶層の必要性、及び、テキスト、および他のデータ記憶列モデルのサポートを必要とします。
グーグル、通常GFS、BigTableの、メガストア、スパナやGoogleの他の技術的な解決策が提案した分散コンピューティングの概念以来。ために、以下のようにオープンソース・フレームワークで表さのHadoop /スパーク、データ記憶層は、典型的には、いくつかのオプションを選択しました。
HDFS：分散ファイルシステムは、非常に良好なスケーラビリティおよびフォールトトレランスと、オープンソース実装をGFS、かつ安価な装置に非常に適した構造である。
HBaseの：HDFSに分散データベース、BigTableのオープンソース実装に基づいて構築され、格納可能構造化および半構造化データ、行と列の無制限の拡大をサポートしています。
クーズー：Cloudera社は、HDFSオープンカラム・ストレージ・システム上で実行されているスケーラビリティと高可用性を備えました。
（IV）リソース管理とサービス連携層
インターネット技術の成長の規模によって、状況は技術の異なるミックスと運用・保守の面にとってますます共通のフレームワーク、開発、巨大な挑戦を生産リソースの利用率です。すべての技術に関しては、マシンのリソースを共有し、統一されたプラットフォームの枠組みの中で展開され、リソース管理とサービス連携層のように紹介。導入後、次のようにいくつかの利点があります。
高いリソース使用率：効果的プログラムとマシンリソースの数のバランスを考慮することができ、クラスタリソースをフルに活用します。
低い操作および保守費用：各フレームの動作は、操作および保守のための統合プラットフォームに集約され、人員要件が低くなります。
共有データであることができる：同じデータが異なるコンピューティングフレームワーク、減少演算コストを有する共有計算結果記憶を計算するために設けることができます。
Googleは、リソース管理のためのボルグ、オメガとチャビー3つのオプションを使用しています。Hadoopのために/スパークは、通常、次のように選択するように、いくつかのオプションを持っているオープンソースのフレームワーク、リソース管理とサービス連携層によって表されます：
糸：Hadoopのフレームワークは、中央マシンのリソース（CPU、メモリなど）を管理し、キューの方法でスケジュールタスクのことができるようにすることができます統一リソース管理とスケジューリングシステムを担当し、
飼育係：分散協調サービス、ソリューション、パクシアルゴリズムに基づいてキュー、分散ロックを分散複雑なシーンを提供します。
（E）計算エンジン層
計算エンジンは、2つのシナリオのバッチに分けて処理をフローである：データ少ない大量のリアルタイムを要求するとき、又は場合複雑な計算ロジック、計算されたデータを使用して、バッチモード、ハイスループットの追求;データの場合、適度な量、及びリアルタイム要件、および比較的単純な論理計算、データのストリーミングモードを使用して計算、低レイテンシーの追求です。複雑でかさばるデータに対処するためのリアルタイムコンピューティングフレームワークは、現在存在しません。近年ではこれら2つのシナリオ、ますます人気に加えて、使いやすさにデータを整理し、計算するための標準化されたOLAPの方法によるインタラクティブなアプローチは、大きな利点があります。エンジンの該当シーンは3種類以下のように：
バッチ：インデックス、データマイニング、大規模で複雑なデータ分析、機械学習、
ストリーミング：広告勧告、リアルタイムのレポート、抗浮気。
インタラクティブ：データクエリ、計算を報告します。
GoogleはMapReduceの、原則ドレメル2つのフレームワークの実現に採択され、広く使われているオープンソースのフレームワークシーンを提供します。プレゲル、Precolatorは、MillWheelまた、オープンソースのシーンの下で採用されています。現在のHadoop /スパーク、オープンソース・フレームワークは、一般的なスキームを表し、次のとおりです。
MapReduceの：古典的なバッチ・エンジンは、非常に優れたスケーラビリティと耐障害性を持っています。
インパラ/プレスト/ドリル：Clouderaのは、Facebook、HDFSに保存されたデータを使用して処理するApacheのオープン、標準SQLによって、それぞれ、グーグルDremlベースのオープンソースで。
スパーク：DAGエンジンによって、RDDに基づいて、データ、高速データ・マイニングのためのメモリの主な用途の抽象表現を提供します。
嵐/スパークストリーミング/ FLINK：ストリーミングシステム、すべての良いフォールトトレランスとスケーラビリティを持って、実装の詳細は異なります。
（VI）データ解析レイヤ
フレームワークの直接出力結果が、簡単のために考慮すべき多くのことを計算し、フレームワークは、計算エンジンインタラクティブ層に置き換えてもよいです。技術的な考慮事項プラットフォーム側に通常の状況下では、層は、複数のプログラムのMySQLは、Oracle、PostgreSQLと他のリレーショナルデータベースを使用しました。次のように通常の分類は、要約されています：
インパラ/プレスト/ドリル：実施するための対話型コンピューティングエンジン。
MySQLの/オラクル/ Postgresqlの：リレーショナルデータベースの実装。
ハイブ/豚：計算質量データに実装。
Mahoutの/ MLlib：今一番スパークによって実装元々のMapReduceの実装に基づいて機械学習とデータマイニングアルゴリズムの共通セット、、;
ビーム/カスケード：統一バッチと計算ロジックを達成するために、より高いレベルのAPIを提供し、計算に2つのフレームワークを流れ。
（G）データ可視化層
大きなデータ・シナリオでは、典型的には、複数の選択されたプログラムを達成するために、等EChartsように、フロントエンドプラグによって実現。一般的な表現は、次のとおり、図のパスのような折れ線グラフ、棒グラフ、円グラフ、散布、K線、レーダー、熱力学的ダイアグラムを、。
データ視覚化層設計コンピュータグラフィックス、画像処理、および他の関連分野、および対話処理に関し、コンピュータ支援設計、コンピュータビジョン技術、人間とコンピュータの相互作用の複数。
