大数据框架原理简介

Posted 2021-08-21 平凡人笔记

针对上篇文章遗留问题联邦学习之一

几亿级别的数据量架构如何设计且如何实现

要解决这个问题 那么咱首先要会大数据处理框架的相关内容

这篇文章咱们走进大数据处理的世界

首先咱们要理解大数据相关的概念和原理 才能很好的使用这些组件和设计大数据处理架构

flume sqoop 数据仓库 ETL ODS Data Mart OLTP OLAP 数据集市

咱一一分析原理

flume

sqoop

Hadoop和关系数据库服务器之间传送数据

数据仓库

`数据仓库是供战略决策使用的数据`
`基本不更新的反应历史变化的数据`
`DW:Data Warehouse`
`一个很大的数据存储集合`
`出于企业的分析性报告和决策支持目的而创建`
`对多样的业务数据进行筛选与整合`
`它为企业提供一定的BI（商业智能）能力`
`指导业务流程改进、监视时间、成本、质量以及控制`
`数据仓库的输入方是各种各样的数据源`
`最终的输出用于企业的数据分析、数据挖掘、数据报表等方向`

特点

• 主题性

`不同于传统数据库对应于某一个或多个项目`
`数据仓库根据使用者实际需求`
`将不同数据源的数据在一个较高的抽象层次上做整合`
`所有数据都围绕某一主题来组织`
`比如对于滴滴出行"司机行为分析"就是一个主题`
`对于链家网"成交分析"就是一个主题`

• 集成性

`数据仓库中存储的数据是来源于多个数据源的集成`
`原始数据来自不同的数据源，存储方式各不相同`
`要整合成为最终的数据集合，需要从数据源经过一系列抽取、清洗、转换的过程`

• 稳定性

`数据仓库中保存的数据是一系列历史快照，不允许被修改`
`用户只能通过分析工具进行查询和分析`

• 时变性

`数据仓库会定期接收新的集成数据 反应出最新的数据变化`

ETL

`ETL是将业务系统的数据经过抽取、清洗转换之后加载到数据仓库的过程`
`目的是将企业中的分散、零乱、标准不统一的数据整合到一起` 
`为企业的决策提供分析依据`
`ETL是BI项目重要的一个环节`
`通常情况下，在BI项目中ETL会花掉整个项目至少1/3的时间`
`ETL设计的好坏直接关接到BI项目的成败`

ODS

`短期的实时的数据 供产品或者运营人员日常使用`
`可以更新的数据`
`操作型数据存储`
`存储的是当前的数据情况` 
`给使用者提供当前的状态` 
`提供即时性的、操作性的、集成的全体信息的需求`
`ODS作为数据库到数据仓库的一种过渡形式`
`与数据仓库在物理结构上不同，能提供高性能的响应时间,ODS设计采用混合设计方式`
`ODS中的数据是"实时值",而数据仓库的数据却是"历史值"`
`一般ODS中储存的数据不超过一个月，而数据仓库为10年或更多`

DSS(decision-support system)决策支持系统

`用于支持管理决策的系统`
`通常，DSS对大量的数据单元进行的分析`
`通常不涉及数据更新`

Data Mart

`为了特定的应用目的或应用范围，而从数据仓库中独立出来的一部分数据`
`也可称为部门数据或主题数据（subjectarea）`
`在数据仓库的实施过程中往往可以从一个部门的数据集市着手`
`以后再用几个数据集市组成一个完整的数据仓库`
`需要注意的就是在实施不同的数据集市时，同一含义的字段定义一定要相容，这样再以后实施数据仓库时才不会造成大麻烦`

工作中实际案例分析

数据部门工作流程

• 删除分析数据库的历史订单数据
• 全量更新订单数据到分析数据库
• 将数据简单清洗，并生成数据集市层
• 分析处理，产出报表

问题分析

• 业务变化很快

`业务数据表经常变化字段含义、增加各种逻辑数据等`

• 业务数据源越来越多

`随着品类越来越多，新部门逐步成立，数据源也就越来越多样化`

• 需求越来越多，越来越复杂

`所有的产品和运营都向我们要各种各样的用户行为数据、订单分析数据和竞对优势数据`

• 数据的实时行要求越来越高

`早晨提出个新业务数据需求，晚上就要`

分析数据特点

`此时的数据集合不是数据仓库 因为不符合相对稳定的和反应历史变化的两个条件`
`因为类似订单类数据，每天全量更新`
`（原因是同一个订单状态随着时间会变化，比如今天买了，明天退货了）`
`而是一个ODS`

解决方案

业务数据 － ODS － 数据仓库

优势

• ODS的数据与数据仓库的数据高度统一
• 开发成本低，开发一次并应用到ODS即可
• 可见ODS是发挥承上启下的作用

劣势

• 数据仓库需要的所有数据都需要走ODS
• 扩展、系统的灵活性差

OB-ODS

优势

• 结构简单 初创数据分析团队都是类似的结构

劣势

• 所有数据都归结到ODS
• 长期数据决策分析能力差，软硬件成本高，模块划分不清晰，通用性差

数据仓库和ODS并行

优势

• 便于扩展，ODS和数据仓库各做各的，形成优势互补

ODS和DW区别

数据的当前性

`ODS包括的是当前或接近当前的数据`
`ODS反映的是当前业务条件的状态`
`ODS的设计与用户或业务的需要是有关联的`
`而DW则是更多的反映业务条件的历史数据`

数据的更新或加载

`ODS中的数据是可以进行修改的`
`而DW中的数据一般是不进行更新的`
`ODS的更新是根据业务的需要进行操作的，而没有必要立即更新`
`因此它需要一种实时或近实时的更新机制`
`DW中的数据是按照正常的或预先指定的时间进行数据的收集和加载的`

数据的汇总性

`ODS主要是包括一些细节数据`
`但是由于性能的需要，可能还包括一些汇总数据`
`如果包括汇总数据，可能很难保证数据的当前性和准确性`
`ODS中的汇总数据生命周期比较短，所以可称作为动态汇总数据`
`如果细节数据经过了修改，则汇总数据同样需要修改`
`而DW中的数据可称为静态的汇总数据`

数据建模

`ODS是站在记录层面访问的角度而设计的`
`DW或DM则是站在结果集层面访问的角度而设计的`
`ODS支持快速的数据更新，DW作为一个整体是面向查询的`

查询的事务

`ODS中的事务操作比较多`
`可能一天中会不断的执行相同的事务`
`而DW中事务的到达是可以预测的`

用途

`ODS用于每一天的操作型决策 是一种短期的`
`DW可以获取一种长期的合作广泛的决策`
`ODS是策略型的，DW是战略型的。`

用户

`ODS主要用于策略型的用户 比如保险公司每天与客户交流的客服`
`DW主要用于战略型的用户，比如公司的高层管理人员`

数据量（主要区别之一）

`ODS只是包括当前数据`
`DW存储的是每一个主题的历史快照`

OLTP与OLAP

• 数据处理分类

`联机事务处理OLTP（on-line transaction processing）`
`联机分析处理OLAP（On-Line Analytical Processing）`
`OLTP是传统的关系型数据库的主要应用`
`主要是基本的、日常的事务处理`
`例如银行交易`
`OLAP是数据仓库系统的主要应用`
`支持复杂的分析操作，侧重决策支持`
`并且提供直观易懂的查询结果`
`OLTP 系统强调数据库内存效率`
`强调内存各种指标的命令率，强调绑定变量，强调并发操作`
`OLAP 系统则强调数据分析`
`强调SQL执行市场，强调磁盘I/O，强调分区等`

• OLTP与OLAP之间的比较

OLTP

`事务性非常高的系统`
`一般都是高可用的在线系统`
`以小的事务以及小的查询为主`
`评估其系统的时候，一般看其每秒执行的Transaction以及Execute SQL的数量`
`单个数据库每秒处理的Transaction往往超过几百个，或者是几千个`
`Select 语句的执行量每秒几千甚至几万个`
`典型的OLTP系统有电子商务系统、银行、证券等，如美国eBay的业务数据库`

OLTP 瓶颈

CPU与磁盘子系统

CPU

表现在逻辑读总量与计算性函数

• 逻辑读总量

`逻辑读总量等于单个语句的逻辑读乘以执行次数`
`如果单个语句执行速度虽然很快，但是执行次数非常多，也可能会导致很大的逻辑读总量`

• 计算型的函数

`如自定义函数、decode等的频繁使用`
`也会消耗大量的CPU时间，造成系统的负载升高`
`尽量避免计算过程，如保存计算结果到统计表`

磁盘子系统

`承载能力一般取决于它的IOPS处理能力`
`磁盘物理读一般都是db file sequential read(单块读)`
`读的次数非常频繁`
`如果频繁到磁盘子系统都不能承载其IOPS的时候，就会出现大的性能问题`

OLTP设计和优化

Cache技术与B-tree索引技术

Cache技术

`Cache决定了很多语句不需要从磁盘子系统获得数据`
`Web cache与Oracle data buffer对OLTP系统是很重要的`

索引

`语句越简单越好 这样执行计划也稳定`
`一定要使用绑定变量，减少语句解析，尽量减少表关联、尽量减少分布式事务`
`基本不使用分区技术、MV技术、并行技术及位图索引`
`因为并发量很高，批量更新时要分批快速提交，以避免阻塞的发生` 

在OLTP环境中使用位图索引很容易造成阻塞与死锁

*   绑定变量
    

用户并发数很大，用户的请求十分密集
并且这些请求的SQL 大多数是可以重复使用的

`OLTP 系统是一个数据块变化非常频繁，SQL 语句提交非常频繁的系统`

##### 数据块

应尽可能让数据块保存在内存当中

##### SQL

尽可能使用变量绑定技术来达到SQL重用
减少物理I/O 和重复的SQL 解析
从而极大的改善数据库的性能

`影响性能的因素`

##### 热快（hot block）

当一个块被多个用户同时读取时
Oracle 为了维护数据的一致性
需要使用Latch来串行化用户的操作
当一个用户获得了latch后，其他用户就只能等待
获取这个数据块的用户越多，等待就越明显
这就是热块的问题
这种热快可能是数据块 也可能是回滚段块

*   数据块
    

通常是数据库的数据分布不均匀导致
如果是索引的数据块，可以考虑创建反向索引来达到重新分布数据的目的

*   回滚段数据块
    

可以适当多增加几个回滚段来避免这种争用

### OLAP

`即DSS决策支持系统或数据仓库`

要对几亿条或者几十亿条数据进行聚合处理
这种海量的数据，全部放在内存中操作是很难的
同时也没有必要，因为这些数据快很少重用
缓存起来也没有实际意义，而且还会造成物理I/O相当大
所以这种系统的瓶颈往往是磁盘I/O上面的。
对于OLAP系统，SQL 的优化非常重要
因为它的数据量很大，做全表扫描和索引对性能上来说差异是非常大的

*   考核标准
    

考核标准是磁盘子系统的吞吐量（带宽）如能达到多少MB/s的流量
不看一条语句的执行时间可能会非常长，读取的数据也非常多

*   磁盘吞吐量
    

磁盘子系统的吞吐量则往往取决于磁盘的个数
Cache基本是没有效果的
数据库的读写类型基本上是db file scattered read与direct path read/write
应尽量采用个数比较多的磁盘以及比较大的带宽，如4Gb的光纤接口

#### 分区技术

`体现在数据库管理的方便性 并不能绝对保证查询性能的提高`

*   通过分区交换的方式实现数据库加载
    
*   通过备份分区表空间实现备份
    
*   通过分区进行删除数据
    

`分区对性能的影响`

*   使得一些大表的扫描变得很快（只扫描单个分区
    
*   分区结合并行可以使得整个表的扫描会变得很快
    

`优化器模式`

*   all\\_rows
    

绝大多数时候数据库上运行着的是报表作业
执行基本上是聚合类的SQL 操作，比如group by

*   first\\_rows
    

对于一些分页操作比较多的网站类数据库

`注意`

`不是大范围地使用分区关键字，而采用其它的字段作为where条件`

*   本地索引，将不得不扫描多个索引，而性能变得更为低下
    
*   全局索引，又失去分区的意义
    

#### 并行技术

在Oracle 10g中
可把一个任务，如select的全表扫描
平均地分派到多个RAC的节点上去

`不需要使用绑定（BIND）变量`

整个系统的执行量很小
分析时间对于执行时间来说，可以忽略
而且可避免出现错误的执行计划
OLAP中可以大量使用位图索引，物化视图
对于大的事务，尽量寻求速度上的优化
没有必要像OLTP要求快速提交，甚至要刻意减慢执行的速度

`一般在完成大型任务时才使用`

如在实际生活中，翻译一本书，可以先安排多个人，每个人翻译不同的章节，这样可以提高翻译速度
如果只是翻译一页书，也去分配不同的人翻译不同的行，再组合起来，就没必要了，因为在分配工作的时间里，一个人或许早就翻译完了

数据集市
----

数据仓库是企业级的，能为整个企业各个部门的运行提供决策支持手段
数据集市则是一种微型的数据仓库,它通常有更少的数据,更少的主题区域,以及更少的历史数据
因此是部门级的，一般只能为某个局部范围内的管理人员服务，因此也称之为部门级数据仓库
数据仓库向各个数据集市提供数据
几个部门的数据集市组成一个数据仓库
数据仓库中数据结构采用规范化模式
数据集市中的数据结构采用星型模式
通常仓库中数据粒度比集市的粒度要细

建库模版
----

*   OLAP使用数据仓库模板
    

数据量大，DML少

*   OLTP使用一般用途或事务处理模板
    

数据量少，DML频繁，并行事务处理多，但是一般都很短

*   DDS 决策支持系统
    

典型的操作是全表扫描
长查询，长事务
但是一般事务的个数很少
往往是一个事务独占系统

参考资料
----

https://blog.csdn.net/weixin_39935887/article/details/83902522