公司要開搞大數據了，針對大數據的一般姿勢做了個簡單調研。
一、通用架構
二、組件選擇
1、Hdfs、HBase
Hdfs：分布式文件存儲，無縫對接所有大數據相關組件。高容錯（多副本）、高吞吐。適合一次寫入，多次讀出。不適合低延遲讀取、小文件存儲（尋址時間超過讀取時間）。
HBase：非關系型分布式數據庫，基於Hdfs，高容錯、高吞吐。HBase采用的是Key/Value的存儲方式，即使隨着數據量增大，也幾乎不會導致查詢的性能下降。
2、Flume、Sqoop
Flume：最主要的作用就是，實時讀取服務器本地磁盤的數據，將數據寫入到HDFS/Kafka/HBase。
Sqoop：用來在RDBMS和Hadoop之間進行數據傳輸的工具就是我們所說的Sqoop。在這里，RDBMS指的是MySQL，Oracle SQL等，而Hadoop指的是Hive，HDFS和HBase等。 我們使用Sqoop將數據從RDBMS導入Hadoop,也可用於將數據從Hadoop導出到RDBMS
3、Kafaka
高並發的基石。吞吐量遠遠領先於同類別的MQ。
LinkedIn團隊做了個實驗研究，對比Kafka與Apache ActiveMQ V5.4和RabbitMQ V2.4的性能
生產者 消費者
4、MapReduce & Hive & Spark & Flink & Beam
4.1、演變史
4.2、MapReduce 到 Hive 到 SparkSQL的演變
4.3、MapReduce 、 Spark 、Flink
MapReduce
Spark
MapReduce：
MapReduce 模型的抽象層次低，大量的底層邏輯都需要開發者手工完成。
只提供 Map 和 Reduce 兩個操作。比如兩個數據集的 Join 是很基本而且常用的功能，但是在 MapReduce 的世界中，需要對這兩個數據集做一次 Map 和 Reduce 才能得到結果。
在 Hadoop 中，每一個 Job 的計算結果都會存儲在 HDFS 文件存儲系統中，所以每一步計算都要進行硬盤的讀取和寫入，大大增加了系統的延遲。
Spark：
Spark 最基本的數據抽象叫作彈性分布式數據集（Resilient Distributed Dataset, RDD），它代表一個可以被分區（partition）的只讀數據集，它內部可以有很多分區，每個分區又有大量的數據記錄（record）。
RDD 是 Spark 最基本的數據結構。Spark 定義了很多對 RDD 的操作。如 Map、Filter、flatMap、groupByKey 和 Union 等等，極大地提升了對各種復雜場景的支持。
相對於 Hadoop 的 MapReduce 會將中間數據存放到硬盤中，Spark 會把中間數據緩存在內存中，從而減少了很多由於硬盤讀寫而導致的延遲，大大加快了處理速度。
Flink
在 Flink 中，程序天生是並行和分布式的。一個 Stream 可以包含多個分區（Stream Partitions），一個操作符可以被分成多個操作符子任務，每一個子任務是在不同的線程或者不同的機器節點中獨立執行的。
性能對比
可以看出，Hadoop 做每一次迭代運算的時間基本相同，而 Spark 除了第一次載入數據到內存以外，別的迭代時間基本可以忽略。
4.4、幾種處理引擎對比
| API | 類SQL | 性能 | 容錯性 | 實時性 | 批處理 | 流處理 | Exactly once語義 | 社區活躍度 | |
|---|---|---|---|---|---|---|---|---|---|
| MapReduce | 復雜 | 沒有 | 低 | 低 | 低 | 中 | 不支持 | 無 | 低 |
| Hive | 簡單 | 有 | 低 | 高 | 低 | 中 | 不支持 | 無 | 中 |
| Spark | 簡單 | 有 | 高 | 高 | 中高（秒級） | 高 | 中 | 支持 | 高 |
| Flink | 簡單 | 有 | 高 | 高 | 高（微妙級） | 中 | 高 | 支持 | 中 |
| Beam | 或者代表着未來。目前在谷歌內部使用、生態還沒發展起來。拭目以待 | ||||||||
附1：
在流處理系統中，我們對應數據記錄的處理，有3種級別的語義定義，以此來衡量這個流處理系統的能力。
- At most once（最多一次）。每條數據記錄最多被處理一次，潛台詞也表明數據會有丟失（沒被處理掉）的可能。
- At least once（最少一次）。每條數據記錄至少被處理一次。這個比上一點強的地方在於這里至少保證數據不會丟，至少被處理過，唯一不足之處在於數據可能會被重復處理。
- Exactly once（恰好一次）。每條數據記錄正好被處理一次。沒有數據丟失，也沒有重復的數據處理。這一點是3個語義里要求最高的。
4.5、使用場景
MapReduce：僅僅用來學習，理解大數據的原理。
Hive：類SQL引擎，適合做報表分析
Spark： Spark 存在的一個缺點——無法高效應對低延遲的流處理場景入手。對於以下場景，你可以選擇 Spark。
- 數據量非常大而且邏輯復雜的批數據處理，並且對計算效率有較高要求（比如用大數據分析來構建推薦系統進行個性化推薦、廣告定點投放等）；
- 基於歷史數據的交互式查詢，要求響應較快；
- 基於實時數據流的數據處理，延遲性要求在在數百毫秒到數秒之間。
Spark 完美滿足這些場景的需求， 而且它可以一站式解決這些問題，無需用別的數據處理平台。
Flink：由於 Flink 是為了提升流處理而創建的平台，所以它適用於各種需要非常低延遲（微秒到毫秒級）的實時數據處理場景，比如實時日志報表分析。
而且 Flink 用流處理去模擬批處理的思想，比 Spark 用批處理去模擬流處理的思想擴展性更好，所以我相信將來 Flink 會發展的越來越好，
生態和社區各方面追上 Spark。比如，阿里巴巴就基於 Flink 構建了公司范圍內全平台使用的數據處理平台 Blink，美團、餓了么等公司也都接受 Flink 作為數據處理解決方案。
可以說，Spark 和 Flink 都在某種程度上統一了批處理和流處理。
三、任務分工
