大數據數據流的架構和組件
作者：尹正傑
版權聲明：原創作品，謝絕轉載！否則將追究法律責任。
一.什么是數據流
1>.數據流概述
所謂數據流（流數據），是一組順序、大量、快速、連續到達的數據序 列，一般情況下，數據流可被視為一個隨時間延續而無限增長的動態數 據集合。應用於網絡監控、傳感器網絡、航空航天、氣象測控和金融服 務等領域。
2>.流數據特點
（1）數據實時到達； （2）數據到達次序獨立，不受應用系統所控制； （3）數據規模宏大且不能預知其大值； （4）數據一經處理，除非特意保存，否則不能被再次取出處理，或者再次提取數據代價昂貴。
3>.批處理和流處理的比較
我們在大數據離線計算開發/運維課介紹了大數據領域內的批處理技術。 它一般用於計算從所含的所有數據得到的結果，並實現對大數據集的深入 分析。相反，流處理則需要攝取一個數據序列，增量式更新指標、報告和 匯總統計結果，以響應每個到達的數據記錄。這種處理方法更適合實時監 控和響應調用。
4>.Lambda架構
很多企業結合使用兩種方法，從而構建一種混合模式，並同時維持實時處理層和批處理層。
二.大數據數據流典型架構
數據采集：
負責從各種數據源實時采集數據，在采集時，可能對數據做 簡單的ETL或格式轉換，以便於下游系統使用。例如：Apache Flume 。
數據接入：
由於數據采集的速度和數據處理的速度不一定同步，通常會 引入一個消息中間件來作為緩沖。例如：Apache Kafka
流式計算：
對流數據進行實時的處理和分析。例如：Apache Storm Ø 數據存儲：對處理后的結果數據進行保存，以便下游系統進行查詢或再 次處理。例如：Apache HBase
三.數據流涉及組件
1>.Flume
Flume是一個分布式、可靠、高可用的海量日志 聚合系統，支持在系統中定制各類數據發送方， 用於收集數據；同時，Flume提供對數據進行簡 單處理，並寫到各種數據接收方。
Flume特性：
高可靠性。Flume提供了end to end的數據可靠性機制
易於擴展。Agent為分布式架構，可水平擴展
易於恢復。Channel中保存了與數據源有關的事件，用於失敗時的恢復
功能豐富。Flume內置了多種組件，包括不同數據源和不同存儲方式
三大部件:
Source：數據源，簡單的說就是agent獲取數據的入口
Channel：管道，數據流通和存儲的通道。一個source必須至少和一個channel關聯
Sink：用來接收channel傳輸的數據並將之傳送到指定的地方，成功后從channel中刪除
2>.StreamSets
在StreamSets推出前，Flume，Scribe等少數開源工具是流式采集日志僅有的解決方案， Flume的應用案例多。StreamSets是Flume的良好替代者，優勢在於：
功能上，有管理界面，可以單個流啟停，統計報表豐富，可以預覽數據;
源端支持，其多出HDFS、JDBC、Redis、FTP等幾種重要的源
目標端支持，其多出JDBC、Redis、RabbitMQ、Flume等幾種重要的目標
數據處理上，StreamSets有多種字段處理組件，Flume僅有過濾功能。有強大的格式處理能力，且支持源端壓縮格式。還能使用JavaScript和Jython等自定義處理邏輯。
缺點是資源占用率比Flume略高，但因為和Flume一樣可以分布式部署，問題不大 • 因為其源和目標的支持特別豐富，還可以對數據進行不落地處理，因此還可以替代傳統ETL軟件的一部分功能.
3>.kafka
Kafka是一個高吞吐、分布式、基於發布訂閱的消息系統，利用Kafka可在廉價PC server上搭 建起大規模的消息系統。
Kafka特性：
使用zero-copy技術，數據在磁盤上存取代價為O(1)
高吞吐率，在萬兆網下，單點寫入吞吐率高於300MB/s
顯式分布式，即所有的producer、broker和consumer都可為分布式的
消費者的high level API易於使用（low level API則相當坑）
核心概念：
Broker：Kafka集群包含一個或多 個服務實例，這種服務實例被稱為 broker
Topic：每條發布到Kafka集群的消 息都有一個類別，這個類別被稱為 Topic
Producer：負責發布消息到Kafka Broker
Consumer：消息消費者，向Kafka Broker讀取消息的客戶端
4>.zookeeper
ZooKeeper是一個分布式應用程序協調服務，是Google的 Chubby的一個開源實現
Znode：ZooKeeper名字空間的每個節點都是以這樣一個路 徑來標識的。這樣的節點統一稱為znode。
持久的/臨時的
無序的/有序的
三種成員：
Leader：接收消息，並編號
Follower：同步消息，參與Leader選舉
Observer：同步消息，但不參與Leader選舉
ZAB：
ZooKeeper原子廣播協議， 是其數據一致性算法，與Paxos 有着明顯區別（注意ZooKeeper 並不是強一致的）