当前快速变化的消费需求和新零售渠道的涌现，正在倒逼传统服装行业进行数字化转型。面对海量数据的存储和管理、数据架构的复杂性、全渠道数据整合的挑战以及数据库性能瓶颈等问题，企业该如何利用创新技术应对传统数据架构的局限性，加强系统的弹性与安全性，并挖掘数据分析与AI在业务流程优化中的巨大潜力？
《数字价值观察室2024 ITValue Summit特别版》圆桌对话中，钛媒体集团联合创始人、联席CEO、ITValue发起理事刘湘明邀请OceanBase CEO杨冰和雅戈尔CIO王歆，就“让业务用起来，零售数字化的价值重构及实现”这一主题展开深入对话。
王歆分享了雅戈尔在全渠道管理中的挑战和解决方案，如何通过实现货品全渠道、会员全渠道和权益全渠道来应对零售行业数字化转型带来的挑战，并强调技术架构要尽量简单化，以降低运维和开发成本，确保业务的可持续性。
杨冰介绍了OceanBase在帮助企业应对数字化转型时的优势，尤其是在处理大规模数据和应对突发流量方面的能力，如何通过分布式数据库技术帮助企业实现高效的存储、低成本和高弹性，并探讨了如何应对零售行业中实时数据分析和高并发处理等复杂需求。
本文根据圆桌对话实录整理，全面呈现了双方在数字化转型进程中的真知灼见，将为企业数字化转型提供有益借鉴。
附上本期直播时间轴，帮你快速跳转感兴趣的部分：
01:26 服装零售行业数字化转型面临的挑战05:22 数据库在助力企业转型中的作用10:12 未来应用架构设计思路的改变18:04 传统行业促销压力与数据库技术的应用27:31 零售行业的安全策略与数据库的安全设计35:02 数据分析的挑战与未来数据产品的发展46:15 AI在雅戈尔业务流程中的创新应用49:24 技术与业务融合的未来趋势及合作模式以下为圆桌对话实录，经钛媒体APP编辑：
刘湘明：大家好，欢迎来到本期数字价值观察室2024 ITValue Summit特别版——“让业务用起来，零售数字化的价值重构及实现”的圆桌讨论。
本场圆桌我们邀请到雅戈尔CIO王歆和OceanBase CEO杨冰，与我们共同探讨服装零售行业在数字化转型过程中遇到的痛点、挑战以及可能的解决方案。
服装零售行业数字化转型面临的挑战
刘湘明：现如今服装零售行业目前面临的诸多挑战，包括市场的快速变化，以及全渠道带来的库存管理、市场预测和供应链效率等问题。雅戈尔在过去几年是否也遇到了这些挑战？你们是如何应对的？
雅戈尔CIO 王歆：挑战是有的，但有一点是确定的，那就是资源共享是最大化利用资源的方式。很多人认为全渠道就是资源共享，但实际上全渠道包含三个维度：货品全渠道、会员全渠道和权益全渠道。
第一，货品全渠道。十几年前，我们把货压到线上的某个店，为单一门店去备单一的货，这个做法没问题，但是现在很难。因为特别是像平台多，且一个平台多开店。一个平台多开店过程中，不同店，不同平台之间的货品的重叠率还是非常高的。全渠道的货品渠道是分两种，一种线上全渠道，一个线下全渠道，然后我们的线上线下全渠道，就是我们分为三个维度。
比如说我有100件衣服，然后我针对天猫、京东、抖音各发布100件衣服，这时候我一看变成300件库存了，但实际上我只有100件货。然后通过技术方式同步扣减，最终达到单店购买效率最高。同样在线下模式也是一样的，我们把线下我们接近2000多家门店的库存变成一个大平台，然后完了以后，当A店没货，但是A店下单完了以后，B店来供货。线上线下融合了，我们就把线上线下库存融在一起，把线上也当成一个门店。任何一家门店需要货，直接划拨给它，这就是技术力量。如果在传统的业务手段的话，它做不到的。原因很简单，它必须得靠业务的决策，业务单据。但是通过我们全渠道，它是完完全全自动的。全渠道的第一步，我们叫货品全渠道。
第二个，会员全渠道。其实今天一个品牌会满足一类会员，但是一类会员过程中还是要分“金银铜铁”不同等级。不同等级如何做到线上线下统一？对于我们传统品牌是把所有的会员集中在一起，然后通过订单，通过行为数据，采集起来做OneID（身份识别和管理系统）。
第三，权益全渠道。一个好的服装品牌，如果它的毛利率能做到70%以上或者是80%以上，这是非常考验它对会员的服务能力。服务能力我们称之为，权益过程中你怎样去调动他的情绪，我们甚至不让他买，租给他，给他一个这样的权益。这样的话，整个会员的复购率会极其高，会员的复购的很大程度上有可能就来自你对会员权益的发放，会员权益的维护。
这是目前为止，我们雅戈尔去做全渠道过程中理解的，全渠道在传统行业中的玩法。
刘湘明：这样会不会对刚才我们谈到的这种市场的预测也会带来一些新的挑战？
雅戈尔CIO 王歆：当我的所有的东西做共享时，小的波动还继续存在，但是我通过大盘的数据来把小波动给拉平，反而对预测的要求变低了，也就是通过全渠道反倒会降低对整体市场的预测的依赖度，但不是说不要预测。
数据库在助力企业转型中的作用
刘湘明：杨总，王总刚刚提到的业务挑战对数据库提出了很多新的要求，OceanBase现在是怎么帮助企业去应对这些挑战的？
OceanBase CEO 杨冰：刚才王总这边提到几个大的渠道，按照我的理解，第一个方面，无论是会员、权益、货品，应该是汇聚了所有的品类、所有的渠道和所有的会员的一些信息，而且是几个维度的叠加，所以可能原先用一套系统或者是仅限于一个渠道的数据，它会被放大再放大，那就会有相对更海量的数据。
OceanBase本身听它的名字和它的出身，就知道我们是比较擅长干这个事情，不但能够存，还可以比较低成本和高效地去存它。以前支付宝的很多的一些数据，从普通的、传统的MySQL或Oracle搬到OceanBase上面，整个存储的成本就降到了原来的三分之一。所以我理解这个“全”带来的海量的数据，可能对于高效的存储，高性价比的存储是一方面的收益。
第二个方面，渠道系统作为背后的一套支撑系统，应该也要去支撑一些线上的活动，甚至于可能会有一些并发。如果歆总说雅戈尔本来8000块钱的西装，今天搞活动6999，有可能就会有一次小的一个波峰，如何去应对这样的弹性的突发流量，像OceanBase这样的这种分布数据库也可以做。
第三个方面，实时的交易，它是属于OLTP（混合事务/分析处理）交易型的场景。刚才提到的，可能要在不同的渠道，线上、线下、门店货品的盘点和分析，如何进行调拨，也许不需要这么实时，只是做预测，但是既然数据存在一起。我相信对于这里面数据的分析洞察的能力，以及洞察效率要求会是更高的。OceanBase正好又是一个双负载引擎，既可以支持那种像双十一弹性这样的这种TP（事务处理）的能力，同时又是可以把这个数据转化成列存的存储格式去做分析，可以更好地、更快速地去在海量数据当中实时地分析，而且它可以用一套数据。
传统的做法可能是有一套在线库，然后中间做一个传输或者ETL（提取、转换、加载），再放到一套分析库再来搞。这个中间其实会有很多断开的部分，会有很多的重复的存储，甚至会有一些不一致的地方，而运维上面任何一个环节出问题，可能都会带来很多的麻烦。OceanBase这样的一套架构，是可以在一套软件里面，把刚才说的交易，分析合并在一起，而且相对来说更高效存储、更省。
雅戈尔CIO 王歆：在2016年之前，以传统的IT架构方式是没办法做到真正意义上全渠道，那时候找到这样的人才还特别难，也特别贵，直至2019年之后，我们才认为用互联网框架的数据库，能够破解掉传统数据库所带来的那种瓶颈。当然传统数据库也在迭代，但是它们已经迭代到让我们很难消费得起。
第一个，有没有使用全渠道的能力？
第二个，有使用全渠道的能力，有没有相应的基础设施来支撑？
第三个，有基础设施在支撑过程中，是不是相应的成本来支撑？
这是目前为止我们在做商业考虑过程中会去考虑的。当然如果说技术支撑，成本基本上不用去考虑的话，那么等于说我的商业模式就少了30%的风险。做企业、做经营就是关注变量，如果你的变量越少，那么你的企业，相对来说经营越稳定。
未来应用架构设计思路的改变
刘湘明：传统的IT架构其实都是针对流程来设计的，从上往下，一层一层，其实最后才考虑的是数据库的问题。但刚才我们谈到了很多的挑战，包括这种业务的灵活性，变得其实越来越以数据为中心。你们觉得未来的这种系统的架构的设计思路，包括整个应用架构的设计思路，会不会有什么根本性的改变？
雅戈尔CIO 王歆：我在为雅戈尔未来的3到5年的技术做准备，技术不外乎是两种准备，第一个是开发框架，第二是技术框架。技术框架又分业务框架和数据库框架，我们内部的类似CTO这样的角色，就特别关注AP（分析处理）的性能。我个人认为，单纯地说AP或者说TP单一指标的话，一定找到最优秀的。
但对我来说的话，假设到目前为止，传统数据库的能力是10分，互联网框架的数据库能力是1000分，但是1000分里面又分1200分和1000分，其实1000分和1200分对我说已经不重要了。它从10分到1000分，已经上升100倍了，所以这时候我更加会看重整个技术框架的简单。当你的技术框架越简单的时候，代表你稳定的可能性越高。稳定性越高，运维的人数会越少，人数越少管理难度也变小。第二，难度减少，开发的成本也会变低。
简单目的的背后是要让业务稳定，稳定的背后是让这个生意可持续。可持续过程，第一个是我们叫客流必须可持续，第二是你的业务模式可以持续，第三个你的运维模式可持续和保持稳定，这才是我们的目的。它并不是追求极致，追求极致的是艺术家。
OceanBase CEO 杨冰：非常赞同歆总的观点，我有一个不一样的角度，我心目当中的答案是，它不是一个固定的标准，它是根据企业的不同的发展阶段，去选择它是可能应用架构优先，还是数据优先。
比方在企业的初期发展阶段，是要活下去，或者是一个创新的业务，它马上就要产生效果。这个时候不管用什么样的东西，先捞过来再说，这个时候肯定是业务优先，业务逻辑优先，这个阶段要的是快。
到了企业的稳定期，开始考虑效率、成本和规模化，如何能够进行合并同类项，来合并成一个。这个时候再去看这套系统的设计，可能会说在数据模型上和数据架构上，如何能做到精简统一，然后再去更高速地、更敏捷地去支持上层业务的开发。所以这两个阶段其实都有可能会是正确的答案。不同的阶段有可能是围绕不同的主题。
传统的数据库还是分不同的类型，今天OceanBase的理念是，以一体化的数据库去支撑业务。初期，我们也是一个全能型的六边形的战士，无论是交易型、分析型甚至于Key-Value的。像我们这种一体化的数据库，也非常适合于业务创新，拿来基本上就能用，也不会消耗你关注底下数据架构的问题。发展到后期的时候，我们又是一个两方面都比较均衡，可能在整体规模效益上面最均衡的一个数据库。
只有在最为极端的情况下，比方说，可能我们某一个系统它要去做巨量数据的分析，或者它就是用这种图的关系型是最合适的，或者它就是一个巨大的数据湖，数据仓库，这个时候它要两套或者多套的系统去支撑，但是，不是这种极端情况下，我们认为可能80%的系统，在可能后期稳态以后，也是可以收敛到一套简单的，一体化的数据库去支撑的。
我觉得无论是应用开发为中心，还是数据开发都是对的，看不同的阶段。但是回到我数据库的角度，无论是哪个阶段，像我们这样的一体化的产品，都适合企业使用。
雅戈尔CIO 王歆：要找什么样的数据库，我的答案是：互联网框架下的数据库。特别是传统行业，如果是在5-10个亿之间，其实它的IT团队也好，或者运营团队也好，都是极简的，它并不会像百亿，几千亿的企业，它会专门配。对我们来说，让数据给我们的商品提供服务，它并不是提供数据服务。未来作为我看传统行业过程中，未来3-5年它到底应该怎么发展，技术框架又回到我刚才说的这句话，极简，极简，再极简。
OceanBase CEO 杨冰：可能在数字化的蓬勃发展过程当中，很多的企业互联网化，线上化以后，确实需要这样的一些技术，但是当它使用这个技术的时候，既得到了它的好处，又为之付出了比较大的运维、复杂度和人员的成本。互联网框架下的数据库每个点可能都会有极端的场景，就需要这么一支队伍去搞，但是最后它在这么个规模下是可以均摊掉的。
比方说可能像Amazon，阿里，其实都养出来一个云部门，蚂蚁做金融和服务相关的，支付相关的，做了一个数据库出来，养了很大的一个团队，投入很大去解决这个极端的场景。它其实可以通过别的方式，把这个产品变成一个科技的东西慢慢去做。但是很多其他的一些企业，它往往是用这个技术。
我们在演进过程中，尤其从2020年，OceanBase从支付宝走到外面，接触到千行百业以后，特别明显能够感觉到很多的CIO觉得你这个东西好，我要用，但是就怕hold不住它的复杂性。所以我们就把自己从一个大型的武器，变成一个分布式单机一体的，变小了，而且把AP和TP这些能力就吸收进来，然后在使用和运维界面上，尽可能地简单，让它可以既享受到互联网的技术带来的红利，同时又屏蔽掉这个复杂度。
不光是OLTP（在线事务处理）在做HTAP（混合事务/分析处理），纯这个数据分析的领域，在提湖仓一体，数据也在结构化、非结构化放在一起。前面比较经典的叫Lambda架构计算，离线一套，实时一套，后来走到kappa，现在说流批一体，还在继续演进……所以计算的框架也在收敛，都在往简单，合并同类相，然后一体化给业务去支撑，但是屏蔽复杂度这个方向在发展。
刘湘明：对传统行业来说，业务面临的变量已经非常多了。技术产品应该尽量简化，减少不必要的技术变量，从而腾出精力应对不断变化的业务需求和复杂场景。
传统行业促销压力与数据库技术的应用
刘湘明：对于互联网公司来说，像阿里的"双十一"大促这种极端场景，是考验系统极限性能的典型案例。王总，雅戈尔会不会面临类似的订单激增挑战，导致系统承受巨大的峰值压力？
雅戈尔CIO 王歆：其实“双十一”对传统行业的压力不大，因为海量的访问，海量的订单都是在平台产生。对我们来说，今天针对于这10万个订单如何做售前，如何做售中，如何做售后，这个压力很大。
“双十一”这种高峰的销售过程中，我认为它并不是销售利润的获取，我更加会把这种场景比喻成我们业务团队的一次“团建”。通过这样的一次高峰的销售过程中，去演练了我们整体的、全公司的、所有部门的相互协同，这是我认为这种洪峰对我们的挑战。放到我们的IT系统过程中，我们订单系统、HR、OA、财务上面是否需要做一些改变，退款过程中，是否把退款的东西和前端系统打通。
这里面需要合规合矩，如果没有业务限制，IT无所不能，因为信息就是搬过来搬过去。所谓的传统IT为什么建设起来又比较难，因为你要踩在合规合纪的界限之内，但是很多界限又是很模糊的，可做可不做，对我们来说这是个挑战。正好是可以通过“双十一”这样一个大的业务战役，去训练我们符合当前整体的业务的发展。
OceanBase CEO 杨冰：我其实感受跟歆总是一样的，OceanBase一开始出来的时候觉得是一个大杀器，但是走到各行各业的时候会发现，大家对于绝对的性能和吞吐量是没有诉求的，我一会分享两个很有意思的场景。
我觉得雅戈尔这边之所以没有促销带来系统压力，开个玩笑，可能两个原因，一方面，歆总系统建设得比较强，第二个他没有把1万块钱的西装打到5000块钱，打到5000块钱我估计也爆了，甚至小程序可能也需要这个弹性。OceanBase一方面是它绝对的吞吐量，另外一方面是对于明显有脉冲式特征的这些业务，平滑的伸缩的能力。不打扰业务的情况下，能够为你准备一部分机器，不要的情况收缩过来的这部分，其实跟零售，服饰相关，用得大。
我举一个泡泡玛特的例子，抽盲盒和抽奖是一样的，比如今天会预告有可能抽到什么样的盲盒，顾客就会被吸引过来。那个量可能是几万分之一于“双十一”，但是对泡泡玛特来说，如果活动安排在周五，与前四天相比，参与人数可能会激增至100倍，就会形成一个波峰。
以前它可能用传统的数据库，它痛苦的是说，第一，传统的数据库要去干这件事情，提前一天到晚上停一下机，起码是分钟级的，会影响业务的。当天就处理，处理完了还不能停，因为业务还在做，而且可能它还会有小活动，累加来个高峰。到了晚上，顾客可能会抽到凌晨一两点钟，处理完、运维、上线，把它再缩回来，第二天处理，一来一回三天的时间，其实它的成本是从第一天开始计算，连续乘三天，几套、几十套，或者是高配的机器放在那儿。
但今天我们完全可以无缝、无管地在业务进行的过程中完成，泡泡玛特用了OceanBase以后，三个小时就搞定了，它的成本就是那个时候的规格乘以3。对于促销形态的这种业务，OceanBase可以更好地、更经济地、灵活地去响应。
这个例子怎么样顶住流量，第二个例子，是怎么样通过优惠券和促销的方式引来流量。前端的流量被平台扛住了，但是可能接下去的发货和处理，可能要批量地去操作。我们跟一家国际知名咖啡零售品牌合作的时候，其实也遇到了发优惠券等等这种促销的活动，
这家咖啡零售品牌，平时不发券，但过年过节它会发券，它扛的不是那种“双十一”的流量，但是也要在很短的时间内去促销、去发券。发券其实本质上是一个批量的insert，操作完还要update去核销掉。以前它的系统吞吐量有限，就每个礼拜每天发一点，一个礼拜把券发完，前前后后可能要好几周。但是如果今天上午老板就拍运营方案， IT可能要在下午几个小时内，把上亿张券全部发完，不同的维度还要去做分析，其实它旧的系统是做不到。后来它后面批量处理的一些系统改造成OceanBase以后，发券核销也体现出来OceanBase在“双十一”促销中弹性的能力。
第一，我在各行各业应用的时候，不看它的绝对量，但看它的伸缩能力。第二个，我也不仅仅是支持Front-end（前端）的系统，其实在Back-end（后端）去批处理也很多。白天支持订单，晚上盘货，银行是白天支持交易，晚上批处理做结算，其实这样的场景非常的多，这是OceanBase动态伸缩的能力的体现。
雅戈尔CIO 王歆：之前我在滔搏，最痛苦是限量款的售卖。每次去做发售的时候，都要在OA上填写升级服务器，我们有统一的运维中心，运维中心是按照升级服务器的量和时间来给我们算成本。每次升级完成了，他们都会要求我们整个APP宕机。直到2021年的时候，我们发现这些事情是可以得到解决，类似于像这种叫互联网框架下的数据库。
零售行业的安全策略与数据库的安全设计
刘湘明：其实安全现在还是很多CIO的头等大事，尤其是前段时间微软蓝屏，连航班都出问题，影响还是非常大的。从零售行业角度，各位对有什么安全看法？
雅戈尔CIO 王歆：我对安全，有四种情况的分析。
第一种情况叫做有防护措施，无安全的管理办法，那叫赌博。
第二种情况叫做有安全状态，无防护措施，你只能靠运气。
第三种情况叫做有防护措施，有安全形态，这才是真正意义上的安全。
第四种情况叫做无管理状态，无防护措施。
所以说我就把整体的建设过程就分两种，第一，在基础的安全防护过程中，投入成本是无底洞，我在内部的跟我们管安全的说，不建议自建机房，因为自建机房所有的安全措施都要自己保证。花同样的成本或者是更少成本反而可以上云，本身云上面的技术安全已经非常强大。
第二，应用安全性。它更多的是考虑你的业务规则，但凡碰见有被薅羊毛的可能性的时候，我们就要拿业务去跟技术部门做个评估，怎么样防止舞弊，这是应用安全性。
第三，数据安全。比如处理员工的个人信息是非常敏感的。在传统数据库很复杂，需要写一套代码，再把敏感信息的屏蔽掉。互联网框架，它只是一个组件，只要定义这个表是敏感的一个表，就必须要输一个类似于key，应用才能够调拨得出来。
安全过程中一方面是通过更好的工具，第二方面是要加强安全意识，第三如果说技术安全，我们普通的用户再怎么做，也是做不过像云厂商这样的级别。所以说总结下来就是相信云厂商，安全意识普及以及尽可能利用互联网框架下面的安全套件。
OceanBase CEO 杨冰：我形容安全其实是叫“买保险”，安全其实没有一个绝对的安全，看你为这件事情愿意买多高程度的保险，100万还是200万？对于支付宝来说，可能每一笔交易每一个金额，它可能涉及到的金额是非常大，就是我们整个架构的设计理念是说，我愿意为这件事情买更多的保险，来确保事情。
安全层面另外一个维度，你尽可能杜绝那些日常会发生的常规性的、低级的安全错误。第二个可能还是要考虑黑天鹅事件，这个事情理论上花很多的钱应该也能解决，或者是你把效率变慢，你也是能解决，但是不能这么做。
我站在OceanBase的角度说两个理念， OceanBase做的是分布数据库，分布数据本质上是多个Replica，多个冗余或者是多个分片，它本身解决分布式的同时，其实是在解决安全性可靠性的问题，因为多个副本。以前像数据库层面上的这种问题，它再出个故障，它应该是属于叫做黑天鹅事件，就是小概率事件。它的设计理念是，如果出问题，只要能切人为，主备切换等等，时间什么不考虑，但是数据别丢就行。
但是在现在互联网的场景下面，可能很多东西线上化了以后，你需要把你的系统部署在本身可靠性没有那么高的X86上面，这个时候机器的故障、存储的故障、网卡的故障是乘以一个数量以后，它这个概率就变成1，变成一个常规性的事件。
所以今天的数据库在应对这种常规性的事件时，OceanBase用这种Paxos算法在设计的时候，就把这种故障的场景当作我们常态的一个场景，一旦出现问题就自动切，不要人为介入，而且我们认为随时随地都可能发生，所以去消除掉。当它的故障概率变高了，我们要用另外一种设计，把常规性的顾虑给解决掉。但是刚才提到的像微软这种黑天鹅事件，我觉得这个东西就是一个成本问题。
云，我认为已经是非常安全的，但在极其极端的情况下，可能某一个机房、某一个网络甚至某一个可能冷却管出现故障就会动摇安全。这个时候对于一家企业来说，它是不愿意承受这个成本。它可以考虑说我能不能用十分之一的成本，来把黑天鹅的事件再降低到百分之一、千分之一甚至于万分之一。
OceanBase除了架在云上，本身享受到云的安全性的同时，我的异构的能力，你另外一个副本放在云上，还是放在别的一个云上，可能十分之一的量，其实是可以帮 CIO在比较可控的成本上，来解决黑天鹅事件，这个也是OceanBase的设计理念和架构理念。
数据分析的挑战与未来数据产品的发展
刘湘明：个性化推荐、库存优化和市场预测等领域对分析的要求越来越高。你在实际运营中，如何看待对分析的期望？尤其在实时数据分析和判断方面，目前存在哪些技术挑战？你对未来数据产品的预期是什么？
雅戈尔CIO 王歆：企业不论是采用交易数据、行为数据还是决策数据，它们都有一个获取过程，这些数据变成知识的时候，实际上获取的成本太高。因为整个数据它是有分权结构，分领域。第二个，分析的数据是跨领域，第三个，分析的数据的颗粒度有可能导致数据量比较大，这是导致获取数据难度的三个维度。
第一个维度，能不能够让数据跨域？类似于以搜索模式来获取数据，这就牵涉到一个大模型和一个新的数据库，向量数据库。如果能够提供这样的工具，整个分析能力是否能得到释放？得到释放是能得出更多的洞察，得出更多的洞察是不是能产生更多可能的商业模式？得到更多商业模式，是不是可能产生更多的数据，产生更多的数据，是不是对某个数据的分析过程中就产生更多的维度？
这个过程中就可能产生奇点，我的管理奇点，我的分析奇点来临时，商业模式就会发生变化了。一旦它的商业发生模式发生变化，我们又产生了一系列东西，让数据多跑路，人少跑路。这才是目前为止我们称之为，在数据的维度上面，我们去考虑这个事情。总结下来第一件事情，我去解决整个数据的交互界面，能不能够从领域的方式变成一个数字模式？
第二个维度，解决完了以后，会产生巨量分析路径，能不能把跨领域流程做聚合，流程聚合就是把所有管理的东西全都让机器跑，让所有的时间和精力全留给业务的，我们叫交互简单，流程聚合。
第三个维度，流程聚合又可以做件事情，数字员工，它的管理成本极低。但是不是能产生好的商业模式，不知道。
只有数据流通，才能够真正产生交互极简、流程聚合、数字经营的三种场景，才能最终产生企业价值。
刘湘明：其实刚才谈到这种分析，矛盾在于我们永远需要更多的数据，又要更快的这种过程，然后更精准的结果，但是这个矛盾我觉得也是数据库的一个机会。OceanBase是怎么解决这个悖论的？
OceanBase CEO 杨冰：王歆总是要更自然、更友好的一个交互，其中有一个维度就是更快更敏捷更自然，由于这件事情被精简掉了，它两秒钟就可以给我回答。如果说它是要做非常详细的东西，它就要等很长时间，所以未来的交互当中，它需要简单，快捷。
快，就需要汇聚做分析，这就是数据库可能要做的另外一个工作，不是交易。以前我们去做这种分析的时候，往往是拉出来另外一套系统去做，所以当年数据库做着做着发现，做大量数据分析的时候，传统的架构就搞不定了，就变成了MPP（大规模并行处理）这种架构。
现在说分布式数据库，其实挺奇怪的，因为你只要是去看大数据型和分析型，没有人说什么分布式的大数据，大数据天然就是分布式的。只有讲交易的时候才有分布式，我们是后面在交易这条线慢慢才把它搞定。
以前的做法就是说，先不考虑快，先把它变成T+1的，然后让它给你一张报表，给你一个分析的东西，但后来需要更敏捷、更快的东西，所以大家会发现OLTP的方向慢慢成熟了，它可以支持海量，同时又有一个湖仓，但是在这两个大的分水岭的系统中间出现了一段Real-Time Analysis，就是实时分析，实时出仓。这个有可能是从TP这长出来，直接就可以在这做分析，甚至于物化视图，直接就给你答案。也可以是说你原先是T+1，我在这个基础上再加一个报表的离线加速，然后更快地回答，这两种都可以。
今天OceanBase的技术发展路线，我是从TP起家的，为了去响应未来快的这种需求，让数据少走路，我帮你用另外一个引擎分析，完成，从而更快地去响应。我觉得这是一个更符合现代企业对于系统的要求，也更符合未来人工智能介入以后的要求。
另一方面，歆总提到要流程更加能够串起来，让机器或者Agent的把这些东西都处理了。以前确实也有一个问题，如果说数据库不做任何的改变，这件事情也能做，但它比较痛苦的是A、B、C、D 4个系统它把它全部抓起来。对于一件事物的描述，它是有不同维度的，但有些可能是用关系型的，有些可能是一张照片，一段视频，有些可能还加上时间轴，它会有不同的切片。但是当它要去对这件事情做分析，给他一个答案的时候，是要把这些东西全部汇总起去处理，这个时候Agent就发现大量的数据孤岛，描述的是一件事情。所以今天我们除了让它更快长出不同的引擎来，也要做多模态的融合。就像AI最初是Chat，后来是图生文、图生音频等等，它是多模态，下一步是世界模型，彻底理解这个世界给你答案。
第三，刚才提到的向量数据库，因为物理世界越来越容易把它被映射成一个向量，而且这个向量容易被人家理解。今天我跟它说一段话，以前让AI去分析，可能准确率是50%，今天可能是98%，这个时候我能干的事情就非常多了。
所以物理世界映射到数字世界以后，它的理解力增加多了一个向量，向量对于一件事情的刻画，也可以融合到以前这种结构化的数据当中，然后给出一个综合的评判。所以今天OceanBase也把向量能力集成进去，也算是我们多模态的一个延伸。过去结构化和非结构化的数据存在不同的地方的，但今天我们试图把这两者合在一起。
这个有机结合在两个层面，第一个是数据结构这个层面，能不能用更少的成本，更少的空间，存一份数据，但是不同的刻画维度，这个时候是更有机的一个模式，让它可以更快。第二个这些数据合在一起以后，对于AI的交互界面这一层来说，能不能更有机地结合？如果说你用SQL（结构化查询语言），你把所有的东西都可以描述成人类语言或者类SQL的方式插进来，然后我反正无论是图片还是什么，我都可以帮你去想，其实也是一种有机融合，但如果是3个组件或者5个组件，那就只能在Application上去做，因为复杂度就高，而且它也不是那么高效，不那么有机。
AI在雅戈尔业务流程中的创新应用
刘湘明：杨总刚刚讲了从数据库的角度怎么去适配未来AI，雅戈尔在AI上面现在做了些什么样的布局？
雅戈尔CIO 王歆：去年我们雅戈尔的整体销售收入是1916亿，超过10个亿体量的组织，每个组织内部的流程，类似于应用，有300个左右，其中 80%都完全有可能被AI重新定义。
我们在商品售卖过程中，有很重要的一个名词叫FAB，可以理解成每件产品都有一个说明书，这个说明书会产生导购的话术，每件衣服的FAB正常情况下，都有20页的描述，就描述的面料，场景等。一季有400个款，400×20页是8000页，8000页的话你让一个导购看完的话，而且是那么枯燥的书，那是不可能的。
AI来了以后，直接把8000页内容扔到大模型，再生成一个FAB助理，顾客来了，只要去拍选择的那件衣服， Agent就给他产生一个100字的推荐，就改善了一个销售服务的动作，这是目前为止我们在雅戈尔已经做的事情。
雅戈尔西服的良品率达到99.8%。所有的衣服在出厂之前，都要做个质检，质检总共有8个动作，怎么确保质检人员把8个动作检测到了，也是通过图像的AI，来解决这个问题。
我的结论是，传统行业的所有的业务流程，都可以基于AI技术改造，基于目前为止的AI能力，就是说可能我们还没想象到，或者AI能力还不够强，所以说你还没办法做改造，但是这个能力是未来已来，马上就要来临。我们有没有这样的思路，我们有没有这样的准备，我们有没有这样的Ready For AI？
技术与业务融合的未来趋势及合作模式
刘湘明：今年峰会除了AI之外，大家谈特别多的就是场景。虽然OceanBase现在在金融行业做得非常好，但是还在进军很多新的行业，在这类行业怎么找到真正发挥的场景，其实需要一些创新的这种思维，我一直觉得未来甲方，乙方，技术提供方和这种用户之间的合作方式，可能会有一些变化，你们怎么看待这个问题？
雅戈尔CIO 王歆：今天我们说业务场景，场景我们就定义为是业务。业务经营，我们叫微服务，一个场景可能调用几个微服务，高频被重复使用的服务叫微服务。所有零售行业里面，都会有类似于叫进销存。如果今天杨总说，和我们在这行业里面做共创，完全不在乎目前为止产生的成本，一定要找适合的场景。在所有的零售行业里面，最底层的管理就是进销存，我能不能把进销存做成一个组件，内置到数据库的插件里面去，那变成微服务了。
从这个角度看，首先有可能改变零售行业进销存管理过程中，运算速度和业务复杂度，把这些全放到PaaS（平台即服务）层面上来，把它解决一部分加一点类似于SaaS（软件即服务）的公共组件。那时候你颠覆的不仅仅是数据库，甚至有可能颠覆SaaS层面的东西。
但是从我的直观角度看，未来所谓的人工智能的发展，不仅解决我们现有业务解决不了问题，它更要解决现有业务解决了的问题。让它更加有效率，让它更加简单。
OceanBase CEO 杨冰：场景我觉得是厂商和业务方双向奔赴的一个过程，我脑海里有这么一个框架，比较偏术这个层面上。
第一，作为我们这样的厂商，我要立一个旗子说我是谁，我要告诉所有的CIO，我是一个什么不一样的产品，有一些 特别的设计理念，这个东西可以让大家在理念层和方向层达成一致，他才会有兴趣来找我聊一聊。
第二个层，我希望能跟更多像王歆，还有其他的这种零售行业的CIO去聊一聊，就像我过去几年更多跟银行、保险、基金这些CIO聊得多。就是我们既然要进入一个行业，一定是要共创。甚至于说刚才歆总提到的说，某些场景大家可以不惜代价去做，然后来创造一个东西，它不是生意，它是一个如何颠覆行业这样的事情，我们是愿意去干的。
第三层我觉得可能光找歆总这样的圈层的人还不够，因为这个行业当中有两种类型，第一种类型是说能力比较强的，而且是很强定制化的需求，还有一部分是比较标准化，它可能是靠ISV（独立软件供应商）一套系统就搞定了。
比如说我们现在跟像伯俊，或者是可能像百胜这样一些公司，可能它就对于这个行业，有非常好的抽象和洞见。他们也在寻找AI能力加进来以后，怎么样去改变这个行业，让它更高效。所以可能今天只是提了那几个刚才的案例，其实我们在零售行业的案例其实还蛮多的，这个案例其实就是在跟他们共创的过程当中发现的。他说你竟然可以这样，我如果说在这个场景用了你，我可以更高效、更快速的方式服务于他的一些客户。再往下down一层的层面，就是顶层的定义，CIO层面上的共创。
另外，OceanBase是开源的，这是一个最细颗粒跟开发者之间的东西，我也不知道一体化了以后，加了一个向量，一个地理位置信息，放在一个数据库里面，会有什么样的惊喜。
第三，这个场景，这个能力变成一个插件，插到OceanBase，我觉得这是有可能的。但每一层都有边界，这个东西是不是插在OceanBase里面，我们确实要考虑一下，但这个东西一定会有。我们可能的想法就是说，这个东西如果适合在数据库上改变，我把它拿下来，集成上去。
今天OceanBase也不一定要只是一家数据库公司，现在最牛的 Oracle，它其实也是非常立体的一家公司的话，有数据库、中间件、PaaS甚至SaaS。今天可能有些东西有价值，有没有可能跟其他公司一起去合作，做成一个联合解决方案。甚至于说我把这个产品我就买进来，不一定要自己做，但是我这个插件是放在另外一层PaaS，甚至于SaaS这层，合在一起，对于零售行业去提供一种全新的解决方案，所以这也是我们的选项之一。
我希望有一天零售行业，甚至于其他更多的行业的CIO，哪天在做技术选型和升级的时候，目前金融行业已经有一定这样的现象了，发现报上来的数据库的列表当中没有OceanBase，他会问一下你有没有测过OceanBase？在选型的时候说，这个行业OceanBase还是有点特色的，你可以试试看。如果说做到这一点，说明我们这条路走对了。
刘湘明：今天其实谈了既要、又要、都要、全要，其实从安全、成本、创新、增长大家都在谈，而且能够看到业务和数据已经变得密不可分了，一体两面。这边看是业务，翻过来是数据，这两边怎么去融合去协作，结合AI其实还有很多想象的空间……
以上为《数字价值观察室2024ITValue Summit特别版：让业务用起来，零售数字化的价值重构及实现》部分内容，完整版请观看《让业务用起来，零售数字化的价值重构及实现》。（本文首发于钛媒体App，作者：唐刚 编辑：华楠）
