共计 5570 个字符，预计需要花费 14 分钟才能阅读完成。
简介： 本文重点介绍 Hologres 如何帮忙阿里巴巴客户体验部（CCO），构建集实时化、自助化、系统化于一体的用户体验实时数仓，完满助力双 11 场景，反对上千 + 服务大屏，削峰 30%，节约老本近 30%。
刚刚完结的 2020 天猫双 11 中，MaxCompute 交互式剖析（下称 Hologres）+ 实时计算 Flink 搭建的云原生实时数仓首次在外围数据场景落地，为大数据平台创下一项新纪录。借此之际，咱们将陆续推出云原生实时数仓双 11 实战系列内容，本文重点介绍 Hologres 如何帮忙阿里巴巴客户体验部（CCO），构建集实时化、自助化、系统化于一体的用户体验实时数仓，完满助力双 11 场景，反对上千 + 服务大屏，削峰 30%，节约老本近 30%。
作者：映海（任海峰），阿里巴巴 CCO 数据利用中台实时技术负责人
客户简介
CCO 是 Chief Customer Officer 的缩写，也是阿里巴巴团体客户体验事业部的简称。在阿里巴巴经济体内，CCO 是“客户第一”价值观落地的组织保障，是整个经济体客户体验的神经网络，也是触达消费者和商家的最火线。“成为新商业的服务生态摇篮”，“让体验成为商业的外围竞争力”是咱们的愿景。凭借着为消费者、商家和经济体提供业余服务的小二，为平台一直开掘存量客户价值的体验经营专家，为业务倒退提供底层撑持的数据、产品和技术人才，咱们成为了互联网行业举世无双的数字化服务体验团队 —— 一支有爱有担当，富裕创造力的“阿里柔军”。
业务背景
从 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 还处于迁徙适度阶段，为了保证系统的整体稳定性，局部业务还没有齐全替换，后续也会开始推动整体的迁徙工作，预计整体迁徙结束后预计能够节俭更多的资源。
将来瞻望
将来咱们心愿能够持续在流批一体、HSAP 上做更深刻的摸索，心愿能与 Hologres 放弃继续的共建，可能推动引擎倒退也能更好的服务于业务倒退。
- 服务 SLA：心愿 Hologres 能够有主备机制，在存储计算拆散的架构上，计算引擎能够主备，存储能够在不同的 Pangu 集群存在多正本的能力，保障业务在写入和读取上，任何主链路故障的状况下，能够无感切换到备实例。
- 实例间实时同步：在实践中，因为不同业务场景的不同保障等级，拆分实例可能将是将来较长时间内的一个可行的解决方案，以后咱们是通过 Flink 工作将数据做实例间同步，实例间相互实时同步数据的能力能够极大的升高业务开发成本和保护老本。
- 资源隔离：真正意义的行 / 列混存，能够在同一个表上撑持 Point Query 和 Olap Query，独立的资源分配，又互不影响。
- 弹性变更：table group 的 shard count 能够动静扩 / 缩，可能灵便应答峰值及日常的业务须要。
- 二级索引：对于 Point Query 反对海量数据的非 PK point query，同时可利用于流计算中，能够极大升高模型建设的冗余度。
原文链接
本文为阿里云原创内容，未经容许不得转载。