本文根據演講視訊以及PPT整理而成。
本文将主要圍繞以下三個方面進行分享：
- 背景簡介
- 技術方案
- 目前現狀
一、 背景簡介
滴滴實時資料開發平台源于這樣的初衷，即建構業務監控的雙眼，用以監控發生的時事對系統業務交易量是否産生影響。此外，資料可能存在異常和波動，直接監控資料較為低效，時序資料還用以實時報警，幫助相關營運人員排查情況。實時監控和實時報警是滴滴資料管理的兩個最核心場景。
2015年以前，滴滴資料管理的架構非常簡單。通過掃描Mysql的從表和api資料進行預計算，預計算的操作結果先存儲于本地檔案，再定時上傳到CKV資料庫。以計算城市訂單量為例，一級目錄是城市id，二級目錄是日期，預計算的操作結果先按照目錄結構存儲于本地檔案，再定時上傳到CKV資料庫中。這種簡單架構的瓶頸是顯而易見的，即名額開發和擴充的難度較大。随着名額增多，在Mysql中維系配置越來越麻煩，并且往往牽一發而動全身。擴充目錄也非常麻煩，以增加産品線次元為例，在原來的一級目錄和二級目錄之間增加産品線次元要求本地檔案目錄和資料庫都需要修改，存儲和計算成本呈指數級别增長。問題的根本原因在于，這種架構無法保證資料的及時性和穩定性。鍊路的延遲以及使用腳本掃描資料使得資料量越大資料查詢越慢，資料及時性較差；通過api或者資料庫查詢無法保證不重不漏地消費資料，資料穩定性較低。
從2015年開始，滴滴針對資料及時性和穩定性兩方面進行優化。滴滴資料管理的流程分為幾個階段，首先輸入業務資料，對資料進行加工和存儲，再經過查詢輸出相關名額。
2015年以前，資料管理平台使用app請求實作所有連接配接，不僅影響系統的吞吐性能，還可能存在資料遺漏。2015年之後，滴滴引入了消息隊列實作連接配接，利用消息隊列的資料吞吐量優勢和ack機制降低了鍊路時延，同時保證了鍊路的穩定性。此外，還将資料加工替換為實時計算引擎，進一步降低系統時延。
查詢名額涉及到資料計算，資料計算可以在業務資料加工時進行，可以在資料存儲時進行，也可以在資料查詢時進行。資料計算越遲進行，前期資料的複用率越高，是以滴滴選擇在資料查詢時進行資料計算。比如，查詢實時訂單呼叫量時，在資料加工處進行資料計算并存儲，在新增實時訂單應答量時，仍需開發新的實時任務進行計算；實時叢集的資源是有限的，如果每開發一個名額都新增一個實時任務，将會帶來極大的資源浪費。假如在資料加工時進行ETL清洗，在資料存儲時僅存儲簡單的訂單表，而在資料查詢時才進行資料計算就可以複用之前資料計算的結果，進而節省叢集資源。這對資料庫的查詢和存儲能力提出了較高的要求。傳統的事務型資料庫僅針對事務，而不針對資料分析場景，因而不适用于時序資料查詢，針對此，滴滴引入了OLAP引擎。由于所有業務資料都具有時序特點，滴滴選擇了KAFKA+SMAZA+DRUID的OLAP引擎。
下圖展示了2015年到2017年初的架構圖，所有線上業務資料使用Kafka進行實時資料流存儲，經過實時計算加工，再寫回Kafka。然而，這存在開發周期過長，開發語言複雜，現有人力成本跟不上業務需求變更的開發瓶頸。同時，還存在調用鍊路較長，實時資料資産管理混亂等缺點。為了應對此開發瓶頸，滴滴緻力于實作實時資料管理的一體化平台，允許全公司共同參與資料的采集、加工和存儲等工作。
由此，滴滴建構了實時計算開發平台Woater，以實作降低開發難度、實時資産管理等優化目标。
二、 技術方案
下圖展示了2017年至今，滴滴實時計算開發平台采用的技術架構。Mysql的資料從表通過Canal采集，文本日志通過Swan采集，采集到的資料存儲于Kafka Topic中。實時計算引擎層引入了Spark Streaming和Flink，對采集到的資料進行資料加工，再寫入Druid中。此外，平台還引入了離線資料，使用HIVE将其與實時資料結合，提高了消息隊列的資料查詢能力。
當資料寫入Druid Datasource後，平台會生成所有資料的模闆，并落地存儲，開放給所有使用者使用，開放的功能包括實時監控、報警服務等。此外，平台還允許使用者自定義功能，比如根據實時應答率動态調節産品價格等。
另外，滴滴實時資料開發平台還提供了血緣管理、權限管理兩個支線功能。血緣管理将平台所有資産，包括Kafka任務和api等實時寫入血緣管理子產品，友善使用者檢視任意資料的上下遊流動情況。資料開發平台的每個子產品都互相解耦，是以滴滴還為每個子產品都實作了權限管理功能。
Druid是針對時序資料提供低延時的資料寫入以及快速互動式查詢的分布式OLAP資料庫。在資料寫入時，由使用者發起實時資料寫入任務，通過overload節點将任務釋出到各個MiddleManager節點上，MiddleManager節點進而發起子任務，實時拉取資料并存儲到Deep Storage中，保證了曆史資料的高可用。Druid支援的Deep storage類型包括Amazon S3, HDFS等任意檔案系統。在資料查詢時，來自用戶端的請求首先到達Broker節點，由Broker節點查詢全局的資料分片拓撲圖，進而将查詢拆分成若幹子查詢，涉及到實時資料的子查詢由MiddleManager節點執行，涉及到曆史資料的子查詢由Historical節點執行，子查詢結果在Broker節點彙總并傳回給前端。
Druid針對時序資料的存儲與查詢進行了多項優化。在資料分片設計方面，Druid将所有資料分成了三個屬性，包括時間戳，次元和名額。時間戳和名額都采用整數型或者浮點型進行本地存儲，是以具有很高的壓縮比。字元串資料在本地存儲時不會直接存儲為字元串格式，而是将其生成映射表。以屬性次元的Page為例，映射表可能将“Justin Bieber”映射為0，将“ke$ha”映射為1，那麼Page列資料在資料庫中将存儲為“0011”，因而也具有較高的壓縮比。為了加快查詢，Druid還為每個值維系一個反向索引，比如，“Justin Bieber”在Page列的反向索引為“1100”，“ke$ha”在Page列的反向索引為“0011”。在查詢Page等于“Justin Bieber”時，隻需挑選索引中為“1”的項。在進行多列篩選時，隻需将各列的索引進行異或計算，比如要查詢Page等于“Justin Bieber”且Username等于“Reach”的資料項時，按照反向索引邏輯，僅需将“0100”和“Justin Bieber”的反向索引進行異或。
下面列出了Druid的主要優化方法。一方面，Druid采用列式Segment進行存儲，另一方面，它采用基于字典的編碼對次元列進行壓縮，進而提高壓縮比。此外，Druid還引入了Rollup聚合存儲機制，允許使用者自定義資料聚合規則，提高資料的查詢效率。
優化後的Druid實作了資料實時可查詢，同時提供亞秒級的查詢效率，99%的資料查詢可以在1秒内傳回結果，這對于擁有700+資料源和日均查詢量近2000千萬的叢集而言非常難得。此外，Druid還将資料壓縮到了其原始大小的1/30，實作了極高的壓縮比。
然而，Druid存在資料加工能力較弱的缺點，僅依賴Druid很難實作兩個表的Join操作。
滴滴實時資料開發平台的解決方案是在資料加工層引入主流的SparkStreaming和Flink技術，二者代表了實時計算引擎的兩種不同設計方向。Spark Streaming以Spark引擎為基礎發展而來，将基于離線資料的批計算壓縮為微批操作，使其變成近乎實時的計算。Spark生态具有極高的活躍度，對Spark相關技術熟悉的人員可以快速上手Spark Streaming。Flink适用于低延遲的資料處理場景，支援實時處理資料，同時支援從下至上相容批處理。此外，Flink還能夠提供“exactly once”的實時處理方案和不重不漏的資料消費。
在開發方式方面，滴滴實時資料開發平台提供了多種使用者操作以适應更多使用者。針對具有流基礎的使用者，平台提供了Web IDE,支援線上開發編譯，線上送出配置，減少了本地配置開發環境的困難。針對具有程式設計經驗的使用者，平台提供了StreamSQL和DruidSQL，StreamSQL允許使用者使用SQL方式進行資料加工，降低使用者的平台上手難度，DruidSQL可用于Druid相關的查詢同時幫助使用者進行線上調試。此外，滴滴還提供了可視化拖拽等功能幫助名額查詢，友善初級使用者。
三、 目前現狀
目前，滴滴實時資料開發平台提供的實時監控功能已覆寫滴滴的全部核心業務線，包括國内和國際化業務。提供的實時監控服務實作了秒級延時，支援每秒重新整理。另外，滴滴團隊還對底層Druid進行了優化，實作了99.995%的可用性。滴滴實時資料開發平台的這些能力針對平台的所有使用者全部開放。
在異常報警方面，根據實時的血緣鍊路，滴滴實時資料開發平台承諾實作的準确性達到3次誤報，1次漏報。在異常報警時，平台将篩除資料正常範圍的延遲、抖動和鍊路異常，減少誤報率。在及時性方面，滴滴實時資料開發平台承諾能在1分鐘内快速響應問題。
同時，滴滴實時資料開發平台還提供了大中小屏可視化方案，進而為使用者提供更豐富的圖表和更靈活的配置方式。