本文主要是介绍实时数据处理革命：从传统数据栈到新一代流处理解决方案，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
“数据像鱼一样，越放越臭，不像酒，越陈越香。”
上述观点可能显得有些尖锐，但也有其道理所在。随着企业努力利用数据来实现新的商业模式，现有的数据栈明显无法继续满足需求，因为传统数据栈设计之初并未考虑到如今企业对于“超低延迟”的要求。
在深入探讨新应用不断涌现的需求之前，让我们回顾大约十年前的数据和分析领域的主要趋势，毫无疑问是“大数据”运动。思想领袖们用三个 V 来定义“大数据”：体量（Volume）、速度（Velocity）和多样性（Variety）。
简而言之，“大数据”指的是来自新来源的大量且复杂的数据集。这些数据集对于传统软件来说过于庞大，但可以用来解决以前无法解决的业务问题。
企业有巨大的潜力从海量数据中提取有意义的信息。然而，由于缺乏处理如此庞大数据集的工具，这一潜力尚未被充分发挥。大家引入 Hadoop 这类技术期望能够释放这一潜力，但这些大数据技术主要关注解决体量方面的问题，大多数用户没有看到其必要性或价值，所以没有被广泛使用。
为什么会这样呢？
原因有很多，但主要原因是数据的有限保质期。数据从业者面临实时访问数据的挑战，准确地说是在数据的内在价值还很高时实时访问数据的挑战。简单地将原始数据存储在数据湖中类似于数据倾倒，而不是利用数据。
另一个重要原因是即便数据可访问，其原始形式通常也不足以进行有效分析。要从数据中提取有价值的信息，复杂的提取-转换-加载（ETL）过程变得必要。数据依然被隔离在独立系统中，并与特定应用紧密相连。数据源的集成最近才通过消息队列和 CDC 连接器得以改善。
1. 数据特征的演变
传统数据从业者都会关注以下特征：
数据库管理系统用 ACID （Atomicity, Consistency, Isolation, Durability）原则支持这些特征。
- 原子性（Atomicity）：通过全有或全无的语义确保完整性。
- 一致性（Consistency）：通过约束确保数据准确性。
- 隔离性（Isolation）：为数据完整性和准确性提供保证。
- 持久性（Durability）：基于不可变写入确保数据的可靠性。
ACID 原则在满足各种业务需求方面是有效的。当前的数据处理系统确保在任何数据栈中对这些特征的强大支持，所以企业能够处理依赖于静态数据快照的工作量。虽然业内已经通过各种优化来提升处理工作的速度和实时能力，但这些改进仍不能满足需要。
数据圈内，越来越多的人达成共识，认为应将数据视为连续无限的流，而不是快照。企业不再满足于了解过去发生了什么，他们更加关注预测未来结果，这需要对数据进行“实时”分析。在这种情况下，“实时”是由数据延迟定义的，而不是查询延迟。为了更好地理解，我们需要为数据的定义建立一套新的特征。
为了解决这些特征，新的数据处理范式是必要的。这个范式将：
- 处理离散事件数据。
- 连续处理实时数据。
- 集成多个数据流进行状态处理。
2. 早期流处理解决方案
要支持上一节讨论的新的数据处理范式，新的数据处理栈是必要的。这个数据栈应具备以下特征：
- 事件数据语义以保持事件数据的一致性。
- 增量计算模型以对实时数据进行连续更新。
- 熟悉的关系数据模型，将流视为表，以实现各种数据源的无缝集成。
第一代流处理系统：流处理系统已经在满足这些需求方面努力了一段时间。第一代流处理系统，如 Spark Streaming、Apache Heron 和早期版本的 Flink，在某些方面证明了其价值。例如，它们在微批处理方面表现出色，适合特定的使用场景。Spark Streaming 对于希望将流处理纳入现有工作负载的 Spark 用户来说，是一个有价值的补充。总体而言，这些系统继承了成熟的批处理模型的许多优点。
然而，它们也从传统批处理模型中继承了调度和协调问题。它们不支持真正的事件时间语义，这对于在事件驱动架构中构建应用至关重要。此外，这些技术仅关注数据处理方面。缺乏数据存储意味着需要一个单独的数据存储来实现持久化，从而导致应用性能下降和运营开销增加。此外，这些系统主要为早期采用者设计，他们习惯于使用低级 API 和接口。因此，这些技术在快速轻松构建实时应用方面没有显著进展。
3. 新一代流处理解决方案
为了使流处理更加广泛地被采用，必须将 SQL 作为标准 API。此外，新系统应包括内置存储层以有效处理数据检索。
流式数据库的出现：其旨在结合流处理引擎的增量处理能力与传统数据库的基于 SQL 的分析和持久化能力。新一代流式数据库的出现可以改善依赖于独立平台进行流处理和批处理所带来的操作低效问题。流式数据库，如 RisingWave 和 Materialize，旨在使用 SQL 查询和实时物化视图连续处理事件数据流。它们还会持久化历史事件数据以供进一步分析。
与将数据存储在外部数据库中的流计算引擎不同，流式数据库设计之初就考虑到了提供内置处理和持久化能力。这意味着单一的流式数据库就可以作为 Apache Flink + Apache Cassandra 等工具组合的可行替代方案。这样做简化了部署、配置、集成和管理。通过流式数据库，数据库功能向上游转移，实现数据到达时的实时处理，并促进数据的即时服务。
4. 展望未来
通过结合早期流处理引擎和传统数据库系统的优势，我们正在降低流处理的门槛，让更广泛的用户群体受益。这种融合的影响是深远的，企业可以利用实时数据分析做出明智的决策，预测结果，并获得竞争优势。连续的实时数据处理和多数据流的集成支持各种应用场景，包括欺诈检测、实时个性化、供应链优化和物联网分析。此外，流处理的大众化使数据工程师、数据科学家和数据分析师能够在无需大量专业技术知识储备的情况下开发实时应用。
5. 关于 RisingWave
RisingWave 是一款开源的分布式流处理数据库，旨在帮助用户降低实时应用的开发成本。RisingWave 采用存算分离架构，提供 Postgres-style 使用体验，具备比 Flink 高出 10 倍的性能以及更低的成本。
👨🔬加入 RW 社区，欢迎关注公众号：RisingWave 中文开源社区
🧑💻快速上手 RisingWave，欢迎体验入门教程：github.com/risingwave
💻深入使用 RisingWave，欢迎阅读用户文档：zh-cn.risingwave.com/docs
🔍更多常见问题及答案，欢迎搜索留言: risingwavelabs/discussions
这篇关于实时数据处理革命：从传统数据栈到新一代流处理解决方案的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
