1
雷鋒網(wǎng)按：本文根據(jù)姜偉華博士在數(shù)果智能新產(chǎn)品發(fā)布會(huì) “智能時(shí)代大數(shù)據(jù)實(shí)時(shí)分析技術(shù) DaTalk” 上的演講整理而來。
實(shí)時(shí)大數(shù)據(jù)分析是指對規(guī)模巨大的數(shù)據(jù)進(jìn)行分析，利用大數(shù)據(jù)技術(shù)高效的快速完成分析，達(dá)到近似實(shí)時(shí)的效果，更及時(shí)的反映數(shù)據(jù)的價(jià)值和意義。
所有人都能理解數(shù)據(jù)的時(shí)效性對于數(shù)據(jù)的價(jià)值至關(guān)重要。以唯品會(huì)為例，唯品會(huì)已經(jīng)有一整套非常成熟的離線數(shù)據(jù)倉庫系統(tǒng)。這套系統(tǒng)對于業(yè)務(wù)有非常大的指導(dǎo)意義，但目前碰到的問題是如何將各種計(jì)算、報(bào)表加速，從原來天級(jí)別、小時(shí)級(jí)別，加速到近實(shí)時(shí)來。
這是我們開始實(shí)時(shí)離線融合這個(gè)項(xiàng)目的緣由。該工作我們是從 2016 年下半年開始的，到目前為止它仍然只是一個(gè)半成品，因此這里面包含的很多內(nèi)容并不是最終的結(jié)論，在多數(shù)情況下，它僅僅是以唯品會(huì)的特點(diǎn)為基礎(chǔ)，而不一定能無縫地適用于其他公司產(chǎn)品。我們希望拋磚引玉，對大家有所俾益。
1. 時(shí)效性與大數(shù)據(jù)
第一個(gè)問題是：什么是實(shí)時(shí)（real-time）? 什么是離線（offline）？很多時(shí)候，我們會(huì)當(dāng)然的把實(shí)時(shí)等同于流處理（stream processing），等同于 Storm、Spark Streaming。但其實(shí)所謂實(shí)時(shí)和離線的區(qū)別其實(shí)是從時(shí)延（latency）的角度出發(fā)，如果時(shí)延短的就是實(shí)時(shí)，時(shí)延長的就是離線。
而時(shí)延就是從數(shù)據(jù)產(chǎn)生到計(jì)算出結(jié)果的時(shí)間差，時(shí)延是從端到端的，不僅僅是 Query 的執(zhí)行時(shí)間。采用簡單的式子表示即為：時(shí)延 = 數(shù)據(jù)準(zhǔn)備時(shí)間 + 查詢計(jì)算時(shí)間。
實(shí)時(shí)、近實(shí)時(shí) (near realtime)、離線一般是以時(shí)延的時(shí)間長短為區(qū)分標(biāo)準(zhǔn)。實(shí)時(shí)表示毫秒、秒級(jí)時(shí)延；近實(shí)時(shí)主要是分鐘級(jí)時(shí)延；而離線是時(shí)延超過十分鐘。
而何為批處理、流處理？批處理，也常被稱為 “離線”，即數(shù)據(jù)以一個(gè)完整的數(shù)據(jù)集被處理可以重復(fù)計(jì)算，數(shù)據(jù)在落盤之后定時(shí)或者按需啟動(dòng)計(jì)算。一般情況下，批處理一次處理的數(shù)據(jù)量大，延遲較大，經(jīng)常需要全量計(jì)算。流處理，也常被稱為 “實(shí)時(shí)”，即數(shù)據(jù)以流式的方式（增量）被處理，它與批處理的特點(diǎn)完成相反。
然而實(shí)時(shí)計(jì)算并不等同于流式計(jì)算，即使大多數(shù)實(shí)時(shí)計(jì)算是流式計(jì)算，但很多也可以采用批處理來實(shí)現(xiàn)。同時(shí)，雖然在流式計(jì)算中實(shí)時(shí)或者準(zhǔn)實(shí)時(shí)計(jì)算結(jié)果占了較大比例，流式計(jì)算也完全可能需要較長時(shí)間才能出結(jié)果，比如說 30 分鐘的 window，window 結(jié)束才輸出結(jié)果等。
所以說，實(shí)時(shí)計(jì)算并不等同于流式計(jì)算。業(yè)務(wù)的實(shí)時(shí)化并不一定要借助于流式計(jì)算來實(shí)現(xiàn)。下面我們來看看目前數(shù)據(jù)處理中之所以實(shí)時(shí)化要流式計(jì)算的瓶頸在何處。
2. 現(xiàn)狀及問題
唯品會(huì)是電子商務(wù)網(wǎng)站，數(shù)據(jù)可以分成兩大類： 行為埋點(diǎn)數(shù)據(jù)和交易類數(shù)據(jù)。下圖是交易類數(shù)據(jù)的一條典型處理鏈路，行為類數(shù)據(jù)的處理與之非常類似。
這張圖其實(shí)代表了當(dāng)前大數(shù)據(jù)處理的一種典型架構(gòu)。對于實(shí)時(shí)和離線而言，這兩條路徑是從源頭開始就完全分離的。
對于離線 / 批處理而言，數(shù)據(jù)層層加工。用戶可以簡易地使用 SQL，使用門檻低，并且其工具、理論、系統(tǒng)完備。然而它的延遲性高，并且不可控制（特別是在大促時(shí)）。
對于流式 / 實(shí)時(shí)計(jì)算而言，一切以時(shí)效性為目標(biāo)，鏈路短，數(shù)據(jù)無層次，大量的應(yīng)用直接處理 raw data。所以它的唯一優(yōu)處在于它的時(shí)效性。但是它的開發(fā)難度高，邏輯復(fù)雜，資源需求很大，并且很難保證其數(shù)據(jù)質(zhì)量。同時(shí)，需要為每個(gè)應(yīng)用單獨(dú)去開發(fā)其應(yīng)用邏輯，無法通用化。
對于實(shí)時(shí)應(yīng)用（特別是報(bào)表）來說，對數(shù)是最痛苦的一件事情。典型場景是利用實(shí)時(shí)報(bào)表提供結(jié)果，但仍需要定時(shí)和離線報(bào)表去比對其正確性。一般普遍認(rèn)為離線應(yīng)用的精度要高于實(shí)時(shí)應(yīng)用，但實(shí)時(shí)和離線的處理方法是完全不同的，其開發(fā)方式、方法，處理邏輯、數(shù)據(jù)來源都不一致，導(dǎo)致對數(shù)非常困難。而這其中最根本的是因?yàn)閷?shí)時(shí)和離線從最本源開始就是兩條計(jì)算路徑。要在這完全不同的兩條路徑上對數(shù)，難度就非常非常大了。
我們也一直在反思怎么樣才能更好的支持業(yè)務(wù)的實(shí)時(shí)化。因?yàn)闃I(yè)務(wù)方總是會(huì)在抱怨數(shù)據(jù)不準(zhǔn)，和離線對不上，口徑?jīng)]更新，開發(fā)效率低下，周期時(shí)間長等狀況，明明我們也在努力加班，努力滿足業(yè)務(wù)方要求，卻發(fā)現(xiàn)總是不能滿足業(yè)務(wù)的需求。
3. 實(shí)時(shí)離線融合
目前的實(shí)時(shí)化方法真的是正確的打開方式嗎? 對于這個(gè)問題，我們的理解是：
業(yè)務(wù)需要的是近實(shí)時(shí)。絕大部分業(yè)務(wù)只需要時(shí)延在分鐘、甚至 5~10 分鐘級(jí)別就可以了。并不需要秒級(jí)的時(shí)延。所以用 Storm/Spark Streaming 這樣的流式計(jì)算去實(shí)現(xiàn)，其實(shí)是一種殺雞用牛刀的行為。
業(yè)務(wù)方需要近實(shí)時(shí)，但目前只有實(shí)時(shí)團(tuán)隊(duì)才有能力實(shí)時(shí)化。這個(gè)的原因是流式計(jì)算的開發(fā)門檻太高。但其實(shí)業(yè)務(wù)方是希望以他們?nèi)菀渍瓶氐姆绞綄?shí)現(xiàn)近實(shí)時(shí)，而不是交給實(shí)時(shí)團(tuán)隊(duì)去排期開發(fā)。
基于上面的理解，我們開展了實(shí)時(shí)離線融合這個(gè)項(xiàng)目。這個(gè)項(xiàng)目的目的就是：
讓業(yè)務(wù)方以他們熟悉的批處理方法來實(shí)現(xiàn)近實(shí)時(shí)的計(jì)算。
讓實(shí)時(shí)團(tuán)隊(duì)專注于系統(tǒng)和平臺(tái)，而不是業(yè)務(wù)。
時(shí)延 = 數(shù)據(jù)準(zhǔn)備時(shí)間 + 查詢時(shí)間。目前之所以無法用批處理方法實(shí)現(xiàn)近實(shí)時(shí)的計(jì)算就是因?yàn)檫@兩個(gè)步驟各自花的時(shí)間太長了。如果數(shù)據(jù)準(zhǔn)備速度足夠快，并且計(jì)算速度也足夠敏捷，那么批處理也可以達(dá)到近實(shí)時(shí)的時(shí)延。
對于批處理而言，數(shù)據(jù)準(zhǔn)備時(shí)間 = 定時(shí)調(diào)度時(shí)間 + 數(shù)據(jù)準(zhǔn)備計(jì)算時(shí)間。只有在兩者都很小的情況下，數(shù)據(jù)準(zhǔn)備時(shí)間才能大幅度地縮短。所以對于數(shù)據(jù)準(zhǔn)備來說，使用流式處理來實(shí)現(xiàn)數(shù)據(jù)的實(shí)時(shí)準(zhǔn)備是非常合理的想法。同時(shí)，因?yàn)檫@種數(shù)據(jù)準(zhǔn)備的一般是基礎(chǔ)數(shù)據(jù)，和業(yè)務(wù)邏輯關(guān)系不大，所以也是很適合用流式的方法來實(shí)現(xiàn)的。
實(shí)時(shí)離線融合鏈路圖
在這個(gè)鏈路中，流式計(jì)算、批處理共享相同的數(shù)據(jù)準(zhǔn)備步驟（清洗、打?qū)挘?。這些步驟保證數(shù)據(jù)是在毫秒級(jí)別就能處理完成的。處理完成的數(shù)據(jù)會(huì)落地到 Hive 中去（時(shí)延控制在分鐘級(jí)別）。這樣，Hive 中就有了近實(shí)時(shí)的已經(jīng)準(zhǔn)備好的基礎(chǔ)數(shù)據(jù)。需要近實(shí)時(shí)的應(yīng)用就可以去訪問這些數(shù)據(jù)了。
實(shí)時(shí)數(shù)據(jù)落地 Hive, 即將大批量數(shù)據(jù)實(shí)時(shí)處理之后存入 Hive 中，提供給后端業(yè)務(wù)系統(tǒng)進(jìn)行處理。目前我們的做法是每 5 分鐘一個(gè) Hive 分區(qū)，數(shù)據(jù)按照 event time 落到相應(yīng)的 Hive 分區(qū)，等待一定時(shí)間后關(guān)閉這個(gè)分區(qū)（這里我們借鑒了流處理中的 watermark 概念）。同時(shí)為了與現(xiàn)有的 Hive 分區(qū)保持兼容（即對于一個(gè)已關(guān)閉分區(qū)的兩次查詢應(yīng)該得到相同的結(jié)果），也為了保證分區(qū)能及時(shí)關(guān)閉，規(guī)定若其數(shù)據(jù)在分區(qū)關(guān)閉后才到達(dá)，那么該數(shù)據(jù)將會(huì)落地到下一個(gè)分區(qū)。
對于那些不關(guān)心分區(qū)是否已關(guān)閉，而時(shí)效性要求高的應(yīng)用，其可以在分鐘級(jí)訪問到數(shù)據(jù)（未關(guān)閉的分區(qū)）；而對于大部分應(yīng)用而言，可以選擇分區(qū)關(guān)閉后再查詢（數(shù)據(jù)準(zhǔn)備的時(shí)延就在 5~6 分鐘左右）。
這種數(shù)據(jù)高頻落地也是存在著一些問題的。
第一，小文件過多（為了保證落地時(shí)延，必須增加并發(fā)），會(huì)導(dǎo)致查詢變慢。
第二，以普通磁盤為主的 HDFS（Hadoop 分布式文件系統(tǒng)）時(shí)延不穩(wěn)定（每個(gè)分區(qū)的數(shù)據(jù)快的幾秒就完成，慢的需要幾分鐘）。這就對數(shù)據(jù)落地的 Spark Streaming 任務(wù)帶來了挑戰(zhàn)。
為了改善這些情況，我們對歷史分區(qū) compact 以減少其文件數(shù)； 將普通磁盤為主的 HDFS 替換為 Alluxio 和以 SSD 為主的 HDFS 以減少其落地波動(dòng)。數(shù)據(jù)放在高速文件系統(tǒng)中，不僅對落地波動(dòng)情況有所改善，也可提高讀取速率。
對于和離線系統(tǒng)的無縫對接，我們目前的做法是在每個(gè)分區(qū)關(guān)閉后，向離線調(diào)度系統(tǒng)發(fā)信號(hào)說這個(gè)分區(qū)數(shù)據(jù)準(zhǔn)備完成了，這樣離線調(diào)度系統(tǒng)就可以正常調(diào)度依賴這個(gè)分區(qū)的下游任務(wù)了。
當(dāng)數(shù)據(jù)準(zhǔn)備實(shí)時(shí)化了后，如何縮短離線查詢時(shí)間呢？查詢時(shí)間 = 定時(shí)調(diào)度時(shí)間 + 查詢計(jì)算時(shí)間。要達(dá)到近實(shí)時(shí)，必須減少其調(diào)度時(shí)間與查詢計(jì)算時(shí)間來提高離線應(yīng)用。那么我們需要將高頻調(diào)度定時(shí)為五分鐘甚至小于五分鐘，并且合理地控制資源使用量，在查詢計(jì)算時(shí)，保證其中間結(jié)果不落地，使用 Spark SQL、Presto 替代 Hive，并且使用 ElasticSearch、Druid、Kylin 等做預(yù)計(jì)算，從而減少計(jì)算量，加速查詢計(jì)算。
如上圖所示。離線應(yīng)用的三個(gè)維度，分別是對 NRT 的要求（業(yè)務(wù)自身的屬性），實(shí)現(xiàn)最小時(shí)延的代價(jià)（人力資源、機(jī)器資源），對數(shù)據(jù)精度的要求。每個(gè)應(yīng)用在實(shí)時(shí)化都要考慮如何在 3 者之間取得一個(gè)平衡。
這種平衡就決定了存在著三種模式。
第一種是零代價(jià)加速，通過實(shí)時(shí)數(shù)據(jù)落地，可以透明地享受 30-50 分鐘的加速；
第二種追求極致的近實(shí)時(shí)，應(yīng)用越實(shí)時(shí)越好，不惜一切代價(jià)，投入大量人力物力完全地重新實(shí)現(xiàn)邏輯；
第三種介于兩者之間，追求在資源有限情況下去加速，但盡量不增加其計(jì)算負(fù)擔(dān)。
在實(shí)時(shí)離線融合的場景下，ES、Druid、Kylin 等的作用會(huì)越來越重要。因?yàn)槿绻麘?yīng)用能夠使用這些帶預(yù)計(jì)算的存儲(chǔ)來實(shí)現(xiàn)的話，那么查詢計(jì)算時(shí)間就可以基本忽略不計(jì)。同時(shí)，因?yàn)檫@些存儲(chǔ)并沒有 Hive 那樣的分區(qū)概念，所以清洗打?qū)捦甑臄?shù)據(jù)其實(shí)是可以流式的落到這些存儲(chǔ)中去的（秒級(jí)）。那么，用戶就可以以類似離線 SQL 的方式實(shí)現(xiàn)秒級(jí)的數(shù)據(jù)查詢。
4. 實(shí)時(shí)離線融合帶來的挑戰(zhàn)
實(shí)時(shí)離線融合并不是免費(fèi)的午餐。它也帶來了一系列新的問題和挑戰(zhàn)。
對于實(shí)時(shí) / 流式計(jì)算而言，它變成了所有大數(shù)據(jù)處理的一個(gè)前置。這就要求其作為平臺(tái)具有很高的穩(wěn)定性、可靠性、可管理性、數(shù)據(jù)質(zhì)量、SLA 保證。特別是現(xiàn)有的在流處理系統(tǒng)（Storm、Spark Streaming、Flink）在理論上還沒有完全實(shí)現(xiàn) end-to-end exactly once 的情況下。一般認(rèn)為批處理系統(tǒng)（Hive、Spark）是非?？煽康?，且支持 exactly once 語義。將基礎(chǔ)數(shù)據(jù)準(zhǔn)備從批處理系統(tǒng)替換為流處理系統(tǒng)，怎么保證其可靠性不降低是一個(gè)非常大的挑戰(zhàn)。
如何確保 Hive 中數(shù)據(jù)的質(zhì)量，目前我們的做法是多方著手：
1. 全鏈路監(jiān)控，保證數(shù)據(jù)質(zhì)量；
2. 考慮各種極端場景的處理方法；
3. 發(fā)現(xiàn)問題時(shí)，如何重寫整個(gè) Hive 分區(qū)；
4. 保留目前的離線小時(shí)抽數(shù)邏輯用于對數(shù)。
5. 改造目前的流框架來提供更好的處理語義保證。
對于離線（Hive、Spark）來說，應(yīng)用要實(shí)時(shí)化，就必須高頻調(diào)度。這也帶來了一系列挑戰(zhàn)。如何提高調(diào)度效率？如何處理在上一次調(diào)度沒執(zhí)行完情況下下一個(gè)批次的調(diào)度問題（數(shù)據(jù)積壓）？如何防止過度占用系統(tǒng)資源？這需要對于調(diào)度系統(tǒng)和應(yīng)用都進(jìn)行改造。另外，我們需要區(qū)分熱數(shù)據(jù)和冷數(shù)據(jù)。熱數(shù)據(jù)使用單獨(dú)的 SSD 或者 Alluxio 集群，而冷數(shù)據(jù)存儲(chǔ)在普通的 HDFS 中。
實(shí)時(shí)離線融合我們目前也只是完成了很多基礎(chǔ)數(shù)據(jù)的實(shí)時(shí)化，目前已經(jīng)能夠比較明顯的看到效果。但這個(gè)任務(wù)是長期的。因?yàn)橛脩粢话愀酉矚g使用天表等很寬的表，而目前實(shí)時(shí)化的更多是小時(shí)表等基礎(chǔ)表，如何實(shí)時(shí)化（或者加速）天表等寬表是我們目前在推進(jìn)的一項(xiàng)工作。只有等這部分工作完成后，我們才能說實(shí)時(shí)離線融合真正成功了。
作者介紹
姜偉華 博士，國內(nèi)最早的 Hadoop 發(fā)行版：IDH 的產(chǎn)品開發(fā)經(jīng)理。主要研究方向集中于對大數(shù)據(jù)開發(fā)，從事大數(shù)據(jù)開源工作，曾經(jīng)在 Intel 期間 2 年之內(nèi)團(tuán)隊(duì)培養(yǎng)出 10 位 committer，創(chuàng)建了上海大數(shù)據(jù)流處理 Meetup，創(chuàng)建 2 個(gè)新的 Apache 項(xiàng)目。目前在唯品會(huì)負(fù)責(zé)實(shí)時(shí)平臺(tái)。
實(shí)戰(zhàn)特訓(xùn)：遠(yuǎn)場語音交互技術(shù)
智能音箱這么火，聽聲智科技CTO教你深入解析AI設(shè)備語音交互關(guān)鍵技術(shù)！
課程鏈接：http://www.mooc.ai/course/80
加入AI慕課學(xué)院人工智能學(xué)習(xí)交流QQ群：624413030，與AI同行一起交流成長
雷峰網(wǎng)版權(quán)文章，未經(jīng)授權(quán)禁止轉(zhuǎn)載。詳情見轉(zhuǎn)載須知。
