本文會簡述大資料分析場景需要解決的技術挑戰，討論目前主流大資料架構模式及其發展。最後我們將介紹如何結合雲上儲存、計算元件，實現更優的通用大資料架構模式，以及該模式可以涵蓋的典型資料處理場景。
現在已經有越來越多的行業和技術領域需求大資料分析系統，例如金融行業需要使用大資料系統結合var(value at risk)或者機器學習方案進行信貸風控，零售、餐飲行業需要大資料系統實現輔助銷售決策，各種iot場景需要大資料系統持續聚合和分析時序資料，各大科技公司需要建立大資料分析中臺等等。
抽象來看，支撐這些場景需求的分析系統，面臨的都是大致相同的技術挑戰：
lambda架構
lambda架構是目前影響最深刻的大資料處理架構，它的核心思想是將不可變的資料以追加的方式並行寫到批和流處理系統內，隨後將相同的計算邏輯分別在流和批系統中實現，並且在查詢階段合併流和批的計算檢視並展示給使用者。lambda的提出者nathan marz還假定了批處理相對簡單不易出現錯誤，而流處理相對不太可靠，因此流處理器可以使用近似演算法，快速產生對檢視的近似更新，而批處理系統會採用較慢的精確演算法，產生相同檢視的校正版本。
圖 1 lambda架構示例
lambda架構典型資料流程是(
所有的資料需要分別寫入批處理層和流處理層；
批處理層兩個職責：(i)管理master dataset(儲存不可變、追加寫的全量資料), (ii)預計算batch view；
服務層對batch view建立索引，以支援低延遲、ad-hoc方式查詢view；
流計算層作為速度層，對實時資料計算近似的real-time view，作為高延遲batch view的補償快速檢視；
所有的查詢需要合併batch view和real-time view；
lambda架構設計推廣了在不可變的事件流上生成檢視，並且可以在必要時重新處理事件的原則，該原則保證了系統隨需求演進時，始終可以建立相應的新檢視出來，切實可行的滿足了不斷變化的歷史資料和實時資料分析需求。
lambda架構的四個挑戰
lambda架構非常複雜，在資料寫入、儲存、對接計算元件以及展示層都有複雜的子課題需要優化：
寫入層上，lambda沒有對資料寫入進行抽象，而是將雙寫流批系統的一致性問題反推給了寫入資料的上層應用；
儲存上，以hdfs為代表的master dataset不支援資料更新，持續更新的資料來源只能以定期拷貝全量snapshot到hdfs的方式保持資料更新，資料延遲和成本比較大；
計算邏輯需要分別在流批框架中實現和執行，而在類似storm的流計算框架和hadoop mr的批處理框架做job開發、除錯、問題調查都是比較複雜的；
結果檢視需要支援低延遲的查詢分析，通常還需要將資料派生到列存分析系統，並保證成本可控；
流批融合的lambda架構
針對lambda架構的問題3，計算邏輯需要分別在流批框架中實現和執行的問題，不少計算引擎已經開始往流批統一的方向去發展，例如spark和flink，從而簡化lambda架構中的計算部分。實現流批統一通常需要支援：1.以相同的處理引擎來處理實時事件和歷史回放事件；2.支援exactly once語義，保證有無故障情況下計算結果完全相同；3.支援以事件發生時間而不是處理時間進行視窗化；
lambda直接支援批處理，因此更適合對歷史資料有很多ad hoc查詢的需求的場景，比如資料分析師需要按任意條件組合對歷史資料進行探索性的分析，並且有一定的實時性需求，期望盡快得到分析結果，批處理可以更直接高效地滿足這些需求；
圖3 uber圍繞hadoop dataset的大資料架構
圖4 kafka + flink + elasticsearch的混合分析系統
lambda plus是基於tablestore和blink打造的雲上存在可以復用、簡化的大資料架構模式，架構方案全serverless即開即用，易搭建免運維。
**儲存（tablestore）是阿里雲自研的nosql多模型資料庫，提供pb級結構化資料儲存、千萬tps以及毫秒級延遲的服務能力，**儲存提供了通道服務（tunnelservice）支援使用者以按序、流式地方式消費寫入**儲存的存量資料和實時資料，同時**儲存還提供了多元索引功能，支援使用者對結果檢視進行實時查詢和分析。
blink是阿里雲在apache flink基礎上深度改進的實時計算平台，blink旨在將流處理和批處理統一，實現了全新的 flink sql 技術棧，在功能上，blink支援現在標準 sql 幾乎所有的語法和語義，在效能上，blink也比社群flink更加強大。
在tablestore + blink的雲上lambda架構中，使用者可以同時使用**儲存作為master dataset和batch&stream view，批處理引擎直讀**儲存產生batch view，同時流計算引擎通過tunnel service流式處理實時資料，持續生成stream view。
圖5 tablestore + blink的lambda plus大資料架構
如上圖5，其具體元件分解：
streaming層:
serving層：
圖6 lambda plus的資料鏈路
針對上述lambda架構1-4的技術問題，lambda plus的解決思路：
針對資料寫入的問題，lambda plus資料只需要寫入**儲存，blink流計算框架通過通道服務api直讀**儲存的實時資料，不需要使用者雙寫佇列或者自己實現資料同步；
儲存上，lambda plus直接使用**儲存作為master dataset，**儲存支援使用者tp系統低延遲讀寫更新，同時也提供了索引功能ad-hoc查詢分析，資料利用率高，容量型**儲存例項也可以保證資料儲存成本可控；
計算上，lambda plus利用blink流批一體計算引擎，統一流批**；
展示層，**儲存提供了多元索引和全域性二級索引功能，使用者可以根據解決檢視的查詢需求和儲存體量，合理選擇索引方式；
總結，**儲存實現了batch view、master dataset直接查詢、stream view的功能全集，blink實現流批統一，tablestore加blink的lambda plus模式可以明顯簡化lambda架構的元件數量，降低搭建和運維難度，拓展使用者資料價值。
使用通道服務精簡架構：
二級索引和多元索引的靈活查詢能力：
基於tablestore和blink的lambda plus架構，適用於基於分布式nosql資料庫儲存資料的大資料分析場景，如iot、時序資料、爬蟲資料、使用者行為日誌資料儲存等，資料量以tb級為主。典型的業務場景如：
雲上資料安全
通過本認證課程，你將 了解資料應該從哪些方面進行安全防護，例如 儲存技術 備份和恢復方案 如何安全地傳輸 該選擇哪種加密演算法等。掌握阿里雲平台上資料安全防護的核心技能，包括 如何實現資料的自動異地備份 如何在雲環境下實現加密儲存 如何生成ssl證書 如何在零 修改的前提下實現站點加密訪問，涉及產品...
SQL大資料優化上
考慮到處理資料一定要結合資料庫自身實際，此篇就先從常用的輔助效能分析工具說起，sql server profiler，效能計數器，執行計畫，sql prompt等工具，也許平時都正在應用，下邊結合自身使用進行介紹。sql server profiler sql server提供的監控工具，在執行命令...
大資料時代 雲架構
關於大資料的資訊鋪天蓋地而來，讓大家看得眼花繚亂。雖然資訊很精彩，我們也看到了大資料背後的價值，但普遍不知道如何下手。yonghong認為，在乙個企業中，超出現有計算機系統處理能力的資料，就是大資料。作為領軍企業，應本著務實的態度，利用較低的成本，通過對大資料進行高速捕獲和實時的分析，以獲取核心業務...