本文是 RisingWave 产品战略与发展系列的第二篇文章。在这篇文章中,我们将解释为什么统一的数据处理框架是大势所趋,以及 RisingWave 以流处理为核心的策略如何更好地实现这一愿景。
如果想要了解《为什么 RisingWave 是流处理工作负载的最佳选择》,请直接跳转参阅。
1为什么需要统一的数据处理框架?
随着 RisingWave 2.0 GA 版本发布,我们希望借此机会回顾一下数据管理的整体格局。流处理已经从一种趋势演变为创新型数据驱动企业的关键需求。传统上,批处理和流处理工作负载被分别对待,需要独立的数据基础架构。但目前,领先的数据平台供应商现在认识到将批处理和流处理融合的重要性。
随着商业挑战的升级,批处理和流处理之间的界限逐渐模糊,为统一的数据处理框架铺平了道路。
传统的批处理系统试图通过微批处理来处理流式工作负载,这本质上是传统批处理的更快版本。但是,在每次新数据到来时处理整个表格是低效且昂贵的,尤其是在使用场景变得更复杂和多样化的情况下,获取结果会更慢,成本也更高。
相比之下,流处理系统通过处理增量变化的方式提供了更高的效率和性能。用户能够编写查询,组合或分层处理衍生和中间数据,确保结果实时更新。
根据数据的延迟需求组织工作负载,而不是仅关注查询性能。这种模型优先考虑数据延迟需求,使数据处理方法与数据的特定需求对齐。
让我们仔细思考数据延迟和查询延迟的概念。
数据延迟:是指数据生成到其可供处理和分析时的时间差。该延迟通常受网络速度和数据摄取费用等因素的影响。 查询延迟:是指查询提交到数据处理系统到结果返回时的延迟。这种延迟主要受查询复杂性、数据量、存储类型和查询引擎的性能影响。
“实时”这个术语在数据行业中被频繁使用,几乎没有厂商公开宣称他们的平台不是“实时”的。然而,了解清楚背后的关键技术和功能差异就能轻松看穿他们的营销噱头。
对于像 RisingWave 这样的流数据库,“实时”指系统能几乎瞬时地处理和分析大量高速数据,从中生成见解。相比之下,传统批处理系统的“实时”指查询结果的实时交付,侧重于批量处理大量历史数据。虽然批处理系统在识别过往趋势和模式方面十分有效,但无法很好地支持实时决策以及将分析应用到下游程序。
当下,现代企业不再满足于历史数据见解或当前事件的简要概览。他们需要融合实时数据与历史信息的高级分析,以提供更深层次且可具备操作性的见解。RisingWave 2.0 标志着我们在不断满足用户使用场景需求道路上迈出重大一步。
2新一代统一数据处理框架
传统基于批处理的数据系统无法有效应对具有不同数据延迟需求的工作负载。这些系统缺乏对 Data sources 和 Data sinks 的原生流连接,通常依赖于脆弱的 ETL 流程和复杂的数据管道。因此,用户必须通过中间数据集来维护数据一致性,这大大增加了数据延迟并带来巨大的运营成本。
RisingWave 通过以流处理为核心的方式,解决了数据延迟和查询延迟问题,确保在广泛的用例中提供最佳性能。接下来,让我们看看 RisingWave 为什么能为批处理和流处理工作负载提供统一的解决方案。
丰富的连接性
RisingWave 为主流的 Data sources 都提供了原生连接器和适配器,包括各种数据库、消息队列、数据湖、API 和物联网设备。这对于及时的数据处理至关重要,因为它既需要处理实时流数据,又要批量加载大规模数据。我们专为流处理设计的连接器具有内置的反压检测功能,可以高效地从众多分散的来源中摄取数据。这种能力不仅允许摄取最新的数据,还支持按需重新处理较早的数据集。
SQL 中的统一数据模型
统一的数据处理框架需要一个通用的数据模型和标准语言,以减少工作负载之间切换的复杂性,并提高开发人员的生产力。共享的数据模型还简化了对多样化数据特征管理的内在复杂性。RisingWave 采用标准的关系型数据模型,支持使用标准 SQL 创建复杂的数据管道。这样,SQL 查询编写者可以将数据表作为构建模块,从而实现复杂的使用场景,并支持异步开发的管道。即使是最复杂的数据管道也可以通过级联的物化视图构建。
可组合的数据管道
现代数据应用通常需要多阶段的管道,并且能灵活地将业务逻辑注入到事件数据中。第一代流处理系统在这方面不尽人意,尤其对于普通数据工程师而言。这限制了他们的使用并阻碍了其从批处理到动态实时系统的过渡。RisingWave 通过提供可组合的数据管道解决了这一问题,使由一个查询生成的表和视图可以无缝用作下游查询的输入。这样的可组合性确保了软件可以根据新需求进行调整,而无需大规模重写,方便了新解决方案的集成。
内置服务层
在现代应用程序中,成千上万的用户通常通过数据驱动的应用获取实时洞察,例如叫车平台或金融交易终端。为了管理大量的快速读取,见解必须从高速服务层(通常是内存数据存储或操作数据库)中传递。这可能因为额外的数据传输而导致更高的延迟和复杂性。RisingWave 通过消除独立服务存储的需求解决了这一问题。它的内存优先架构确保了数据在流处理任务完成后立刻可用。RisingWave 还支持分离计算,配有专用于即时查询的服务节点,确保高效的数据访问。
实时数据的连续处理
实时数据的价值往往具有时效性。传统上,物化视图用于通过缓存结果来加速查询。而在 RisingWave 中,物化视图被持续更新,以确保结果始终是最新的。增量更新会自动触发,也就无需在数据实时处理的速度和时效性之间进行取舍。此外,RisingWave 能管理数据的整个生命周期,包括保留、归档和清理,以保持高性能并有效管理存储成本。
数据的时效性
数据的时效性是批处理和流处理工作负载之间的一个关键区别。在流处理系统中,时效性指的是在时间窗口内连续处理实时数据的能力。而对于批处理来说,重点则在于历史数据,通常由 Time travel 和 ASOF joins 等功能支持。RisingWave 提供了全面的功能集确保在这两种工作负载中都能具备强大的数据时效性。它支持各种时间窗口策略,如 tumbling、sliding 和 session windows,以及用于有效处理无限数据流的 watermarks 和 temporal filters。
与其他系统的互操作性
一个支持统一数据处理模型的系统应该优先考虑通用标准而非定制解决方案。这意味着要拥抱广泛采用的文件和存储格式。互操作性是 RisingWave 的核心设计原则之一。随着 Iceberg 和 Delta 逐渐成为数据湖仓表格格式的实际标准,RisingWave 提供了对两者的强大读写支持。除了连接批处理和流处理范式,RisingWave 还通过通用的 UDF 框架统一了 Python、SQL、Java 和 JavaScript 的开发和使用模式。这使得开发人员能够轻松将自定义业务逻辑嵌入到数据管道中,从而实现更复杂的数据处理、高级分析和机器学习推理。
3结论
RisingWave 从诞生之初就是一个流处理系统。我们在 RisingWave 1.0 开发过程中做出的设计选择,为处理实时数据工作负载奠定了坚实的基础。通过 RisingWave 2.0,我们在这一基础上继续发展,引入新的功能,以推进我们实现统一数据处理框架的愿景。在结束本文之前,有必要指出,统一数据处理框架的目标值得称赞,尽管它可能看起来过于雄心勃勃。但我们相信,“统一”不一定意味着一个平台能够全面应对所有类型的工作负载。相反,RisingWave 凭借以流处理为核心的设计,专注于为现代数据需求提供高效而灵活的解决方案,从而独具优势。
关于 RisingWave
往期推荐
技术内幕