Lazada是阿里旗下的综合电商平台,包含Marketplace、LazMall、跨境等多种商业模式,通过自建物流网络与推出LazPay不断升级东南亚电商的基础设施。
1. Lazada数据体系和架构
阿里巴巴淘系有关大数据领域的建设已经有将近20年的打磨,目前是非常成熟的体系了。当前Lazada数据体系与淘系数据体系非常相似,主要分为六个部分:数据源、数据集成、数据建模与计算、数据聚合与集市、数据服务、数据应用。
数据集成主要依靠cdp和datahub系统,数据建模分为离线和实时两部分,其中离线模块基于 MaxCompute ,实时模块基于 Flink 平台实现了实时数仓。在数据聚合层,2020年后逐渐使用Hologres统一替换了此前比较繁杂的数据结果层与数据计算层中间件,通过Hologres提供OLAP查询分析、数据服务和ADS即席查询作用,最后统一对接上层应用。
下面将会分享如何基于上诉的数据体系架构支3撑Lazada如大促营销、A/B Test等多个应用场景。
1.1 场景一:融合实时计算的大促营销运营手段升级
大促是电商常见且非常重要的场景,我们期望能够通过实时数据和实时技术赋能大促或改变整个业务形态。
1.1.1 大促营销的三个阶段
分别是促前、促中与促后:
- 促前包括各种准备工作,比如招商、选品、会场页面搭建,是一些比较离线或长周期的动作;
- 促中阶段需要预热蓄,为加购、流量分发以及动态调控做准备,此阶段多为实时决策与实时调控,需要实时数据作为支撑;
- 促后需要进行业务复盘与数据分析、数据PR等。
为了支撑业务侧的实时决策与实时调控,需要对原先的离线数据架构进行改造。因此,我们利用 Flink+ Hologres将数据链路全部进行实时化、体系化升级,利用 Hologres 的OLAP 查询能力,能够在大促当天支持业务做实时分析,业务可以根据业务诉求,比如目标人群覆盖不够,GMV达成不足时,就能在极短时间内进行快速查询与分析,然后做下一步的运营策略,如圈选优惠券发放的目标人群,同时也能实时检测流量、权益等数据,方便运营动态调整策略。
以Lazada大促场景下用户实时权限动态调控为例,来介绍具体的数据流转链路和数据加工过程。
大促发放用户优惠券需要讲究策略与节奏以及圈选的目标人群,需要考虑给哪些人发券、发完券之后用户是否领取了优惠券、领取之后有否使用等问题都会影响大促节奏的调控。于是在发券之前,我们需要了解,现在用户是否有券、券的额度是多少等实时数据信息。基于这些实时数据,业务开发人员结合更多的数据资产、用户本身的购买力、消费习惯等信息形成目标人群锁定,并在大促期间给出实时反馈。
1.1.2 在后端的具体实现
- 从 DataHub 消息中间件消费用户的实时领取与使用券等数据。同时因为大促周期长,需要将用户历史状态数据也一并进行计算,因此还会将离线 MaxCompute 表作为初始化表,在一个Flink 任务里进行实时与离线两种不同数据的 source 消费。
- 数据消费完之后,一方面会将数据写进 DataHub 消息中间件,推送给下游营销系统直接消费与使用;另外会将数据存放到 Hologres,为业务人员提供实时 OLAP 分析的数据指标与数据标签。
- 因为实时计算的仅是用户使用券的金额数据,数据不全面,因为还会将离线MaxCompute用户资产数据同步至Hologres,这样就可以通过Hologres既能够对用户购买力、消费习惯与偏好类目等基础性数据资产类数据做分析,同时也能与大促中的实时变化交易与权益变化数据做关联查询,快速锁定不同业务需要的目标人群。
1.1.3 方案优势
- 流批一体:使用Flink计算引擎同时消费实时与离线两种不同数据源,实现了流批体实时计算;能够将用户历史累计权益数据结合实时变化权益数据进行实时计算,得到用户全状态的权益领用及实时数据
- 实时与离线混合 OLAP 分析:在 Hologres 计算引擎里存有离线数据,比如存储一些已经计算好的离线标签数据,同时线上实时变化的状态类数据也同时写入Hologres。因此,Hologres里会有全量状态与非常大范围用户的整体数据,除了能够观测到当前状态,也能够对历史行为与表现进行综合性的分析。
通过该方案,营销活动系统从原先的离线化状态成功过渡到可调控、可决策、可落地的实时系统。实现业务在大促场景中动态调整运营策略与运营动作,助力业务的精细化运营。
1.2 场景二:Hologres在Lazada LAB平台的使用
Lazada LAB实验平台累计了万级的实验数量,实验数量排名处于 top 5 水平,支持百级子业务阈,千级月实验人数。为产品、运营、业务决策者等提供多方位的数据驱动实验方案和商业决策。
1.2.1 LAB平台的架构的三个层次
从下至上分别是数据模块、系统模块和应用模块:
- 数据模块:主要存储各类实验指标,包括流量指标、行为指标、用户指标、商家指标等各类数据
- 系统模块:系统模块主要包括查询引擎、指标管理、维度管理、异常告警等功能
- 应用模块:主要是数据对上层的应用,包括实验Dashboard、指标分析、OLAP分析,实验监控等
在数据模块层利用的数据存储引擎已经全部切换为Hologres 。实验里通用的数据指标会进行提前预计算再写入Hologres,以减轻Hologres 的计算压力。另外,会将明细层数据与轻度汇总层数据通过实时计算方式写到 Hologres里,以支撑在A/B实验场景里自定义与灵活快速分析所需的能力。最后,将各种实验维度数据同步到 Hologres 进行自定义分析与查询使用。
下图为LAB平台实验的数据流加工过程:
数据源是常见的业务Binlog 数据,以及日志采集、搜推广日志数据等,然后同步到分别同步到离线数仓和实时数仓:
- 离线数仓会进行数据加工,然后写到Hologres。
- 实时数仓会通过Flink实时计算与操作,将实时的明细层与汇总层数据同步到 Hologres 。
- 在Hologres 建立了一套完整的实时数仓,有实时的 DWD 明细层, ADS/DWS层存放计算好的离线数据,以及DIM维度数据。其上还建设了大量逻辑视图与部分物化视图,因为实验场景中,查询条件或查询模式对于表的使用非常固定,可能需要通过逻辑视图与物化视图将经常使用的查询方式与指标固化,增加前端的实验性能。
以上架构利用 Hologres 强大的查询与数据写入导出能力,提升了整个 LAB平台的实验速率与效率。
同时也为了提高AB实现的计算效率,我们也针对Hologres做了较多的性能优化,下面也分享一些实践经验。
1.2.2 在优化方面主要两大方向
1.2.2.1 存储优化:确保数据合理均匀的分布
- 合理的设置表存储属性:KV点查使用行存,OLAP查询使用列存
- 合理的设置分区表:数据大于1亿条建议设置分区表,同时分区表选择时,一定要有分布键。
- 合理的设置distribution key:join key设置为distribution key,提升local join的能力
- Table Group选择与Shard分配:一般选择默认的TG,但是实例规格较大时,设置多个TG与不同的shard count,以保证资源的充分利用。同时也要结合维表数据量与业务场景不断实践与摸索。
1.2.2.2 计算优化:降低计算复杂度,提高查询性能
- 设置主键:保持数据的唯一性
- 用近似计算APPROX_COUNT_DISTINCT替代count distinct去重函数,效率会更高。另外Hologres 1.3版本支持uniq精确去重,效率也更高
- 设置聚簇索引:对于范围过滤查询,设置聚簇索引clustering key,减少文件扫描
- 设置分段键:对于时间范围查询,设置分段键segment key,直接命中文件,提升查询性能
- 设置位图索引:对于等值查询,设置位图bitmap,命中文件内的block
- 优化字典编码:为字符串比较的字段设置dictionary,减少其余不必要text字段的dictionary设置,从而减少数据编码、解码开销。
2. 总结
lazada数据技术发展经历了从以MaxCompute为主的离线数仓(主要支撑T+1更新、批量计算等)实现了离线数仓的基础体系建设),到Flink 问世后的实时数仓,支撑了实时更新,流批一体等多个业务场景。随着 Hologres云原生引擎的诞生,我们已经可以窥到湖仓一体可能的实现和使用方式,并以此支撑异构多元智能计算,
未来我们期望能够利用 Hologres服务与分析一体化的能力,并结合 AI 处理,在一个平台、一个组件上快速完成数据加工,将业务价值通过技术平台高效释放。
牛顿说,站在巨人肩膀上能让我们看得更远。而我们也坚信,有阿里云这样一个巨人,我们能够将数据业务价值发挥得更加透彻、更加淋漓尽致。
了解Hologres