作者 | 梅酱
来源 | 阿里技术公众号

一 2021年双11总结

2021年阿里巴巴双11期间，由CCO+Hologres构建的高可用实时数仓经过2年的迭代，支撑了阿里集团内部从智能到人工，从应用到数据产品，从B/C到内部运营等数10个核心应用场景，并在双11实时大屏、实时监控大盘等多个应用场景全面启动新一代高可用及灾备方案，在Hologres主集群写入峰值达450万+每秒的情况下，还能真正做到数据“0”延迟，服务“0”延迟。

相比2020年，今年通过优化实时写入链路，在Binlog消费和维表Join流量翻倍的情况下，同等资源下Hologres Binlog读取峰值达1700万+每秒，整体水位平稳保持正常高吞吐。同时今年首次在大促核心场景上线新一代高可用及灾备方案，取消去年使用的双实例+双链路的高成本方式，极大降低人力开发、压测以及运维成本，降低无效双链路任务上百个，减少人力投入50%，节约上千cu计算资源。

下面将会介绍今年是如何在去年基础上进行实时数仓高可用架构升级，并成功大规模落地双11。

去年精彩回顾：Hologres是如何完美支撑双11智能客服实时数仓的？

二 客户简介

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

三 业务挑战

CCO通过与Hologres高度共建，构建了集实时化、自助化、系统化于一体的用户体验实时数仓，完美助力2020年双11场景，支持上千+服务大屏，削峰30%，节约成本近30%。

但是在2021年，任务规模也相比2020年增长1.5倍，实时数据膨胀2倍以上，如何有效管理数据和资源成为了越来越关键的问题，同时2021年大促期间将会面临更加高并发高吞吐的流量，如何保障实时数仓的高可用，以及保持稳定性和成本的平衡，是今年构建实时数仓的核心挑战。

2020年双11，为了应对大促的流量洪峰，在高可用方面，我们花费1个月，投入巨大人力成本，来构建双链路+双实例的高可用方案，以下为去年双11的实时数仓架构。这个架构虽然支撑了去年双11等各种大促流量洪峰，但是在今年更为复杂的环境和外部更多挑战的情况下，也存在着一定的痛点，主要有以下几个：

• 浪费资源：数据同时写入多个实例，满足主备要求，既浪费了计算资源，也浪费了存储资源，同时也额外增加了业务的开发成本和运维成本。
• 无法高效保证主备链路数据一致性：在数据双写时，当某个实例因为因为种种原因出现延迟时，无法与另外一个实例保持完整的数据一致性，无法做到真正的高可靠。
• 运维复杂：双链路意味着需要采用两套架构，虽然搭建逻辑以及开发逻辑都一致，但是当对主链路进行运维发布（如升降配，bug fixed等）或者逻辑修改时，牵一发而动全身，还需要同时维护备链路，操作比较复杂，运维链路长。

为了解决2020年遗留的问题，2021年双11对实时数仓进行升级，采用新一代高可用及灾备方案，在对单链路进行充分的压测评估以及长应急预案外，实例内使用多副本+共享存储的方式，除了在出现未知问题时可以快速切换副本来提高业务的可用性外，还极大的降低了构建双链路的成本。同时在面对大促和日常流量时，可以快速缩容，提高架构的整体灵活性，在成本和效率上相比去年更加的平衡，实现生成高可用，成功大规模落地双11。

下面将会具体介绍今年的高可用及灾备方案。

四 业务方案

整体数据链路同2020年保持一致：数据源数据通过Flink ETL处理后实时写入Hologres，行存表用于在线服务场景，列存表用于复杂多维分析场景，再由Hologres通过通过不同的场景直接对接上层应用。
在去年方案的基础上，对架构进行升级，对Hologres服务和分析场景进行集群隔离以及高可用部署，组成当下实时数仓3.0架构。
注：部分不核心业务由于历史原因暂时无法下线，所以由Hologres同步至某DB引擎提供服务。

升级1：多种隔离方式满足生产高可用

在高可用部分，今年的方案升级主要如下：
1）服务和分析集群隔离
采用行存和列存两个实例集群，有效隔离行存服务和列存分析场景下对于QPS/RT不同要求的能力。

• 行存集群承载核心实时数据，主要承担与Flink高频的交互（数据写入、Binlog消费、维表关联），同时提供比如数据特征、用户画像等在线点查服务，实现在线推荐。
• 列存集群主要用于复杂多维分析，由Flink实时写入，应用于实时数据大屏、实时监控等一系列核心场景

2）分析场景读写分离高可用和灾备
对于大促期间高保的列存分析核心场景，启用多实例共享存储读写分离高可用和非共享存储灾备的能力建设。

• 读写分离高可用：多个实例共享存储，主实例具备完整能力，数据可读可写，权限、系统参数可配置，而子实例处于只读状态，所有的变更都通过主实例完成，实例之间共享一份数据存储，实例间数据异步实时同步。这个方案实现了完整的读写分离功能，保障不同业务场景的SLA，在高吞吐的数据写入和复杂的架构作业、OLAP、AdHoc查询、线上服务等场景中，负载之间物理上完全隔离，不会因写入产生查询的抖动。同时当某个子实例出现问题时，可以在其余子实例间紧急切换，也不会带来数据一致性的问题。
• 灾备：在多机房部署多个实例，实例间不共享存储，数据通过实例间进行实时同步，数据冗余在多个文件系统，在集群出现问题时，可做紧急切换。

日增量数据在数十TB的规模下，无论是共享存储的读写分离高可用还是非共享存储的灾备模式，同机房/跨机房实时数据同步延迟都低于10ms，完全满足我们对于大促高保场景的数据时效性要求。

升级2：实时链路优化提高吞吐

对于核心场景，在大促流量洪峰下查询需要保持高性能，写入也同样需要保持高吞吐，才能不影响业务的下一步决策，例如每年双11交易峰值，对写入和Binlog消费的压力都比较大，因此实时链路的优化与保障需要格外处理。今年针对大流量场景的任务调优，在实时链路上我们针对并发、攒批、connector等都做了相应的优化，保证了高吞吐写入，降级写入延迟，满足不同业务系统的需求。

• 优化写入connector的带宽策略，避开VIP带宽由5GB/s到20GB/s的限制。
• 大流量的行存表扩容shard数，比如交易表，提高写入并发能力。
• 大流量的任务选择合适的并发，比如交易表我们采用的参数是Binglog并发：512、sink并发：512、batch size：512、buffer size：20000、ingore delete：true。
• 合适的攒批能力：选择更加合适的connector的攒批以及server端的攒批，交易场景的输入流量和输出流量的峰值差距能够达到30%，一定程度上具备削峰填谷的效果。

为什么要采用这样的方案，有比较强的场景原因也有比较客观原因造成的方案折中：

• 由于历史原因，不同的应用系统可能会依赖不同的数据服务引擎，比如某些KV引擎暂时未改造下线，为了保证数据一致性，我们通过消费Hologres Binlog，将某些实时数据向其它KV引擎做实时同步，既保证了数据一致性，也可以满足不同应用系统的需求。
• 对于交易流量，大促峰值往往高于日常非常多，为了保证峰值吞吐性能，所有引擎按照峰值扩容，会有极大的资源浪费，通过数仓中转的流量需要具备一定的“消峰填谷”的能力，来保证目标引擎不必过度扩容。

五 总结

由CCO+Hologres构建的高可用实时数仓经过2年的迭代，由最初的传统数仓逐渐升级到2021年的高可用实时数仓：2020年年双11大促首次采用以Hologres为核心实时数仓方案，统一了实时核心数据与部分离线数据的存储。再到2021年通过对实时数仓进行高可用架构升级，由链路双写顺利升级为读写分离高可用以及灾备架构，并在双11以及双12等核心场景规模应用。实时任务规模由去年的几百+增加至上千+，写入压力增加至1700万+每秒，数据规模高达几百TB，直接服务数十个在线服务场景，数百个核心分析业务，有效降低了构建实时数仓主备链路的人力以及机器成本，减轻了核心业务对于读取稳定的压力，完美经受住各大促核心场景的检验，实现生产高可用，