Hologres是如何完美支撑双11智能客服实时数仓的？

简介： 本文重点介绍Hologres如何帮助阿里巴巴客户体验部（CCO），构建集实时化、自助化、系统化于一体的用户体验实时数仓，完美助力双11场景，支持上千+服务大屏，削峰30%，节约成本近30%。

刚刚结束的2020天猫双11中，MaxCompute交互式分析（下称Hologres）+实时计算Flink搭建的云原生实时数仓首次在核心数据场景落地，为大数据平台创下一项新纪录。借此之际，我们将陆续推出云原生实时数仓双11实战系列内容，本文重点介绍Hologres如何帮助阿里巴巴客户体验部（CCO），构建集实时化、自助化、系统化于一体的用户体验实时数仓，完美助力双11场景，支持上千+服务大屏，削峰30%，节约成本近30%。

作者：映海（任海峰），阿里巴巴CCO数据应用中台实时技术负责人

客户简介

CCO是Chief Customer Officer的缩写，也是阿里巴巴集团客户体验事业部的简称。在阿里巴巴经济体内，CCO是“客户第一”价值观落地的组织保障，是整个经济体客户体验的神经网络，也是触达消费者和商家的最前线。“成为新商业的服务生态摇篮”，“让体验成为商业的核心竞争力”是我们的愿景。凭借着为消费者、商家和经济体提供专业服务的小二，为平台不断挖掘存量客户价值的体验运营专家，为业务发展提供底层支撑的数据、产品和技术人才，我们成为了互联网行业独一无二的数字化服务体验团队 —— 一支有爱有担当，富有创造力的“阿里柔军”。

业务背景

从2016年开始CCO开始将实时数据应用到业务中，一开始主要支撑 双十一作战室大屏 应用。（注：双11作战室又名光明顶，是阿里巴巴双11期间的总指挥室，其作战大屏承载了全集团双11期间的作战指挥系统，是阿里巴巴作战组织的技术、产品、服务串联起来的“作战指挥图”。）

2017年实时数据应用出现了规模化的上涨，不再局限于大促，在日常的客服小二管理实时监控、对内运营数据产品、线上产品数据应用及算法模型在线应用场景中开始大规模应用。2018年开始整体实时数据任务高保障作业数已经接近400，大促中，双十一指挥室大屏也全面取消了准实时的应用，全面实时化落地，截止到目前，实时作业数已经超过800+。从作业的规模、各类引擎中间件的使用、业务场景的覆盖发展到非常多元化的一个阶段。

整体上CCO在实时数据的应用上呈现出几个特点：

• 数据复杂度高，覆盖了从用户加购、下单、支付到售后退款等全渠道的业务场景及数据依赖。
• 数据量大，从手淘日志（千万/s 峰值）到交易（几百万/s 峰值）到咨询（几十万/s 峰值）。
• 应用场景丰富，实时监控大屏，实时交互式分析数据产品，To B/C类的线上应用。

伴随着场景的丰富、数据量的剧增以及业务端不断变化的查询要求等，既要快速响应业务需求提供高可靠和低延时的数据服务，又要保证系统不断的平稳运行，其背后的技术系统不断受到挑战。

实时技术架构演进历程

CCO的实时架构演进分为三个阶段： 数据库阶段、传统数据仓库阶段、实时数仓阶段 。

1）数据库阶段

第一个阶段为数据库阶段，采用典型的Lambda架构，数据从采集->加工->服务， 根据业务场景烟囱化建设，在数据架构上不做分层，以任务为单位来支撑对应的应用场景 ，将数据全部预处理完毕，存储到OLTP和KV引擎，直接通过Point Query提供对外服务。

在数据处理层，通过Flink多流Join，通过Hbase做维表关联，将流式数据预处理到指定粒度，持久化到数据库中并提供对应服务。

在场景少、任务少的情况下，这种end to end的建设方式，既灵活又节省成本，并且能提供较高QPS低RT的服务能力。

但随着业务场景的复杂度增加，运维开发成本越来越大，全部采用预处理并且每个开发同学都需要从源头end to end加工的方式已经不能适应业务的变化。

2）传统数据仓库阶段

随着实时数据应用的规格上线，以及数据库阶段的明显痛点，发展到了传统数据仓库阶段。传统数据仓库阶段架构的优化点如下：

• 引入OLAP引擎： 小数据量的明细、轻度汇总等数据统一存储到AnalyticDB，支持较高QPS的OLAP Query。
• 数据模型及任务加工分层： 在DWD层按照主题将不同数据源数据整合，并且输出到Lindorm，然后通过Hlog订阅，触发流任务反查事实表，将宽表字段对齐输出到TT，做为DWD中间层存储。构建可复用的DWS层，将常用维度及指标按照主题建模，供下游复用，减少烟囱化。

通过引入数据仓库的分层架构以及MPP的技术，增强了整个实时数据架构的灵活性和数据的复用性，但随着数据体量和规模的增加，我们发现， 任务量在规模化膨胀，引擎成本在逐年增加 ，我们构建的数仓中的数据并没有真正意义上流转起来， 由于存储的多样，服务的多样，造成不可避免的在不同的任务和引擎中冗余大量的烟囱化的业务逻辑和数据 。

为了解决业务对稳定性SLA不同级别的要求，我们将KV引擎和OLAP引擎按照业务保障等级做了实例拆分和资源隔离，在保障提升的同时，我们不得不将已经加工过的数据，重复加工，并且写入到不同的实例和引擎中去，这就使得数据有非常多的冗余，且多个系统也带来高额的运维开发成本。

3）实时数仓阶段

传统数据仓库阶段，随着任务规模的持续增长，数据开发同学需要维护多个任务作业，同时业务应用对实时数据的诉求也越来越强，于是，一系列的数据开发问题逐渐呈现，例如开发效率如何提升，数据复用性如何提高，数据成本如何降低？这也就使得我们不得不对数据仓库阶段的技术架构不断优化和演进，随之而来的就是第3阶段--实时数仓阶段。

首先我们来分析一下，传统数据仓库演进为实时数仓最主要的困难点：

• 任务重复建设： 常用的做法就是按照业务场景分拆实例，按照保障等级分拆实例，按照不同服务形式路由到不同的引擎，比如KV/OLAP。任务不得不重复建设，需要在重复建设和稳定性上做出权衡。在实践中，我们往往选择了第二或者第三种方式来优先保障稳定性，由于在同一任务中增加多个SINK到不同实例，任何一个实例有问题，都会造成整个任务背压或者failover，会影响到其它实例的稳定性。

• 数据存储冗余： 实际场景中，我们需要提供Point Query，Adhoc Query，Olap Query等多种服务形式，我们需要至少在KV存储和MPP存储中存放两份，造成非常多不必要存储，存储成本也只增不降。
• 元数据管理： 在传统的KV引擎上，由于schema free的特点，我们无法友好并且高效的管理我们的表及字段的元数据信息。
• 加工链路复杂： 其中两个典型场景是，一是对于dwd层宽表的字段对齐问题，目前只能通过Lindorm的KV特性，可以多个不同的流根据同一PK进行更新，然后通过Hlog捕捉到对应PK的每次变化，然后触发流对Lindorm宽表的反查，再将整行记录下发。二是写入到MPP引擎的数据，往往由于MPP引擎不支持写入数据的重新订阅消费，造成必须在上游任务增加SINK，写入到消息中间件，然后才能支持二次消费，一定程度上也增加了链路的复杂度。

实时数仓架构

鉴于以上建设实时数仓的困难点和迫切性，我们也在一直调研和探索究竟有什么产品能够有能力解决这些问题。也是某个契机了解到了Hologres，Hologres的定位是服务和分析一体化，这一点也很符合我们后期的技术规划方向。通过跟团队的深入沟通以及前期产品的深度测试，最终选定了Hologres来作为实时数仓的主要载体。 为什么要选择Hologres呢？，Hologres有哪些优秀的能力可以落地在CCO的场景中呢？

• 支持行存列存，HSAP的混合服务能力： 针对现有的Point Query的场景，可以采取行存方式存储，针对典型的OLAP场景，可以采取列存方式存储。
• 高吞吐的实时写入： 经过实际测试，对于行存的写入，目前可以满足我们业务上千万/s的吞吐要求，在列存的OLAP场景上，可以轻松应对我们几十万/s的高聚合数据写入要求。
• 行存的日志订阅以及维表关联能力： 我们写入Hologres行存表的数据，可以通过Binlog订阅，通过Hologres connector，轻松应用Flink的任务开发中，将公共层明细数据有选择的进行二次计算，并写入回Hologres，提供给不同的应用场景，一定程度上解决了Hologres引擎和Blink引擎计算的算力平衡和高QPS的相应问题。
• 云原生： 支持弹性扩缩容和高度可扩展性，今年大促我们在几分钟内完成平时几倍资源的扩容，可以轻松应对日常和大促的弹性业务需求。

下面是由Hologres组成的现CCO实时数仓架构：

• 统一存储： 需要Point Query的表在Hologres中使用行存模式，并且存放公共明细层、公共轻度汇总层，需要OLAP查询的表使用列存模式，存放于应用层明细、应用层汇总。
• 简化实时链路： Hologres行存集群存放的公共层数据，通过Binlog订阅，供应用层做二次消费，替代Lindorm订阅日志，再通过额外任务反查获取整行记录的链路。
• 统一服务： Point Query路由到行存表，Olap Query路由到列存表。
• 流批一体： 小型维表的加速不再通过异构数据导入的方式加载，而是直接在Hologres中创建外表，通过外表与内表的联邦查询（join）能力，直接为线上OLAP应用场景提供服务。

业务价值

从开始接触Hologres，到Hologres真正落地CCO的具体场景，包括双11光明顶指挥大屏，以及日常运营等场景，Hologres带来的显著业务价值主要如下：

1）实时架构升级

• 实时数据闭环流转 截止当前60%的实时作业运行在新实时数仓架构上，公共层明细的维护全部切换为通过Hologres Binlog订阅来消费，今年为了维护系统稳定性，我们仍然把部分核心业务的Point Query查询放在Lindorm，并通过Flink任务消费Binlog来保持两边引擎的实时同步，在压测中通过Hologres connector目前可以支持到上千万/s的单表写入和读取，已经超出了我们业务的诉求。
• 大促削峰降成本 今年大促中，实际效果上，交易峰值在几百多万每秒写入到行存表后，我们借助Hologres Server端针对同一批次同一PK多次变化的merge能力和Hologres Connector的攒批能力，完成写入和写出， 30%的削峰效果，降低了服务器成本 。

2）自助分析快速响应

• FBI+Vshow+Hologres 自助实时大屏 我们将现有公共层明细数据实时同步到Hologres列存表，通过业务小二在FBI自定义大屏配置，实现了实时数据业务自助分析的能力，解决了每年大促遇到的业务诉求和数据开发资源的Gap。
• 灵活的索引机制 根据场景，灵活定制索引，通过distribution key、clustering key、segment key可针对排序、检索、聚合等多维分析场景做灵活定制，大大提升了查询性能
• table group和shard count优化 按照业务场景将需要关联的表放入同一个table group，通过local join减少shuffle的机制，可极大提升OLAP query的响应时间。创建哨兵表，方便开发同学可以直接对新增表做新增/修改/删除。实践中，尽量将表放入尽可能小的shard count的table group，可极大减少每次SQL启动的开销，减少响应时间，我们实际优化中，一个针对小二的聚合操作，由秒级优化到毫秒级。

3）服务资源系统化

服务资源现场管理上千+大屏，帮助服务资源现场合理调度人力、预测排班，实时监控预警，帮助几十+SP服务商，多家政企和数十+校企等大幅提升服务资源的调度能力，让上万+小二能快速响应商家和消费者的服务请求。

4）体验引擎智能化

基于CCO业务数据+消费者全渠道语聊数据+行为操作数据，围绕逆向全链路交易场景，买卖家联合、结构化和非结构化交叉，深度洞察问题根因，并快速解决问题，以往从发现问题到去查问题以及解决问题，需要耗费大量的人力、精力以及物力，而现在体验引擎的智能化，使得问题能够被快速定位，这样也就有更多的时间和精力去解决问题，往往几分钟就能得到解决，提升了整个流程的用户体验。

5）整体成本节省近30%

对于业务来说，成本也是一个重要的考虑因素，尤其是在数据量越来越大的情况下。替换Hologres之后，在整个双11期间， 整体的成本预估节省几百万，相比之前节省30%左右 。目前CCO还处于迁移过度阶段，为了保证系统的整体稳定性，部分业务还没有完全替换，后续也会开始推动整体的迁移工作，预计整体迁移完毕后预计可以节省更多的资源。

未来展望

未来我们希望可以继续在流批一体、HSAP上做更深入的探索，希望能与Hologres保持持续的共建，能够推动引擎发展也能更好的服务于业务发展。

• 服务SLA： 希望Hologres可以有主备机制，在存储计算分离的架构上，计算引擎可以主备，存储可以在不同的Pangu集群存在多副本的能力，保证业务在写入和读取上，任何主链路故障的情况下，可以无感切换到备实例。
• 实例间实时同步： 在实践中，由于不同业务场景的不同保障等级，拆分实例可能将是未来较长时间内的一个可行的解决方案，当前我们是通过Flink任务将数据做实例间同步，实例间互相实时同步数据的能力可以极大的降低业务开发成本和维护成本。
• 资源隔离： 真正意义的行/列混存，可以在同一个表上支撑Point Query和Olap Query，独立的资源分配，又互不影响。
• 弹性变更： table group的shard count可以动态扩/缩，能够灵活应对峰值及日常的业务需要。
• 二级索引： 对于Point Query支持海量数据的非PK point query，同时可应用于流计算中，可以极大降低模型建设的冗余度。

版权声明： 本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。