对上一篇文章遗留问题的联邦学习之一
数亿级数据量体系结构是如何设计和实现的
要解决这个问题，首先要对处理框架的相关内容进行大数据
这篇文章让我们进入了大数据处理的世界
首先，要成功使用这些组件并设计大数据处理架构，必须了解大数据的相关概念和原理
flume sqoop数据仓库ETL ODS Data Mart OLTP OLAP数据集市
我们逐一分析原理
flume sqoop Hadoop和关系数据库服务器之间传送数据
数据仓库是用于战略决策的数据
几乎不更新的反应历史变化的数据
dw :数据仓库
是一个大型数据存储库的集合
是为了企业的分析报告和决策支援而制作的
过滤和集成各种业务数据
为企业提供一定的商务智能(BI )能力
指导业务流程的改进、监控时间、成本、质量和控制；
数据仓库的输入位置是各种数据源
最终输出用于企业数据分析、数据挖掘、数据报告等方向
主题性与传统数据库对应的twdbbz中的一个或多个项目不同
数据仓库基于用户的实际需求
在高抽象级别合并来自不同数据源的数据
所有数据都围绕主题进行组织
例如，关于滴滴出行，“司机的行动分析”是主题
链家网的“成交分析”是主题
统一数据仓库中存储的数据是来自多个数据源的统一
原始数据的保存方法因数据源而异
要合并到最终的数据集合中，需要从数据源经过一系列的提取、清洗和转换过程
稳定性数据仓库中存储的数据是一组历史快照，不能更改
用户只能使用分析工具进行查询和分析
时变数据仓库定期接收新的综合数据并对最新的数据变化做出反应
ETL ETL是提取、清洗、转换业务系统的数据并加载到数据仓库中的过程
其目的是整合企业内分散、零散、标准不统一的数据
为企业决策提供分析依据
ETL是BI项目的重要一环
在BI项目中，ETL通常至少占用整个项目的1/3的时间
ETL设计的好坏直接关系到BI项目的成败
ODS短期实时数据由产品或运营人员日常使用
可更新的数据
操作型数据存储
保存的是现在的数据状况
向用户提供当前状态
需要提供即时性、易用性和统一的整体信息
ODS是从数据库向数据仓库的过渡形态
与数据仓库物理结构不同，提供了高性能的响应时间，ODS设计采用混合设计方式
ODS数据为“实时值”，而数据仓库数据为“历史值”
ODS通常存储不超过一个月的数据，但数据仓库超过10年
诊断支持系统(DSS )决策支持系统用于支持管理决策的系统
DSS通常分析大量的数据单元
通常情况下，数据更新无关
Data Mart为特定APP应用目的或范围而独立于数据仓库的数据的一部分
也称为部门数据或主题数据(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