转载

数据架构的未来——浅谈流处理架构

数据架构设计领域正在发生一场变革，其影响的不仅是实时处理业务，这场变革可能将基于流的处理视为整个架构设计的核心，而不是将流处理只是作为某一个实时计算的项目使用。本文将对比传统数据架构与流处理架构的区别，并将介绍如何将流处理架构应用于微服务及整体系统中。

传统数据架构

传统数据架构是一种中心化的数据系统，可能会分为业务数据系统和大数据系统。

数据架构的未来——浅谈流处理架构

业务数据系统存储事务性数据，比如SQL， NOSQL数据库，这种数据拥有准确的数据，比如用户业务，支付业务等体系都可以这样实现，这类需要经常更新，是整体业务系统支撑的核心。

大数据系统主要负责存储不需要经常更新的数据，由于数据量过大，可能需要Hadoop等大数据框架进行实现，系统会定时的计算结果，比如在每天零点统计用户访问量，可能将结果结果写入SQL数据库，完成统计工作。

而实时数据系统往往只作为一个某一个项目使用，比如实时日志报警系统，实时推荐系统。

数据架构的未来——浅谈流处理架构

这样设计的原因是因为数据处理性能和准确性的限制，在 Streaming-大数据的未来一文中曾提到过，由于对事件时间的不可控，我们不能将实时数据作为准确可靠的数据来源。而低延迟的要求将极大的占用系统性能。

这种传统架构成功地服务了几十年，但随着大型分布式系统中的计算复杂度不断上升，这种架构已经不堪重负。许多公司经常遇到以下问题。

• 在许多项目中，从数据到达到数据分析所需的工作流程太复杂、太缓慢。

• 传统的数据架构太单一：数据库是唯一正确的数据源，每一个应用程序都需要通过访问数据库来获得所需的数据。

• 采用这种架构的系统拥有非常复杂的异常问题处理方法。当出现异常问题时，很难保证系统还能很好地运行。

而且随着系统规模扩大，维持实际数据与状态数据间的一致性变得越来越困难，需要不断更新维护全局状态。

流处理架构

作为一种新的选择，流处理架构解决了企业在大规模系统中遇到的诸多问题。以流为基础的架构设计让数据记录持续地从数据源流向应用程序，并在各个应用程序间持续流动。没有一个数据库来集中存储全局状态数据，取而代之的是共享且永不停止的流数据，它是唯一正确的数据源，记录了业务数据的历史。在流处理架构中，每个应用程序都有自己的数据，这些数据采用本地数据库或分布式文件进行存储。

这种思路在之前是不可能办到的，它要求我们对消息有重复消费的能力，还要保持消息系统的高性能，同时还必须对事件时间做出精确的处理，但是现在我们有了Kafka与Flink，一切都变得简单了。

数据架构的未来——浅谈流处理架构

流处理项目架构主要是两部分：消息传输层，流处理层。数据来源是连续的消息流，比如日志，点击流事件，物联网数据。输出为各种可能的数据流向。

消息传输层从各种数据源（生产者）采集连续事件产生的数据，并传输给订阅了这些数据的应用程序和服务（消费者）。这种设计使得生产者与消费者解耦，topic的概念，多个源接收数据，给多个消费者使用，消费者不需要立刻处理消息也不需要一直处于启动状态。消息传输层需要同时具备高性能，持久性，相当于缓冲区，可以将事件数据短期保存起来。而Kafka可以让高性能和持久性兼得。Offset机制实现了消息持久性，消息可以重播再计算；而基于磁盘缓存的读写可以做到高吞吐。

数据架构的未来——浅谈流处理架构