电商
高效查询
精简架构

释放数据价值 - ProtonBase 在某头部跨境电商场景的实践

导读

近年来，跨境电商市场规模迅速扩大。根据中商产业研究院发布的《2022-2027 年中国跨境电商市场需求预测及发展趋势前瞻报告》显示，2024 年中国跨境电商市场规模将达 17.9 万亿元。在数字化浪潮下，数据已成为企业核心资产。然而，如何高效利用海量数据仍是诸多公司面临的挑战。本文将分享某跨境电商借助 ProtonBase 解决数据孤岛问题的同时释放数据价值的实践经验。本文结构如下：

  1. 业务背景：数据产品在跨境电商运营中的重要性与日俱增
  2. 业务痛点：架构、性能、弹性、多云
  3. ProtonBase 在该跨境电商多条业务线的应用
  4. 总结与展望

一、业务背景

数据产品在跨境电商运营中的重要性与日俱增

该客户是一家跨境出海电商品牌。作为一家新兴的跨境电商公司正在迅速崛起，目前在全球各社交媒体上已积累数十亿次曝光，覆盖来自 100 多个国家的消费者，在全球已有超过 200 万的粉丝。该跨境电商的商业模式是通过自营和平台两种方式开展业务。自营业务方面，公司直接采购国内厂商的产品，通过自建的海外仓库网络，高效地将商品配送至世界各地；平台业务则是为国内商家提供一站式的跨境出口服务，包括物流、清关、本地化运营等环节。

对于这样的跨境电商公司而言，数据库和数据仓库产品在其业务运营中扮演着至关重要的角色。不论是在面向 ERP 场景，C 端用户场景，亦或者根据产品的销售信息进行分析的大数据场景，处处都需要高效稳定且性能强大的数据产品来支撑。

业务架构

从上图可以看到该客户的典型业务流程：

  1. 通过手机或 PC 端进行登录；
  2. 在流量入口层进行接入处理（比如风控识别）；
  3. 在业务处理这部分涉及了电商场景的一些核心功能，比如订单、商品、搜索和购物车等服务；
  4. 同时服务治理层提供了一些监控和告警的能力。

场景需求

可以看到核心的业务处理部分，必然涉及了数据的写入、存储和查询过程。围绕业务场景，该跨境电商对数据产品的主要需求如下：

分布式事务

为了保证在高并发访问和商品查询场景下的稳定运行，具有高性能和高可用性的数据库系统是确保网站稳定运行的重要基础。该系统不仅需要支持大量的商品信息查询及下单操作，可以高效地进行数据存储与检索，更为重要的是，在整个处理过程中要维护数据的一致性和完整性，以满足商品信息和订单数据的实时查询与事务处理要求。而随着业务的快速发展，单机关系型数据库如 MySQL 和 PostgreSQL 在处理海量数据时将面临性能瓶颈。为解决数据量持续增长带来的挑战，需要引入具备分布式事务能力的数据库系统。

实时 OLAP 分析

作为一个独立站品牌，该跨境电商有自己的生产和供应链系统。在 ERP 端，当用户下单后，ERP 系统可以整合来自供应链系统、订单系统、物流系统等多个数据源的信息，集中存储订单数据、物流轨迹等结构化和非结构化数据。这为后续对商品销售情况的多维度分析、订单号和物流单号的联合查询等分析需求，提供了强大的数据支持。这种支持主要体现在两方面：一方面可以对商品销售情况的统计分析，如按商品类别 / SKU / 区域等维度统计销量、销售额等指标；另一方面，也可以根据订单号和物流单号关联查询包裹的全部轨迹信息，用来查询订单轨迹、发现物流瓶颈、优化物流路径等。

高并发关键字查询

电商网站通常需要为用户提供高效、准确的商品搜索服务，以满足用户快速查找所需商品的需求。传统的关系型数据库在处理大规模非结构化数据和全文检索方面存在一定局限性，因此需要引入专门的搜索引擎产品。

大数据分析

数据仓库与大数据计算框架的结合，可以非常有效地支持基于用户行为数据（如商品浏览、点击等）进行广告策略优化和渠道投放计算。具体来说:

  1. 数据收集：数据库收集并存储大量用户在该跨境电商平台上的行为数据，包括浏览记录、点击商品、加入购物车、下单购买等，以及用户的人口统计属性等维度信息。
  2. 数据抽取：通过 ETL 或数据集成工具，将这些用户行为数据从数据库抽取到大数据计算平台（如 Apache Spark）进行分析计算。
  3. 数据分类：在大数据计算平台上，可以基于用户行为特征，构建用户画像模型，对用户进行细分和分类，发现不同群体的兴趣偏好。
  4. 数据分析：将用户画像与商品信息相结合，分析不同类型用户对不同商品类别/属性的敏感程度，从而预测用户对某类商品的购买意向。
  5. 数据决策：根据用户画像和购买意向分析结果，制定个性化的广告投放策略，选择最合适的广告渠道（搜索、社交媒体、推广等）进行精准推广。
  6. 链路优化：持续跟踪广告效果数据，并反馈回数据仓库，进行在线的一些报表分析和 Ad - Hoc（即席查询）的查询加速，形成闭环优化，动态调整广告策略。

总之，在这样的跨境电商企业中，数据库和数据仓库产品提供了高效的数据存储、处理和分析能力，支撑了核心业务系统的运行，并为业务优化和决策提供了数据支撑，是不可或缺的关键基础设施。

二、业务痛点：架构、性能、弹性、多云

该客户初期 1.0 架构图如下：

其中对于数据产品的使用，主要涉及三条业务线:

1、ERP 线：ERP 线主要负责订单、物流、供应链相关，简单说就是用户不在 APP 或者网站上直接用到的功能，体现在商品的生产端或者用户下单之后的服务等，比如工厂生产衣服的质检，包裹的物流轨迹查询。查询场景主要有 Serving 查询、AP 分析查询、看板查询和多场景的联合查询（比如订单和物流的联合查询）。目前主要使用了 PostgreSQL 和阿里云某数仓产品 A（下文简称 A 产品) 。

2、C 端用户线：主要涉及 C 端客户涉及的一些场景，比如用户信息、订单积分、商品库、购物车、风控、服务、push、搜索和行为日志等。涉及了多款数据产品：MySQL、PostgreSQL、PolarDB、Elastic Search 和 Kafka 等。查询场景以 OLTP 写入查询、Serving 查询和关键字检索等为主。

3、大数据线：通过定时同步任务，从 ERP 线和 C 端用户线的源数据库中抽取数据，并将其离线处理至阿里云某离线数仓产品 B（以下简称 B 产品）以执行计算任务。待这些任务完成后，再利用同步工具将处理结果导入阿里云某数仓产品 C（下午简称 C 产品），以实现在线查询的加速。大数据处理线主要对接的应用场景包括：

  • 报表分析：借助报表工具连接 C 产品，进行与业务场景相关的统计分析，从而支持更精确的商业决策制定。例如，可以统计在特定时间段内，某一价格区间中最畅销的商品。
  • 即席查询：企业运营人员或 BI 分析师可根据自身需求，灵活设定查询条件，快速获取所需信息以辅助各类场景分析。例如，可以从国家、地区、时间及商品类别等多个维度，进行销售情况的统计分析。
  • 广告策略引擎：通过对用户行为数据的洞察与分析，为广告投放策略提供预测支持。

在之前业务架构的基础上，该跨境电商的业务痛点主要有四方面：

架构 - 多数据库产品架构复杂

公司不同业务线在面临不同子场景问题时，使用了多种数据产品，如 PostgreSQL、MySQL、PolarDB、Elasticsearch、阿里云数仓 A 产品和阿里云数仓 C 产品等。采用越来越多数据产品解决业务问题的同时，也引入了新问题:

  1. 研发门槛高：构建复杂的系统要求研发人员熟悉多种产品及其特性，这显著提高了开发的难度和门槛。
  2. 运维复杂：多种产品的共存增加了运维工作的复杂性，尤其是在数据同步任务方面，给运维团队带来了额外的挑战。
  3. 数据延迟与不一致：尽管整体数据架构是随着业务需求逐步演进而形成的，但随着业务的发展，也暴露出了一些问题。一方面，系统内部多点数据同步不可避免地会导致一定的数据延迟；另一方面，这样的架构设计也可能引发数据不一致的情况。

性能 - 数据库性能及查询优化挑战

  1. 之前使用的 PostgreSQL 在线上持续运行一段时间后，会发生某些场景查询越来越慢的问题。重启或手动执行 VACUUM FULL 后可恢复正常性能，但是 VACUUM FULL 会锁表影响线上服务，因此只能选业务低峰期执行。
  2. 存在较慢查询。如在 ERP 线物流场景下，大部分查询需求秒级返回，但从之前线上某天日志来看，单日最慢查询达 147 秒。
  3. 之前在大数据场景下使用 C 产品，涉及一个几十亿大表和其他表有比较复杂的关联和统计查询，只能支持最多一个月内的统计查询，时间范围有限，超出限制会出现内存溢出。

弹性 - 云产品扩容时效性及可用性挑战

扩容时效性慢。随着业务发展，线上各云产品实例随时有扩容需求。目前绝大多数云产品扩容时效性都在分钟以上，有的甚至需要 10 分钟，在面对扩容场景时有些力不从心。另外在扩容过程中服务也会受到一定影响，甚至需要停服进行升级。

多云 - 跨云产品迁移挑战

部分数据库产品和云数仓产品与云平台绑定。当客户有搬云或者出海等迁移需求时，在目标云上寻找替代品往往存在两大问题：

  1. 数据同步：数据同步本身就是比较薄弱的环节，容易出错，同步后数据校验也需大量人力。
  2. 无对应替代产品：某些数据产品与云平台绑定，换云后可能找不到对应替代品。

三、ProtonBase 在该跨境电商多条业务线的应用

ProtonBase 是一个云原生的分布式 Data Warebase。Data Warebase 这个词是由 Data Warehouse（数据仓库）和 Database（数据库）两个词融合而来。这也意寓它包含了数仓和数据库的所有能力。它具备多云原生、支持所有数据、在所有场景下挑战性能极限以及极简体验等特点。

在和该客户合作的过程中，ProtonBase 针对业务上遇到的多个痛点场景进行了持续深入的交流。各个子场景的具体实践如下：

ERP 线场景：查询性能提速 10+ 倍，冗余存储大幅减少

ERP 线场景主要有两个痛点：

  1. 性能：同样 SQL 的查询性能逐渐退化以及存在慢查询
  2. 冗余存储：多个实例的数据从库和 A 产品在功能上有重叠，架构不够精简，导致数据冗余存储。

改造前后的架构图对比如下：

一、高效的查询性能，相对 PG 提速 10+ 倍

ProtonBase 在该场景下，相对于 PostgreSQL 有明显的性能优势。下图是在 ERP 一个物流场景下的性能对比，根据线上一个时间范围内的查询日志，使用同样的数据在 ProtonBase 同资源规格下进行性能测试。从统计结果可以看出：

  1. 在全量查询下，最慢的 query 查询性能从 147 秒提升到了 14 秒，是原来的 10.4 倍。
  2. 在全量查询下，query 的平均查询性能从 18 ms 提升到了 2 ms，是原来的 9 倍。
  3. 在原来的 top1000 的慢 query 范围内，平均性能从 8864ms 提升到 167ms，是原来的 53 倍。原因主要是慢 query 主要是 OLAP 的分析型 query，在该场景下 ProtonBase 有良好的查询性能。

二、稳定的查询体验，针对高频更新优化

接下来，我们来看一下业务上线后遇到的一个问题：相同的查询 SQL 随着时间推移执行越来越慢。经过分析发现，这个问题主要和客户的业务场景特点有关，在该业务场景中，存在大量的更新（update）和删除（delete）操作，这在 PostgreSQL 中会导致较为严重的读取放大现象。相比之下，ProtonBase 基于 LSM-Tree（Log-Structured Merge-Tree）结构设计，能够通过适度的写入放大来避免读取放大，并且其合并（compaction）过程是由后台异步执行的，因此不会出现类似的问题。

三、统一架构，大幅减少冗余存储

在这一场景中，ProtonBase 作为统一的实时数据仓库，替代了原有的多个线上只读从库。通过 ProtonBase 数据同步服务，实现了数据的高效同步，在提升性能的同时，取代了多个只读的 PostgreSQL 实例。此外，由于各个 PostgreSQL 实例的数据均已同步至 ProtonBase，并且 ProtonBase 拥有卓越的 OLAP 分析能力，性能比阿里云 A 产品更好，因此原有的 A 产品也被替换。这样一来，不仅整体数据架构得到了简化，还大幅减少了冗余存储。

C 端数仓场景： 5 天降低至 10 分钟，数据分析流程提速显著

该客户 C 端原有的各个业务库是独立的 MySQL 或 PostgreSQL 实例。在业务初期，面对日常分析需求，工程团队通常的做法是从各个业务库中提取数据，再在本地使用 Excel 通过 VLOOKUP 函数实现数据的联接。由于初期各业务库的数据量不大，这种方法能够较快地解决业务问题，并在一段时间内满足了数据仓库的分析需求。然而，随着业务规模和数据量的增长，即便是稍微复杂一点的数据分析需求，从业务团队提出，经由数据分析团队进行需求分析，再到工程团队执行，直至最终交付分析结果，整个流程逐渐延长到了五天之久。在这种情况下，建立一个高效的 C 端数据仓库系统的必要性变得显而易见。

决定在 C 端用户线构建实时数据仓库后，该客户 C 端用户线场景与 ProtonBase 展开了紧密合作。通过前面物流场景性能对比的结果我们已经知道 ProtonBase 的查询性能高效，在有了一个高效的查询和分析引擎的前提下，C 端数仓这个场景主要对数据同步工具提出了挑战。有如下需求：

  1. 实时同步 MySQL、PostgreSQL 等数据源
  2. 支持全量同步和实时增量同步，以及二者的无缝衔接
  3. 支持分库分表的同步
  4. 支持数据源的 Schema Evolution

这些需求点恰好也都是 ProtonBase 的同步服务能力的一部分。

  1. ProtonBase 数据同步服务具备良好的易用性，通过前端 UI 的一些勾选操作即可完成一个数据同步任务的配置
  2. 对分库分表的场景，ProtonBase 数据同步服务提供正则表达式的配置方式，在数据同步的同时通过几行简单配置即可将数据映射到下游的同一张表里，降低分库分表场景的同步门槛

ProtonBase 凭借强大的数据集成能力，高效地将该跨境电商的多源异构数据实时汇聚到 AWS 数据仓库中，实现了数据的统一管理。同时，ProtonBase 先进的分析引擎可以在数据仓库上提供高并发、低延迟的实时分析能力，助力挖掘数据价值，为客户提供增值服务。通过一体化的数据平台，大幅简化了客户的数据架构，降低了开发运维成本，提升了业务灵活性。

带来的直接业务收益是业务团队人员在经过一定的查询 SQL 培训后，新的业务分析需求的平均时间从 5 天降低到 10 分钟。

大数据线场景：迁云保持数据链路一致性，整体性能大幅提升

最后是该客户大数据线在迁移到 AWS 后的变化。

客户此前将系统部署在阿里云上，但由于公司业务策略的调整，整个大数据模块需要迁移至 AWS。原先的大数据处理部分涉及 ERP 线和 C 端用户线的数据源，通过 B 产品进行离线调度和计算以生成汇总数据，并利用 C 产品加速查询，主要应用场景包括报表分析、即席查询（Ad-hoc Queries）以及广告策略引擎。在迁移至 AWS 之后，整体数据链路保持了与之前的相似性，阿里云 B 产品的功能由 AWS 上的 EMR（Elastic MapReduce）替代，而 C 产品的角色则由 ProtonBase 承担。此次迁移不仅提升了整体性能，还解决了某些场景下的查询内存溢出（OOM）问题。

四、总结和展望

在数字化转型的大潮下，数据已成为企业核心资产。作为一家高速增长的新兴跨境电商公司，该跨境电商正面临如何高效利用海量数据的挑战。传统的数据架构已无法完全满足业务快速发展的需求，存在架构复杂、性能不佳、扩展性差、跨云迁移难等痛点。为解决这些痛点，该跨境电商与 ProtonBase 开展了深入合作，并在 ERP 线、C 端数仓和大数据线三个场景进行了合作的一些探索和实践，主要落地收益如下：

  • 统一的数据库和数仓产品：首先从架构上，ProtonBase 同时支持了数据库、数据仓库和搜索引擎的能力，不仅支持，并且从各自的领域，都是更好的数据库、数仓、搜索引擎产品。在该跨境电商客户多个业务线，先后取代 PostgreSQL 、A 产品 、C 产品等多个产品，极大化精简架构。在 C 端数仓场景，ProtonBase 凭借强大的数据集成和分析能力，实现了异构数据的无缝汇聚和高性能分析，将业务分析需求的响应时间从 5 天降至 10 分钟。
  • 多场景高效且稳定的性能：从性能上，ProtonBase 通过对存储格式、索引、优化器、执行引擎等进行了深度的优化，在各个场景下都有良好的性能。以物流场景为例，最慢的查询从 147 秒优化至 14 秒，提升近 10 倍。在 ERP 线场景中，ProtonBase 替代了原有多个只读实例，提供了统一高效的查询能力，查询性能最高提升 53 倍。
  • 极致弹性秒级扩容：从弹性上，ProtonBase 能做到秒级扩容，并且扩容过程中服务不受影响。扩容后性能随着计算节点扩展基本可满足线性关系。相比绝大多数云产品的分钟级扩容能力，ProtonBase 可以有效应对紧急扩容场景。
  • 无缝迁云：在大数据场景，ProtonBase 作为一款多云原生数据库，顺利完成了客户原有大数据 AP 分析场景从阿里云到 AWS 的迁移，继续支持原有的报表分析、即席查询和广告策略引擎等需求。在同一云内部，备份文件的上传和下载速度可达到 300MB/s，而跨云迁移的速度则取决于不同云服务商之间的公网带宽。

未来，双方还将在更多场景开展创新实践。可能的合作方向包括:

  • 向量检索：客户在其内部多个场景中有向量检索的需求。ProtonBase 不仅具备向量检索的能力，而且还支持分布式事务、关系型约束及 RBAC（基于角色的访问控制）权限模型，非常适合与数据库紧密结合的向量检索场景。通过标准的 PostgreSQL 接口，ProtonBase 能够无缝支持结构化、非结构化数据查询与向量检索的联合操作。
  • 只读 Replica 功能：在 ERP 线和 C 端业务数据库中，业务人员已被培训来自行执行查询，但他们的即席（ad-hoc）查询可能受限于编写 SQL 的熟练程度，从而导致可能出现性能较差的查询，影响线上服务的稳定性。ProtonBase 支持只读 Replica 功能，基于同一份数据实现场景隔离，既能满足业务人员的即席查询需求，又能保障服务的稳定性。
  • AI 方向探索：双方还将在更多场景下开展创新实践，利用 ProtonBase 强大的数据处理能力支持实时数据分析，并探索与人工智能（AI）/机器学习（ML）等前沿技术的融合，旨在为业务创造更多价值，使数据产生智能。