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

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

传统数据架构

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

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

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

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

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

这种传统架构成功地服务了几十年，但随着大型分布式系统中的计算复杂 度不断上升，这种架构已经不堪重负。许多公司经常遇到以下问题。 • 在许多项目中，从数据到达到数据分析所需的工作流程太复杂、太缓慢。

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

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

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

流处理架构

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

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

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

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

流处理层有 3 个用途：①持续地将数据在应用程序和系统间移动；②聚合并处理事件；③在本地维持应用程序的状态

Flink兼顾了这些优势，Apache Flink是一个框架和分布式处理引擎，用于在无边界和有边界数据流上进行有状态的计算。Flink 能在所有常见集群环境中运行，并能以内存速度和任意规模进行计算。

将流处理架构应用于微服务与整体系统

应用于微服务

从上文可以知道，流处理架构的消息是从Kafka中流出的流数据。Flink从消息队列中订阅数据并加以处理。处理后的数据可以流向另一个消息队列。这样所有的应用都可以共享流数据。

基于流处理的微服务架构也为欺诈检测系统的开发人员带来了灵活性。新增加一个数据消费者的开销几乎可以忽略不计，同时只要合适，数据的历史信息可以保存成任何一种格式，并且使用任意的数据库服务。消息就在反复使用，处理，持久化中发挥了其最大最高效的作用。

应用于整体系统

事实上，流处理架构的作用远不止于此，流数据消费者并不仅限于实时应用程序，尽管它们是很重要的一种。

图中展示了从流处理架构中获益的几类消费者。A 组消费者可能做各种实时分析，包括实时更新仪表盘。B 组消费者记录数据的当前状态，这些数据可能同时也被存储在数据库或搜索文件中。

比如在电力监控系统中，我们需要实时的对电力故障报警，也需要实时监控电流电压数据，也需要持久化数据做历史分析预测等等。