HiStore：阿里巴巴海量数据场景下的OLAP解决方案

原文地址

本次分享的主题是阿里巴巴海量数据场景下的OLAP解决方案，主要是也为大家介绍一下阿里巴巴OLAP存储的一款产品——HiStore。大家都知道海量数据，包括大数据和数据仓库这些在当下都是非常热门的话题，大家都比较关心这个领域，所以这个领域也成为了各大厂商的必争之地，为什么？原因很简单，就是在未来，大家的不同就在于对于数据理解的不同，换句话说就是未来属于能够真正地读懂数据的人。

本次的分享将主要围绕以下四个方面进行：
一、HiStore产品的由来以及它所能够应对的场景以及能够解决的痛点
二、结合现实已经落地的成功案例帮助大家 理解HiStore的应用场景以及HiStore能够为业务带来什么样的价值
三、HiStore在目前海量数据、大数据以及数据仓库领域的定位
四、HiStore的核心技术、架构设计以及优化思路

一、Why HiStore？
业界的痛点

那么业界的痛点在哪里呢？从传统互联网数据到移动互联网数据，再到现在很热门的IoT，实际上随着每一次业界的进步，数据量而言都会出现两到三个数量级的增长。而且现在的数据增长呈现出的是一个加速增长的趋势，所以现在提出了一个包括移动互联网以及物联网在内的互联网大数据的5大特征：Volume、 Velocity、 Variety、 Value、 Veracity。同时也出现了一些问题，第一问题就是成本，成本问题是一个日益突出的问题，大家也知道，就是半年前SSD的硬盘架构飙涨了一倍，可以说已经赶上了房价的涨幅，现在的情况是硬件成本如此之高，即便是再土豪的公司也需要考虑成本的问题。另外一个问题就是在这么大的数据量的背景下，让数据发挥出自己应该有的价值，实际上需要高效的聚合和查询分析。如果想要让大数据分析出来的趋势更加精确，能够带来更高的参考价值，就需要更多的维度，但是维度更多则会带来更多技术上的困难。另外就是实时性，在某些场景下需要大数据呈现实时或者准实时的结果。另外就是迁移和学习的成本，其实很多公司也都在考虑怎样去迁移数据以及怎样更加方便的接入大数据的产品。

现在提到大数据，其实大家第一反应就是Hadoop体系的产品非常之多，让人眼花缭乱。在这里也为大家简单地梳理一下Hadoop技术栈的主要产品：第一代的HDFS、MapReduce产品，可以说太慢了，逐渐引进到第二代，第二代就是通过内存cache等增加吞吐量的方式产生了Spark等产品，这时候性能得到了进一步的提升。再往后就是如果想要实现一个复杂任务的话，使用MapReduce就会是一个比较复杂和麻烦的事情，那么就会考虑到是不是使用脚本或者SQL的方式就会更简单呢？因为SQL比较简单，那么就产生了Hive和Pig，而且现在逐渐比较流行了，到了这一步就已经引入了SQL了。SQL已经比较好用了，但是这时候在某些场景下实际的性能还不够，应该怎么办呢？其实性能还不够的原因在于之前的MapReduce以及Spark这种模型做的太通用、太健壮、太保守了，实际上我们应该在某种程度上更激进地获取数据，实际上这时候就产生了一些计算层的产品，比如Presto，Drill，Impala。

实际上就是Hadoop体系从下往上看就是从最底层的HDFS或者其他的一些分布式文件系统，到上层的第一代的MapReduce、Spark，在往上就是到Pig或者Hive；另外就是HDFS或者其他文件系统上直接跑Presto，Drill，Impala；那大规模数据处理的另外一个领域——大规模分布式MPP架构，比如SAP的HANA，HP的Vertica，开源的GreenPlum等等。 

集团内的痛点

那么，反映到集团内是什么样痛点呢？以集团内的某个日志系统为例，它每天会产生几万亿条日志，每产生的数据将近PB级别的量级，如果使用MySQL可能会需要使用数千台，这个成本是不言而喻的。从公司层面看，存储领域有数十万台物理机，其中的大概50%用于存储离线数据，包括历史数据、日志、轨迹、用户行为分析数据。其实这部分数据是符合OLAP的场景的，因为这部分数据的增长速度是加速增长的，所以这部分数据存储的成本是要控制住的，也是需要关注的。另外就是在如此大的数据量的情况下，在降低成本的同时要保证数据分析的时效性和高性能。

什么是HiStore
为了解决前面提到的业内以及集团内面临的痛点，HiStore产品就应运而生了。HiStore产品的定位是分布式低成本OLAP分析型数据库产品，是一款基于独特的知识网格技术的列式数据库，定位于海量数据高压缩比列式存储，是低存储成本，低维护成本，海量数据OLAP存储引擎；有效的解决了海量数据存储的成本问题，以及在百亿数据场景下支持实时高效的多维度自由组合的检索。而且通过近两三年的发展，HiStore在阿里内部已经应用于多个核心应用，包括菜鸟、 B2B、阿里妈妈、聚划算、天猫等，也应用于很多外部用户，比如在人社部，上海新能源汽车，新零售等超大数据量测试环境都取得了令人信服的结果，无论成本、性能、稳定性都表现完美。

HiStore提供哪些特性来解决相关问题呢？HiStore所具有的特性如下图所示：

基于上面的这些特点，HiStore具有如下的这些优势：

• 海量数据存储: PB级数据大小，百亿条记录，数据量存储主要依赖自己提供的高速数据加载工具（TB/小时）和高数据压缩比（>10:1）。
• 高压缩比：平均压缩比>10:1，远高于常规压缩算法，甚至可以达到40:1，极大地节省了数据存储空间。
• 基于列存储：无需建索引，无需分区。即使数据量十分巨大，查询速度也很快，用于数据仓库、查询性能强劲、稳定：亿级记录数条件下，同等的SELECT查询语句（这里主要是聚合查询，多维查询等等），速度比MyISAM、InnoDB等普通的MySQL存储引擎快数十倍。
• 高性能数据导入：基于MySQL协议的并行导入，以及专门的数据预处理入库工具。
• 多维分析查询：实时性的多维度数据检索；海量数据聚合秒级计算；为实时业务提供保障。
• 线性扩展：用户可以轻松实现存储容量和处理能力的线性提升。
• 系统易用：迁移成本低，无其它依赖独立部署，MySQL工具及应用可直接无缝运行其上。
• 快速响应复杂的聚合类查询：适合复杂的分析性SQL查询，如SUM, COUNT, AVG, GROUP BY。

二、案例分析
接下来会借助一些成功落地的案例帮助大家深入地理解HiStore产品的使用场景。首先看下图将HiStore产品的应用场景做了简单的分类，这部分场景包括数据分析与商业智能、用户画像和用户行为、历史数据、分析应用与广告数据、日志，轨迹，记录，监控，归档、数据仓库、物联网数据、存储成本敏感等。

而以上所有分类的场景都基本具备以下的特点：海量存储、快速导入、低存储成本、低接入成本、多维度检索和复杂分析、并发访问量大、数据实时分析、响应低延迟、数据自动过期、深度挖掘、线性扩展以及生态兼容等。

案例1：高德热力图
接下来结合几个实际的案例来分析，第一个案例就是高德热力图。大家都知道高德的产品是与地理相关的，它可以拿到每个人的地理信息，那么通过这种人地关系以及用户画像相结合，就可以实现如下图中右侧所示的界面这样的显示出用户的职业、性别、年龄、教育水平、资产等的用户画像。高德能够将地理位置与用户画像结合起来，那么就能够迸发出很多的商业价值，比如在确定了目标人群之后，对于商铺或者商品而言就可以通过这样的应用分析出潜在的客户，这样的产品目前也是高德目前的拳头级产品。那么对于这样的产品而言，在技术实现上有哪些难点呢？第一就是数据量大，万亿级别，导入速度要求高；除此之外就是想要在这么大的数据量上进行这样多维度聚合查询得出趋势和结论，传统的MySQL数据库将无法完成，简单来说传统MySQL数据库的InnoDB引擎是B+树的改进，B+树实际上是磁盘不友好的数据结构，其在数据查询和导入的时候会产生大量的随机IO，而且随着数据量的增加，B+树的分列会越来越多，就会导致数据导入越来越慢，查询起来也会越来越慢，甚至无法得出结果。

HiStore产品的引入帮助高德解决的第一个问题就是不管数据量多大，能稳定的在秒级别完成多维度Adhoc查询。其次就是实现了高性能数据导入，实际部署时的百亿级别增量数据在两小时之内就可以完成导入，而之前却需要至少一两天的时间，这也是一个非常明显的优势。还有就是高压缩比，机器成本低，可以帮助高德将机器成本降低到原来的十分之一。

案例2：御膳房项目

御膳房策略中心项目是阿里巴巴集团“品销全营销，unimarketing”项目中的一部分，产品定位是品牌商品牌发展策略的支持平台，通过从淘宝、天猫、聚划算等平台收集的海量实时数据，帮助品牌商更高效，更明智地做出品牌发展相关的商业决策。

御膳房这个项目的第一个特点就是数据量大，另外一个很明显的特点就是需要聚合的维度非常多，在下图中就可以看出有非常多的维度，可以到几百个维度，而且他还需要动态地增加维度，这是什么意思呢？也就是说可能今天只有200个属性，需要在这200个属性维度上进行数据分析，而明天可能表立马扩展成300个属性，那就需要在这300个属性维度上做数据分析，也就是这种动态地扩充表的维度，以前是没有办法实现的，维度上限也很低，一般几十个维度就到上限了。所以御膳房在业务上难点和痛点就是商品属性的维度是动态的,需要支持多维查询；另外就是查询的数据量很大，还涉及到了一张8亿条数据的表和一张1亿条数据的表之间的join。还有就是目前存储成本太高、稳定性不好且数据导入实时性不够。

而HiStore引入的价值和意义就是秒级别的高效稳定的多维查询，可以支持多达4096列，基本上可以满足大多数的场景，另外还可以动态增删列: 标准MySQL语句ALTER TABLE就能够搞定了，而不需要再进行复杂的操作。至于在动态增删列之前的那些数据，比如像null填充、以及默认值等都是可以实现的。另外就是高性能数据导入，十亿数据在一个小时加载完成，相对当前方案提升十倍。最后一点就是在存储成本上有明显的降低，御膳房二期全链路和透视项目从原来400台高配物理机集群，替换为50台HiStore docker机器部署。可以看出使用HiStore为御膳房解决了非常大的痛点，带来了非常大的价值。

案例3：蚂蚁体验平台
我们再来看一个例子-蚂蚁体验平台，这个产品是为了构建一套包含“问题收集、分析、推进、协作、价值衡量”的体系，帮助蚂蚁金服自己的产品做良性的改进；方便蚂蚁小二对集团的数据进行分析，比如对花呗的几千万上亿的会员进行画像分析，从而对于产品做一些改进，这是用户行为分析以及商业智能的又一个典型的场景。

蚂蚁体验平台所面对的业务痛点就是之前使用MySQL方案，单表数据大于2000万时，查询经常超时；特征列不能超过100列，查询条件越多越慢扩展不方便，并且维护索引非常麻烦。在上图中右边这张表中，包含有count (*) [where]条件，有一列、五列和十列的结果，如果使用MySQL的话就会随着查询列数的增加查询时间明显增加，从15秒到65秒再到150秒，然而对于HiStore的单机或者集群而言，却可以随着查询条件的增多查询的速度反而更快，可以从一个查询条件时的1秒到5个条件时的0.5秒，再到10个条件的时候不到0.3秒就搞定了，这是一个正好与MySQL相悖的情况，这是为什么呢？其实这与HiStore的存储结构相关，简单讲HiStore的查询是通过粗糙集过滤的方式实现的，也就是查询的条件越多，在内存时就能够过滤越多的数据包，最后实际上真正需要解压做查询的数据包就会越来越小，这就是为什么随着查询条件越多，查询速度越快的原因。

案例4：全链路追踪系统EagleEye
EagleEye是集团内一款应用广泛的分布式调用跟踪系统，主要帮助用户方便地查看应用的实时数据及快速定位线上问题，为全链路压测、跨单元分析、链路梳理提供数据支撑。而EagleEye系统日志量非常之大，大到每天近万亿条，大概每天会产生数千TB的数据，这个数据量在业内也属于顶级的一个水平了。另外就是EagleEye系统的数据峰值很高可以达到数千万的TPS，如果使用传统的MySQL成本太高，这样是吃不消的。

而HiStore在如此大数据量的场景先，能够为EagleEye系统实现秒级别的多维度Adhoc查询，做到单机支持数十万TPS写入，并且实现高压缩比存储，为集团节省数千台机器的成本。

三、竞品分析
接下来为大家简单介绍一下大数据领域以及数据仓库领域，HiStore产品的定位以及竞品分析。

上图的纵坐标表示的是产品的成熟度，横坐标表示的是趋势。从这张图的最左边的最传统的OLAP的数据库解决方案，一直到中间第二阶段的基于列式存储的大规模MPP架构的分布式存储引擎，这部分主要是针对结构化数据，这部分包括惠普的Vertica以及SAP的HANA等都是业内著名的数据仓库解决方案。大家可以看到HiStore也在这一部分，但是要偏向于下面一下，因为HiStore的定位是一个存储引擎，所以其产品化程度不如Vertica以及HANA，因为大家都知道HANA在上层的数据抽取和数据展现都比较好的。再往右这部分就是Big Data这部分，这部分主要是解决存储计算分离，这种半结构化数据或者非结构化数据这样的异构源，什么意思呢，举个例子就是，有一部分非结构化数据存储在HBase上，另外一部分结构化的数据存储在MPP架构的HiStore上面，那如果对于这两段数据进行join的话，实际上就会使用大数据计算层的技术（如Presto，Drill）解决这些问题。HiStore这个产品在大规模MPP架构场景下和Hadoop体系以及Big Data体系下的这两个方向其实都是有适用场景的，这就是HiStore的定位。其实大家也能够感觉到，很多技术的边界变得越来越模糊，很多组件之间可以相互融合或者相互组合，这也是未来技术的一个大趋势。

以下是针对于MPP架构的同类产品分析：

但是如果拿HiStore与上述的这些产品进行比较，HiStore有什么优势呢？举一个新零售行业的例子，之前它可能会使用SAP的HANA做数据分析和报表展现，之前的成本可能是一次性花费了500万，成本非常高。当使用HiStore评估其场景后发现，其业务与之前提到的一些销售的单据展现以及BI类似，HiStore对于其场景以及功能性支持都是可以的，根据数据量来看，使用两个实例就搞定，每个实例15万，30万就搞定了，也就是可以将原来500万的成本降低到50万之内，这也是一个很典型的例子。也就是HiStore能够在同样满足用户数据分析需求的前提下将成本尽可能地降低，这也是HiStore在业内最大的优势所在。

四、核心技术

下面简单介绍一下HiStore的架构和一些核心的技术点：
列式存储引擎

HiStore使用的是列存，也就是Column-based，它与传统的Row-based不同。如果需要查询数据表的某一列，传统方式是使用Row-based，也就是将每一行数据都取出来，然后取出其中的某一列，这样做其实磁盘的效率很低。而使用Column-based则可以直接取这一列，这样可以节省很大的磁盘IO，从而间接地提升磁盘性能。另外按列可以对于相同数据进行压缩，特别是数值相同的情况，这也就是为什么推荐用户使用数值型的来做，因为使用数值型可以压缩的更高。另外就是看起来可能需要使用文本，比如String类型的省份信息，这一类看起来好像是文本类型，但是36个省份可以在内部优化转化成为36个整型数据，实际上这个压缩也是非常占优势的，也就是说，重复的数据越多，压缩就会越高效，这也是Column-based数据库的优势。

数据组织结构

数据组织结构就是知识网格，每一列大概是64K条数据做压缩，做压缩之后每一列会产生两个数据结构，一个叫做Metadata，另外一个是KG。Metadata存储了这一列64K条数据里面的最大值、最小值、和以及平均值等预统计信息，这就是为什么在进行预聚合的时候会非常快，因为不需要解压数据，只要将这些统计信息全拿到就可以了，而且执行时间是不会随着数据量增加而增加的，因为Metadata和知识节点都是内存里面的，不需要跑磁盘，不需要解压，所以速度非常快，这就是秒级聚合快的根本原因。另外一个就是查询时候用到的知识网格KG，这也是进行高效查询过滤压缩包的关键技术，后面我们也会详细介绍一下KG。

整体架构
下面这张图大家可以从左上角开始看起，标准的MySQL客户端以及标准的JDBC和ODBC客户端都可以进来，其下面就是Parser以及Optimizer，也就是解析和优化器根据HiStore独特的数据结构来进行优排。再往下就是KG Manager，也就是知识网格和MetaData，这块内容也是数据结构最为核心的部分，也是高速数据导入最核心的部分，也包括Succinct Data。Succinct也是最近比较火的一个技术，它可以实现更好的数据压缩以及基于压缩包的检索，也就是说它可以在不需要解压数据的前提下就进行检索，HiStore中对于Succinct Data的数据结构实现了其C++版本。再往下的Memery Manager，也就是对于内存进行更加高效的加载，使得更多的数据存在内存里以实现更高效的数据查询和导入，然后右边这部分就是一些并行计算，比如sharding，也就是一条SQL语句进来之后如何实现分片，以及在分片之后进行并行处理。因为现在机器高配都是多磁盘的，那么可以实现充分利用多核、多磁盘以及这种并行计算的硬件优势。再往下就是压缩、解压，包括LZ4或者是PPM这种压缩解压算法。到最底下的落盘，HiStore支持与MySQL相同标准的Binlog以及自己的Hilog，这样可以方便的通过DRC以及阿里内部的精卫等进行数据同步，同步到其他数据源都是没有任何问题的。

原文地址