OLAP

Posted on 2022-08-12 Edited on 2024-09-17 In Computer Science Views:

Outline:

OLAP Database

OLAP数据库是数据分析领域过去几十年内常用的数据仓库，近年来已经被列数据库逐步取代。

OLTP: using a database to run your business
- 对OLTP 数据库的查询形如: "one Honda Civic by Jane Doe in the London branch on the 1st of January, 2020";
OLAP: using a database to understand your business
- 对OLAP数据库的查询形如: "give me the total sales of green Honda Civics in the UK for the past 6 months"

可以看到，OLAP的查询比OLTP复杂的多。关系型数据库可以胜任OLTP，但是对于每个OLTP查询，都可能要进行大量连表，效率很低。而在BI( Bussiness Intelligence )中, 有着大量的OLAP查询

可以看到，每一次子查询就是查询某个"维度(dimention)"。比如，如果要查“找出某天某地生产的所有产品”，那么对于“时间”、“地点”、“产品”这三个维度，就要进行三次连表，开销是不可接受的

OLAP 数据库把数据按维度组织成高维数组。一组数据就形成了一个"cube"，进行OLAP查询时复杂度只有O(1)

OLAP数据库的问题有：

每个cube只能适应一小部分的OLAP查询。假如出现了新查询或者新的类型的数据，需要新建Cube. 比如说，对于上图的Cube，如果数据分析师想要进一步分析“省份”数据，而原有Cube没有“省份”这个维度，就得让数据工程师新建一个包含了这个维度的Cube
要把数据仓库中的数据转化为OLAP Cube, 需要对数据仓库进行一定的建模( 需要满足一些稀奇古怪的范式要求，比如 Kimball dimensional modeling, Inmon-style entity-relationship modeling, or data vault modeling )；并且采用大量的pipeline，比如ETL (extract-transform-load)
数据分析师的工作会严重依赖数据工程师。因为每次有新的分析，都需要数据工程师来创建新Cube。工作效率极低。同时数据工程师还得维护pipeline。

OLAP Cube的问题来源于它要牺牲劳动力来节省计算和存储资源。近年来，随着CPU性能提升，内存价格降低，以及列数据库的出现， OLAP已经逐步被列数据库所取代。 列数据库可以胜任OLAP workload，并且性能更高。这样做的好处有:

如图，列数据库把数据按列存储，特点有：

对于"Read only"的OLAP workload(也就是有好多维度的只读查询)，这种存储方式是完美契合的，每个维度查一列就行了
- 同时也可以看到列数据库的缺点 --- 修改既有数据的效率非常低，因为要把该行的每一列进行一次删除。好在OLAP workload大部分是Read Only的，事实上很多OLAP查询根本就不允许修改原有数据
由于数据按列存储，而同一列的数据一般而言格式相似，因此列数据库比行数据库更容易压缩，减少内存占用
因为列数据库可以更大程度地压缩，也就能腾出更多的内存来给其他进程使用。列数据库的排序等操作因此更快

ETL：Extract, Transform, and Load. 即将源数据库( OLTP database )的数据“提取( extract )”到专门的数据处理服务器，后者将数据“转换( transform )”为符合要求的形式，最终结果被加载到最终的数据仓库( data warehouse )
- ETL和OLAP是紧密联系的。 ETL的目的数据仓库的数据已经是“提取、转换”之后的数据了。因此ETL具有和OLAP相同的缺点：
  1. 每次新查询都要重新ETL
  2. 需要专人来进行ETL
  3. 最糟的是，海量数据的ETL是很耗时的。那应该在什么时候进行ETL呢？你可能认为可以在晚上ETL，白天工人上班的时候直接拿结果来用。但是如果是跨国公司，某个地方的晚上是另一个地方的白天，就没法做到ETL的同步，数据也就没法同步
ELT： Extract, Load, and Transform. 随着硬件的发展，现在普遍将数据直接传输到目标数据仓库，然后数据分析师手动进行数据处理( Transform )