怎样查网站备案人的联系方式,简单制作网页,wordpress vieu,官方网站建设需要做哪些东西简介#xff1a;本文将会介绍今年是如何在去年基础上进行实时数仓高可用架构升级#xff0c;并成功大规模落地双11。
作者 | 梅酱 来源 | 阿里技术公众号
一 2021年双11总结
2021年阿里巴巴双11期间#xff0c;由CCOHologres构建的高可用实时数仓经过2年的迭代#xff0…简介本文将会介绍今年是如何在去年基础上进行实时数仓高可用架构升级并成功大规模落地双11。
作者 | 梅酱 来源 | 阿里技术公众号
一 2021年双11总结
2021年阿里巴巴双11期间由CCOHologres构建的高可用实时数仓经过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 size512、buffer size20000、ingore deletetrue。合适的攒批能力选择更加合适的connector的攒批以及server端的攒批交易场景的输入流量和输出流量的峰值差距能够达到30%一定程度上具备削峰填谷的效果。
为什么要采用这样的方案有比较强的场景原因也有比较客观原因造成的方案折中
由于历史原因不同的应用系统可能会依赖不同的数据服务引擎比如某些KV引擎暂时未改造下线为了保证数据一致性我们通过消费Hologres Binlog将某些实时数据向其它KV引擎做实时同步既保证了数据一致性也可以满足不同应用系统的需求。对于交易流量大促峰值往往高于日常非常多为了保证峰值吞吐性能所有引擎按照峰值扩容会有极大的资源浪费通过数仓中转的流量需要具备一定的“消峰填谷”的能力来保证目标引擎不必过度扩容。
五 总结
由CCOHologres构建的高可用实时数仓经过2年的迭代由最初的传统数仓逐渐升级到2021年的高可用实时数仓2020年年双11大促首次采用以Hologres为核心实时数仓方案统一了实时核心数据与部分离线数据的存储。再到2021年通过对实时数仓进行高可用架构升级由链路双写顺利升级为读写分离高可用以及灾备架构并在双11以及双12等核心场景规模应用。实时任务规模由去年的几百增加至上千写入压力增加至1700万每秒数据规模高达几百TB直接服务数十个在线服务场景数百个核心分析业务有效降低了构建实时数仓主备链路的人力以及机器成本减轻了核心业务对于读取稳定的压力完美经受住各大促核心场景的检验实现生产高可用。
原文链接
本文为阿里云原创内容未经允许不得转载。
