ZB 級的大數(shù)據(jù)探索與應(yīng)用實踐「附 PPT」

據(jù)報告顯示到 2025 年，全球?qū)a(chǎn)生 180ZB 的數(shù)據(jù)。這些海量的數(shù)據(jù)正是企業(yè)進(jìn)行數(shù)字化轉(zhuǎn)型的核心生產(chǎn)因素，然而真正被有效存儲、使用和分析的數(shù)據(jù)不到百分之十。如何從 ZB 級的數(shù)據(jù)中尋找分析有價值的信息并回饋到業(yè)務(wù)發(fā)展才是關(guān)鍵。11 月 30 日 UCan 技術(shù)沙龍大數(shù)據(jù)專場（北京站）邀請了 5 位資深大數(shù)據(jù)技術(shù)專家分享他們對大數(shù)據(jù)的探索和應(yīng)用實踐。

大數(shù)據(jù)業(yè)務(wù)常態(tài)化的處理手段與架構(gòu)衍變

很多開發(fā)人員在解決實際的業(yè)務(wù)問題時，經(jīng)常會面臨如何選擇大數(shù)據(jù)框架的困惑。比如有十億條數(shù)據(jù)需要進(jìn)行聚合操作，是把數(shù)據(jù)放在 HBase+Phoenix 還是 Kudu+Impala 或是 Spark 上進(jìn)行呢？到底哪種方案才能夠達(dá)到降低開發(fā)運營成本且性能足夠高的效果呢？ UCloud 大數(shù)據(jù)工程師劉景澤分享了他的思考。

要想對數(shù)據(jù)進(jìn)行分析決策，首先要有數(shù)據(jù)來源，其次要將采集到的數(shù)據(jù)進(jìn)行存儲，然后把這些數(shù)據(jù)進(jìn)行匯總、聚合、計算，最后反饋到數(shù)據(jù)應(yīng)用層。目前市面上主流的大數(shù)據(jù)框架有幾百種，總結(jié)下來主要分為數(shù)據(jù)采集層、數(shù)據(jù)存儲層、數(shù)據(jù)計算層和數(shù)據(jù)應(yīng)用層。除此之外，一套完整的大數(shù)據(jù)技術(shù)棧還包括了任務(wù)調(diào)度、集群監(jiān)控、權(quán)限管理和元數(shù)據(jù)管理。

面對數(shù)量眾多、種類繁雜的技術(shù)棧，選擇的自由度很高，但前提是不能把強依賴的框架給拆分開。這里劉景澤給出了一個通用型架構(gòu)如下圖所示：

圖中左邊 OLTP SDK 指的是后臺接口，可以調(diào)用很多大數(shù)據(jù)的服務(wù)。從接口或者從 Flume 采集到的數(shù)據(jù)，直接送到 Kafka，然后送到 ES，再通過 ES 進(jìn)行建模。整個過程相當(dāng)于只使用了 ELK 這套系統(tǒng)，雖然很簡單，但這也是一個大數(shù)據(jù)框架。對于數(shù)據(jù)量比較大、業(yè)務(wù)范圍比較廣的公司，往往要求原始數(shù)據(jù)要做冷備留存，這時 HDFS 就可以作為一個數(shù)據(jù)冷備的集群，HDFS + Hive 作為冷備也是非常常見的方案。

當(dāng)業(yè)務(wù)規(guī)模發(fā)展到足夠大的時候，需要進(jìn)行一些聚合操作，如果從單獨的一個框架拉出來的數(shù)據(jù)是不完整的，可能需要多個框架同時操作然后進(jìn)行 join，這樣操作的效率非常低。要解決這個問題，可以用大寬表的思路：第一步先把業(yè)務(wù)數(shù)據(jù)存放在 MySQL 或者 HBase 里面。然后通過 Spark 或 Flink，從 MySQL 或 HBase 里面通過異步 IO 的方式把所需要的維度數(shù)據(jù)拿出來進(jìn)行 join，join 好的數(shù)據(jù)可以存在 HBase 中。到這一層的時候，所有的數(shù)據(jù)維度已經(jīng)非常完整了。當(dāng)進(jìn)行一個重要指標(biāo)分析的時候，我們只需要從 HBase 里面拿數(shù)據(jù)就可以了。對于業(yè)務(wù)不是非常重的指標(biāo)可以直接通過 Phoenix 或者 HBase、Impala 和 Trafodion 對接業(yè)務(wù)需求，把想要的結(jié)果輸出。

再往后發(fā)展，如果業(yè)務(wù)還是異常繁重，數(shù)據(jù)處理不過來，我們就可以把明細(xì)數(shù)據(jù)層 HBase 里面的數(shù)據(jù)拿出來，放到 Spark 和 Flink 這兩個流計算框架中進(jìn)行預(yù)聚合，然后對接到 OLTP 系統(tǒng)，提供后臺服務(wù)。

可見，大數(shù)據(jù)技術(shù)棧的選擇并沒有統(tǒng)一的標(biāo)準(zhǔn)，不同業(yè)務(wù)場景需要不同的處理方式。正如劉景澤所說：“在很多場景里面，我們面對框架的時候要一以貫之，發(fā)現(xiàn)它真正的自由度在哪里？而不要被它們所局限了。”

存儲計算分離與數(shù)據(jù)抽象實踐

大數(shù)據(jù)誕生的初期，很多公司的大數(shù)據(jù)集群是由一個龐大的 Cluster 陣列組成，里面包括很多臺服務(wù)器，也就是集群的計算能力和存儲能力分布在一個數(shù)據(jù)中心。這是由于當(dāng)時的網(wǎng)絡(luò)條件較差，導(dǎo)致任務(wù)處理中的數(shù)據(jù)傳輸開銷非常大，而本地磁盤比網(wǎng)絡(luò)傳輸更快，因此當(dāng)時的主要理念就是要以數(shù)據(jù)為中心做計算，為的是減少數(shù)據(jù)的遷移，提高計算效率，這里最典型的代表就是 MapReduce。

實際上，這種” 資源池” 方案不能同時充分利用存儲和計算資源，造成了大量浪費，還面臨著各種組件升級困難、無法區(qū)別對待不同數(shù)據(jù)、定位問題困難、臨時調(diào)配資源困難等一系列問題。隨著網(wǎng)絡(luò)速度的大幅提升、內(nèi)存和磁盤的大規(guī)模擴容、大數(shù)據(jù)軟件的迭代更新，之前的存儲 + 計算集群的方案該如何改進(jìn)呢？BLUECITY 大數(shù)據(jù)總監(jiān)劉寶亮提出了存儲計算分離架構(gòu)，如下圖所示：

要實現(xiàn)存儲計算分離，首先存儲計算要分開，同時存儲內(nèi)部要分離，計算內(nèi)部也要分離。存儲集群是該架構(gòu)的核心，因為大數(shù)據(jù)最重要的就是數(shù)據(jù)；計算集群是這個架構(gòu)的靈魂，因為一切的靈活性都是由計算集群帶來的。此外，無阻塞網(wǎng)絡(luò)是此架構(gòu)最重要的依賴，因為一旦出現(xiàn)網(wǎng)絡(luò)問題，存儲集群的讀取和寫入操作就不能持平。

說到存儲計算分離的優(yōu)點，劉寶亮特別強調(diào)了 “彈性”，這是由于多集群的軟硬件升級更容易、數(shù)據(jù)可分級對待、可臨時創(chuàng)建新集群應(yīng)對緊急問題等等都更加靈活，從而進(jìn)一步提升了計算速度。

數(shù)據(jù)驅(qū)動 —— 從方法到實踐

所謂數(shù)據(jù)驅(qū)動，就是通過各種技術(shù)手段采集海量數(shù)據(jù)，并進(jìn)行匯總形成信息，之后對相關(guān)的信息進(jìn)行整合分析并形成決策指導(dǎo)。在這里神策聯(lián)合創(chuàng)始人 & 首席架構(gòu)師付力力將整個數(shù)據(jù)驅(qū)動的環(huán)節(jié)總結(jié)為四步，分別是數(shù)據(jù)采集、數(shù)據(jù)建模、數(shù)據(jù)分析、數(shù)據(jù)反饋，并且這四個環(huán)節(jié)要形成閉環(huán)，也就是數(shù)據(jù)反饋最終要回歸到數(shù)據(jù)采集。

數(shù)據(jù)采集是一切數(shù)據(jù)應(yīng)用的根基，可以通過客戶端、業(yè)務(wù)端、第三方數(shù)據(jù)、線下數(shù)據(jù)四個方面進(jìn)行采集，無論以何種方式進(jìn)行，建議在內(nèi)部做技術(shù)架構(gòu)設(shè)計的時候，要設(shè)定統(tǒng)一的數(shù)據(jù)接入 API，通過 SDK 或服務(wù)端的數(shù)據(jù)采集工具將數(shù)據(jù)做統(tǒng)一處理接收，方便后續(xù)的數(shù)據(jù)建模。

第二步是數(shù)據(jù)建模，一個基礎(chǔ)的數(shù)據(jù)模型分為三部分：事件、用戶、實體，在此之上，還可以做用戶分群，例如根據(jù)用戶的年齡、性別、省份、手機設(shè)備等屬性進(jìn)行劃分。數(shù)據(jù)建模的過程中有一個難點就是 ETL，在多數(shù)據(jù)源采集的情況下，很難找到直接可用的 ETL 產(chǎn)品，因此我們可以搭建好調(diào)度、計算框架、質(zhì)量管理和元數(shù)據(jù)管理等通用工作，盡量把數(shù)據(jù)的源頭建設(shè)好，從而降低運營成本。

第三步數(shù)據(jù)分析，這里有兩種非常典型的思路：一種是通過例行的報表滿足基本的指標(biāo)獲取需求，如果是臨時性的需求就要通過新的開發(fā)解決；另一種是使用抽象的模型覆蓋指標(biāo)體系以及大部分分析需求，通過友好的交互讓需要數(shù)據(jù)的人自主獲取數(shù)據(jù)。后者的靈活性遠(yuǎn)遠(yuǎn)大于前者，而數(shù)據(jù)分析對靈活性的要求會遠(yuǎn)大于對響應(yīng)時間的要求。除此之外，數(shù)據(jù)的可解釋性以及整體架構(gòu)的簡潔性也是非常重要的考量因素。

數(shù)字時代業(yè)務(wù)風(fēng)控的挑戰(zhàn)與機遇

企業(yè)的業(yè)務(wù)、營銷、生態(tài)、數(shù)據(jù)等正面臨日益嚴(yán)重的黑產(chǎn)威脅，面對黑產(chǎn)鏈條完備、分工明確的形勢，現(xiàn)有的風(fēng)控方案面臨著哪些挑戰(zhàn)？

數(shù)美科技 CTO 梁堃歸納了三點：第一，防御能力單薄，依賴黑名單、依賴簡單人工規(guī)則、單點防御（SDK、驗證碼）；第二，防御時效性差，依賴 T+1 離線挖掘、策略生效周期長；第三，防御進(jìn)化慢，缺乏策略迭代閉環(huán)、無自學(xué)習(xí)機制。那么如何改善以上這些問題并建立完整的風(fēng)控體系呢？

梁堃認(rèn)為一個全棧式風(fēng)控體系應(yīng)該包括布控體系、策略體系、畫像體系和運營體系。在布控體系上，我們可以增加設(shè)備風(fēng)險 SDK、增加登錄注冊保護(hù)、 提供業(yè)務(wù)行為保護(hù)。在策略體系上，可以對虛擬機設(shè)備農(nóng)場等風(fēng)險設(shè)備、對機器注冊撞庫***等風(fēng)險操作、對欺詐團(tuán)伙高危群體進(jìn)行識別檢測等。畫像體系可以在多個場景進(jìn)行數(shù)據(jù)打通，多行業(yè)聯(lián)防聯(lián)控，共同對抗黑產(chǎn)。運營體系可通過案例分析、***研究、策略的設(shè)計、研發(fā)、驗證、上線、運營等環(huán)節(jié)形成完整的閉環(huán)進(jìn)行運轉(zhuǎn)，這樣才能保證風(fēng)控一直有效。

這些體系跑在什么樣的架構(gòu)上呢？首先風(fēng)控系統(tǒng)要跟業(yè)務(wù)系統(tǒng)解耦，這樣業(yè)務(wù)規(guī)則隨時升級變化不會影響風(fēng)控，風(fēng)控規(guī)則的變化不會影響業(yè)務(wù)。另外一個風(fēng)控平臺結(jié)構(gòu)需要包括多場景策略體系、實時風(fēng)控平臺和風(fēng)險畫像網(wǎng)絡(luò)，如下圖所示：

最后，這整個風(fēng)控平臺的架構(gòu)是運行在云服務(wù)基礎(chǔ)設(shè)施上的 7 個全球服務(wù)集群，每日請求量達(dá) 30 億，峰值 QPS 高達(dá) 10 萬 +。該架構(gòu)可分為接入層、策略引擎層、模型引擎層和存儲層，通過負(fù)載均衡管理每一層的節(jié)點，實現(xiàn)動態(tài)的橫向擴展。

Spark 在 MobTech 應(yīng)用實操分享

MobTech 作為全球領(lǐng)先的數(shù)據(jù)智能科技平臺，目前累計覆蓋設(shè)備量有 120 億，服務(wù)開發(fā)者 32 萬，累計接入 APP 數(shù)量達(dá) 50 萬，龐大的數(shù)據(jù)量也給 MobTech 帶來了諸多挑戰(zhàn)，例如運行的 Yarn/Spark 任務(wù)多、數(shù)據(jù)體量大、資源開銷大、運算時間較長等。

在 Mob 有大量復(fù)雜的任務(wù)，業(yè)務(wù)需求促使其將部分慢任務(wù)、Hive 任務(wù)遷移到 Spark 上面，取得性能的提升，同時還對一些 Spark 任務(wù)進(jìn)行優(yōu)化。MobTech 大數(shù)據(jù)技術(shù)架構(gòu)師張峻滔圍繞復(fù)雜的 Spark 使用分享了兩個案例：第一個是 Spark 動態(tài)裁減在 MobTech 的應(yīng)用。

所謂動態(tài)分區(qū)裁剪，就是基于運行時（run time）推斷出來的信息來進(jìn)一步進(jìn)行分區(qū)裁剪。假設(shè) A 表有 20 億數(shù)據(jù)，B 表有 1000 萬數(shù)據(jù)，然后把 A 表和 B 表 join 起來，怎么才能過濾掉 A 表中無用的數(shù)據(jù)，這里我們引入了 bloomfilter。它的主要特性就是節(jié)省空間，如果 bloomfilter 判斷 key 不存在，那么就一定不存在；如果 bloomfilter 判斷 key 存在，那么可能存在，也可能不存在。簡而言之，這是一種犧牲精度來換取空間的數(shù)據(jù)結(jié)構(gòu)。Bloomfilter 在 MobTech 具體應(yīng)用實現(xiàn)如下圖所示：

其邏輯 SQL 如下：

SELECT /+ bloomfilter(b.id) / a.,b.FROM a join b on a.id = b.id
第二個案例是 Spark 在千億級別數(shù)據(jù)上的檢索與計算。MobTech 有 4000 多個標(biāo)簽需要歷史回溯，且回溯時間周期長達(dá) 2 年，回溯頻次很低，面對這樣的冷數(shù)據(jù)，如何在資源開銷比較小的情況下完成業(yè)務(wù)檢索要求？由于數(shù)據(jù)分布太散，4000 多標(biāo)簽分布在各個不同的表里面 (橫向), 歷史數(shù)據(jù)又分布在日表里面 (縱向), 間接造成搜索要在千億的數(shù)據(jù)中進(jìn)行查找。這里，建立索引的思路有兩個：

橫向數(shù)據(jù)整合：將 4000 多個標(biāo)簽的日數(shù)據(jù)索引整合到一個表里面；
縱向數(shù)據(jù)整合：將日數(shù)據(jù)進(jìn)行周級別 / 月級別整合。

橫向整合的日表數(shù)據(jù)還是太大，于是決定將日期和數(shù)據(jù) ID 整合做出一個索引表，來加快日表的查詢，確保能直接通過 ID 定位到具體在事實表中的哪個文件，哪一行有該 ID 的信息。日表的數(shù)據(jù)通過 Spark RDD 的 API 獲取 ID,ORC 文件名，行號的信息，生成增量索引；增量索引通過 UDAF 合并入全量索引。具體方案如下：

由于篇幅有限，更多精彩技術(shù)內(nèi)容敬請關(guān)注 “UCloud 技術(shù)” 并回復(fù) “大數(shù)據(jù)” 即可獲取講師 PPT~