Lamda ————> Kappa —————> 流计算 + 交互式分析双擎架构
架构的演进本质上都是在往批流一体这个方向发展。让用户能够以最自然、成本最小的方式完成实时计算。其次,全链路的实时化和 SQL 化是一个非常明确的趋势。一方面,越来越多的业务需要实时(这个实时很多时候指的是分钟级的延迟和可接受的实现代价),另一方面,能用 SQL(最好是标准 SQL)表达所有环节的计算也是很明显的趋势。
生产系统中,一般实时链路包含了 Kafka,Storm/Flink,Redis/HBase/MySQL 等组件。其中,每个组件实例一般只做一件事情,比方说 Redis 用来做实时 ETL 的查表,Storm/Flink/Spark Streaming 用来做实时计算,Redis/HBase/MySQL 用来做实时计算的结果存储等等。因为链路比较长,所以有大量专门的同步任务将数据在不同的系统之间同步。
在流处理器出现之前,数据处理架构主要由批处理器组成,其是对 无限数据的有限切分,具有 吞吐量大、数据较为准确 的特点。
然而我们知道,批处理器在时间切分点附近 仍然无法保证数据结果的真实性,且数据的时效性往往比较低,延迟大。
除了批处理之外,人们为了达到数据生成的高时效性,在数据处理架构中也常常使用微服务来解决,其特点是 延迟低、无状态、服务与存储分离。例如:data-connector。
但是微服务无状态的约束很大程度上决定了其并不能很好的应用于现代实时数据处理的需求中,比如准确一次的语义、乱序数据流的处理能力等,它无法满足人们对一个先进的流处理器的想象(在无状态的业务需求中,微服务仍然是最佳选择)。
而要满足人们的这些想象,数据处理架构恰恰需要有 「状态」 的概念和相应的机制支持才行。
由此 有状态的流处理器 开始逐渐完善并大规模使用。
有状态的流处理器依赖 高可用可重放的数据源,通过 State(状态)提供准确一次的语义,通过 时间推理工具能够还原真实世界的数据情况,广泛应用于 事件驱动(实时警报)、数据管道(实时数仓)、数据分析(实时报表) 等业务场景中。
高可用可重放的数据源:
开源流处理器在不断地发展,从一开始只关注低延迟指标到现在兼顾延迟、吞吐与结果准确性,在发展过程中解决了很多问题,编程API的易用性也在不断地提高。
Lambda架构向Kappa架构的演进。
Spring微服务接Kafka等消息中间件处理MySQL binlog数据。缺点非常明显:复杂数据处理是瓶颈!
Storm
Flink
内容来源于网络,如有侵权,请联系作者删除!