作者：刘一鸣（合一）阿里云高级产品专家，实时数仓Hologres产品负责人

分析服务一体化是阿里云一体化数仓的一个重要能力创新。

通过数据做决策的过程就是分析，常见的有多维分析、探索式分析、交互式分析、AD Hoc分析等，通常用在内部的经营报表，领导驾驶舱、指标库平台等领域，擅长处理复杂多变灵活的查询；而服务通常是TP领域的说法，负责支撑在线业务的高性能、高QPS的数据读写需求，对SLA、可用性、延时都有很高的要求。但它与TP也是有所区别的，它对事务的要求弱于对于吞吐和系统的要求，通常服务于2c场景，包括在线推荐、在线营销、风控等。

分析和服务两个场景底层数据来源是统一的，甚至是互相支撑的，服务的数据会用来做二次的分析，分析的数据也可以用来做在线的服务。通过分析和服务一体化架构可以简化系统之间的数据交换，提升开发效率。

合一1.png

什么是一个有效率、有质量、可靠的实时数仓？在加工领域，实时数仓的趋势是越来越敏捷化，包含加工手段的轻量化、实时化、数据分层的弱化；在服务领域，越来越多的大数据团队直接服务公司的在线业务，从成本中心转化为盈利中心，保障在线业务的稳定和高效率；在架构领域，通过分析服务的一体化的融合，提升开发效率，降低运维成本。

针对各领域的趋势变化，我们做了一系列能力的创新。

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

传统上搭建一个合理的大数据实时数仓系统是个复杂的工程，基本采用Lambda架构，有实时的加工层、离线的加工层，甚至还有一些近实时的处理层。数据存储会根据不同的访问特征，分为离线存储和在线存储，在线部分又会细分为OLAP系统以及KV系统，分别提供灵活分析的能力和在线高性能点查。在应用侧，以API方式访问的多是在线系统，以SQL方式访问的多是分析系统，不同的系统分别对接不同的存储引擎。

合一2.png

上述架构在业务变化少、数据质量高的时候是有效的，但现实情况往往比较复杂，业务的变化会越来越敏捷，数据的质量更是无法保障。数据结构的日常调整、数据质量的修正和重刷仍旧是一项高频且耗时的工作。而且架构内存在多套存储，数据的反复同步会导致业务的敏捷性变得无法实现，IT工程师需要花费大量的时间在数据的排查修正上。

总而言之，架构的孤岛必然会导致数据同步难、资源消耗大、开发成本高，招聘人才也更难。

数据加工敏捷化

解决加工敏捷化的核心有两点：一是简化状态存储，减少数据冗余，使得数据开发修正只需要在一份数据上进行；二是加工链路轻量化。

合一3.png

在状态存储上，Hologres提供了良好的实时批量写入与更新的能力，无论是单条的灵活更新，还是上亿条批量的回刷场景都可以很好地支撑。因此，可以基于Hologres构建数据的统一状态层，减少数据搬迁。

在加工上，分为公共层加工与应用层加工。公共层加工采用Flink+Hologres Binlog的方式，实现ODS到DWD到DWS全链路的事件实时驱动开发，实现数据写入及加工；在应用层，通过封装业务逻辑的方式，减少中间表的管理，通过Hologres优秀的分布式查询能力，为业务层提供良好的分析灵活性，将灵活性从工程师交还给分析师。

数据服务在线化

在当前的大环境下，数据从原先的针对2B的对内决策场景，逐步拓展到支撑2C的在线业务场景，支持实时画像、实时个性化推荐、实时风控等。通过数据实现在线转化的提效，对系统执行的效率和稳定性都提出了更高的要求。也让过去的分析系统从一个相对边缘的系统演进为一个mission-critical的关键业务系统，需要数据平台具备更高的可用性、更高的并发能力、低延时低抖动，以及支持云原生的弹性扩展能力、支持服务的热升级热扩容，还要具备更完善的可观测性和运维能力。

合一4.png

针对上述需求，Hologres在存储引擎、执行引擎、运行能力等方面做了大量的创新。

在线化驱动可靠性设计

在原有行存、列存基础上支持了行列共存的结构，让一张表兼具OLAP和Key-Value两种优势场景，同时引入了shard级多副本的能力，通过增加副本数，实现QPS线性增长。此外，通过组合行列共存和shard集多副本两个能力，支撑了一个新的场景——非主键点查能力，广泛应用于订单检索的场景。

合一5.png

此外，系统不可避免地会有很多运维升级的需求，Hologres引入了热升级能力，保持升级过程中服务不中断，降低系统运维对业务的影响。同时也通过对元数据物理备份以及数据文件lazy open等能力的创新，优化了故障恢复的速度。

实际业务验证表明，优化后有了10倍以上的恢复速度的提升，实现了分钟级的故障自动恢复，将故障的影响降到了最低。

分析服务一体化简化数据服务出口（HybridServing/AnalyticalProcessing,HSAP)

分析服务一体化是简化数据平台、统一数据服务出口的重要趋势，它也是存储查询引擎的重要能力创新。在一个架构内支撑了两种典型的数据场景，既可以支持复杂的OLAP分析，也可以满足在线服务的高QPS、低延时的需求；业务上为用户创建了统一的数据服务出口，实现了业务的敏捷响应；支撑数据自主分析，避免了数据孤岛，也简化了运维。

合一6.png

但上述需求对技术架构挑战很高，因此Hologres也在存储上针对不同的场景设计了行存列存，行存支撑了在线的高QPS点查，列存支撑了OLAP场景，在计算上也实现了在数据共享基础之上支撑更细粒度的负载隔离能力。

资源隔离，高可用，无限弹性，统一存储

Hologres具备基于共享存储的多实例、高可用互助模式。用户可以创建多个实例，这些实例代表了不同的计算资源，但所有实例共享一份数据，其中一个实例是主实例，支持数据的读写操作，其他实例为只读的子实例。不同实例之间数据的内存状态是毫秒级、实时的同步，物理上只存了一份数据。此方案中，数据是统一的，权限配置也是统一的，但计算负债通过物理资源区分做到了百分百的隔离，读写请求也不会增强资源，同时也体现了更好的故障隔离能力。

1个主实例目前最多支持挂载4个子实例，如果是在同1个region内部署，所有数据共享存储；如果是不同的region部署，则数据需要复制多份。

合一7.png

此方案在21年双11大量场景下被反复验证，可靠性非常高。通常建议一个主实例作为数据的写入和加工实例，其他子实例作为OLAP经营分析或做对外的数据服务，这样即可根据不同的场景和不同计算力的需求，分配不同的计算规格。

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

分享一个实际的优化案例——一家头部物流公司的实时数仓架构的升级历程。物流公司对实时的决策和实时的分析有很强的需求，也会有定期营销大促的流量高峰，系统负载的波动比较大，同时还需要直接支持很多2c场景，对服务的响应能力要求很高。

合一8.png

在架构升级之前，该企业多采用一些传统的关系型数据库架构，来支撑在线业务的实时查询、实时监控，包括刷新每个包裹的物流状态等场景。

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

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

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