导读 喜得国际成立于 2020 年 9 月，短短的四年之间，公司发展非常快速，成为了跨境电商的头部公司。在这四年里，我们服务超过 130 个国家和地区，提供从 XXS 到 4XL 的尺寸，上线了 9 种语言。我们的全球创意中心位于洛杉矶，办公室分布在新加坡、中国、英国、韩国、法国、德国、巴西和中东超过 500 人，核心团队来自亚马逊、Airbnb、字节、腾讯等。

本文将分享我们在数据平台建设上的一些思考与实践。

主要分为四个部分：

1. 业务架构分享

2. 业务架构遇到的问题

3. 业务架构优化

4. 业务架构优化的价值

分享嘉宾｜王筱磊 北京喜得国际网络科技有限公司 CTO

编辑整理｜汪维

内容校对｜李瑶

出品社区｜DataFun

01

业务架构分享

首先介绍一下主要的业务架构。

前端应用层包括 IOS 和安卓。

流量入口层包括边缘计算、Apisix 网关、CDN 和行为风控服务。其中，行为风控方面做了比较多的工作。行为风控的核心目标就是防止机刷。在跨境电商领域，价格、衣服的款式和整体的风格是比较关键的数据。行为风控做的工作主要是以下几点：控制每一个请求或者每一次图片在固定时间窗口的访问频次；判断是否是爬虫，防止款式、价格和上线数量等信息被竞争对手拿到；防止攻击代码，在跨境电商领域竞争非常激烈，不希望被别人攻击。所以，在网关层面做了很多行为风控。在 CDN 层面融合了很多 CDN，自己做了一些调度。

在业务层面，包括搜索、内容推荐、市场运营、商品等，重点分享一下物流。国际物流跟国内的情况不一样，国内物流非常成熟，包括四通一达、顺丰、京东等，对接这几家就完全足够。但在全球化的市场里面，每个国家地区的物流方式都不一样，所以我们在物流服务方面做了很多的权衡，包括为用户匹配最合适的物流方式，匹配符合价格的物流商等，提供了非常丰富的选择。

前端内容处理完成之后，就是下层的业务处理，业务处理跟大家平时用的各种电商 APP 差不太多。有一点区别是在购物车部分，为了最大程度地获得用户的下单，在海外购物车开放了未登录加购的功能，这样会导致购物车里面的数据可能存在大量未注册且没下单的无效数据，也会导致购物车的数据异常庞大。后面会介绍我们的解决方案。

购物车之后是支付，支付也跟国内有差别，国内对接完支付宝和微信就已经完全够用，但在海外有非常多的卡商、信用卡，以及很多的支付方式，在支付方面我们做了非常多的支付方式切换，流量切换和一些校验，还有订单风控。订单风控和行为风控有什么区别呢？订单风控主要做了这几点：识别是否有盗刷信用卡；识别高风险订单。高风险订单怎么理解呢？在网关层面拦截了机刷，购物车层面得拦截人为刷。我们希望用户能够快速下单，在退货方面给了用户极大的便利。大家都知道，国际物流的成本相对较高，所以我们给用户的一个选择是可以把商品留下，退款一部分，或者把商品留下，接受礼品卡。因为有的时候可能物流的成本比商品价值还要更高。提供了这个选择之后，导致非常多的用户刷单，因此需要对这种高风险的订单做一些识别。还有一个是异常单，比如可能一不小心金额配错了，也有可能研发出了 bug 等导致金额特别低，所以也需要去防止价格单价过低、金额错误等各种情况的异常订单产生。

最后是服务治理层，包括监控系统、质量保证，以及告警平台。

最下面是基础服务层，这一层重点讲一下 I18n 国际化。对全球化业务来讲，国际化是非常重要的，我们在国际化做了统一的收口，这个收口会将货币的币种、汇率还有翻译统一融合到国际化服务。有了这个收口，最上层的业务就不需要关心汇率的波动。前端应用展示的所有翻译，也都是由国际化服务提供，可以高效地做翻译。用户服务和库存服务跟现在国内平台类似。

最上面的服务支撑层也与国内电商平台类似，在此不做展开讲解。

以上就是我们在 C 端国际化市场上的业务架构。

02

业务架构遇到的问题

上述架构设计也遇到了一些问题，业务发展得太快了，人员跟不太上。业务团队，比如商品、物流、供应链、产品等团队想要了解业务的发展情况，就会需要一些数据。有些公司业务同学可以直接通过数据分析平台去获取数据，但是我们公司成立较短，还没有那么多资源建设完善的数据平台。业务团队分析用户、库存、销售等数据需要把需求提给数据分析团队，数据分析团队进行消化和排期，数据分析团队相对人员规模较小，一个数据分析师需要面对十多个业务，很难应对一天非常多的事情，而且还有很多临时插进来的需求，永远有优先级更高的 P0 需求。对于数据分析团队来讲，还有一个困难在于业务不是数据分析团队写的，还需要去找工程团队去了解库、表及字段的含义，工程团队也可能还需要去查才能了解，非常耗时。

做了微服务拆分之后，线上库分成订单、支付、购物车和商品 4 个库，这里就暴露出来了一个问题，怎么解决数据大量冗余的问题？特别是购物车。我们采用了行业内一般的分表做法，将购物车分了 32 个表，分表后由工程团队将数据查出来。

拆了 4 个库之后库和库之间没法做关联了，工程团队在极端情况下可能 3 天才能查出数据，因为需要基于不同的库查询数据，订单信息取自订单数据库，购物车信息来自购物车信息数据库，在不同的库中无法直接关联，需要将相关的数据拉到本地，通过本地写代码或者 excel 的 VLOOKUP 功能加工才能把数据给关联起来反馈给业务方。极端情况下，一个提取数据的需求可能需要将近 5 个工作日。

这是我们面临的一个比较大的问题，在数据分析团队的资源和数据基础不够完善的情况下，提效困难。

03

业务架构优化

1. 架构优化思路

要解决这个问题：

首先要彻底解决分库分表的联合查询问题，购物车分了 32 个表之后无法进行联合查询操作，需要把表合到一个地方才能想办法 join。第二是要支持高性能的联合查询。第三是需要支持多分库分表的同步导入，导入的频率越高成本会越高，大数据团队的数据产品目前支持实时导入，但主要是天表。业务和产品希望可以支持实时的同步导入。最后是支持源端业务库的 schema evolution，支持将表结构的变动同步到业务库表里面。

2. 基于 Prontonbase的架构改造之搭建数仓

机缘巧合下，我们用 Protonbase 来做了改造。

把主要库，尤其是购物车库中的数据同步到了 Protonbase，将 30 多张表融合到一张表，在一张表里去做联合查询操作和一些业务处理。有了 Protonbase 之后，业务方经过培训后，就能直接在 Protonbase 用 SQL 查询数据了，不用再通过数据分析团队和工程团队，解决了跨库问题，也解决了一部分数据分析的问题。做了这个改造后，查询数据所用的时间从之前极端情况的 5 天降低到小于 10 分钟。

3. 基于 Prontonbase 的架构改造之去掉从库

前面的改造是搭建的数仓，另一个改造是针对从库的，在业务上经常会选择从库的方案，平时主库用来读写业务对，从库主要解决一些查询问题和一些复杂 SQL 查询的问题，因为复杂 SQL 的查询可能会拖垮主库，影响线上业务，风险很大。有了 Protonbase 之后，可以把从库放到 Protonbase 里面，去掉从库。架构就变成了主库还是业务库，业务库的数据直接同步到 Protonbase，通过 Protonbase 来解决从库的功能，也分担一些数仓的压力，同时给工程团队提升效率，给业务分析团队提供便利。

4. 基于 Prontonbase 的架构改造之 all in one

我们也在思考，未来是否有可能 all in one，将业务库也变成 Protonbase，这是我们的设想，还没有完全落地。

04

业务架构优化的价值

最后简单回顾架构优化带来的价值，主要是三个方面：

查数和取数的效率有了极大的提高，从极端情况下的 5 天缩减到了 10 分钟，为公司带来了非常大的价值，同时也减少了员工间的沟通成本和摩擦，提升了员工的幸福度。优化了使用数据的路径，以前数据有多个备份放在多个地方，目前只有主库和 Protonbase 两份数据，整体效率提高了很多，业务的响应速度更快。成本得以下降，包括提数需求的沟通成本、提取数据的实现成本以及从库的基础设施成本。

以上就是本次分享的内容，谢谢大家。