共计 4654 个字符，预计需要花费 12 分钟才能阅读完成。
这篇文章将为大家详细讲解有关 Hologres 是如何完美支撑双 11 智能客服实时数仓的，文章内容质量较高，因此丸趣 TV 小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。
业务背景
从 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 智能客服实时数仓的就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
