业务介绍
AliExpress（简称AE）是从集团内wholesale孵化出来面向全球消费者的B2C电商平台，目前也是全球化电商业务的排头兵。当前AE为全球220+个国家提供在线购物服务，支持3端（PC、Msite和APP）、18+种语言，有5个独立分站（印尼、俄罗斯、巴西、西班牙、法国）和2个本地站（西班牙Plaza和俄罗斯Tmall）为当地提供更精细化的服务。
业务挑战
营销是电商业务的核心场景，本质是解决人货场的匹配问题。而大数据时代，传统的小二人工运营的方式越来越力不从心，AE数据智能中台赋能小二们在海量用户和商品里进行人货匹配，释放小二们的压力，从而更快、更精准的营销。
去年AE数据智能中台在双十一中小试牛刀，效果得到了业务团队的普遍认可。然而今年由于疫情等各种复杂的国际形势，对AE智能化产生了更多的赋能场景，而这些场景对支撑业务的数据系统也提出了更高的要求和挑战。
时效性---速度要快
AE的场景基本都是实时营销，如果给用户的营销是基于非实时的数据计算出来的结果，会大幅降低运营的决策效率。以会场调控举例，需要在双十一大促期间从修改选品池条件到生效到会场整体时间稳定在10分钟以内，运营根据实时看板的秒级粒度的大促数据表现，以修改选品规则进行实时调控，解决商品疲劳、会场投放效果差、调整会场货品结构布局等问题。
智能型---效果要准
相对于传统的小二凭借自身知识营销，AE数据智能平台需要支持各种分析需求，既有基于规则的简单分析需求，又有大数据分析需求，越多的数据纬度，越多的成交数据，分析出来的结果就越精确，效果越好。以人群洞察为例，需要使用各种聚类算法尝试对用户进行分组，从而找到相似的客群。传统的数据库已经不满足这种复杂分析需求。
耐操型---使用要狠
在大促期间，既有来自于多用户高QPS的分析查询，又有各种复杂离线需求，同时这些离线计算不能影响用户的即时分析。以用户洞察为例，既需要秒级响应用户TGI的计算，又需要支持复杂聚类算法的计算；而实时会场调控也需要支持高QPS的在线统计和将大数据量结果同时导出给会场展现引擎，同时还有大数据量的实时写入，还需要数据实时可见，这样狠的使用方式，一般的数仓根本满足不了。
简易型---使用要省
在满足以上条件的情况下，往往会使用链路很长的复杂大数据方案，同时对于开发者，既要去掌握多平台的开发能力，又要在使用上区分不同的场景使用不同的系统，这个开发运维成本都非常的大。故AE数据智能平台需要一个数仓，使用简单的sql就可以满足用户的所以需求，达到事半功倍的效果。
AnalyticDB--快准狠省的云原生实时数仓
AnalyticDB是阿里云自研的云原生数仓，全面兼容MySQL语法，为分析而生，拥有出色的分析性能。
数据写入实时可见
会场实时调控对数据的时效性要求高，AnalyticDB数据写入后实时可见，可以使运营小二的调控效果实时的反映到会场上，同时AE会场的实时效果数据，从产生到分析到决策应用，从原来的天级别或者小时级别缩短在10分钟以内。数据写入实时可见充分满足了AE对时效性的要求。
高性能高并行度
AnalyticDB不仅数据写入生效快，计算也快得当仁不让，AnalyticDB在业界权威性能TPC-DS榜上连续两年夺得第一名，拥有行列混存、自适应索引，结合向量化的分布式执行引擎实现大部分复杂查询在毫秒级完成，全面满足AE智能营销各个场景的性能需求：人群洞察场景中人群间的DiffScore计算秒级响应；基于AnalyticDB的进行分析决策，在高峰期平均每小时进行了4800次有效流量调控，平均每分钟进行80次。
支持各种大数据分析需求
AnalyticDB不仅支持高QPS的即时查询，同时也支持各种类型的大数据分析能力，用户洞察业务里AnalyticDB支持了业务的多种聚类算法，从而满足AE的智能化需求。
在离线一体化数仓
借助混合负载管理能力，不管用户的查询情况多“狠”，AnalyticDB都可以以最高性能完成用户的所有查询，同时保证在线查询不受离线/batch查询影响。在实时会场调控中，AnalyticDB支撑了平均每分钟80次的导出，每次导出平均100w条记录，1w/s的实时写入、10qps的秒级查询的混合压力。
MySQL兼容
好用是数据库价值真正的体现，AnalyticDB高度兼容MySQL，基本无需修改代码即可像使用MySQL一样使用AnalyticDB，简单易用。对于AE智能平台的用户--商家和小二来讲，会MySQL语法就掌握了全套的大数据分析能力。在AE业务里用户圈选，分析一体化，tgi，聚类计算等等都是直接使用SQL全部完成。
业务实践
业务架构
业务概述
数据智能部使命：致力于全面集成 AliExpress 数据分析体系，以数据服务化的形式，支撑用户增长、导购营销、社交互动等业务场景，通过与 AnalyticDB 的深度合作与共建，将原有臃肿的离线数据服务链路，打造成快、准、狠、省的实时化链路，通过人、货、场等多维度的标准化数据服务，提升运营小二、商家的运营效率。
架构升级
使用AnalyticDB之前的数据处理链路
在计算引擎框中因为多种计算需求的原因，引入了两种计算引擎：
- MaxCompute: 满足数据批计算需求
- Pai: 满足算法分析需求
计算出来的结果会同步到两个地方：
- 会场展现引擎： 分析的结果对线上生效。
- HBase：结果存储在HBase里供其它业务高QPS查询。
这样的方案除了链路复杂外，更本质的是满足不了业务实时性需求以及高并发高性能需求。实时会场调控在这条链路下时效性日常30分钟，大促繁忙时2小时以上。
使用AnalyticDB后的数据处理链路
AnalyticDB作为一个云原生实时仓库，增加 Embedding Algorithm 模块，实现了算法与分析的一体化能力，极大的缩短了数据处理链路。
如上，AnalyticDB解决了所有的计算需求。实时会场调控的时效性缩小到6分钟。AnalyticDB MySQL作为链路核心，支撑了AE业务的快准狠省的智能营销。在数据时效性、高并发、低延时以及复杂分析等方面提供了强力的保障。
效果展示
图示摘自 AE 数据银行商家版，通过实时标签、AIPL 趋势分析、实时人群画像、秒级人群生成、效果监控等核心能力，丰富了商家自主运营的手段，目前已成为商家店铺运营的核心产品之一。
店铺用户分析
人群显著性特征分析
人群画像分析
投放效果分析
未来展望
今年AE智能中台在营销场景中借助AnalyticDB的能力得到了长足的进步，特别在双十一大促中，表现丝般顺滑。未来将继续融入AnalyticDB的最新能力进行工程架构上的升级。
全链路实时化演进
随着业界软硬件技术的发展，全链路实时化的路径变得越来越清晰，数据智能部在关注数据内容建设之外，也着手于全链路实时化的探索与演进。未来，数据智能部将投入大量的人力，将 AE 的离线链路迁移至实时化链路，从算法到工程，从数据到服务，依托于 AnalyticDB 的强大能力，加快小二与商家的运营效率，以应对瞬息万变的全球化电商市场。
数据服务成本降低研究
业务资源隔离
AE的业务繁多，经常出现多个业务共用一个库，其中有些是双十一在线重点保障业务，而有些是测试需求临时搭建的业务，在大促中出现未经过压测的复杂测试业务抢占重保业务的资源，作为AE平台，要么增加成本，物理上严格分离这两个业务；要么进行人工管理这两个业务的资源。在 AnalyticDB MySQL版新推出的弹性形态下实现了资源组功能，通过新建资源组可以从现有实例划分出部分计算节点，这些计算节点资源只归属该资源组。AE平台直接将业务绑定到不同的资源组，从而满足内部多租户隔离、混合负载的需求。资源组的创建、修改、删除等操作都可以在线实时生效，并可以通过API与用户业务系统进行深度融合，实现全自动调配。
存储计算分离
AE智能营销经过这么多的工作取得了非常不错的效果，但同时AE智能平台仍时刻关注成本的投入，AnalyticDB高性能实例是按存储能力来计费的，而不同的业务场景计算和存储的开销却不是一致的，甚至相差很大。比如人群洞察业务来讲，聚类算法的计算开销要求更多的资源，相对于计算，存储需要的资源是少量的，故后续也需要使用AnalyticDB弹性功能中的存储计算分离能力进行成本的降低。
弹性扩容
在存储计算分离的情况下，能够自动根据负载进行弹性库容，便于管控。AE业务作为典型的电商场景来讲，具有很明显的峰值和低谷流量时刻。而目前的AnalyticDB高性能模式是资源预分配模式，在绝大部分低谷流量时刻，资源也是在进行计费。而AnalyticDB新推出的弹性形态下自动弹性扩缩功能可以在保证业务服务能力的情况下，同时大幅度降低闲时成本。
数据查询服务可行性研究
AE智能业务里很多数据都会在HBase里存一份，比如现在的架构里会场的计算结果仍然会在HBase里放一份，用来后续业务高QPS点查，这个场景AnalyticDB已经具备高QPS点查能力，目前正在展开前期相关工作，进行KV系统的替换，使用AnalyticDB为AE智能平台提供全站数据服务。
智能化诊断
需要做好监控和边界问题的发现机制，在出现问题时能够快速定位。期望能够充分利用AnalyticDB的监控能力，在出现问题前第一时间预警，规避问题的发生。为此，AnalyticDB将提供全方位、多维度以及准实时的实例运行状况洞察能力，通过对实例内部的各类运行日志和时序指标进行算法建模，提供出问题前准确预测、出问题时及时告警、处理问题时精准定位的能力，确保不影响用户上层业务。
原文链接
本文为阿里云原创内容，未经允许不得转载。
来源：oschina
链接：https://my.oschina.net/yunqi/blog/4792451