CMU15-721 Note1 | Modern OLAP Database Systems

文章发布时间:

最后更新时间:

文章总字数:
1.4k

预计阅读时间:
5 分钟

页面浏览: 加载中...

1. 背景

  • OLAP(on-line analytical processing) 被用来从现存数据集中提取新信息。
  • 过去常在包含所有数据的单独的数据库中运行(比如直接在mysql，pg中运行AP负载的查询)

1.1. 1990s Data Cubes

  • 数据库会维护一个多维数组作为预先计算的聚合来加快查询：
    • 需要定期刷新物化视图(Materialized View)
    • 需要管理人员提前指定特定的数据立方体
  • 在现存的行存数据库中经常被提到

比如，以下sql语句从销售表中聚合出了一个三维数组，维度分别是商品名称、地区、日期，后续查询如“某商品销售总额”、“某地区某天销售总额”等时能加快计算速度。

1
2
3
4
SELECT
  商品名称, 地区, 日期, SUM(销售额) AS 总销售额 
FROM 销售表 
GROUP BY CUBE(商品名称, 地区, 日期);

2000s Data Warehouses (数据仓库)

  • 专门为AP负载设计
  • 单片式无共享架构
  • 列式储存数据
  • 数据使用专有格式/编码
  • (许多该时期的系统开始于从Postgresql创建分叉)
  • 通过ETL(Extract, Transform, Load)将数据从TP数据库存到AP数据库

1.2. 2010s Shared-Disk Engines

  • 依赖第三方分布式存储系统(而不是定制的)，比如S3
    • 第一代系统自己管理文件
    • 新系统允许外部实体直接向存储系统添加新数据文件，不强制数据结构(lakehouse)
  • 结构：
    • 外部实体/ETL：向存储系统上传数据文件，并登记这些文件信息
    • 查询引擎：从登记处查找需要查询的文件信息，并去存储系统中查询

1.3. 2020s Lakehouse System

  • 数据湖的中间件，增加了更好的对事务性 CRUD 操作的模式控制/版本控制的支持(本课程不探讨这部分)
    • 将更改存储在带有索引的行存日志结构文档中
    • 定期将最近添加的数据压缩到只读列式文档中
  • Lakehouse利用了以下观点：
    1. 人们对于数据不止有运行SQL的需求(比如在数据上运行机器学习的需求)
    2. 将数据存储和数据库管理系统解耦利于减轻输入输出的阻碍(不再只能通过数据库驱动来获取数据)
    3. 大多数数据是非结构化/半结构化的

2. OLAP数据库系统架构

2.1. OLAP数据库组件

一个目前趋势是将OLAP数据库系统拆分成独立的服务和库，兼顾可操作性和性能极具挑战：

  • 系统目录
  • 中间表示(IR)
  • 查询优化器
  • 文件格式/文件访问库
  • 执行引擎

2.2. 架构总览

architecture overview

2.3. 分布式查询执行

在分布式数据库系统上执行查询和在单节点上一样。执行计划是一个DAG。每个operator只需要考虑从哪获取数据和向哪里输出数据。

数据分为两类：

  1. 持久数据(Persistent Data)：数据库中的源记录。现代系统认为它们是不可变的，但是可以通过重写来改变(可以看做Append Only的)
  2. 中间态数据(Intermediate Data)：生命周期短。与读取持久数据量或者执行时间几乎没有相关性

2.4. 分布式系统架构

分布式数据库指定了持久数据文件的位置。这影响了不同节点如何相互协作和从数据库中存取对象。两种连接数据和查询的方式：

  1. Push query to data：
    • 将查询发向数据节点
    • 在数据需要通过网络传输之前进行尽可能多的过滤和处理
  2. Pull data to query：
    • 从其他节点拉取数据到处理节点
    • 当持久数据文件所在节点没有计算资源时，这是必须的

2.5. 系统架构

  • Shared-Nothing：
    • 每个节点拥有自己的CPU、内存、本地磁盘，节点之间只通过网络相互交流
    • 数据库在节点间被分片成不相交的子集，新增节点需要在节点间物理地移动数据
    • 由于需要移动数据，节点容量难以平衡
    • 因为数据是本地的，数据库可以通过POSIX API访问数据文件
    • 允许Push策略，具有高性能潜力，可以在数据传输之前过滤转换
  • Shared-Disk(过去十年的主流)：
    • 通过内部连接，每个节点连接一个逻辑磁盘，解耦了计算节点和储存节点
    • 拥有自己的CPU、内存和短期储存，依然必须在节点间发送信息来了解各自当前状态
    • 使用用户空间API来访问磁盘，而不是POSIX API
    • 空闲计算节点资源可以轻易关机
    • 可能需要Pull策略从储存节点拉取未被缓存的持久数据(在过滤和转换之前)

2.6. Shared-Disk 实现

  • 传统存储层位于本地NAS(e.g. Oracle Exadata)
  • 云对象存储是现代OLAP数据库系统的主要目标，因为其近乎无限的可扩展性(e.g. Amazon S3, Azure Blob,...)

3. 对象存储(Object Stores)

  • 将数据库中的表(持久数据)分割成大的不可变的储存在对象存储中的文件
    • 单个元组的所有属性都以列存存在同一个文件中
    • 文件头(或尾)包含关于列存偏移、压缩架构、索引和区域映射的元数据。数据库检索文件头来决定它应该检索文件中的字节范围
  • 每个云供应商实现自己的专有API来访问数据(GET,PUT,DELETE)
≡