一、传统数据处理架构
传统数据处理架构-事务处理
Compute:计算层
Storage:存储层
CRM(customer relation managament): 客户关系管理系统
Order System : 订单系统
Contact Events:连接请求事件
Order Events:订单事件
Click Events：点击事件
Response:响应
Transactional DBMS:事务数据库管理系统
- 传统事务型数据处理过程：系统收到请求之后，可能需要跟存储层数据做交互（关联join等），经过计算之后返回Response结果，并将结果存储在存储层（数据库）。
- 传统事务型数据处理会有的问题：当客户端发送的请求数据过大的时候，跟存储层数据进行联表查询时，会造成服务器处理不过来。（思考：可以做负载均衡、分布式计算、增加资源来解决当下问题，但是代价过高）
二、数据分析处理架构
将数据从业务数据库复制到数仓，再进行分析和查询。
分析处理架构
Transactional DBMS:事务数据库管理系统
ETL Process:抽取、转换、加载处理过程
Data Warehouse:数仓
Reports:报表
Ad-Hoc Queries:即席查询
- 分析处理架构过程：从不同的业务传统数据库将数据进行ETL，统一加载到数仓里面，通过分析计算出报表或者做即席查询。（即：离线处理过程）
- 问题：大数据量和高并发都可以做到，但是延迟性特别高，所以如何实现既能处理大数据量、高并发、延迟低成了我们的最终目标。下面提出了有状态的流式数据计算架构。
三、流式数据计算架构（第一代流式计算架构）
有状态的流式计算
Application Logic:应用程序逻辑
Local State:本地状态
Periodic Checkpoint:周期型检查点
Remote Storage:远程存储（HDFS存储）
- 提出问题：来一条数据处理一条，但是规模上不去，主要瓶颈是关系型数据库做联表查询很麻烦。所以提出有状态的计算架构。
- 有状态的计算：将数据放到本地内存中，将其存储为一个本地状态，当来了一条数据，通过应用程序的逻辑计算后，去判断本地的状态，计算完成后将计算结果sink出去，并更新本地状态。整个过程中，使用一个本地状态代替了传统数据处理架构和分析型数据处理架构中的表数据。
- 有状态计算如何实现高并发：通过实现集群，每个不同的节点是实现自己的本地状态去处理数据，最终再做汇总。
- 数据的整个处理流程：数据流 -> 处理逻辑 -> 本地状态判断 -> 周期性检查点 -> 落盘
- 提出问题：如果节点挂了，该怎么办？设置周期型的检查点，针对状态，周期型地去保存到一个远程的持久化存储空间。
- 提出问题：分布式架构处理中，会出现一个严重的问题，即：数据的顺序性无法保证。提出了一下的架构转变，Lambda架构、。
四、Lamda架构
使用两套系统，同时保证低延迟和结果准确。
lamda架构
Event Log:事件日志
Batch Layer:批处理层
Event Importer:事件加载
Batch Storage:批处理存储
Batch Processor:批处理器
Speed Layer:流处理层
Stream Processor:流处理器
Serving Layer:服务层
Batch Table:批处理表
Speed Table:流处理表
Query and merge results:查询或者合并结果
Application:应用
流处理层保证低延迟，批处理保证准确性，最后再服务层由用户指定查询或者合并流处理和批处理的表。
- 存在的问题：批处理和流处理一致难以保证，需要付出较大的代价，flink就可以做到批处理和流处理，并能保证高吞吐，低延迟，正确性。
网友评论