導讀： 隨着信息化時代的來臨，信息呈現出爆炸式的增長。尤其是在移動互聯網的推動下，每天大量信息湧入讓人們應接不暇，騰訊新聞客戶端的出現，就是以幫助用戶尋找有用信息而出現。這時，面對海量的數據、繁多的業務，如何處理手中的數據，利用數據賦能是今天會議討論的重點。
今天的介紹會圍繞下面三部分展開：
- 背景介紹
- 海量日誌處理架構
- 數據應用舉例
--
01 背景介紹
首先介紹一下騰訊新聞的背景。
團隊目前承擔騰訊新聞客戶端，體育和新聞插件的創新業務的輸入，廣告和用戶行爲的數據採集、處理、計算和分析的工作。最大的特點就是數據多、業務廣。數據龐大，業務應用多樣，例如數據會被用於報表展示、算法模型的訓練、產品決策等場景。
--
02 海量日誌處理架構
1. 總體架構
衆所周知，業務在實際開發過程中需要一套有效的數據管理、組織、處理方法，使得整個數據體系更加有序。上圖展示的是騰訊新聞整體的處理架構，包括：
-
採集層：依託於大同數據採集上報服務，大同是目前內部力推的數據治理的客戶端上報平臺。
-
計算層：包括實時計算與離線計算。離線是基於TDW（hive表）和HDFS建立的各個業務請求、點擊、曝光等維度的數據表，同時利用歐拉平臺的數據分層、數據分類、數據血緣等能力完成數據資產的管理。實時計算方面使用Oceanus平臺和內部的Datahub完成整個數據的開發。這個設計解決了需求多變、代碼複雜、系統高可用、海量數據低延時接入、數據高複用等問題。在ODS原始數據層、DWD數據明細層、DWS主題輕匯聚層，我們採用集團的Tube消息中間件，以及BG內部的CDMQ。Tube消息中間件解決海量數據及時接入的問題。數據各層由流式計算引擎進行業務的清洗與轉化，結果會迴流到下一個消息中間件，供下游使用。對於ODS層的實時數據我們會每隔一個小時同步到TDW，大概存儲週期爲3天，這部分數據既能用於離線計算，又能作爲數據的備份。比如一些鏈路發生異常，可以利用這部分數據進行問題排查和數據恢復。
-
數據存儲層：組件比較豐富，有Impala、ClickHouse、Mysql、Redis等。Impala主要應用在內部燈塔平臺和Datatalk平臺進行報表和數據探測的工作中。
2.數據上報
這部分詳細地講解整個數據上報體系。目前數據上報會根據數據源進行分類上報。數據源主要分爲四大類：
-
客戶端：包括客戶端、PC、H5這類數據。採用燈塔SDK進行上報，使用大同SDK進行採集。同時會基於大同平臺進行事件的管理，例如埋點的事件管理和統一參數的上報。大同平臺有效地解決需求散亂、數據難校驗、上報不規範等問題。在整個實時鏈路中，這部分數據接着會通過atta分發到TDW（hive表）和CDMQ實時中間件供下游進行實時消費。
-
後臺：主要包括後臺服務器日誌的上報。這部分數據會上報到Tdbank。Tdbank會同時將數據轉化爲TDW（hive表），同時還會分發到Tube實時流中，供下游進行實時消費。
-
DB：跟後臺數據上報類似。以前的方式是DB同步，例如按小時更新或者按天更新將Mysql更新數據放到Hive表中。目前，會通過Flink CDC監聽Mysql的binLog實時更新業務維表。
-
文件：例如業務配置和運營的配置文件，量不大，會通過手動的方式離線同步到TDW（hive表）中去。
3. 實時計算框架
實時計算架構整體上選擇Lamda架構，ODS層到DWD層數據的處理，實時和離線部分是公用的，也體現了流批一體的概念。下面就分模塊介紹實時計算部分的整體架構。
-
存儲/接入層：負責客戶端與後臺的實時中間數據上報。數據被上報到消息中間件中，消息中間件一方面負責消息的存儲，另一方面承擔數據分發給離線和在線處理平臺的功能，同時它是數據源和數據處理系統之間的橋樑。
-
DWD：DWD層的設計是爲了減少下游頻繁對ODS層數據進行消費。對於新的需求開發我們只需要申請DWD層的Tube消費節點即可。這樣處理極大地節省了計算單元。
-
計算層：主要負責數據的ETL、維表關聯、特徵抽取等業務邏輯的計算。
-
數據倉庫存儲層：主要採用TDW（hive表）、HDFS和Impala作爲存儲介質。ODS層的原始數據默認保存在HDFS上，保存週期默認爲3天。
另外，DWD和DWS層數據支持寫入TDW和HDFS去做離線計算。同時也支持導入Impala進行存儲，以供燈塔平臺和DataTalk平臺等進行數據探測和報表展示。
4. 離線計算框架
針對離線計算部分，我們對數據進行了分層管理，簡單概括爲以下四層：
-
ODS：原始數據存儲層。存儲大同上報或後臺上報的原始數據，例如廣告點擊曝光等數據。
-
DWD：數據明細存儲層。存儲經過清洗和標準化的數據。
-
DWS：數據輕度匯合層。基於單業務場景或者單用戶行爲的彙總。
-
ADS：數據應用層。只要存儲最終的，呈現結果的數據。例如存儲報表和進入Impala之前的數據，或者 存儲需要進入Redis、ClickHouse等的數據。
我們對數據層的調用進行了約束：
-
DWD層必須存在。且所有的ETL邏輯都在DWD層上。
-
DWS層優先調用DWD層。ADS優先調用DWS層。
-
DWD層不做過多與DIM維表的關聯。
同時我們對於表的命名進行規範，該命名規範使得雜亂無章的數據表變得規範有序，使得內部業務合作變得便利。具體規範如下：
5. 數據質量及鏈路保障
關於數據質量以及鏈路保障，分爲在線和離線兩部分進行講解。
離線部分，一方面會依託平臺提供指標監控告警以及SLA保障的能力；另一方面，在代碼層面進行設計，通過異常捕獲、分級告警，出錯分層管理，重置機制等，提高整個系統的高可用和穩定性。
實時部分，最容易出錯的就是Flink實時計算部分，例如出現內存不足、TaskManager突然減少、網絡抖動導致的服務連接超時等。我們會依託於Oceanus平臺提供的告警能力。我們設計了一套代碼層級的告警作爲報警獨立模塊。首先我們通過try catch捕捉Flink Task中的異常，同時這些報警信息會被髮送到消息中間件，然後報警信息會在消息中間件中被聚合，爲了預防報警疲勞，報警信息會被分級，錯誤碼會被沉澱，然後報警會統一通過企業微信進行通知，正常情況問題可在5min內被解決。
6. 總結
我們在實時和離線對海量日誌處理設計方案上的收益可以總結如下：
-
首先，通過大同平臺上報，使得上報更加規範化；
-
第二是事件規範化，各個BG之間可以應用同一規範數據，有統一規範的數據格式和命名規則；
-
第三就是數據倉庫規範化，包括分層、主題、管理等，使得整體管理更加清晰。
03 數據應用舉例
1. Flink CDC（Change Data Capture）- DB數據同步技術
這部分，我們通過Flink CDC的DB數據同步技術，進一步舉例說明我們的海量數據處理流程。上圖是通過Flink CDC進行實時更新維表和實時排行榜更新的設計方案，整體主要包括輸入數據源、Flink實時ETL模塊、Flink核心計算模塊和數據存儲模塊四部分。Flink內部繼承開源組件Debezium和Kafka，CDC技術可以實時捕捉Mysql的增刪改，然後將數據同步到下游，同步到多個數據源，然後通過抽取數據庫日誌的方式完成數據上報。
2. Flink CDC實現方法
Flink CDC實現方式主要有兩種：SQL模式和自定義反序列化模式。個人傾向於選擇第二種方式，可以更加靈活地實現業務需求。通過實現反序列化相關接口，數據庫的變更數據可以通過SourceRecord得到，解析之後的數據可以通過collect進行收集然後傳到下游進行消費。
今天的分享就到這裏，謝謝大家。
本文首發於微信公衆號“DataFunTalk”。