通用计算平台 滴滴实时计算平台在运营监控方面的应用(3)

数据采集到kafka后，实时计算平台的SparkStreaming以及Flink引擎就会对kafka中的实时binlog数据进行实时清洗和计算。之所以平台会选择SparkStreaming和Flink两套引擎是因为它们分别能够提供秒级microBatch和完全基于Stream的两种对实时计算级别的计算需要，同时其各自引擎上对结构化数据处理，SQL接口以及Window等接口化支持都非常完备，并且还在不断完善。

对数据进行实时清洗和计算后，有部分可以直接Sink到持久化存储系统中（比如HDFS）进行存储，以便后续对其进行离线分析和报表计算，也方便实时指标的明细查询等需求。其他部分实时数据按照业务需要写入Druid系统，由于Druid能够对数据进行实时聚合计算，因此非常适合进行诸如topN，GroupBy，Filter，Count等即时查询，也因此非常适合BI实时监控的业务需求。实时指标从Druid中查询出来后，要么会通过API的方式直接被业务应用程序引用进行逻辑调度，要么就通过dashboard呈现为实时业务报表和监控供运营和BI团队进行查看。

不仅业务团队需要对实时指标进行查看，同时系统还需要对各个业务指标的曲线突变进行实时的报警，以及时发现业务突变的发生，进而采取相应措施。BI实时监控针对各个业务指标提供了一套报警配置系统，让用户可以针对业务特征进行模型或者阈值报警设置。这样每一个实时指标发生任何突变都会立刻发送邮件，短信以及电话报警给相应的值班人员，确保线上业务突变情况第一时间得到响应。

乘客位置语义实时推送

在平时的乘客发单，司机接单后，到乘客上车的这段时间里，司机和乘客的沟通成本是比较高的。由于路况，路边位置，乘客发单后的位置变化，司机因路口原因需要掉头等等千变万化的情况，造成乘客和司机常常需要在乘客上车之前通过好几通电话进行沟通，很多的时候由于沟通上的小摩擦造成交易失败，甚至造成司乘之间的误会。

由于滴滴平台能够知道乘客流和司机订单流的情况，如果能够通过实时数据流将司机和订单进行join，来向司机实时的推送乘客的位置变化，比如乘客已出发，乘客已到达，乘客正在移动等等信息，就可以方便司机准确的判断乘客的状态，以便准确的接驾。司机和乘客也可以不必进行过多的电话沟通，提升接驾效率，也降低司机的接驾成本和提升司机的驾驶安全。

通过将实时订单数据流和乘客数据流进行join的业务架构如下：

通过Flink引擎对两个实时数据流进行join，并将司乘的中间状态进行缓存，并通过publisher系统实时从codis中将实时计算出来的状态变化推送给司机，以达到预期效果。该项目上线后，推送准确率达到94%。

平台构建&赋能

实时平台的底层存储和计算引擎为实时计算提供了架构支撑，但实际应用中这些系统的使用门槛通常都比较高，需要业务开发者有比较深厚的技术积累才能很好的使用。这无疑给平台为用户赋能上造成了比较大的门槛。为此滴滴实时计算团队抽象了用户开发实时计算任务过程中需要通过平台赋能的一些场景，如下图所示：

其中绿色指引部分即为用户在开发中需要通过平台工具提升效率的点。

出于更好的赋能用户的目的，滴滴实时计算团队依托为各业务团队开发大数据实时计算应用沉淀下来的经验，前瞻性的提出了构建实时数据一站式服务平台的理念，以创新的产品设计和技术手段，完成了从一款定制化的实时数据产品到通用的一站式实时数据服务平台的转变。通过高效整合实时数据采集、ETL、血缘关系展示、计算任务管理，监控大屏及报警策略配置等环节，对外开放和输出实时计算和分析能力，解放自己，赋能用户。有效解决了在团队人力严重不足的情况下，如何快速满足全公司全业务线大量的、迫切的业务监控需求的难题，有力的支撑了公司业务的快速发展，为线上业务保驾护航。在业界（无论国内还是国外），实时计算平台作为一个崭新的领域，具有非常大的技术挑战性。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-88211-3.html