/*
size_a，pa——指向數組a的有效末端
ma——a的最大容量,必須大於na
n=12——求n的階
p——求階乘時的當前乘數
*/
#include<stdio.h>
#define Ma 10000
int pa;/*指向數組a的有效末端*/
int p=2;
int memory_over=0;
union data
{ unsigned long int b;
struct
{unsigned l:16;
unsigned h:16;
}m;
}a[Ma];
/*+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
演算法說明1：考慮到result比較長，我用a[Ma].b來存儲n!的result，每一位a[pa].b能存儲4位10進制數字。
因為我定義的數組是靜態的，所以Ma應該足夠大。
ps:其實只用定義一個unsigned long int b[Ma];就可以了（直接用b[pa]代替a[pa].b），但是我考慮到可能會訪問每一結點b[pa]的高16位(a[pa].m.h)和低16位(a[pa].m.l)，但是的我考慮是多餘的！！不用像我這樣定義這么復雜的共用體！！
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*/
unsigned int cashe;
unsigned int carry;
void main()
{
unsigned int n;/*求n的階*/
void facto(unsigned int n);
printf("Input n:");
scanf("%u",&n);
/*=================開始求階乘！=============*/
a[0].b=1;/*初始化*/
facto(n);
/*+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
演算法說明2：上面這句直接調用facto(n)來求n!
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*/
/*========================以下是顯示最後結果====================================*/
if(memory_over==0)
{printf("the result include %dNO:\n",pa+1);
printf("%u",a[pa--].m.l);
for(;pa>=0;pa--)
printf("%04u",a[pa].m.l);
printf("\n");
}
getch();
}
/*+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
演算法說明2：求階函數facto(n)說明：
這個函數會不斷地調用multiple()，它的作用是每被調用一次就使得a[pa].b與階數p相乘一次，直到乘完n為止！
{multiple();
p++;/*每一輪乘一個階數p*/
}
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*/
void facto(unsigned int n)
{void multiple();
pa=0;
while(pa<Ma-1&&p<=n)/*容量限制*/
{multiple();
p++;/*每一輪乘一個階數p*/
}
if(p<=n)
{printf("memory out!\n");memory_over=1;}/*如果當前的存儲結果的數組a[Ma]不夠用!應提高Ma*/
}
/*==============================================================================
演算法說明3：乘法函數multiple()說明：負責a[pa].b與階數p相乘。
a[pa].b有很多結點，a[0].b、a[1].b、a[2].b、a[3].b、a[4].b、。。。
當然是從低結點a[0].b開始不斷與p相乘，產生的「進位」加到高位a[1].b，直到a[pa].b*p為止！
隨著結果數值增大，pa個結點的a[].b可能容納不下結果，所以如果a[pa].b與p相乘後還有「進位」carry,就擴大pa，並把carry放入到新增加的結點：
if(carry>0)
a[++pa].b=carry;
===================================================================================*/
void multiple()
{int i=0;
carry=0;
while(i<=pa)/*i指向當前處理的元素a[i],每一輪用一個位與階數p相乘*/
{a[i].b=a[i].b*p+carry;/*計算結果，要考慮來自低位的進位*/
carry=a[i].b/10000;/*計算進位*/
a[i].b=a[i].b%10000;/*計算余數*/
i++;
}
if(carry>0)
a[++pa].b=carry;
}
B. 五種大數據處理架構
五種大數據處理架構
大數據是收集、整理、處理大容量數據集，並從中獲得見解所需的非傳統戰略和技術的總稱。雖然處理數據所需的計算能力或存儲容量早已超過一台計算機的上限，但這種計算類型的普遍性、規模，以及價值在最近幾年才經歷了大規模擴展。
本文將介紹大數據系統一個最基本的組件：處理框架。處理框架負責對系統中的數據進行計算，例如處理從非易失存儲中讀取的數據，或處理剛剛攝入到系統中的數據。數據的計算則是指從大量單一數據點中提取信息和見解的過程。
下文將介紹這些框架：
· 僅批處理框架：
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提供了真正的流處理並具備批處理能力，通過深度優化可運行針對其他平台編寫的任務，提供低延遲的處理，但實際應用方面還為時過早。
最適合的解決方案主要取決於待處理數據的狀態，對處理所需時間的需求，以及希望得到的結果。具體是使用全功能解決方案或主要側重於某種項目的解決方案，這個問題需要慎重權衡。隨著逐漸成熟並被廣泛接受，在評估任何新出現的創新型解決方案時都需要考慮類似的問題。
C. 大數據的預測功能是增值服務的核心
大數據的預測功能是增值服務的核心
從走在大數據發展前沿的互聯網新興行業，到與人類生活息息相關的醫療保健、電力、通信等傳統行業，大數據浪潮無時無刻不在改變著人們的生產和生活方式。大數據時代的到來，給國內外各行各業帶來諸多的變革動力和巨大價值。
最新發布的報告稱，全球大數據市場規模將在未來五年內迎來高達26%的年復合增長率——從今年的148.7億美元增長到2018年的463.4億美元。全球各大公司、企業和研究機構對大數據商業模式進行了廣泛地探索和嘗試，雖然仍舊有許多模式尚不明朗，但是也逐漸形成了一些成熟的商業模式。
兩種存儲模式為主
互聯網上的每一個網頁、每一張圖片、每一封郵件，通信行業每一條短消息、每一通電話，電力行業每一戶用電數據等等，這些足跡都以「數據」的形式被記錄下來，並以幾何量級的速度增長。這就是大數據時代帶給我們最直觀的沖擊。
正因為數據量之大，數據多為非結構化，現有的諸多存儲介質和系統極大地限制著大數據的挖掘和發展。為更好地解決大數據存儲問題，國內外各大企業和研究機構做了許許多多的嘗試和努力，並不斷摸索其商業化前景，目前形成了如下兩種比較成熟的商業模式：
可擴展的存儲解決方案。該存儲解決方案可幫助政府、企業對存儲的內容進行分類和確定優先順序，高效安全地存儲到適當存儲介質中。而以存儲區域網路（SAN）、統一存儲、文件整合/網路連接存儲（NAS）的傳統存儲解決方案，無法提供和擴展處理大數據所需要的靈活性。而以Intel、Oracle、華為、中興等為代表的新一代存儲解決方案提供商提供的適用於大、中小企業級的全系存儲解決方案，通過標准化IT基礎架構、自動化流程和高擴展性，來滿足大數據多種應用需求。
雲存儲。雲存儲是一個以數據存儲和管理為核心的雲計算系統，其結構模型一般由存儲層、基礎管理、應用介面和訪問層四層組成。通過易於使用的API，方便用戶將各種數據放到雲存儲裡面，然後像使用水電一樣按用量進行收費。用戶不用關心數據的存儲介質、網路狀況以及安全性的管理，只需按需向提供方購買空間。
源數據價值水漲船高
在紅紅火火的大數據時代，隨著數據的累積，數據本身的價值也在不斷升值，這種情況很好地反應了事物由量變到質變的規律。例如有一種罕見的疾病，得病率為十萬分之一，如果從小樣本數據來看非常罕見，但是擴大到全世界70億人，那麼數量就非常龐大。以前技術落後，不能將該病情數字化集中研究，所以很難攻克。但是，我們現在把各種各樣的數據案例搜集起來統一分析，我們很快就能攻克很多以前想像不到的科學難題。類似的例子，不勝枚舉。
正是由於可以通過大數據挖掘到很多看不見的價值，源數據本身的價值也水漲船高。一些掌握海量有效數據的公司和企業找到了一條行之有效的商業路徑：對源數據直接或者經過簡單封裝銷售。在互聯網領域，以Facebook、twitter、微博為代表的社交網站擁有大量的用戶和用戶關系數據，這些網站正嘗試以各種方式對該源數據進行商業化銷售，Google、Yahoo!、網路[微博]等搜索公司擁有大量的搜索軌跡數據以及網頁數據，他們可以通過簡單API提供給第三方並從中盈利；在傳統行業中，中國聯通[微博]（3.44, 0.03, 0.88%）、中國電信[微博]等運營商擁有大量的底層用戶資料，可以通過簡單地去隱私化，然後進行銷售盈利。
各大公司或者企業通過提供海量數據服務來支撐公司發展，同時以免費的服務補償用戶，這種成熟的商業模式經受住了時間的考驗。但是對於任何用戶數據的買賣，還需處理好用戶隱私信息，通過去隱私化方式，來保護好用戶隱私。
預測是增值服務的核心
在大數據基礎上進行深度挖掘，所衍生出來的增值服務，是大數據領域最具想像空間的商業模式。大數據增值服務的核心是什麼？預測！大數據引發了商業分析模式轉變，從過去的樣本模式到現在的全數據模式，從過去的小概率到現在的大概率，從而能夠得到比以前更准確的預測。目前形成了如下幾種比較成熟的商業模式。
個性化的精準營銷。一提起「垃圾簡訊」，大家都很厭煩，這是因為本來在營銷方看來是有價值的、「對」的信息，發到了「錯」的用戶手裡。通過對用戶的大量的行為數據進行詳細分析，深度挖掘之後，能夠實現給「對」的用戶發送「對」的信息。比如大型商場可以對會員的購買記錄進行深度分析，發掘用戶和品牌之間的關聯。然後，當某個品牌的忠實用戶收到該品牌打折促銷的簡訊之後，一定不是厭煩，而是欣喜。如優捷信達、中科嘉速等擁有強大數據處理技術的公司在數據挖掘、精準廣告分析等方面擁有豐富的經驗。
企業經營的決策指導。針對大量的用戶數據，運用成熟的數據挖掘技術，分析得到企業運營的各種趨勢，從而給企業的決策提供強有力的指導。例如，汽車銷售公司，可以通過對網路上用戶的大量評論進行分析，得到用戶最關心和最不滿意的功能，然後對自己的下一代產品進行有針對性的改進，以提升消費者的滿意度。
總體來說，從宏觀層面來看，大數據是我們未來社會的新能源；從企業微觀層面來看，大數據分析和運用能力正成為企業的核心競爭力。深入研究和積極探索大數據的商業模式，對企業的未來發展有至關重要的意義。
D. 開源的大數據框架有哪些
文件存儲：Hadoop HDFS、Tachyon、KFS離線計算：Hadoop MapRece、Spark流式、實時計算：Storm、Spark Streaming、S4、HeronK-V、NOSQL資料庫：HBase、Redis、MongoDB資源管念埋理：YARN、Mesos日誌收集：Flume、Scribe、Logstash、Kibana消息系統：Kafka、StormMQ、ZeroMQ、RabbitMQ查詢分析：Hive、Impala、Pig、Presto、Phoenix、SparkSQL、Drill、Flink、Kylin、祥豎Druid分布式協調服務：Zookeeper集謹高大群管理與監控：Ambari、Ganglia、Nagios、Cloudera
E. 什麼是大數據的主流框架
市場上有許多可用的框架。其中一些更受歡迎，例如Spark，Hadoop，Hive和Storm。Presto在效用指數上得分很高，而Flink具有巨大的潛力。
1. Apache Hadoop
Hadoop是基於Java的平台。這是一個開放源代碼框架，可跨集群排列的一組硬體機器提供批處理數據處理和數據存儲服務。Hadoop同樣適用於可靠，可擴展和分布式的計算。但是，它也可以用作通用文件存儲。它可以存儲和處理PB的信息。Hadoop由三個主要組件組成。
2. Apache Spark
Spark框架由加利福尼亞大學伯克利分校成立。它是具有改進的數據流處理的批處理框架。藉助完整的內存計算以及處理優化，它保證了極其快速的集群計算系統。
3.Apache Storm
Apache Storm是另一個引人注目的解決方案，專注於處理巨大的實時數據流。Storm的主要亮點是可伸縮性和停機後的迅速恢復能力。
4. Apache Flink
Apache Flink是一個開源框架，同樣適用於批處理和流數據處理。它最適合於集群環境。該框架基於轉換–流概念。它也是大數據的4G。它比Hadoop – Map Rece快100倍。
5. Presto
Presto是最適合較小數據集的開源分布式SQL工具。Presto配備了協調員以及各種工人。當客戶提交查詢時，將對這些查詢進行解析，分析，計劃執行並分配給協調員在工作人員之間進行處理。
6. Samza
Apache Samza是有狀態的流，准備與Kafka共同開發的大數據系統。Kafka提供數據服務，緩沖和容錯能力。
F. 第三章 大數據存儲
一，HDFS的基本特徵與構架
1.基本特徵
（1）大規模數據分布存儲能力：以分布式存儲能力和良好的可擴展性。（基於大量分布節點上的本地文件系統，構建一個邏輯上具有巨大容量的分布式文件系統，並且整個文件系統的容量可隨集群中節點的增加而線性擴展）
（2）高並發訪問能力：提供很高的數據訪問寬頻（高數據吞吐率），並且可以把帶寬的大小等比例擴展到集群中的全部節點上
（3）強大的容錯能力：（設計理念中硬體故障被視作常態）保證在經常有節點發生硬體故障的情況下正確檢測硬體故障，並且能自動從故障中快速恢復，確保數據不丟失（採用多副本數據塊形式存儲）
（4）順序式文件訪問：（大數據批處理都是大量簡單數據記錄的順序處理）對順序讀進行了優化，支持大量數據的快速順序讀出，代價是對於隨機的訪問負載較高
（5）簡單的一致性模型（一次寫多次讀）：支持大量數據的一次寫入，多次讀取；不支持已寫入數據的更新操作，但允許在文件尾部添加新的數據
（6）數據塊存儲模式：默認的塊大小是64MB。好處：減少元數據的數量，允許這些數據塊通過隨機方式選擇節辯局睜點，分布存儲在不同地方
2.基本框架與工作過程
（1）基本組成結構與文件訪問過程
[1]HDFS；一個建立在一組分布式伺服器節點的本地文件系統之上的分布式文件系統（採用經典主-從結構）
[2]主控節點NameNode:
1）是一個主伺服器，用來管理整個文件系統的命名空間和元數據,以及處理來自外界的文件訪問請求
2）保存了文件系統的三中元數據
命名空間：整個分布式文件系統的目錄結構
數據塊與文件名的映射表
每個數據塊副本的位置信息，每一個數據塊默認有3個副本
[3]從節點DataNode：
1）用來實際存儲和管理文件的數攜歲據塊
2）為了防止數據丟失，每個數據塊默認有3個副本，且3個副本會分別復制在不同節點上，以避免一個節點失效造成一個數據塊的徹底丟失
[4]程序訪問文件時，實際文件數據流並不會通過NameNode傳送，而是從NameNode獲得所需訪問數據塊的存儲位置信息後，直接去訪問對應的DataNode獲取數據
[5]設計好處：
1）可以允許一個文件的數據能同時在不同DataNode上並發訪問，提高數據訪問的速度
2）減少NameNode的負擔，避免使NameNode成為數據訪問瓶頸
[6]基本訪問過程：
1）首先，用戶的應用程序通過HDFS的客戶端程序將文件名發送至NameNode
2）NameNode接收到文件名之後，在HDFS目錄中檢索文件名對應的數據塊，再根據數據塊信息找到保存數據塊的DataNode地址，講這些地址回送到客戶端
3）客戶端接收到這些DataNode地址之後，與這些DataNode並行的進行數據傳輸操作，同時將操作結臘兆果的相關日誌提交到NameNode
2.數據塊
（1）為了提高硬碟的效率，文件系統中最小的數據讀寫單元是數據塊
（2）HDFS數據塊的默認大小是64MB，實際部署中，可能會更多
（3）將數據塊設置大的原因是減少定址開銷的時間
（4）當應用發起數據傳輸請求：
[1]NameNode首先檢索文件對應的數據塊信息，找到數據塊對應的DataNode
[2]DataNode根據數據塊信息在自身的存儲中尋找相應的文件，進而與應用程序之間交換數據
[3]因為檢索過程是但進行，所以要增加數據塊大小，這樣就可以減少定址的頻度和時間開銷
3.命名空間
（1）文件命名遵循「目錄/子目錄/文件」格式
（2）通過命令行或者是API可以創建目錄，並且將文件保存在目錄中。可以對文件進行創建，刪除，重命名操作
（3）命令空間由NameNode管理。所有對命名空間的改動都會被記錄
（4）允許用戶配置文件在HDFS上保存的副本數量，保存的副本數稱作「副本因子」
4.通信協議
（1）採用TCP協議作為底層的支撐協議
（2）應用協議
[1]應用可以向NameNode主動發起TCP連接
[2]應用和NameNode交互協議稱為Client協議
[3]NameNode和DataNode交互的協議稱為DataNode協議
（3）用戶和DataNode的交互是通過發起遠程調用（RPC），並由NameNode響應來完成的。另外，NameNode不會主動發起遠程過程調用請求
5.客戶端：是用戶和HDFS通信最常見的渠道，部署的HDFS都會提供客戶端
二，HDFS可靠性設計
1.HDFS數據塊多副本存儲設計
（1）採用了在系統中保存多個副本的方式保存數據，且同一個數據塊的多個副本會存放在不同節點上
（2）優點：
[1]採用多副本，可以讓客戶從不同數據塊中讀取數據，加快傳輸速度
[2]HDFS的DataNode之間通過網路傳輸數據，如果採用多個副本可以判斷數據傳輸是否出錯
[3]多副本可以保證某個DataNode失效的情況下，不會丟失數據
2.可靠性的設計實現
（1）安全模式：
[1]HDFS啟動時，NameNode進入安全模式
[2]處於安全模式的NameNode不能做任何文本操作，甚至內部的副本創建不允許
[3]NameNode需要和各個DataNode通信，獲得其中保存的數據塊信息，並對數據塊信息進行檢查
[4]只有通過了NameNode檢查，一個數據塊被認為安全。當被認為安全的數據塊所佔比例達到某個閾值，NameNode退出
（2）SecondaryNmaeNode
[1]使用它來備份NameNode元數據，以便在其失效時能從中恢復出其上的元數據
[2]它充當NameNode的一個副本，本身並不處理任何請求。
[3]作用：周期性保存NameNode的元數據
（3）心跳包和副本重新創建
[1]心跳包：位於HDFS核心的NameNode，通過周期性的活動檢查DataNode的活動
[2]檢測到DataNode失效，保存在其上的數據不可用。則其上保存的副本需要重新創建這個副本，放到另外可用的地方
（4）數據一致性
[1]採用了數據校驗和機制
[2]創建文件時，HDFS會為這個文件生成一個校驗和，校驗和文件和文件本身保存在同一空間上，
[3]傳輸數據時會將數據與校驗和一起傳輸，應用收到數據後可以進行校驗
（5）租約
[1]防止同一個文件被多個人寫入數據
[2]NameNode保證同一個文件只會發放一個允許的租約，可以有效防止出現多人寫入的情況
（6）回滾
三，HDFS文件存儲組織與讀寫
1.文件數據的存儲組織
（1）NameNode目錄結構
[1]藉助本地文件系統來保存數據，保存文件夾位置由配置選項（{dfs.name.dir}/{/tmp/dfs/name}）決定
[2]在NameNode的${dfs.name.dir}之下有3個文件夾和1個文件：
1）current目錄：
文件VERSION:保存了當前運行的HDFS版本信息
FsImages:是整個系統的空間鏡像文件
Edit：EditLog編輯文件
Fstime：上一次檢查點時間
2）previous.checkpoint目錄：和上一個一致，但是保存的是上一次檢查點的內容
3）image目錄：舊版本的FsImage存儲位置
4）in_use.look:NameNode鎖，只在NameNode有效（啟動並且能和DataNode正常交互）時存在。
（2）DataNode目錄結構
[1]藉助本地文件系統來保存數據。保存文件夾位置由配置選項{dfs.data.dir}決定
[2]在其之下有4個子目錄和2個文件
1）current目錄：已經成功寫入的數據塊，以及一些系統需要的文件
a)文件VERSION：保存了當前運行的HDFS版本信息
b)subdirXX:當同一目錄下文件超過一定限制，新建一個目錄，保存多出來的數據塊和元數據
2）tmp目錄和blockBeingWritten目錄：正在寫入的數據塊，是HDFS系統內部副本創建時引發的寫入操作對應的數據塊
3）detach目錄：用於DataNode升級
4）Storage目錄：防止版本不同帶來風險
5）in_user.lock文件：DataNode鎖。只有在DataNode有效時存在。
（3）CheckPointNode目錄結構：和上一個基本一致
2.數據的讀寫過程
（1）數據讀取過程
[1]首先，客戶端調用FileSystem實例的open方法，獲得這個文件對應的輸入流，在HDFS中就是DFSInputStream
[2]構造第一步的輸入流時，通過RPC遠程調用NameNode可以獲得NameNode中此文件對應的數據塊保存位置，包括這個文件副本的保存位置（註：在輸入流中會按照網路拓撲結構，根據與客戶端距離對DataNode進行簡單排序）
[3]-[4]獲得此輸入流後，客戶端調用READ方法讀取數據。輸入流選擇最近的DFSInputStream會根據前面的排序結果，選擇最近的DataNode建立連接並讀取數據。
[5]如果已達到數據塊末端，關閉這個DataNode的連接，然後重新查找下一個數據塊
[6]客戶端調用close，關閉輸入流DFSInputStream
（2）數據輸入過程
[1]-[2]:客戶端調用FileSystem實例的create方法，創建文件。檢查後，在NameNode添加文件信息，創建結束之後，HDFS會返回一個輸出流DFSDataOutputStream給客戶端
[3]調用輸出流的write方法向HDFS中對應的文件寫入數據。
數據首先會被分包，這些分包會寫入一個輸出流的內部隊列Data隊列中，接收完整數據分包，輸出流回想NameNode申請保存文件和副本數據塊的若干個DataNode
[4]DFSDataOutputStream會（根據網路拓撲結構排序）將數據傳輸給距離上最短的DataNode，這個節點接收到數據包後傳給下一個。數據在各節點之間通過管道流通，減少傳輸開銷
[5]數據節點位於不同機器上，數據需要通過網路發送。（為保證數據節點數據正確，接收到數據的節點要向發送者發送確認包）
[6]執行3-5知道數據全部寫完，DFSDataInputStream繼續等待知道所有數據寫入完畢並確認，調用complete方法通知NameNode文件寫入完成
[7]NameNode接收到complete消息之後，等待相應數量的副本寫入完畢後，告知客戶端
傳輸過程，當某個DataNode失效，HDFS執行：
1）關閉數據傳輸的管道
2）將等待ACK隊列的數據放到Data隊列頭部
3）更新正常DataNode中所有數據塊版本。當失效的DataNode重啟，之前的數據塊會因為版本不對被清除
4）在傳輸管道中刪除失效的DataNode,重新建立管道並發送數據包
4.HDFS文件系統操作命令
（1）HDFS啟動與關閉
[1]啟動過程：
1）進入到NameNode對應節點的Hadoop安裝目錄
2）執行啟動腳本:bin/start-dfs.sh
[2]關閉過程:bin/stop-dfs.sh
（2）文件操作命令格式與注意事項
[1]基本命令格式：
1）bin/hadoop dfs-cmd <args> args-> scheme://authority/path
2）args參數基本格式前面是scheme，authority是機器地址和對應埠
a)本地文件，scheme是file
b)HDFS上文件，scheme是hdfs
（3）文件操作基本格式
[1]hadoop dfs-cat URL [URL ...]
[2]作用：將參數所指示文件內容輸出到stdout
G. c語言處理文件里的大數據
C語言處理大數據一般有三種處理方法：
1、分段處理，即無論文件多大，程序中使用的永遠只是一小段部分，可以使用一個緩沖區，根據用戶交互輸入，分段的輸出。
2、使用內存文件映射，這是最常用的文件的處理方法，Linux和Windows都提供一種內存文件映射的機制，以Windows為例，可以調用 CreateFile()、 CreateFileMapping()以及 MapViewOfFile()三個函數來完成內存文件映射。
3、使用資料庫，藉助SQL查詢語言對大數據進行操作。