也可在PC端打开 https://developer.aliyun.com/topic/download?id=961 下载
一、背景介绍
从技术影响力的角度来说，Github Star排名前5的系统也是目前市面上比较流行的开源OLAP系统，它们的开源时间以及产品的定位各不相同，我们将会选取排名前3的系统来与Hologres做深度的对比。
另外再从业务的视角来看一下大数据架构中OLAP系统的一个定位和功能，以及它在业务系统中的作用，可以看到，在整个大数据架构中，为了解决不同的问题，需要用到不同的系统，在大数据架构中，OLAP系统百家争鸣、万花齐放。
二、开源系统对比
将会从以下几个方面来深度对比Hologres和开源OLAP系统。
1）存储计算角度
在存储方面，Hologres支持毫秒级的写入可见性，Druid和ClickHouse支持的是秒级。同时Hologres支持写入更新。
在计算方面，Hologres同Druid和ClickHouse都采用了向量化/SIMD执行器，值得一体的是，因Hologres底层技术原理可以支持联邦查询和高QPS的点查，这些都是Druid和ClickHouse无法做到的。
2）SQL、高级功能和生态
在SQL方面，Hologres是兼容Postgres语法，开箱即可用，学习成本低，而Druid和ClickHouse的语法都是较复杂，难以上手。并且对于update、delete、join等，Druid和ClickHouse的支持都是比较有限。
在高级功能上，Hologres支持向量检索、空间数据等，支持更加丰富的业务场景，并且对于安全管控方面，Hologres也有着非常严苛的权限管理，例如RAM、IP白名单等。
在生态上Hologres支持会更加丰富，Hologres提供JDBC接口，且能通过Flink或者DataX、StreamX写入，实现多种异构数据源轻松导入Hologres。
三、迁移指南
对比完主流的开源OLAP引擎之后，肯定就会有人问，要是想把OLAP引擎迁移到Hologres，应该怎么做呢？它们的不同点在哪里呢？下面将会一一讲述。
1）Presto迁移
- Presto简介及应用场景
Presto是Facebook推出的一个分布式的SQL查询引擎，基于内存的并行计算，它可以提供比较快速的一个交互式查询能力。应用场景有离线加速，联邦查询，数据湖，以及实时数仓。
从Presto迁移到Hologres后，基本上功能可以无缝的得到支持，而且Presto不支持实时数仓，而Hologres支持实时数仓，提供写入和更新能力，并支持高QPS的查询能力。
- 迁移方案
可以分别从数据模型，数据类型，SQL，数据接入，BI生态来看。数据模型上2者概念类似，只不过Presto的Catalog需要变成Hologres的Database。数据类似方面Hologres同Presto一致都支持基本以及复杂类型，无需做修改。SQL层面，2者都是支持ANSI SQL，学习成本也比较低。对于数据接入和生态而言，Hologres同Presto都提供JDBC接口，无需更换工具，只需要更换对应的连接信息就能立即使用
总结来看，迁移的成本是非常低的，基本上可以做到无缝的迁移。
2）Druid迁移
- Druid简介及应用场景
Druid自带存储引擎，支持实时数据，并提供亚秒级查询的OLAP引擎。
Druid的适用场景有：
- 时序组织数据（点击，曝光，监控）
- 数据质量要求不高（有可能重复/丢失）
- 海量append only数据 (不支持更新）
- 单表聚合类查询
Druid不适用的场景有：
- 高QPS明细场景
- 有一致性要求的场景
- 需要更新的场景
- 需要join的场景
从Druid迁移到Hologres后，可以支持一些原来Druid不适用的场景
- 迁移方案
下面来看实践，首先是数据模型的迁移。Druid所有数据都存储在dataSource中，dataSource类似于Hologres的表。Druid通过json的方式来描述一个dataSource的schema，dataSource schema与Hologres的概念映射，如下图所示。
- 迁移示例
下图是一个具体的从Druid迁移Hologres的示例。
就DDL而言，如上面所诉，Datasorce修改为table，其余的参数都配置为Hologres的字段信息即可。
再来看Query相关的Query迁移，Druid当前版本支持两种查询方式：SQL查询和Native查询，SQL查询和Hologres的SQL查询方式类似，在此主要介绍Native query到Hologres的迁移方式。
Scan查询修改为Hologres中的Select 字段即可。
TOPN查询修改为Sum和Group by查询即可。
Timeseries查询修改where条件的sum查询。
GroupBy查询在Hologres中也是Group by，无需做大幅度的修改。
3） ClickHouse迁移
- ClickHouse简介及应用场景
ClickHouse自带存储引擎，支持实时数据，并提供亚秒级查询，C++实现的OLAP分布式列式数据库。
适用场景有：
- 海量明细数据存储
- 单表聚合类查询
- 写入可见性/一致性要求不高
不适用的场景有：
- 高QPS查询
- 高QPS更新
- 需要join的场景
- 迁移方案
常见实时数仓写入链路如下图所示，通过Flink将实时日志数据写入到ClickHouse中。这里将会设计到两种数据迁移。
首先是增量数据迁移，Hologres紧密结合Flink生态，如果客户之前是通过Flink来向ClickHouse写入实时数据，那么通过Hologres Connector就能可以方便地将数据导入Hologres，将增量数据迁移过来。
然后是存量数据迁移，由于DataX等插件，暂不支持ClickHouse Reader。 如果已经在ClickHouse中存储了存量数据，需要搬迁至Hologres，目前可以用ClickHouse -> COPY OUT -> Data File -> COPY IN -> Hologres的链路，需要确定好字符集、分隔符和NULL标记等规范就能迁移。
迁移过程中，数据模型的对应关系，如下图所示。
- 迁移示例
迁移的DDL示例如下图所示，建表语句可以保持一致，但是索引的创建需要改成call set语句。
对于一些典型查询Query，只需要修改部分的语法即可达到更好的效果。
四、典型案例分享
从Hologres诞生到赋能阿里巴巴集团内大多数核心业务再到云上商业化，已经沉淀无数开源OLAP成功迁移Hologres的案例。下面将会介绍典型的成功迁移案例。
1）搜索业务
在最开始的时候，阿里巴巴的搜索推荐的业务，用到的是一个非常复杂的架构，如下图所示。我们把这个业务架构仔细拆开来看，它具有需要系统具备多种能力：第一，KVStore：Redis/Mysql/Hbase/Cassandra 存储能力。第二，交互式计算能力： Presto/Drill 计算能力。第三， 实时数仓：Clickhouse/Druid存储+计算。
正是因为这样一些复杂的业务架构，我们做了一个HSAP的系统，进行了业务的架构升级，把多种能力有机统一于一个引擎。这样，用户只需要通过Hologres就可以解决问题，让用户的学习成本降低非常多，不需要再去学习多个系统。 升级后的架构：
下图是具体的迁移表现。迁移到Hologres后，资源节省60%。平均查询性能大幅提升，开发周期显著加快。
2）某社交网站替换ClickHouse
在阿里云上也有成功的迁移案例，例如某个社交网站的客户成功从ClickHouse迁移到Hologres，资源也节省了几百core，原来只能存储7天的数据，现在能无限制存储并支持7-15天的明细数据复杂查询，相比之前的实时写入QPS也有大幅提升。
3）某游戏客户替换Redis
下面是公共云上某个游戏客户替换Redis后的收益，首先是成本下降了50%，也支持了复杂查询，学习成本也降低了，无需特别维护，就能开箱即用。
五、总结
Hologres作为HSAP服务分析一体化的最佳落地实践，。支持联邦查询，通过Hologres完全无缝的加速离线场景。同时也能解决AP常见的能力，同时比AP系统的性能更好。并且还能解决HBASE这种点查系统的能力，可以解决实时推荐的一些场景的能力。
在整个大数据架构中，通过Hologres完成了非常好的业务架构的整合，让业务能力得到非常大的扩张，用户可以非常方便的使用一套系统来完成各种各样的业务。
关键词：Hologres实时数仓，开源OLAP系统，HSAP升级实践，大数据