Hologres助力AliExpress双11实时数仓升级

简介：本篇将重点介绍Hologres在阿里巴巴AliExpress的最佳实践，并助力AliExpress实时数仓升级，节约成本近50%，提效300%。

概要：刚刚结束的2020天猫双11中，MaxCompute交互式分析（Hologres）+实时计算Flink搭建的云原生实时数仓首次在核心数据场景落地，为大数据平台创下一项新纪录。借此之际，我们将陆续推出云原生实时数仓双11实战系列内容，本篇将重点介绍Hologres在阿里巴巴AliExpress的最佳实践，并助力AliExpress实时数仓升级，节约成本近50%，提效300%。

AliExpress中文名是全球速卖通，是阿里巴巴面向国际市场打造的跨境电商平台，被广大卖家称为“国际版淘宝"，在2020年全球疫情肆虐的大背景下迎来了自己的10周年，伴随业务全球市场的拓展，AliExpress也同样遇到了大多数电商都会遇到的问题：流量红利逐步消失、拉新成本飞速上升以及引流效率的逐渐疲软等。业务发展需要从原始的野蛮生长逐步转向流量的精细化运营，于是帮助业务看清站内流量的分发及承接效率的流量通道也就应运而生了。 关于电商平台元素的解析有大家比较熟悉的“人、货、场”分法，人和货相对好理解，场可以理解为消费者和商品之间创建特殊链接的产品形式，如搜索、推荐、店铺、猜你喜欢等，流量通道便是以更加结构化的方式描述平台元素之间的关系，实现更好研究不同场域流量效率的目的。 在仅持续48小时（国际11不同于国内，持续2天）的双11大促过程中，数据更新的频率直接决定了业务做决策的频次，流量通道数据实时化的需求迫在眉睫。文章接下来希望带你一起还原借助Hologres卓越性能落地流量通道实时分析体系的过程。

一、流量通道实时化数仓架构调研

流量通道升级前停留在准实时架构，整体数据的时效为H+3（3小时前数据可查），所以接下来的重点工作变成了实时架构的设计及实现，综合AliExpress内部及其他BU的应用场景，主流实时数仓架构演进主要如下：

1）基于Flink+多数据引擎的Lambda数仓架构

Lambda实时数仓也是业界相对通用的解决方案，数据采集之后根据业务需求分为实时层与离线层，分别进行实时处理和离线处理。处理结果在数据服务层对接数据应用之前会进行数据的合并，从而实现实时数据与离线数据同时服务于在线数据应用和数据产品。

image

离线层处理：采集数据归并到离线数仓之后，首先会统一到ODS层。对ODS层的数据进行简单数据清洗，构建DWD层（明细层）。在数据建模的过程中，为了提高数据分析效率以及进行业务分层，会对DWD层的数据进行进一步的加工和处理，相当于预计算。预计算结果在对接数据服务之前还会转储到一些离线存储系统中。 实时层处理：逻辑与离线层类似，但是更加讲究时效性。实时层同样是对上游数据库或者系统的数据进行实时数据的订阅和消费。消费数据之后会将其写到实时的DWD层或DWS层。实时计算引擎提供的是计算能力，最终处理结果需要写到一些实时存储中，例如KV Store等。 很多场景离线层还有一个重要的功能就是对实时层数据问题的修正，其次基于成本和开发效率的考虑，实时层一般保留两到三天的数据，而月、年的数据等更长的数据存储在离线数仓中，使用时需要离线数据和实时数据的结合场景，方式是引入了更多产品，如MySQL、ADB等。在流量通道场景，大促相关的分析往往需要对比历史同比或环比数据，比如需要和去年或者是前年的双11做对比分析，同样需要考虑到离线数据回刷或者数据一致性的问题。 AliExpress已有的实时数仓也属于Lambda架构的范畴，流处理层的几个关键思路如下：

1. Flink承担绝大部分的解析+聚合计算。

2. 消息队列TimeTunnel中沉淀抽象明细层和汇总层结果。

3. 按照维度表数据量级，选择使用Lindorm或者MaxCompute存储。

4. 根据下游应用场景特点将结果数据导入不同的存储引擎，例如为了提供高QPS的点查询引入Lindorm；为了对离线数据进行交互式分析，会引入ADB等。

伴随业务的高速增长和数据膨胀，数据质量、运维复杂、成本高、业务敏捷性等问题也逐渐突显，具体如下：

1. 一致性问题：离线/实时2套代码、2套语义、2份数据。流和批执行的代码数据处理逻辑的不同，导致同一份源数据处理结果可能不一致，同时离线数据和实时数据合并过程需要不断地进行数据结构的重新定义，数据的转储、变化、合并，都可能引入数据一致性问题。常听到“流批一体”技术核心就是解决一致性问题。

2. 多套系统环环相扣，架构复杂，延迟风险大：数据计算链路长，穿插在若干Flink任务中间的TT sink节点降低了系统了鲁棒性，当某一个下游任务发现了数据异常，其向上溯源及排查成本被放大。而流式计算任务由于其实时的特性，往往给到开发定位和止血问题的时间都在小时级别，有时涉及线上系统甚至会要求分钟级别。

3. 开发周期长，业务不敏捷：复杂架构带来还有较高的开发、变更成本，任何一套数据或业务方案上线之前都需要进行数据校对、数据验证。数据校对过程中一旦出现问题，其定位和诊断将十分复杂，在极端情况下，实现一个实时任务的代码逻辑只占开发时间的20%不到，剩下80%时间都用于漫长的比对任务开发，数据校验调试，任务调优运维等，这对研发效能提升是非常大挑战。

4. 元数据管理困难、存储成本高：数据服务部分，针对不同的业务场景选择不同的数据库引擎，一方面存储成本成本增加，同时管理这些系统也变得异常麻烦，当底层存储引擎多样的时候，尤其是包含了很多KV引擎时，由于schema free的特点，我们很难有一种简洁友好的方式管理表及字段。

2）基于Flink+Lindorm实时数仓架构

鉴于以上痛点，是否可以用Flink+Lindorm简化实时部分呢？Lindorm 是一个分布式的 No-SQL 数据库，数据以键值对形式存储，支持高并发、毫秒级响应的点查询，同时Flink作为当前业界最先进的流计算引擎，其动态表状态管理及回撤机制能满足大部分指标计算需求。

image

从架构图可以看出，所有指标的计算，包括表关联、指标聚合、维表查询，都在Flink 引擎中完成。具体地讲，Flink 引擎实时处理消息，在引擎内存中保存指标的结果，当指标有更新时，会将结果通过回撤机制（指标结果的新旧值）通知下游算子，将指标结果的最新值更新到 Lindorm 中。 这种方案最大的特点是指标的计算都是通过Flnk流引擎实现，然后将预计算好的多维 Cube 导入到 Lindorm 这个低延迟的分布式数据库中，从而可以实现亚秒级的查询响应。然而，这种架构存储明显的弊端：

1. 计算逻辑，资源消耗大：指标按不同维度组合都需要保存在 Flink 内存中，当指标粒度越细或指标时间跨度越大时，资源消耗越大。

2. 查询灵活性不足：计算逻辑需预先定义，无法灵活调整 Query。在流量通道的场景中，会有行业/产品/商品/商家等类似多维灵活交叉分析的场景。

3）基于Flink+Druid实时数仓架构

Flink+Druid如何呢？Druid 是一个分布式、支持实时多维 OLAP 分析的数据处理系统。它的关键特性在于支持根据时间戳对数据进行预聚合摄入和聚合分析，支持亚妙极高并发查询。此方案Flink只需要负责简单的ETL工作，指标的计算由 Druid 完成。Druid 按预先定义的指标计算模板进行预聚合计算存储，并对外提高查询服务。

image

但是该方案的局限性也非常明显：

• 查询灵活度不够：指标计算逻辑需预先按模板定义，同时数据预聚合存储，复用性明细降低了。

• 表关联能力性能差：Druid在表关联场景支持比较弱，在流量通道的场景中，转化率相关指标的计算逻辑复杂，同时需要大量实时表的关联聚合。

以上两种方案，在某些特定场景下均有较好的应用价值，比如 Flink+Lindorm 方案很适合实时大屏等时效性要求非常高的场景；Flink+Druid 方案则较适合超大数据量（万亿级）单表的实时多维分析场景。而对于流量分析场景，这两种方案都存在明显的局限性，无法满足我们的需求。

二、基于Flink+Hologres实时数仓的实现

偶然的机会，在公司内部看到淘系搜索推荐、客服体验事业部等在尝试Flink+Hologres的方式实现实时数仓，详细了解后，给了我们很大的信心，其中最吸引我们的能力有三点：

1. Hologres高性能的写入：可以支持上百W+ RPS，同时支持数据实时写入即可查。

2. Hologres高性能的查询：基于 MPP 架构的分布式 ROLAP （Relational OLAP）分析引擎，各节点职责对等，各自负责一部分数据的处理（Shared Nothing），开发了向量化执行引擎，利用日志合并树、bitmap索引与 CPU 的 SIMD（单指令多数据 ，Single Instruction Multiple Data）等特性，充分发挥硬件优势，即使面对大数据量计算的场景，通常也能达到 CPU 性能的极限，达到高效计算的目的。具备同时支持PointQuery，Ad-hoc，OLAP，实时离线联邦分析等多业务场景的能力，让对外服务统一引擎成为可能。

3. Hologres丰富可扩展的存储：Hologres丰富可扩展的存储：Hologres支持行存和列存两种存储格式，采用计算与存储分离架构，便于水平弹性伸缩，可以支持海量 （TB到PB）的数据存储。

image

基于此，我们设计了流量通道实时架构：

• 交互式计算：Flink只做简单明细层数据的产出，指标汇总在Hologres实时交互式触发。

• 流批一体：历史明细数据提前导入Hologres内表，基于Hologres引擎同当天分区数据实时汇总比对。

• 联邦查询：部分小维表直接作为Hologres外部表，做离线加速方式查询关联。

image

图5-流量通道具体Flink+Hologres实时数仓实现 那Flink+Hologres升级版实时数仓架构是如何解决Lindorm/Druid架构存在的问题呢？

• 资源消耗大：Flink+Lindorm方案最大的局限性在于，所有维度的计算都通过Flink完成，Flink是纯内存有状态的流式计算，每到一条消息都需要对内存状态进行读取更新。维度组合复杂、聚合周期跨度较大时，内存往往会成为瓶颈，使得无法应对细粒度的分析需求。在流量通道场景场景中，查询均为人工触发，所以QPS相对较低，同时运营查询维度相对固定，实时CUBE存在大量的计算浪费，预期利用Hologres 强大的交互式查询能力，可以大大降低计算资源的消耗。

• 灵活性不足：上述提及的两种方案，由于物理存储的是指标数据，都存在灵活性不足的缺点。当需新增不同维度的指标时，这两种方案都需要重新创建任务计算新指标，而新指标历史数据的回刷成本极高。基于Hologres的方案可以直接存储明细数据，具备满足各种查询维度的能力。

• 表关联能力弱：流量通道分析遵循漏斗分析模型，从用户浏览->收藏加购->下单支付各阶段看流量转化的表现，所以存在大量大表关联操作。借助Hologres的特性，对主要分析链路的明细数据表进行精心设计，以满足流量分析场景中的大表关联需求。从整个分析链路来看，最终可以细化到每个设备在网站的行为表现，所以我们选取了设备id 作为表的分布键，充分利用 Hologres 的 Local Join 能力，使得大表的关联操作得以在秒级以内完成返回。

• 运维成本高：大促往往具有数据量成倍增长的特点，因此需要在大促前进行资源预估以及扩容，而当大促结束后，为了不让资源浪费，会进行相应的缩容操作。对比Flink+Lindorm方案，由于计算负载都在Flink任务中，所以扩缩容主要集中在Flink任务上。而对Flink任务进行扩缩容的成本非常高，需要对每个任务独立执行停止-扩容/缩容-启动操作。Hologres的计算节点是云原生的，具有良好的弹性伸缩能力，因此，本方案在运维成本上基本可以忽略不计，大大降低了开发人员的工作量。

三、业务价值

从开始接触Hologres，到Hologres真正落地具体场景，Hologres带来诸多显著业务价值，主要体现在决策实时化，研发提效，降成本三方面。

1）成本节约50%

• 更简单的Flink计算逻辑，对比Flink+Lindorm方案，流量通道场景至少节省 6000 Cores。

• 更简单的数据模型，无DWS实际存储，触发式计算代替了DWS预计算。

2）决策效率提升300%

• 实时准确的业务决策：双11有限48小时内，实时带来最大的价值便是根据流量实时的表现作出当前最直接的应对，保障应对方案的准确性和时效性，今年大促整体的有效的数据复盘从过去的1次提升为3次，时效价值提升300%，让我们对未来有了更大的想象空间。 如图，2-3点这个区间运营发现会场通道浏览转化持续走低，及时调整后，实时数据验证提升效果符合预期。

image

• 灵活的多维数据分析：实时数据产出后，分析师，业务运营等角色可以根据需求进行实时数据的筛选，过滤和分析展示，双11前烽火台（内部使用的数据产品）快速沉淀了行业、产品、商家、商品、海外仓等多视角通道效率分析的能力，其中商品、海外仓部分完成由运营同学自助完成。

3）研发效率提升30%

基于Flink+Hologres架构带给DA同学最大的惊喜便是研发效率的明显提升，项目初期评估整体需要40人日，伴随中间层数据侧产出，指标生产、数据验证、分析报表搭建等工作并行展开，实际人日减少11天，提效近30%，使得我们在大促前有更多的精力来做Hologres SQL调优及性能压测的工作。

4）更简单的数据加工链路

• 事实明细层：直接开放公共层明细数据给到运营/BA/BI小二，需求交互方式SQL化，指标口径实时验证，开发效率由天级缩减至小时级，海外仓需求4合1，效率提升400%。

• 事实汇总层：DWS视图化虽然增加了诸多性能方面的挑战，但更短的问题排除路径、更灵活的指标变更（无需数据回刷）带来的好处是显而易见的。

• 数据展示：BI/BA可通过FBI/Vshow+Hologres方式自助搭建实时大屏，提升了业务自助数据分析的体验，解决了每年大促遇到的业务诉求和数据开发资源的Gap。

5）让业务打仗随时上膛-俄罗斯topBrand临时圈选

今年俄罗斯受卢布贬值的影响(相对美元贬值，AE商品价格以美元计价，相对消费者来说价格变高)，双11最后的4小时标类行业用户下单意愿疲软，运营临时新增topBrand圈选需求，按照行业维度筛选出高于行业平均IPVUV价值但IPVUV低于行业平均值的商品，针对这部分商品做流量的加持，从而促进整体GMV目标的达成。

四、对于Hologres的期望

期待Hologres未来可以继续在流批一体、HSAP上做更深入的探索，也希望与Hologres保持更加深入的合作，期待的Hologres架构与能力如下：

image

• 资源隔离：长期看批流统一计算后，大Query/小Query难以避免资源的抢占，资源组隔离即对计算资源进行弹性划分，不同资源组之间的计算资源在物理上完全隔离。通过账号绑定到不同的资源组，SQL查询根据绑定关系自动路由至对应的资源组执行命令，用户可以选择为不同的资源组设置不同的查询执行模式，从而满足用户实现实例内部多租户、混合负载的需求，当然如果Hologres调度可以自动优化资源抢占问题就更加完美了。

• 流批一体：批和流一套引擎，运行在一套资源底座上，天然削峰填谷，自然混布，不仅节省了开发成本，同时也大幅节省了运维成本和资源成本。

• 存储统一（方向一）：MaxCompute可以直接访问Hologres数据，准实时链路逐步升级实时，Hologres数据支持归档MaxCompute，逐步去除离线ODS，实现离线&实时数据的统一。

• 计算统一（方向二）：基于Hologres一体的流批一体数据业务，MPP模式错峰执行流批任务。

• 分时弹性：数仓系统的负载存在明细的时段波动，低峰期资源往往处于闲置阶段。分时弹性功能允许用户灵活定制弹性计划（每天定时），在业务高峰期来临之前自动进行扩容满足业务流量，即满足了业务流量高峰的需求，又降低了使用成本，同时结合资源组功能，甚至可以让某个资源组在低峰期时0节点，成本极低。

• 数据分层：按表粒度、表的二级分区粒度独立选择冷、热存储介质，比如指定用户维表数据全部存储在本地SSD，或指定交易表的一部分分区数据存储在本地SSD，冷分区存储在OSS上，以达到最低的存储成本。

• 行列混存：维度表订阅TT流实现维表实时更新，行列混存方式帮助维度表同时具备行存表的更新，列关联聚合的理想性能。

• 行列自动转化：Flink/业务数据实时写入时，选择行存表，单记录全字段更新删除操作更友好，行存表如果可以自动转换为列存表，同时进行组合排序或多维排序，让列存表提供贴合业务场景的最佳查询性能。

• 物化视图：简化数据清洗流程(ETL: Extract, Load, Transform)，帮助用户加速分析，如：大屏类业务加速，配合BI工具使用，或者是缓存一些公共中间结果集用以加速慢查询。

作者： 陈功（昀西），阿里巴巴数据技术及产品部技术专家 李月（志歉），阿里巴巴数据技术及产品部技术专家

原文链接

本文为阿里云原创内容，未经允许不得转载