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

赋能

通常技术部门会有比较偏向业务本身的技术团队和偏向底层架构和平台的技术团队，由于业务初期为了能够快速响应，通常是有业务的需求人直接提需求给平台架构团队直接进行开发，而由于底层平台团队没有很方便的工具和开发平台，这就绕过了对业务特征理解更深的业务技术团队，而由平台架构的技术部门直接对业务数据需求进行响应。而如果能够构建足够方便直观的开发平台，就可以将这些开发工作转而由对业务更加理解的业务技术团队进行个性化的定制开发，平台架构团队转而专注于平台和底层架构的优化，并通过不断的完善对业务开发团队进行赋能。这种团队分工的转变有利于提升各自团队的效率和专注度，也能够让业务团队对支撑的技术团队有足够明确的接口人和接口部门。在滴滴实时计算和实时监控的服务中，逐渐发现上述情况，并对实时计算平台赋能进行了深入积累，也有一些经验和思考。

综上所述，由于面对极其复杂的业务场景和技术挑战，滴滴出行大数据架构部为此专门成立实时计算团队进行底层架构的深度优化以及开发平台的构建，并逐步将BI实时监控和实时业务报警等业务实现用平台来承接，完成了实时计算在滴滴内部的平台化和服务化。以下会从技术方案，系统架构，和平台产品等方面对其进行深入介绍。

技术方案和案例

实时计算和实时数据处理的数据流程，通常都会包括如下几个环节：

?? 数据产生

?? 数据采集

?? 数据清洗(ETL)

?? 数据计算

?? 数据应用

而数据应用下通常会让数据有如下几个应用出口：

?? Sink到持久化存储系统，以便后续进行离线分析

?? 实时监控大盘

?? 实时API调用

实时计算平台

抽象出滴滴的实时数据流整体架构和流程后，构建了支撑实时数据流计算的实时计算系统，其整体架构如下：

如上图所示，滴滴实时数据流的整体架构中也包含了数据产生，数据采集，数据清洗(ETL)，数据计算，以及最终将其应用到各个业务环节的过程。在上图系统架构中，包含有数据采集的消息中间层Kafka，实时计算引擎采用了目前社区活跃度和整体设计架构最先进的SparkStreaming和Flink两套计算引擎，计算结果分别根据不同业务需要写入实时的存储和查询系统（Druid，HBase和ES，甚至包括写会mis系统的mysql等）。

该实时计算平台为业务提供如下保证：

?? 易用性：Web化操作，无需登入客户机；资源按需申请；自带Metrics监控 ；

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

?? 稳定性：大数据底座SLA：99.95%；完善的监控报警体系；7*24小时专家团队技术支持；

基于以上实时平台，就可以构建不同的实时计算业务，以下会简单介绍几个实时计算的案例分享。

BI实时监控

如上文业务挑战中介绍，由于滴滴要面对非常复杂的业务场景，滴滴的数据本身就会有很多的维度和指标细分，数据分析团队和BI人员也会针对数据的不同维度和各种维度组合进行各种各样的分析和提取，其中就包括对业务数据进行精准实时的统计监控，以及针对各种业务指标的曲线进行指标突变的模型和阈值报警等。

BI实时监控的数据流整体机构如下：

由于业务监控的数据大多来自线上mysql的binlog，因此BI实时监控的数据可以做到在业务口径上完全准确，直接可以跟财务和收银系统一致。mysql的binlog通过采集系统实时写入到kafka进行缓存，也等待后续实时计算引擎对其进行消费和计算处理。考虑到有可能因为业务变更和一些特殊原因需要对历史数据进行回溯，所以kafka中的binlog数据会按照不同策略保存响应的历史周期，比如1周或者3天。

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