本文作者：白剑，石基大商连锁事业部架构组

石基大商连锁事业部专注于连锁零售软件，为企业提供ERP解决方案。石基在零售行业拥有众多知名品牌客户，如华润万家、永旺、永辉和联华等，并与很多地方性零售企业紧密合作。而对于石基，除了零售业，业务也涵盖了酒店餐饮与娱乐休闲领域，如广州长隆游乐场便是客户之一。

从单台到HTAP：零售行业数据库20年发展历程

连锁零售行业的发展历经了几个阶段，而最初的模样，或许80年代的前辈们记忆犹新。大约在2000年左右，开一家连锁超市其实很简单：摆上几个货架，放几台收银机，就能开门迎客。那时，一根电话线，加上一个调制解调器，就能满足基本的通讯需求。这背后所反映的，是连锁管理软件在初期的单体结构特性，简洁且几乎不依赖复杂的数据库，Excel表格或许就是最常用的工具。

当中国加入世贸组织后，国内掀起了一场名为“新零售革命”的浪潮。这一时期，众多新概念应运而生。以往，零售商只需一家店铺就能销售商品。而今，销售渠道变得多元化。天猫、美团、饿了么等平台家喻户晓，当然，还有许多新兴平台也在不断推陈出新。

零售行业正经历着重大变革，主要体现在移动化、智能化以及特殊技术的应用上。像VR、3D等前沿技术，不仅能够创造出虚拟店铺，还可以生成门店平面图、3D导图等，极大地丰富了消费者的购物体验。更为深刻的是，经营理念也在悄然转变。以往，我们可能只关注商品销售和盈利，但现在，与消费者建立情感联系成为新的重点。

世纪初时，许多客户，尤其是银行和金融系统，广泛采用Informix数据库。那时，除了Informix，DB2也是另一个常用的选择。当时的数据管理相对简单，主要集中在商品价格和库存等基本信息上，并没有涉及太多复杂的内容。进入2010年代后，零售行业逐渐演变成了一个高度现代化的系统。随着数据量的增多，企业需要从多渠道、多行业、多维度去采集和分析数据。因此，对于石基来说，最初我们可能只关注交易数据，但随后，图像数据、消费者标签等多样化数据类型也应运而生。

那么，面对庞大的数据量，分库、分表成为了一种常见做法，但这也导致了数据被打散到各个角落，形成了数据孤岛。为了应对这一挑战，零售行业开始积极寻求解决方案，尤其是要加强数据治理，最终构建起统一的数据仓库。

在这一过程中，一个较大的挑战就是数据仓库的建设成本极为高昂。可以想象一下，一个年销售额约100亿、毛利率仅5%左右的企业，很难有余力将自身的数据仓库建设好。因为这不仅需要聘请大量的DBA，还需要一支运维团队来管理，而这样的投入对他们来说往往是不现实的。

因此我们决定引入OceanBase。目前，我们将OceanBase作为石基的数据湖和实时数仓来使用。

性能与成本并重：零售业数据库选型的挑战与需求

为了直观地展示连锁零售系统的复杂度，可以参考以下示意蓝图，它就像一个全能的ERP，把企业方方面面都管理得井井有条。以前台触点为例，这一系统尤为关键，如POS收银系统，涵盖多种收银方式，包括自助收银、AI一体秤等。同时，系统还连接消费者销售端、供应商、门店及各类设备，实现全方位管理。

连锁零售系统的蓝图

系统中流转和处理的大量数据旨在为零售业的多样场景提供服务。零售业场景相当复杂，涵盖了主数据管理、门店运营、财务以及会员营销等多个环节。所有业务最终都会汇入石基的数据中台，实现全面打通与整合。此外，还有一些边缘系统，如HR、OA、BI等，整套系统能够全方位管理零售连锁企业。

在数据处理的过程中，数据库开发人员和运维人员感知颇深。

对于数据库开发而言，存在两个难点：

经营分析的成本高昂。零售的核心就在于销售，而现代销售与以往不同，涉及多个渠道和各类促销活动，如天猫、美团、抖音等。各渠道的经营状况、商品销售表现及哪些渠道下的客单价更高，这些都是很深的学问，需要进行系统的经营分析。起初，石基采用数十台MySQL数据库来构建类似小型数据仓库的系统，主要用于数据整合。然而，这种做法导致运维和部署成本高昂。

• 新增渠道的数据管理繁杂。随着业务的发展，石基的渠道不断增多，这就要求石基迅速扩张系统，增加接口和功能，而这些都离不开数据库的支持。在应对这些变化时，我们经常需要思考如何有效管理数据量，包括是否要分库、分表，甚至进行分区。这些问题让开发进一步的复杂化。

对于数据库运维而言，使用传统单机数据库+分布式中间件的方式面临两个挑战。

• 数据缺失。由于数据处理复杂，有时会出现数据不一致的情况。客户会发现某些数据缺失，比如门店反馈昨天货物已售罄，但系统上却未显示。这些问题都让客户感到困惑和不满。
• 业财数据不一致。这个问题更贴近业务层面。具体来说，就是门店的业务报表与财务报表之间存在脱节。整个数据链路包含多个环节，正如之前介绍的，零售系统相当复杂。在每个环节中，数据采集都可能丢失，计算也可能不及时。这些问题最终会导致业务和财务数据的不一致，令人十分头疼。

面对零售系统繁杂的数据处理挑战。我们总结了零售业态对数据库的几大需求。

第一，稳定性，由于此前引入多种数据库及组件后带来的复杂度增加，系统急需可靠的备份和日常维护。

第二，容灾恢复能力，确保数据安全及系统安全。

第三是数据量级的适应性。零售业的规模各异，数据量级自然各不相同。小客户可能只有几十家门店，年数据量几十GB；而大客户如某连锁零售头部企业，年销售额达千亿，数据量则更为庞大。石基在2021年前采用MySQL分库分表分区架构，对于几百GB的数据量尚能应对，但面对TB级数据量则显得力不从心，需要一款能够支撑大规模数据处理的数据库。

第四，开发及运维成本。分库分表导致开发和运维成本急剧上升。客户运维团队能力参差不齐，大型企业客户运维能力较强，而小型地方企业则缺乏专职DBA。这使得他们难以维护由十几台MySQL组成的数据库系统，面临严峻挑战。MySQL架构虽在一定程度上解决了数据存储问题，但随数据量增长，其局限性和运维难度逐渐显现。

第五，系统扩容。随着业务发展和渠道增加，数据量也将持续增长，无论是扩展数据库实例还是扩容存储，都势在必行。

基于上述难点和需求，我们开始考察新的数据库方案。

大道至简，石基从众多数据库厂家中找到了大道。

OceanBase落地实践：Flink CDC + OceanBase搭建数据湖

我们曾在2022年参与了浙江联华的项目。联华的特点是其IT部门并未自建机房，所有服务均依托阿里云。

随着业务量的快速增长，‌联华原先使用的数据库逐渐难以满足业务需求。此时，OceanBase进入了我们的视野，联华团队对此有着浓厚兴趣，他们希望利用OceanBase构建一个数据湖，并实现类似实时数仓的功能。

在确定使用OceanBase后，石基整条产品线都着手向OceanBase迁移。经过多轮测试，包括代码功能性测试、压力测试以及客户体验测试，结果均表现良好。于是，在今年上半年，石基向四个客户团队推广了OceanBase社区版。

下面以石基真实客户为例，分享在零售业的多渠道核算场景中，OceanBase的落地实践：

在零售行业，业财一体化至关重要。由于市场变化过快，零售的核心就在于快速分析企业或门店的经营状况，比如哪些店铺盈利，哪些单品亏损。为此，我们需要一个高效的数据处理方案。多渠道核算的场景主要聚焦于数据分析，于是便引入了“数据湖”的概念，数据湖融合了部分数仓功能，相较于数仓却更加轻便灵活

在技术选型方面，我们采用了经典的组合：Flink CDC搭配OceanBase，再加上石基的报表平台。我们非常看重OceanBase交易分析一体化处理（HTAP）的能力和系统动态扩容的能力。

在该案例的应用中，客户拥有1200余家线下门店，且拥有众多线上销售渠道，包括美团、饿了么、多点和京东等，还有一系列外围数据，涵盖预算系统、资产系统及费用数据。作为一家老牌国企，他们最初选择了Oracle作为数据库系统。随着业务数据的增长，他们考虑对现有的数据库系统进行替换升级。预计明年在我们团队的协助下将门店系统迁移到OceanBase数据库。

这一场景中，数据流转过程如下图所示，我们将Oracle中的数据用Flink CDC抽取并同步到OceanBase，对于MySQL等数据源，我们使用OceanBase的OMS和简单的ETL工具进行抽取和加工，并将其导入数据湖。简而言之，我们把OceanBase打造成实时数仓，对数据进行原子化处理。

另外，在零售领域，存在多种角色，如采购、营销分析和财务，他们关注的数据维度各不相同。为了满足不同角色的数据分析需求，我们根据不同场景进行数据聚合，并最终输出为报表。

那么，在通过一系列采集加工后，达到什么样的效果呢？

首先，数据日加工能在短短30分钟内高效完成，让ToB用户能直观地感受到速度之快。相较于客户之前频繁吐槽的数据丢失问题和仅支持T+1的更新频率，基于Flink CDC + OceanBase 搭建的数据湖方案不仅数据强一致、零丢失，还实现了准实时处理的标准。后期我们也通过实际压力测试进一步验证了OceanBase的卓越性能。此次改造也得到了客户信息部的高度认可。

其次，数据的呈现与响应更加快速。借助OceanBase的强大性能，大屏数据刷新速度、常规及复杂数据的响应时间都远超ToB客户原有的数仓系统。据他们反映，旧系统查询数据时常有延迟，而且传统数仓对建模要求严格，数据一旦落地就很难修改。相比之下，OceanBase系统具有独特优势，它并不强制要求数据建模，这一特性使我们能够轻松帮助用户修正数据。

此外，在该场景案例中，相较于传统数据库，OceanBase在多个方面为我们的客户带来了显著的改善：

• 完善的分布式存储，开发不用过多考虑数据存储细节，规划好分区和索引后，可以专心做好业务规则开发。
• 优秀的处理能力，能够轻松应对上万QPS及TPS需求，性能强劲，满足用户未来3年的业务需要，用户可以准实时地拿到最热点数据。

• OCP监控功能异常强大，运维人员在工作台上即可对整个系统的预警状态一目了然，极大提升了工作效率。
• 出色的压缩能力，和原始业务数据对比，存储压缩比在 60% 左右，节省成本的同时，灵活的扩容能力为后续业务发展奠定基础。

总结来说，OceanBase无论是存储、处理、监控还是降本表现都很出色，为客户带来实实在在的价值的同时，也为石基带来了多方面的提升：

首先，开发流程相比往前更加灵活。以往，我们总是被束缚在用户当前的业务模型中，需要进行无数次的建模讨论。而现在，我们能够迅速适应变化，开发更加自由、敏捷。

其次，运维的复杂度也大幅降低。让我们松了一口气。曾经繁琐的运维工作，如今变得轻松简单，让我们能够更专注于提升系统的稳定性和效率。

再者，数据呈现的速度大幅提升。数据的快速呈现，让我们能够迅速洞察业务动态，为决策提供有力支持。

最后，我们的客户认可新的系统。这一点也是最重要的，客户或许不懂技术细节，但非常看重实际效果，关注各部门新系统实际的使用情况，得到的反馈都是正面的。而且，硬件投资也明显减少，这无疑是客户对石基系统最大的肯定和认可。

对OceanBase的未来展望

鉴于OceanBase的出众性能，我们将毫不犹豫地在所有解决方案中向客户力荐。石基拥有多元化的零售软件产品线，目前正积极推进产品向OceanBase迁移，以替代原有的MySQL分库分表架构，实现技术的全面升级。

此外，我们渴望与更多行业伙伴深入交流、携手共进，未来将积极参与OceanBase社区共建。同时，期待OceanBase未来的卓越成长。

• 期待未来在OceanBase中看到更多AI技术的体现。事实上，最新版本的OceanBase已经在这方面有所加强。未来也期待将这些技术可以应用到石基的产品中。
• 期望未来OceanBase的部署方案能得到显著提升。不同规模、不同行业的客户，对OceanBase的部署需求各不相同。我们需要不断完善和优化部署策略，无论是云部署的灵活性、私有云部署的安全性，还是本地化部署的可控性，都应根据客户实际情况量身定制，最终找到最佳实践方案。
• 期待未来OceanBase可以持续增强智能化运维能力。借助AI技术的能力，大幅减轻DBA的工作负担。让DBA无需再时刻监控报警信息，系统也可以自动处理异常并具备自愈能力，从而提升整体工作效率。