回顾:
- Day6 离线数据开发之数据开发平台
- Day5 数据同步遇到的问题与解决方案
1. 简介
阿里巴巴在流式数据处理方面采用了多种技术和框架,这些技术的特点包括:
-
高可伸缩性:
阿里巴巴使用Apache Flink进行大规模数据处理,Flink能够处理极高吞吐量的数据流,据报告在双11期间峰值处理能力达到17亿条记录每秒,这体现了其在分布式环境下的高可伸缩性和处理能力。 -
实时性:
阿里巴巴利用流式计算技术实现实时数据处理和分析,这意味着数据可以在到达后立即被处理,这对于需要即时反馈的场景(如实时监控、广告投放、风控等)至关重要。 -
数据一致性:
使用Flink的stateful stream processing特性,阿里巴巴能够确保在故障恢复后数据处理的一致性和准确性,避免数据丢失或重复处理。 -
集成能力:
阿里巴巴的流式处理系统能够与多种数据源和目标系统集成,包括数据库、消息队列、日志服务等,这使得数据可以无缝地流入和流出流处理管道。 -
自研技术:
除了开源框架,阿里巴巴也开发了自己的流式大数据平台StreamCompute,它在内部支持了集团的流式计算需求,提供了更定制化的解决方案。 -
统一的数据管理:
OneData方法体系和工具提供了数据整合和治理的能力,确保数据的统一管理和质量控制。
这些技术的应用使阿里巴巴能够处理和分析来自不同来源的海量数据,包括传感器数据、应用程序日志、社交媒体信息等,从而实现更高效的数据驱动型业务运营。
2. 流式技术架构
2.1 简介
流式技术架构通常围绕实时数据处理和分析构建,其子系统可以根据功能划分为以下几个关键部分:
数据采集
-
数据源(Source):
- 这是数据的初始产生点,可以是传感器、日志文件(如订单的修改日志)、数据库更新、消息队列或其他任何产生实时数据的系统。
-
数据摄取(Ingestion):
- 负责从各种数据源收集和导入数据,可能包含数据格式转换、清洗和初步的预处理工作。
数据处理
-
流处理引擎(Streaming Processing Engine):
- 这是流式架构的核心,负责实时处理和分析数据流,执行诸如过滤、聚合、窗口操作、连接等任务。常见的流处理引擎包括Apache Kafka Streams、Apache Flink、Apache Spark Streaming等。
-
状态管理(State Management):
- 处理状态保持和恢复,确保数据处理的一致性和容错性。状态管理对于需要维护上下文或历史数据的复杂流式应用尤为重要。
-
事件路由和分发(Event Routing and Distribution):
- 将数据流定向到正确的处理模块或下游系统,可能涉及负载均衡和数据分区策略。
数据存储(Storage)
:- 存储处理后的数据,以便后续的查询、分析或持久化存储。可能包括关系数据库、NoSQL数据库、时序数据库或数据仓库。这里的写操作是增量操作,且是源源不断的。
数据服务
在存储系统上架设一层服务层,如提供HSF接口、HTTP服务等,用于获取实时计算结果。
-
实时分析和查询(Real-time Analytics and Querying):
- 提供对流数据的实时分析和查询能力,可能包括仪表板展示、告警系统或复杂的算法分析。
-
数据可视化和报告(Visualization and Reporting):
- 将分析结果以图表、仪表板等形式呈现给最终用户,便于理解和决策。
其他
-
集成与编排(Integration and Orchestration):
- 确保流式架构与其他系统(如批处理系统、微服务架构等)的集成和协调工作。
-
监控与运维(Monitoring and Operations):
- 监控流式系统的健康状况和性能指标,提供预警机制,并支持系统的日常运维。
由图可以看出,在数据采集和数据服务部分,实时和离线是公用的。因为在这两层中都不需要关心数据的时效性。这样才能够做到数据源的统一,避免流式处理和离线处理的不一致。
- 监控流式系统的健康状况和性能指标,提供预警机制,并支持系统的日常运维。
2.2 数据采集
2.2.1 数据采集种类
-
数据库变更日志,比如MySQL的binlog日志、HBase的hlog日志、OceanBase的变更日志、Oracle的变更日志等。
-
引擎访问日志,比如用户访问网站产生的Apache引擎日志、搜索引擎的接口查询日志等。
2.2.2 数据采集原则(满足其一即可)
-
数据大小限制:当达到限制条件时,把目前采集到的新数据作为一批(例如512KB写一批)。
-
时间阈值限制:当时间达到一定条件时,也会把目前采集到的新数据作为一批,避免在数据量少的情况下一直不采集(例如30秒写一批)。
2.2.3 数据中间件的使用、和消息系统的对比
对于采集到的数据需要一个数据交换平台分发给下游,这个平台就是数据中间件。数据中间件系统有很多实现方式,比如开源的系统有Kafka,而阿里巴巴集团内部用得比较多的是TimeTunnel(原理和Kafka类似),还有MetaQ、Notify等消息系统。
- 消息系统:这是一个用于在不同组件之间传递信息的平台。它通常使用队列或发布/订阅模式来处理和路由消息。消息系统可以提供异步通信、解耦和可扩展性。
- 数据中间件:这是位于应用程序和服务之间的软件层,用于管理和优化数据传输。数据中间件可以帮助解决与分布式系统相关的挑战,如性能、可靠性和安全性。
如下图,时效性和吞吐量是数据处理中的两个矛盾体,很多时候需要从业务的角度来权衡使用什么样的系统来做数据中转。
2.3 数据处理原理(以Storm为例)
点击跳转Storm官网
Apache Storm 是一个免费且开源的分布式实时计算系统。Apache Storm 让你能够轻松地处理无限的数据流,它为实时处理所做的是类似于 Hadoop 对于批量处理所做的。Apache Storm 简单易用,可以与任何编程语言配合使用,并且非常有趣!
Apache Storm 有许多用途:实时分析、在线机器学习、持续计算、分布式远程过程调用(RPC)、提取、转换、加载(ETL)等。Apache Storm 的速度非常快:一项基准测试显示它能够以每秒每节点处理超过一百万条元组的速度运行。它具有可扩展性,容错性,保证你的数据会被处理,并且易于设置和运行。
Apache Storm 与你已经使用的队列和数据库技术集成。Apache Storm 的拓扑结构会消费数据流,并以任意复杂的方式处理这些流,根据需要在计算的每个阶段重新分区流。更多细节可以在教程中阅读。
简而言之,Apache Storm 是一个实时流处理框架,它能够处理大量数据流,提供高性能、可扩展性以及数据处理的可靠性。
这是一个有向无环图,学过图论的旁友应该知道
-
spout:拓扑的输入,从数据中间件中读取数据,并且根据自定义的分发规则发送给下游的 bolt,可以有多个输入源。
-
bolt:业务处理单元,可以根据处理逻辑分为多个步骤,其相互之间的数据分发规则也是自定义的。
2.4 数据处理特点
- 出于性能考虑,计算任务多线程
- 分桶处理,数据存在内存中,提高应用吞吐量
- 避免内存溢出,需及时清理,方法:LRU(最近最少使用)和业务时间集合归类清理,比如业务时间是T-1的,那么就会在今天凌晨时进行清理)
LRU(Least Recently Used,最近最少使用)算法是一种缓存淘汰策略,用于在缓存空间有限的情况下决定哪些数据应该被清除以腾出空间。它的核心思想是:如果数据最近被访问过,那么将来被访问的几率也较高;反之,长期未被访问的数据在未来被访问的可能性较小。因此,当缓存满了需要释放空间时,LRU算法会选择最长时间未被访问的数据项进行淘汰。
LRU算法特点:
- 时间局部性:假设数据的访问存在时间上的局部性,即最近访问过的数据很可能在不久的将来再次被访问。
- 简单高效:实现相对简单,可以通过双向链表和哈希表结合的方式来实现高效的插入和查找。
业务时间集合归类清理:
业务时间集合归类清理是一种基于时间维度对数据进行管理和清理的方法。这种方法通常用于处理那些具有生命周期或有效期的数据。例如,日志数据可能仅在一定天数内需要保存,之后就可以清理;用户行为数据可能仅保留最近几个月的记录等。
清理策略:
- 时间窗口:设定一个时间窗口,超过这个窗口的数据将被视为不再需要并被清理。
- 定期检查:定期(如每天、每周)检查数据集,删除超出规定时间范围的数据。
- 自动删除:当数据到达其预定的生命周期结束时,自动触发删除操作。
LRU与业务时间集合归类清理的区别:
- 目的不同:LRU主要关注的是缓存空间的高效利用,而业务时间集合归类清理更多是基于业务逻辑和数据生命周期管理。
- 应用场景不同:LRU适用于缓存场景,而业务时间集合归类清理适用于长期数据存储和管理。
- 触发机制不同:LRU在缓存空间不足时触发,业务时间集合归类清理通常基于时间周期或数据生命周期触发。
结合使用:
在实际应用中,LRU和业务时间集合归类清理策略可以结合使用。例如,对于一个包含大量数据的缓存系统,可以使用LRU算法来管理活跃的数据,同时设定一个时间窗口来定期清理那些已经过期或不再活跃的数据,从而保持缓存的高效和相关性。
2.5 数据处理典型问题1 去重指标
在实时数据处理中,去重指标通常是指在数据流中去除重复的记录,以确保分析和统计的准确性和效率。例如,如果在一段时间内多次接收到同一个用户的登录事件,可能只需要计算一次以反映唯一登录次数。去重可以基于时间窗口、键值或数据特征来进行。
当去重的明细数据达到十几亿,内存中放不下了,怎么办?
- 这些明细数据必须要保存,即
精确去重
,考虑使用数据倾斜处理,把一个节点的内存压力分到多个节点上去,文章后面会讲到 模糊去重
,业务精度要求不高,数据量又非常大,可以使用相关去重算法,把内存使用量降到千分之一或万分之一,提高内存利用率。关于去重方法,书中只是简单介绍了两种,分别是布隆过滤器和基数估计。感兴趣的旁友可以自己上网了解算法实现的细节问题。
布隆过滤器(Bloom Filter)和基数估计(Cardinality Estimation)是两种不同的数据结构或算法,它们各自解决不同的问题,但都在大数据处理和实时计算中扮演着重要角色。
布隆过滤器(Bloom Filter)
布隆过滤器是一种空间效率极高的概率型数据结构,用于测试一个元素是否在一个集合中。它由以下部分组成:
- 一个比特数组(bit array)
- 多个独立的散列函数(hash functions)
工作原理:
- 当一个元素加入到布隆过滤器时,通过多个散列函数将其映射到比特数组的不同位置,并将这些位置的比特置为1。
- 查询一个元素是否存在时,同样通过散列函数确定比特数组的位置,如果所有对应的比特位都是1,则认为该元素可能存在于集合中。但这种判断可能存在误报(false positive),即一个实际上不存在的元素也可能被标记为存在。
特点:
- 非常节省空间,因为不需要存储元素本身。
- 查询速度快,只需通过散列函数访问比特数组即可。
- 无法从布隆过滤器中删除元素,因为删除可能会干扰其他元素的判断。
- 存在误报率,但可以通过调整比特数组的大小和散列函数的数量来控制误报率。
基数估计(Cardinality Estimation)
基数估计是用来估算一个集合中不同元素的数量,即集合的基数。在处理大规模数据集时,精确计数可能非常耗资源,基数估计算法可以在牺牲一些精度的情况下大大减少所需的计算和存储资源。
常见的基数估计算法包括:
- HyperLogLog:一种高效的算法,通过跟踪流中出现的不同的低阶位模式来估计基数。
- Flajolet-Martin算法:基于哈希函数和二进制表示的特性,也是HyperLogLog的基础之一。
特点:
- 能够处理非常大的数据集,使用相对较少的内存。
- 估计结果不是精确的,但可以通过调整参数来优化精度和资源消耗之间的平衡。
- 可以用于实时数据分析,如网站流量统计、网络监控等场景。
在实时计算框架如Apache Storm中,布隆过滤器和基数估计算法可以用于各种场景,比如过滤重复数据、实时统计唯一用户数等。这些工具对于优化内存使用、提高处理速度以及在大数据环境中进行有效的数据分析至关重要。
2.6 数据处理典型问题2 数据倾斜
数据倾斜是指在数据处理中,数据的分布不均匀,导致某些处理节点或任务处理的数据量远远超过其他节点或任务。这会导致资源利用率不均衡,某些节点可能过载,而其他节点则处于空闲状态,影响整体处理速度和效率。节点就是前面有向无环拓扑图中的bolt。
解决方案
- 重新分区:重新分配数据,使得数据更均匀地分布在处理节点上。
- 智能分发:使用更复杂的分发策略,例如基于数据频率的分发。
- 增加并行度:为热点数据增加额外的处理实例,以分散负载。
书中提到的方法是分桶处理。分桶处理和离线处理的思路是一样的。
- 去重指标分桶
通过对去重值进行分桶 Hash,相同的值一定会被放在同一个桶中去重,最后再把每个桶里面的值进行加和就得到总值,这里利用了每个桶的 CPU 和内存资源。 - 非去重指标分桶
数据随机分发到每个桶中,最后再把每个桶的值汇总,主要利用的是各个桶的 CPU 能力。
2.7 数据处理典型问题3 事务处理
由于实时计算是分布式处理的,系统的不稳定性必然会导致数据的处理有可能会出现失败的情况。比如网络的抖动导致数据发送不成功、机器重启导致数据丢失等。在这些情况下,怎么做到数据的精确处理呢?上面提到的几个流计算系统几乎都提供了数据自动ACK、失败重发
以及事物信息
等机制。
数据自动ACK,这个概念主要出现在网络通信和数据传输领域。“ACK"是英文"acknowledge"的缩写,意为“确认”,在计算机网络中,它通常用于表示接收方已经成功接收到发送方的数据。
在数据传输过程中,当接收方接收到数据后,会向发送方发送一个ACK信号,告诉发送方数据已经被正确接收。这种机制被称为"确认应答机制”,它是TCP协议(Transmission Control Protocol,传输控制协议)的重要组成部分,能够保证数据在网络中的可靠传输。
而"数据自动ACK"则是指系统或设备在接收到数据后,无需人工干预,自动发出ACK信号的过程。这种方式可以大大提高数据传输的效率,减少人为错误的可能性。例如,在一些物联网设备或者无线传感器网络中,为了节省能源和提高效率,常常采用数据自动ACK的方式进行数据传输。
-
超时时间:由于数据处理是按照批次来进行的,当一批数据处理超时时,会从拓扑的 spout 端重发数据。另外,批次处理的数据量不宜过大,应该增加一个限流的功能(限定一批数据的记录数或者容量等),避免数据处理超时。
-
事务信息:每批数据都会附带一个事务 ID 的信息,在重发的情况下,让开发者自己根据事务信息去判断数据第一次到达和重发时不同的处理逻辑。
-
备份机制:开发人员需要保证内存数据可以通过外部存储恢复,因此在计算中用到的中间结果数据需要备份到外部存储。
今天的分享到这里就结束啦,点赞关注收藏,获取更多干货知识~