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

創(chuàng)新互聯(lián)堅(jiān)持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：成都做網(wǎng)站、成都網(wǎng)站設(shè)計(jì)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿足客戶于互聯(lián)網(wǎng)時(shí)代的鹿城網(wǎng)站設(shè)計(jì)、移動(dòng)媒體設(shè)計(jì)的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！

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

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

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

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

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

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

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

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

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

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

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

要實(shí)現(xiàn)存儲(chǔ)計(jì)算分離，首先存儲(chǔ)計(jì)算要分開，同時(shí)存儲(chǔ)內(nèi)部要分離，計(jì)算內(nèi)部也要分離。存儲(chǔ)集群是該架構(gòu)的核心，因?yàn)榇髷?shù)據(jù)最重要的就是數(shù)據(jù)；計(jì)算集群是這個(gè)架構(gòu)的靈魂，因?yàn)橐磺械撵`活性都是由計(jì)算集群帶來(lái)的。此外，無(wú)阻塞網(wǎng)絡(luò)是此架構(gòu)最重要的依賴，因?yàn)橐坏┏霈F(xiàn)網(wǎng)絡(luò)問(wèn)題，存儲(chǔ)集群的讀取和寫入操作就不能持平。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

其邏輯 SQL 如下：

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

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

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

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