零售行业的数据孤岛形成史（二）| Tapdata

数据孤岛的形成是有其必然性的。企业的历史也是业务系统信息化/数字化的历史。企业的成长，和孩子的成长是一样的。原本合身的上衣和裤子，也会发展过程中，慢慢变得不合适，不再适用当前的发展状态。本系列以珠宝零售行业为例，分析企业孤岛形成的原因和因此面临的数据痛点。

痛点二：割裂的商品中心，难以形成合力

不同的地域都部署了相同的“服务和数据库”的组合模式，这也为后续的数据孤岛埋下伏笔。随着数字化进程的深入，这些割裂的系统让不同区域的商品数据无法流转和查询，同时还会造成冗余的库存信息，最大的问题实际上是在业务侧：不同的业务条线有不同的业务人员，他们作为数据消费者，在现有的架构下是无法及时消费到数据的，换句话说，订单的状态抵达相关业务人员的时间，会被大幅度延长。

这种难以消费数据的原因是，数据割裂。数据割裂这一概念本身可能过于抽象。

我们从数据割裂造成的实际问题来谈一谈。

作为一家头部的珠宝零售公司，它的商品 SKU 大概有 100 多万，分别散落在不同的数据库表和数据库中，且字典表难以理解，业务映射表关系复杂，业务研发不得不花费大量时间在内部的沟通上。

即使沟通也不一定能解决全部问题，还需要通过数据库的跨实例查询（dblink）解决数据割裂的问题。因为超过 1.5 亿库存订单存放在多个 Oracle 和分布在 20 张表中的 10 万商品信息，整个运维团队和业务团队，需要花费很多的精力解决：

• 订单状态跨地域维护。

• 数据在多个数据库之间的同步导致的延时。

• 订单逻辑复杂，不易扩展。

当一位中国香港门店店员想要在香港查一件货，通过系统查询得知这件货不在香港，在澳门。一般而言，店员可以通过系统去做“调货”动作，最后完成交易。

但因为一些 IT 历史原因，这家珠宝零售公司的门店店员，必须通过系统将澳门的货转到香港后，才可以查询该货明细，而这个转货的过程需要花费数小时来等待。客户的购买时间，往往也就在关键的几个小时以内。如果这样的等待经常发生，这对营业额会产生较大的冲击。

Tapdata 实时主数据服务平台 Active Master Data Platform

传统的主数据管理采用 T+1 的方式从业务系统获取源数据，加工处理后形成企业的标准数据， 并通过导出方式输送到业务系统使用。这种方案的局限性在于数据更新较为滞后。Tapdata 的实时主数据方案允许用户用实时数据管道及强大的 UDF 功能让用户可以简单的实现去重、规则判断等主数据治理功能。端到端的秒级延迟 + 自动API 服务意味着客户直接从Tapdata 获取需要的主数据。免费试用 >‍