【稿件】經(jīng)過多年的發(fā)展，從大數(shù)據(jù)1.0的BI/Datawarehouse時(shí)代，到大數(shù)據(jù)2.0的Web/App過渡期間，再進(jìn)入到IOT的大數(shù)據(jù)3.0時(shí)代，隨之而來的是數(shù)據(jù)架構(gòu)的變化。

10年積累的網(wǎng)站制作、成都網(wǎng)站制作經(jīng)驗(yàn)，可以快速應(yīng)對(duì)客戶對(duì)網(wǎng)站的新想法和需求。提供各種問題對(duì)應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識(shí)你，你也不認(rèn)識(shí)我。但先網(wǎng)站設(shè)計(jì)后付款的網(wǎng)站建設(shè)流程，更有三門峽免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。

2018 年 5 月 18-19 日，由 主辦的全球軟件與運(yùn)維技術(shù)峰會(huì)在北京召開。在“大數(shù)據(jù)處理技術(shù)”分會(huì)場(chǎng)，來自易觀智庫的CTO郭煒先生為我們帶來了《Lambda架構(gòu)已死，新一代的去ELT化IOTA架構(gòu)》的主題演講。

他就Lambda與Kappa架構(gòu)的發(fā)展及優(yōu)缺點(diǎn)展開，分享IOTA大數(shù)據(jù)架構(gòu)的思路及優(yōu)缺點(diǎn)，以及易觀在IOTA架構(gòu)領(lǐng)域的實(shí)踐經(jīng)驗(yàn)。

IOTA架構(gòu)的背景

首先介紹我們遇到過的各種數(shù)據(jù)問題和提出IOTA架構(gòu)的背景。

我們的數(shù)據(jù)來源于手機(jī)的SDK。上圖是易觀當(dāng)前的數(shù)據(jù)規(guī)模。如今月活數(shù)已經(jīng)達(dá)到了5.5個(gè)億，其中包含有大概20多億個(gè)用戶畫像(Profile)，并且已“打上了”各種維度的標(biāo)簽。

那么面對(duì)這么多維度的數(shù)據(jù)量，以及層出不窮的新數(shù)據(jù)，我們?cè)撊绾沃С趾酶鞣N數(shù)據(jù)的運(yùn)作呢?

我們先來看看IOTA架構(gòu)的提出背景。上圖右側(cè)是易觀在前兩年構(gòu)建的大數(shù)據(jù)架構(gòu)，底層是SDK采集各類數(shù)據(jù)的過程。

由于每天都會(huì)有幾百億條的數(shù)據(jù)量，因此我們?cè)赟DK上采取的是“云+端”的控制策略，以避免底層SDK淪為導(dǎo)流層。

目前我們使用的接收帶寬已達(dá)到6個(gè)GB。當(dāng)有并發(fā)數(shù)據(jù)傳到我們的接收端時(shí)，可能會(huì)出現(xiàn)幾個(gè)GB以上的流量爆增，因此我們要避免這種類似DDoS情況的出現(xiàn)。

在底層上面，我們基于Kafka自行定制了各種內(nèi)部使用的隊(duì)列與分發(fā)。與此同時(shí)，我們實(shí)現(xiàn)了多方的HDFS查詢，并基于此構(gòu)建了批量查詢的Hive。

對(duì)于前端的各種產(chǎn)品，我們用Greenplum實(shí)現(xiàn)了Ad—hoc查詢。同時(shí)，我們用Presto來滿足內(nèi)部分析師的各種查詢需求。

圖中的右側(cè)部分是內(nèi)部的一些數(shù)據(jù)治理服務(wù)，包括對(duì)源數(shù)據(jù)的管理、數(shù)據(jù)口徑與質(zhì)量的檢測(cè)、以及左側(cè)綠色的各種調(diào)度服務(wù)。

上述便是我們?cè)谇皟赡陿?gòu)建的內(nèi)部大數(shù)據(jù)結(jié)構(gòu)。當(dāng)然，我們也遇到了如下各種問題：

• 如今IoT的時(shí)代已經(jīng)來臨，各種智能硬件設(shè)備接踵而至，包括智能手環(huán)，醫(yī)用糖尿病篩查設(shè)備、智能WiFi、BCON和智能攝像頭等。隨著數(shù)據(jù)越來越復(fù)雜，簡(jiǎn)單的移動(dòng)客戶端已經(jīng)無法滿足我們采集和分析數(shù)據(jù)的需求了。
• 隨著IoT設(shè)備的面市和產(chǎn)生的巨大數(shù)據(jù)量級(jí)，其采集頻次遠(yuǎn)大于人工點(diǎn)擊，這給整個(gè)架構(gòu)帶來了更大的挑戰(zhàn)。
• 數(shù)據(jù)格式不統(tǒng)一，例如一種云攝像頭的數(shù)據(jù)格式，就不一定與其他廠商的IoT攝像頭相同。
• 數(shù)據(jù)格式多變，會(huì)導(dǎo)致業(yè)務(wù)查詢的頻繁變更。我們易觀的70多名分析師，他們所要求的數(shù)據(jù)類型，每天都不盡相同。
•  數(shù)據(jù)需要能夠被實(shí)時(shí)地查詢到。

我們以轉(zhuǎn)化查詢?yōu)槔耗彻疽陔p十一大促的活動(dòng)中，查詢一下自己前一個(gè)小時(shí)廣告投放的效果、以及價(jià)格波動(dòng)對(duì)于用戶***購買的影響。這些都屬于Ad-hoc式查詢。

Lambda架構(gòu)

我們回頭來看Lambda架構(gòu)。如今80%～90%的企業(yè)都在使用Lambda架構(gòu)進(jìn)行自己的大數(shù)據(jù)分析，包括我們自己也是從Lambda架構(gòu)過渡而來。

如圖所示，所有的數(shù)據(jù)采集都是從最左側(cè)進(jìn)入架構(gòu)的。根據(jù)不同的SDK，各種數(shù)據(jù)源所采集到的數(shù)據(jù)格式會(huì)有所不同。它們?cè)诖藚R聚到我們?cè)贫说拇髷?shù)據(jù)平臺(tái)。

我們通過兩條線來保證數(shù)據(jù)的實(shí)時(shí)性和有效性：

• 通過傳統(tǒng)的ETL，我們將數(shù)據(jù)做成批量任務(wù)—Batch Data，每晚運(yùn)行一次，次日早上我們?nèi)ゲ榭聪嚓P(guān)的數(shù)據(jù)結(jié)果。
• 為了保證實(shí)時(shí)地采集，例如：需要根據(jù)銷售量來做出智能推薦的決策，或是查看當(dāng)日的PV/UV，那么我們就去“跑”一些Data Streaming(數(shù)據(jù)流)。

上述兩條線的結(jié)果，最終都被放入一個(gè)Result Database(結(jié)果數(shù)據(jù)庫，如某個(gè)MySQL)中，以方便我們的前端應(yīng)用，通過該數(shù)據(jù)庫，來查詢后端的數(shù)據(jù)。

但是，該架構(gòu)存在著如下問題：

1. 業(yè)務(wù)方會(huì)發(fā)現(xiàn)，次日看到的數(shù)據(jù)比昨晚看到的要少。原因在于：數(shù)據(jù)在被放入Result Database時(shí),走了兩條線的計(jì)算方式：一條線是ETL按照某個(gè)口徑“跑”過來，得到更為準(zhǔn)確的批量處理結(jié)果;另一條線是通過Streaming“跑”過來，依靠Hadoop Hive或其他算法得出的實(shí)時(shí)性結(jié)果。當(dāng)然它犧牲了部分的準(zhǔn)確性。可見，這兩個(gè)來自批量的和實(shí)時(shí)的數(shù)據(jù)結(jié)果是對(duì)不上的，因此大家覺得很困惑。

2. 針對(duì)每一次實(shí)時(shí)分析的需求，都需要用Data Streaming重新開發(fā)一次。無論您是用Storm、Spark Streaming還是Flink，只要你想查看某個(gè)結(jié)果，就必須開發(fā)一次流式計(jì)算。也就是說，我們要按需做各種各樣的ETL開發(fā)，這顯然效率不高。

3. 我們做數(shù)據(jù)清洗的目的就是為了得到更好的數(shù)據(jù)格式，然后放到大數(shù)據(jù)平臺(tái)之上。但是由于平臺(tái)需要通過處理，來適配不同的采集格式，因此，我們無法迅速地呈現(xiàn)不同領(lǐng)域的實(shí)時(shí)數(shù)據(jù)。

KAPPA架構(gòu)

后來LinkedIn提出了一個(gè)新的架構(gòu)：KAPPA。它的理念是：鑒于大家認(rèn)為批量數(shù)據(jù)和實(shí)時(shí)數(shù)據(jù)對(duì)不上是個(gè)問題，它直接去掉了批量數(shù)據(jù);而直接通過隊(duì)列，放入實(shí)時(shí)數(shù)據(jù)之中。

例如：將所有的數(shù)據(jù)直接放到原來的Kafka中，然后通過Kafka的Streaming，去直接面向***的查詢結(jié)果。

當(dāng)然，該架構(gòu)也存在著一些問題：

1. 不能及時(shí)查詢和訓(xùn)練。例如：我們的分析師想通過一條SQL語句，來查詢前五秒的狀態(tài)數(shù)據(jù)。這對(duì)于KAPPA架構(gòu)是很難去實(shí)現(xiàn)的。

2. 面對(duì)各種需求，它同樣也逃不過每次需要重新做一次Data Streaming。也就是說，它無法實(shí)現(xiàn)Ad—hoc查詢，我們必需針對(duì)某個(gè)需求事先準(zhǔn)備好，才能進(jìn)行數(shù)據(jù)分析。

3. 新數(shù)據(jù)源的結(jié)構(gòu)問題。例如：要新增一臺(tái)智能硬件設(shè)備，我們就要重新開發(fā)一遍它對(duì)應(yīng)的適配格式、負(fù)責(zé)采集的SDK、以及SDK的接收端等，即整體都要重復(fù)開發(fā)一遍。

因此，雖然KAPPA架構(gòu)比Lambda好的方面是不必實(shí)時(shí)地把ETL數(shù)據(jù)做兩遍，但是它仍然存在著結(jié)構(gòu)上的問題。

IOTA架構(gòu)

至此，我們提出了IOTA架構(gòu)。在取名上，它是基于希臘字母的順序，即：從IOTA、到KAPPA、再到Lambda的。

我們首先來看看IOTA架構(gòu)的基本思路。鑒于大家既需要支持實(shí)時(shí)數(shù)據(jù)、又要支持Ad—hoc查詢，還要支持各種數(shù)據(jù)的適配，因此該架構(gòu)必然會(huì)有一些“約束”。

***個(gè)約束：我們應(yīng)事先確定好通用的數(shù)據(jù)模型(Common Data Model)。例如：我們?cè)谧鲇脩粜袨榉治鰰r(shí)，可以通過一種“主-謂-賓”的模型去描述：“誰對(duì)什么做了什么”。而剩下的其他修飾詞，則完全可以被作為其他的列和參數(shù)。

在此模型基礎(chǔ)上，所有的數(shù)據(jù)其實(shí)并非在中央被處理，而是在最開始的SDK端被操作。在此我們可以引入邊緣計(jì)算的概念，即：不是在云端加工數(shù)據(jù)，而是把所有數(shù)據(jù)分散到從數(shù)據(jù)產(chǎn)生到***存儲(chǔ)整個(gè)過程之中。

另外，由于一般公司的業(yè)務(wù)并不會(huì)天天發(fā)生變化，因此我們可以抽象出一套完整的業(yè)務(wù)模型，進(jìn)而實(shí)現(xiàn)在邊緣端做數(shù)據(jù)統(tǒng)一，而不是在云端進(jìn)行。

如上圖中所提到的Common Data Model的示例。我們可以用“主-謂-賓”模型，即“X用戶 – 事件1 – A頁面(2018/4/11 20:00)”來進(jìn)行抽象。

當(dāng)然，我們也可以根據(jù)業(yè)務(wù)的不同需求，使用“產(chǎn)品-事件”、或“地點(diǎn)-時(shí)間”模型。

第二個(gè)約束：對(duì)于同樣的硬件設(shè)備而言，我們完全可以將“X用戶的MAC 地址-出現(xiàn)- A樓層(2018/4/11 18:00)”模型，與前面提到的“主-謂-賓”模型統(tǒng)一成一種。

也就是說，無論是App小程序、Web頁面、攝像頭、還是IoT智能WiFi，只要數(shù)據(jù)模型是統(tǒng)一的，你就能夠在數(shù)據(jù)產(chǎn)生端，統(tǒng)一整體的數(shù)據(jù)格式。

第三個(gè)約束：由于云端的數(shù)據(jù)只負(fù)責(zé)存儲(chǔ)和查詢，而不再負(fù)責(zé)做加工。

因此在IOTA架構(gòu)中，有著如下主要的組成部分：

• Real Time Data Cache，對(duì)于海量的實(shí)時(shí)數(shù)據(jù)，我們會(huì)存儲(chǔ)到云端，但是在將它們直接導(dǎo)入數(shù)據(jù)庫的時(shí)候則會(huì)產(chǎn)生延遲，因此我們需要選用Hbase或Kudu之類的組件，來實(shí)現(xiàn)簡(jiǎn)單的列式存儲(chǔ)。
• Historical Data，針對(duì)的是大量歷史數(shù)據(jù)的底層存儲(chǔ)，我們可以在云端用到HDFS。而之所以不將實(shí)時(shí)數(shù)據(jù)直接接入HDFS，是為了避免產(chǎn)生大量的碎片文件，而影響到最終的查詢效率。
• Dumper，該程序?qū)崿F(xiàn)并銜接了從Real Time Data Cache到數(shù)據(jù)的存儲(chǔ)。我們可以按照既定的規(guī)則(每五分鐘、或到達(dá)一百萬條數(shù)據(jù)時(shí))，將Real Time Data Cache“落”到HDFS文件中。同時(shí)，我們也可以添加相關(guān)的索引，為后面的Query Engine做好準(zhǔn)備。
• Query Engine，它可以用到的計(jì)算引擎包括：Spark、Presto、Impala等。通過Query Engine，我們既可以查詢存儲(chǔ)在HDFS的底層數(shù)據(jù)，又可以查詢幾分鐘前的實(shí)時(shí)數(shù)據(jù)。另外，通過兩者的合并，分析師還能夠?qū)崿F(xiàn)智能分析。

因此，基本的流程是：底層的SDK先將數(shù)據(jù)的格式予以統(tǒng)一，接著先存放在Cache里，然后再放入Historical Data中。

而在查詢時(shí)，我們可以暴露一個(gè)SQL接口(如：Presto或SparkSQL)，以供分析師們直接查看到幾秒之前的各種數(shù)據(jù)狀態(tài)。

例如：我們可以通過Query Engine查詢到：用戶是如何從登錄頁面最終點(diǎn)擊到了購買頁面，他們所經(jīng)歷的智能路徑和觸發(fā)過的事件等。這些一連串的前后相關(guān)的數(shù)據(jù)都能夠被實(shí)時(shí)地顯示出來，甚至包括一些Ad-hoc的查詢。

總結(jié)

我們?cè)倩仡櫼幌律厦嫣岬降闹匾矫妫?/p>

• 通用數(shù)據(jù)模型非常重要，它貫穿整個(gè)業(yè)務(wù)的始終，從SDK的產(chǎn)生直至***的存儲(chǔ)，以及按需查詢。當(dāng)然，如果模型本身上無法固定，我們則可以用Protobuf在SDK中先行定義一個(gè)模型。在做好了協(xié)議架構(gòu)的基礎(chǔ)上，如果后期需求固定下來了，我們只要保持從底層到上層的模型統(tǒng)一，那么修改起來就十分方便，甚至都不會(huì)涉及到云端存儲(chǔ)的改動(dòng)。
• 數(shù)據(jù)緩沖區(qū)，主要用來減少索引的延遲和歷史數(shù)據(jù)的碎片等問題。
• 歷史數(shù)據(jù)沉浸區(qū)，主要是為了Ad-hoc查詢，其包括建立好各種相關(guān)的索引，以實(shí)現(xiàn)秒級(jí)的結(jié)果返回。
• SDK，過去我們只是讓SDK進(jìn)行簡(jiǎn)單地埋點(diǎn)和采集，而如今，我們?cè)赟DK上增加了一些簡(jiǎn)單的計(jì)算，讓數(shù)據(jù)在產(chǎn)生端就完成了轉(zhuǎn)化。
• 如果產(chǎn)生端(如攝像頭)的性能不夠，我們可以為它添加一臺(tái)專門用作轉(zhuǎn)化的EdgeAIServer服務(wù)器，從而實(shí)現(xiàn)上述提到的“主-謂-賓”模型的格式輸出。當(dāng)然，對(duì)于App和H5頁面來說，由于沒有計(jì)算的工作量，因此只要求埋點(diǎn)格式即可。

根據(jù)上述對(duì)于IOTA模型的介紹，我們對(duì)原來的大數(shù)據(jù)系統(tǒng)做了相應(yīng)的調(diào)整。

具體情況如下：

• 我們的數(shù)據(jù)查詢已不再需要ETL，而是通過Query Engine實(shí)現(xiàn)了數(shù)據(jù)的各種留存、轉(zhuǎn)化、營(yíng)銷和分析等操作。
• 針對(duì)查詢服務(wù)，我們基于Presto進(jìn)行了二次開發(fā)，并構(gòu)建出了“秒算平臺(tái)”。
• 對(duì)應(yīng)上面提到過的“主-謂-賓”模型，我們相應(yīng)地制定了兩個(gè)主要的數(shù)據(jù)存儲(chǔ)結(jié)構(gòu)：“用戶/事件”，即：“誰在哪發(fā)生了什么”。
• 為了保證緩存中的數(shù)據(jù)能夠被順利地“灌”入Historical Data所對(duì)應(yīng)的存儲(chǔ)區(qū)域，我們配置了DumpMR服務(wù)模塊。
• 針對(duì)“灌入”的數(shù)據(jù)會(huì)被分成很多個(gè)文件，如：每十分鐘產(chǎn)生一個(gè)文件的情況，我們配置了MergerMR服務(wù)模塊，它能夠?qū)⑦@些碎片化的多個(gè)文件合并成為一個(gè)大的存儲(chǔ)塊。另外，我們還為這些數(shù)據(jù)重新添加了索引，以方便實(shí)時(shí)地進(jìn)行計(jì)算。
• 在“秒算平臺(tái)”上，我們運(yùn)用Hbase來對(duì)實(shí)時(shí)數(shù)據(jù)進(jìn)行緩存，并用HDFS來對(duì)歷史數(shù)據(jù)進(jìn)行存儲(chǔ)。
• 由于我們將Presto作為查詢服務(wù)引擎，為了能讓它能夠連接HDFS和Hbase，我們自行研發(fā)了一些Connector。通過我們的二次開發(fā)，它能夠支持諸如MySQL、Redis和MongoDB等各種第三方數(shù)據(jù)庫的查詢。
• 我們對(duì)從用戶處收集來的大數(shù)據(jù)，根據(jù)上面提到的“用戶/事件”和“主-謂-賓”模型，直接放到SDK里，進(jìn)行相關(guān)的計(jì)算。

眾所周知，任何一種軟件只有經(jīng)歷了開放源代碼，才能夠不斷地促進(jìn)自己的完善與發(fā)展。雖然我們的系統(tǒng)目前尚屬內(nèi)部版本，但是我們計(jì)劃在今年底，將上述提到的基于IOTA架構(gòu)模型的“秒算平臺(tái)”開源出來，以供大家使用。

有了這樣的平臺(tái)，大家可以基于其存儲(chǔ)引擎來快速地進(jìn)行二次開發(fā)，而不必自己去寫HDFS、Connector、DumpMR、MergerMR、以及一大堆Profile相關(guān)的代碼。我們會(huì)把這些“坑”事先幫大家“填好”，大家直接用它去做用戶級(jí)別的數(shù)據(jù)分析便可。

目前，就易觀大數(shù)據(jù)混合云的數(shù)據(jù)規(guī)模和性能而言，已經(jīng)能夠根據(jù)我們分析師的各種Ad-hoc數(shù)據(jù)查詢需求，實(shí)現(xiàn)了秒級(jí)的結(jié)果返回。同時(shí)，我們內(nèi)部的秒算服務(wù)引擎，也能夠支持并提供帶有各種分析結(jié)果的分析報(bào)告。

郭煒，現(xiàn)任易觀CTO，負(fù)責(zé)易觀整體技術(shù)架構(gòu)及分析產(chǎn)品線。北大計(jì)算系本科與研究生，在Teradata，IBM，中金負(fù)責(zé)大數(shù)據(jù)方向架構(gòu)師或研發(fā)總監(jiān)，后任萬達(dá)電商數(shù)據(jù)部總經(jīng)理，聯(lián)想研究院大數(shù)據(jù)總監(jiān)。在電商、移動(dòng)互聯(lián)網(wǎng)、商業(yè)地產(chǎn)、百貨、移動(dòng)通信、零售、院線等多個(gè)業(yè)務(wù)領(lǐng)域大數(shù)據(jù)方面具有搭建團(tuán)隊(duì)、系統(tǒng)以及分領(lǐng)域的分析與算法經(jīng)驗(yàn)。

【原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文作者和出處為.com】

網(wǎng)頁題目：Lambda架構(gòu)已死，基于IOTA模型的“秒算平臺(tái)”架構(gòu)實(shí)踐
轉(zhuǎn)載來于：http://uogjgqi.cn/article/dpeesjp.html