时序数据在滴滴实时数据开发平台中的处理和应用

本文涉及的产品
云数据库 MongoDB,独享型 2核8GB
推荐场景:
构建全方位客户视图
云原生多模数据库 Lindorm,多引擎 多规格 0-4节点
云数据库 Tair(兼容Redis),内存型 2GB
简介: 在阿里云栖开发者沙龙时序数据库技术专场上,滴滴高级研发工程师张婷婷为大家介绍了滴滴实时数据开发平台的架构变迁,为大家揭示了滴滴如何应用Druid、Spark Streaming以及Flink等主流技术来优化时序数据的加工、存储与查询。

本文根据演讲视频以及PPT整理而成。

本文将主要围绕以下三个方面进行分享:

  1. 背景简介
  2. 技术方案
  3. 当前现状

一、 背景简介
滴滴实时数据开发平台源于这样的初衷,即构建业务监控的双眼,用以监控发生的时事对系统业务交易量是否产生影响。此外,数据可能存在异常和波动,直接监控数据较为低效,时序数据还用以实时报警,帮助相关运营人员排查情况。实时监控和实时报警是滴滴数据管理的两个最核心场景。

1

2015年以前,滴滴数据管理的架构非常简单。通过扫描Mysql的从表和api数据进行预计算,预计算的操作结果先存储于本地文件,再定时上传到CKV数据库。以计算城市订单量为例,一级目录是城市id,二级目录是日期,预计算的操作结果先按照目录结构存储于本地文件,再定时上传到CKV数据库中。这种简单架构的瓶颈是显而易见的,即指标开发和扩展的难度较大。随着指标增多,在Mysql中维系配置越来越麻烦,并且往往牵一发而动全身。扩展目录也非常麻烦,以增加产品线维度为例,在原来的一级目录和二级目录之间增加产品线维度要求本地文件目录和数据库都需要修改,存储和计算成本呈指数级别增长。问题的根本原因在于,这种架构无法保证数据的及时性和稳定性。链路的延迟以及使用脚本扫描数据使得数据量越大数据查询越慢,数据及时性较差;通过api或者数据库查询无法保证不重不漏地消费数据,数据稳定性较低。

2

从2015年开始,滴滴针对数据及时性和稳定性两方面进行优化。滴滴数据管理的流程分为几个阶段,首先输入业务数据,对数据进行加工和存储,再经过查询输出相关指标。
2015年以前,数据管理平台使用app请求实现所有连接,不仅影响系统的吞吐性能,还可能存在数据遗漏。2015年之后,滴滴引入了消息队列实现连接,利用消息队列的数据吞吐量优势和ack机制降低了链路时延,同时保证了链路的稳定性。此外,还将数据加工替换为实时计算引擎,进一步降低系统时延。
查询指标涉及到数据计算,数据计算可以在业务数据加工时进行,可以在数据存储时进行,也可以在数据查询时进行。数据计算越迟进行,前期数据的复用率越高,因此滴滴选择在数据查询时进行数据计算。比如,查询实时订单呼叫量时,在数据加工处进行数据计算并存储,在新增实时订单应答量时,仍需开发新的实时任务进行计算;实时集群的资源是有限的,如果每开发一个指标都新增一个实时任务,将会带来极大的资源浪费。假如在数据加工时进行ETL清洗,在数据存储时仅存储简单的订单表,而在数据查询时才进行数据计算就可以复用之前数据计算的结果,从而节省集群资源。这对数据库的查询和存储能力提出了较高的要求。传统的事务型数据库仅针对事务,而不针对数据分析场景,因而不适用于时序数据查询,针对此,滴滴引入了OLAP引擎。由于所有业务数据都具有时序特点,滴滴选择了KAFKA+SMAZA+DRUID的OLAP引擎。

3

下图展示了2015年到2017年初的架构图,所有线上业务数据使用Kafka进行实时数据流存储,经过实时计算加工,再写回Kafka。然而,这存在开发周期过长,开发语言复杂,现有人力成本跟不上业务需求变更的开发瓶颈。同时,还存在调用链路较长,实时数据资产管理混乱等缺点。为了应对此开发瓶颈,滴滴致力于实现实时数据管理的一体化平台,允许全公司共同参与数据的采集、加工和存储等工作。

4

由此,滴滴构建了实时计算开发平台Woater,以实现降低开发难度、实时资产管理等优化目标。

5

二、 技术方案
下图展示了2017年至今,滴滴实时计算开发平台采用的技术框架。Mysql的数据从表通过Canal采集,文本日志通过Swan采集,采集到的数据存储于Kafka Topic中。实时计算引擎层引入了Spark Streaming和Flink,对采集到的数据进行数据加工,再写入Druid中。此外,平台还引入了离线数据,使用HIVE将其与实时数据结合,提高了消息队列的数据查询能力。
当数据写入Druid Datasource后,平台会生成所有数据的模板,并落地存储,开放给所有用户使用,开放的功能包括实时监控、报警服务等。此外,平台还允许用户自定义功能,比如根据实时应答率动态调节产品价格等。
另外,滴滴实时数据开发平台还提供了血缘管理、权限管理两个支线功能。血缘管理将平台所有资产,包括Kafka任务和api等实时写入血缘管理模块,方便用户查看任意数据的上下游流动情况。数据开发平台的每个模块都相互解耦,因此滴滴还为每个模块都实现了权限管理功能。

6

Druid是针对时序数据提供低延时的数据写入以及快速交互式查询的分布式OLAP数据库。在数据写入时,由用户发起实时数据写入任务,通过overload节点将任务发布到各个MiddleManager节点上,MiddleManager节点进而发起子任务,实时拉取数据并存储到Deep Storage中,保证了历史数据的高可用。Druid支持的Deep storage类型包括Amazon S3, HDFS等任意文件系统。在数据查询时,来自客户端的请求首先到达Broker节点,由Broker节点查询全局的数据分片拓扑图,从而将查询拆分成若干子查询,涉及到实时数据的子查询由MiddleManager节点执行,涉及到历史数据的子查询由Historical节点执行,子查询结果在Broker节点汇总并返回给前端。

7

Druid针对时序数据的存储与查询进行了多项优化。在数据分片设计方面,Druid将所有数据分成了三个属性,包括时间戳,维度和指标。时间戳和指标都采用整数型或者浮点型进行本地存储,因此具有很高的压缩比。字符串数据在本地存储时不会直接存储为字符串格式,而是将其生成映射表。以属性维度的Page为例,映射表可能将“Justin Bieber”映射为0,将“ke$ha”映射为1,那么Page列数据在数据库中将存储为“0011”,因而也具有较高的压缩比。为了加快查询,Druid还为每个值维系一个倒排索引,比如,“Justin Bieber”在Page列的倒排索引为“1100”,“ke$ha”在Page列的倒排索引为“0011”。在查询Page等于“Justin Bieber”时,只需挑选索引中为“1”的项。在进行多列筛选时,只需将各列的索引进行异或计算,比如要查询Page等于“Justin Bieber”且Username等于“Reach”的数据项时,按照倒排索引逻辑,仅需将“0100”和“Justin Bieber”的倒排索引进行异或。

8

下面列出了Druid的主要优化方法。一方面,Druid采用列式Segment进行存储,另一方面,它采用基于字典的编码对维度列进行压缩,从而提高压缩比。此外,Druid还引入了Rollup聚合存储机制,允许用户自定义数据聚合规则,提高数据的查询效率。
优化后的Druid实现了数据实时可查询,同时提供亚秒级的查询效率,99%的数据查询可以在1秒内返回结果,这对于拥有700+数据源和日均查询量近2000千万的集群而言非常难得。此外,Druid还将数据压缩到了其原始大小的1/30,实现了极高的压缩比。

9

然而,Druid存在数据加工能力较弱的缺点,仅依赖Druid很难实现两个表的Join操作。
滴滴实时数据开发平台的解决方案是在数据加工层引入主流的SparkStreaming和Flink技术,二者代表了实时计算引擎的两种不同设计方向。Spark Streaming以Spark引擎为基础发展而来,将基于离线数据的批计算压缩为微批操作,使其变成近乎实时的计算。Spark生态具有极高的活跃度,对Spark相关技术熟悉的人员可以快速上手Spark Streaming。Flink适用于低延迟的数据处理场景,支持实时处理数据,同时支持从下至上兼容批处理。此外,Flink还能够提供“exactly once”的实时处理方案和不重不漏的数据消费。

10

在开发方式方面,滴滴实时数据开发平台提供了多种用户操作以适应更多用户。针对具有流基础的用户,平台提供了Web IDE,支持在线开发编译,在线提交配置,减少了本地配置开发环境的困难。针对具有编程经验的用户,平台提供了StreamSQL和DruidSQL,StreamSQL允许用户使用SQL方式进行数据加工,降低用户的平台上手难度,DruidSQL可用于Druid相关的查询同时帮助用户进行在线调试。此外,滴滴还提供了可视化拖拽等功能帮助指标查询,方便初级用户。

11

三、 当前现状
目前,滴滴实时数据开发平台提供的实时监控功能已覆盖滴滴的全部核心业务线,包括国内和国际化业务。提供的实时监控服务实现了秒级延时,支持每秒刷新。另外,滴滴团队还对底层Druid进行了优化,实现了99.995%的可用性。滴滴实时数据开发平台的这些能力针对平台的所有用户全部开放。

12

在异常报警方面,根据实时的血缘链路,滴滴实时数据开发平台承诺实现的准确性达到3次误报,1次漏报。在异常报警时,平台将筛除数据正常范围的延迟、抖动和链路异常,减少误报率。在及时性方面,滴滴实时数据开发平台承诺能在1分钟内快速响应问题。

13

同时,滴滴实时数据开发平台还提供了大中小屏可视化方案,从而为用户提供更丰富的图表和更灵活的配置方式。

14

相关文章
|
6月前
|
数据采集 监控 数据挖掘
如何更有价值采集电商数据,高效分析数据?
大数据,就是在一定时间范围内用常规工具软件对历史数据捕捉、处理,加以分析,进而改善决策和管理。在大数据时代,企业必须用大数据分析方法来做电商。
|
存储 消息中间件 缓存
腾讯看点基于 Flink 的实时数仓及多维实时数据分析实践
当业务发展到一定规模,实时数据仓库是一个必要的基础服务。从数据驱动方面考虑,多维实时数据分析系统的重要性也不言而喻。但是当数据量巨大的情况下,拿腾讯看点来说,一天上报的数据量达到万亿级的规模,要实现极低延迟的实时计算和亚秒级的多维实时查询是有技术挑战的。
腾讯看点基于 Flink 的实时数仓及多维实时数据分析实践
|
4月前
|
存储 数据可视化 数据挖掘
实时数据分析系统的构建与优化
【7月更文挑战第29天】实时数据分析系统的构建与优化是一个复杂而细致的过程,需要从需求分析、数据源确定、数据采集与传输、数据处理与分析、数据存储、数据可视化、系统部署与配置、监控与优化等多个方面进行综合考虑。通过选择合适的技术栈和优化策略,可以构建出高效、稳定的实时数据分析系统,为企业决策提供强有力的支持。
|
6月前
|
存储 消息中间件 SQL
分钟级实时数据分析的背后——实时湖仓产品解决方案
袋鼠云在结合当前数据湖技术的基础上,建设实时湖仓平台,满足客户“快、精、准”的数据需求。本文将详细介绍实时湖仓产品解决方案,让企业能够更专注地去解决他们的业务价值。
146 0
|
12月前
|
存储 消息中间件 数据可视化
Dataphin实时研发实践—电商场景下的实时数据大屏构建
实时数据大屏是实时计算的重要应用场景之一,广泛应用在电商业务中,用于实时监控和分析电商平台的运营情况。通过大屏展示实时的销售额、订单量、用户活跃度、商品热度等数据指标,帮助业务人员随时了解业务的实时状态,快速发现问题和机会。同时,通过数据可视化和趋势分析,大屏也提供了决策支持和优化运营的功能,帮助业务人员做出及时的决策和调整策略,优化电商业务的运营效果。 下面以电商业务为背景,介绍如何构建经典实时数仓,实现实时数据从业务库到ODS层、DWD层、DWS层全链路流转,基于Dataphin和Quick BI实现实时数据大屏。
505 0
|
消息中间件 前端开发 Java
实时即未来,车联网项目之车辆驾驶行为分析【五】
单次行驶里程区间分布、单次行程消耗soc区间分布、最大里程分布、充电行程占比、平均行驶里程分布、周行驶里程分布、最大行驶里程分段统计、常用行驶里程、全国-每日平均行驶里程(近4周)、全国-单车日均行驶里程分布(近一年)、各车系单次最大行驶里程分布、不同里程范围内车辆占比情况。
349 0
实时即未来,车联网项目之车辆驾驶行为分析【五】
|
消息中间件 JSON 物联网
实时即未来,车联网项目之原始终端数据实时ETL【二】
实时即未来,车联网项目之原始终端数据实时ETL【二】
230 0
实时即未来,车联网项目之原始终端数据实时ETL【二】
EMQ
|
数据采集 存储 人工智能
高效数据通道支撑生产情况实时分析与可视化
EMQ生产数据可视化解决方案海量保障生产数据传输和持久化的实时性、可靠性、安全性,为大数据分析、人工智能应用提供良好数据基础。
EMQ
178 0
高效数据通道支撑生产情况实时分析与可视化
|
多模数据库 物联网 数据处理
明日14点开播!多模数据库Lindorm的车联网轨迹数据处理技术与应用解析
《数据库风向标》是一档聚焦数据库新趋势与新技术的视频栏目,节目每期会请到几位资深技术大咖,与大家共话数据库热点话题。
明日14点开播!多模数据库Lindorm的车联网轨迹数据处理技术与应用解析
|
消息中间件 SQL 运维
如何设计实时数据平台(技术篇)
本文从技术角度入手,介绍RTDP的技术选型和相关组件,探讨适用不同应用场景的相关模式。