據報告顯示到 2025 年，全球將產生 180ZB 的數據。這些海量的數據正是企業進行數字化轉型的核心生產因素，然而真正被有效存儲、使用和分析的數據不到百分之十。如何從 ZB 級的數據中尋找分析有價值的信息並回饋到業務發展纔是關鍵。11 月 30 日 UCan 技術沙龍大數據專場（北京站）邀請了 5 位資深大數據技術專家分享他們對大數據的探索和應用實踐。
大數據業務常態化的處理手段與架構衍變
很多開發人員在解決實際的業務問題時，經常會面臨如何選擇大數據框架的困惑。比如有十億條數據需要進行聚合操作，是把數據放在 HBase+Phoenix 還是 Kudu+Impala 或是 Spark 上進行呢？到底哪種方案才能夠達到降低開發運營成本且性能足夠高的效果呢？ UCloud 大數據工程師劉景澤分享了他的思考。
要想對數據進行分析決策，首先要有數據來源，其次要將採集到的數據進行存儲，然後把這些數據進行彙總、聚合、計算，最後反饋到數據應用層。目前市面上主流的大數據框架有幾百種，總結下來主要分爲數據採集層、數據存儲層、數據計算層和數據應用層。除此之外，一套完整的大數據技術棧還包括了任務調度、集羣監控、權限管理和元數據管理。
面對數量衆多、種類繁雜的技術棧，選擇的自由度很高，但前提是不能把強依賴的框架給拆分開。這裏劉景澤給出了一個通用型架構如下圖所示：
圖中左邊 OLTP SDK 指的是後臺接口，可以調用很多大數據的服務。從接口或者從 Flume 採集到的數據，直接送到 Kafka，然後送到 ES，再通過 ES 進行建模。整個過程相當於只使用了 ELK 這套系統，雖然很簡單，但這也是一個大數據框架。對於數據量比較大、業務範圍比較廣的公司，往往要求原始數據要做冷備留存，這時 HDFS 就可以作爲一個數據冷備的集羣，HDFS + Hive 作爲冷備也是非常常見的方案。
當業務規模發展到足夠大的時候，需要進行一些聚合操作，如果從單獨的一個框架拉出來的數據是不完整的，可能需要多個框架同時操作然後進行 join，這樣操作的效率非常低。要解決這個問題，可以用大寬表的思路：第一步先把業務數據存放在 MySQL 或者 HBase 裏面。然後通過 Spark 或 Flink，從 MySQL 或 HBase 裏面通過異步 IO 的方式把所需要的維度數據拿出來進行 join，join 好的數據可以存在 HBase 中。到這一層的時候，所有的數據維度已經非常完整了。當進行一個重要指標分析的時候，我們只需要從 HBase 裏面拿數據就可以了。對於業務不是非常重的指標可以直接通過 Phoenix 或者 HBase、Impala 和 Trafodion 對接業務需求，把想要的結果輸出。
再往後發展，如果業務還是異常繁重，數據處理不過來，我們就可以把明細數據層 HBase 裏面的數據拿出來，放到 Spark 和 Flink 這兩個流計算框架中進行預聚合，然後對接到 OLTP 系統，提供後臺服務。
可見，大數據技術棧的選擇並沒有統一的標準，不同業務場景需要不同的處理方式。正如劉景澤所說：“在很多場景裏面，我們面對框架的時候要一以貫之，發現它真正的自由度在哪裏？而不要被它們所侷限了。”
存儲計算分離與數據抽象實踐
大數據誕生的初期，很多公司的大數據集羣是由一個龐大的 Cluster 陣列組成，裏面包括很多臺服務器，也就是集羣的計算能力和存儲能力分佈在一個數據中心。這是由於當時的網絡條件較差，導致任務處理中的數據傳輸開銷非常大，而本地磁盤比網絡傳輸更快，因此當時的主要理念就是要以數據爲中心做計算，爲的是減少數據的遷移，提高計算效率，這裏最典型的代表就是 MapReduce。
實際上，這種” 資源池” 方案不能同時充分利用存儲和計算資源，造成了大量浪費，還面臨着各種組件升級困難、無法區別對待不同數據、定位問題困難、臨時調配資源困難等一系列問題。隨着網絡速度的大幅提升、內存和磁盤的大規模擴容、大數據軟件的迭代更新，之前的存儲 + 計算集羣的方案該如何改進呢？BLUECITY 大數據總監劉寶亮提出了存儲計算分離架構，如下圖所示：
要實現存儲計算分離，首先存儲計算要分開，同時存儲內部要分離，計算內部也要分離。存儲集羣是該架構的核心，因爲大數據最重要的就是數據；計算集羣是這個架構的靈魂，因爲一切的靈活性都是由計算集羣帶來的。此外，無阻塞網絡是此架構最重要的依賴，因爲一旦出現網絡問題，存儲集羣的讀取和寫入操作就不能持平。
說到存儲計算分離的優點，劉寶亮特別強調了 “彈性”，這是由於多集羣的軟硬件升級更容易、數據可分級對待、可臨時創建新集羣應對緊急問題等等都更加靈活，從而進一步提升了計算速度。
數據驅動 —— 從方法到實踐
所謂數據驅動，就是通過各種技術手段採集海量數據，並進行彙總形成信息，之後對相關的信息進行整合分析並形成決策指導。在這裏神策聯合創始人 & 首席架構師付力力將整個數據驅動的環節總結爲四步，分別是數據採集、數據建模、數據分析、數據反饋，並且這四個環節要形成閉環，也就是數據反饋最終要回歸到數據採集。
數據採集是一切數據應用的根基，可以通過客戶端、業務端、第三方數據、線下數據四個方面進行採集，無論以何種方式進行，建議在內部做技術架構設計的時候，要設定統一的數據接入 API，通過 SDK 或服務端的數據採集工具將數據做統一處理接收，方便後續的數據建模。
第二步是數據建模，一個基礎的數據模型分爲三部分：事件、用戶、實體，在此之上，還可以做用戶分羣，例如根據用戶的年齡、性別、省份、手機設備等屬性進行劃分。數據建模的過程中有一個難點就是 ETL，在多數據源採集的情況下，很難找到直接可用的 ETL 產品，因此我們可以搭建好調度、計算框架、質量管理和元數據管理等通用工作，儘量把數據的源頭建設好，從而降低運營成本。
第三步數據分析，這裏有兩種非常典型的思路：一種是通過例行的報表滿足基本的指標獲取需求，如果是臨時性的需求就要通過新的開發解決；另一種是使用抽象的模型覆蓋指標體系以及大部分分析需求，通過友好的交互讓需要數據的人自主獲取數據。後者的靈活性遠遠大於前者，而數據分析對靈活性的要求會遠大於對響應時間的要求。除此之外，數據的可解釋性以及整體架構的簡潔性也是非常重要的考量因素。
數字時代業務風控的挑戰與機遇
企業的業務、營銷、生態、數據等正面臨日益嚴重的黑產威脅，面對黑產鏈條完備、分工明確的形勢，現有的風控方案面臨着哪些挑戰？
數美科技 CTO 樑堃歸納了三點：第一，防禦能力單薄，依賴黑名單、依賴簡單人工規則、單點防禦（SDK、驗證碼）；第二，防禦時效性差，依賴 T+1 離線挖掘、策略生效週期長；第三，防禦進化慢，缺乏策略迭代閉環、無自學習機制。那麼如何改善以上這些問題並建立完整的風控體系呢？
樑堃認爲一個全棧式風控體系應該包括布控體系、策略體系、畫像體系和運營體系。在布控體系上，我們可以增加設備風險 SDK、增加登錄註冊保護、 提供業務行爲保護。在策略體系上，可以對虛擬機設備農場等風險設備、對機器註冊撞庫***等風險操作、對欺詐團伙高危羣體進行識別檢測等。畫像體系可以在多個場景進行數據打通，多行業聯防聯控，共同對抗黑產。運營體系可通過案例分析、***研究、策略的設計、研發、驗證、上線、運營等環節形成完整的閉環進行運轉，這樣才能保證風控一直有效。
這些體系跑在什麼樣的架構上呢？首先風控系統要跟業務系統解耦，這樣業務規則隨時升級變化不會影響風控，風控規則的變化不會影響業務。另外一個風控平臺結構需要包括多場景策略體系、實時風控平臺和風險畫像網絡，如下圖所示：
最後，這整個風控平臺的架構是運行在雲服務基礎設施上的 7 個全球服務集羣，每日請求量達 30 億，峯值 QPS 高達 10 萬 +。該架構可分爲接入層、策略引擎層、模型引擎層和存儲層，通過負載均衡管理每一層的節點，實現動態的橫向擴展。
Spark 在 MobTech 應用實操分享
MobTech 作爲全球領先的數據智能科技平臺，目前累計覆蓋設備量有 120 億，服務開發者 32 萬，累計接入 APP 數量達 50 萬，龐大的數據量也給 MobTech 帶來了諸多挑戰，例如運行的 Yarn/Spark 任務多、數據體量大、資源開銷大、運算時間較長等。
在 Mob 有大量複雜的任務，業務需求促使其將部分慢任務、Hive 任務遷移到 Spark 上面，取得性能的提升，同時還對一些 Spark 任務進行優化。MobTech 大數據技術架構師張峻滔圍繞複雜的 Spark 使用分享了兩個案例：第一個是 Spark 動態裁減在 MobTech 的應用。
所謂動態分區裁剪，就是基於運行時（run time）推斷出來的信息來進一步進行分區裁剪。假設 A 表有 20 億數據，B 表有 1000 萬數據，然後把 A 表和 B 表 join 起來，怎麼才能過濾掉 A 表中無用的數據，這裏我們引入了 bloomfilter。它的主要特性就是節省空間，如果 bloomfilter 判斷 key 不存在，那麼就一定不存在；如果 bloomfilter 判斷 key 存在，那麼可能存在，也可能不存在。簡而言之，這是一種犧牲精度來換取空間的數據結構。Bloomfilter 在 MobTech 具體應用實現如下圖所示：
其邏輯 SQL 如下：
SELECT /+ bloomfilter(b.id) / a.,b.FROM a join b on a.id = b.id
第二個案例是 Spark 在千億級別數據上的檢索與計算。MobTech 有 4000 多個標籤需要歷史回溯，且回溯時間週期長達 2 年，回溯頻次很低，面對這樣的冷數據，如何在資源開銷比較小的情況下完成業務檢索要求？由於數據分佈太散，4000 多標籤分佈在各個不同的表裏面 (橫向), 歷史數據又分佈在日表裏面 (縱向), 間接造成搜索要在千億的數據中進行查找。這裏，建立索引的思路有兩個：
橫向數據整合：將 4000 多個標籤的日數據索引整合到一個表裏面；
縱向數據整合：將日數據進行周級別 / 月級別整合。
橫向整合的日表數據還是太大，於是決定將日期和數據 ID 整合做出一個索引表，來加快日表的查詢，確保能直接通過 ID 定位到具體在事實表中的哪個文件，哪一行有該 ID 的信息。日表的數據通過 Spark RDD 的 API 獲取 ID,ORC 文件名，行號的信息，生成增量索引；增量索引通過 UDAF 合併入全量索引。具體方案如下：
由於篇幅有限，更多精彩技術內容敬請關注 “UCloud 技術” 並回復 “大數據” 即可獲取講師 PPT~