ZB級的大數(shù)據(jù)探索與應用實踐「附PPT」-創(chuàng)新互聯(lián)

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

超過十余年行業(yè)經(jīng)驗，技術(shù)領(lǐng)先，服務至上的經(jīng)營模式，全靠網(wǎng)絡(luò)和口碑獲得客戶，為自己降低成本，也就是為客戶降低成本。到目前業(yè)務范圍包括了：成都網(wǎng)站制作、網(wǎng)站設(shè)計，成都網(wǎng)站推廣，成都網(wǎng)站優(yōu)化，整體網(wǎng)絡(luò)托管，小程序定制開發(fā)，微信開發(fā)，app軟件開發(fā)，同時也可以讓客戶的網(wǎng)站和網(wǎng)絡(luò)營銷和我們一樣獲得訂單和生意！

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

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

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

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

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

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

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

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

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

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

實際上，這種” 資源池” 方案不能同時充分利用存儲和計算資源，造成了大量浪費，還面臨著各種組件升級困難、無法區(qū)別對待不同數(shù)據(jù)、定位問題困難、臨時調(diào)配資源困難等一系列問題。隨著網(wǎng)絡(luò)速度的大幅提升、內(nèi)存和磁盤的大規(guī)模擴容、大數(shù)據(jù)軟件的迭代更新，之前的存儲 + 計算集群的方案該如何改進呢？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)建新集群應對緊急問題等等都更加靈活，從而進一步提升了計算速度。

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

所謂數(shù)據(jù)驅(qū)動，就是通過各種技術(shù)手段采集海量數(shù)據(jù)，并進行匯總形成信息，之后對相關(guān)的信息進行整合分析并形成決策指導。在這里神策聯(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è)務端、第三方數(shù)據(jù)、線下數(shù)據(jù)四個方面進行采集，無論以何種方式進行，建議在內(nèi)部做技術(shù)架構(gòu)設(shè)計的時候，要設(shè)定統(tǒng)一的數(shù)據(jù)接入 API，通過 SDK 或服務端的數(shù)據(jù)采集工具將數(shù)據(jù)做統(tǒng)一處理接收，方便后續(xù)的數(shù)據(jù)建模。

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

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

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

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

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

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

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

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

Spark 在 MobTech 應用實操分享

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

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

所謂動態(tài)分區(qū)裁剪，就是基于運行時（run time）推斷出來的信息來進一步進行分區(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 具體應用實現(xiàn)如下圖所示：

其邏輯 SQL 如下：

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

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

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

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

另外有需要云服務器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應用場景需求。

當前標題：ZB級的大數(shù)據(jù)探索與應用實踐「附PPT」-創(chuàng)新互聯(lián)
分享URL：http://muchs.cn/article20/djjcjo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供建站公司、動態(tài)網(wǎng)站、網(wǎng)站營銷、網(wǎng)站維護、企業(yè)網(wǎng)站制作、做網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)