本次分享的主题是阿里巴巴海量数据场景下的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以及阿里内部的精卫等进行数据同步，同步到其他数据源都是没有任何问题的。
再看一下数据的导入，这部分可以使用histore高效的导入工具从hbase、odps以及oracle db等导入数据。另外就是最右边的运维、管控这部分内容，hidas可以实现对于数据库的运维、监控、报警、部署等一体化操作，方便地实现对于数据库的运维，以上这些就是histore整体的架构设计。
接下来为大家分享一下histore的核心技术点。
核心技术1：histore查询优化器
大家可以从下图中看到从上面的histore查询优化器下来之后到中间有三种过滤器，也就是前面提到的kg部分，包括位图索引，bloom filter过滤器，以及直方图，可以更好地实现粗糙集过滤。实际上在查询的时候最高效的就是这三个部分：位图索引、bloom filter过滤器以及直方图，这部分都是在内存里面可以过滤大部分无效的包，真正可以被命中的压缩包才会从磁盘中被读取出来，然后进行解压去寻找。
往右边看的话，就是接下来准备做的按列索引，因为原来的时候是没有索引的。再右边是基于代价的关联方法，也就是表与表之间的join，在普通的表与表之间可以使用hash join，在大表之间可以使用map join或者merge join。
核心技术2：执行优化
histore对于很多sql语句都实现了执行优化，可以理解成可以根据histore的存储结构做一些语句上的查询条件的优化，比如让哪些查询条件优先执行，其实这与sql优化的核心思想是基本一样的，就是让更苛刻的条件优先执行，可以过滤更多的包，这其实也是目前通用的做法。
核心技术3：压缩数据实时检索
这个部分主要采用succinct技术，针对不同类型的字段进行了单独的优化处理。这个算法非常复杂，其实简单而言就是通过原始数据的bwt变换，能够将字典排序做的很好，更加高效地压缩，并且通过游程编码以及checkpoint来加快检索，实现不需要解压数据就可以实现检索。
核心技术4：高性能数据写入
之前也有所提及，histore在数据导入这部分也做了重点的优化。简单而言就是两点：第一点就是cpu的每个核与每一列、每一个磁盘都进行绑定，实现了多线的并行的导入，充分利用多核和多磁盘的硬件特性进行高效导入；另外一点就是在内存里基于mmap实现一个ringbuffer无锁队列，这个是非常高效的。大家都知道mmap在linux用户态和内核态之间进行切换的时候可以减少一次内存拷贝，于是就能够使得磁盘io更加高效。通过以上的两个方面，单机数据导入可以达到每秒70万条数据，除此之外，insert的功能可以达到每秒10万+这样的级别，并且数据是实时导入，实时生效的。
核心技术5：mvcc无锁读事务
这部分的技术主要是解决了数据导入的读写锁对于并发查询的阻塞，以前的并发查询的性能不是太好，就是因为读写锁会造成阻塞。其实简单来讲，histore实现了snapshot隔离级别，每个事务每次进来的时候看到的数据都是一个单独的copy，这也就是copy-on-write，直到事务的整个生命周期结束、修改完成，下一个事务进来的时候才会看到新的copy，这就是snapshot隔离级别的mvcc。怎么做的呢？其实还是计算机领域那句经典的话“all problems in computer science can be solved by another level of indirection”，也就是说所有的计算机问题都可以通过添加一层中间层来解决，在这里的应用就是通过添加一个request proxy这样一个中间层来解决问题。
核心技术6：硬件加速
目前这部分是histore在尝试进行实现的，现在就是包括fpga、gpu等技术都在进行尝试，在fpga方面的尝试是基于intel的qat技术，实际上qat这个技术成功的落地场景主要有三个：编解码、压缩解压以及加解密。我们就是应用intel qat的fpga板来分担cpu的压缩解压这部分，这样就可以释放部分cpu的能力，因为之前压缩解压是非常消耗cpu的工作。这样有什么好处呢，一个就是传统的gzip算法的压缩率是很高的，但是大家却不常使用gzip压缩，因为其压缩解压的效率太低，而在使用了intel qat技术之后，就可以将这部分工作放到fpga板上去做，实际上就可以让压缩的吞吐量增加，那我们就可以重新启用gzip的压缩方式，这样就可以在获得更好的压缩率的同时让吞吐量也有明显的提升。
核心技术7: 聚合计算(group by)查询优化
group by的时候会将数据分片，然后每个片单独进行计算，之后在进行聚合，这样可以优化group by场景下的查询，就不详细介绍了。
核心技术8：生态兼容
在这部分主要做与binlog的兼容，做主备之间同步，以及与其他数据源之间打通，通过binlog方式结合精卫以及drc等已有的工具实现多数据源的同步。
技术部分就先分享到这里，那海量数据olap产品histore也就分享到这里。
那么除此之外，我还想借此机会分享另外一个产品，就是高性能时序数据库hitsdb。大家知道，目前在监控以及iot场景下，时序数据库是一个非常热门的话题，在这样的背景下，阿里也推出了一款产品叫做hitsdb，也就是hi-performance time series database，并且在7月31日在阿里云公网上已经开始进行公测了，大家可以在阿里云官网上留意一下。
hitsdb主要解决的是时序场景，那么什么是时序场景呢？实际上就是在时间上分布的一系列数值，其实这个场景也非常多，比如股票、气温变化以及网站的pv、uv、iot的工业传感器数据以及整个服务器监控的数据、硬件指标等等以及车联网等基于时间维度的一系列数值。
时序数据有以下这些特点：
持续产生大量数据，每秒上百万数据点
数据产生率平稳，无明显的波峰谷
近期的数据关注度更高
时间久远的数据，极少被访问，甚至不再需要
数据存在多个维度的标签
展示或使用时往往需要对数据做聚合计算
专用的时序数据库与传统数据库关注点就不太一样了，时序数据库非常关注写性能的优化，hitsdb可以达到每秒千万级别的写入，尤其是这种顺序时间写入，另外一个就是更关注读延迟而非qps，存储的成本可以根据时序场景特定的算法进行优化，比如插值采样等。
hitsdb在时序场景下做了很多的增强，包括了如下内容：
写回方式的内存缓存，写入的数据先在内存中压缩和缓存，积累一段时间后写回磁盘，极大优化了写入性能；
高压缩内存缓存可以保存比较长时间的数据，查询热数据时性能大大高于磁盘，降低了读延迟；
时间序列标签和时间点数据分开存储，减少数据重复，提高存储效率；
在时间序列标签建立倒排索引，极大提升多维度查询的性能；
磁盘数据也使用高压缩存储，大大降低了磁盘的效率；
hitsdb的主要应用场景
hitsdb最主要的应用场景有两个方面，一个是应用性能监控，另外一个就是物联网iot，包括了车联网、智慧交通、智能制造、智慧医疗以及石油化工等领域，其中iot在时序方面要求非常突出。
这里也给大家看两个案例，鉴于篇幅，这里就不一一详述了。
案例1：应用监控&系统监控
案例2：物联网存储
最后，我的邮箱是[email protected]，大家有问题或者有兴趣的话可以发我邮件来讨论一下，同时也热情邀请有识之士加入我们，共同在数据库领域开疆拓土，谢谢大家！