简介：本文将会介绍往年是如何在去年根底上进行实时数仓高可用架构降级，并胜利大规模落地双 11。
作者 | 梅酱
起源 | 阿里技术公众号
一 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，间接服务数十个在线服务场景，数百个外围剖析业务，无效升高了构建实时数仓主备链路的人力以及机器老本，加重了外围业务对于读取稳固的压力，完满禁受住各大促外围场景的测验，实现生产高可用。
原文链接
本文为阿里云原创内容，未经容许不得转载。