“我們正在從it時代走向dt時代(資料時代)。it和dt之間，不僅僅是技術的變革，更是思想意識的變革，it主要是為自我服務，用來更好地自我控制和管理，dt則是激活生産力，讓别人活得比你好”——阿裡巴巴董事局主席馬雲。
資料量從m的級别到g的級别到現在t的級、p的級别。資料量的變化，資料管理系統（dbms）和數倉系統（dw）也在悄然的變化着。
傳統應用的資料系統架構設計時，應用直接通路資料庫系統。當使用者通路量增加時，資料庫無法支撐日益增長的使用者請求的負載時，進而導緻資料庫伺服器無法及時響應使用者請求，出現逾時的錯誤。出現這種情況以後，在系統架構上就采用圖（a）的架構，在資料庫和應用中間過一層緩沖隔離，緩解資料庫的讀寫壓力。然而，當使用者通路量持續增加時，就需要考慮讀寫分離技術（master－slave）架構如圖（b），分庫分表技術。現在，架構變得越來越複雜了，增加隊列、分區、複制等處理邏輯。應用程式需要了解資料庫的schema，才能通路到正确的資料。
圖（a）
圖（b）
大資料處理技術需要解決這種可伸縮性與複雜性。
首先要認識到這種分布式的本質，要很好地處理分區與複制，不會導緻錯誤分區引起查詢失敗，而是要将這些邏輯内化到資料庫中。當需要擴充系統時，可以非常友善地增加節點，系統也能夠針對新節點進行rebalance。
其次是要讓資料成為不可變的。原始資料永遠都不能被修改，這樣即使犯了錯誤，寫了錯誤資料，原來好的資料并不會受到破壞。
storm的作者nathan marz提出的一個實時大資料處理架構（lambda架構）就滿足以上兩點。marz在twitter工作期間開發了著名的實時大資料處理架構storm，lambda架構是其根據多年進行分布式大資料系統的經驗總結提煉而成。
lambda架構的目标是設計出一個能滿足實時大資料系統關鍵特性的架構，包括有：高容錯、低延時和可擴充等。lambda架構整合離線計算和實時計算，融合不可變性（immunability），讀寫分離和複雜性隔離等一系列架構原則，可內建hadoop，kafka，storm，spark，hbase等各類大資料元件。
marz介紹big data system許具備的屬性：
a、robust and fault-tolerant（容錯性和魯棒性）：對大規模分布式系統來說，機器是不可靠的，可能會當機，但是系統需要是健壯、行為正确的，即使是遇到機器錯誤。除了機器錯誤，人更可能會犯錯誤。在軟體開發中難免會有一些bug，系統必須對有bug的程式寫入的錯誤資料有足夠的适應能力，是以比機器容錯性更加重要的容錯性是人為操作容錯性。對于大規模的分布式系統來說，人和機器的錯誤每天都可能會發生，如何應對人和機器的錯誤，讓系統能夠從錯誤中快速恢複尤其重要。
b、low latency reads and updates（低延時）：很多應用對于讀和寫操作的延時要求非常高，要求對更新和查詢的響應是低延時的。
c、scalable（橫向擴容）：當資料量/負載增大時，可擴充性的系統通過增加更多的機器資源來維持性能。也就是常說的系統需要線性可擴充，通常采用scale out（通過增加機器的個數）而不是scale up（通過增強機器的性能）。
d、general（通用性）：系統需要能夠适應廣泛的應用，包括金融領域、社交網絡、電子商務資料分析等。
e、extensible（可擴充）：需要增加新功能、新特性時，可擴充的系統能以最小的開發代價來增加新功能。
f、allows ad hoc queries（友善查詢）：資料中蘊含有價值，需要能夠友善、快速的查詢出所需要的資料。
d、minimal maintenance（易于維護）：系統要想做到易于維護，其關鍵是控制其複雜性，越是複雜的系統越容易出錯、越難維護。
h、debuggable（易調試）：當出問題時，系統需要有足夠的資訊來調試錯誤，找到問題的根源。其關鍵是能夠追根溯源到每個資料生成點。
marz認為：資料系統通過查詢過去的（部分、全部）資料去回答問題。如：他是一個什麼樣的人？他有多少朋友？這個賬号是否收支平衡？。是以，data system的通用定義為：
query ＝ function（all data）。
對通用的表達式進行分解得到：
資料系統 ＝ 資料 ＋ 查詢
進而可以從資料和查詢兩個方面認識大資料系統的本質。
資料是一個不可分割的單元，資料有兩個關鍵的特性：when 和 what。
when是隻資料是與時間相關的，也就是資料是在某個時間産生的。這個非常重要，在具有事務特性的資料庫中，操作的先後順序對結果至關重要。例如資料庫的binlog日志。是以，資料的時間性質決定了資料的全局發生先後，也就決定了資料的結果。
what是隻資料的本身。由于資料跟某個時間點相關，是以資料的本身是不可變的(immutable)，過往的資料已經成為事實（fact），你不可能回到過去的某個時間點去改變資料事實。這也就意味着對資料的操作其實隻有兩種：讀取已存在的資料和添加更多的新資料。采用資料庫的記法，crud就變成了cr，update和delete本質上其實是新産生的資料資訊，用c來記錄。
根據上述對資料特性的分析，lambda架構中對資料的存儲采用的方式是：資料不可變，存儲所有資料。
采用這兩種方式存儲的好處：
a、簡單。采用不可變的資料模型，存儲資料時隻需要簡單的往主資料集後追加資料即可。相比于采用可變的資料模型，為了update操作，資料通常需要被索引，進而能快速找到要更新的資料去做更新操作。
b、應對人為和機器的錯誤。人和機器每天都可能會出錯，如何應對人和機器的錯誤，讓資料系統快速恢複極其重要。不可變和可重複計算是應對認為和機器錯誤的常用方法。采用可變資料模型，引發錯誤的資料有可能被覆寫而丢失。相比于采用不可變的資料模型，因為所有的資料都在，引發錯誤的資料也在。修複的方法就可以簡單的是周遊資料集上存儲的所有的資料，丢棄錯誤的資料，重新計算得到views。重新計算的關鍵點在于利用資料的時間特性決定的全局次序，依次順序重新執行，必然能得到正确的結果。
目前業界有很多采用不可變資料模型來存儲所有資料的例子。比如分布式資料庫datomic，基于不可變資料模型來存儲資料，進而簡化了設計。分布式消息中間件kafka，基于log日志，以追加append-only的方式來存儲消息。
lambda架構的主要思想是将大資料系統架構為多層個層次，分别為批處理層（batch layer）、實時處理層（speed layer）、服務層（serving layer）如圖（c）。
理想狀态下，任何資料通路都可以從表達式query = function(all data)開始，但是，若資料達到相當大的一個級别（例如pb），且還需要支援實時查詢時，就需要耗費非常龐大的資源。一個解決方式是預運算查詢函數（precomputed query funciton）。書中将這種預運算查詢函數稱之為batch view（a），這樣當需要執行查詢時，可以從batch view中讀取結果。這樣一個預先運算好的view是可以建立索引的，因而可以支援随機讀取（b）。于是系統就變成：
（a）batch view = function(all data)；
（b）query = function(batch view)。
圖（c）
在lambda架構中，實作（a）batch view = function(all data)的部分稱之為batch layer。他承擔兩個職責：
a、存儲master dataset，這是一個不變的持續增長的資料集
b、針對這個master dataset進行預運算
在全體資料集上線上運作查詢函數得到結果的代價太大，同時處理查詢時間過長，導緻使用者體驗不好。如果我們預先在資料集上計算并儲存預計算的結果，查詢的時候直接傳回預計算的結果，而無需重新進行複制耗時的計算。顯然，batch view 是一個批處理過程，如采用hadoop或spark支援的map－reduce方式。采用這種方式計算得到的每個view都支援再次計算，且每次計算的結果都相同。
圖（d）
對view的了解：
view是一個和業務關聯性比較大的概念，view的建立需要從業務自身的需求出發。一個通用的資料庫查詢系統，查詢對應的函數千變萬化，不可能窮舉。但是如果從業務自身的需求出發，可以發現業務所需要的查詢常常是有限的。batch layer需要做的一件重要的工作就是根據業務的需求，考察可能需要的各種查詢，根據查詢定義其在資料集上對應的views。
batch layer的immutable data模型和views
如圖（e）坐席（agentid＝50023）的人，在10:00:06分的時候，狀态是calling，在10:00:10的時候狀态為waiting。在傳統的資料庫設計中，直接後面的紀錄覆寫前面的紀錄，而在immutable 資料模型中，不會對原有資料進行更改，而是采用插入修改紀錄的形式更改曆史紀錄。
圖（e）
上文所提及的view是圖（e）中預先計算得到的相關視圖，例如：2016-06-21當天所有上線的agent數，每條熱線、公司下上線的agent數。根據業務需要，預先計算出結果。此過程相當于傳統數倉模組化的應用層，應用層也是根據業務場景，預先加工出的view。
batch layer能夠很好的處理離線資料，但是在很多場景資料不斷産生，并且業務場景需要實時查詢。speed layer就是設計用來處理增量實時資料。
speed layer和batch layer比較類似，對資料進行計算并生成realtime view，其主要的差別在于：
a、speed layer處理的資料是最近的增量資料流，batch layer處理的是全體資料集
b、speed layer為了效率，接收到新資料及時更新realtime view，而batch layer根據全體離線資料直接得到batch view。speed layer是一種增量計算，而非重新計算（recomputation）。
c、speed layer因為采用增量計算，是以延遲小，而batch layer是全資料集的計算，耗時比較長。
綜上所訴，speed layer是batch layer在實時性上的一個補充。如圖（f）
圖（f）
speed layer可總結為以（c）realtime view ＝ function（realtime view， new data）；
lambda architecture将資料處理分解為batch layer 和speed layer有如下優點：
a、容錯性：speed layer中處理的資料不斷寫入batch layer，當batch layer中重新計算資料集包含speed layer處理的資料集後，目前的realtime view就可以丢棄，這就意味着speed layer進行中引入的錯誤，在batch layer重新計算時都可以得到修證。這點也可以看成時cap理論中的最終一緻性（eventual consistency）的展現。
b、複雜性隔離。batch layer處理的是離線資料，可以很好的掌控。speed layer采用增量算法處理實時資料，複雜性比batch layer要高很多。通過分開batch layer和speed layer，把複雜性隔離到speed layer，可以很好的提高整個系統的魯棒性和可靠性。
batch layer通過對master dataset執行查詢獲得batch view，speed layer通過增量計算提供realtime view。lambda架構的serving layer用于響應使用者的查詢請求，合并batch view和realtime view中的結果資料集到最終的資料集，如圖（g）。是以，serving layer的職責包含：
a、對batch view和realtime view的随機通路
b、更新batch veiw和realtime view，并負責結合兩者的資料，對使用者提供統一的接口
圖（g）
綜上所訴，serving layer采用如下等式（d）表示：query ＝ function（batch views， realtime view）。
下圖給出了lambda架構中各元件在大資料生态系統中和阿裡集團的常用元件。資料流存儲選用不可變日志的分布式系統kafa、tt、metaq；batch layer資料集的存儲選用hadoop的hdfs或者阿裡雲的odps；batch view的加工采用mapreduce；batch view資料的存儲采用mysql（查詢少量的最近結果資料）、hbase（查詢大量的曆史結果資料）。speed layer采用增量資料處理storm、flink；realtime view增量結果資料集采用記憶體資料庫redis。
圖（h）
lambda是一個通用架構，各子產品選型不要局限于上面給出的元件，特别是view的選型。因為view是和各業務關聯非常大的概念，view選擇元件時要根據業務的需求，選擇最合适的元件。
優點：
a、資料的不可變性。裡面給出的資料傳輸模型是在初始化階段對資料進行執行個體化，這樣的做法是能獲益良多的。能夠使得大量的mapreduce工作變得有迹可循，進而便于在不同階段進行獨立調試。
b、強調了資料的重新計算問題。在流進行中重新計算是個主要挑戰，但是經常被忽視。比方說，某工作流的資料輸出是由輸入決定的，那麼一旦代碼發生改動，我們将不得不重新計算來檢視變更的效度。什麼情況下代碼會改動呢？例如需求發生變更，計算字段需要調整或者程式發出錯誤，需要進行調試。
缺點：
a、jay kreps認為lambda包含固有的開發和運維的複雜性。lambda需要将所有的算法實作兩次，一次是為批處理系統，另一次是為實時系統，還要求查詢得到的是兩個系統結果的合并。
由于存在以上缺點，linkedin的jay kreps提出了kappa架構如圖（i）：
圖（i）
1、使用kafka或其它系統來對需要重新計算的資料進行日志記錄，以及提供給多個訂閱者使用。例如需要重新計算30天内的資料，我們可以在kafka中設定30天的資料保留值。
2、當需要進行重新計算時，啟動流處理作業的第二個執行個體對之前獲得的資料進行處理，之後直接把結果資料放入新的資料輸出表中。
3、當作業完成時，讓應用程式直接讀取新的資料記錄表。
4、停止曆史作業，删除舊的資料輸出表。
kappa架構暫時未做深入了解，在此不做評價。我個人覺得，不同的資料架構有各自的優缺點，我們使用的時候隻能根據應用場景，選擇更合适的架構，才能揚長避短。
big data: principles and best practices of scalable real-time data systems——nathan marz
<a href="http://blog.csdn.net/brucesea/article/details/45937875">http://blog.csdn.net/brucesea/article/details/45937875</a>
<a href="https://zhuanlan.zhihu.com/p/20510974">https://zhuanlan.zhihu.com/p/20510974</a>
<a href="http://www.infoq.com/cn/news/2014/09/lambda-architecture-questions">http://www.infoq.com/cn/news/2014/09/lambda-architecture-questions</a>