大數據實踐基礎架構先行

① 五種大數據處理架構

五種大數據處理架構
大數據是收集、整理、處理大容量數據集，並從中獲得見解所需的非傳統戰略和技術的總稱。雖然處理數據所需的計算能力或存儲容量早已超過一台計算機的上限，但這種計算類型的普遍性、規模，以及價值在最近幾年才經歷了大規模擴展。
本文將介紹大數據系統一個最基本的組件：處理框架。處理框架負責對系統中的數據進行計算，例如處理從非易失存儲中讀取的數據，或處理剛剛攝入到系統中的數據。數據的計算則是指從大量單一數據點中提取信息和見解的過程。
下文將介紹這些框架：
· 僅批處理框架：
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提供了真正的流處理並具備批處理能力，通過深度優化可運行針對其他平台編寫的任務，提供低延遲的處理，但實際應用方面還為時過早。
最適合的解決方案主要取決於待處理數據的狀態，對處理所需時間的需求，以及希望得到的結果。具體是使用全功能解決方案或主要側重於某種項目的解決方案，這個問題需要慎重權衡。隨著逐漸成熟並被廣泛接受，在評估任何新出現的創新型解決方案時都需要考慮類似的問題。

② 如何正確建立大數據結構

大數據各行各業的企業都提供了潛力。正確使用這些大數據信息可能將增加商業價值，幫助您的企業從市場競爭中脫穎而出。如下是幾個企業成功應用大數據的案例： 大數據的例子 汽車製造商已經開始使用大數據來了解汽車何時需要返回到車庫進行維修。使用汽車發動機的數百個感測器，可以為汽車製造商發送實時的數據信息，這使得製造商甚至比駕駛汽車的司機還要提前知道汽車何時會出現故障。卡車製造商開始使用大數據，基於實時交通條件和客戶的需求來改進他們的路由，從而節約燃料和時間。 零售業也開始越來越多的使用大數據，鑒於越來越多的產品均有一個RFID標簽能幫助零售商跟蹤產品，知道很少某種產品庫存缺貨，並及時向供貨商訂購新產品。沃爾瑪便是這正確利用大數據這方面的一個很好的例子。當零售商開始識別他們的客戶時，就能夠更好地建立商店，更好的滿足客戶的需求。 當然，上述這些只是幾個淺顯的例子，大數據的可能性幾乎是無止境的。不久的將來，我們將討論在大數據平台上的最佳實踐。知道大數據能夠提供商業價值是一回事；而企業要知道如何創建正確的架構則又是另一回事了。 大數據結構 大數據有三個特徵，使得大數據不同於現有的數據倉庫和商業智能。大數據的這三大特點是： 數據量龐大：大數據的數據量相當龐大，更多的時候大數據的數據量可以達到比數TB到PB級位元組。 高速度傳遞：所有這些TB和PB位元組的數據能夠實時交付，數據倉庫每天都需要應付如此高速的數據流。

③ 企業應該如何在大數據基礎架構方面做出選擇

企業應該如何在大數據基礎架構方面做出選擇

如果詢問十家公司他們為了運行大數據負載需要使用怎樣的基礎架構，那麼可能會得到十種不同的答案。現在這個領域當中幾乎沒有可以遵循的原則，甚至沒有可以參考的最佳實踐。

不管是從資源還是從專業性方面來說，大數據分析已經成為基礎架構領域當中真正的難題。顧名思義，大數據分析工具所針對的數據集合，規模將會非常龐大，並且需要大量的計算、存儲和網路資源來滿足性能需求。但是這些大數據工具通常是由超大規模企業開發的，這些企業並不存在普通企業需要考慮的同等級安全問題和高可用性問題，而主流IT企業還沒有深入了解這些工具，再加上大數據在投資回報率方面的不確定性，導致只有非常少的企業願意在大數據方面進行投入。

此外，即便對於曾經在Hadoop、Spark和類似產品上運行過大數據集群的部分企業來說，也會在大數據基礎架構方面遇到技術和業務方面的挑戰。

大數據帶來大問題

一家大型遠程通訊提供商正在構建一種新的數字服務，預計在今年年底正式推出，並且准備使用Hadoop來分析這種服務所產生的內容、使用情況和收入（廣告服務）數據。但是由於這種服務是全新的，因此很難分析應該使用哪種大數據基礎架構，負責這個項目的技術副總裁表示。

「對於一個還沒有推出的項目來說，我們不可能進行任何容量規劃，」他說。

確實，現在很多大數據項目仍然處於初級階段。「大多數大數據項目的性質比我們想像的還要低，」 可擴展存儲基礎架構提供商Coho Data CTO Andrew Warfield表示。

即便企業還不是十分了解大數據技術，但這並不意味著企業不應該在大數據方面投入精力。「但是運行這種技術可能面臨著很大風險，提前認識到這點非常重要，」 Warfield說，他認為企業應該提前考慮基礎架構方面的因素。

對於這家遠程通訊提供商來說，他們將會採用一種漸進的方式，使用來自於BlueData Software的軟體在商用硬體環境當中運行大數據集群，這樣就能夠從現有的存儲系統上訪問數據了。

無處不在的數據

如果數據來自於雲，那麼當然可以直接在雲中進行分析；如果數據全部位於本地，那麼底層的基礎架構也應該位於本地。但是如果數據分散在不同位置，那麼無疑會使得基礎架構更加復雜。

遠程通訊提供商的服務將會同時使用來自於雲和本地的數據。對於任何大數據解決方案來說，考慮到合規性、節省時間和網路帶寬等因素，能夠同時支持兩種數據來源都是十分重要的。「同步生產環境當中的數據是一件非常困難的事情，」這位副總裁說，「我們希望將所有的實例全都指向一個單一數據源。」

此外，雖然數據科學家想要分析的信息是可用的，但是現在還不能進行使用，因為其位於大數據計算工具無法訪問的存儲基礎架構當中，Warfield說。一種解決方案是存儲硬體使用Hadoop Distributed File System或者RESTful API這樣的協議公開這些數據。

注意延遲

對於特性類型的大數據分析來說，將數據從存儲陣列移動到計算環境所花費的時間將會對性能造成嚴重影響。但是如果不將數據跨越整個網路移動到計算環境當中，而是將應用程序移動到數據附近以降低延遲，將會怎樣呢？

將計算環境移動到數據附近並不是一種全新的概念，但是現在出現了一種前所未有的實現方式：Docker。比如Coho Data和Intel通過合作證明了這種概念的有效性，在一個大型金融服務公司當中，使用Docker格式封裝計算節點，之後在上面直接運行Hadoop負載。

在存儲陣列上直接運行Docker容器，這樣做的意義在於直接對附近的數據進行分析，而不再需要跨網路移動數據，同時利用任何可用的計算資源。「相比於其他存儲平台來說，大數據平台的CPU使用率通常會很高，」 Warfield說。「更何況如果你將快閃記憶體加入其中，那麼問題就會變成『我該如何從這種資源當中獲得更多價值？』」

直接在存儲陣列當中運行容器化應用程序是一件非常有趣的事情，但是需要提前對負載進行認真評估，以確保其能夠很好地適應當前環境，為建築行業提供文檔管理服務的Signature Tech Studios公司副總裁Bubba Hines說。這種服務基於Amazon Web Services，使用來自於Zadara Storage的存儲服務。這家公司最近開始評估新的Zadara Container Service，其中容器化應用程序運行在存儲陣列上，可以直接訪問本地磁碟。根據Hines的想法，現在有幾種可能的使用情況：在存儲陣列上運行其災難恢復軟體的容器版本來持續監控用戶數據和工作方面的變化，更改或者驗證主要存儲數據。

但是如果使用Zadara Container Service處理全部數據將沒有什麼意義。Signature Tech Studio的系統正在按照計劃執行數據轉換，並且已經實現大規模容器化了。但是「我們可能不會將所有Docker容器移動到Zadara容器服務當中，因為從體積和規模方面考慮這樣做並沒有意義，」Hines說。「我們必須尋找能夠真正從降低延遲當中獲利的負載。」

以上是小編為大家分享的關於企業應該如何在大數據基礎架構方面做出選擇的相關內容，更多信息可以關注環球青藤分享更多干貨

④ 大數據平台有哪些架構

01

傳統大數據架構

以上的種種架構都圍繞海量數據處理為主，Unifield架構則將機器學習和數據處理揉為一體，在流處理層新增了機器學習層。

優點：

提供了一套數據分析和機器學習結合的架構方案，解決了機器學習如何與數據平台進行結合的問題。

缺點：

實施復雜度更高，對於機器學習架構來說，從軟體包到硬體部署都和數據分析平台有著非常大的差別，因此在實施過程中的難度系數更高。

適用場景：

有著大量數據需要分析，同時對機器學習方便又有著非常大的需求或者有規劃。

大數據時代各種技術日新月異，想要保持競爭力就必須得不斷地學習。寫這些文章的目的是希望能幫到一些人了解學習大數據相關知識 。加米穀大數據，大數據人才培養機構，喜歡的同學可關注下，每天花一點時間學習，長期積累總是會有收獲的。

⑤ 大數據使一個新時代應運而生

大數據使一個新時代應運而生
在「大數據」趨勢的驅動下，企業具有更大規模的收集和處理數據的能力，越來越廣泛的信息加速了各行各業決策的速率和准確率。而大數據的「大」，已成為存儲業界目前所面臨的嚴峻挑戰。據IDC預測，到2015年，大數據技術和服務市場將從2010年的32億美元增長到169億美元，年復合增長率（CAGR）達到39.4%，幾乎是整個信息和通信技術市場年復合增長率的七倍。快速的數據流轉，動態的數據體系，以及越來越多樣化的數據類型，面對如此海量的數據規模，盡管業界的專業人士不斷的推崇「大數據」，但其所帶來的復雜程度和處理難度，使得企業不得不去重新考慮存儲基礎架構的問題。
隨著企業不斷尋求通過各種方法創新並為客戶構建更好的解決方案，他們面臨的一個最大挑戰是，如何使真正對社會具有深遠意義以及可持續影響力的創新解決方案實現商業化。據 IDC 調查，到2014年，絕大部分數據將是非結構化數據。因此，在數據大爆炸或大數據的背景下，我們需要具備發揮非結構化數據巨大潛力的能力，以便生成新的可持續業務、從現有資產獲取經濟價值並提高用戶生產效率。
大數據洞察，基礎架構先行
大數據數量龐大，格式多樣化。大量數據和信息由家庭和辦公場所的各種設備生成。它的爆炸式增長已超出了傳統IT基礎架構的處理能力，給企業帶來嚴峻的數據管理問題。
IDC認為傳統的基礎架構不能滿足大數據需求和挑戰。支持大數據部署的架構必須可以動態調整，並具備以下主要特性：
按需提供的容量和可擴展性，使基礎架構能夠在必要時根據容量和性能擴展或縮減規模。
維持「始終在線」的環境以及防止計劃外停機的故障恢復能力。
內置數據管理，並且能夠在每個處理階段以及每個後處理常規運行階段管理數據保護、監管達標、處置和同化。
針對大數據的容量需求，存儲虛擬化是目前為止提高容量效率最重要最有效的解決方案，它為缺乏這些能力的現有存儲系統拓展了自動分層和精簡配置等存儲效率的工具。擁有了虛擬化存儲，便可以將來自內部、外部和多廠商存儲的結構化和非結構化數據的文件、內容和塊存儲等所有的數據類型，整合到一個單一的存儲平台上。當所有存儲資產成為一個單一的存儲資源池時，自動分層和精簡配置功能就可以擴大到整個存儲基礎設施，從而可以輕松實現容量回收和利用最大化，甚至達到重用現有資產以延長使用，顯著提高IT靈活性和容量效率，以滿足非結構化數據增長的需求。目前，藉助HUS中型企業可以在不影響性能的情況下能夠擴展系統容量達到近3PB，自動更正性能問題，通過動態虛擬控制器實現快速預配置。此外，通過VSP的虛擬化，大型企業可以創建接近四分之一EB容量的存儲池。
針對非結構化數據，傳統文件系統中有限的索引節點總數導致文件系統可以容納的文件、目錄或其它對象的最大數量受到限制。而HNAS和HCP使用基於對象的文件系統，這使它們能夠擴展到PB級，以及數十億的文件或對象。位於VSP或HUS頂部的HNAS和HCP網關可以充分利用模塊存儲的可擴展性，同時享受到通用管理平台Hitachi Command Suite帶來的好處。HNAS和HCP為大數據文件和內容構建起了相應的架構。
除了可擴展性，大數據必須能夠不受干擾地持續擴展並具有跨越不同時代技術的遷移能力。數據遷移必須保持在最小范圍，且在後台完成。大數據應該只需要復制一次便可以恢復可用性；通過版本控制來跟蹤變更，而不是為大數據發生的每一個變更備份整個大數據。大數據太大而無法整體備份。整個HDS的產品系列均可以實現數據的後台移動和分層，也可以增加VSP或HUS塊數據池、HNAS文件系統或HCP租戶的容量，並自動在新的容量中調整數據。舊的文件系統與塊數據存儲設備不支持動態擴展。為了使用新的存儲容量，這些舊系統中的數據不得不從舊的塊數據存儲或文件系統中重新載入到新的存儲容量中。
不論企業規模大小，信息過載都是長期以來難以解決的問題。企業需要高度集成的基礎架構堆棧，以便統一地對所有來源的大數據進行匯聚、訪問管理、分析和交付。這需要基礎架構能夠管理和理解信息。根據及時、相關、全面、准確的信息而非猜測來採取行動，企業也會因此贏得競爭優勢。反之，則會在浩瀚的信息中受制於繁雜的數據、拘泥不前。
三步走，輕松駕馭大數據

基於對雲計算和大數據的深入研究，HDS提出了三步雲戰略，即基礎架構雲、內容雲和信息雲。三步雲戰略基於企業現有的IT設施，為企業的所有數據提供單一的虛擬化平台。其中基礎架構雲目的為提供動態基礎架構，以實現支持所有數據的單一平台。而內容雲則基於這一單一平台，藉助智能工具，實現對所有類型數據的索引、搜索和發掘。讓數據可以更容易地被發現、共享並且重新利用，因而也會變得更有價值。在信息雲中，和大數據會更加關聯，讓各種信息分析工具和流程與底層基礎架構完美集成。連接不同的數據集，揭示其中的規律，以為企業用戶提供有價值的信息和商業洞察，幫助客戶應對在醫療、生命科學、能源研究、社會基礎設施等領域的挑戰。

⑥ 大數據基礎架構發展需考慮的重要因素

大數據基礎架構發展需考慮的重要因素
隨著IT行業持續地灌輸廉價存儲的優勢，企業較以往擁有者更多的數據，那麼在評估大數據基礎架構的過程中需要深入地調查哪些因素。本篇涉及到了在容量、延遲、訪問性、安全性和成本這些重要因素的評估。
大數據發展的驅動因素
除了存儲比以往更多的數據，我們所面臨的數據種類也變得更加繁雜。這些數據源包括互聯網事務交易、社交網路的活動、自動化感測器、移動設備以及科研儀器等。除了靜態的數據增長方面，事務交易也會保持一個固定的數據「增長速度」。例如飛速增長的社交信息所產生的大量交易事務和記錄。不過現有的不斷擴大數據集無法確保能夠為業務搜索出有價值的信息。
當今的信息是一項重要的生產因素
數據業已成為了一種生產資料，就如何資本、勞動力和原始材料那樣，而且也不限於某一行業內的特定應用。企業中所有部門都旨在整合比較越來越多的數據集合，致力於降低成本、提升品質、增強生產能力以及開發新產品。舉例來說，對於現場產品的直接數據分析有助於提升設計。又例如企業可以通過對用戶習慣的深入分析，比較整體市場的增長特性，大幅提升自己在競爭分析方面的能力。
存儲發展的必要性
大數據意味著數據的增長超過了其本身的基礎架構，這驅動著應對這些特殊挑戰的存儲、網路和計算系統進一步的發展。軟體應用需求最終推動了硬體功能的發展，同時在這種情況下，大數據分析的處理過程正在影響著數據存儲基礎架構的發展。這對於存儲和IT基礎架構企業而言是一項機遇。隨著結構化和非結構化數據集的持續增長，這類數據的分析方式也更為多樣化，當前的存儲系統設計難以應對大數據基礎架構所需。存儲供應商已經開始推出基於數據塊和基於文件的系統來應對許多這方面的需求。以下列出了一些大數據存儲基礎架構的特性，這些都是源自大數據的挑戰。
容量。「大」在很多時候可以理解為PB級別的數據，因此大數據基礎架構當然要能夠可以擴展。不過其同樣必須能夠簡易地完成擴展，以模塊化或陣列的方式為用戶直接增加容量，或者至少保持系統不會宕機。橫向擴展式存儲由於能夠滿足這種需求，變得十分流行。橫向擴展集群體系架構的特徵是由存儲節點構成，每個節點具備處理能力和可連接性，可以無縫地擴展，避免傳統系統可能產生的煙囪式存儲的問題。
大數據還意味著大量的文件。管理元數據文件系統的累計會降低可擴展性並影響性能，用傳統的NAS系統就會在這種情況下出現問題。基於對象的存儲體系架構則通過另一種方式，支持在大數據存儲系統中擴展至十億級別的文件數量，而不會產生傳統文件系統中會遇到的負載問題。基於對象的存儲可以在不同的地理位置進行擴展，可以在多個不同地點擴展出大型的基礎架構。
延遲。大數據基礎架構中或許同樣會包含實時性的組件，尤其是在網頁交互或金融處理事務中。存儲系統必須能夠應對上述問題同時保持相應的性能，因為延遲可能產生過期數據。在這一領域，橫向擴展式基礎架構同樣能夠通過應用存儲節點集群，隨著容量擴展的同時增強處理能力和可連接性。基於對象的存儲系統可能並發數據流，更大程度上改善吞吐量。

⑦ 評估大數據基礎架構的重大因素

評估大數據基礎架構的重大因素
隨著IT行業持續地灌輸廉價存儲的優勢，企業較以往擁有者更多的數據，那麼在評估大數據基礎架構的過程中需要深入地調查哪些因素。本篇涉及到了在容量、延遲、訪問性、安全性和成本這些重要因素的評估。

大數據發展的驅動因素
除了存儲比以往更多的數據，我們所面臨的數據種類也變得更加繁雜。這些數據源包括互聯網事務交易、社交網路的活動、自動化感測器、移動設備以及科研儀器等。除了靜態的數據增長方面，事務交易也會保持一個固定的數據"增長速度".例如飛速增長的社交信息所產生的大量交易事務和記錄。不過現有的不斷擴大數據集無法確保能夠為業務搜索出有價值的信息。
當今的信息是一項重要的生產因素
數據業已成為了一種生產資料，就如何資本、勞動力和原始材料那樣，而且也不限於某一行業內的特定應用。企業中所有部門都旨在整合比較越來越多的數據集合，致力於降低成本、提升品質、增強生產能力以及開發新產品。舉例來說，對於現場產品的直接數據分析有助於提升設計。又例如企業可以通過對用戶習慣的深入分析，比較整體市場的增長特性，大幅提升自己在競爭分析方面的能力。
存儲發展的必要性
大數據意味著數據的增長超過了其本身的基礎架構，這驅動著應對這些特殊挑戰的存儲、網路和計算系統進一步的發展。軟體應用需求最終推動了硬體功能的發展，同時在這種情況下，大數據分析的處理過程正在影響著數據存儲基礎架構的發展。這對於存儲和IT基礎架構企業而言是一項機遇。隨著結構化和非結構化數據集的持續增長，這類數據的分析方式也更為多樣化，當前的存儲系統設計難以應對大數據基礎架構所需。存儲供應商已經開始推出基於數據塊和基於文件的系統來應對許多這方面的需求。以下列出了一些大數據存儲基礎架構的特性，這些都是源自大數據的挑戰。
容量。"大"在很多時候可以理解為PB級別的數據，因此大數據基礎架構當然要能夠可以擴展。不過其同樣必須能夠簡易地完成擴展，以模塊化或陣列的方式為用戶直接增加容量，或者至少保持系統不會宕機。橫向擴展式存儲由於能夠滿足這種需求，變得十分流行。橫向擴展集群體系架構的特徵是由存儲節點構成，每個節點具備處理能力和可連接性，可以無縫地擴展，避免傳統系統可能產生的煙囪式存儲的問題。
大數據還意味著大量的文件。管理元數據文件系統的累計會降低可擴展性並影響性能，用傳統的NAS系統就會在這種情況下出現問題。基於對象的存儲體系架構則通過另一種方式，支持在大數據存儲系統中擴展至十億級別的文件數量，而不會產生傳統文件系統中會遇到的負載問題。基於對象的存儲可以在不同的地理位置進行擴展，可以在多個不同地點擴展出大型的基礎架構。
延遲。大數據基礎架構中或許同樣會包含實時性的組件，尤其是在網頁交互或金融處理事務中。存儲系統必須能夠應對上述問題同時保持相應的性能，因為延遲可能產生過期數據。在這一領域，橫向擴展式基礎架構同樣能夠通過應用存儲節點集群，隨著容量擴展的同時增強處理能力和可連接性。基於對象的存儲系統可能並發數據流，更大程度上改善吞吐量。

⑧ 如何架構大數據應用

1.可視化分析大數據分析的使用者有大數據分析專家，同時還有普通用戶，但是他們二者對於大數據分析最基本的要求就是可視化分析，因為可視化分析能夠直觀的呈現大數據特點，同時能夠非常容易被讀者所接受，就如同看圖說話一樣簡單明了。2.數據挖掘演算法大數據分析的理論核心就是數據挖掘演算法，各種數據挖掘的演算法基於不同的數據類型和格式才能更加科學的呈現出數據本身具備的特點，也正是因為這些被全世界統計學家所公認的各種統計方法（可以稱之為真理）才能深入數據內部，挖掘出公認的價值。另外一個方面也是因為有這些數據挖掘的演算法才能更快速的處理大數據，如果一個演算法得花上好幾年才能得出結論，那大數據的價值也就無從說起了。3.預測性分析大數據分析最終要的應用領域之一就是預測性分析，從大數據中挖掘出特點，通過科學的建立模型，之後便可以通過模型帶入新的數據，從而預測未來的數據。4.語義引擎非結構化數據的多元化給數據分析帶來新的挑戰，我們需要一套工具系統的去分析，提煉數據。語義引擎需要設計到有足夠的人工智慧以足以從數據中主動地提取信息。5.數據質量和數據管理。大數據分析離不開數據質量和數據管理，高質量的數據和有效的數據管理，無論是在學術研究還是在商業應用領域，都能夠保證分析結果的真實和有價值。大數據分析的基礎就是以上五個方面，當然更加深入大數據分析的話，還有很多很多更加有特點的、更加深入的、更加專業的大數據分析方法。大數據的技術數據採集：ETL工具負責將分布的、異構數據源中的數據如關系數據、平面數據文件等抽取到臨時中間層後進行清洗、轉換、集成，最後載入到數據倉庫或數據集市中，成為聯機分析處理、數據挖掘的基礎。數據存取：關系資料庫、NOSQL、SQL等。基礎架構：雲存儲、分布式文件存儲等。數據處理：自然語言處理(NLP，NaturalLanguageProcessing)是研究人與計算機交互的語言問題的一門學科。處理自然語言的關鍵是要讓計算機地理解地自然語言，所以自然語言處理又叫做自然語言理解也稱為計算語言學。一方面它是語言信息處理的一個分支，另一方面它是人工智慧的核心課題之一。統計分析：假設檢驗、顯著性檢驗、差異分析、相關分析、T檢驗、方差分析、卡方分析、偏相關分析、距離分析、回歸分析、簡單回歸分析、多元回歸分析、逐步回歸、回歸預測與殘差分析、嶺回歸、logistic回歸分析、曲線估計、因子分析、聚類分析、主成分分析、因子分析、快速聚類法與聚類法、判別分析、對應分析、多元對應分析（最優尺度分析）、bootstrap技術等等。數據挖掘：分類（Classification）、估計（Estimation）、預測（Prediction）、相關性分組或關聯規則（）、聚類（Clustering）、描述和可視化、DescriptionandVisualization）、復雜數據類型挖掘(Text,Web,圖形圖像，視頻，音頻等)模型預測：預測模型、機器學習、建模模擬。結果呈現：雲計算、標簽雲、關系圖等。大數據的處理1.大數據處理之一：採集大數據的採集是指利用多個資料庫來接收發自客戶端（Web、App或者感測器形式等）的數據，並且用戶可以通過這些資料庫來進行簡單的查詢和處理工作。比如，電商會使用傳統的關系型資料庫MySQL和Oracle等來存儲每一筆事務數據，除此之外，Redis和MongoDB這樣的NoSQL資料庫也常用於數據的採集。在大數據的採集過程中，其主要特點和挑戰是並發數高，因為同時有可能會有成千上萬的用戶來進行訪問和操作，比如火車票售票網站和淘寶，它們並發的訪問量在峰值時達到上百萬，所以需要在採集端部署大量資料庫才能支撐。並且如何在這些資料庫之間進行負載均衡和分片的確是需要深入的思考和設計。2.大數據處理之二：導入/預處理雖然採集端本身會有很多資料庫，但是如果要對這些海量數據進行有效的分析，還是應該將這些來自前端的數據導入到一個集中的大型分布式資料庫，或者分布式存儲集群，並且可以在導入基礎上做一些簡單的清洗和預處理工作。也有一些用戶會在導入時使用來自Twitter的Storm來對數據進行流式計算，來滿足部分業務的實時計算需求。導入與預處理過程的特點和挑戰主要是導入的數據量大，每秒鍾的導入量經常會達到百兆，甚至千兆級別。3.大數據處理之三：統計/分析統計與分析主要利用分布式資料庫，或者分布式計算集群來對存儲於其內的海量數據進行普通的分析和分類匯總等，以滿足大多數常見的分析需求，在這方面，一些實時性需求會用到EMC的GreenPlum、Oracle的Exadata，以及基於MySQL的列式存儲Infobright等，而一些批處理，或者基於半結構化數據的需求可以使用Hadoop。統計與分析這部分的主要特點和挑戰是分析涉及的數據量大，其對系統資源，特別是I/O會有極大的佔用。4.大數據處理之四：挖掘與前面統計和分析過程不同的是，數據挖掘一般沒有什麼預先設定好的主題，主要是在現有數據上面進行基於各種演算法的計算，從而起到預測（Predict）的效果，從而實現一些高級別數據分析的需求。比較典型演算法有用於聚類的Kmeans、用於統計學習的SVM和用於分類的NaiveBayes，主要使用的工具有Hadoop的Mahout等。該過程的特點和挑戰主要是用於挖掘的演算法很復雜，並且計算涉及的數據量和計算量都很大，常用數據挖掘演算法都以單線程為主。整個大數據處理的普遍流程至少應該滿足這四個方面的步驟，才能算得上是一個比較完整的大數據處理。

⑨ 大數據平台架構如何進行 包括哪些方面

【導語】大數據平台將互聯網使用和大數據產品整合起來，將實時數據和離線數據打通，使數據能夠實現更大規模的相關核算，挖掘出數據更大的價值，然後實現數據驅動事務，那麼大數據平台架構如何進行?包括哪些方面呢?

1、事務使用：

其實指的是數據收集，你經過什麼樣的方法收集到數據。互聯網收集數據相對簡略，經過網頁、App就能夠收集到數據，比方許多銀行現在都有自己的App。

更深層次的還能收集到用戶的行為數據，能夠切分出來許多維度，做很細的剖析。但是對於涉及到線下的行業，數據收集就需要藉助各類的事務體系去完成。

2、數據集成：

指的其實是ETL，指的是用戶從數據源抽取出所需的數據，經過數據清洗,終究依照預先定義好的數據倉庫模型，將數據載入到數據倉庫中去。而這兒的Kettle僅僅ETL的其中一種。

3、數據存儲：

指的便是數據倉庫的建設了，簡略來說能夠分為事務數據層(DW)、指標層、維度層、匯總層(DWA)。

4、數據同享層：

表明在數據倉庫與事務體系間提供數據同享服務。Web Service和Web
API，代表的是一種數據間的銜接方法，還有一些其他銜接方法，能夠依照自己的情況來確定。

5、數據剖析層：

剖析函數就相對比較容易理解了，便是各種數學函數，比方K均值剖析、聚類、RMF模型等等。

6、數據展現：

結果以什麼樣的方式呈現，其實便是數據可視化。這兒建議用敏捷BI，和傳統BI不同的是，它能經過簡略的拖拽就生成報表，學習成本較低。

7、數據訪問：

這個就比較簡略了，看你是經過什麼樣的方法去查看這些數據，圖中示例的是因為B/S架構，終究的可視化結果是經過瀏覽器訪問的。

關於大數據平台架構內容，就給大家介紹到這里了，不知道大家是不是有所了解呢，未來，大數據對社會發展的重大影響必將會決定未來的發展趨勢，所以有想法考生要抓緊時間學起來了。

⑩ 大數據定義、思維方式及架構模式

大數據定義、思維方式及架構模式
一、大數據何以為大
數據現在是個熱點詞彙，關於有了大數據，如何發揮大數據的價值，議論紛紛，而筆者以為，似乎這有點搞錯了原因與結果，就象關聯關系，有A的時候，B與之關聯，而有B的時候，A卻未必關聯，筆者還是從通常的4個V來描述一下我所認為的大數據思維。
1、大數據的量，數據量足夠大，達到了統計性意義，才有價值。筆者看過的一個典型的案例就是，例如傳統的，收集幾千條數據，很難發現血緣關系對遺傳病的影響，而一旦達到2萬條以上，那麼發現這種影響就會非常明顯。那麼對於我們在收集問題時，是為了發現隱藏的知識去收集數據，還是不管有沒有價值地收集，這還是值得商榷的。其實收集數據，對於數據本身，還是可以劃分出一些標准，確立出層級，結合需求、目標來收集，當然有人會說，這樣的話，將會導致巨大的偏差，例如說喪失了數據的完整性，有一定的主觀偏向，但是筆者以為，這樣至少可以讓收集到的數據的價值相對較高。
2、大數據的種類，也可以說成數據的維度，對於一個對象，採取標簽化的方式，進行標記，針對需求進行種類的擴充，和數據的量一樣，筆者認為同樣是建議根據需求來確立，但是對於標簽，有一個通常採取的策略，那就是推薦標簽和自定義標簽的問題，分類法其實是人類文明的一大創舉，採取推薦標簽的方式，可以大幅度降低標簽的總量，而減少後期的規約工作，數據收集時擴充量、擴充維度，但是在數據進入應用狀態時，我們是希望處理的是小數據、少維度，而通過這種推薦、可選擇的方式，可以在標准化基礎上的自定義，而不是毫無規則的擴展，甚至用戶的自定義標簽給予一定的限制，這樣可以使維度的價值更為顯現。
3、關於時效性，現在進入了讀秒時代，那麼在很短的時間進行問題分析、關聯推薦、決策等等，需要的數據量和數據種類相比以前，往往更多，換個說法，因為現在時效性要求高了，所以處理數據的方式變了，以前可能多人處理，多次處理，現在必須變得單人處理、單次處理，那麼相應的信息系統、工作方式、甚至企業的組織模式，管理績效都需要改變，例如筆者曾經工作的企業，上了ERP系統，設計師意見很大，說一個典型案例，以往發一張變更單，發出去工作結束，而上了ERP系統以後，就必須為這張變更單設定物料代碼，設置需要查詢物料的存儲，而這些是以前設計師不管的，又沒有為設計師為這些增加的工作支付獎勵，甚至因為物料的缺少而導致變更單不能發出，以至於設計師工作沒有完成，導致被處罰。但是我們從把工作一次就做完，提升企業的工作效率角度，這樣的設計變更與物料集成的方式顯然是必須的。那麼作為一個工作人員，如何讓自己的工作更全面，更完整，避免王府，讓整個企業工作更具有時間的競爭力，提高數據的數量、種類、處理能力是必須的。
4、關於大數據價值，一種說法是大數據有大價值，還有一種是相對於以往的結構化數據、少量數據，現在是大數據了，所以大數據的單位價值下降。筆者以為這兩種說法都正確，這是一個從總體價值來看，一個從單元數據價值來看的問題。而筆者提出一個新的關於大數據價值的觀點，那就是真正發揮大數據的價值的另外一個思路。這個思路就是針對企業的問題，首先要說什麼是問題，筆者說的問題不是一般意義上的問題，因為一說問題，大家都以為不好、錯誤等等，而筆者的問題的定義是指狀態與其期望狀態的差異，包括三種模式，
1）通常意義的問題，例如失火了，必須立即撲救，其實這是三種模式中最少的一種；
2）希望保持狀態，
3）期望的狀態，這是比原來的狀態高一個層級的。
我們針對問題，提出一系列解決方案，這些解決方案往往有多種，例如員工的培訓，例如設備的改進，例如組織的方式的變化，當然解決方案包括信息化手段、大數據手段，我們一樣需要權衡大數據的方法是不是一種相對較優的方法，如果是，那麼用這種手段去解決，那麼也就是有價值了。例如筆者知道的一個案例，一個企業某產品部件偶爾會出現問題，企業經歷數次後決定針對設備上了一套工控系統，記錄材料的溫度，結果又一次出現問題時，進行分析認為，如果工人正常上班操作，不應該有這樣的數據記錄，而經過與值班工人的質詢，值班工人承認其上晚班時睡覺，沒有及時處理。再往後，同樣的問題再沒有再次發生。
總結起來，筆者以為大數據思維的核心還是要落實到價值上，面向問題，收集足夠量的數據，足夠維度的數據，達到具有統計學意義，也可以滿足企業生產、客戶需求、甚至競爭的時效要求，而不是一味為了大數據而大數據，這樣才是一種務實、有效的正確思維方式，是一線大數據的有效的項目推進方式，在這樣的思維模式基礎上，採取滾雪球方式，把大數據逐步展開，才真正贏來大數據百花齊放的春天。
二、大數據思維方式
大數據研究專家舍恩伯格指出，大數據時代，人們對待數據的思維方式會發生如下三個變化：
1）人們處理的數據從樣本數據變成全部數據；
2）由於是全樣本數據，人們不得不接受數據的混雜性，而放棄對精確性的追求；
3）人類通過對大數據的處理，放棄對因果關系的渴求，轉而關注相關關系。
事實上，大數據時代帶給人們的思維方式的深刻轉變遠不止上述三個方面。筆者認為，大數據思維最關鍵的轉變在於從自然思維轉向智能思維，使得大數據像具有生命力一樣，獲得類似於「人腦」的智能，甚至智慧。
1、總體思維
社會科學研究社會現象的總體特徵，以往采樣一直是主要數據獲取手段，這是人類在無法獲得總體數據信息條件下的無奈選擇。在大數據時代，人們可以獲得與分析更多的數據，甚至是與之相關的所有數據，而不再依賴於采樣，從而可以帶來更全面的認識，可以更清楚地發現樣本無法揭示的細節信息。
正如舍恩伯格總結道：「我們總是習慣把統計抽樣看作文明得以建立的牢固基石，就如同幾何學定理和萬有引力定律一樣。但是，統計抽樣其實只是為了在技術受限的特定時期，解決當時存在的一些特定問題而產生的，其歷史不足一百年。如今，技術環境已經有了很大的改善。在大數據時代進行抽樣分析就像是在汽車時代騎馬一樣。
在某些特定的情況下，我們依然可以使用樣本分析法，但這不再是我們分析數據的主要方式。」也就是說，在大數據時代，隨著數據收集、存儲、分析技術的突破性發展，我們可以更加方便、快捷、動態地獲得研究對象有關的所有數據，而不再因諸多限制不得不採用樣本研究方法，相應地，思維方式也應該從樣本思維轉向總體思維，從而能夠更加全面、立體、系統地認識總體狀況。
2、容錯思維
在小數據時代，由於收集的樣本信息量比較少，所以必須確保記錄下來的數據盡量結構化、精確化，否則，分析得出的結論在推及總體上就會「南轅北轍」，因此，就必須十分注重精確思維。然而，在大數據時代，得益於大數據技術的突破，大量的非結構化、異構化的數據能夠得到儲存和分析，這一方面提升了我們從數據中獲取知識和洞見的能力，另一方面也對傳統的精確思維造成了挑戰。
舍恩伯格指出，「執迷於精確性是信息缺乏時代和模擬時代的產物。只有5%的數據是結構化且能適用於傳統資料庫的。如果不接受混亂，剩下95%的非結構化數據都無法利用，只有接受不精確性，我們才能打開一扇從未涉足的世界的窗戶」。也就是說，在大數據時代，思維方式要從精確思維轉向容錯思維，當擁有海量即時數據時，絕對的精準不再是追求的主要目標，適當忽略微觀層面上的精確度，容許一定程度的錯誤與混雜，反而可以在宏觀層面擁有更好的知識和洞察力。
3、相關思維
在小數據世界中，人們往往執著於現象背後的因果關系，試圖通過有限樣本數據來剖析其中的內在機理。小數據的另一個缺陷就是有限的樣本數據無法反映出事物之間的普遍性的相關關系。而在大數據時代，人們可以通過大數據技術挖掘出事物之間隱蔽的相關關系，獲得更多的認知與洞見，運用這些認知與洞見就可以幫助我們捕捉現在和預測未來，而建立在相關關系分析基礎上的預測正是大數據的核心議題。
通過關注線性的相關關系，以及復雜的非線性相關關系，可以幫助人們看到很多以前不曾注意的聯系，還可以掌握以前無法理解的復雜技術和社會動態，相關關系甚至可以超越因果關系，成為我們了解這個世界的更好視角。舍恩伯格指出，大數據的出現讓人們放棄了對因果關系的渴求，轉而關注相關關系，人們只需知道「是什麼」，而不用知道「為什麼」。我們不必非得知道事物或現象背後的復雜深層原因，而只需要通過大數據分析獲知「是什麼」就意義非凡，這會給我們提供非常新穎且有價值的觀點、信息和知識。也就是說，在大數據時代，思維方式要從因果思維轉向相關思維，努力顛覆千百年來人類形成的傳統思維模式和固有偏見，才能更好地分享大數據帶來的深刻洞見。
4、智能思維
不斷提高機器的自動化、智能化水平始終是人類社會長期不懈努力的方向。計算機的出現極大地推動了自動控制、人工智慧和機器學習等新技術的發展，「機器人」研發也取得了突飛猛進的成果並開始一定應用。應該說，自進入到信息社會以來，人類社會的自動化、智能化水平已得到明顯提升，但始終面臨瓶頸而無法取得突破性進展，機器的思維方式仍屬於線性、簡單、物理的自然思維，智能水平仍不盡如人意。
但是，大數據時代的到來，可以為提升機器智能帶來契機，因為大數據將有效推進機器思維方式由自然思維轉向智能思維，這才是大數據思維轉變的關鍵所在、核心內容。眾所周知，人腦之所以具有智能、智慧，就在於它能夠對周遭的數據信息進行全面收集、邏輯判斷和歸納總結，獲得有關事物或現象的認識與見解。同樣，在大數據時代，隨著物聯網、雲計算、社會計算、可視技術等的突破發展，大數據系統也能夠自動地搜索所有相關的數據信息，並進而類似「人腦」一樣主動、立體、邏輯地分析數據、做出判斷、提供洞見，那麼，無疑也就具有了類似人類的智能思維能力和預測未來的能力。
「智能、智慧」是大數據時代的顯著特徵，大數據時代的思維方式也要求從自然思維轉向智能思維，不斷提升機器或系統的社會計算能力和智能化水平，從而獲得具有洞察力和新價值的東西，甚至類似於人類的「智慧」。
舍恩伯格指出，「大數據開啟了一個重大的時代轉型。就像望遠鏡讓我們感受宇宙，顯微鏡讓我們能夠觀測到微生物一樣，大數據正在改變我們的生活以及理解世界的方式，成為新發明和新服務的源泉，而更多的改變正蓄勢待發」。
大數據時代將帶來深刻的思維轉變，大數據不僅將改變每個人的日常生活和工作方式，改變商業組織和社會組織的運行方式，而且將從根本上奠定國家和社會治理的基礎數據，徹底改變長期以來國家與社會諸多領域存在的「不可治理」狀況，使得國家和社會治理更加透明、有效和智慧。