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

这篇文章将为大家详细讲解有关Hologres是如何完美支撑双11智能客服实时数仓的，文章内容质量较高，因此小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。

业务背景

从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还处于迁移过度阶段，为了保证系统的整体稳定性，部分业务还没有完全替换，后续也会开始推动整体的迁移工作，预计整体迁移完毕后预计可以节省更多的资源。

关于Hologres是如何完美支撑双11智能客服实时数仓的就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。