聚集导航的设计和实现之读书笔记

关于聚集导航的技术，最近读了一本很不错了书籍《Mastering Data Warehouse Aggregates: Solutions for Star Schema Performance》，其中的很多理念之前已经熟悉，不过人家写了一本书讲的还是蛮细致系统的。

1,数据仓库系统与数据库系统的对比，这个已经看了很多，就不列举了。

2，避免雪花模型设计 ，除非架构需要。因为雪花模型带来的空间节省很小，却对查询和报表处理增加了很大的复杂度。

3，在企业级的数据仓库总，通常会面对多个星型模式的情况，产生了一个概念：drill across。
Drill-across reports combine data from multiple fact tables by querying each star separately and then merging the result sets by performing a full outer join on the common dimension values.


聚集的原则：
1，提升性能
数据库查询的时间花费主要集中在读取数据，大部分时间，是等待数据的从存储硬件加载。同时还要识别加载那些记录。当数据被返回后，需要执行连接和聚合操作，不过跟读取数据相比，这些额外操作所花的时间是很少的。聚集表的原理就是减少需要读取的数据量，进而提升查询性能。
2，The Base Schema and the Aggregate Schema

聚集导航的原则：
1，An aggregate schema must always provide exactly the same results as the base schema.
返回相同的结果,无论是走基表还是走聚合表，应该保证返回的结果相同。

2，The Same Facts and Dimension Attributes as the Base Schema(The attributes of each aggregate table must be a subset of those from a base
schema table. The only exception to this rule is the surrogate key for an aggregate dimension table.)
聚合表的字段应该与基表中的字段相同，唯一的例外情况是聚合表中的代理键字段。
如果引入新的外键字段则使得聚集导航对前端不再透明，有侵入性。(当然这个原则不是强制的，在biee的模型层，就实现了base schema和聚合表的字段的映射，字段名称不完全相同也是可以正确导航的)

聚合表的不可见性 :对于用户是透明的，作为数据仓库的一个组件，能够拦截sql对查询语句进行最优的表名替换，进而查询走相应的聚合表，依然返回正确的结果，但是速度快了很多。

聚集导航的实现 ，既简单也复杂，简单的情况下，只需要替换合适的聚合表名即可，复杂的情况是，如何完全透明(不考虑前端应用，后端数据库，以及物理位置等)，又如何保证聚合表的增加和删除依然保证sql的改写没有问题，一切都取决于如何维护。

数据库自带的特性，比如物化视图以及物化查询，这些技术与聚合表的理念类似，只不过物化视图是在数据库层，而聚集导航是中间层去处理。

Aggregate tables improve data warehouse performance by reducing the number of rows the RDBMS must access when responding to a query.总体思想就是，以空间换时间

Not all forms of summarization meet the requirements of invisible aggregates. 其他类型 的汇总：
1，pre-joined aggregates
the pre-joined aggregate places the results in a single table.聚合表，毕竟还是需要维度表和事实表进行关联查询的。而pre-joined的做法是将多张表查询的结果放到一张表里，避免了数据库层的join操作。带来的问题是对空间的占用比较多，特别是维度字段很多的情况。
其主要用在特定的报表查询中，在聚集导航组件处理时，要替换所有的表为pre-joined表名，然后忽略where后面的关联字段信息。
2,派生表
a.the merged fact table:The merged fact table combines facts from more than one fact table at a common grain.
b.the pivoted fact table(数据透视表):The pivoted fact table transforms a set of metrics in a single row into multiple rows with a single metric, or vice versa.
相当于将多列指标进行了行化，简化了特定的报表格式对应的数据存储问题。
c.the sliced fact table(分片表):The sliced fact table does nothing to transform the structure of the original schema, but does change its content.
根据特定维度的字段值，将事实表进行拆分，对基表结构不产生影响。
3，Tables with New Facts
总结如下：The merged and pivoted fact tables signifi-cantly alter schema structure, while the sliced fact table alters its content.虽然不能使用聚集导航，但是这些汇总表也是对于数据仓库基表的有益补充，只不过访问的时候需要应用sql显式指定。

聚集导航的实现技术涉及如下：

如何识别和选择聚合 ：
1，分析报表来识别，比如查询频率高的sql优先聚合(Don’t study every report for candidate aggregates. Instead, look at the popular ones, batch subscriptions, poorly performing reports, and those that are required by key users.)

Some tools deliver key information only when certain conditions are met. This is often called pushing.(推送)
Sometimes, the distribution of individual values within a group is not even, a concept referred to as skew. (倾斜)

设计聚合：
table-level VS process-level
A table-level conformance matrix is an important component of the design documentation. It illustrates conformance requirements, and will be useful in selecting aggregates as well.
table-level是从表的粒度进行聚合的分析，更清晰的看出潜在的聚合表。process-level则更为宏观。

涉及到缓慢变化维的问题，type 1 change(直接更新),type 2 change(保留历史，插入新的记录)

housekeeping columns 定义审核维，并在事实表中与它关联；用来跟踪数据如何被加载进DW系统，一般在ETL阶段填充数据。

Aggregate Schema的设计原则
Single Schema and the Level Field(在维度表中，针对不同的层次有对应的记录，通过level进行标识。在一张事实表中可以存储同一维度但是不同层级的聚合数据，对于定位不同层级的聚合是个好做法)
但是这种方法不太建议，因为每次查询时需要带上level条件，不然的话，很有可能导致结果错误。
所以良好的实践是，separate table(独立的聚合表 )。

命名规范：
1,保持聚合表与基表的属性字段名称一致，这样可以保证一致性，易于理解，同时对sql的替换处理也只需要修改表名而已这么简单。
2，聚合表本身的命名要能够表达该表存储的数据，便于直观的了解。但并且是随之而来的问题是，表名直观的话就会很长，常用的缓解方法是用些缩略词来表示，比如brand-brd，统一并且坚持下去。开发人员自己要形成一定的规范即可。

有些操作不适合走聚合表，还得走基表。
Counts cannot be accurately performed against aggregate schemas, even if all attributes are the same. All counts must be performed against the base schema.



USE AGGREATE:
前置条件：
1,维度，指标是否满足
2,行数比较
3,is available?分为on-line和off-line(也许该聚合表还在装载中)
4,都不满足的情况下，依然走基表。

The aggregate navigator should support aggregate star schemas (including aggregate dimensions) and pre-joined aggregates (if desired). It should not require changes to the base schema design.
聚集导航是在运行时将sql进行重写，对于前端而言是透明的。

在设计和实现上，聚合表可以灵活的增加和下线，聚集导航组件能够智能处理。同时设计上要能够支持Multiple Front-End applications(比如不同的报表工具，即席查询)，方便接入无需重复开发。还需要支持Multiple Back Ends，通常数据仓库不会再一个数据库，可能会跨域多个数据库平台。

总结：
1. The aggregate navigator should permit users and applications to deal with the base schema only.
2. The aggregate navigator should support aggregate star schemas (including aggregate dimensions) and pre-joined aggregates. It should not require
changes to the base schema design.
3. The aggregate navigator should be able to identify all necessary information automatically, through examination of the database catalog. This includes aggregate families, conformance, and relative table size.
4. The aggregate navigator translates base-schema SQL into aggregate-aware SQL at runtime. This process is transparent to the applications that issue
SQL queries.
5. The aggregate navigator should respond to the dynamic availability of aggregates.
6. The aggregate navigator should facilitate easy addition and removal of aggregates from the data warehouse.
7. A single aggregate navigator should service all front-end applications.
8. A single aggregate navigation system should service all back-end databases.