『壹』 主流的數據分析平台構架有哪些
1、Hadoop
Hadoop 採用 Map Rece 分布式計算框架，根據 GFS開發了 HDFS 分布式文件系統，根據 Big Table 開發了 HBase數據存儲系統。Hadoop 的開源特性使其成為分布式計算系統的事實上的國際標准。Yahoo，Facebook，Amazon 以及國內的網路，阿里巴巴等眾多互聯網公司都以 Hadoop 為基礎搭建自己的分布。
2、Spark
Spark 是在 Hadoop 的基礎上進行了一些架構上的改良。Spark 與Hadoop 最大的不同點在於，Hadoop 使用硬碟來存儲數據，而Spark 使用內存來存儲數據，因此 Spark 可以提供超過 Ha?doop 100 倍的運算速度。由於內存斷電後會丟失數據，Spark不能用於處理需要長期保存的數據。
3、Storm
Storm是 Twitter 主推的分布式計算系統。它在Hadoop的基礎上提供了實時運算的特性，可以實時的處理大數據流。不同於Hadoop和Spark，Storm不進行數據的收集和存儲工作，它直接通過網路實時的接受數據並且實時的處理數據，然後直接通過網路實時的傳回結果。
4、Samza
Samza 是由 Linked In 開源的一項技術，是一個分布式流處理框架，專用於實時數據的處理，非常像Twitter的流處理系統Storm。不同的是Sam?za 基於 Hadoop，而且使用了 Linked In 自家的 Kafka 分布式消息系統。
Samza 非常適用於實時流數據處理的業務，如數據跟蹤、日誌服務、實時服務等應用，它能夠幫助開發者進行高速消息處理,同時還具有良好的容錯能力。
『貳』 五種大數據處理架構
五種大數據處理架構
大數據是收集、整理、處理大容量數據集，並從中獲得見解所需的非傳統戰略和技術的總稱。雖然處理數據所需的計算能力或存儲容量早已超過一台計算機的上限，但這種計算類型的普遍性、規模，以及價值在最近幾年才經歷了大規模擴展。
本文將介紹大數據系統一個最基本的組件：處理框架。處理框架負責對系統中的數據進行計算，例如處理從非易失存儲中讀取的數據，或處理剛剛攝入到系統中的數據。數據的計算則是指從大量單一數據點中提取信息和見解的過程。
下文將介紹這些框架：
· 僅批處理框架：
Apache Hadoop
· 僅流處理框架：
Apache Storm
Apache Samza
· 混合框架：
Apache Spark
Apache Flink
大數據處理框架是什麼？
處理框架和處理引擎負責對數據系統中的數據進行計算。雖然「引擎」和「框架」之間的區別沒有什麼權威的定義，但大部分時候可以將前者定義為實際負責處理數據操作的組件，後者則可定義為承擔類似作用的一系列組件。
例如Apache Hadoop可以看作一種以MapRece作為默認處理引擎的處理框架。引擎和框架通常可以相互替換或同時使用。例如另一個框架Apache Spark可以納入Hadoop並取代MapRece。組件之間的這種互操作性是大數據系統靈活性如此之高的原因之一。
雖然負責處理生命周期內這一階段數據的系統通常都很復雜，但從廣義層面來看它們的目標是非常一致的：通過對數據執行操作提高理解能力，揭示出數據蘊含的模式，並針對復雜互動獲得見解。
為了簡化這些組件的討論，我們會通過不同處理框架的設計意圖，按照所處理的數據狀態對其進行分類。一些系統可以用批處理方式處理數據，一些系統可以用流方式處理連續不斷流入系統的數據。此外還有一些系統可以同時處理這兩類數據。
在深入介紹不同實現的指標和結論之前，首先需要對不同處理類型的概念進行一個簡單的介紹。
批處理系統
批處理在大數據世界有著悠久的歷史。批處理主要操作大容量靜態數據集，並在計算過程完成後返回結果。
批處理模式中使用的數據集通常符合下列特徵…
· 有界：批處理數據集代表數據的有限集合
· 持久：數據通常始終存儲在某種類型的持久存儲位置中
· 大量：批處理操作通常是處理極為海量數據集的唯一方法
批處理非常適合需要訪問全套記錄才能完成的計算工作。例如在計算總數和平均數時，必須將數據集作為一個整體加以處理，而不能將其視作多條記錄的集合。這些操作要求在計算進行過程中數據維持自己的狀態。
需要處理大量數據的任務通常最適合用批處理操作進行處理。無論直接從持久存儲設備處理數據集，或首先將數據集載入內存，批處理系統在設計過程中就充分考慮了數據的量，可提供充足的處理資源。由於批處理在應對大量持久數據方面的表現極為出色，因此經常被用於對歷史數據進行分析。
大量數據的處理需要付出大量時間，因此批處理不適合對處理時間要求較高的場合。
Apache Hadoop
Apache Hadoop是一種專用於批處理的處理框架。Hadoop是首個在開源社區獲得極大關注的大數據框架。基於谷歌有關海量數據處理所發表的多篇論文與經驗的Hadoop重新實現了相關演算法和組件堆棧，讓大規模批處理技術變得更易用。
新版Hadoop包含多個組件，即多個層，通過配合使用可處理批數據：
· HDFS：HDFS是一種分布式文件系統層，可對集群節點間的存儲和復制進行協調。HDFS確保了無法避免的節點故障發生後數據依然可用，可將其用作數據來源，可用於存儲中間態的處理結果，並可存儲計算的最終結果。
· YARN：YARN是Yet Another Resource Negotiator（另一個資源管理器）的縮寫，可充當Hadoop堆棧的集群協調組件。該組件負責協調並管理底層資源和調度作業的運行。通過充當集群資源的介面，YARN使得用戶能在Hadoop集群中使用比以往的迭代方式運行更多類型的工作負載。
· MapRece：MapRece是Hadoop的原生批處理引擎。
批處理模式
Hadoop的處理功能來自MapRece引擎。MapRece的處理技術符合使用鍵值對的map、shuffle、rece演算法要求。基本處理過程包括：
· 從HDFS文件系統讀取數據集
· 將數據集拆分成小塊並分配給所有可用節點
· 針對每個節點上的數據子集進行計算（計算的中間態結果會重新寫入HDFS）
· 重新分配中間態結果並按照鍵進行分組
· 通過對每個節點計算的結果進行匯總和組合對每個鍵的值進行「Recing」
· 將計算而來的最終結果重新寫入 HDFS
優勢和局限
由於這種方法嚴重依賴持久存儲，每個任務需要多次執行讀取和寫入操作，因此速度相對較慢。但另一方面由於磁碟空間通常是伺服器上最豐富的資源，這意味著MapRece可以處理非常海量的數據集。同時也意味著相比其他類似技術，Hadoop的MapRece通常可以在廉價硬體上運行，因為該技術並不需要將一切都存儲在內存中。MapRece具備極高的縮放潛力，生產環境中曾經出現過包含數萬個節點的應用。
MapRece的學習曲線較為陡峭，雖然Hadoop生態系統的其他周邊技術可以大幅降低這一問題的影響，但通過Hadoop集群快速實現某些應用時依然需要注意這個問題。
圍繞Hadoop已經形成了遼闊的生態系統，Hadoop集群本身也經常被用作其他軟體的組成部件。很多其他處理框架和引擎通過與Hadoop集成也可以使用HDFS和YARN資源管理器。
總結
Apache Hadoop及其MapRece處理引擎提供了一套久經考驗的批處理模型，最適合處理對時間要求不高的非常大規模數據集。通過非常低成本的組件即可搭建完整功能的Hadoop集群，使得這一廉價且高效的處理技術可以靈活應用在很多案例中。與其他框架和引擎的兼容與集成能力使得Hadoop可以成為使用不同技術的多種工作負載處理平台的底層基礎。
流處理系統
流處理系統會對隨時進入系統的數據進行計算。相比批處理模式，這是一種截然不同的處理方式。流處理方式無需針對整個數據集執行操作，而是對通過系統傳輸的每個數據項執行操作。
· 流處理中的數據集是「無邊界」的，這就產生了幾個重要的影響：
· 完整數據集只能代表截至目前已經進入到系統中的數據總量。
· 工作數據集也許更相關，在特定時間只能代表某個單一數據項。
處理工作是基於事件的，除非明確停止否則沒有「盡頭」。處理結果立刻可用，並會隨著新數據的抵達繼續更新。
流處理系統可以處理幾乎無限量的數據，但同一時間只能處理一條（真正的流處理）或很少量（微批處理，Micro-batch Processing）數據，不同記錄間只維持最少量的狀態。雖然大部分系統提供了用於維持某些狀態的方法，但流處理主要針對副作用更少，更加功能性的處理（Functional processing）進行優化。
功能性操作主要側重於狀態或副作用有限的離散步驟。針對同一個數據執行同一個操作會或略其他因素產生相同的結果，此類處理非常適合流處理，因為不同項的狀態通常是某些困難、限制，以及某些情況下不需要的結果的結合體。因此雖然某些類型的狀態管理通常是可行的，但這些框架通常在不具備狀態管理機制時更簡單也更高效。
此類處理非常適合某些類型的工作負載。有近實時處理需求的任務很適合使用流處理模式。分析、伺服器或應用程序錯誤日誌，以及其他基於時間的衡量指標是最適合的類型，因為對這些領域的數據變化做出響應對於業務職能來說是極為關鍵的。流處理很適合用來處理必須對變動或峰值做出響應，並且關注一段時間內變化趨勢的數據。
Apache Storm
Apache Storm是一種側重於極低延遲的流處理框架，也許是要求近實時處理的工作負載的最佳選擇。該技術可處理非常大量的數據，通過比其他解決方案更低的延遲提供結果。
流處理模式
Storm的流處理可對框架中名為Topology（拓撲）的DAG（Directed Acyclic Graph，有向無環圖）進行編排。這些拓撲描述了當數據片段進入系統後，需要對每個傳入的片段執行的不同轉換或步驟。
拓撲包含：
· Stream：普通的數據流，這是一種會持續抵達系統的無邊界數據。
· Spout：位於拓撲邊緣的數據流來源，例如可以是API或查詢等，從這里可以產生待處理的數據。
· Bolt：Bolt代表需要消耗流數據，對其應用操作，並將結果以流的形式進行輸出的處理步驟。Bolt需要與每個Spout建立連接，隨後相互連接以組成所有必要的處理。在拓撲的尾部，可以使用最終的Bolt輸出作為相互連接的其他系統的輸入。
Storm背後的想法是使用上述組件定義大量小型的離散操作，隨後將多個組件組成所需拓撲。默認情況下Storm提供了「至少一次」的處理保證，這意味著可以確保每條消息至少可以被處理一次，但某些情況下如果遇到失敗可能會處理多次。Storm無法確保可以按照特定順序處理消息。
為了實現嚴格的一次處理，即有狀態處理，可以使用一種名為Trident的抽象。嚴格來說不使用Trident的Storm通常可稱之為Core Storm。Trident會對Storm的處理能力產生極大影響，會增加延遲，為處理提供狀態，使用微批模式代替逐項處理的純粹流處理模式。
為避免這些問題，通常建議Storm用戶盡可能使用Core Storm。然而也要注意，Trident對內容嚴格的一次處理保證在某些情況下也比較有用，例如系統無法智能地處理重復消息時。如果需要在項之間維持狀態，例如想要計算一個小時內有多少用戶點擊了某個鏈接，此時Trident將是你唯一的選擇。盡管不能充分發揮框架與生俱來的優勢，但Trident提高了Storm的靈活性。
Trident拓撲包含：
· 流批（Stream batch）：這是指流數據的微批，可通過分塊提供批處理語義。
· 操作（Operation）：是指可以對數據執行的批處理過程。
優勢和局限
目前來說Storm可能是近實時處理領域的最佳解決方案。該技術可以用極低延遲處理數據，可用於希望獲得最低延遲的工作負載。如果處理速度直接影響用戶體驗，例如需要將處理結果直接提供給訪客打開的網站頁面，此時Storm將會是一個很好的選擇。
Storm與Trident配合使得用戶可以用微批代替純粹的流處理。雖然藉此用戶可以獲得更大靈活性打造更符合要求的工具，但同時這種做法會削弱該技術相比其他解決方案最大的優勢。話雖如此，但多一種流處理方式總是好的。
Core Storm無法保證消息的處理順序。Core Storm為消息提供了「至少一次」的處理保證，這意味著可以保證每條消息都能被處理，但也可能發生重復。Trident提供了嚴格的一次處理保證，可以在不同批之間提供順序處理，但無法在一個批內部實現順序處理。
在互操作性方面，Storm可與Hadoop的YARN資源管理器進行集成，因此可以很方便地融入現有Hadoop部署。除了支持大部分處理框架，Storm還可支持多種語言，為用戶的拓撲定義提供了更多選擇。
總結
對於延遲需求很高的純粹的流處理工作負載，Storm可能是最適合的技術。該技術可以保證每條消息都被處理，可配合多種編程語言使用。由於Storm無法進行批處理，如果需要這些能力可能還需要使用其他軟體。如果對嚴格的一次處理保證有比較高的要求，此時可考慮使用Trident。不過這種情況下其他流處理框架也許更適合。
Apache Samza
Apache Samza是一種與Apache Kafka消息系統緊密綁定的流處理框架。雖然Kafka可用於很多流處理系統，但按照設計，Samza可以更好地發揮Kafka獨特的架構優勢和保障。該技術可通過Kafka提供容錯、緩沖，以及狀態存儲。
Samza可使用YARN作為資源管理器。這意味著默認情況下需要具備Hadoop集群（至少具備HDFS和YARN），但同時也意味著Samza可以直接使用YARN豐富的內建功能。
流處理模式
Samza依賴Kafka的語義定義流的處理方式。Kafka在處理數據時涉及下列概念：
· Topic（話題）：進入Kafka系統的每個數據流可稱之為一個話題。話題基本上是一種可供消耗方訂閱的，由相關信息組成的數據流。
· Partition（分區）：為了將一個話題分散至多個節點，Kafka會將傳入的消息劃分為多個分區。分區的劃分將基於鍵（Key）進行，這樣可以保證包含同一個鍵的每條消息可以劃分至同一個分區。分區的順序可獲得保證。
· Broker（代理）：組成Kafka集群的每個節點也叫做代理。
· Procer（生成方）：任何向Kafka話題寫入數據的組件可以叫做生成方。生成方可提供將話題劃分為分區所需的鍵。
· Consumer（消耗方）：任何從Kafka讀取話題的組件可叫做消耗方。消耗方需要負責維持有關自己分支的信息，這樣即可在失敗後知道哪些記錄已經被處理過了。
由於Kafka相當於永恆不變的日誌，Samza也需要處理永恆不變的數據流。這意味著任何轉換創建的新數據流都可被其他組件所使用，而不會對最初的數據流產生影響。
優勢和局限
乍看之下，Samza對Kafka類查詢系統的依賴似乎是一種限制，然而這也可以為系統提供一些獨特的保證和功能，這些內容也是其他流處理系統不具備的。
例如Kafka已經提供了可以通過低延遲方式訪問的數據存儲副本，此外還可以為每個數據分區提供非常易用且低成本的多訂閱者模型。所有輸出內容，包括中間態的結果都可寫入到Kafka，並可被下游步驟獨立使用。
這種對Kafka的緊密依賴在很多方面類似於MapRece引擎對HDFS的依賴。雖然在批處理的每個計算之間對HDFS的依賴導致了一些嚴重的性能問題，但也避免了流處理遇到的很多其他問題。
Samza與Kafka之間緊密的關系使得處理步驟本身可以非常鬆散地耦合在一起。無需事先協調，即可在輸出的任何步驟中增加任意數量的訂閱者，對於有多個團隊需要訪問類似數據的組織，這一特性非常有用。多個團隊可以全部訂閱進入系統的數據話題，或任意訂閱其他團隊對數據進行過某些處理後創建的話題。這一切並不會對資料庫等負載密集型基礎架構造成額外的壓力。
直接寫入Kafka還可避免回壓（Backpressure）問題。回壓是指當負載峰值導致數據流入速度超過組件實時處理能力的情況，這種情況可能導致處理工作停頓並可能丟失數據。按照設計，Kafka可以將數據保存很長時間，這意味著組件可以在方便的時候繼續進行處理，並可直接重啟動而無需擔心造成任何後果。
Samza可以使用以本地鍵值存儲方式實現的容錯檢查點系統存儲數據。這樣Samza即可獲得「至少一次」的交付保障，但面對由於數據可能多次交付造成的失敗，該技術無法對匯總後狀態（例如計數）提供精確恢復。
Samza提供的高級抽象使其在很多方面比Storm等系統提供的基元（Primitive）更易於配合使用。目前Samza只支持JVM語言，這意味著它在語言支持方面不如Storm靈活。
總結
對於已經具備或易於實現Hadoop和Kafka的環境，Apache Samza是流處理工作負載一個很好的選擇。Samza本身很適合有多個團隊需要使用（但相互之間並不一定緊密協調）不同處理階段的多個數據流的組織。Samza可大幅簡化很多流處理工作，可實現低延遲的性能。如果部署需求與當前系統不兼容，也許並不適合使用，但如果需要極低延遲的處理，或對嚴格的一次處理語義有較高需求，此時依然適合考慮。
混合處理系統：批處理和流處理
一些處理框架可同時處理批處理和流處理工作負載。這些框架可以用相同或相關的組件和API處理兩種類型的數據，藉此讓不同的處理需求得以簡化。
如你所見，這一特性主要是由Spark和Flink實現的，下文將介紹這兩種框架。實現這樣的功能重點在於兩種不同處理模式如何進行統一，以及要對固定和不固定數據集之間的關系進行何種假設。
雖然側重於某一種處理類型的項目會更好地滿足具體用例的要求，但混合框架意在提供一種數據處理的通用解決方案。這種框架不僅可以提供處理數據所需的方法，而且提供了自己的集成項、庫、工具，可勝任圖形分析、機器學習、互動式查詢等多種任務。
Apache Spark
Apache Spark是一種包含流處理能力的下一代批處理框架。與Hadoop的MapRece引擎基於各種相同原則開發而來的Spark主要側重於通過完善的內存計算和處理優化機制加快批處理工作負載的運行速度。
Spark可作為獨立集群部署（需要相應存儲層的配合），或可與Hadoop集成並取代MapRece引擎。
批處理模式
與MapRece不同，Spark的數據處理工作全部在內存中進行，只在一開始將數據讀入內存，以及將最終結果持久存儲時需要與存儲層交互。所有中間態的處理結果均存儲在內存中。
雖然內存中處理方式可大幅改善性能，Spark在處理與磁碟有關的任務時速度也有很大提升，因為通過提前對整個任務集進行分析可以實現更完善的整體式優化。為此Spark可創建代表所需執行的全部操作，需要操作的數據，以及操作和數據之間關系的Directed Acyclic Graph（有向無環圖），即DAG，藉此處理器可以對任務進行更智能的協調。
為了實現內存中批計算，Spark會使用一種名為Resilient Distributed Dataset（彈性分布式數據集），即RDD的模型來處理數據。這是一種代表數據集，只位於內存中，永恆不變的結構。針對RDD執行的操作可生成新的RDD。每個RDD可通過世系（Lineage）回溯至父級RDD，並最終回溯至磁碟上的數據。Spark可通過RDD在無需將每個操作的結果寫回磁碟的前提下實現容錯。
流處理模式
流處理能力是由Spark Streaming實現的。Spark本身在設計上主要面向批處理工作負載，為了彌補引擎設計和流處理工作負載特徵方面的差異，Spark實現了一種叫做微批（Micro-batch）*的概念。在具體策略方面該技術可以將數據流視作一系列非常小的「批」，藉此即可通過批處理引擎的原生語義進行處理。
Spark Streaming會以亞秒級增量對流進行緩沖，隨後這些緩沖會作為小規模的固定數據集進行批處理。這種方式的實際效果非常好，但相比真正的流處理框架在性能方面依然存在不足。
優勢和局限
使用Spark而非Hadoop MapRece的主要原因是速度。在內存計算策略和先進的DAG調度等機制的幫助下，Spark可以用更快速度處理相同的數據集。
Spark的另一個重要優勢在於多樣性。該產品可作為獨立集群部署，或與現有Hadoop集群集成。該產品可運行批處理和流處理，運行一個集群即可處理不同類型的任務。
除了引擎自身的能力外，圍繞Spark還建立了包含各種庫的生態系統，可為機器學習、互動式查詢等任務提供更好的支持。相比MapRece，Spark任務更是「眾所周知」地易於編寫，因此可大幅提高生產力。
為流處理系統採用批處理的方法，需要對進入系統的數據進行緩沖。緩沖機制使得該技術可以處理非常大量的傳入數據，提高整體吞吐率，但等待緩沖區清空也會導致延遲增高。這意味著Spark Streaming可能不適合處理對延遲有較高要求的工作負載。
由於內存通常比磁碟空間更貴，因此相比基於磁碟的系統，Spark成本更高。然而處理速度的提升意味著可以更快速完成任務，在需要按照小時數為資源付費的環境中，這一特性通常可以抵消增加的成本。
Spark內存計算這一設計的另一個後果是，如果部署在共享的集群中可能會遇到資源不足的問題。相比HadoopMapRece，Spark的資源消耗更大，可能會對需要在同一時間使用集群的其他任務產生影響。從本質來看，Spark更不適合與Hadoop堆棧的其他組件共存一處。
總結
Spark是多樣化工作負載處理任務的最佳選擇。Spark批處理能力以更高內存佔用為代價提供了無與倫比的速度優勢。對於重視吞吐率而非延遲的工作負載，則比較適合使用Spark Streaming作為流處理解決方案。
Apache Flink
Apache Flink是一種可以處理批處理任務的流處理框架。該技術可將批處理數據視作具備有限邊界的數據流，藉此將批處理任務作為流處理的子集加以處理。為所有處理任務採取流處理為先的方法會產生一系列有趣的副作用。
這種流處理為先的方法也叫做Kappa架構，與之相對的是更加被廣為人知的Lambda架構（該架構中使用批處理作為主要處理方法，使用流作為補充並提供早期未經提煉的結果）。Kappa架構中會對一切進行流處理，藉此對模型進行簡化，而這一切是在最近流處理引擎逐漸成熟後才可行的。
流處理模型
Flink的流處理模型在處理傳入數據時會將每一項視作真正的數據流。Flink提供的DataStream API可用於處理無盡的數據流。Flink可配合使用的基本組件包括：
· Stream（流）是指在系統中流轉的，永恆不變的無邊界數據集
· Operator（操作方）是指針對數據流執行操作以產生其他數據流的功能
· Source（源）是指數據流進入系統的入口點
· Sink（槽）是指數據流離開Flink系統後進入到的位置，槽可以是資料庫或到其他系統的連接器
為了在計算過程中遇到問題後能夠恢復，流處理任務會在預定時間點創建快照。為了實現狀態存儲，Flink可配合多種狀態後端系統使用，具體取決於所需實現的復雜度和持久性級別。
此外Flink的流處理能力還可以理解「事件時間」這一概念，這是指事件實際發生的時間，此外該功能還可以處理會話。這意味著可以通過某種有趣的方式確保執行順序和分組。
批處理模型
Flink的批處理模型在很大程度上僅僅是對流處理模型的擴展。此時模型不再從持續流中讀取數據，而是從持久存儲中以流的形式讀取有邊界的數據集。Flink會對這些處理模型使用完全相同的運行時。
Flink可以對批處理工作負載實現一定的優化。例如由於批處理操作可通過持久存儲加以支持，Flink可以不對批處理工作負載創建快照。數據依然可以恢復，但常規處理操作可以執行得更快。
另一個優化是對批處理任務進行分解，這樣即可在需要的時候調用不同階段和組件。藉此Flink可以與集群的其他用戶更好地共存。對任務提前進行分析使得Flink可以查看需要執行的所有操作、數據集的大小，以及下游需要執行的操作步驟，藉此實現進一步的優化。
優勢和局限
Flink目前是處理框架領域一個獨特的技術。雖然Spark也可以執行批處理和流處理，但Spark的流處理採取的微批架構使其無法適用於很多用例。Flink流處理為先的方法可提供低延遲，高吞吐率，近乎逐項處理的能力。
Flink的很多組件是自行管理的。雖然這種做法較為罕見，但出於性能方面的原因，該技術可自行管理內存，無需依賴原生的Java垃圾回收機制。與Spark不同，待處理數據的特徵發生變化後Flink無需手工優化和調整，並且該技術也可以自行處理數據分區和自動緩存等操作。
Flink會通過多種方式對工作進行分許進而優化任務。這種分析在部分程度上類似於SQL查詢規劃器對關系型資料庫所做的優化，可針對特定任務確定最高效的實現方法。該技術還支持多階段並行執行，同時可將受阻任務的數據集合在一起。對於迭代式任務，出於性能方面的考慮，Flink會嘗試在存儲數據的節點上執行相應的計算任務。此外還可進行「增量迭代」，或僅對數據中有改動的部分進行迭代。
在用戶工具方面，Flink提供了基於Web的調度視圖，藉此可輕松管理任務並查看系統狀態。用戶也可以查看已提交任務的優化方案，藉此了解任務最終是如何在集群中實現的。對於分析類任務，Flink提供了類似SQL的查詢，圖形化處理，以及機器學習庫，此外還支持內存計算。
Flink能很好地與其他組件配合使用。如果配合Hadoop 堆棧使用，該技術可以很好地融入整個環境，在任何時候都只佔用必要的資源。該技術可輕松地與YARN、HDFS和Kafka 集成。在兼容包的幫助下，Flink還可以運行為其他處理框架，例如Hadoop和Storm編寫的任務。
目前Flink最大的局限之一在於這依然是一個非常「年幼」的項目。現實環境中該項目的大規模部署尚不如其他處理框架那麼常見，對於Flink在縮放能力方面的局限目前也沒有較為深入的研究。隨著快速開發周期的推進和兼容包等功能的完善，當越來越多的組織開始嘗試時，可能會出現越來越多的Flink部署
總結
Flink提供了低延遲流處理，同時可支持傳統的批處理任務。Flink也許最適合有極高流處理需求，並有少量批處理任務的組織。該技術可兼容原生Storm和Hadoop程序，可在YARN管理的集群上運行，因此可以很方便地進行評估。快速進展的開發工作使其值得被大家關注。
結論
大數據系統可使用多種處理技術。
對於僅需要批處理的工作負載，如果對時間不敏感，比其他解決方案實現成本更低的Hadoop將會是一個好選擇。
對於僅需要流處理的工作負載，Storm可支持更廣泛的語言並實現極低延遲的處理，但默認配置可能產生重復結果並且無法保證順序。Samza與YARN和Kafka緊密集成可提供更大靈活性，更易用的多團隊使用，以及更簡單的復制和狀態管理。
對於混合型工作負載，Spark可提供高速批處理和微批處理模式的流處理。該技術的支持更完善，具備各種集成庫和工具，可實現靈活的集成。Flink提供了真正的流處理並具備批處理能力，通過深度優化可運行針對其他平台編寫的任務，提供低延遲的處理，但實際應用方面還為時過早。
最適合的解決方案主要取決於待處理數據的狀態，對處理所需時間的需求，以及希望得到的結果。具體是使用全功能解決方案或主要側重於某種項目的解決方案，這個問題需要慎重權衡。隨著逐漸成熟並被廣泛接受，在評估任何新出現的創新型解決方案時都需要考慮類似的問題。
『叄』 大數據處理必備的十大工具！
大數據的日益增長,給企業管理大量的數據帶來了挑戰的同時也帶來了一些機遇。下面是用於信息化管理的大數據工具列表：
1.ApacheHive
Hive是一個建立在hadoop上的開源數據倉庫基礎設施，通過Hive可以很容易的進行數據的ETL,對數據進行結構化處理,並對Hadoop上大數據文件進行查詢和處理等。Hive提供了一種簡單的類似SQL的查詢語言—HiveQL,這為熟悉SQL語言的用戶查詢數據提供了方便。
2JaspersoftBI套件
Jaspersoft包是一個通過資料庫列生成報表的開源軟體。行業領導者發現Jaspersoft軟體是一流的,許多企業已經使用它來將SQL表轉化為pdf,，這使每個人都可以在會議上對其進行審議。另外，JasperReports提供了一個連接配置單元來替代HBase。
3.1010data
1010data創立於2000年，是一個總部設在紐約的分析型雲服務，旨在為華爾街的客戶提供服務，甚至包括NYSEEuronext、 游戲 和電信的客戶。它在設計上支持可伸縮性的大規模並行處理。它也有它自己的查詢語言,支持SQL函數和廣泛的查詢類型，包括圖和時間序列分析。這個私有雲的方法減少了客戶在基礎設施管理和擴展方面的壓力。
4.Actian
Actian之前的名字叫做IngresCorp，它擁有超過一萬客戶而且正在擴增。它通過Vectorwise以及對ParAccel實現了擴展。這些發展分別導致了ActianVector和ActianMatrix的創建。它有Apache，Cloudera，Hortonworks以及其他發行版本可供選擇。
5.PentahoBusinessAnalytics
從某種意義上說,Pentaho與Jaspersoft相比起來,盡管Pentaho開始於報告生成引擎，但它目前通過簡化新來源中獲取信息的過程來支持大數據處理。Pentaho的工具可以連接到NoSQL資料庫，例如MongoDB和Cassandra。PeterWayner指出,PentahoData(一個更有趣的圖形編程界面工具)有很多內置模塊，你可以把它們拖放到一個圖片上,然後將它們連接起來。
6.KarmasphereStudioandAnalyst
KarsmasphereStudio是一組構建在Eclipse上的插件,它是一個更易於創建和運行Hadoop任務的專用IDE。在配置一個Hadoop工作時，Karmasphere工具將引導您完成每個步驟並顯示部分結果。當出現所有數據處於同一個Hadoop集群的情況時，KarmaspehereAnalyst旨在簡化篩選的過程,。
7.Cloudera
Cloudera正在努力為開源Hadoop,提供支持，同時將數據處理框架延伸到一個全面的「企業數據中心」范疇,這個數據中心可以作為首選目標和管理企業所有數據的中心點。Hadoop可以作為目標數據倉庫，高效的數據平台，或現有數據倉庫的ETL來源。企業規模可以用作集成Hadoop與傳統數據倉庫的基礎。Cloudera致力於成為數據管理的「重心」。
8.
HP提供了用於載入Hadoop軟體發行版所需的參考硬體配置,因為它本身並沒有自己的Hadoop版本。計算機行業領袖將其大數據平台架構命名為HAVEn(意為Hadoop,Autonomy,Vertica,EnterpriseSecurityand「n」applications)。惠普在Vertica7版本中增加了一個「FlexZone」，允許用戶在定義資料庫方案以及相關分析、報告之前 探索 大型數據集中的數據。這個版本通過使用HCatalog作為元數據存儲，與Hadoop集成後為用戶提供了一種 探索 HDFS數據表格視圖的方法。
9.TalendOpenStudio
Talend』s工具用於協助進行數據質量、數據集成和數據管理等方面工作。Talend是一個統一的平台，它通過提供一個統一的，跨企業邊界生命周期管理的環境，使數據管理和應用更簡單便捷。這種設計可以幫助企業構建靈活、高性能的企業架構,在次架構下，集成並啟用百分之百開源服務的分布式應用程序變為可能。
10.ApacheSpark
ApacheSpark是Hadoop開源生態系統的新成員。它提供了一個比Hive更快的查詢引擎，因為它依賴於自己的數據處理框架而不是依靠Hadoop的HDFS服務。同時，它還用於事件流處理、實時查詢和機器學習等方面。
『肆』 Python幾種主流框架比較
從GitHub中整理出的15個最受歡迎的Python開源框架。這些框架包括事件I/O，OLAP，Web開發，高性能網路通信，測試，爬蟲等。x0dx0ax0dx0aDjango: Python Web應用開發框架x0dx0a Django 應該是最出名的Python框架，GAE甚至Erlang都有框架受它影響。Django是走大而全的方向，它最出名的是其全自動化的管理後台：只需要使用起ORM，做簡單的對象定義，它就能自動生成資料庫結構、以及全功能的管理後台。x0dx0ax0dx0aDiesel：基於Greenlet的事件I/O框架x0dx0a Diesel提供一個整潔的API來編寫網路客戶端和伺服器。支持TCP和UDP。x0dx0ax0dx0aFlask：一個用Python編寫的輕量級Web應用框架x0dx0a Flask是一個使用Python編寫的輕量級Web應用框架。基於Werkzeug WSGI工具箱和Jinja2 x0dx0a模板引擎。Flask也被稱為「microframework」，因為它使用簡單的核心，用extension增加其他功能。Flask沒有默認使用的數x0dx0a據庫、窗體驗證工具。x0dx0ax0dx0aCubes：輕量級Python OLAP框架x0dx0a Cubes是一個輕量級Python框架，包含OLAP、多維數據分析和瀏覽聚合數據（aggregated data）等工具。x0dx0ax0dx0aKartograph.py：創造矢量地圖的輕量級Python框架x0dx0a Kartograph是一個Python庫，用來為ESRI生成SVG地圖。Kartograph.py目前仍處於beta階段，你可以在virtualenv環境下來測試。x0dx0ax0dx0aPulsar：Python的事件驅動並發框架x0dx0a Pulsar是一個事件驅動的並發框架，有了pulsar，你可以寫出在不同進程或線程中運行一個或多個活動的非同步伺服器。x0dx0ax0dx0aWeb2py：全棧式Web框架x0dx0a Web2py是一個為Python語言提供的全功能Web應用框架，旨在敏捷快速的開發Web應用，具有快速、安全以及可移植的資料庫驅動的應用，兼容Google App Engine。x0dx0ax0dx0aFalcon：構建雲API和網路應用後端的高性能Python框架x0dx0a Falcon是一個構建雲API的高性能Python框架，它鼓勵使用REST架構風格，盡可能以最少的力氣做最多的事情。x0dx0ax0dx0aDpark：Python版的Sparkx0dx0a DPark是Spark的Python克隆，是一個Python實現的分布式計算框架，可以非常方便地實現大規模數據處理和迭代計算。DPark由豆瓣實現，目前豆瓣內部的絕大多數數據分析都使用DPark完成，正日趨完善。x0dx0ax0dx0aBuildbot：基於Python的持續集成測試框架x0dx0a Buildbot是一個開源框架，可以自動化軟體構建、測試和發布等過程。每當代碼有改變，伺服器要求不同平台上的客戶端立即進行代碼構建和測試，收集並報告不同平台的構建和測試結果。x0dx0ax0dx0aZerorpc：基於ZeroMQ的高性能分布式RPC框架x0dx0a Zerorpc是一個基於ZeroMQ和MessagePack開發的遠程過程調用協議（RPC）實現。和 Zerorpc 一起使用的 Service API 被稱為 zeroservice。Zerorpc 可以通過編程或命令行方式調用。x0dx0ax0dx0aBottle: 微型Python Web框架x0dx0a Bottle是一個簡單高效的遵循WSGI的微型python Web框架。說微型，是因為它只有一個文件，除Python標准庫外，它不依賴於任何第三方模塊。x0dx0ax0dx0aTornado：非同步非阻塞IO的Python Web框架x0dx0a Tornado的全稱是Torado Web Server，從名字上看就可知道它可以用作Web伺服器，但同時它也是一個Python Web的開發框架。最初是在FriendFeed公司的網站上使用，FaceBook收購了之後便開源了出來。x0dx0ax0dx0awebpy: 輕量級的Python Web框架x0dx0a webpy的設計理念力求精簡（Keep it simple and powerful），源碼很簡短，只提供一個框架所必須的東西，不依賴大量的第三方模塊，它沒有URL路由、沒有模板也沒有資料庫的訪問。x0dx0ax0dx0aScrapy：Python的爬蟲框架x0dx0a Scrapy是一個使用Python編寫的，輕量級的，簡單輕巧，並且使用起來非常的方便。
『伍』 PHP或者python進行數據採集和分析，有什麼比較成熟的框架
Python：
1.requests 很好用的http庫，中文文檔：Requests: 讓 HTTP 服務人類
2.BeautifulSoup 很好用很強大的html解析庫，中文文檔：Beautiful Soup 4.4.0 文檔
3.Scrapy 知名爬蟲框架，中文文檔：Scrapy 0.25 文檔
『陸』 數據處理框架分類都有哪些
就目前而言，不管是系統中的歷史數據，還是持續不斷接入系統中的實時數據，只要數據是可訪問的，我們就能夠處理這些數據。按照處理的數據形式和得到結果的時效性進行分類，數據處理框架就可以分為兩類：批處理系統和流處理系統。
數據處理框架中的批處理就是一種用來計算大規模數據集的方法。批處理的過程包括將任務分解為較小的任務，分別在每個計算機上進行計算運行，根據數據分析的結果對數據的重新組合，然後通過計算機的計算出組合數據的最終結果。當處理非常巨大的數據集時，批處理系統是最有效的。而流處理就是對由連續不斷的單條數據項組成的數據流進行計算，注重數據處理結果的時效性。
一、批處理系統
批處理系統在大數據中有很長的歷史。批處理系統主要操作大量靜態的數據，並且等到全部處理完成後才能得到返回的結果。批處理系統中的數據集一般符合以下特徵：
1、有限： 數據集中的數據必須是有限的。
2、持久： 批處理系統處理的數據一般存儲在某個儲存器上。
3、海量： 一般來說只有海量的數據才能用批處理系統進行分析，並且海量的數據通常只能使用批處理系統來處理。
由於批處理系統在處理海量的持久數據方面表現出色，而歷史數據的數量是很多的，所以它通常被用來處理歷史數據，但是由於海量數據的處理需要耗費很多時間，所以批處理系統一般不用於即時性場景需求以及對延時要求較高的場景。
二、流處理系統
批處理系統好理解，那什麼是流處理系統呢？流處理系統與批處理系統所處理的數據不同之處在於，流處理系統並不是針對已經存在的數據集進行操作，而是處理對從外部系統接入的的數據。流處理系統一般分為兩種：
1、逐項處理： 每次處理一條數據，是真正意義上的流處理。
2、微批處理： 這種處理方式把一小段時間內的數據當作一個微批次，對這個微批次內的數據進行處理。
不論是哪種處理方式，其實時性都要遠遠好於批處理系統。因此，流處理系統非常適合應用於對實時性要求較高的場景，由於很多情況下，我們想要盡快看到計算結果，所以近些年流處理系統的應用越來越廣泛。
相信大家看了這篇文章以後已經知道了數據處理框架上面的相關情況了吧，一般來說，數據的處理里不來批處理和流處理，批處理適用於歷史數據的分析，而流處理適用於即時數據的分析，兩者都有各自的優缺點。希望本文能夠幫到大家。
『柒』 教育大數據的技術體系框架
一般而言，大數據的處理流程包括數據採集、數據處理、數據分析與應用服務四個環節。
從下往上依次是：教育數據採集層、教育數據處理層、教育數據分析與展現層和教育數據應用服務層——通過數據傳輸介面，數據採集層將採集到的各類教育數據傳遞給數據處理層，並通過數據整合、存儲形成教育數據平台；基於該教育數據平台，分析與展現層可實現教育數據的可視化展現和大數據的分析與挖掘，並將分析結果通過數據介面傳遞給應用服務層。
安全與監控貫穿整個流程，以保證教育數據各個環節的安全性和可控性；標准與規范則是整個框架的基礎，以保障各個環節之間以及整個系統教育數據的融通與共享。
各個環節的主要任務及其涉及的關鍵技術如下：
1、教育數據採集
數據採集涉及的關鍵技術包括：數據源的選擇和高質量原始數據的採集方法，多源數據的實體識別和解析方法，數據清洗和自動修復方法，數據演化的溯源管理，數據載入、流計算、信息傳輸技術等。
2、教育數據處理
教育數據處理環節包含 數據整合和數據存儲 。其中，數據整合是指通過高質量的數據整合方法，對數據進行加工處理，並在盡可能保留原有語義的情況下去粗取精、消除雜訊，從全局的角度保證數據的一致性和相關性；數據存儲是所有數據的集中存放地，主要用來存放各種結構化、半結構化和非結構化的歷史數據、預測數據、匯總數據以及需要共享的數據等。
3、教育數據分析與展現
（1）教育數據挖掘
教育數據挖掘是一個將來自各教育系統的原始數據轉換為有用信息的過程，這些有用信息可為教師、學生、家長、教育研究人員以及教育軟體系統開發人員所利用。
（2）學習分析
學習分析是指通過測量、收集、分析、匯報學習者和他們所處環境的數據，用以理解和優化學習以及學習發生的環境。
目前，學習分析領域常用的分析方法包括網路分析法、話語分析法和內容分析法。
4、教育數據應用服務
通過對教育大數據的分析，可以輔助教師更好地調整和改進教學策略，重構教學計劃，完善課程的設計與開發；向學生推薦個性化的學習資源、學習任務、學習活動和學習路徑；幫助家長更加全面、真實地認識孩子，與學校一起促進孩子的個性化成長；幫助教育管理者進行更科學的管理決策；幫助社會公眾把握教育的發展現狀，享受更具針對性、更適合自己的終身學習服務。
後續深入介紹。
參考文獻
教育大數據的技術體系框架與發展趨勢——「教育大數據研究與實踐專欄」之整體框架篇 楊現民
『捌』 單片機串口數據處理框架
串口通信具有廣泛的應用，一方面串口配置簡單，僅需3根線（tx、rx、gnd）即可實現通信，另一方面串口具備全雙工通信的能力。因此串口開發是單片機開發中一個重要的能力。
串口通信的難點在於，每條通信命令的長度可能不一致，何時判斷數據包是否接收完整，每包數據如何校驗，在單片機開發中均佔用很大的工作量。
由於單片機往往同時對接多個串口通信，可以將所有的通信統一處理，收到一包數據後再通知相應的線程進行處理。
writeptr 和 readptr 分別記錄串口緩沖區內數據寫入和讀取的指針（標號）。一般將緩沖區構建為環形緩沖， *writeptr==*readptr 認為緩沖區空， *writeptr==*readptr + 1 認為緩沖區滿。 ctrl 欄位用來控制是否開始計時數據接收超時，在超時時間內沒接收到一個位元組的數據，重新累計數據包超時時間， timeout 欄位則是具體的超時時間。 discart 欄位用來丟棄不完整的數據包，如果數據包在規定的時間內均沒有收到完整數據，則將該數據包丟棄。
系統初始化時，對每個欄位進行賦值：
串口數據的接收既可以採用中斷的方式，也可以採用DMA的方式。盡管中斷方式會影響CPU使用效率，但從實際使用效果上來看，一般不是時間要求非常高的應用，中斷的影響非常小。
每收到一包數據，將 timeout 置零，並將 ctrl 置一，開始計算數據包是否超時。由於緩沖區是環形的， UartCtrl[UART_VIDEO].writeptr 欄位增加時需要注意對邊界的處理。
通過定時器中不斷檢測相應的欄位，來決定是否通知線程處理收到的數據包，或者丟棄不完整的數據包。
串口數據包往往具有比較簡單數據結構，如包頭、包尾、長度、校驗等欄位，通過對每包數據相應欄位的檢驗，判斷數據包是否完整及合法。不同的感測器的通信格式一般都比較類似，因此可以採用以下的流程進行檢驗。最後既可以將合格的數據包復制到另外的緩存進行處理，也可以在該函數中直接處理以節省空間。
處理完一包數據以後，若發現剩餘長度大於0，認為環形緩存中還有待處理的數據包，重新進入該函數進行處理。
串口數據的處理在單片機開發中佔有很大比重的工作量，通過上述數據結構和相應處理函數，可以將不同的感測器的數據用同樣的方式處理，有效提高開發效率。其他匯流排的數據處理，也可以採用類似的方式進行。