滴滴处理海量数据的秘诀是什么？

滴滴大数据体系的主要特点在于数据都是实时的，数据采集可以采集到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、实时报表、实时监控的领域目前技术已经非常成熟，也基本上涵盖了所有滴滴内部的业务场景。实时业务对时延、容错的要求非常高，这是我们现在面临的一个重要挑战。

业务峰谷资源合理分配：我们现在要做的就是如何将资源合理分配，让资源能够更合理地使用，为公司节省成本。

我今天的分享就到这里，谢谢大家！