这几年随着滴滴业务的不断发展，用户（乘客、司机）在体验的改善上不断提出新的要求。不仅如此，滴滴内部数据和运营团队越来越实时、丰富和精准的营销策略对底层技术支撑平台日益严格和高效的要求，不仅要求数据更加实时（从天级，到小时级，到秒级，甚至毫秒级），要求数据更加准确（不重复，不缺失），还要求基于数据的各类用户画像和用户标签更加丰富。因此对底层技术平台和系统在各方面都提出了更高的要求。
滴滴每天会有上千万的成交单量，每一次发单接单，用户呼叫以及路径规划都对会对后台发出一系列的调用。由于滴滴现在服务于全球几百个城市的用户，不同城市因为各方面的原因需要有针对性的运营策略，在同一个城市的不同地段（比如机场，大型活动，演唱会体育场等）也因为实地情况不同进一步产生不同的业务特点。同时由于滴滴出行本身针对不同的用户提供了多样的服务类型选择（比如快车，优享，专车，主租车，顺风车，代价，小巴等等），不同的产品和服务后台的策略和逻辑也不尽相同。滴滴的司机团队也来自多种合作平台和直营平台，这些情况也进一步加剧了业务的复杂性。如何在每天每时每秒中针对不同城市，不同地段，不同产品，不同司机和不同乘客类型等瞬息万变的复杂业务场景进行高效，精准，多维度组合和细粒度的实时数据监控，并针对各种不同情况进行实时的风险控制和报警提醒，如何满足好滴滴业务团队因为这些需求而对底层技术团队和支撑平台提出的要求，是摆在滴滴大数据实时计算和平台团队面前的一个巨大难题。
由于面对极其复杂的业务场景和技术挑战，滴滴出行大数据架构部为此专门成立实时计算团队进行底层架构的深度优化以及开发平台的构建，并逐步将BI实时监控和实时业务报警等业务实现用平台来承接，完成了实时计算在滴滴内部的平台化和服务化。以下会从技术方案，系统架构，和平台产品等方面对其进行深入介绍。
技术方案和案例
实时计算和实时数据处理的数据流程，通常都会包括如下几个环节：
数据产生
数据采集
数据清洗（ETL）
数据计算
数据应用
而数据应用下通常会让数据有如下几个应用出口：
Sink到持久化存储系统，以便后续进行离线分析
实时监控大盘
实时API调用
实时计算平台
抽象出滴滴的实时数据流整体架构和流程后，构建了支撑实时数据流计算的实时计算系统，其整体架构如下：
滴滴实时数据流的整体架构中也包含了数据产生，数据采集，数据清洗（ETL），数据计算，以及最终将其应用到各个业务环节的过程。在上图系统架构中，包含有数据采集的消息中间层Kafka，实时计算引擎采用了目前社区活跃度和整体设计架构最先进的SparkStreaming和Flink两套计算引擎，计算结果分别根据不同业务需要写入实时的存储和查询系统（Druid，HBase和ES，甚至包括写会mis系统的mysql等）。
该实时计算平台为业务提供如下保证：
易用性：Web化操作，无需登入客户机；资源按需申请；自带Metrics监控
安全性：专用集群，避免批处理任务干扰；基于CGroup的进程级隔离机制；基于NodeLabel的业务级格隔离方案
稳定性：大数据底座SLA：99.95%；完善的监控报警体系；7*24小时专家团队技术支持；
BI实时监控
由于滴滴要面对非常复杂的业务场景，滴滴的数据本身就会有几多的维度和指标细分，数据分析团队和BI人员也会针对数据的不同维度和各种维度组合进行各种各样的分析和提取，其中就包括对业务数据进行精准实时的统计监控，以及针对各种业务指标的曲线进行指标突变的模型和阈值报警等。
由于业务业务监控的数据大多来自线上mysql的binlog，因此BI实时监控的数据可以坐到在业务口径上完全准确，直接可以跟财务和收银系统一致。mysql的binlog通过采集系统实时写入到kafka进行缓存，也等待后续实时计算引擎对其进行消费和计算处理。考虑到有可能因为业务变更和一些特殊原因需要对历史数据进行回溯，所以kafka中的binlog数据会按照不同策略保存响应的历史周期，比如一周或者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，来向司机实时的推送乘客的位置变化，比如乘客已出发，乘客已到达，乘客正在移动等等信息，就可以方便司机准确的判断乘客的状态，以便准确的接驾。司机和乘客也可以不必进行过多的电话沟通，提升接驾效率，也降低司机的接驾成本和提升司机的驾驶安全。
通过Flink引擎对两个实时数据流进行join，并将司乘的中间状态进行缓存，并通过publisher系统实时从codis中将实时计算出来的状态变化推送给司机，已达到预期效果。该项目上线后，推送准确率达到94%。
平台构建&赋能
实时平台的底层存储和计算引擎为实时计算提供了架构支撑，但实际应用中这些系统的使用门槛通常都比较高，需要业务开发者有比较深厚的技术积累才能很好的使用。这无疑给平台为用户赋能上造成了比较大的门槛。为此滴滴实时计算团队抽象了用户开发实时计算任务过程中需要通过平台赋能的一些场景，如下图所示：
出于更好的赋能用户的目的，滴滴实时计算团队依托为各业务团队开发大数据实时计算应用沉淀下来的经验，前瞻性的提出了构建实时数据一站式服务平台的理念，以创新的产品设计和技术手段，完成了从一款定制化的实时数据产品到通用的一站式实时数据服务平台的转变。通过高效整合实时数据采集、ETL、血缘关系展示、计算任务管理，监控大屏及报警策略配置等环节，对外开放和输出实时计算和分析能力，解放自己，赋能用户。有效解决了在团队人力严重不足的情况下，如何快速满足全公司全业务线大量的、迫切的业务监控需求的难题，有力的支撑了公司业务的快速发展，为线上业务保驾护航。在业界（无论国内还是国外），实时计算平台作为一个崭新的领域，具有非常大的技术挑战性。
该平台提供了如下关键功能和突破。
实时计算任务管理和调度
为多种实时计算引擎（Spark Streaming、Flink Streamin、Samza）提供统一的资源管理及任务调度功能，提供统一的可视化管理界面，自动同步Hadoop YARN状态
成本计价透明化：对接成本中心，计算资源申请、审批流程化、服务化
计算任务监控：计算任务Metrics统一上报，发现任务异常会及时给用户发送报警
实时数据API开放平台：让用户更便捷的获取实时数据
支持对OLAP Cube进行可视化建模
支持原子指标和复合指标的配置
基于SQL配置数据指标API，支持Group by , TopN的查询
拓展SQL语法，提出SQL占位符的概念，实现SQL的动态生成，使得查询有可筛选的能力，提高SQL复用率
提供API公共网关：对API访问权限、频率进行控制，保证数据安全
API服务化：使实时数据API申请、授权、访问实现流程化、服务化、自动化，提升数据获取的便捷性、安全性
随着互联网业务的不断发展，对大数据平台的存储和计算需求这几年也在逐渐的向偏实时化和智能化发展，对平台和架构也提出了新的要求和挑战。平台和业务在改善用户体验和赋能用户的追求是不会有止尽的。作为基础平台部门，也需要不断的探索能够更好支撑业务需求的架构和系统，为服务用户，改善用户体验保驾护航。
作者
罗李
滴滴出行技术研究员，滴滴基础平台部-大数据架构部门负责人，负责大数据架构团队下的实时，离线，NOSQL，OLAP等各大数据存储计算引擎的开发，测试，升级，上线，以及线上运维，数据开发平台和产品等各团队的技术和团队工作。前阿里巴巴高级技术专家，阿里云梯创始人之一，云梯负责人，先后在阿里巴巴搜索技术中心，阿里集团研发院，阿里云，淘宝数据团队等多个部门服务。主要负责阿里集团分布式系统，hadoop系统等版本的开发，测试，性能瓶颈分析，性能优化，集群管理，集群维护和监控，应用团队分布式技术支持，公司内部培训和hadoop技术在阿里集团内的推广等工作。
联系客服
