1. 数仓与BI
- 数据仓库(Data Warehouse)
数据仓库是一个各种数据的中心存储系统(包括历史数据和当前数据)，是BI的核心组件。这里所说的数据包括来自企业内部的各种业务数据，例如订单，库存，交易流，账目，客户，供应商等，同时也包括从外部获取的各种数据，例如爬虫爬取的数据等。
- BI 商业智能(Business Intelligence)
商业智能通常被理解为将企业中现有的数据转换为知识，帮助企业做合理的，明智的经营决策工具，是企业数字化转型的关键系统。为了将数据转化为知识，需要利用数据仓库，联机分析处理(OLAP)工具和数据挖掘等技术
- 数仓和BI的关系
2. 数据处理系统
2.1 OLTP和OLAP的区别
- 联机事务处理OLTP（on-line transaction processing）- 事务驱动
OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。
OLTP采用实体-联系ER模型和面向应用的数据库设计
- 联机分析处理OLAP（On-Line Analytical Processing）- 分析驱动
OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。
OLAP采用星型或雪花模型和面向主题的数据库设计.
下表列出了OLTP与OLAP之间的比较：
| OLTP | OLAP | |
主要使用场景 |
在线业务服务 |
数据分析，挖掘，机器学习 |
| 涉及数据量 | 当前正在发生的业务数据 | 历史存档数据，可能时间跨度比较大 |
事务和数据完整性 |
对事务和数据一致性要求比较高 |
对事务能力没有要求，数据不一致也可重建数据 |
功能使用需求 |
简单的增删改查，要求相应极端 |
复杂的聚合和多数据源关联，查询执行时间可到分钟，小时，天级别 |
并发要求 |
高并发 |
低并发 |
技术实现方案 |
事务，索引，存储计算在一起 |
大量的scan，列式存储，存储计算可分离 |
数据模型/规约 |
关系模型，3NF范式 |
关系模型，维度模型，对范式要求低 |
总的来说，OLTP就是面向我们的应用系统数据库的，OLAP是面向数据仓库的。
2.2 OLTP和OLAP存储区别
⼀般来说OLTP数据库使⽤⾏式存储，OLAP数据库使⽤列式存储
- OLAP场景下列式存储更具优势
- OLTP场景下行式存储更具优势
2.3 OLAP分类
OLAP 是一种让用户可以用从不同视角方便快捷的分析数据的计算方法。
主流的 OLAP 可以分为3类：
多维 OLAP ( Multi-dimensional OLAP )、关系型 OLAP ( Relational OLAP ) 和混合 OLAP ( Hybrid OLAP ) 三大类。
- MOLAP 的优点和缺点
MOLAP的典型代表是：Druid，Kylin，Doris，MOLAP一般会根据用户定义的数据维度、度量（也可以叫指标）在数据写入时生成预聚合数据；Query查询到来时，实际上查询的是预聚合的数据而不是原始明细数据，在查询模式相对固定的场景中，这种优化提速很明显。
MOLAP 的优点和缺点都来自于其数据预处理 ( pre-processing ) 环节。
数据预处理，将原始数据按照指定的计算规则预先做聚合计算，这样避免了查询过程中出现大量的即使计算，提升了查询性能。
但是这样的预聚合处理，需要预先定义维度，会限制后期数据查询的灵活性；如果查询工作涉及新的指标，需要重新增加预处理流程，损失了灵活度，存储成本也很高；同时，这种方式不支持明细数据的查询，仅适用于聚合型查询（如：sum，avg，count）。
因此，MOLAP 适用于查询场景相对固定并且对查询性能要求非常高的场景。如广告主经常使用的广告投放报表分析。
- ROLAP 的优点和缺点
ROLAP的典型代表是：Presto，Impala，GreenPlum，Clickhouse，Elasticsearch，Hive，Spark SQL，Flink SQL
数据写入时，ROLAP并未使用像MOLAP那样的预聚合技术；ROLAP收到Query请求时，会先解析Query，生成执行计划，扫描数据，执行关系型算子，在原始数据上做过滤(Where)、聚合(Sum, Avg, Count)、关联(Join)，分组（Group By)、排序（Order By）等，最后将结算结果返回给用户，整个过程都是即时计算，没有预先聚合好的数据可供优化查询速度，拼的都是资源和算力的大小。
ROLAP 不需要进行数据预处理 ( pre-processing )，因此查询灵活，可扩展性好。这类引擎使用 MPP 架构 ( 与Hadoop相似的大型并行处理架构，可以通过扩大并发来增加计算资源 )，可以高效处理大量数据。
但是当数据量较大或 query 较为复杂时，查询性能也无法像 MOLAP 那样稳定。所有计算都是即时触发 ( 没有预处理 )，因此会耗费更多的计算资源，带来潜在的重复计算。
因此，ROLAP 适用于对查询模式不固定、查询灵活性要求高的场景。如数据分析师常用的数据分析类产品，他们往往会对数据做各种预先不能确定的分析，所以需要更高的查询灵活性。
- 混合 OLAP ( HOLAP )
混合 OLAP，是 MOLAP 和 ROLAP 的一种融合。当查询聚合性数据的时候，使用MOLAP 技术；当查询明细数据时，使用 ROLAP 技术。在给定使用场景的前提下，以达到查询性能的最优化。
3. 离线数仓
3.1 离线数仓架构
离线数仓特点:
数据源通过离线的方式导入到离线数仓中
数据处理采用MapReduce，Hive，SparkSql等离线计算引擎
离线数仓内部分层计算
通过OLAP引擎和数据服务，对外提供计算之后的数据
3.2 离线数仓分层
ADS(Application Data Store)层：应用数据层
DWS（Data Warehouse Summary）层：高度汇总数据层。从ODS层中对用户的行为做一个初步的汇总，抽象出来一些通用的维度：时间、ip、id，并根据这些维度做一些统计值，比如用户每个时间段在不同登录ip购买的商品数等。这里做一层轻度的汇总会让计算更加的高效，在此基础上如果计算仅7天、30天、90天的行为的话会快很多。我们希望80%的业务都能通过我们的DWS层计算，而不是ODS。
DWM（Data Warehouse Middle）层：中间层， 对明细数据按照常用的维度，做轻度汇总
DWD（Data Warehouse Detail）层：明细数据层。这一层主要解决一些数据质量问题和数据的完整度问题。比如用户的资料信息来自于很多不同表，而且经常出现延迟丢数据等问题，为了方便各个使用方更好的使用数据，我们可以在这一层做一个屏蔽。（汇总多个表）
ODS（Operational Data Store）层： 离线或准实时数据接入层
3.3 典型案例
4. 实时数仓-Lambda架构
4.1 Lambda架构
4.2 Lambda架构的缺陷
- 使用两套大数据处理引擎，如果两套大数据处理引擎的API不同，有任何逻辑上的改动，需要在两边同步更新，维护成本高，后期的迭代时间周期长。
- 早期流处理层的结果只是近似准确。
5. 实时数仓-Kappa架构
Kafka的创始人Jay Kreps认为在很多场景下，维护一套Lambda架构的大数据处理平台耗时耗力，于是提出在某些场景下，没有必要维护一个批处理层，直接使用一个流处理层即可满足需求，即下图所示的Kappa架构。
5.1 Kappa架构
5.2 Kappa架构重处理过程
在Kappa架构中，即使流处理引擎再健壮，由于上游数据原因，仍然存在数据重新处理的需求。修改数据或历史数 据重新处理都通过上游重放完成(从数据源拉取数据重新计算⼀次)。
Kappa架构最⼤的问题是流式重新处理历史数据的吞吐能⼒会低于批处理，但这个可以通过增加计算资源来弥补。
重新处理是⼈们对Kappa架构最担⼼的点，但实际上并不复杂：
- 1. 选择⼀个具有重放功能的、能够保存历史数据并⽀持多消费者的消息队列，根据需求设置历史数据保存的时 ⻓，⽐如Kafka，可以保存全部历史数据。
- 2. 当某个或某些指标有重新处理的需求时，按照新逻辑写⼀个新作业，然后从上游消息队列的最开始重新消费， 把结果写到⼀个新的下游表中。
- 3. 当新作业赶上进度后，应⽤切换数据源，读取2中产⽣的新结果表。 4. 停⽌⽼的作业，删除⽼的结果表
6. Lambda vs Kappa架构
7. 离线数仓 vs 实时数仓
