作者：马琳，万家数科数据库专家
对于华润万家，大家应该非常熟悉了，主营的品牌如华润万家、万家 mart、万家 life、万家 city BLT OLE 及香港优购及万家 App，囊括的商品（食品、用品等）涉及我们生活中的方方面面。
华润万家旗下的信息科技公司——万家数科商业数据有限公司，聚焦于零售领域，在服务华润万家的同时，市场化运营发展，为零售商及其生态提供核心业务系统的整体解决方案与运维服务。
数据及 SaaS 的产品服务：基于海量的内外部的数据，建立内部数据中台，提供敏捷的数据对接能力，建立 API 标准接口，向品牌商提供原数支持；同时引入零售行业专业分析方法论及算法，实现各场景业务监测及洞察。 业务洞察咨询服务：向品牌商客户提供全渠道业务洞察解决方案，包括但不限于购物者决策研究、智能选品、新品创新及追踪、品类及品牌业绩回顾、消费行为研究、价格策略优化、促销机制回顾等，帮助客户实现精细化业务优化及管理。 精准营销及相关服务：线上全渠道业务服务平台，App、小程序、微信公众号等多触点广告投放，自动化营销互动，加价购能消费链路引流扩大购物篮，帮助品牌商实现人群圈定，精准触达目标消费群体。
基于上述业务，下面简单介绍技术侧的应对挑战，以及解决策略和措施。
华润万家是 1984 年在香港成立了第一家门店，至今已有 40 年的历史了。在整体零售业务的发展的过程中，系统从最初简单的进销存系统演变为如今多套系统的配合，比如物流供应链，会员系统、线上业务系统。但由于新老系统的交替运行积攒了各种各样的问题，我们总结为以下四类：
多系统并行，导致数据孤岛。 用户体验降低，由于线下门店与线上渠道的联动及业务融合，加上用户需求多样化，系统的响应速度与易用性逐渐难以满足用户要求。 链路复杂，导致故障排查困难，产生性能瓶颈。 系统可扩展性受限。受限于技术架构和成本压力，系统扩展能力较差。
挑战 1：多系统并行
这是一个绕不开的话题，跟随业务发展阶段的演变，系统也从最初的套装系统转变为 Java 定制开发，以及使用了很多不同的数据库，如 IBM informix、Oracle、MySQL 等。不同数据库的差异化非常大，以至于不同团队需要频繁沟通，制定统一交互协议，确保数据流转顺畅，这会耗费大量的时间和精力。
同时，对于各个系统之间的技术架构、数据格式、接口规范差异，也需要定制化开发适配器和中间件，增加了集成难度。长此以往，业务量在增长，各业务系统之间的资源耗费也随之加剧，带来了成本压力，各团队需要合理分配硬件资源、网络带宽，优化系统配置，减少资源冲突，提升整体性能。
挑战 2：用户体验降低
用户体验分为内部用户和外部用户，但总体而言，可以总结为三点要求。
第一，个性化需求。不同用户对系统的功能、界面、操作方式等有不同的需求，满足个性化需求难度较大。
第二，响应速度。用户要求系统的响应速度越来越快，尤其是在高并发情况下，但保证系统的快速响应是一个挑战。
第三，易用性。系统的复杂功能可能导致用户操作困难，降低用户体验。
挑战 3：链路复杂
这是我们所面临的一个极大问题，由于各系统在数据传输过程中存在各种各样的问题。导致故障点难定位，需要经过多环节排查，增加修复时间，而且链路中某环节容易造成瓶颈，影响整体性能，需要优化资源配置。作为运维人员，我们只能利用监控手段定位问题，然而某些监控盲点需要一个更强大的运维团队做实时分析，这十分考验我们监控运维团队对业务的理解能力。
更关键的是复杂链路提升了被攻击的风险，加强安全防护措施，确保系统安全也是我们需要重点关注的。
挑战 4：系统可扩展性受限
原有的数据库由于其架构特性，难以应对业务增长后带来的性能需求，同时随着系统规模的不断扩展，代码的复杂度增加，导致维护难度加大。如果扩展系统，不仅需要投入大量的资金，还需要大量的人力资源支持，企业要面临的成本压力极大，这也成为了限制企业发展的主要矛盾。
*数据库选型与测评详见博客 https://open.oceanbase.com/blog/9690209104
下面具体说明新技术引入的历程与收益，以及在此过程中的挫折与经验。
无论是新项目的生产与开发，还是旧项目的迁移，目前万家数科已有五六十个项目使用 OceanBase，未来将有更多的项目建立在 OceanBase 数据库之上。具体收益总结为以下 5 点。
成本节约：高压缩存储技术，原存储迁移后容量降低约 60%，硬件成本节约 50%，业务综合成本节约 25%左右。 资源有效利用率提高：使用集群汇聚多个实例，多租户资源隔离，减少资源碎片，充分利用资源。 改善业务韧性，开发效率提升：优化业务架构，统一技术栈，降低开发难度，提升开发效率，增强业务稳态和扩展性。相比此前整个运维团队都忙于稳固 MySQL 集群，现在大家轻松多了。 性能提升与混合分析：解除当前架构中的性能瓶颈，系统性能提升 70%，同时支持实时报表查询，减少了数据链路开发与维护的工作，兼备混合分析场景的支持。 运维效率提升：数据库平台化管理，支持 DBA 白屏化操作，提升了运维效率，降低了运维工具开发和运维成本。
（二）数据库迁移经验解析
在本次数据库迁移过程中，我们也从遇到的问题中总结了一些经验供大家参考。
这是一个利用 OMS（OceanBase 迁移工具）进行数据库迁移的普通方案。我们原有的 MySQL 集群是一个庞大的基于中间件的多实例集群，迁移到 OceanBase 后就变成了一个数据库。从迁移策略来说，我们使用 OMS 将多条链路分步汇聚到 OceanBase。按照读写分离策略，先迁移读业务，后迁移写业务，这样的优点是系统稳定性较高，业务平滑地过渡至新系统。最大化地保障用户体验，让用户对系统变动无感知。
在切割方案中，我们对读写业务进行应用改造以适配双数据源，设置合理的规则，在整个迁移过程中分批次进行业务迁移，直到迁移完成。
这样做的好处是，我们可以把整个业务的迁移风险降到最低。第一步只是利用小部分流量做迁移测试，确定没问题后再进行后续步骤逐一迁移读写业务，每步迁移过程在 10 秒内即可完成，对业务影响极低。
但在迁移过程中，我们遇到了一个挫折，就是合库合表，这是 MySQL 分库分表集群迁移 OceanBase 必须考虑的问题。不仅需要对每张大表检查验证，确认每条数据的唯一性，并配置合适的大表分区键，确认热点 SQL 的性能最优，还要考虑历史数据能够快速卸载，保证运维清理能够简单高效。
由于我们使用的是多 DB 模式，且在 DB 中 table 主键使用了相关的雪花算法，这种算法只能保证每一个 DB 有唯一性，在多个 DB 中有极小的概率会存在主键冲突。因此，这成为了合库合表的难点。
解决方案倒也简单。如果是小表，可以通过查询、排除主键的方式来更改；如果是几十亿上百亿数据量的大表，使用排除主键法就不可行了，会耗费大量资源，因此我们对主键做了一些改造，抛弃现有基于雪花算法的主键。新增了自增主键，并对所有 DB 的自增链设置了一个范围的起始值。这样能够保证在一定时间内数据库的主键不会冲突。而在这个时间段内，我们就需要尽快合库合表并完成迁移。
此外，我们也遇到了数据流相关的问题，由于万家数科在推进 Flink 生态所采用的统一格式为 debezium，而 OMS 不支持此格式，如果改造那么工作量非常大，最终经过双方沟通，OceanBase 针对 debezium 格式进行了相应的开发与适配。
下图基于 OMS+FLINK 调度的流数据实时处理。取代了此前基于 Mysql_KAFKA 延时较高的任务调度模式。
OMS 提供可视化的集中管控平台，界面化操作，可以基于时间点同步，维护成本低。同时使用 Flink 流实现实时数据处理逻辑。通过 Flink 的 StreamSink 和 TableSink 将处理后的数据实时推送到目标系统。确保目标系统支持实时数据的接收和处理。其 checkpoint 机制，实现任务的持续检查和恢复。在任务运行过程中，定期检查 checkpoint 状态，确保任务在异常情况下能够恢复到一致的状态。
OMS+Flink 方案保证了用户操作简单和数据实时性，整个数据流转可在 2s 内完成，保证每一笔数据消费都能准确实时可靠地推送至每一个用户。
在迁移完成后，我们利用 OceanBase 丰富的生态体系极大地简化了监控运维的工作，不仅提升了运维管理细粒度，还提高了运维效率。
以 OCP 和 ODC 的性能优化为例。在几个月前的某天凌晨，业务人员反馈在程序发布后，新增业务需求执行效率低下，该场景在 UAT 环境中性能稳定，上线后效率较之前降低几倍，造成业务单据压单，无法实时处理业务单据。
我接到问题后，第一时间通过 OCP 平台的 OCP-SQL 诊断功能发现这个时间点没有明显慢 SQL，和开发人员沟通后发现这个场景是高频 SQL 场景，平均响应时间慢几毫秒都会对业务产生影响。由于当晚要传成千上万单数据，而且必须在 1 小时内完成，因此我们很快就确定了问题 SQL，发现并没有相关索引问题呈现。于是，我使用 ODC 查询、定位执行计划，发现该 SQL 存在过多的 RPC 调用，实际上只慢了 2ms 左右，却对业务造成了较大的影响。
对于这个问题，我们只需要新建表组避免 RPC 调用，整体性能就会产生质的提升，借此机会也希望 OceanBase 官方能够推出更好的解决方案！期待后续更多合作！
