支持百亿数据场景，海量高性能列式数据库HiStore技术架构解析

          支持百亿数据场景，海量高性能列式数据库HiStore技术架构解析

HiStore介绍

HiStore是阿里中间件团队研发的数据库产品，是一款基于独特的知识网格技术的列式数据库，定位于海量数据高压缩比列式存储，是低存储成本，低维护成本，海量数据OLAP存储引擎；有效的解决了海量数据存储的成本问题，以及在百亿数据场景下支持实时高效的多维度自由组合的检索。

关键字：列式,分布式,高压缩比;

一、HiStore



HiStore专门针对OLAP应用程序进行设计和优化，在常规X86服务器上，HiStore可以在百亿数据场景下进行高性能,多维度自由组合的adhoc查询。相对比常规事务引擎，其查询速度提升了数倍甚至数十倍。此外HiStore完全兼容MySQL通讯协议和SQL语法，可以支持客户端无代码修改进行迁移,并且无缝配合现有的MySQL客户端工具以及中间件数据层产品。

HiStore经过多个版本的迭代和深度定制化开发，现在HiStore各项指标（查询性能,数据装载效率）均超过原始版本，此外HiStore还增加了批量数据Load，并发查询以及数据块复制等自研技术。在我们团队所测试过的同类产品中（InfiniDB、Infobright等），HiStore的单机性能处于领先地位。

1.1 Histore 技术特性

海量数据背景：实测单机可以支持百亿+数据量的秒级查询；

大数据量查询性能强劲、响应时间稳定；

支持任意字段组合（adhoc）的复杂聚合类查询；

数据库维护成本低，在没有专职DBA维护索引/配置的情况下性能依然稳定；

低存储成本，高压缩比数据存储，极大节省磁盘空间。平均压缩比>10:1，最高甚至可以达到40:1；

迁移成本低，无其它依赖独立部署，MySQL工具及应用可直接无缝运行其上。

1.2 Histore适用场景

日志/事件管理系统：日志数据存储与分析，系统/网络安全审计记录；

数据仓库/数据集市: 低成本数据汇聚与存储,高性能数据导入和查询支持；

实时展示统计分析后数据，便于用户根据统计结果做决策；

大数据量的分析应用：移动app数据存储与分析,客户行为分析,营销和广告数据；

物联网/机器采样数据：传感器、射频设备等采集上报的原始样本值以]及状态信息等,用于后期统计处理；

关系型OLAP应用：HiStore作为一套完整的数据库系统,可以支撑与实时报表,决策管理及商业智能等海量数据相关的业务系统。

1.3 外部同类产品

Infobright

InfiniDB

Pivotal Greenplum

Amazon RedShift

Teradata DB

HP Vertica

SAP HANA

IBM Netezza

神舟通用,kstore

华为高斯DB

达梦数据库DM7

二、HiStore
技术架构

2.1 HiStore 引擎

HiStore 采用基于知识网格分析和SMP优化的列式存储引擎。该引擎为海量数据背景下的分析型(OLAP)应用而设计，通过列式数据存储，知识网格过滤,高效数据压缩和并行查询等特性，为应用提供低成本和高性能的数据查询支持.



2.2 基于列（Column）的数据存储

在描述HiStore的列存技术之前，可以先看看常见的行（row）式存储引擎的实现方式。以MySQL为例，常见的事务引擎（InnoDB、TokuDB等）均采用基于ROW的存储模型：

记录（Record/Row）作为数据库中最小的逻辑存储单元，每条记录包含了Table中各列的值。



通过PK（或Hidden ID）来标识唯一Row。

大部分存储引擎都采用基于B+树(或其变种)的聚簇存储(即row中的相关数据会与ID存储在一起)，此时各条记录在磁盘上的存储位置是相邻的。数据查询时直接从磁盘读取，不需要在内存中组装数据。



一般而言，每条记录总数据量不宜过大，引擎会以记录为单位在内存中进行读写。

数据库引擎一般通过批量预读以及缓存来提高性能。

在设计上要求范式化,减少冗余数据,通过多表join来构建完整视图（雪花模型）。

采用索引(Index)来增加对特定列的查找速度。

总结一下行(row)式存储引擎的适用场景：

适合典型的OLTP场景：

活动数据集不会过多（一般小于500GB），历史数据会归档储存；

细粒度事务处理（row level locking）；

单表查询只需扫描部分数据，一般通过多表join构建完整查询视图。

查询请求通常在Row中选取所有列。

频繁的插入或更新操作：更新操作的成本只与索引和Row大小相关。

但是针对海量数据背景的OLAP应用，随着数据量不断增长，行（row）式存储会出现诸如查询性能，存储效率和数据库维护等一系列问题：

数据仓库的构建以及海量数据下的OLAP查询：

海量数据存储(TB ~ PB级别)：索引的维护会占用可观的资源；

缺少高效的压缩机制，物理存储利用率较低；

常见聚簇存储,即使只需要选择部分字段,也会浪费IO操作去读取所本记录中有字段的值；

举例：select sum(score) from table，假设该表中包含1M记录，每条记录平均长度为1KB。而 score 这个column为8字节，在Row- based的存储中，为了获取大概8M的数据，需要消耗大概1GB的IO资源。



包含任意字段组合的adhoc查询，需要遍历大量数据（例如多维分析型查询）：

查询的列组合不可预测，DBA无法事先增加合适的索引来增强查询性能；

ad-hoc查询不可避免的会造成全表扫描：why? 不可能在Row-based engine中对所有列都添加索引！

如上所述，在海量数据背景下，行（row）式存储引擎无法从引擎自身解决查询性能和维护成本等问题。

与行（row）式存储不同，HiStore引擎将数据按照关系列（Column）进行存储，每列占用单独的物理存储空间，查询时在内存中高效组装各列的值，最终形成关系记录集：



数据按照列（Column）进行存储，每个列所对应的单元值（Cell）是最小的逻辑存储单元。

查询过程中，针对各列的运算并发执行,最后在内存中聚合完整记录集；

HiStore 引擎基于知识网格来在数据列中高效查找数据，无需维护索引,支持任意Column组合的adhoc查询；

高效压缩支持：因为各列独立存储，且数据类型已知，可以进行针对该列的数据类型,数据量大小等因素动态选择压缩算法。

当数据记录按行式存储，应用程序必须读取每一条完整记录，当数据记录按列式存储，数据库只返回与部门相关的值。在分析应用程序中（不可预测的ad-hoc查询），列式存储的方法可以显著减少IO消耗和降低查询响应时间，特别是大数据量查询和用户创建复杂即席查询的情况下：

海量数据下的OLAP应用（分析引擎，报表等）：

并发数据处理（SMP）：最大可能降低查询响应时间；

高效的压缩机制，提高物理存储利用率；

查询过程中能够尽量减少无关IO,避免全表扫描。

任意列组合的adhoc查询（BI系统等）：

查询性能基于知识网格而不是索引，无索引维护成本（DBA调优）；

Column-based的存储只需要访问相关列的数据即可，显著减少所需IO资源，适合基于关系模型实现的OLAP应用（ROLAP：星型模型/带字段冗余的大表）；

基于知识网格的智能查询优化，能显著降低查询响应时间；

举例：select sum(score) from table，假设该表中包含1M记录，每条记录平均长度为1KB，而 score 这个column为8字节，在列存中，只需要访问大概8M数据获取结果。



最后提一下列（Column）存的不适用场景：

事务交易场景：数据需要频繁更新。

表中列（Column）较少，或数据量固定时（常量表），列存并没有明显优势。

2.3 数据组织结构与知识网格

为了达到合理利用IO资源、且高效、快速查找所需数据的目标，HiStore引擎将数据组织为两个层次：

物理存储介质上的的块数据（Data Node、DN）；

知识网格（Knowledge Grid、KG）。



物理数据块（DN）

数据块是存储的最低层，列中每份大小固定的单元组成一个数据块。数据块比列更小，具有更好的压缩比率，又比磁盘默认存储单元单元更大，具有更好的查询性能。

物理数据按固定数据块存储（Data Node）。

数据块大小固定（典型值128KB），优化IO效率。

提供基于块（Block）的高效压缩/加密算法。

知识网格（KG）

HiStore引擎利用知识网格架构来对查询优化器，计划执行和压缩算法等提供支持，知识网格是HiStore引擎进行快速数据查询的关键。

在查询计划分析与构建过程中,通过知识网格可以消除或大量减少需要解压的数据块，降低IO消耗，提高查询响应时间和网络利用率。对于大部分统计/聚合性查询，HiStore引擎往往只需要使用知识网格就能返回查询结果（而不需要读取数据），这种情况下在1s时间内就可以返回查询结果。

HiStore 知识网格由数据元信息节点（MD）和知识节点（KN）组成：



数据元信息节点（MD）与数据节点（DN）之间保持1:1关系，元信息节点中包含了其对应数据块中数据的相关信息：

数据聚合函数值（MIN、MAX、SUM、AVG等）；

记录数量（count）；

数据中的null记录标记。

元信息节点在数据装载的时候就会构建，MD为数据压缩。聚合函数即席查询等技术提供了支持。

知识节点（KN）除了基础元数据外，还包括数据特征以及更深度的数据统信息，知识节点在数据查询/装载过程中会动态计算。

该列的数据类型定义，约束条件等基础信息。

数据节点(DN)中记录值范围段的标识BitMap.针对数值类型的记录(date/time, integer, decimal…)，范围段可以用来快速确认当前对应DN是否包含所需数据，例如对于整数类型，Field Range的大致组成如下：



从MD中获取数据块的MAX与MIN，并将MAX-MIN划分为固定段（例如1024）

每个段中分别使用1个bit标识是否有记录存在与该范围内。

关系位图记录多表join中关联的DN信息：显著提高join查询性能,减少无效DN扫描。





统计当前Column中各记录的值分布信息。

基于统计信息,HiStore引擎可以提供近似值查询（Approximate Query）支持，对于某些对数据精确性要求不高的场景（例如海量 数据下求 top 10），近视值查询可以利用统计信息去除大量不影响最终结果的数据节点，显著提升查询性能。

知识网格存储在内存中，方便快速查询。

通过知识网格，HiStore 引擎无需通过传统数据索引、数据分区、预测、手动调优或特定架构等方式就能高速处理复杂的分析查询。

2.3 计算引擎

知识网格优化器

对于来自客户端的查询请求，首先由查询优化器进行基于知识网格的优化，产生执行计划后再交给执行引擎去处理。



基于知识网格中的信息进行粗燥集（Rough Set）构建，并确定此次请求所需使用到的数据节点。

基于KN和MD，确定查询涉及到的DN节点集合，并将DN节点归类：

关联DN节点：满足查询条件限制的数据节点、

不确定性DN节点: 数据节点中部分数据满足查询条件。

非关联DN节点: 与查询条件完全不相关。

执行计划构建时，会完全规避非关联DN，仅读取并解压关联DN。按照特定情况决定是否读取 不确定的DN：

如果查询请求的结果可以直接从元信息节点（MD）中产生（例如count、max、min等操作），则直接返回元信息节点中的数据,无需访问物理数据文件。

例子：对于一个查询请求, 通过KG可以确定3个关联性DN和1个不确定性DN：

SELECT count(*) FROM employees where salary < 2500

如果此请求包含聚合函数，此时只需要解压不确定性DN并计算聚合值，再结合3个关联性DN中MD上的统计值即可得出结果。

如果此请求需要返回具体数据，那么无论关联性DN还是不确定性DN，都需要读取数据块并解压缩，以获得结果集。



执行引擎

执行计划解析与执行

执行计划解析

IO线程池维护

内存分配与管理

事务支持（redo/undo log、double write…）

SMP支持（并发查询）

物理文件管理

2.4 高效数据压缩

HiStore基于列数据类型和特定领域优化的高效压缩技术能提高查询速度，降低数据库磁盘容量。HiStore引擎通过优化后的高效压缩处 理,可以在没有特意数据库调优和管理情况下确保性能需求；随着数据量的增长，可以最小化所需的存储和服务器容量，从而节约成本，达到具有高性能、低成本的解决方案。



基于列进行数据压缩

列中所有记录的类型一致,可以根据数据类型选择对应的高效压缩算法。

列中重复值出现概率高,压缩效果明显。

数据节点大小固定,可以最大化压缩性能和效率。



字符串压缩：PPM 算法；

数值类型压缩(int,float,date/time等): PPM预测，找到最优分割位，把数据分成高位部分和低位部分，分别对分割后的数据执行Carryless RangeCoder 编码；

除了常规数据类型外，可以针对一些特定业务场景开发高效压缩算法，例如Email地址、IP地址、URL等。

2.5 其他特性

预处理数据导入



针对异构数据源背景海量数据背景，HiStore还提供了外部预处理导入支持，方便客户端应用在不增加HiStore负载的情况下告诉导入外部数据。



提供独立的数据导入客户端：

支持不同的数据源环境：Hbase, DB等环境。

客户端控制异构数据源与关系Schema的映射。

支持多语言架构。

数据预处理

导入客户端在外部处理数据块的压缩以及知识节点的构建。

数据预处理完成后，可以直接归档进入HiStore引擎，无需再次执行SQL解析、数据验证以及 事务处理等操作。

优点：

数据在外部完成预处理，直接使用二进制导入。

无需通过SQL文本来表达数据，这很适合数据量小但是插入频繁的场景。

避免SQL解析，数据验证等操作对服务器造成性能冲击.影响服务器吞吐量。

拥有异构数据源以及多语言支持，客户端可以不再通过拼装SQL语句的方式来导入数据。

高速的导入支持：可以达到2TB/小时的处理量，适合面向批量处理的系统。

近似查询（Approximate Query）

近视值查询依据存储在知识网格中每个数据节点的概率样本值，进一步过滤不会对最终查询结果造成重点影响的数据节点（DN），对于某些 对数据精确性要求不高的场景，近视值查询可以利用统计信息去除大量不影响最终结果的数据节点，显著提升查询性能。

常见的近似查询场景：海量数据下查询 top 10 记录。

2.6 HiStore 架构总结

关键字：低存储成本、低维护成本、海量数据背景下的OLAP存储引擎

低存储成本：高效数据压缩，提高磁盘存储空间利用率。

低维护成本：基于自动构建的知识网格，无需DBA手动创建索引来提升查询速度。

海量数据背景下的OLAP存储引擎：

为OLAP型应用而优化，通过知识网格、SMP、近视查询等特性，最大化查询性能。

基于关系列（Column）的存储模型，只查询所需数据，并提供任意列组合的ad-hoc查询支持。

三、HiStore未来规划

3.1 HiStore 管控平台

HiStore引擎可以提供强大的数据查询和低成本的数据存储，但是其自身的安装和管理需要一定的学习曲线，为了更有效的推广HiStore存 储引擎,我们团队也正在开发配套的HiStore引擎管控平台，通过HiStore管控平台，用户可以直接部署HiStore引擎到指定目标机器上。目前这一块正在和UDP团队合作，其最终目标为打造成为一款集HiStore
Engine自动部署，实例管控、运行时监控、数据备份/恢复以及自动化运维的一体化产品。



3.2 HiStore 高可用集群

HiStore 本身与常见关系数据库的高可用架构一样（例如MySQL），为了保证强一致性，都会将数据更新在Master上执行，然后通过复制技术将副本导入到Slave节点。

但是与MySQL标准的binlog复制不同。HiStore引擎中存储的不是原始数据，而是压缩后的数据块（DN），此时如果使用binlog的方式来进行复制，会导致网络上产生大量数据流量。

为了解决这一点，HiStore目前正计划实现基于压缩后DP块的高效数据复制支持，相对于binlog复制，该技术可以大大降低网络传输所需的数据量。

此外，HiStore也会可选地支持透明的读写分离，方便客户端在不修改的代码的情况下，扩展查询性能。

最后提一下，HiStore后续的集群技术将会朝Share-nothing的方向发展（自动处理数据分片与事务一致性），这部分的架构设计目前也正在团队中进行技术讨论与原型验证。

3.3 HiStore Roadmap

Hybrid Engine：热点数据存储在Row-engine中,历史数据自动转储到Column-engine。

数据验证：可支持自动校验数据,以此确保服务器异常退出时数据的完整性。

外部数据导入工具：支持从HDFS、ODPS中导入数据到HiStore。

知识网格管理/Rebuilder：为管理员提供针对知识网格的在线管控支持。

此外我们团队也正在讨论和验证HiStore引擎/集群与中间件团队其他产品结合的可能。

四、相关参考

术语解释：

OLAP: OLAP is an acronym for
Online Analytical Processing. OLAP performs multidimensional analysis of business data and provides the capability for complex calculations, trend analysis, and sophisticated data modeling.

OLTP: Online transaction processing,
or OLTP, is a class of information systems that facilitate and manage transaction-oriented applications, typically for data entry and retrieval transaction processing.

DN: Data Node: 数据节点. 数据块是存储的最低层,列中每份大小固定的单元组成一个数据块。

MD: Meta data: 数据元信息节点(MD)与数据节点(DN)之间保持1:1关系,元信息节点中包含了其对应数据块中数据的相关信息.

KN: Knowledge Node: 知识节点(KN)除了基础元数据外,还包括数据特征以及更深度的数据统信息.
知识节点在数据查询/装载过程中会动态计算.

KG: Knowledge Grid: 知识网格是HiStore
引擎进行快速数据查询的关键. 在查询计划分析与构建过程中,通过知识网格可以消除或大量减少需要 解压的数据块,降低IO消耗,提高查询响应时间和网络利用率。

参考资料

Histore 介绍：http://jm.taobao.org/2016/06/16/histore-intro/

ACM - An Analytic Data Warehouse for Adhoc Queries.pdf

RSCTC_Kowalski_2010 - Towards Approximate SQL

BloorResearch - What’s Cool about Columns.pdf

BloorResearch - Approximate Query Processing]

版权申明：内容来源网络，版权归原创者所有。除非无法确认，我们都会标明作者及出处，如有侵权烦请告知，我们会立即删除并表示歉意。谢谢。

-END-