滴滴实时计算平台在运行监控中的应用

项目背景

随着Didi近年来业务的不断发展，用户（乘客和驾驶员）不断提出改善体验的新要求. 不仅如此，滴滴的内部数据和运营团队越来越实时，丰富而精确的营销策略对基础技术支持平台的要求越来越严格和高效，不仅要求数据更加实时（从白天到小时）到第二级（甚至毫秒），需要更准确的数据（不重复，不丢失），并且需要基于数据的更丰富的用户肖像和用户标签. 因此，对底层技术平台和系统的各个方面都提出了更高的要求.

业务挑战

Didi每天将有数千万笔交易订单. 每次下订单时，用户呼叫和路径规划都会向后台发出一系列呼叫. 由于滴滴目前为全球数百个城市的用户提供服务，因此出于各种原因，不同的城市需要有针对性的运营策略. 在同一城市的不同位置（例如，机场，大型活动，音乐会体育场等），不同的现场条件还产生了不同的业务特征. 同时，由于滴滴出行本身为不同的用户提供了多种服务类型（如特快，特惠，特价车，主车租赁，顺风，成本，小巴等），不同的产品和服务背景策略和逻辑不一样. 滴滴的司机团队也来自各种合作平台和直销平台，这进一步加剧了业务的复杂性. 如何每天，每秒地针对复杂且快速变化的业务场景（例如不同的城市，不同的位置，不同的产品，不同的驾驶员和不同的乘客类型）进行高效，准确，多维组合和细粒度的实时数据监视在不同情况下的实时风险控制和警报提醒，由于这些需求，如何满足滴滴业务团队对底层技术团队和支持平台的要求，是滴滴大数据实时计算面前的一个巨大问题. 和平台团队.

技术挑战

对于实际业务的各种业务变化，例如订单呼叫量，订单响应量，订单交易量，实时响应率，平均行驶距离等，这些数据应反馈给运营团队实时业务团队在仪表板上，即使不考虑更复杂的业务场景，在如此庞大的数据量下，仅获得实时且准确的数据已经是一个很大的挑战. 从业务行为的生成到生成的日志数据，再到将日志收集到大数据平台，清理，分析和汇总此数据，再写入实时查询系统，最后将其呈现给业务团队的监视市场实际上是一个非常长且非常复杂的数据链接. 它涉及业务日志标准规范，实时数据收集和清理，实时计算，实时聚合和其他基础支持系统和平台，多个链接连接和连接，以及技术团队对业务的自上而下的理解和实施特征. 不仅如此，由于业务和战略的日新月异，经常需要调整和适应各种特殊情况和策略，这对基础技术的可伸缩性和灵活的适应能力提出了更高的要求.

授权

通常，技术部门将拥有一个更喜欢业务本身的技术团队和一个更喜欢基础架构和平台的技术团队. 为了能够在业务的早期阶段迅速做出响应，通常是业务的需求直接提高了对平台体系结构团队进行直接开发的需求，并且由于底层平台团队没有非常方便的工具和开发平台，这使业务技术团队对业务特征有了更深入的了解，而平台架构的技术部门则直接响应业务数据需求. 如果您可以构建一个方便且直观的开发平台，则可以由了解业务的业务技术团队将这些开发工作变成个性化的自定义开发. 相反，平台体系结构团队专注于平台和基础体系结构的优化，并通过持续改进来赋予业务开发团队权力. 劳动分工的这种转移有利于提高各个团队的效率和集中度，并且还使业务团队能够为支持的技术团队配备足够清晰的接口人员和接口部门. 在滴滴的实时计算和实时监控服务中，上述情况逐渐被发现，并且实时计算平台的授权能力得到了深厚的积累，也有一些经验和想法.

总而言之，由于极其复杂的业务场景和技术挑战，滴滴出行大数据架构部门已成立了一个实时计算团队，以深入优化底层架构和开发建设平台. 实时监控，实时业务警报和其他服务通过一个平台来实现，以在Didi中完成实时计算的平台化和服务化. 下面将在技术解决方案，系统架构和平台产品方面进行深入的介绍.

技术解决方案和案例

实时计算和实时数据处理的数据流通常包括以下链接:

数据生成

数据收集

数据清除（ETL）

数据计算

数据应用

数据应用程序通常允许按以下方式导出数据:

沉入永久性存储系统以进行后续脱机分析

实时监控市场

实时API调用

实时计算平台

在抽象了Didi实时数据流的总体架构和过程之后，构建了一个支持实时数据流计算的实时计算系统. 总体架构如下:

如上图所示，Didi的实时数据流的总体体系结构还包括数据生成，数据收集，数据清理（ETL），数据计算以及最终将其应用于各种业务链接的过程. 在以上系统体系结构中，包括了具有数据收集功能的消息中间层Kafka. 实时计算引擎使用当前社区活动以及最先进的SparkStreaming和Flink两组计算引擎的总体设计架构. 计算结果根据不同的业务需求编写. 实时存储和查询系统（Druid，HBase和ES，甚至包括mysql等）.

实时计算平台为业务提供以下保证:

易用性: 基于Web的操作，无需登录客户端；资源按需使用；带有指标监控

安全性: 专用集群，避免批任务干扰；基于CGroup的进程级隔离机制；基于NodeLabel的业务级网格隔离方案

稳定性: 大SLA: 99.95％；完善的监控报警系统； 7 * 24小时专家团队技术支持；

基于上述实时平台，可以构建不同的实时计算服务. 下面将简要介绍一些实时计算案例共享.

BI实时监控

正如上面的业务挑战中所述，由于Didi面临非常复杂的业务场景，因此Didi的数据本身将具有多个维度和指标，并且数据分析团队和BI员工还将以数据为目标. 不同的维度和各种维度的组合用于各种分析和提取，包括对业务数据的准确和实时统计监视，以及各种业务指标曲线的指标突变的模型和阈值警报.

BI实时监视的数据流的总体结构如下:

由于大多数业务监视数据来自mysql binlog，因此BI实时监视数据在业务水平上可以令人满意地准确，并且可以直接与财务和收银机系统保持一致. mysql的binlog通过收集系统实时写入kafka进行缓存，并且还等待随后的实时计算引擎使用和计算它. 考虑到由于业务变化和某些特殊原因可能需要回溯历史数据，kafka中的binlog数据将根据不同的策略（例如一星期或三天）保存历史响应时间.

将数据收集到kafka中之后，实时计算平台的SparkStreaming和Flink引擎将实时清理并计算kafka中的实时binlog数据. 该平台之所以选择SparkStreaming和Flink引擎，是因为它们可以为实时计算级别提供两级microBatch和完全基于Stream的计算要求，同时在各自的结构上提供结构化数据处理，SQL接口和Window引擎界面支持非常完整，并且仍在改进中.

在实时清理和计算数据之后，可以将某些部分直接下沉到持久性存储系统（例如HDFS）中进行存储，以便可以以报告的形式脱机分析和计算它们，并且方便详细查询实时指标等需求. 实时数据的其他部分根据业务需要写入Druid系统. 由于Druid可以对数据执行实时聚合计算，因此非常适合诸如topN，GroupBy，Filter，Count等实时查询，因此非常适合BI实时监视业务需求. 从Druid查询实时指标后，它们将由业务应用程序通过API直接引用以进行逻辑调度，或作为实时业务报告并监视操作和BI团队以查看在仪表板上显示.

业务团队不仅需要查看实时指标，而且系统还需要为各种业务指标的曲线突变提供实时警报，以及时发现业务突变并采取相应的措施. BI实时监控为各种业务指标提供了一套警报配置系统，允许用户为业务特征设置模型或阈值警报设置. 这样，实时指标的任何突然变化都会立即向相应的值班人员发送电子邮件，短信和电话，以确保尽快响应业务的突然变化.

实时推送乘客位置语义

在通常的乘客计费中，在驾驶员收到订单后，直到乘客上车之前，驾驶员和乘客之间的通信成本相对较高. 由于道路状况，路边位置以及计费后乘客的位置的变化，驾驶员由于交叉路口等需要转身，乘客和驾驶员通常需要在乘客上车之前通过几个电话进行通信. 交易中的小摩擦导致交易失败，甚至引起驾驶员和乘客之间的误会.

由于Didi平台可以了解驾驶员的乘客流量和订单流，因此如果可以通过实时数据流将驾驶员和订单合并在一起，则可以将驾驶员的位置更改实时推送给驾驶员例如，乘客已离开而乘客已到达，乘客正在行驶等，方便驾驶员准确地确定乘客的状态，从而准确地上车. 驾驶员和乘客还可以避免过多的电话通讯，从而提高了接送效率，降低了驾驶员的接送成本，并提高了驾驶员的驾驶安全性.

通过结合实时订单数据流和乘客数据流的业务架构如下:

Flink引擎将两个实时数据流合并，缓存驱动程序的中间状态，并通过发布者系统实时将实时计算的状态更改从codis推送到驱动程序，从而实现了预期的效果. 项目上线后，推送准确率达到94％.

平台建设与授权

实时平台的底层存储和计算引擎为实时计算提供了体系结构支持，但是这些系统的实际应用门槛通常较高，业务开发人员需要具有深厚的技术积累才能很好地使用它. 毫无疑问，这为平台授权用户创造了一个相对较大的门槛. 为此，Didi实时计算团队提取了一些场景，这些场景需要在开发实时计算任务时由平台授权用户，如下图所示:

绿色指南部分是用户在开发过程中需要通过平台工具提高效率的点.

为了更好地增强用户能力，滴滴实时计算团队依靠为各个业务团队开发大数据实时计算应用程序而积累的经验，并且前瞻性地提出了构建一个单一的实时数据的一站式服务平台创新的产品设计和技术手段已经完成了从定制的实时数据产品到通用的一站式实时数据服务平台的转换. 有效集成实时数据收集，ETL，血缘关系显示，计算任务管理，监视大屏幕和警报策略配置等，打开并输出实时计算和分析功能，解放自己并赋予用户权力. 有效解决了在团队人力资源严重不足的情况下，如何快速满足公司整个业务线的大，紧急业务监控需求的问题计算平台，有力地支持了公司业务的快速发展，并护送业务. 在业界（无论是国内还是国外），实时计算平台作为一个崭新的领域，都面临着很大的技术挑战.

该平台提供以下关键功能和突破.

实时计算任务管理和调度

为多个实时计算引擎（Spark Streaming，Flink Streamin，Samza）提供统一的资源管理和任务调度功能，提供统一的可视化管理界面，并自动同步Hadoop YARN状态

定价透明: 与成本中心对接，计算资源申请，审批流程和服务

监控计算任务: 统一报告计算任务指标，发现异常任务会及时向用户发送警报

CloudIDE

开拓行业中从台式机到云的实时计算任务的开发环境，集成云数据资源，计算资源和安全系统，以量身定制用于实时计算的开发环境. 通过Kubernetes和Docker，为每个用户分配了一个完全隔离的容器作为开发环境，从而避免了相互影响.

提高用户实时计算任务开发效率: 集成云数据资源（例如与Kafka，Druid，Hadoop的链接），统一开发环境，并方便用户进行实时开发，测试和部署时间计算程序

内置项目管理，代码编辑器，Web Terminal等功能

内置多个代码模板，以方便用户针对常见的应用场景快速开发

支持Java，Scala计算平台，Python和其他开发语言

实时数据API开放平台: 让用户更方便地获取实时数据

支持OLAP Cube的可视化建模

支持原子指标和复合指标的配置

基于SQL配置数据索引API，支持Group by，TopN查询

扩展SQL语法，提出SQL占位符的概念，实现SQL的动态生成，使查询具有过滤能力，提高SQL重用率

提供API公共网关: 控制API的访问权限和访问频率，以确保数据安全性

API服务: 实现实时数据API的应用，授权以及访问过程，服务和自动化，以提高数据获取的便利性和安全性

监视大屏幕配置

基于图技术，对数据链接进行实时动态分析，一目了然

此外，还有诸如实时数据血液关系，数据分析笔记本，可视化组件等工具，可帮助用户更好地分析和使用数据.

总结与反思

随着Internet业务的不断发展，近年来大数据平台的存储和计算需求已逐渐向实时和智能发展，对平台和体系结构也提出了新的要求和挑战. 追求平台和服务以改善用户体验并赋予用户权力永远不会停止. 作为基础平台部门，它还需要不断探索可以更好地支持业务需求，护送服务用户并改善用户体验的体系结构和系统.

关于作者

Luo Li，滴滴出行技术研究员，滴滴基金会平台部大数据架构部负责人，负责大数据下实时，离线，NOSQL，OLAP等大数据存储计算引擎的开发和测试. 架构团队，升级，上线以及运营和维护，数据开发平台和产品，每个团队的技术和团队合作.

前阿里巴巴高级技术专家，阿里云梯子的创始人之一，云梯负责人，先后在阿里巴巴搜索技术中心，阿里巴巴集团研发研究院，阿里云和淘宝数据团队. 主要负责开发，测试，性能瓶颈分析，性能优化，集群管理，集群维护，监控，应用团队分布式技术支持，公司内部培训以及阿里集团内部的hadoop技术推广等工作. 这是阿里集团派遣团队成立之初的第一批员工重返搜狐，了解更多

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