目录

架构历程

我们从两个维度纵观数据架构的演变：一个是数据集的使用方式，另一个是这种使用方式的使用范围-即（所说的大数据框架，Hadoop，storm，spark等）主要针对企业内部进行数据挖掘和分析

1.传统数据基础架构

1.1单体应用数据架构

单一的RDMS（MySQL，Oracle）作为数据库对外部所有应用提供服务（包括企业外部的业务应用及内部进行数据挖掘和分析的应用）

单体数据库如下图

单体数据库

1.2微服务应用数据架构

主要理解数仓的概念

1）每个服务有各自的DB，各自DB支撑各自的业务逻辑

2）为了满足企业内部的数据挖掘和分析要求，且鉴于微服务各自DB（主要是业务数据）分散不集中的情况：

a. 抽象出数据仓库的概念，数仓周期性从不同DB中进行数据抽取、汇总-作为存储角度

b.数仓会进行数据的加工、转换-构建不同的数据集（可以理解成不同格式）

3）微服务数据库架构如下

微服务数据库架构

2.大数据数据架构

2.1背景

1）RDMS规模、数据量、计算处理能力的限制

2.2产品

2.2.1 纯Hadoop时代

说明：

a.存储-HDFS

b.ETL-Hive

c.实时交互查询-Impala

优劣：

a.Hadoop作为大数据平台，其数据需周期从业务系统中同步->一系列ETL转换->形成数据集市，影响时效性

2.2.2 Lambda架构时代(只有storm，但spark, flink未出现的年代）

组成：

a.批量计算-Batch Layer(比如MapReduce),

b.实时计算-Speed Layer（比如Storm）

优劣：

a.平台复杂，运维成本高

Lambda架构如下

lambda大数据架构

2.2.3 Spark时代

思想：

a.分布式内存处理框架

b.将数流切片分成微批的处理模型

c.一套计算框架容纳：批处理+流处理

d.spark本身是批处理模式（局限）

3.有流状态的计算架构

3.1回归本质

1）数据产生的本质是一条条真实存在的事件，我们最期望的是每产生一条数据就可以立刻得到计算结果（想要：数据产生过程中进行计算并直接产生统计结果）

2）前面的方式，都是有一点延迟（数仓存储，ETL转化等）

3.2有状态的流计算架构

a.状态即计算过程中产生的中间计算结果

b.每次计算新的数据都是基于之前的中间状态结果

c.中间状态从常驻内存

d.有状态计算方式最大优势：不需将原始数据从外部存储中取出再计算，也不需将计算结果落入外部仓库

3.3特点

a.时效性

3.4状态计算架构示意图

有状态计算框架

4.为什么是Flink

4.1 三大性能的综合体

大数据库框架考虑3个因素：高性能、高吞吐、低延迟

1.Flink

a.低延迟

b.高性能

c.高吞吐

2.Storm

a.低延迟

b.高性能

3.Spark

a.高性能

b.高吞吐

4.2 支持Event Time

基于窗口的计算（Windows）是大数据实时处理的核心概念

1）一般大数据框架只支持系统时间，即数据到达大数据系统时系统机器的时间

2）FLink支持按Event产生时间构造计算窗口的机制

避免网络耗时、机器状态对时间的影响，保存原数据产生的原生时间，不乱序

4.3 有状态计算

在内存保存中间数据

4.4 支持高度灵活的Windows窗口

基于不同类型窗口（即对数据流进行一定时间范围内的聚合运算）的实时数据统计

1）Time

2）Count

3）Session

4.5 基于轻量级分布式快照（SnapShot）实现容错-对异常问题的处理

1）分布式节点宕机、重启导致的内存状态数据丢失

2）Flink采用SnapShot机制 在执行过程中将采用基于SnapShot的checkpoint机制，将state状态信息持久化存储

4.6 基于JVM实现独立的内存管理

1）基于状态的流式框架处理，状态会耗用大量内存

2）Flink 对状态数据的内存处理采用特殊的二进制序列化方式，降低内存使用率

4.7 save point

1）SnapShot checkpoint解决异常问题时state的持久化

2）save point 解决对于24 hour运行系统出现系统升级、停机运维等主动停止计算时的状态保存

a.我要升级系统了，把原来的数据保存一下吧，"save point: 好的"