阿里云云原生一体化数仓 — 分析服务一体化新能力解读

分析服务一体化一直都是阿里云离线实时一体化数仓的重要能力创新

分析服务一体化需求分析

业务在线化、运营精细化驱动数据实时化

随着互联网的信息，业务对于在线化、运营精细化的需求日益强烈，领导驾驶舱、实时大屏等，起到了越来越重要的作用。对于ToB业务，需要支持数据决策，将数据分析的能力赋予业务，同时要提供实时的精细化运营的能力；对于ToC的业务，核心是需要提高在线转化的效率，那么就产生了实时数据中台，实时用户画像，个性化推荐和实时风控的需求。

批流多路、混合负载的实时数仓场景

这是一个常见的业务需求架构。日志系统的数据和交易系统的数据实时地写入数仓。对于写入的数据，会经过两条链路，一条链路会生成明细数据，由前端BI系统在线Ad-hoc的查询。同时也可以持续的被Dashboad实时的展示出来。同时这些明细数据也会进行实时聚合，形成聚合数据，比如页面流量明细，用户点击明细会被聚合成5分钟的商品浏览记录，7天的浏览记录，30天的流转记录等，这些数据对推荐系统提供在线服务，同时这个过程中还会与维表数据关联，例如用户的特征，商品特征等，关联后进行聚合以服务于在线系统。

传统Lambda架构“纷繁芜杂”，数仓建设之痛

为了满足业务这样的需求，一般会使用Lambda架构搭建数仓，客户实时的写入例如Clickhouse或者Druid这样的OLAP系统，同时对于在线服务，使用Hbase、Redis这样的系统支撑，最后，对于离线服务将其归档到Hive和MaxCompute这类离线数仓中，有时业务需要离在线一体化的分析，会用到Presto来加速查询这些离线数据和在线数据，然后作为统一出口，再提供给报表和Dashboard去使用。上文提到过可能还会有一些实时聚合的需求，以及维表的需求，这些维表往往会存在HBase里面，同时跟交易数据实时聚合后，变成我们提到的如5日的sku的浏览量或者是七日页面流量数据等，再写回HBase里面或者Redis里面，再实时的面对如API的服务，或者手机App这种服务。那自然而然我们会发现在整条链路里面会有很多线，自然会形成一些问题，比如架构复杂，数据同步难，资源消耗大，数据孤岛等等一系列的问题。不难发现，在这种架构中，数据多次被搬迁，导致加工链路长，数据不一致，且随着组件增加，开发难度，架构复杂性，运维难度随之而增加。

每种技术仅解决一种问题

在这个架构下，我们一起来看看每种技术分别解决了什么问题。我们大概可以将这些技术分为三类，这是我们可以想一下整个场景的业务要求，例如适合聚合计算，高吞吐，高可用等。

第一类就是事务数据库，一般事务数据库是按照行存储的，对于交易型的数据有很好的更新能力，但是对于千万级及以上的统计型的查询，消耗时非常大的，所以一般我们也不用事务型数据库做分析。

第二类是OLAP系统，这一类技术会对分析的场景做很多的优化，例如列存的技术，分布式的技术，索引的技术等等，这类的技术查询都很快，但是往往在更新上稍显不足。

第三类在大数据分析场景中也很常见，我们把它们定义为serving的系统，需要提供在线服务，需要有高吞吐和超快的查询相应，但是牺牲了灵活性，例如文档数据库，或者KV查询的数据库，对于Key/Value的查询和更新的效率都非常高。

现有的架构，就是根据业务的特征，将不同的业务拆分到不同的系统存储，数据在各个系统中交换，每一次的数据交换就带来了数据搬迁的成本，数据不一致的可能性和数据开发的复杂性。所以大家自然而然的在很多领域做创新，第一类就是在TP和AP领域做创新，在混合负载的场景下，使用一种技术解决TP和AP的负载，一个系统既支持事务又支持分析，这个状态非常的理想，我们也希望这个系统能够真正的落地，但是我们看来现在这个系统还有些过于理想。因为要支持事务，那么会带来更多的锁的开销，那么在整个并发查询和更新上会有更高的代价，和更多的负载。其实从左侧也可以有一些创新，我们发现左侧最明显的是不支持事务。如果不需要那么多事务，那么不需要这么锁的，那么更有可能支持更高的查询性能、提供更强的写入和更新能力，可能左侧的技术呢，更加能覆盖我们以上提到的分析和服务一体化的场景。

解决问题的方案：分析、服务一体化

Hologres就是符合左侧所说的分析和服务一体化的这么一个产品。一套系统支持多个场景，OLAP的分析可以、点查可以、在线服务也可以，同时支持离线的数据导入和实时的数据更新。真正意义上做到分析服务一体化。

分析服务一体化产品新能力解读

分析服务一体化产品能力需求

其实产品的能力也是和需求相关的，在OLAP分析场景，我们提供了高性能的实时写入与更新能力，写入即可查，使用了列存，压缩，索引等技术，以支撑高性能的查询分析。同时还支持了基于主键的全量更新和局部更新场景，这种能力在实时场景下尤为重要，实时场景下数据通常来在于OLTP的交易系统，事务型数据库中的数据通常都是有主键的，同时主键的设置也能有效的避免脏数据的重复写入，所以现在主键更新能力在实时场景下也越发重要。同时在线上服务场景，我们支持了行存，能够提供上万乃至千万级别的QPS的Key/Value点查能力，能够对于行存的数据支持多副本的高可用能力，保证服务的高可用。由于服务场景是非常敏感的，需要更强的资源隔离保证服务的稳定性，所以我们现在提供了读写分离的架构，避免了高吞吐写入对于读的影响。最后，在数据湖分析的场景中，我们可以对于MaxCompute的数据进行离线加速，无需数据搬迁即可分析MaxCompute中的数据，并且我们能够支持每秒百万行数据的极速同步，减少离线重刷等场景的数据延迟。

Hologres 技术特点

为什么Hologres能做到这些呢，其实没有那么多神秘的地方，还是得益于IT技术的发展，现在网络带宽越来越大，现在存储计算分离的架构，使用了阿里云自研的分布式文件系统盘古，这样就能将整个系统做的更轻，做到多副本和高可用。在发生意外的时候，可以快速的从盘古上将数据加载回来，快速恢复服务。下一步是对于存储的，对于数据更新的场景呢，过去很多的系统都是根据扫描场景设计的，所以对于快速更新不太适合，Hologres底层存储使用了SSD的存储介质，这样的介质随机读写能力更强，这样就让架构设计的时候就可以抛开传统的针对扫描场景的系统设计，有行存有列存，来应对不同的场景。第三个是CPU的多核化，随着现在CPU的核心越来越多，那么提升CPU的利用率，发挥并行计算的能力，就可以更有效的提升性能，Hologres本身使用C++进行开发，使用了全异步的执行引擎，最大程度的利用了多核的性能。

从行存、列存到行列共存

此前的版本中，我们支持行存，数据按行存储，行存更加适合Key/Value点查的场景，用于支撑高QPS的查询场景。同时也支持了列存，列存是将数据按列存储，更加适合OLAP场景。但是现实场景会更加复杂，一张表生成后很难绝对的只支持一种场景，因此我们推出了行列共存表，一张表在后端同时存储一张行存表也存储一张列存表，Hologres内部保证读写一致性，优化器会根据查询的特征，对于适合的场景使用最适合的存储进行回答查询。这样同时兼顾了行存和列存的优势场景。

资源隔离，高可用，统一存储

为了提高可用性，和提供更强的资源隔离的能力，我们现在不仅支持同一实例内的线程级别的资源组隔离，还能支持共享存储的高可用模式，多个实例共享一份存储。对于读写的主实例，提供高性能写入能力，进行加工负载。同时配置多个只读从实例，用于满足不同负载的需求，例如一个只读从实例提供在线的OLAP分析，一个只读从实例支持点查的分析。互相之间互不影响，实现高可用和资源隔离。

分析服务一体产品新能力解读

这里算是一个预告，Hologres在即将发布的1.3版本中，进一步的提供了更多的能力，在数据湖离线加速的场景，支持了读取OSS上的Hudi和Delta格式的数据，同时支持了MaxCompute的Transactional Table的离线加速。数据写入的场景上，进一步扩展了Fixed Plan支持的场景，支持了更新部分列，写入分区父表等场景。在数据查询上我们支持了实时物化视图，用来加速实时聚合查询场景。同时支持了JSONB的列存优化，通过采用列式存储，提高存储效率和查询效率。同时针对很多用户日常使用的分区表场景，支持了自动创建和删除分区子表，便于用户更加便捷的管理分区表。同时还有很多针对查询的优化。最后在生态兼容上，我们支持了Oracle扩展包，兼容了数百个兼容函数。同时PostGIS支持下推到Hologres原生的引擎，提升了查询效率。当然作为一个大数据产品，通常要用于对接BI系统，我们在最新版本对于Tableau的官方测试集的通过率达高了99%以上。

冷热分层，成本优化

针对几个较为重要的功能，在此也做一些展开。在1.3中，为了进一步帮助客户优化成本，提供了冷热分层存储。在业务中，对于分区表中的数据，通常业务会高频访问近期的分区的数据，这样的需要高频访问的数据，使用SSD的存储介质中，以满足高性能访问的需求。随着时间的推移，热数据会渐渐的变为访问频次较低的冷数据，此时系统可以根据用户设置的策略，将系统转到HDD的存储介质中，以优化存储成本。

Fixed Plan场景拓展，提升写入性能

Fixed Plan是Hologres独有的执行引擎优化方式，传统的SQL执行要经过优化器、协调器、查询引擎、存储引擎等多个组件，例如这样一条SQL，如果没有走FixedPlan，那么其执行计划如下所示，整个过程需要经过优化器、协调器、查询引擎、存储引擎等多个组件。而Fixed Plan选择了短路径（Short-Cut）优化执行SQL，绕过了优化器、协调器、部分查询引擎的开销。通过Fixed FrontEnd直接对接Fixed Query Engine，实现SQL执行效率的成倍提升，是支持高吞吐实时写入，高并发查询的关键优化方法。所以如果使用了Fixed Plan，对应的执行计划就如图所示。以下是一个对比，对于数据更新场景，可以看出，无论是行存、列存、行列共存，使用了Fixed Plan之后，RPS有20倍以上的提升。下图橙色为使用了Fixed Plan之后的RPS，黄色为不使用Fixed Plan的RPS。

支持实时物化视图，优化聚合查询场景

在新版本中支持了实时物化视图。物化视图是一个通用的概念，一般的数据库需要定期刷新物化视图，存在一定的数据滞后性。Hologres的物化视图无需手动刷新，数据在写入时即预计算，进入物化视图。例如一个简单的业务场景，某客户有100多家门店，他想实时查看各个门店营业收入情况，以便实时调整经营策略。客户的明细表如下所示，存储了订单的明细数据，其中有订单号，客户号，门店ID，订单日期，订单金额。创建物化视图后，在数据写入明细表后，Hologres会实时的进行物化。当客户写SQL的时候，系统可以自动改写SQL，使SQL支持查询物化视图的数据，以提升查询性能。

JSON列式存储，提升半结构化数据查询和存储效率

最后一个大功能是JSON列式存储，是指使用列存存储JSON的数据，由于列存的压缩效率很高，可以那么有效提升数据的存储效率，节省存储空间。例如一个常见的场景，对于某视频网站厂商，希望查询男性用户的用户数量和平均年龄。他的数据按照如下的JSON类型存储。此时对应的SQL如图所示。此时需要查询结果时，需要扫描所有的JSON数据，把所有数据都读取出来，再汇总，才能得到最终结果。如果开启了列式存储，那么存储模式会如图所示，Hologres会将其按照列的存储模式将其存储到盘古上，此时如果需要查询男性用户的用户数量和平均年龄，今需要扫描2列数据，可以明显的提升查询效率。

典型案例

分析服务一体化架构升级案例

分享一个实际的优化案例：一家头部物流公司的实时数仓架构的升级历程。物流公司对实时的决策和实时的分析有很强的需求，也会有定期营销大促的流量高峰，系统负载的波动比较大，同时还需要直接支持很多2c场景，对服务的响应能力要求很高。在架构升级之前，该企业多采用一些传统的关系型数据库架构，来支撑在线业务的实时查询、实时监控，包括刷新每个包裹的物流状态等场景。

但这样的架构存在实时性不足的问题。订单的数据更新效率低，更新链路也很长，无法满足实时监控的需求，也会降低物流的配送效率。同时多个指标之间往往需要很复杂的关联计算，查询效率比较慢，无法满足业务实时决策的需求。

架构的另一个痛点就是稳定性不足，多个业务高并发查询的时候，整体的延迟会增加，影响业务的稳定性。双11期间需要承担的流量会数倍于日常的流量，原有的系统也无法承受突然的流量增加，会导致需要很多额外的人工运维。

因此我们为用户做了一次实时数仓架构的升级改造，通过Flink+Hologres替代原有的数仓架构。对于高频访问的服务性数据，使用Flink从DataHub中消费数据，把计算结果直接存储在Hologres中；对于一些复杂查询的分析型数据，通过DataWorks读取上游的RDS binlog，在Hologres中进行ODS\DWD\DWS等数据的分层建设，从而将最终的汇总数据对接上层应用，实现了高并发快速查询。

该方案采用了分析服务一体化的混合模式，既发挥了Flink流计算能力进行业务的预加工，也充分利用了Hologres强大的复杂多维查询能力，成功替代了传统的OLAP系统、RDS系统等数据库软件，简化了数据的架构。

升级之后，系统的稳定性得到极大的改善，无论是实时的数据写入还是数据的读取，都体现了极强的稳定性。整个双11期间真正做到了零故障率，满足了实时的业务需求，支撑了比如实时的揽件、库内的操作中转调拨等实时大屏，为运营提供了强有力的实时数据支撑。

整体的实效性也得到了显著提升，为用户带来了良好的物流体验，提升了公司的服务水平。

此外，针对双11的流量高峰期比日常流量高出上千倍，通过Hologres云原生的弹性能力，实现了资源的动态扩缩容，满足了对资源的不同需求，也降低了运维的成本。