百花齊放”。離線特征計算的基本模式是基于Spark和Flink計算引擎，通過消費Kafka、BMQ、Hive、HDFS、Abase、RPC等數據源實現特征計算，然后將特征結果寫入在線和離線存儲。不同類型的基礎特征計算分散在不同的服務中，缺乏業務抽象，導致運維成本大，穩定性問題多。龐大的業務規模:抖音、今日頭條、西瓜、火山等產品的數據規模可達日均PB級。例如，在抖音的場景中，晚高峰Feed的播放量達到數百萬QPS，客戶端上報的用戶行為數據達到數千萬IOPS。業務期望在任何時候，功能任務都能保持流動，消費無滯后等。，這就要求特征制作具有非常高的穩定性。實時特征要求更高:在以直播、電商、短視頻為代表的推薦場景中，為了保證推薦效果，實時特征的離線制作時效需要穩定在分鐘。更好的可擴展性和靈活性:隨著業務場景的日益復雜，功能需求更加靈活多變。從統計、系列、屬性類型的特征生產，到窗口特征、多維特征的靈活支持，業務端需要特征中心支持新的特征類型和逐漸衍生的需求。服務迭代速度快:特征中心站提供的面向服務的DSL需要足夠多的場景，特征生產環節讓服務編寫盡可能少的代碼，底層計算引擎和存儲引擎對服務完全透明，完全釋放服務計算、存儲選擇和優化的負擔，完全實現實時基礎特征的規模化生產，不斷提升特征生產力；2020年初，是一個重要的節點。我們開始將Flink SQL和Flink State技術系統引入到特征生產中，并逐步在計數特征系統、模型訓練的樣本拼接、窗口特征等場景中實現。，探索新一代專題節目制作方案的思路。新方案的定位是:解決基礎特征計算和在線服務，提供更抽象的基礎特征服務層DSL。在計算層，基于Flink SQL靈活的數據處理和表達能力，以及Flink State狀態存儲和計算能力，支持各種復雜的窗口計算。大大縮短業務基礎功能的制作周期，提高功能輸出環節的穩定性。在新的體系結構中，我們將特征產生的環節分為數據源提取/拼接、狀態存儲和計算三個階段。Flink SQL完成特征數據提取和流式拼接，Flink State完成特征計算的中間狀態存儲。輕離線，重在線”，即所有的窗口狀態存儲和特征聚合計算都放在存儲層，在線完成。離線數據流負責基礎數據的過濾和寫入，離線詳細數據按照時間劃分進行匯總和存儲(類似于微批量)。底層存儲多為KV存儲或專門優化的存儲引擎，線上層完成復雜的窗口聚合計算邏輯。每個請求到來后，線上層拉取存儲層的詳細數據進行聚合計算。輕在線，重離線”，即將所有重時間片細節數據狀態存儲和窗口聚合計算放在離線層。結果聚合由離線窗口觸發機制完成，特征結果推送到在線KV存儲。在線模塊非常輕量，只負責簡單的在線服務，大大簡化了在線層的架構復雜度。在離線存儲層。我們主要依靠Flink提供的native state存儲引擎RocksDB，充分利用離線計算集群的本地SSD磁盤資源，大大減輕了在線KV存儲的資源壓力。在“狀態冷啟動”的場景中，我們引入集中存儲作為底層狀態存儲層的存儲介質，整體是混合架構。比如7天內的狀態存儲在本地SSD，7 ~ 30天內的狀態存儲在集中存儲引擎。離線數據回溯可以非常方便地寫入集中存儲。類型定義功能示例計算功能需要緩存上下文數據。類型數據源架構解析(a聯合b)窗口聯接(c查找聯接d)。類型拼接邏輯備注窗口Join基于關鍵粒度的區間狀態JoinLookup維度表Join多數據源Union策略講解部分實時功能已在抖音直播、電商、推送、抖音推薦等場景上線。主要有有狀態特征，如帶窗口的一維統計型、二維倒拉鏈型、二維TOPK型、實時CTR/CVR率型特征、序列型特征等。預計在不久的將來，單個任務的狀態可能會超過100T，這對架構的穩定性是一個很大的挑戰。:，大部分場景下在線緩存的CPU利用率大概會高達50%左右；對CPU來說更經濟，但是網絡帶寬不會盈利。預計切割會節省大量CPU資源。PB IDL裁剪上線后，大部分任務的CPU收益在30%左右。作者介紹:

郭文飛，字節跳動推薦系統基礎服務方向負責人。Byte是2015年初加入的，主要負責推薦系統的基礎服務方向，比如去重、計數、特性等。

字節跳動推薦架構團隊的實時計算方向，負責抖音、今日頭條、西瓜視頻等超過10億用戶的產品推薦系統架構的實時計算系統的設計與開發，保證系統的穩定性和高可用性。抽象出通用的實時計算系統，構建統一的推薦特征中心，實現靈活可擴展的高性能存儲系統和計算模型，實現推薦服務的去重、計數、特征服務等先進的實時推薦數據流系統。目前缺人。歡迎追求技術的同學們加入我們，打造世界一流的先進實時推薦數據流系統。聯系方式:guowenfei@bytedance.com。