① 五種大數據處理架構
五種大數據處理架構
大數據是收集、整理、處理大容量數據集，並從中獲得見解所需的非傳統戰略和技術的總稱。雖然處理數據所需的計算能力或存儲容量早已超過一台計算機的上限，但這種計算類型的普遍性、規模，以及價值在最近幾年才經歷了大規模擴展。
本文將介紹大數據系統一個最基本的組件：處理框架。處理框架負責對系統中的數據進行計算，例如處理從非易失存儲中讀取的數據，或處理剛剛攝入到系統中的數據。數據的計算則是指從大量單一數據點中提取信息和見解的過程。
下文將介紹這些框架：
· 僅批處理框架：
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提供了真正的流處理並具備批處理能力，通過深度優化可運行針對其他平台編寫的任務，提供低延遲的處理，但實際應用方面還為時過早。
最適合的解決方案主要取決於待處理數據的狀態，對處理所需時間的需求，以及希望得到的結果。具體是使用全功能解決方案或主要側重於某種項目的解決方案，這個問題需要慎重權衡。隨著逐漸成熟並被廣泛接受，在評估任何新出現的創新型解決方案時都需要考慮類似的問題。
② 實現潛在大數據交付的七個步驟
實現潛在大數據交付的七個步驟
大數據趨勢代表了不斷變化的處理大量數據的需求，需要新的技術解決方案，而不一定是老一代的資料庫處理方式。那麼，企業開始與大數據打交道時需要考慮哪些因素呢？
首先，他們需要知道什麼是大數據。如下是我如何定義大數據這一概念：
「新興技術和實踐方案，使收集、處理、發現和儲存大量結構化和非結構化數據變得快速而富有成本效益。」
大數據涵蓋了眾多社會生活的范疇——從金融交易到人類基因組，從汽車的遙測感測器到互聯網上社會媒體日誌。利用傳統的資料庫方式來處理和存儲這些大數據是相當昂貴的。為了解決這個問題的新技術，利用開放源解決方案和商業硬體高效存儲數據，並行工作負載，提供快速處理能力。
隨著越來越多的IT部門開始研究大數據的替代品，討論中心棧，處理速度和平台。而這些IT部門無法很好的把握其現有技術的局限性，許多不能闡明這些替代方案的商業價值，更遑論他們將如何進行分類和優先順序的數據排序，進入大數據治理。
事實上，我們所看到的新出現的大數據需求，以及關於其處理平台和流程的討論只是大數據傳輸整體的一部分。在現實中，實現的全部潛在大數據的交付過程，需要七個步驟：
收集：從數據源和分布在多個節點處收集數據——通常是一個網格——每個進程的一個子集，並行數據。
流程：然後系統使用相同的高功率並行執行，對每個節點上的數據進行快速計算。節點「壓縮」結果數據到更多的消費數據，由此產生的數據集可以被人工（在分析的情況下）或機器（在解釋大型結果的情況下）使用。[page] 管理：正在處理大數據往往是異構的，來自不同的交易系統。這些數據通常需要理解、定義、注釋，並且以安全起見，還要進行掃描和審核。
測量：公司往往會測量數據的速率，可與其他客戶的行為或記錄進行整合，並隨時間的推移來決定是否對其進行整合或校正。業務要求應告知測量和持續跟蹤的類型。
消耗：所產生的使用數據應符合原要求的處理流程。例如，如果利用幾百TB的社會化媒體數據互動，有助於我們了解社會媒體數據如何驅動用戶額外購買產品，那麼我們應該建立社會媒體的數據應當如何被訪問和更新的規則。這與機器對機器的數據訪問是同樣重要的。
存儲：由於「數據即服務」趨勢的形成，越來越多的數據開始存儲在單一位置，以便於進程的訪問。數據用於短期的存儲批處理或長期保留，應審慎處理存儲解決方案。
數據管理：數據治理是驅動業務的決策和監督數據。根據數據治理的定義，數據治理適用於六個前階段的大數據傳輸。通過建立流程和指導原則，制裁圍繞數據的行為。大數據需要根據其預期消費進行管轄。其他的風險是對於數據分配的不滿，更不用說過度投資。
大多數工作人員負責調查和獲取大數據解決方案側重於收集和存儲步驟，而犧牲了其他的步驟。他們的問題是：「我們如何收集所有這些數據，我們把這些數據存儲在何處？」
但許多IT部門仍然逃避了定義離散的大數據業務需求的進程。而業務人士經常將大數據的趨勢看成只是一個IT重新整修的借口，沒有明確的終點的游戲。這種相互嘲諷的環境就是為什麼大數據沒有超越「前期調查階段」的罪魁禍首。
③ 大數據來襲應用交付市場呼喚高性能產品
大數據來襲應用交付市場呼喚高性能產品
一分鍾內，微博、推特上新發的數據量超過10萬，社交網路「臉譜」的瀏覽量超過600萬……近年來，隨著雲計算和大數據應用的廣泛普及，及越來越多基於網路的應用和業務頻繁出現，這直接導致了數據量和訪問量的急速增加。
一方面，海量的數據交互讓企業級網路應用平台收獲了火爆的人氣和收益;而另一方面，迅猛增長的數據量也對企業網路業務平台的可靠性、連續性、安全性提出了更為嚴峻的考驗。如何保障企業應用在大數據、雲計算環境下的安全、可用且可擴展應用，成為了各企業IT管理者亟待解決的問題，而高性能的應用交付正在擔當解決這一系列問題的重要使命。
大數據來襲 企業級網路應用暗藏危機
由於大數據流動發生在「比特王國」里，無法用肉眼看見，也無法用身體感官體驗，所以很多IT管理者一時間還無法感受到潛藏在「比特王國」里的數據危機。那麼不妨做個比喻，假如北京要舉行一場極具吸引力的火爆活動，火到足以吸引全國各地數百萬人驅車而來，可以想像本已擁堵不堪的北京路網交通將會面臨怎樣的境地?眾所周知，每月數萬量的車輛自然增長就已讓北京的路網交通疲於應付，就更別提這種瞬時間的車輛暴增情況。
而面臨大數據的空前增長，「比特王國」里暗藏的問題危機則與這個比喻極為相似。比如「雙十一」大促當天，各大電商網站承受的用戶流量呈現幾十倍甚至幾百倍的暴增，其伺服器及網路鏈路瞬時間承受的壓力可想而知。若解決不善，不但企業面臨重大損失，網路世界的「擁塞」同樣會讓眾多用戶心煩意亂、惱怒不止。試想，眾多用戶若因網路問題，無法在有效的時間內買到限時促銷的特價商品，其心情會是怎樣的失落?該網路平台的用戶體驗及口碑將會受到怎樣的質疑和抨擊?
當然，瞬時的數據增長僅是各類型企業網路應用中所面臨的問題之一，隨著當前網路應用環境日趨復雜、以及成長性需求頻現等，企業級網路應用所面臨的問題也越來越多，也越來越復雜。
面對這日益復雜的局面，越來越多企業的IT管理者們發現，僅僅是無限制的增加寬頻來應對這一挑戰已顯得力不從心。尤其是在數據流量瞬時增長幾十倍甚至幾百倍的情況下，伺服器與帶寬肯定不能同樣以幾十倍甚至上百倍的隨之增設。企業應用系統更多的時候需要根據用戶所處地域，瀏覽器類型，訪問的URI，Cookie類型等應用層信息進行更智能的流量調度，這就需要的是一個端到端的，更智能、可靠、高效、安全的解決方案。
由此，為了有效解決在企業IT的建設中，因大數據有序或無序增長所產生的一系列問題，「應用交付」開始扮演起極其重要的角色，並已是必然選擇。
化解危機 呼喚高性能「應用交付」產品
「應用交付」是一套綜合系統，除了包含傳統負載均衡所有功能外，還包括進行更智能的流量調度，提升應用系統訪問速度，節省伺服器和帶寬開支，改善用戶體驗以及對應用系統的安全防護等。同時，應用交付產品有三個最核心的功能，即必須實現應用系統的高性能、高可靠性和應用的安全。由此，高性能是實現高品質應用交付的最基礎保障，否則產品自身反而成為應用系統的性能和可靠性瓶頸。
然而，要想打造高性能的「應用交付」產品卻絕非易事。據國內新興的應用交付解決方案供應商太一星晨研發總監馮曉傑表示，要想使應用交付產品具備高性能，首先需要有高轉發性能的硬體平台，其次是能夠駕馭硬體平台的軟體系統。這就好比要建設高效通暢的地面交通路網，一方面需要科學規劃道路網路硬體基礎，另一方面也必須擁有高效智能的交通調度管理系統。
目前，應用交付開發依託的硬體平台主要由X86平台和Cavium兩大類。在2006-2009年期間，嵌入式多核平台(Mips、powerpc等)在處理網路流量方面有一定優勢。但在2009年之後，嵌入式多核平台因在業務中包含復雜演算法時(例如DPI、病毒檢測、協議分析、應用檢測等)，性能衰減程度高，漸漸不適應未來大數據時代的應用。而此間Intel在嵌入式事業部的重點投入、X86平台逐漸在網路設備領域實現了趕超。因此，目前主流負載均衡廠商都在採用X86平台，以滿足高性能應用交付的平台需求。
但要打造高性能的應用交付，僅有硬體平台是遠遠不夠的，還需要與之配套的軟體系統。多年來，國際優秀廠商利用自身技術積累，研發最新的軟體，充分發揮硬體多核的優勢，成倍提升了產品性能。但在最初，依託硬體平台的軟體研發實力卻成為了掣肘國內應用交付廠打造高性能應用交付產品的瓶頸。
據了解，由於在硬體平台開發的積累不夠成熟，很多國內廠家硬體雖達到了8核、16核，但是缺乏必要的軟體開發能力，絕大部分都在使用intel的開源代碼，性能提升有限，產品無法滿足數據中心10G以上吞吐的要求。
不過，近兩年來隨著太一星晨等擁有深厚技術積累的應用交付廠商的興起，開始加大在應用交付領域的研發投入，已經取得了很多讓國內同行驚喜的成果。這主要表現在應用交付產品性能上屢創新高，業已呈現出迎頭趕上，且在性能指標上可以挑戰國際品牌的旺盛發展勢頭。
蛹化成蝶 國產高性能應用交付破繭而出
通過國內應用交付廠商的潛心研究發現，將具備網路開發和應用開發經驗的人才相融合，是一條可行的發展道路。只要開發人員具備嵌入式平台的開發經驗，同時又具備X86平台開發經驗。將兩種架構融合起來，硬體平台內部進行數據分流檢測，就會極大的提升負載均衡的產品性能，充分發揮出X86 sandybridge平台的吞吐性能。
令業內欣喜的是，目前國內已經有先驅者組建了這樣的優秀團隊，努力攻堅，並成功發布負載均衡產品，且其產品已經在多個行業得到高效可靠的應用，讓業內強烈感受到了國產品牌的競爭力。
日前，太一星晨旗下T-Force系列應用交付控制器(ADC)推出了V3.0版本。該版本便基於intel sandybridge多核硬體平台研發設計，並基於Hypervisor虛擬化架構，將應用交付與虛擬化高效結合，可以實現智能動態地利用資源，實現更高的靈活性和拓展性，以幫助企業更加通暢快捷的實現數據業務落地。
業內人士指出，由於前段時間發生的棱鏡門等事件，無疑給國家數據信息安全防護敲響了警鍾。因此，無論是出於國家信息安全的需要，還是國產品牌自強的使命，這都需要國產應用交付廠商肩負起義不容辭的責任，以研發高性能的應用交付產品來捍衛國家的信息安全。
而據消息透露，目前太一星晨已經研發出更高端且性能更加強勁的分布式平台，據傳其整機會達到600G以上的處理能力，這已然達到國際領先水平。不僅可以完全滿足超大型數據中心的各種要求，而且具備更好的雙主控可靠性設計和彈性擴展能力，這無疑是國產應用交付產品發展史上又一針強心劑。
以上是小編為大家分享的關於大數據來襲應用交付市場呼喚高性能產品的相關內容，更多信息可以關注環球青藤分享更多干貨
④ 如何保障穩定交付
咨詢記錄 · 回答於2021-11-22
⑤ 怎麼更好的利用數據提高項目管理水平
數據的數量，價值，多樣性，准確性和速度（通常稱為大數據的5 V）正在不斷收集有關業務和人類生活不同方面的多層數據，為利用數據提供了重要機會企業和社會的利益。項目在一個環境中生活和呼吸，無論是商業還是非商業，因此作為背景的一部分，大量有關項目和項目管理的數據也在不斷收集。首先，關於項目管理收集的數據的性質有兩種：涉及更廣泛的項目生態系統，涉及政策，監管環境，業務背景，項目效益實現程序，項目融資和組織項目成熟度，關於活動，事件，這意味著如上所述的大數據集合可以至少以兩種方式使用。首先，數據可用於開發新的科學和協議，以改進項目的規劃，控制和交付。其次，可以分析數據以塑造整個項目生態系統的未來。為了開始關於這個關鍵問題的對話，我們討論了大數據分析可以影響未來或項目管理交付的一些方式。
⑥ 大數據的生命周期的九個階段
大數據的生命周期的九個階段
企業建立大數據的生命周期應該包括這些部分：大數據組織、評估現狀、制定大數據戰略、數據定義、數據收集、數據分析、數據治理、持續改進。
一、大數據的組織
沒有人，一切都是妄談。大數據生命周期的第一步應該是建立一個專門預算和獨立KPI的「大數據規劃、建設和運營組織」。包括高層的首席數據官，作為sponsor，然後是公司數據管理委員會或大數據執行籌劃指導委員會，再往下就是大數據的項目組或大數據項目組的前身：大數據項目預研究團隊或大數據項目籌備組。這個團隊是今後大數據戰略的制定和實施者的中堅力量。由於人數眾多，建議引入RACI模型來明確所有人的角色和職責。
二、大數據的現狀評估和差距分析
定戰略之前，先要做現狀評估，評估前的調研包括三個方面：一是對外調研：了解業界大數據有哪些最新的發展，行業頂尖企業的大數據應用水平如何？行業的平均尤其是主要競爭對手的大數據應用水準如何？二是對內客戶調研。管理層、業務部門、IT部門自身、我們的最終用戶，對我們的大數據業務有何期望？三是自身狀況摸底，了解自己的技術、人員儲備情況。最後對標，作差距分析，找出gap。
找出gap後，要給出成熟度現狀評估。一般而言，一個公司的大數據應用成熟度可以劃分為四個階段：初始期（僅有概念，沒有實踐）；探索期（已經了解基本概念，也有專人進行了探索和探討，有了基本的大數據技術儲備）；發展期（已經擁有或正在建設明確的戰略、團隊、工具、流程，交付了初步的成果）；成熟期（有了穩定且不斷成熟的戰略、團隊、工具、流程，不斷交付高質量成果）。
三、大數據的戰略
有了大數據組織、知道了本公司大數據現狀、差距和需求，我們就可以制定大數據的戰略目標了。大數據戰略的制定是整個大數據生命周期的靈魂和核心，它將成為整個組織大數據發展的指引。
大數據戰略的內容，沒有統一的模板，但有一些基本的要求：
1. 要簡潔，又要能涵蓋公司內外干係人的需求。
2. 要明確，以便清晰地告訴所有人我們的目標和願景是什麼。
3. 要現實，這個目標經過努力是能達成的。
四、大數據的定義
我認為：「數據不去定義它，你就無法採集它；無法採集它，你就無法分析它；無法分析它，你就無法衡量它；無法衡量它，你就無法控制它；無法控制它，你就無法管理它；無法管理它，你就無法利用它」。所以「在需求和戰略明確之後，數據定義就是一切數據管理的前提」。
五、 數據採集
1. 大數據時代的數據源很廣泛，它們可能來自於三個主要方面：現有公司內部網各應用系統產生的數據（比如辦公、經營生產數據），也有來自公司外互聯網的數據（比如社交網路數據）和物聯網等。
2.大數據種類很多，總的來講可以分為：傳統的結構化數據，大量的非結構化數據（比如音視頻等）。
3. 數據採集、挖掘工具很多。可以基於或集成hadoop的ETL平台、以互動式探索及數據挖掘為代表的數據價值發掘類工具漸成趨勢。
4. 數據採集的原則：在數據源廣泛、數據量巨大、採集挖掘工具眾多的背景下，大數據決策者必須清楚地確定數據採集的原則：「能夠採集到的數據，並不意味著值得或需要去採集它。需要採集的數據和能夠採集到的數據的"交集"，才是我們確定要去採集的數據。」
六、數據處理和分析
業界有很多工具能幫助企業構建一個集成的「數據處理和分析平台」。對企業大數據管理者、規劃者來講，關鍵是「工具要滿足平台要求，平台要滿足業務需求，而不是業務要去適應平台要求，平台要去適應廠商的工具要求」。那麼這個集成的平台應該有怎樣的能力構成呢？它應該能檢索、分類、關聯、推送和方便地實施元數據管理等。見下圖：
七、 數據呈現
大數據管理的價值，最終要通過多種形式的數據呈現，來幫助管理層和業務部門進行商業決策。大數據的決策者需要將大數據的系統與BI（商業智能）系統和KM（知識管理）系統集成。下圖就是大數據的各種呈現形式。
八、 審計、治理與控制
1.大數據的審計、治理和控制指的是大數據管理層，組建專門的治理控制團隊，制定一系列策略、流程、制度和考核指標體系，來監督、檢查、協調多個相關職能部門的目標，從而優化、保護和利用大數據，保障其作為一項企業戰略資產真正發揮價值。
2.大數據的治理是IT治理的組成部分，大數據的審計是IT審計的組成部分，這個體系要統籌規劃和實施，而不是割裂的規劃和實施。
3.大數據的審計、治理與控制的核心是數據安全、數據質量和數據效率。
九、 持續改進
基於不斷變化的業務需求和審計與治理中發現的大數據整個生命周期中暴露的問題，引入PDCA等方法論，去不斷優化策略、方法、流程、工具，不斷提升相關人員的技能，從而確保大數據戰略的持續成功！
⑦ 大數據數倉建設性能優化方案
大數據數倉的性能優化主要圍繞以下四個方面：
在數據倉庫建設的過程中，我們不可避免的要執行數據任務，那麼這些任務如何進行配置才會是最優的？如果任務調度配置存在問題，將會導致出現瓶頸任務，或者無法及時提供業務所需的數據，這時我們就需要首先從調度方面來考慮，是不是有些任務的調度時間設置不合理？或者是不是有的任務的優先順序設置不合理？
對於數倉的建模而言，其實可以分為3NF建模和維度建模，推薦使用維度建模方式，可以按照星型模型或者雪花模型架構的方式去建模。3NF建模方式或者實體建模方式的應用性會差一點，在很多時候其性能也會差一點，但3NF會避免數據的冗餘，其擴展性會好一些。而維度建模會有一定的數據冗餘，並且冗餘程度會很高，但是對於上層使用者而言，其易用性要好很多，並且其查詢的性能也會好很多，雖然犧牲了一定的可擴展性，但是仍然在可接受的范圍之內。之所以在大數據的框架下推薦使用維度建模，是因為建模產生的數據冗餘對於大數據離線數倉來說，存儲的成本並不高，因為其都屬於SATA盤的存儲，這樣的存儲成本是很低的。
總之，在大數據框架下推薦大家使用維度建模，使用星型模型或者雪花模型建模的方式，這樣無論對於後續的運維還是後續的數據使用而言，都是比較便利的，並且性能會好一些。星型模型其實就是中間一個事實表，周邊圍繞著一堆維度表，其結構會簡單一些，使用比較方便，性能也比較好；對於雪花模型而言，維度表可能還會繼續關聯其他的維度表，這種方式就是雪花模型，它會略微比星型模型復雜一些。其實星型模型也可以理解為較為簡單的雪花模型。這里推薦大家使用星型模型，當然如果業務非常復雜，必須要使用雪花型也可以使用。這是因為星型模型雖然有數據冗餘，但是其結構比較簡單，容易理解，而且使用起來只需要A傳給B就可以了，不需要再關聯一個C。
除了上述兩個較大的關鍵點之外，還有一些需要注意的小點，比如中間表的使用。我們一般將數倉分為三層，第一層做緩沖，第二層做整合，第三層做應用。但是並不是嚴格的只能分為三層，中間可能會有一些中間表，用於存儲中間計算的結果，如果能夠利用好中間表則會增強數倉的易用性和整體的性能。中間表的使用主要在數倉的第二層裡面，因為需要整合數據，但整合後的數據仍是明細數據，對於這些表而言，數據量往往會比較大，而且會有見多的下游任務依賴這個表，因此可以做一些輕度的匯總，也就是做一些公共的匯總的中間表，這樣應用層可以節省很多的計算量和成本。此外，雖然建議使用中間表，但也要注意中間表的數量，因為中間表數量過多，就會有太多的依賴層級。
在某些業務場景下，我們還需要對寬表進行拆表，拆表的情況一般發生在該表的欄位較多，而其中幾個欄位的產出時間較晚，導致整個表的交付時間也會延遲，在這種情況下我們可以將這幾個欄位單獨拆出來處理，這樣就不會因為幾個欄位影響其餘業務的使用。
與拆表相對的情況是合表，隨著業務的增多，可能會有多個表中存放類似的數據指標，此時，我們可以將多個表整合到一個表中，減少數據任務的冗餘。
表分區的功能一定要合理利用，這對於性能會產生很大的影響，一級分區一般都是按照天劃分的，建議大家一天一個增量或者一天一個全量來做。二級分區的選擇反而會多一些，首先大家要烤爐是否建立二級分區，其次大家再選擇二級分區的建立方式。二級分區比較適合於在where語句中經常使用到的欄位，而且這個欄位應該是可枚舉的，比如部門名稱這樣的。這里還有一個前提，就是如果這個欄位的值的分布是非常不均勻的，那麼就不太建議做二級分區。
離線數倉的計算任務基本都是通過SQL實現，這里也只講在SQL部分如何進行優化。我們平時在進行數據處理，數據清洗，數據轉換，數據加工的過程中都會使用到SQL。對於大數據體系下的SQL的優化而言，主要集中在兩個大的方面進行：減少數據輸入和避免數據傾斜。減少數據輸入是最核心的一點，如果數據輸入量太大，就會佔用很多的計算資源。而數據傾斜是在離線數倉中經常會遇到的，數據傾斜分為幾種，需要針對性的進行優化。
對有分區的表，合理使用分區可以過濾數據，避免全表掃描，有效的降低計算的數據輸入。
SQL支持只讀取一次源數據，然後將其寫入到多個目標表，這樣就保證了只做一次查詢。語法如下
當我們在使用join，Rece或者UDF時，先對數據進行過濾也能有效的提高任務的效率
當發生數據再Map階段傾斜的情況，第一種處理方式反饋至業務層面，看能否通過業務層面的修改讓kv值均衡分布，如果業務層面無法處理，那麼可以調整Map的個數，也就是加大Map的計算節點，默認情況是每256M的數據為一個計算節點，我們可以將其調小，也就是加大Map處理的節點的個數，使得數據分割的更加均勻一些。
Join階段的傾斜也是比較常見的，其解決方案需要分鍾如下幾種情況處理：
Rece傾斜可能的情況有以下幾種：
總結一下，性能調優歸根結底還是資源不夠了或者資源使用的不合理，或者是因為任務分配的不好，使得某些資源分配和利用不合理。
⑧ 再談如何提高全球交付保障能力
而對新一代服務外包，客戶也不再僅僅關心成本降低和一般的需求符合，更關注於商務價值、服務質量及創新、以及交付的可靠性，這意味著客戶對供應商的選擇提出了更高的要求。
質量保證（QA）是傳統 IT 服務供應商較關注的一個最佳實踐，但 QA只注重需求和 SLA的符合、以及開發過程的監控和質量的審計，但為實現客戶的商務精良，則要求就需更進一步——這就是所謂的「交付保障」（Delivery Assurance ——DA）：它強調預報和控制風險，更高的服務質量，為客戶提供更好商務價值和投資回報（ROI），能提供創新的解決方案，顯著改進客戶滿意度。
從 QA 到 DA 已成為今天服務供應商全球交付模型的一個重要組成部分，一些具領先意識的廠商已開始建立獨立的 DA 管理團隊、設立專職的 DA 管理崗位。他們都是一些有經驗和專長的人員組成，能對客戶的商務復雜性有足夠的把握，能對交付質量作出合理評估，能對交付過程有效監管、降低風險、提高客戶干係者的利益回報和信心。
交付保障 DA 關系組織價值管理體系，要予以制度化滲透到每個成員和過程環節中，保證對客戶的交付質量和價值承諾。DA 程序要求對每個客戶和項目作出客觀完整評估，它涉及八個方面，包括：交易結構、客戶環境、軟體架構、項目計劃和跟蹤、財務、團隊組織、方法論和接受准則。
DA 是一個有效工具，能幫助企業實現較高的交付質量基準，讓客戶充分放心，提高服務競爭力，顯示企業的與眾不同。
交付管理 （Delivery Management – DM） 要比項目管理有更寬的含義，它關系人員、過程和技術的組織與管理，提供商務和技術功能，實現客戶預期想得到的價值和好處。負責這類工作的人，稱為交付經理、交付主任或交付 VP，他們與項目經理有些相近之處，但項目經理涉及更多細節，交付經理則站得更高些，往往跨多個責任領域，也是更有經驗的人員，常常參與更大更復雜的項目和更高層的管理。他們需要熟悉生命周期管理、項目管理方法、交付方法、客戶位理、供應商管理、關系管理、人員管理、有技術經驗和新技術的知識，也是一個能與客戶就交付目標達成共識的戰略家。
交付管理框架包括：商務交付模型、定價模型、項目管理模型、軟體開發方法、和要求的符合過程。當前流行的全球交付模型是同時組合在岸和離岸模型的混合交付或多層交付模型，在定價方式上採用多種靈活選擇形式，新一代偏向於基於 TCO 的模式，強調與客戶共擔風險/共享收益，開發方法上趨向敏捷迭代開發，項目管理模型包羅 PMI PMBOK， Prince2 和敏捷項目管理 （APM），而參考的符合標准模型，包括： CMMI，ISO （SPICE，ISO 20000）和六西格瑪。
一些著名IT 廠商也已經開發了一些交付管理系統和解決方案，如微軟的服務交付管理（SDM）、Borland 的全套軟體交付產品、1stCore 的交付管理產品等。
VDM 與傳統的項目管理在著眼點上有很大的差別，它也有助於解決過去項目管理中存在的一些問題，如有些項目建議沒有與商務目標掛鉤，沒有提供商務價值考慮或支持組織策略，項目預期與商務預期存在差異，承諾了的商務價值沒有實際交付，或者由於沒有預期的風險造成商務價值的失落。
VDM 則不同，對每一個項目建議都要做價值評估和案例分析，為什麼要做這一功能 ？它的好處是什麼樣？ 需要什麼代價 ？風險度和可行性如何 ？對項目實施范圍，實現優先排序，項目的計劃也是基於價值的，要求計劃與客戶組織的商務行動密切配合，得到高層領導的直接支持與參與，真正理解干係者的預期和價值，對變更管理的態度也不只是隨附客戶要求的被動應諾，而是把它看成是為客戶帶來更高價值的變革要求和動力，對風險管理也不只是著眼保護項目本身，而是更關心保護項目的產出價值，盡力消除價值實施的障礙或可能造成損失的因素，這稱之為價值風險管理。VDM 也特別關注財務方面和收益/價值管理，要求把項目價值管理目標都量化，評估產出結果和影響因素，財務管理也不僅局限於項目預算，更關注於結果損益，對項目的管控， VDM 的著眼點不是項目是否完成，是否超支和誤期，是否達到質量要求，而更關注的是否實現預期價值，這是所有管理決策、判斷和測量的出發點。
在項目管理層面也有不同，全球開發和交付還必須應對全球項目管理 （Global Project Management —— GPM）的新課題和挑戰，這包括：全球項目管理框架的建立、全球虛擬團隊的發展和項目領導、基本架構實現要求、結構化項目管理過程、跨文化合作、信任建立、合作工具、沖突解決、分布團隊的協調、知識傳播和共享、全球溝通策略和技術、干係者識別和溝通渠道、會議規則和模板等，為培養全球項目管理經理和人才
，已推出不少 GPM 培訓課程，國外一些大學也已通過多國合作，讓高年級學生能得到參與全球項目開發的實訓體驗。
與交付保障和管理直接相關的一個內容，就是所謂的「服務/軟體交付平台」（Service/Software Delivery Platform —— SDP），這個名稱起源於通信業，期望通過服務交付平台（SDP）和服務交付框架 （SDF），提高服務的復用率，縮短服務的上市時間，雖然它與這里談的交付保障和管理沒有直接關系，但 SDP 的概念，即需要一個共性的支撐環境或交付平台，還是十分有用的，這方面已經出現了一些有價值的產品和解決方案，譬如，微軟提出的通過服務交付平台實現有效的軟體交付，把應用開發中一些共性功能，作為平台的可復用支撐服務，它可支持服務的創建、部署和執行以及服務的協調、集成和管理；再如 Borland 的軟體交付平台，通過集成的工具套，支持整個應用開發生命周期上開發團隊不同角色間的合作和配合，這些工具包括：CoreAnalyst， CoreArchitect， CoreDeveloper， CoreTester， 它支持Java和Eclipse 平台上的開發；其它可注意的還有，Capgemini 用集成服務平台 BPOpen， 加快 BPO 的交付 .
軟體作為服務（SaaS）的興起，也是值得這里特別關注的一件事。因為 SaaS 本身就意味著是一類新的軟體交付模型，它無論對客戶方和供應方都有許多吸引力的地方：對客戶而言，這是一種按需交付模式，它可以快速上線，初始投資低，且交付可靠性高，運行維護省心，系統容易同步升級；對供應方而言，可以提供一對多的服務，有持久性的服務收入。近年來，SaaS 交付平台的出現，像微軟、Orcale、HCL、OpSource等都紛紛推出了相關的產品，其基本技術都是基於 SOA 的，更為這一模式的推廣如虎添翼，更方便了應用開發商進入 SaaS 市場的步伐。而 SaaS 交付模式對外包市場的影響也已開始顯露，如印度的 TCS 已經開始與 SaaS 供應商Salesforce.com結盟，利用後者已有的服務解決作為新外包服務的基礎，以加快對按需服務的交付，同時減輕過於依賴勞力資源的傳統外包服務。BPO 與SaaS 匯合也是一個可以預期的趨勢，因為在 BPO 領域同樣存在如何擺脫過分依賴勞務密集商務模式帶來的問題，應用SaaS 能提供更多機會自動化現成的過程和操作，這方面一個可引用的例子是印度的 Cognizant 公司對兩家 SaaS 公司marketRx 和 AimNet的並購。按Gartner 和一些專家的分析，SaaS 正成為對外包的一個成本有效和較少風險的選擇，作為服務供應商也不得不考慮採納這種新的交付模式，以保持對市場的競爭力，一個建議是外包供應商應加強與 SaaS 開發商的合作，或者發展自己的SaaS模型。專家的另一個建議是，外包供應商應設法利用 SaaS 去「轉化他們的運行模式從勞力中心到技術使能」，否則不斷升高的工資期望和高舉不下的跳槽率，將消去離岸外包的價格優勢，一個可借鑒的實例是：一個叫 TrueAdvantage 的印度公司，它通過收購矽谷一家 SaaS 公司 InsideView，幫助母公司緊縮了 150 名開發人員。
提高全球交付保障能力，要求供應商進一步加強管理，它要求新的思路和方法，本文僅是羅列了一些應考慮的要點。
⑨ 大數據應用成功的四個標准
大數據應用成功的四個標准
在大數據范疇大展拳腳肯定是個正確方向，同時世界各地的初創公司及企業巨頭也在借力大數據和大數據應用創造價值——將大量的數據處理轉化為金錢或競爭優勢。然而光彩的背後，總是掩飾著一些不可忽視的真相。簡而言之，不是所有在大數據上的嘗試都得到了應有的回報，而且遠非如此。同樣這里也有另一個不容忽視的真相，在IT企業界，大數據「成功」定義的標准非常寬松，甚至「我們並沒有完全失敗」這種的觀念都可以歸結於「成功」。
那麼大數據應用成功的標准究竟是什麼？10gen戰略副總裁Matt Asay帶來了他為成功總結的4個標准：
首先，必須要可以運作
大數據應該為行業創造切實的價值，不止是高科技。McKinsey在關於大數據未來的報告中指出，大數據在醫療、政府、零售以及製造產業上擁有萬億的潛在價值。機構對大數據的成功實現需要在一下幾個方面帶來切實的收獲：附加收益、提升客戶滿意度、削減成本等。
其次，必須有本質提高
大數據交付的不應該只是漸進式的商務模式改善，更應該是本質上的突破。比如就初創企業Foursquare來說，為了發現數據之間的關系，Foursquare使用了機器學習演算法讓系統可以建立「Explore」，一個社交推薦系統可以實時的給用戶推薦有價值的位置信息，使用新的業務模式去驅動位置信息類型業務。「Explore」依賴大數據技術，同時從多於3000萬個位置信息中獲取見解。現在Foursquare已經具備了理解人們之間如何進行互動的能力，並且位置信息也不只止步平台，而是真實世界。
再次，必須具備高速度
傳統資料庫技術會拉低大數據的性能，同樣也是非常繁瑣的，因為不管這項技術是否迎合你的需求，專利許可涉及到的企業繁瑣制度遠超出你的想像。一個成功大數據項目，使用的工具集和資料庫技術必須同時滿足數據體積及多樣性的雙重需求。論據是：一個Hadoop集群只需幾個小時就可以搭建，搭建完成後就可以提供快速的數據分析。事實上大部分的大數據技術都是開源的，這就意味著你可以根據你的需求添加支持和服務，同時許可不再是快速部署的阻礙之一。
最後，必須能以前所不能
在大數據出現之前，類似Gilt Groupe這種「限時搶購」公司根本不可能實現。限時搶購網站需要日處理上千萬用戶的登陸，並且會造成非常高的伺服器負載峰值——通過高性能、快速擴展的大數據技術讓這種商業模型成為可能。
總結
大數據部署成敗的關鍵不是系統每秒可以處理多少數據量，而是使用大數據後給公司業務帶來了多少價值以及是否讓業務有突破性的提升。專注業務類型，選擇適合公司業務的工具集才是該重點關注的領域。