▌lambda架構
在過去lambda資料架構成為每乙個公司大資料平台必備的架構，它解決了乙個公司大資料批量離線處理和實時資料處理的需求。乙個典型的lambda架構如下：
資料從底層的資料來源開始，經過各種各樣的格式進入大資料平台，在大資料平台中經過kafka、flume等資料元件進行收集，然後分成兩條線進行計算。一條線是進入流式計算平台（例如 storm、flink或者spark streaming），去計算實時的一些指標；另一條線進入批量資料處理離線計算平台（例如mapreduce、hive，spark sql），去計算t+1的相關業務指標，這些指標需要隔日才能看見。
lambda架構經歷多年的發展，其優點是穩定，對於實時計算部分的計算成本可控，批量處理可以用晚上的時間來整體批量計算，這樣把實時計算和離線計算高峰分開，這種架構支撐了資料行業的早期發展，但是它也有一些致命缺點，並在大資料3.0時代越來越不適應資料分析業務的需求。缺點如下：
● 實時與批量計算結果不一致引起的資料口徑問題：因為批量和實時計算走的是兩個計算框架和計算程式，算出的結果往往不同，經常看到乙個數字當天看是乙個資料，第二天看昨天的資料反而發生了變化。
● 批量計算在計算視窗內無法完成：在iot時代，資料量級越來越大，經常發現夜間只有4、5個小時的時間視窗，已經無法完成白天20多個小時累計的資料，保證早上上班前準時出資料已成為每個大資料團隊頭疼的問題。
●資料來源變化都要重新開發，開發周期長：每次資料來源的格式變化，業務的邏輯變化都需要針對etl和streaming做開發修改，整體開發周期很長，業務反應不夠迅速。
● 伺服器儲存大：資料倉儲的典型設計，會產生大量的中間結果表，造成資料急速膨脹，加大伺服器儲存壓力。
1.用kafka或者類似mq佇列系統收集各種各樣的資料，你需要幾天的資料量就儲存幾天。
2.當需要全量重新計算時，重新起乙個流計算例項，從頭開始讀取資料進行處理，並輸出到乙個新的結果儲存中。
3.當新的例項做完後，停止老的流計算例項，並把老的一些結果刪除。
● 流式處理對於歷史資料的高吞吐量力不從心：所有的資料都通過流式計算，即便通過加大併發例項數亦很難適應iot時代對資料查詢響應的即時性要求。
iota架構
而在iot大潮下，智慧型手機、pc、智慧型硬體裝置的計算能力越來越強，而業務需求要求資料實時響應需求能力也越來越強，過去傳統的中心化、非實時化資料處理的思路已經不適應現在的大資料分析需求，我提出新一代的大資料iota架構來解決上述問題，整體思路是設定標準資料模型，通過邊緣計算技術把所有的計算過程分散在資料產生、計算和查詢過程當中，以統一的資料模型貫穿始終，從而提高整體的預算效率，同時滿足即時計算的需要，可以使用各種ad-hoc query來查詢底層資料。
關於iota架構的分析請查閱附件！
下一代微服務架構 Service Mesh
service mesh 是什麼？為什麼我們需要它？service mesh 服務網格 是乙個基礎設施層，讓服務之間的通訊更安全 快速和可靠。如果你在構建雲原生應用，那麼就需要 service mesh。在過去的一年中，service mesh 已經成為雲原生技術棧裡的乙個關鍵元件。很多擁有高負載流...
大資料及下一代基礎設施
什麼是大資料？對於大資料的概念，這裡給出的定義是超出現有資料庫系統處理能力的資料。由於過快的資料產生速度，以及規模巨大的資料量，這就要求使用合適的系統來處理它們。大資料的價值主要可以分為兩種 資料分析 開發新產品。大資料分析能夠揭露消費行為及趨勢，如消費者如何受到同齡人的影響。對開發新產品而言，通過...
DataWorks 下一代智慧型資料工場
阿里巴巴從2009年開始從hadoop搭建資料平台體系,資料工場與以前體系一脈相承,有了資料工場後,大家不用再自建資料工場,資料平台會建立乙個雲服務。從自建水電煤廠 水電煤成為基礎設施服務 從自建it資料中心 使用雲計算服務，雲計算本質上解決了運維問題 從自建大資料平台 使用雲資料平台服務 資料工場...