大数据框架原理简介

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

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

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

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

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

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