背景

大數據時代，數據的重要性不言而喻，尤其對于互聯網公司，隨著業務的快速變化，商業模式的不斷創新、用戶體驗個性化、實時化需求日益突出，海量數據實時處理在商業方面的需求越來越大。如何通過數據快速分析出用戶的行為，以便做出準確的決策，越來越體現一個公司的價值。現階段對于實時數據的建設比較單一，主要存在以下問題：

實時倉庫建設不足，維度及指標不夠豐富，無法快速滿足不同業務需求。

實時數據和離線數據對比不靈活，無法自動化新增對比基期數據，且對比數據無法預先生產。

數據監控不及時，一旦數據出現問題而無法及時監控到，就會影響業務分析決策。

因此，本文將基于美團大交通實時數據產品，從面臨的挑戰、總體解決方案、數據設計架構、后臺設計架構等幾個方面，詳細介紹實時數據系統的整體建設思路。

挑戰

實時流數據來源系統較多，處理非常復雜，并且不同業務場景對實時數據的要求不同，因此在建設過程主要有以下挑戰：

如何在保證數據準確性的前提下實現多實時流關聯；實時流出現延遲、亂序、重復時如何解決。 流式計算中通常需要將多個實時流按某些主鍵進行關聯得到特定的實時數據，但不同于離線數據表關聯，實時流的到達是一個增量的過程，無法獲取實時流的全量數據，并且實時流的達到次序無法確定，因此在進行關聯時需要考慮存儲一些中間狀態及下發策略問題。

實時流可復用性，實時流的處理不能只為解決一個問題，而是一類甚至幾類問題，需要從業務角度對數據進行抽象，分層建設，以快速滿足不同場景下對數據的要求。

中臺服務如何保證查詢性能、數據預警及數據安全。 實時數據指標維度較為豐富，多維度聚合查詢場景對服務層的性能要求較高，需要服務層能夠支持較快的計算能力和響應能力；同時數據出現問題后，需要做好及時監控并快速修復。

如何保證產品應用需求個性化。 實時數據與離線數據對比不靈活，需要提供可配置方案，并能夠及時生產離線數據。

解決思路

我們在充分梳理業務需求的基礎上，重新對實時流進行了建設，將實時數據分層建模，并對外提供統一的接口，保證數據同源同口徑；同時，在數據服務層，增加可配置信息模塊解決了配置信息不能自動化的問題，在數據處理策略上做了多線程處理、預計算、數據降級等優化，在數據安全方面增加數據審計功能，更好地提升了產品的用戶體驗。

總體方案

產品整體建設方案基于美團技術平臺，總共分為源數據層、存儲層、服務層及WEB層，整體架構如下所示：

• 源數據層：主要提供三部分數據，實時數據、離線數據、配置信息、維度信息。
• 存儲層：源數據清洗后放入相應的存儲引擎中，為服務層提供數據服務。
• 服務層：提供三部分功能，數據API服務、預計算服務、權限服務、數據審計服務。
• Web層：使用Echarts可視化數據。

數據層

數據架構

依托于美團提供的公共資源平臺，數據架構按功能分為數據采集、數據處理、數據存儲、數據服務四層，如下所示：

數據采集

數據來源主要有兩種：業務上報的Log日志及數據庫Binlog日志。這些日志通過美團日志中心進行采集后存儲在消息中間件Kafka中，并按照不同的分類存儲在不同的Topic中，供下游訂閱。

數據處理

數據處理顧名思義，就是對采集的實時流進行邏輯處理，按業務需求輸出對應的實時數據，因此這一步驟是流式計算的關鍵，分兩步進行：數據加工、數據推送。

數據加工：數據加工通常需要在流式計算系統中進行，目前流行的流式處理系統主要有Storm、Spark Streaming系統及Flink系統，這些系統都能在不同的應用場景下發揮很好處理能力，并各有優缺點，如下圖所示：

|計算框架|吞吐量|延遲|傳輸保障|處理模式|成熟度| |:—:|:—:|:—:|:—:|:—:|:—:|:—:| |Storm |低|毫秒級|At least once|單條處理|成熟| |Spark Streaming |高|秒級|Exactly once|微批處理|成熟| |Flink |高|毫秒級|Exactly once|單條處理/微批處理|新興|

最終我們選擇Storm作為實時數據處理框架，并借助公司提供的通用組件來簡化拓撲開發流程和重復代碼編碼。例如，組件MTSimpleLogBolt的主要功能是將Kafka中讀取的數據（Log or Binlog）解析成Java實體對象；組件StormConfHelper的功能是獲取Storm作業應用配置信息。

數據推送：將處理好的數據推送到存儲引擎中。

數據存儲

數據加工完成后會被存儲到實時存儲引擎中，以提供給下游使用。目前常用的存儲引擎主要有MySQL、Druid、Elasticsearch、Redis、Tair比較如下：

存儲引擎優點缺點

MySQL	使用簡單，支持數據量小	數據量大，對MySQL的壓力大,查詢性能慢
Druid	數據預計算	不支持精確查詢
Elasticsearch	查詢效率快，支持常用聚合操作；可以做到精確去重	查詢條件受限
Redis	內存存儲KV，查詢效率高	寫入資源有限，不支持大數據量寫入
Tair	持久化和非持久化兩種緩存，查詢效率高	單節點性能比Redis較弱
Kylin	多維查詢預計算	不支持實時

綜上比較，由于實時數據量較大，且數據精度要求較高，因此我們最終選擇交易存儲使用ES，流量存儲使用Druid，維度存儲使用Tair，中間數據存儲使用Redis；而離線數據，我們采用Hive和Kylin存儲。

數據服務

將存儲引擎數據統一對外提供查詢服務，支持不同業務應用場景。

具體實現

實時流處理流程

整個數據層架構上主要分為實時數據和離線數據兩部分：實時數據分為交易的Binlog日志和流量的Log日志，經過Strom框架處理后寫入Kafka，再經過DataLinkStreaming分別寫入ES和Druid；離線數據通過Hive處理寫入Kylin。

下圖所示為一條消息的處理流程：

兩個Topic分別是order_base（主要存放訂單基本信息：訂單id、訂單狀態、支付時間、票量、金額等）；order_biz（主要存放訂單的擴展信息：訂單id、訂單類型、出發時間、到達時間、出發城市、到達城市）。我們最終要拿到一條包括上述全部內容的一條記錄。

具體例子：Bolt在處理一條記錄時，首先判斷這條記錄是base還是biz，如果是base則寫入緩存中base的Category中，如果是biz則寫入biz的Category中。以order_id為Key，如果是base則去和biz關聯，如果biz存在則代表能夠關聯上，這時發送關聯后的完整數據，同時刪除該主鍵（order_key）記錄；如果biz中不存在，則說明沒關聯上，這時可能biz的數據延遲或者是丟失，為了保證主數據的準確性，這時我們只發送base的數據，緩存中的數據保留不被刪除。如果這條消息是biz，則首先會更新緩存中該主鍵的biz記錄，然后去和base關聯，關聯上則發送同時刪除base中數據，否則不發送。此時我們會根據ES的Update特性去更新之前的數據。從現實效果來看保證了99.2%的數據完整性，符合預期。

數據寫入

在Topic2es的數據推送中，通過DataLinkString工具（底層Spark Streaming）實現了Kafka2es的微批次同步，一方面通過多并發batch寫入ES獲得了良好的吞吐，另一方面提供了5秒的實時寫入效率，保證了ES查詢的實時可見。同時我們也維護了Kafka的Offset，可以提供At lease once的同步服務，并結合ES的主鍵，可以做到Exactly once，有效解決了數據重復問題。

ES索引設計及優化

在數據寫入ES過程中，由于數據量大，索引時間區間長，在建設索引時需要考慮合理設計保證查詢效率，因此主要有以下三點優化：

• 寫入優化 在通過DataLinkString寫入ES時，在集群可接受的范圍內，數據Shuffle后再分組，增加Client并發數，提升寫入效率。
• 數據結構化 根據需要設計了索引的模版，使用了最小的足夠用的數據類型。
• 按天建索引 通過模版按天建索引，避免影響磁盤IO效率，同時通過別名兼容搜索一致性。
• 設置合理的分片和副本數 如果分片數過少或過多都會導致檢索比較慢。分片數過多會導致檢索時打開比較多的文件，另外也會影響多臺服務器之間通訊。而分片數過少為導至單個分片索引過大，所以檢索速度慢。在確定分片數之前需要進行單服務單索引單分片的測試。 我們根據 索引分片數=數據總量/單分片數 設置了合理的分片數。

實時數據倉庫模型

整個實時數據開發遵循大交通實時數倉的分層設計，在此也做一下簡單介紹，實時數倉架構如下：

• ODS層：包含美團頁面流量日志、模塊事件日志以及用戶操作的Binlog信息日志，是直接從業務系統采集過來的原始數據。
• 事實明細層：根據主題和業務過程，生成訂單事實和流量事實。
• 匯總層：對明細層的數據擴展業務常用的維度信息，形成主題寬表。
• App層：針對不同應用在匯總層基礎上加工擴展的聚合數據，如火車票在搶票業務下的交易數據匯總信息。

規范建模后，業務需求來臨時，只需要在App層建模即可，底層數據統一維護。

中臺服務層

后臺服務主要實現 登陸驗證和權限驗證(UPM)、指標邏輯計算和API、預計算服務、數據質量監控、數據審計功能。由于數據量大且實時性要求較高，在實現過程遇到如下挑戰：

• 如何保證查詢響應性能。
• 服務發生故障后，數據降級方案。
• 數據監控預警方案及數據出現問題解決方案。

針對以上問題，下面進行一一詳述:

性能響應優化

服務層處理數據過程中，由于數據量大，在查詢時需要一定的響應時間，所以在保證響應性能方面，主要做了以下優化：

項目初始由于數據量不是很大，采用單線程直接查詢ES，能夠滿足需求。

隨著節假日來臨，數據量大增，并行查詢人次增多，查詢響應變慢，無法快速響應結果，因此引入緩存技術，將中間結果進行緩存，并在緩存有效期內，直接讀取緩存數據大大提高了時間效率；并且在此基礎上，引入Master-Worker多線程模式，將多指標查詢拆分，并行查詢ES，使得查詢響應大大提高。

雖然問題得到解決，但仍存在一個問題，就是每次都是現查ES及部分中間緩存結果，尤其是第一次查詢，需要完全走ES，這樣就會讓第一個查詢數據的用戶體驗較差，因此引入預計算服務，通過定時調度任務，將部分重要維度下的指標進行預計算放入緩存，用戶查詢時直接讀取緩存數據。而一些不常用的維度下的數據，采用的策略是，第一個用戶查詢時現查ES，并將結果數據預加載到緩存，后續所有用戶再次查詢直接讀緩存數據，這樣既能保證用戶體驗，也不至于占用太多緩存空間。

數據降級方案

使用緩存避免不了出現一些問題，比如緩存失效、緩存雪崩等問題，針對緩存雪崩問題，通過設置不同Key的過期時間能夠很好的解決；而對于緩存數據失效，我們有自己的數據降級方案，具體方案如下：

預計算數據會分別在Redis、Tair和本地緩存中存儲一份以保證查詢效率，當查詢Redis數據不存在時，會去Tair中讀取數據，Tair也為空時，會讀取本地緩存，只有當本地緩存數據也為空時，才會現查ES做聚合計算，這樣也會降低ES的查詢壓力。

數據監控

實時監控預警非常重要，在數據出現問題時，一方面能夠及時通知我們快速定位修復數據，另一方面也能夠及時周知業務同學，避免做出錯誤分析。基于此，我們做了兩方面的實時監控，其一是對源實時流在Storm處理層面的監控，確保源實時流正確生產；其二是對展示的匯總數據進行監控，確保產品展示指標數據正常。 針對數據出現問題預警，我們在解決方案上規范了流程：

監控報警機制及時周知相關同學。

第一時間通過產品上方的黃條提示用戶哪些數據異常。

快速定位問題，給出修復方案。

目前對于實時異常數據的修補，主要有兩種方法：

針對特殊情況的數據修補方案第一靈活指定Offset，重新消費Kafka數據。

預留了Hive2es的準實時重導功能,確保生產數據的準確和完整。

數據安全

在以數據取勝的時代，數據的安全不言而喻，我們采用公司提供的UPM權限接口進行二級權限管理并加入審計功能及水印功能，能夠準確記錄用戶的所有訪問以及操作記錄，并且將日志數據格式化到數據庫中，進行實時監控分析。

總結

實時數據可以為業務特定場景分析決策提供巨大支持，尤其對于大交通節假日及春運期間。在大交通實時戰場沙盤產品化過程中，我們投入了大量的思考和實踐，主要取得以下收益：

可視化的產品，為業務方實時分析提供極大便利，取得較好的反饋。

優化實時數據倉庫建設，合理分層建模，規范命名設計，統一維度建設和指標口徑，對外提供統一接口，保證數據規范準確。

在Storm框架下實時開發和數據寫入方面積累了一定的經驗。

服務層支持可配置信息，可以靈活配置個性化信息。

服務層性能及獲取數據策略的優化，為用戶帶來更好的產品體驗。

加入我們

最后插播一個招聘廣告，我們是一群擅長大數據領域數據建設、數倉建設、數據治理及數據BI應用建設的工程師，期待更多能手加入，感興趣的可以投遞個人簡歷到郵箱：yangguang09#meituan.com，歡迎您的加入。

作者介紹

• 娣娣，美團數據開發工程師，2015年加入美團，從事數據倉庫建設、大數據產品開發工作。
• 曉磊，美團數據開發工程師，2017年加入美團，從事數據倉庫建設、大數據產品開發工作。

總結

以上是生活随笔為你收集整理的实时数据产品实践——美团大交通战场沙盘的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。