【大資料】Lambda架構已死,去ETL化的IOTA才是未來
經過這麼多年的發展,已經從大資料1.0的BI/Datawarehouse時代,經過大資料2.0的Web/APP過渡,進入到了IOT的大資料3.0時代,而隨之而來的是資料架構的變化。
▌Lambda架構
在過去Lambda資料架構成為每一個公司大資料平臺必備的架構,它解決了一個公司大資料批量離線處理和實時資料處理的需求。一個典型的Lambda架構如下:
資料從底層的資料來源開始,經過各種各樣的格式進入大資料平臺,在大資料平臺中經過Kafka、Flume等資料元件進行收集,然後分成兩條線進行計算。一條線是進入流式計算平臺(例如 Storm、Flink或者Spark Streaming),去計算實時的一些指標;另一條線進入批量資料處理離線計算平臺(例如Mapreduce、Hive,Spark SQL),去計算T+1的相關業務指標,這些指標需要隔日才能看見。
Lambda架構經歷多年的發展,其優點是穩定,對於實時計算部分的計算成本可控,批量處理可以用晚上的時間來整體批量計算,這樣把實時計算和離線計算高峰分開,這種架構支撐了資料行業的早期發展,但是它也有一些致命缺點,並在大資料3.0時代越來越不適應資料分析業務的需求。缺點如下:
● 實時與批量計算結果不一致引起的資料口徑問題:因為批量和實時計算走的是兩個計算框架和計算程式,算出的結果往往不同,經常看到一個數字當天看是一個資料,第二天看昨天的資料反而發生了變化。
● 批量計算在計算視窗內無法完成:在IOT時代,資料量級越來越大,經常發現夜間只有4、5個小時的時間視窗,已經無法完成白天20多個小時累計的資料,保證早上上班前準時出資料已成為每個大資料團隊頭疼的問題。
●資料來源變化都要重新開發,開發週期長:每次資料來源的格式變化,業務的邏輯變化都需要針對ETL和Streaming做開發修改,整體開發週期很長,業務反應不夠迅速。
● 伺服器儲存大:資料倉儲的典型設計,會產生大量的中間結果表,造成資料急速膨脹,加大伺服器儲存壓力。
▌Kappa架構
針對Lambda架構的需要維護兩套程式等以上缺點,LinkedIn的Jay Kreps結合實際經驗和個人體會提出了Kappa架構。Kappa架構的核心思想是通過改進流計算系統來解決資料全量處理的問題,使得實時計算和批處理過程使用同一套程式碼。此外Kappa架構認為只有在有必要的時候才會對歷史資料進行重複計算,而如果需要重複計算時,Kappa架構下可以啟動很多個例項進行重複計算。
一個典型的Kappa架構如下圖所示:
Kappa架構的核心思想,包括以下三點:
1.用Kafka或者類似MQ佇列系統收集各種各樣的資料,你需要幾天的資料量就儲存幾天。
2.當需要全量重新計算時,重新起一個流計算例項,從頭開始讀取資料進行處理,並輸出到一個新的結果儲存中。
3.當新的例項做完後,停止老的流計算例項,並把老的一些結果刪除。
Kappa架構的優點在於將實時和離線程式碼統一起來,方便維護而且統一了資料口徑的問題。而Kappa的缺點也很明顯:
● 流式處理對於歷史資料的高吞吐量力不從心:所有的資料都通過流式計算,即便通過加大併發例項數亦很難適應IOT時代對資料查詢響應的即時性要求。
● 開發週期長:此外Kappa架構下由於採集的資料格式的不統一,每次都需要開發不同的Streaming程式,導致開發週期長。
● 伺服器成本浪費:Kappa架構的核心原理依賴於外部高效能儲存redis,hbase服務。但是這2種系統元件,又並非設計來滿足全量資料儲存設計,對伺服器成本嚴重浪費。
▌IOTA架構
而在IOT大潮下,智慧手機、PC、智慧硬體裝置的計算能力越來越強,而業務需求要求資料實時響應需求能力也越來越強,過去傳統的中心化、非實時化資料處理的思路已經不適應現在的大資料分析需求,我提出新一代的大資料IOTA架構來解決上述問題,整體思路是設定標準資料模型,通過邊緣計算技術把所有的計算過程分散在資料產生、計算和查詢過程當中,以統一的資料模型貫穿始終,從而提高整體的預算效率,同時滿足即時計算的需要,可以使用各種Ad-hoc Query來查詢底層資料:
IOTA整體技術結構分為幾部分:
● Common Data Model:貫穿整體業務始終的資料模型,這個模型是整個業務的核心,要保持SDK、cache、歷史資料、查詢引擎保持一致。對於使用者資料分析來講可以定義為“主-謂-賓”或者“物件-事件”這樣的抽象模型來滿足各種各樣的查詢。以大家熟悉的APP使用者模型為例,用“主-謂-賓”模型描述就是“X使用者 – 事件1 – A頁面(2018/4/11 20:00) ”。當然,根據業務需求的不同,也可以使用“產品-事件”、“地點-時間”模型等等。模型本身也可以根據協議(例如 protobuf)來實現SDK端定義,中央儲存的方式。此處核心是,從SDK到儲存到處理是統一的一個Common Data Model。
●Edge SDKs & Edge Servers:這是資料的採集端,不僅僅是過去的簡單的SDK,在複雜的計算情況下,會賦予SDK更復雜的計算,在裝置端就轉化為形成統一的資料模型來進行傳送。例如對於智慧Wi-Fi採集的資料,從AC端就變為“X使用者的MAC 地址-出現- A樓層(2018/4/11 18:00)”這種主-謂-賓結構,對於攝像頭會通過Edge AI Server,轉化成為“X的Face特徵- 進入- A火車站(2018/4/11 20:00)”。也可以是上面提到的簡單的APP或者頁面級別的“X使用者 – 事件1 – A頁面(2018/4/11 20:00) ”,對於APP和H5頁面來講,沒有計算工作量,只要求埋點格式即可。
● Real Time Data:實時資料快取區,這部分是為了達到實時計算的目的,海量資料接收不可能海量實時入歷史資料庫,那樣會出現建立索引延遲、歷史資料碎片檔案等問題。因此,有一個實時資料快取區來儲存最近幾分鐘或者幾秒鐘的資料。這塊可以使用Kudu或者Hbase等元件來實現。這部分資料會通過Dumper來合併到歷史資料當中。此處的資料模型和SDK端資料模型是保持一致的,都是Common Data Model,例如“主-謂-賓”模型。
● Historical Data:歷史資料沉浸區,這部分是儲存了大量的歷史資料,為了實現Ad-hoc查詢,將自動建立相關索引提高整體歷史資料查詢效率,從而實現秒級複雜查詢百億條資料的反饋。例如可以使用HDFS儲存歷史資料,此處的資料模型依然SDK端資料模型是保持一致的Common Data Model。
● Dumper:Dumper的主要工作就是把最近幾秒或者幾分鐘的實時資料,根據匯聚規則、建立索引,儲存到歷史儲存結構當中,可以使用map reduce、C、Scala來撰寫,把相關的資料從Realtime Data區寫入Historical Data區。
● Query Engine:查詢引擎,提供統一的對外查詢介面和協議(例如SQL JDBC),把Realtime Data和Historical Data合併到一起查詢,從而實現對於資料實時的Ad-hoc查詢。例如常見的計算引擎可以使用presto、impala、clickhouse等。
● Realtime model feedback:通過Edge computing技術,在邊緣端有更多的互動可以做,可以通過在Realtime Data去設定規則來對Edge SDK端進行控制,例如,資料上傳的頻次降低、語音控制的迅速反饋,某些條件和規則的觸發等等。簡單的事件處理,將通過本地的IOT端完成,例如,嫌疑犯的識別現在已經有很多攝像頭本身帶有此功能。
IOTA大資料架構,主要有如下幾個特點:
●去ETL化:ETL和相關開發一直是大資料處理的痛點,IOTA架構通過Common Data Model的設計,專注在某一個具體領域的資料計算,從而可以從SDK端開始計算,中央端只做採集、建立索引和查詢,提高整體資料分析的效率。
● Ad-hoc即時查詢:鑑於整體的計算流程機制,在手機端、智慧IOT事件發生之時,就可以直接傳送到雲端進入real time data區,可以被前端的Query Engine來查詢。此時使用者可以使用各種各樣的查詢,直接查到前幾秒發生的事件,而不用在等待ETL或者Streaming的資料研發和處理。
● 邊緣計算(Edge-Computing):將過去統一到中央進行整體計算,分散到資料產生、儲存和查詢端,資料產生既符合Common Data Model。同時,也給與Realtime model feedback,讓客戶端傳送資料的同時馬上進行反饋,而不需要所有事件都要到中央端處理之後再進行下發。
如上圖,IOTA架構有各種各樣的實現方法,為了驗證IOTA架構,易觀也自主設計並實現了“秒算”引擎,目前支援易觀內部月活5.5億裝置端進行計算的同時,也基於“秒算”引擎研發出了可以獨立部署在企業客戶內,進行數字使用者分析和營銷的“易觀方舟”,可以訪問ark.analysys.cn進行體驗。
在大資料3.0時代,Lambda大資料架構已經無法滿足企業使用者日常大資料分析和精益運營的需要,去ETL化的IOTA大資料架構才是未來。
人工智慧賽博物理作業系統
AI-CPS OS
“人工智慧賽博物理作業系統”(新一代技術+商業作業系統“AI-CPS OS”:雲端計算+大資料+物聯網+區塊鏈+人工智慧)分支用來的今天,企業領導者必須瞭解如何將“技術”全面滲入整個公司、產品等“商業”場景中,利用AI-CPS OS形成數字化+智慧化力量,實現行業的重新佈局、企業的重新構建和自我的煥然新生。
AI-CPS OS的真正價值並不來自構成技術或功能,而是要以一種傳遞獨特競爭優勢的方式將自動化+資訊化、智造+產品+服務和資料+分析一體化,這種整合方式能夠釋放新的業務和運營模式。如果不能實現跨功能的更大規模融合,沒有顛覆現狀的意願,這些將不可能實現。
領導者無法依靠某種單一戰略方法來應對多維度的數字化變革。面對新一代技術+商業作業系統AI-CPS OS顛覆性的數字化+智慧化力量,領導者必須在行業、企業與個人這三個層面都保持領先地位:
重新行業佈局:你的世界觀要怎樣改變才算足夠?你必須對行業典範進行怎樣的反思?
重新構建企業:你的企業需要做出什麼樣的變化?你準備如何重新定義你的公司?
重新打造自己:你需要成為怎樣的人?要重塑自己並在數字化+智慧化時代保有領先地位,你必須如何去做?
AI-CPS OS是數字化智慧化創新平臺,設計思路是將大資料、物聯網、區塊鏈和人工智慧等無縫整合在雲端,可以幫助企業將創新成果融入自身業務體系,實現各個前沿技術在雲端的優勢協同。AI-CPS OS形成的數字化+智慧化力量與行業、企業及個人三個層面的交叉,形成了領導力模式,使數字化融入到領導者所在企業與領導方式的核心位置:
精細:這種力量能夠使人在更加真實、細緻的層面觀察與感知現實世界和數字化世界正在發生的一切,進而理解和更加精細地進行產品個性化控制、微觀業務場景事件和結果控制。
智慧:模型隨著時間(資料)的變化而變化,整個系統就具備了智慧(自學習)的能力。
高效:企業需要建立實時或者準實時的資料採集傳輸、模型預測和響應決策能力,這樣智慧就從批量性、階段性的行為變成一個可以實時觸達的行為。
不確定性:數字化變更顛覆和改變了領導者曾經仰仗的思維方式、結構和實踐經驗,其結果就是形成了複合不確定性這種顛覆性力量。主要的不確定性蘊含於三個領域:技術、文化、制度。
邊界模糊:數字世界與現實世界的不斷融合成CPS不僅讓人們所知行業的核心產品、經濟學定理和可能性都產生了變化,還模糊了不同行業間的界限。這種效應正在向生態系統、企業、客戶、產品快速蔓延。
AI-CPS OS形成的數字化+智慧化力量通過三個方式激發經濟增長:
創造虛擬勞動力,承擔需要適應性和敏捷性的複雜任務,即“智慧自動化”,以區別於傳統的自動化解決方案;
對現有勞動力和實物資產進行有利的補充和提升,提高資本效率;
人工智慧的普及,將推動多行業的相關創新,開闢嶄新的經濟增長空間。
給決策制定者和商業領袖的建議:
超越自動化,開啟新創新模式:利用具有自主學習和自我控制能力的動態機器智慧,為企業創造新商機;
迎接新一代資訊科技,迎接人工智慧:無縫整合人類智慧與機器智慧,重新
評估未來的知識和技能型別;
制定道德規範:切實為人工智慧生態系統制定道德準則,並在智慧機器的開
發過程中確定更加明晰的標準和最佳實踐;
重視再分配效應:對人工智慧可能帶來的衝擊做好準備,制定戰略幫助面臨
較高失業風險的人群;
開發數字化+智慧化企業所需新能力:員工團隊需要積極掌握判斷、溝通及想象力和創造力等人類所特有的重要能力。對於中國企業來說,創造兼具包容性和多樣性的文化也非常重要。
子曰:“君子和而不同,小人同而不和。” 《論語·子路》雲端計算、大資料、物聯網、區塊鏈和 人工智慧,像君子一般融合,一起體現科技就是生產力。
如果說上一次哥倫布地理大發現,擴充的是人類的物理空間。那麼這一次地理大發現,擴充的就是人們的數字空間。在數學空間,建立新的商業文明,從而發現新的創富模式,為人類社會帶來新的財富空間。雲端計算,大資料、物聯網和區塊鏈,是進入這個數字空間的船,而人工智慧就是那船上的帆,哥倫布之帆!
新一代技術+商業的人工智慧賽博物理作業系統AI-CPS OS作為新一輪產業變革的核心驅動力,將進一步釋放歷次科技革命和產業變革積蓄的巨大能量,並創造新的強大引擎。重構生產、分配、交換、消費等經濟活動各環節,形成從巨集觀到微觀各領域的智慧化新需求,催生新技術、新產品、新產業、新業態、新模式。引發經濟結構重大變革,深刻改變人類生產生活方式和思維模式,實現社會生產力的整體躍升。
產業智慧官 AI-CPS
用“人工智慧賽博物理作業系統”(新一代技術+商業作業系統“AI-CPS OS”:雲端計算+大資料+物聯網+區塊鏈+人工智慧),在場景中構建狀態感知-實時分析-自主決策-精準執行-學習提升的認知計算和機器智慧;實現產業轉型升級、DT驅動業務、價值創新創造的產業互聯生態鏈。
長按上方二維碼關注微信公眾號: AI-CPS,更多資訊回覆:
新技術:“雲端計算”、“大資料”、“物聯網”、“區塊鏈”、“人工智慧”;新產業:“智慧製造”、“智慧金融”、“智慧零售”、“智慧駕駛”、“智慧城市”;新模式:“財富空間”、“工業網際網路”、“資料科學家”、“賽博物理系統CPS”、“供應鏈金融”。
官方網站:AI-CPS.NET
本文系“產業智慧官”(公眾號ID:AI-CPS)收集整理,轉載請註明出處!
版權宣告:由產業智慧官(公眾號ID:AI-CPS)推薦的文章,除非確實無法確認,我們都會註明作者和來源。部分文章推送時未能與原作者取得聯絡。若涉及版權問題,煩請原作者聯絡我們,與您共同協商解決。聯絡、投稿郵箱:erp_vip@hotmail.com
相關文章
- 虛擬機器已死,容器才是未來?虛擬機
- 大資料,未來已來大資料
- 資料庫容器化|未來已來資料庫
- 大資料Lambda架構概念及應用大資料架構
- Data Fabric:資料管理的未來已來
- 大資料的未來大資料
- 資料整合的兩種架構:ELT和ETL架構
- 阿里架構師眼中Dubbo的過去,現在以及未來阿里架構
- 【虹科乾貨】Lambda資料架構和Kappa資料架構——構建現代資料架構架構APP
- 面向未來,我們來聊一聊什麼是現代化資料架構架構
- 資料分析的三大時間軸:過去、現在和未來
- Dun:資料的過去、現在和未來
- 大資料的未來–資料資訊圖大資料
- 大資料的緣起、發展和未來構思大資料
- 怎樣的架構設計才是真正的資料倉儲架構(轉載)架構
- 資料庫已死資料庫
- 螞蟻金服首席架構師何昌華:開源SQLFlow是牛刀初試,實時大資料系統才是未來基石架構SQL大資料
- 向死而生:中國獨立遊戲的過去、現在與未來遊戲
- 大資料的未來掌控於資料整合大資料
- 大規模資料傳輸,知易行難 — 資料傳輸與 ETL 平臺的架構演進架構
- 大資料未來發展大資料
- 大資料架構師大資料架構
- 大資料架構和模式(三)——理解大資料解決方案的架構層大資料架構模式
- Coursera資料工程師董飛:矽谷大資料的過去與未來(圖靈訪談)工程師大資料圖靈
- SOA:編織未來IT架構架構
- 中國未來經濟架構架構
- Blink開源,Spark3.0,誰才是未來大資料領域最閃亮的星?Spark大資料
- 通過容器化技術RestCloud ETL支援大規模的分散式部署架構RESTCloud分散式架構
- 大資料前景:大資料未來的7個發展方向大資料
- ETL架構師面試題架構面試題
- 健康大資料顛覆未來大資料
- 十張圖看懂未來的大資料世界大資料
- 大資料Big Data的未來:Cassandra大資料
- 大資料時代——未來世界的資料分析法大資料
- Yarn已過時!Kubeflow實現機器學習排程平臺才是未來Yarn機器學習
- 大資料架構和模式(一)——大資料分類和架構簡介大資料架構模式
- 質疑Lambda架構架構
- ETL資料整合平臺,RestCloud視覺化ETLRESTCloud視覺化