发帖
雷达卡
滴滴大数据实时计算平台在运营监控方面的应用
项目背景
这几年随着滴滴业务的不断发展，用户（乘客、司机）在体验的改善上不断提出新的要求。不仅如此，滴滴内部数据和运营团队越来越实时、丰富和精准的营销策略对底层技术支撑平台日益严格和高效的要求，不仅要求数据更加实时（从天级，到小时级，到秒级，甚至毫秒级），要求数据更加准确（不重复，不缺失），还要求基于数据的各类用户画像和用户标签更加丰富。因此对底层技术平台和系统在各方面都提出了更高的要求。
业务挑战
滴滴每天会有上千万的成交单量，每一次发单接单，用户呼叫以及路径规划都对会对后台发出一系列的调用。由于滴滴现在服务于全球几百个城市的用户，不同城市因为各方面的原因需要有针对性的运营策略，在同一个城市的不同地段（比如机场，大型活动，演唱会体育场等）也因为实地情况不同进一步产生不同的业务特点。同时由于滴滴出行本身针对不同的用户提供了多样的服务类型选择（比如快车，优享，专车，主租车，顺风车，代价，小巴等等），不同的产品和服务后台的策略和逻辑也不尽相同。滴滴的司机团队也来自多种合作平台和直营平台，这些情况也进一步加剧了业务的复杂性。如何在每天每时每秒中针对不同城市，不同地段，不同产品，不同司机和不同乘客类型等瞬息万变的复杂业务场景进行高效，精准，多维度组合和细粒度的实时数据监控，并针对各种不同情况进行实时的风险控制和报警提醒，如何满足好滴滴业务团队因为这些需求而对底层技术团队和支撑平台提出的要求，是摆在滴滴大数据实时计算和平台团队面前的一个巨大难题。
技术挑战
对实际线上业务的各种业务变化，比如订单呼叫量、订单应答量、订单成交量、实时应答率、平均接驾距离等，要将这些数据实时的反馈到运营团队业务团队的dashboard上，即使不考虑更多复杂的业务场景的前提下在如此巨大的数据量下仅仅做到数据足够实时和准确就已经是一个非常巨大的挑战。从一个业务行为的产生，到其产生的log数据，到采集这条log到大数据平台，再到对这条数据进行清洗，分析，聚合统计，再到写入实时查询系统，最后呈现到业务团队的监控大盘，这其实是一条很长且非常复杂的数据链路，中间涉及到业务日志标准规范，实时数据采集和清洗，实时计算，实时聚合等多个底层支撑系统和平台，多个环节的打通和衔接，以及技术团队自上而下的对业务特征的了解和实现。不仅如此，由于业务和策略千变万化，经常要针对各种特殊情况和政策进行调整和适配，这就对底层技术实现在可扩展性和灵活的适配能力上提出了更高的要求。
赋能
通常技术部门会有比较偏向业务本身的技术团队和偏向底层架构和平台的技术团队，由于业务初期为了能够快速响应，通常是有业务的需求人直接提需求给平台架构团队直接进行开发，而由于底层平台团队没有很方便的工具和开发平台，这就绕过了对业务特征理解更深的业务技术团队，而由平台架构的技术部门直接对业务数据需求进行相应。而如果能够构建足够方便直观的开发平台，就可以将这些开发工作转而由对业务更加理解的业务技术团队进行个性化的定制开发，平台架构团队转而专注于平台和底层架构的优化，并通过不断的完善对业务开发团队进行赋能。这种团队分工的转变有利于提升各自团队的效率和专注度，也能够让业务团队对支撑的技术团队有足够明确的接口人和接口部门。在滴滴实时计算和实时监控的服务中，逐渐发现上述情况，并对实时计算平台赋能进行了深入积累，也有一些经验和思考。
综上所述，由于面对极其复杂的业务场景和技术挑战，滴滴出行大数据架构部为此专门成立实时计算团队进行底层架构的深度优化以及开发平台的构建，并逐步将BI实时监控和实时业务报警等业务实现用平台来承接，完成了实时计算在滴滴内部的平台化和服务化。以下会从技术方案，系统架构，和平台产品等方面对其进行深入介绍。
技术方案和案例
实时计算和实时数据处理的数据流程，通常都会包括如下几个环节：
数据产生
数据采集
数据清洗（ETL）
数据计算
数据应用
而数据应用下通常会让数据有如下几个应用出口：
Sink到持久化存储系统，以便后续进行离线分析
实时监控大盘
实时API调用
实时计算平台
抽象出滴滴的实时数据流整体架构和流程后，构建了支撑实时数据流计算的实时计算系统，其整体架构如下：
如上图所示，滴滴实时数据流的整体架构中也包含了数据产生，数据采集，数据清洗（ETL），数据计算，以及最终将其应用到各个业务环节的过程。在上图系统架构中，包含有数据采集的消息中间层Kafka，实时计算引擎采用了目前社区活跃度和整体设计架构最先进的SparkStreaming和Flink两套计算引擎，计算结果分别根据不同业务需要写入实时的存储和查询系统（Druid，HBase和ES，甚至包括写会mis系统的mysql等）。
该实时计算平台为业务提供如下保证：
1.易用性：Web化操作，无需登入客户机；资源按需申请；自带Metrics监控
2.安全性：专用集群，避免批处理任务干扰；基于CGroup的进程级隔离机制；基于NodeLabel的业务级格隔离方案
3.稳定性：大数据底座SLA：99.95%；完善的监控报警体系；7*24小时专家团队技术支持；
基于以上实时平台，就可以构建不同的实时计算业务，以下会简单介绍几个实时计算的案例分享。
BI实时监控
如上文业务挑战中介绍，由于滴滴要面对非常复杂的业务场景，滴滴的数据本身就会有几多的维度和指标细分，数据分析团队和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，来向司机实时的推送乘客的位置变化，比如乘客已出发，乘客已到达，乘客正在移动等等信息，就可以方便司机准确的判断乘客的状态，以便准确的接驾。司机和乘客也可以不必进行过多的电话沟通，提升接驾效率，也降低司机的接驾成本和提升司机的驾驶安全。
通过将实时订单数据流和乘客数据流进行join的业务架构如下：
通过Flink引擎对两个实时数据流进行join，并将司乘的中间状态进行缓存，并通过publisher系统实时从codis中将实时计算出来的状态变化推送给司机，已达到预期效果。该项目上线后，推送准确率达到94%。
平台构建&赋能
实时平台的底层存储和计算引擎为实时计算提供了架构支撑，但实际应用中这些系统的使用门槛通常都比较高，需要业务开发者有比较深厚的技术积累才能很好的使用。这无疑给平台为用户赋能上造成了比较大的门槛。为此滴滴实时计算团队抽象了用户开发实时计算任务过程中需要通过平台赋能的一些场景，如下图所示：
其中绿色指引部分即为用户在开发中需要通过平台工具提升效率的点。
出于更好的赋能用户的目的，滴滴实时计算团队依托为各业务团队开发大数据实时计算应用沉淀下来的经验，前瞻性的提出了构建实时数据一站式服务平台的理念，以创新的产品设计和技术手段，完成了从一款定制化的实时数据产品到通用的一站式实时数据服务平台的转变。通过高效整合实时数据采集、ETL、血缘关系展示、计算任务管理，监控大屏及报警策略配置等环节，对外开放和输出实时计算和分析能力，解放自己，赋能用户。有效解决了在团队人力严重不足的情况下，如何快速满足全公司全业务线大量的、迫切的业务监控需求的难题，有力的支撑了公司业务的快速发展，为线上业务保驾护航。在业界（无论国内还是国外），实时计算平台作为一个崭新的领域，具有非常大的技术挑战性。
该平台提供了如下关键功能和突破。
实时计算任务管理和调度
1.为多种实时计算引擎（SparkStreaming、Flink Streamin、Samza）提供统一的资源管理及任务调度功能，提供统一的可视化管理界面，自动同步Hadoop YARN状态
2.成本计价透明化：对接成本中心，计算资源申请、审批流程化、服务化
3.计算任务监控：计算任务Metrics统一上报，发现任务异常会及时给用户发送报警
CloudIDE
1.在业界开创性的将实时计算任务的开发环境从桌面搬到云端，整合了云端的数据资源、计算资源、安全体系，为实时计算量身定制开发环境。通过Kubernetes及Docker为每个用户分配完全隔离的容器作为开发环境，避免了相互影响。
2.提升用户开发实时计算任务的效率：整合云端数据资源（如链接Kafka、Druid、Hadoop），统一了开发环境，方便用户开发、测试、部署实时计算程序
3.内置项目管理、代码编辑器、WebTerminal等功能
4.内置多个代码模板，方便用户快速针对常见应用场景进行开发
5.支持Java、Scala、Python等开发语言
实时数据API开放平台：让用户更便捷的获取实时数据
支持对OLAP Cube进行可视化建模
1.支持原子指标和复合指标的配置
2. 基于SQL配置数据指标API，支持Group by , TopN的查询
3.拓展SQL语法，提出SQL占位符的概念，实现SQL的动态生成，使得查询有可筛选的能力，提高SQL复用率
4.提供API公共网关：对API访问权限、频率进行控制，保证数据安全
5. API服务化：使实时数据API申请、授权、访问实现流程化、服务化、自动化，提升数据获取的便捷性、安全性
监控大屏配置
基于图数据库技术，实时、动态分析数据链路，数据上下游一目了然
另外还有诸如实时数据血缘关系，数据分析notebook，可视化组件等等工具帮助用户更好的分析和使用数据。
总结和思考
随着互联网业务的不断发展，对大数据平台的存储和计算需求这几年也在逐渐的向偏实时化和智能化发展，对平台和架构也提出了新的要求和挑战。平台和业务在改善用户体验和赋能用户的追求是不会有止尽的。作为基础平台部门，也需要不断的探索能够更好支撑业务需求的架构和系统，为服务用户，改善用户体验保驾护航。
提升卡
置顶卡
沉默卡
变色卡
抢沙发
千斤顶
显身卡
京公网安备 11010802022788号
