滴滴處理海量資料的祕訣是什麼？

滴滴大資料體系的主要特點在於資料都是實時的，資料採集可以採集到90%以上的資料。我們的資料來源一共有三類，一類是Binlog資料，所有端上資料進資料庫通過Binlog進行實時採集；另外有publiclog，服務端的所有日誌也做了實時採集；還有端上埋點上報資料。

因為我們所有資料基本都是實時採集，所以客戶級的處理流程也廣泛運用了實時的技術。實時儲存方面用了三個產品，一個是ES，主要是做日誌檢索和實時分析；另一個是Druid，用於做實時報表和實時監控；HBase是做查詢和資料掃描。

離線這部分目前用了Hive和Spark。Hive主要負責ETL工作，Spark做資料分析以及分析後的查詢。流計算方面我們用了Spark Streaming和Flink Streaming。

從規模上來說，我們實時儲存和離線規模都已經做到了國內的領先水平。

實時計算有四大場景，ETL、實時報表、實時監控和實時業務。

因為我們90%的資料都是通過實時採集，採集過來之後第一個環節就是做ETL，所以現在ETL的規模是最大的。實時報表可以給運營和客服可以用來做報表展示。

實時監控的規模僅次於ETL，內部有兩類監控需求，一類是機器層面的，用了其它的技術方案；剩下就是業務類的實時監控，例如每天的訂單量、平衡率等資料，都運用了實時計算體系。

實時業務是我們今年重點突破的部分，我們想把流計算在端上的場景去做一些突破。

為了方便使用ETL，我們把它做了平臺化，使用者只需要在web上配置就可以實現資料清洗。現在的清洗量可以達到每秒350萬左右的資料量，每天大約會清洗幾個P的資料量。這完全是基於Spark Streaming的雲端計算來實現的。

實時報表主要用的實時技術有Spark Streaming和Druid。Spark Streaming還是做資料清洗。Druid可以實時消費Kafka資料，但對資料是有要求的，所以要先經過一輪清洗並轉化。

實時報表的場景也比較多，有客服大屏、異常統計大盤和訂單熱力圖。

客服大屏就是一個可以顯示客服電話的應答率、投訴熱點及排隊情況等資訊的螢幕。

異常統計大盤包括了端上向服務端發起請求的監控，請求的成功率失敗率、請求數，都可以通過這種方式進行監控。

訂單熱力圖可以看到某個區域的訂單量、乘客量、司機量，通過地圖的方式進行展現。

我們選擇了Druid是因為它有一些特點，比如查詢靈活。

為了提升以後的監控效率，我們構建了一站式自助監控平臺，進行了全鏈路的平臺建設。

基於這個平臺，我們滴滴內部接入的資料來源大概有兩百個，指標監控大概有四五百個。

Flink Streaming是今年剛引入的引擎，我們想通過實時的業務對延遲性非常高、資料丟失以及資料重複等問題提出更好的解決方案。

降低實時計算開發成本：相對於Hive等等，開發實時計算的難度還是比較大，我們也在探索更簡單的開發方式。

實時業務擴充與挑戰：我們在實時ETL、實時報表、實時監控的領域目前技術已經非常成熟，也基本上涵蓋了所有滴滴內部的業務場景。實時業務對時延、容錯的要求非常高，這是我們現在面臨的一個重要挑戰。

業務峰谷資源合理分配：我們現在要做的就是如何將資源合理分配，讓資源能夠更合理地使用，為公司節省成本。

我今天的分享就到這裡，謝謝大家！