當前快速變化的消費需求和新零售渠道的涌現(xiàn)，正在倒逼傳統(tǒng)服裝行業(yè)進行數(shù)字化轉型。面對海量數(shù)據(jù)的存儲和管理、數(shù)據(jù)架構的復雜性、全渠道數(shù)據(jù)整合的挑戰(zhàn)以及數(shù)據(jù)庫性能瓶頸等問題，企業(yè)該如何利用創(chuàng)新技術應對傳統(tǒng)數(shù)據(jù)架構的局限性，加強系統(tǒng)的彈性與安全性，并挖掘數(shù)據(jù)分析與AI在業(yè)務流程優(yōu)化中的巨大潛力？

《數(shù)字價值觀察室2024 ITValue Summit特別版》圓桌對話中，鈦媒體集團聯(lián)合創(chuàng)始人、聯(lián)席CEO、ITValue發(fā)起理事劉湘明邀請OceanBase CEO楊冰和雅戈爾CIO王歆，就“讓業(yè)務用起來，零售數(shù)字化的價值重構及實現(xiàn)”這一主題展開深入對話。

王歆分享了雅戈爾在全渠道管理中的挑戰(zhàn)和解決方案，如何通過實現(xiàn)貨品全渠道、會員全渠道和權益全渠道來應對零售行業(yè)數(shù)字化轉型帶來的挑戰(zhàn)，并強調技術架構要盡量簡單化，以降低運維和開發(fā)成本，確保業(yè)務的可持續(xù)性。

楊冰介紹了OceanBase在幫助企業(yè)應對數(shù)字化轉型時的優(yōu)勢，尤其是在處理大規(guī)模數(shù)據(jù)和應對突發(fā)流量方面的能力，如何通過分布式數(shù)據(jù)庫技術幫助企業(yè)實現(xiàn)高效的存儲、低成本和高彈性，并探討了如何應對零售行業(yè)中實時數(shù)據(jù)分析和高并發(fā)處理等復雜需求。

本文根據(jù)圓桌對話實錄整理，全面呈現(xiàn)了雙方在數(shù)字化轉型進程中的真知灼見，將為企業(yè)數(shù)字化轉型提供有益借鑒。

附上本期直播時間軸，幫你快速跳轉感興趣的部分：

01:26 服裝零售行業(yè)數(shù)字化轉型面臨的挑戰(zhàn)05:22 數(shù)據(jù)庫在助力企業(yè)轉型中的作用10:12 未來應用架構設計思路的改變18:04 傳統(tǒng)行業(yè)促銷壓力與數(shù)據(jù)庫技術的應用27:31 零售行業(yè)的安全策略與數(shù)據(jù)庫的安全設計35:02 數(shù)據(jù)分析的挑戰(zhàn)與未來數(shù)據(jù)產品的發(fā)展46:15 AI在雅戈爾業(yè)務流程中的創(chuàng)新應用49:24 技術與業(yè)務融合的未來趨勢及合作模式

以下為圓桌對話實錄，經鈦媒體APP編輯：

劉湘明：大家好，歡迎來到本期數(shù)字價值觀察室2024 ITValue Summit特別版——“讓業(yè)務用起來，零售數(shù)字化的價值重構及實現(xiàn)”的圓桌討論。

本場圓桌我們邀請到雅戈爾CIO王歆和OceanBase CEO楊冰，與我們共同探討服裝零售行業(yè)在數(shù)字化轉型過程中遇到的痛點、挑戰(zhàn)以及可能的解決方案。

服裝零售行業(yè)數(shù)字化轉型面臨的挑戰(zhàn)

劉湘明：現(xiàn)如今服裝零售行業(yè)目前面臨的諸多挑戰(zhàn)，包括市場的快速變化，以及全渠道帶來的庫存管理、市場預測和供應鏈效率等問題。雅戈爾在過去幾年是否也遇到了這些挑戰(zhàn)？你們是如何應對的？

雅戈爾CIO 王歆：挑戰(zhàn)是有的，但有一點是確定的，那就是資源共享是最大化利用資源的方式。很多人認為全渠道就是資源共享，但實際上全渠道包含三個維度：貨品全渠道、會員全渠道和權益全渠道。

第一，貨品全渠道。十幾年前，我們把貨壓到線上的某個店，為單一門店去備單一的貨，這個做法沒問題，但是現(xiàn)在很難。因為特別是像平臺多，且一個平臺多開店。一個平臺多開店過程中，不同店，不同平臺之間的貨品的重疊率還是非常高的。全渠道的貨品渠道是分兩種，一種線上全渠道，一個線下全渠道，然后我們的線上線下全渠道，就是我們分為三個維度。

比如說我有100件衣服，然后我針對天貓、京東、抖音各發(fā)布100件衣服，這時候我一看變成300件庫存了，但實際上我只有100件貨。然后通過技術方式同步扣減，最終達到單店購買效率最高。同樣在線下模式也是一樣的，我們把線下我們接近2000多家門店的庫存變成一個大平臺，然后完了以后，當A店沒貨，但是A店下單完了以后，B店來供貨。線上線下融合了，我們就把線上線下庫存融在一起，把線上也當成一個門店。任何一家門店需要貨，直接劃撥給它，這就是技術力量。如果在傳統(tǒng)的業(yè)務手段的話，它做不到的。原因很簡單，它必須得靠業(yè)務的決策，業(yè)務單據(jù)。但是通過我們全渠道，它是完完全全自動的。全渠道的第一步，我們叫貨品全渠道。

第二個，會員全渠道。其實今天一個品牌會滿足一類會員，但是一類會員過程中還是要分“金銀銅鐵”不同等級。不同等級如何做到線上線下統(tǒng)一？對于我們傳統(tǒng)品牌是把所有的會員集中在一起，然后通過訂單，通過行為數(shù)據(jù)，采集起來做OneID（身份識別和管理系統(tǒng)）。

第三，權益全渠道。一個好的服裝品牌，如果它的毛利率能做到70%以上或者是80%以上，這是非?？简炈鼘T的服務能力。服務能力我們稱之為，權益過程中你怎樣去調動他的情緒，我們甚至不讓他買，租給他，給他一個這樣的權益。這樣的話，整個會員的復購率會極其高，會員的復購的很大程度上有可能就來自你對會員權益的發(fā)放，會員權益的維護。

這是目前為止，我們雅戈爾去做全渠道過程中理解的，全渠道在傳統(tǒng)行業(yè)中的玩法。

劉湘明：這樣會不會對剛才我們談到的這種市場的預測也會帶來一些新的挑戰(zhàn)？

雅戈爾CIO 王歆：當我的所有的東西做共享時，小的波動還繼續(xù)存在，但是我通過大盤的數(shù)據(jù)來把小波動給拉平，反而對預測的要求變低了，也就是通過全渠道反倒會降低對整體市場的預測的依賴度，但不是說不要預測。

數(shù)據(jù)庫在助力企業(yè)轉型中的作用

劉湘明：楊總，王總剛剛提到的業(yè)務挑戰(zhàn)對數(shù)據(jù)庫提出了很多新的要求，OceanBase現(xiàn)在是怎么幫助企業(yè)去應對這些挑戰(zhàn)的？

OceanBase CEO 楊冰：剛才王總這邊提到幾個大的渠道，按照我的理解，第一個方面，無論是會員、權益、貨品，應該是匯聚了所有的品類、所有的渠道和所有的會員的一些信息，而且是幾個維度的疊加，所以可能原先用一套系統(tǒng)或者是僅限于一個渠道的數(shù)據(jù)，它會被放大再放大，那就會有相對更海量的數(shù)據(jù)。

OceanBase本身聽它的名字和它的出身，就知道我們是比較擅長干這個事情，不但能夠存，還可以比較低成本和高效地去存它。以前支付寶的很多的一些數(shù)據(jù)，從普通的、傳統(tǒng)的MySQL或Oracle搬到OceanBase上面，整個存儲的成本就降到了原來的三分之一。所以我理解這個“全”帶來的海量的數(shù)據(jù)，可能對于高效的存儲，高性價比的存儲是一方面的收益。

第二個方面，渠道系統(tǒng)作為背后的一套支撐系統(tǒng)，應該也要去支撐一些線上的活動，甚至于可能會有一些并發(fā)。如果歆總說雅戈爾本來8000塊錢的西裝，今天搞活動6999，有可能就會有一次小的一個波峰，如何去應對這樣的彈性的突發(fā)流量，像OceanBase這樣的這種分布數(shù)據(jù)庫也可以做。

第三個方面，實時的交易，它是屬于OLTP（混合事務/分析處理）交易型的場景。剛才提到的，可能要在不同的渠道，線上、線下、門店貨品的盤點和分析，如何進行調撥，也許不需要這么實時，只是做預測，但是既然數(shù)據(jù)存在一起。我相信對于這里面數(shù)據(jù)的分析洞察的能力，以及洞察效率要求會是更高的。OceanBase正好又是一個雙負載引擎，既可以支持那種像雙十一彈性這樣的這種TP（事務處理）的能力，同時又是可以把這個數(shù)據(jù)轉化成列存的存儲格式去做分析，可以更好地、更快速地去在海量數(shù)據(jù)當中實時地分析，而且它可以用一套數(shù)據(jù)。

傳統(tǒng)的做法可能是有一套在線庫，然后中間做一個傳輸或者ETL（提取、轉換、加載），再放到一套分析庫再來搞。這個中間其實會有很多斷開的部分，會有很多的重復的存儲，甚至會有一些不一致的地方，而運維上面任何一個環(huán)節(jié)出問題，可能都會帶來很多的麻煩。OceanBase這樣的一套架構，是可以在一套軟件里面，把剛才說的交易，分析合并在一起，而且相對來說更高效存儲、更省。

雅戈爾CIO 王歆：在2016年之前，以傳統(tǒng)的IT架構方式是沒辦法做到真正意義上全渠道，那時候找到這樣的人才還特別難，也特別貴，直至2019年之后，我們才認為用互聯(lián)網框架的數(shù)據(jù)庫，能夠破解掉傳統(tǒng)數(shù)據(jù)庫所帶來的那種瓶頸。當然傳統(tǒng)數(shù)據(jù)庫也在迭代，但是它們已經迭代到讓我們很難消費得起。

第一個，有沒有使用全渠道的能力？

第二個，有使用全渠道的能力，有沒有相應的基礎設施來支撐？

第三個，有基礎設施在支撐過程中，是不是相應的成本來支撐？

這是目前為止我們在做商業(yè)考慮過程中會去考慮的。當然如果說技術支撐，成本基本上不用去考慮的話，那么等于說我的商業(yè)模式就少了30%的風險。做企業(yè)、做經營就是關注變量，如果你的變量越少，那么你的企業(yè)，相對來說經營越穩(wěn)定。

未來應用架構設計思路的改變

劉湘明：傳統(tǒng)的IT架構其實都是針對流程來設計的，從上往下，一層一層，其實最后才考慮的是數(shù)據(jù)庫的問題。但剛才我們談到了很多的挑戰(zhàn)，包括這種業(yè)務的靈活性，變得其實越來越以數(shù)據(jù)為中心。你們覺得未來的這種系統(tǒng)的架構的設計思路，包括整個應用架構的設計思路，會不會有什么根本性的改變？

雅戈爾CIO 王歆：我在為雅戈爾未來的3到5年的技術做準備，技術不外乎是兩種準備，第一個是開發(fā)框架，第二是技術框架。技術框架又分業(yè)務框架和數(shù)據(jù)庫框架，我們內部的類似CTO這樣的角色，就特別關注AP（分析處理）的性能。我個人認為，單純地說AP或者說TP單一指標的話，一定找到最優(yōu)秀的。

但對我來說的話，假設到目前為止，傳統(tǒng)數(shù)據(jù)庫的能力是10分，互聯(lián)網框架的數(shù)據(jù)庫能力是1000分，但是1000分里面又分1200分和1000分，其實1000分和1200分對我說已經不重要了。它從10分到1000分，已經上升100倍了，所以這時候我更加會看重整個技術框架的簡單。當你的技術框架越簡單的時候，代表你穩(wěn)定的可能性越高。穩(wěn)定性越高，運維的人數(shù)會越少，人數(shù)越少管理難度也變小。第二，難度減少，開發(fā)的成本也會變低。

簡單目的的背后是要讓業(yè)務穩(wěn)定，穩(wěn)定的背后是讓這個生意可持續(xù)?？沙掷m(xù)過程，第一個是我們叫客流必須可持續(xù)，第二是你的業(yè)務模式可以持續(xù)，第三個你的運維模式可持續(xù)和保持穩(wěn)定，這才是我們的目的。它并不是追求極致，追求極致的是藝術家。

OceanBase CEO 楊冰：非常贊同歆總的觀點，我有一個不一樣的角度，我心目當中的答案是，它不是一個固定的標準，它是根據(jù)企業(yè)的不同的發(fā)展階段，去選擇它是可能應用架構優(yōu)先，還是數(shù)據(jù)優(yōu)先。

比方在企業(yè)的初期發(fā)展階段，是要活下去，或者是一個創(chuàng)新的業(yè)務，它馬上就要產生效果。這個時候不管用什么樣的東西，先撈過來再說，這個時候肯定是業(yè)務優(yōu)先，業(yè)務邏輯優(yōu)先，這個階段要的是快。

到了企業(yè)的穩(wěn)定期，開始考慮效率、成本和規(guī)模化，如何能夠進行合并同類項，來合并成一個。這個時候再去看這套系統(tǒng)的設計，可能會說在數(shù)據(jù)模型上和數(shù)據(jù)架構上，如何能做到精簡統(tǒng)一，然后再去更高速地、更敏捷地去支持上層業(yè)務的開發(fā)。所以這兩個階段其實都有可能會是正確的答案。不同的階段有可能是圍繞不同的主題。

傳統(tǒng)的數(shù)據(jù)庫還是分不同的類型，今天OceanBase的理念是，以一體化的數(shù)據(jù)庫去支撐業(yè)務。初期，我們也是一個全能型的六邊形的戰(zhàn)士，無論是交易型、分析型甚至于Key-Value的。像我們這種一體化的數(shù)據(jù)庫，也非常適合于業(yè)務創(chuàng)新，拿來基本上就能用，也不會消耗你關注底下數(shù)據(jù)架構的問題。發(fā)展到后期的時候，我們又是一個兩方面都比較均衡，可能在整體規(guī)模效益上面最均衡的一個數(shù)據(jù)庫。

只有在最為極端的情況下，比方說，可能我們某一個系統(tǒng)它要去做巨量數(shù)據(jù)的分析，或者它就是用這種圖的關系型是最合適的，或者它就是一個巨大的數(shù)據(jù)湖，數(shù)據(jù)倉庫，這個時候它要兩套或者多套的系統(tǒng)去支撐，但是，不是這種極端情況下，我們認為可能80%的系統(tǒng)，在可能后期穩(wěn)態(tài)以后，也是可以收斂到一套簡單的，一體化的數(shù)據(jù)庫去支撐的。

我覺得無論是應用開發(fā)為中心，還是數(shù)據(jù)開發(fā)都是對的，看不同的階段。但是回到我數(shù)據(jù)庫的角度，無論是哪個階段，像我們這樣的一體化的產品，都適合企業(yè)使用。

雅戈爾CIO 王歆：要找什么樣的數(shù)據(jù)庫，我的答案是：互聯(lián)網框架下的數(shù)據(jù)庫。特別是傳統(tǒng)行業(yè)，如果是在5-10個億之間，其實它的IT團隊也好，或者運營團隊也好，都是極簡的，它并不會像百億，幾千億的企業(yè)，它會專門配。對我們來說，讓數(shù)據(jù)給我們的商品提供服務，它并不是提供數(shù)據(jù)服務。未來作為我看傳統(tǒng)行業(yè)過程中，未來3-5年它到底應該怎么發(fā)展，技術框架又回到我剛才說的這句話，極簡，極簡，再極簡。

OceanBase CEO 楊冰：可能在數(shù)字化的蓬勃發(fā)展過程當中，很多的企業(yè)互聯(lián)網化，線上化以后，確實需要這樣的一些技術，但是當它使用這個技術的時候，既得到了它的好處，又為之付出了比較大的運維、復雜度和人員的成本。互聯(lián)網框架下的數(shù)據(jù)庫每個點可能都會有極端的場景，就需要這么一支隊伍去搞，但是最后它在這么個規(guī)模下是可以均攤掉的。

比方說可能像Amazon，阿里，其實都養(yǎng)出來一個云部門，螞蟻做金融和服務相關的，支付相關的，做了一個數(shù)據(jù)庫出來，養(yǎng)了很大的一個團隊，投入很大去解決這個極端的場景。它其實可以通過別的方式，把這個產品變成一個科技的東西慢慢去做。但是很多其他的一些企業(yè)，它往往是用這個技術。

我們在演進過程中，尤其從2020年，OceanBase從支付寶走到外面，接觸到千行百業(yè)以后，特別明顯能夠感覺到很多的CIO覺得你這個東西好，我要用，但是就怕hold不住它的復雜性。所以我們就把自己從一個大型的武器，變成一個分布式單機一體的，變小了，而且把AP和TP這些能力就吸收進來，然后在使用和運維界面上，盡可能地簡單，讓它可以既享受到互聯(lián)網的技術帶來的紅利，同時又屏蔽掉這個復雜度。

不光是OLTP（在線事務處理）在做HTAP（混合事務/分析處理），純這個數(shù)據(jù)分析的領域，在提湖倉一體，數(shù)據(jù)也在結構化、非結構化放在一起。前面比較經典的叫Lambda架構計算，離線一套，實時一套，后來走到kappa，現(xiàn)在說流批一體，還在繼續(xù)演進……所以計算的框架也在收斂，都在往簡單，合并同類相，然后一體化給業(yè)務去支撐，但是屏蔽復雜度這個方向在發(fā)展。

劉湘明：對傳統(tǒng)行業(yè)來說，業(yè)務面臨的變量已經非常多了。技術產品應該盡量簡化，減少不必要的技術變量，從而騰出精力應對不斷變化的業(yè)務需求和復雜場景。

傳統(tǒng)行業(yè)促銷壓力與數(shù)據(jù)庫技術的應用

劉湘明：對于互聯(lián)網公司來說，像阿里的"雙十一"大促這種極端場景，是考驗系統(tǒng)極限性能的典型案例。王總，雅戈爾會不會面臨類似的訂單激增挑戰(zhàn)，導致系統(tǒng)承受巨大的峰值壓力？

雅戈爾CIO 王歆：其實“雙十一”對傳統(tǒng)行業(yè)的壓力不大，因為海量的訪問，海量的訂單都是在平臺產生。對我們來說，今天針對于這10萬個訂單如何做售前，如何做售中，如何做售后，這個壓力很大。

“雙十一”這種高峰的銷售過程中，我認為它并不是銷售利潤的獲取，我更加會把這種場景比喻成我們業(yè)務團隊的一次“團建”。通過這樣的一次高峰的銷售過程中，去演練了我們整體的、全公司的、所有部門的相互協(xié)同，這是我認為這種洪峰對我們的挑戰(zhàn)。放到我們的IT系統(tǒng)過程中，我們訂單系統(tǒng)、HR、OA、財務上面是否需要做一些改變，退款過程中，是否把退款的東西和前端系統(tǒng)打通。

這里面需要合規(guī)合矩，如果沒有業(yè)務限制，IT無所不能，因為信息就是搬過來搬過去。所謂的傳統(tǒng)IT為什么建設起來又比較難，因為你要踩在合規(guī)合紀的界限之內，但是很多界限又是很模糊的，可做可不做，對我們來說這是個挑戰(zhàn)。正好是可以通過“雙十一”這樣一個大的業(yè)務戰(zhàn)役，去訓練我們符合當前整體的業(yè)務的發(fā)展。

OceanBase CEO 楊冰：我其實感受跟歆總是一樣的，OceanBase一開始出來的時候覺得是一個大殺器，但是走到各行各業(yè)的時候會發(fā)現(xiàn)，大家對于絕對的性能和吞吐量是沒有訴求的，我一會分享兩個很有意思的場景。

我覺得雅戈爾這邊之所以沒有促銷帶來系統(tǒng)壓力，開個玩笑，可能兩個原因，一方面，歆總系統(tǒng)建設得比較強，第二個他沒有把1萬塊錢的西裝打到5000塊錢，打到5000塊錢我估計也爆了，甚至小程序可能也需要這個彈性。OceanBase一方面是它絕對的吞吐量，另外一方面是對于明顯有脈沖式特征的這些業(yè)務，平滑的伸縮的能力。不打擾業(yè)務的情況下，能夠為你準備一部分機器，不要的情況收縮過來的這部分，其實跟零售，服飾相關，用得大。

我舉一個泡泡瑪特的例子，抽盲盒和抽獎是一樣的，比如今天會預告有可能抽到什么樣的盲盒，顧客就會被吸引過來。那個量可能是幾萬分之一于“雙十一”，但是對泡泡瑪特來說，如果活動安排在周五，與前四天相比，參與人數(shù)可能會激增至100倍，就會形成一個波峰。

以前它可能用傳統(tǒng)的數(shù)據(jù)庫，它痛苦的是說，第一，傳統(tǒng)的數(shù)據(jù)庫要去干這件事情，提前一天到晚上停一下機，起碼是分鐘級的，會影響業(yè)務的。當天就處理，處理完了還不能停，因為業(yè)務還在做，而且可能它還會有小活動，累加來個高峰。到了晚上，顧客可能會抽到凌晨一兩點鐘，處理完、運維、上線，把它再縮回來，第二天處理，一來一回三天的時間，其實它的成本是從第一天開始計算，連續(xù)乘三天，幾套、幾十套，或者是高配的機器放在那兒。

但今天我們完全可以無縫、無管地在業(yè)務進行的過程中完成，泡泡瑪特用了OceanBase以后，三個小時就搞定了，它的成本就是那個時候的規(guī)格乘以3。對于促銷形態(tài)的這種業(yè)務，OceanBase可以更好地、更經濟地、靈活地去響應。

這個例子怎么樣頂住流量，第二個例子，是怎么樣通過優(yōu)惠券和促銷的方式引來流量。前端的流量被平臺扛住了，但是可能接下去的發(fā)貨和處理，可能要批量地去操作。我們跟一家國際知名咖啡零售品牌合作的時候，其實也遇到了發(fā)優(yōu)惠券等等這種促銷的活動，

這家咖啡零售品牌，平時不發(fā)券，但過年過節(jié)它會發(fā)券，它扛的不是那種“雙十一”的流量，但是也要在很短的時間內去促銷、去發(fā)券。發(fā)券其實本質上是一個批量的insert，操作完還要update去核銷掉。以前它的系統(tǒng)吞吐量有限，就每個禮拜每天發(fā)一點，一個禮拜把券發(fā)完，前前后后可能要好幾周。但是如果今天上午老板就拍運營方案， IT可能要在下午幾個小時內，把上億張券全部發(fā)完，不同的維度還要去做分析，其實它舊的系統(tǒng)是做不到。后來它后面批量處理的一些系統(tǒng)改造成OceanBase以后，發(fā)券核銷也體現(xiàn)出來OceanBase在“雙十一”促銷中彈性的能力。

第一，我在各行各業(yè)應用的時候，不看它的絕對量，但看它的伸縮能力。第二個，我也不僅僅是支持Front-end（前端）的系統(tǒng)，其實在Back-end（后端）去批處理也很多。白天支持訂單，晚上盤貨，銀行是白天支持交易，晚上批處理做結算，其實這樣的場景非常的多，這是OceanBase動態(tài)伸縮的能力的體現(xiàn)。

雅戈爾CIO 王歆：之前我在滔搏，最痛苦是限量款的售賣。每次去做發(fā)售的時候，都要在OA上填寫升級服務器，我們有統(tǒng)一的運維中心，運維中心是按照升級服務器的量和時間來給我們算成本。每次升級完成了，他們都會要求我們整個APP宕機。直到2021年的時候，我們發(fā)現(xiàn)這些事情是可以得到解決，類似于像這種叫互聯(lián)網框架下的數(shù)據(jù)庫。

零售行業(yè)的安全策略與數(shù)據(jù)庫的安全設計

劉湘明：其實安全現(xiàn)在還是很多CIO的頭等大事，尤其是前段時間微軟藍屏，連航班都出問題，影響還是非常大的。從零售行業(yè)角度，各位對有什么安全看法？

雅戈爾CIO 王歆：我對安全，有四種情況的分析。

第一種情況叫做有防護措施，無安全的管理辦法，那叫賭博。

第二種情況叫做有安全狀態(tài)，無防護措施，你只能靠運氣。

第三種情況叫做有防護措施，有安全形態(tài)，這才是真正意義上的安全。

第四種情況叫做無管理狀態(tài)，無防護措施。

所以說我就把整體的建設過程就分兩種，第一，在基礎的安全防護過程中，投入成本是無底洞，我在內部的跟我們管安全的說，不建議自建機房，因為自建機房所有的安全措施都要自己保證?；ㄍ瑯拥某杀净蛘呤歉俪杀痉炊梢陨显?，本身云上面的技術安全已經非常強大。

第二，應用安全性。它更多的是考慮你的業(yè)務規(guī)則，但凡碰見有被薅羊毛的可能性的時候，我們就要拿業(yè)務去跟技術部門做個評估，怎么樣防止舞弊，這是應用安全性。

第三，數(shù)據(jù)安全。比如處理員工的個人信息是非常敏感的。在傳統(tǒng)數(shù)據(jù)庫很復雜，需要寫一套代碼，再把敏感信息的屏蔽掉?；ヂ?lián)網框架，它只是一個組件，只要定義這個表是敏感的一個表，就必須要輸一個類似于key，應用才能夠調撥得出來。

安全過程中一方面是通過更好的工具，第二方面是要加強安全意識，第三如果說技術安全，我們普通的用戶再怎么做，也是做不過像云廠商這樣的級別。所以說總結下來就是相信云廠商，安全意識普及以及盡可能利用互聯(lián)網框架下面的安全套件。

OceanBase CEO 楊冰：我形容安全其實是叫“買保險”，安全其實沒有一個絕對的安全，看你為這件事情愿意買多高程度的保險，100萬還是200萬？對于支付寶來說，可能每一筆交易每一個金額，它可能涉及到的金額是非常大，就是我們整個架構的設計理念是說，我愿意為這件事情買更多的保險，來確保事情。

安全層面另外一個維度，你盡可能杜絕那些日常會發(fā)生的常規(guī)性的、低級的安全錯誤。第二個可能還是要考慮黑天鵝事件，這個事情理論上花很多的錢應該也能解決，或者是你把效率變慢，你也是能解決，但是不能這么做。

我站在OceanBase的角度說兩個理念， OceanBase做的是分布數(shù)據(jù)庫，分布數(shù)據(jù)本質上是多個Replica，多個冗余或者是多個分片，它本身解決分布式的同時，其實是在解決安全性可靠性的問題，因為多個副本。以前像數(shù)據(jù)庫層面上的這種問題，它再出個故障，它應該是屬于叫做黑天鵝事件，就是小概率事件。它的設計理念是，如果出問題，只要能切人為，主備切換等等，時間什么不考慮，但是數(shù)據(jù)別丟就行。

但是在現(xiàn)在互聯(lián)網的場景下面，可能很多東西線上化了以后，你需要把你的系統(tǒng)部署在本身可靠性沒有那么高的X86上面，這個時候機器的故障、存儲的故障、網卡的故障是乘以一個數(shù)量以后，它這個概率就變成1，變成一個常規(guī)性的事件。

所以今天的數(shù)據(jù)庫在應對這種常規(guī)性的事件時，OceanBase用這種Paxos算法在設計的時候，就把這種故障的場景當作我們常態(tài)的一個場景，一旦出現(xiàn)問題就自動切，不要人為介入，而且我們認為隨時隨地都可能發(fā)生，所以去消除掉。當它的故障概率變高了，我們要用另外一種設計，把常規(guī)性的顧慮給解決掉。但是剛才提到的像微軟這種黑天鵝事件，我覺得這個東西就是一個成本問題。

云，我認為已經是非常安全的，但在極其極端的情況下，可能某一個機房、某一個網絡甚至某一個可能冷卻管出現(xiàn)故障就會動搖安全。這個時候對于一家企業(yè)來說，它是不愿意承受這個成本。它可以考慮說我能不能用十分之一的成本，來把黑天鵝的事件再降低到百分之一、千分之一甚至于萬分之一。

OceanBase除了架在云上，本身享受到云的安全性的同時，我的異構的能力，你另外一個副本放在云上，還是放在別的一個云上，可能十分之一的量，其實是可以幫 CIO在比較可控的成本上，來解決黑天鵝事件，這個也是OceanBase的設計理念和架構理念。

數(shù)據(jù)分析的挑戰(zhàn)與未來數(shù)據(jù)產品的發(fā)展

劉湘明：個性化推薦、庫存優(yōu)化和市場預測等領域對分析的要求越來越高。你在實際運營中，如何看待對分析的期望？尤其在實時數(shù)據(jù)分析和判斷方面，目前存在哪些技術挑戰(zhàn)？你對未來數(shù)據(jù)產品的預期是什么？

雅戈爾CIO 王歆：企業(yè)不論是采用交易數(shù)據(jù)、行為數(shù)據(jù)還是決策數(shù)據(jù)，它們都有一個獲取過程，這些數(shù)據(jù)變成知識的時候，實際上獲取的成本太高。因為整個數(shù)據(jù)它是有分權結構，分領域。第二個，分析的數(shù)據(jù)是跨領域，第三個，分析的數(shù)據(jù)的顆粒度有可能導致數(shù)據(jù)量比較大，這是導致獲取數(shù)據(jù)難度的三個維度。

第一個維度，能不能夠讓數(shù)據(jù)跨域？類似于以搜索模式來獲取數(shù)據(jù)，這就牽涉到一個大模型和一個新的數(shù)據(jù)庫，向量數(shù)據(jù)庫。如果能夠提供這樣的工具，整個分析能力是否能得到釋放？得到釋放是能得出更多的洞察，得出更多的洞察是不是能產生更多可能的商業(yè)模式？得到更多商業(yè)模式，是不是可能產生更多的數(shù)據(jù)，產生更多的數(shù)據(jù)，是不是對某個數(shù)據(jù)的分析過程中就產生更多的維度？

這個過程中就可能產生奇點，我的管理奇點，我的分析奇點來臨時，商業(yè)模式就會發(fā)生變化了。一旦它的商業(yè)發(fā)生模式發(fā)生變化，我們又產生了一系列東西，讓數(shù)據(jù)多跑路，人少跑路。這才是目前為止我們稱之為，在數(shù)據(jù)的維度上面，我們去考慮這個事情?？偨Y下來第一件事情，我去解決整個數(shù)據(jù)的交互界面，能不能夠從領域的方式變成一個數(shù)字模式？

第二個維度，解決完了以后，會產生巨量分析路徑，能不能把跨領域流程做聚合，流程聚合就是把所有管理的東西全都讓機器跑，讓所有的時間和精力全留給業(yè)務的，我們叫交互簡單，流程聚合。

第三個維度，流程聚合又可以做件事情，數(shù)字員工，它的管理成本極低。但是不是能產生好的商業(yè)模式，不知道。

只有數(shù)據(jù)流通，才能夠真正產生交互極簡、流程聚合、數(shù)字經營的三種場景，才能最終產生企業(yè)價值。

劉湘明：其實剛才談到這種分析，矛盾在于我們永遠需要更多的數(shù)據(jù)，又要更快的這種過程，然后更精準的結果，但是這個矛盾我覺得也是數(shù)據(jù)庫的一個機會。OceanBase是怎么解決這個悖論的？

OceanBase CEO 楊冰：王歆總是要更自然、更友好的一個交互，其中有一個維度就是更快更敏捷更自然，由于這件事情被精簡掉了，它兩秒鐘就可以給我回答。如果說它是要做非常詳細的東西，它就要等很長時間，所以未來的交互當中，它需要簡單，快捷。

快，就需要匯聚做分析，這就是數(shù)據(jù)庫可能要做的另外一個工作，不是交易。以前我們去做這種分析的時候，往往是拉出來另外一套系統(tǒng)去做，所以當年數(shù)據(jù)庫做著做著發(fā)現(xiàn)，做大量數(shù)據(jù)分析的時候，傳統(tǒng)的架構就搞不定了，就變成了MPP（大規(guī)模并行處理）這種架構。

現(xiàn)在說分布式數(shù)據(jù)庫，其實挺奇怪的，因為你只要是去看大數(shù)據(jù)型和分析型，沒有人說什么分布式的大數(shù)據(jù)，大數(shù)據(jù)天然就是分布式的。只有講交易的時候才有分布式，我們是后面在交易這條線慢慢才把它搞定。

以前的做法就是說，先不考慮快，先把它變成T+1的，然后讓它給你一張報表，給你一個分析的東西，但后來需要更敏捷、更快的東西，所以大家會發(fā)現(xiàn)OLTP的方向慢慢成熟了，它可以支持海量，同時又有一個湖倉，但是在這兩個大的分水嶺的系統(tǒng)中間出現(xiàn)了一段Real-Time Analysis，就是實時分析，實時出倉。這個有可能是從TP這長出來，直接就可以在這做分析，甚至于物化視圖，直接就給你答案。也可以是說你原先是T+1，我在這個基礎上再加一個報表的離線加速，然后更快地回答，這兩種都可以。

今天OceanBase的技術發(fā)展路線，我是從TP起家的，為了去響應未來快的這種需求，讓數(shù)據(jù)少走路，我?guī)湍阌昧硗庖粋€引擎分析，完成，從而更快地去響應。我覺得這是一個更符合現(xiàn)代企業(yè)對于系統(tǒng)的要求，也更符合未來人工智能介入以后的要求。

另一方面，歆總提到要流程更加能夠串起來，讓機器或者Agent的把這些東西都處理了。以前確實也有一個問題，如果說數(shù)據(jù)庫不做任何的改變，這件事情也能做，但它比較痛苦的是A、B、C、D 4個系統(tǒng)它把它全部抓起來。對于一件事物的描述，它是有不同維度的，但有些可能是用關系型的，有些可能是一張照片，一段視頻，有些可能還加上時間軸，它會有不同的切片。但是當它要去對這件事情做分析，給他一個答案的時候，是要把這些東西全部匯總起去處理，這個時候Agent就發(fā)現(xiàn)大量的數(shù)據(jù)孤島，描述的是一件事情。所以今天我們除了讓它更快長出不同的引擎來，也要做多模態(tài)的融合。就像AI最初是Chat，后來是圖生文、圖生音頻等等，它是多模態(tài)，下一步是世界模型，徹底理解這個世界給你答案。

第三，剛才提到的向量數(shù)據(jù)庫，因為物理世界越來越容易把它被映射成一個向量，而且這個向量容易被人家理解。今天我跟它說一段話，以前讓AI去分析，可能準確率是50%，今天可能是98%，這個時候我能干的事情就非常多了。

所以物理世界映射到數(shù)字世界以后，它的理解力增加多了一個向量，向量對于一件事情的刻畫，也可以融合到以前這種結構化的數(shù)據(jù)當中，然后給出一個綜合的評判。所以今天OceanBase也把向量能力集成進去，也算是我們多模態(tài)的一個延伸。過去結構化和非結構化的數(shù)據(jù)存在不同的地方的，但今天我們試圖把這兩者合在一起。

這個有機結合在兩個層面，第一個是數(shù)據(jù)結構這個層面，能不能用更少的成本，更少的空間，存一份數(shù)據(jù)，但是不同的刻畫維度，這個時候是更有機的一個模式，讓它可以更快。第二個這些數(shù)據(jù)合在一起以后，對于AI的交互界面這一層來說，能不能更有機地結合？如果說你用SQL（結構化查詢語言），你把所有的東西都可以描述成人類語言或者類SQL的方式插進來，然后我反正無論是圖片還是什么，我都可以幫你去想，其實也是一種有機融合，但如果是3個組件或者5個組件，那就只能在Application上去做，因為復雜度就高，而且它也不是那么高效，不那么有機。

AI在雅戈爾業(yè)務流程中的創(chuàng)新應用

劉湘明：楊總剛剛講了從數(shù)據(jù)庫的角度怎么去適配未來AI，雅戈爾在AI上面現(xiàn)在做了些什么樣的布局？

雅戈爾CIO 王歆：去年我們雅戈爾的整體銷售收入是1916億，超過10個億體量的組織，每個組織內部的流程，類似于應用，有300個左右，其中 80%都完全有可能被AI重新定義。

我們在商品售賣過程中，有很重要的一個名詞叫FAB，可以理解成每件產品都有一個說明書，這個說明書會產生導購的話術，每件衣服的FAB正常情況下，都有20頁的描述，就描述的面料，場景等。一季有400個款，400×20頁是8000頁，8000頁的話你讓一個導購看完的話，而且是那么枯燥的書，那是不可能的。

AI來了以后，直接把8000頁內容扔到大模型，再生成一個FAB助理，顧客來了，只要去拍選擇的那件衣服， Agent就給他產生一個100字的推薦，就改善了一個銷售服務的動作，這是目前為止我們在雅戈爾已經做的事情。

雅戈爾西服的良品率達到99.8%。所有的衣服在出廠之前，都要做個質檢，質檢總共有8個動作，怎么確保質檢人員把8個動作檢測到了，也是通過圖像的AI，來解決這個問題。

我的結論是，傳統(tǒng)行業(yè)的所有的業(yè)務流程，都可以基于AI技術改造，基于目前為止的AI能力，就是說可能我們還沒想象到，或者AI能力還不夠強，所以說你還沒辦法做改造，但是這個能力是未來已來，馬上就要來臨。我們有沒有這樣的思路，我們有沒有這樣的準備，我們有沒有這樣的Ready For AI？

技術與業(yè)務融合的未來趨勢及合作模式

劉湘明：今年峰會除了AI之外，大家談特別多的就是場景。雖然OceanBase現(xiàn)在在金融行業(yè)做得非常好，但是還在進軍很多新的行業(yè)，在這類行業(yè)怎么找到真正發(fā)揮的場景，其實需要一些創(chuàng)新的這種思維，我一直覺得未來甲方，乙方，技術提供方和這種用戶之間的合作方式，可能會有一些變化，你們怎么看待這個問題？

雅戈爾CIO 王歆：今天我們說業(yè)務場景，場景我們就定義為是業(yè)務。業(yè)務經營，我們叫微服務，一個場景可能調用幾個微服務，高頻被重復使用的服務叫微服務。所有零售行業(yè)里面，都會有類似于叫進銷存。如果今天楊總說，和我們在這行業(yè)里面做共創(chuàng)，完全不在乎目前為止產生的成本，一定要找適合的場景。在所有的零售行業(yè)里面，最底層的管理就是進銷存，我能不能把進銷存做成一個組件，內置到數(shù)據(jù)庫的插件里面去，那變成微服務了。

從這個角度看，首先有可能改變零售行業(yè)進銷存管理過程中，運算速度和業(yè)務復雜度，把這些全放到PaaS（平臺即服務）層面上來，把它解決一部分加一點類似于SaaS（軟件即服務）的公共組件。那時候你顛覆的不僅僅是數(shù)據(jù)庫，甚至有可能顛覆SaaS層面的東西。

但是從我的直觀角度看，未來所謂的人工智能的發(fā)展，不僅解決我們現(xiàn)有業(yè)務解決不了問題，它更要解決現(xiàn)有業(yè)務解決了的問題。讓它更加有效率，讓它更加簡單。

OceanBase CEO 楊冰：場景我覺得是廠商和業(yè)務方雙向奔赴的一個過程，我腦海里有這么一個框架，比較偏術這個層面上。

第一，作為我們這樣的廠商，我要立一個旗子說我是誰，我要告訴所有的CIO，我是一個什么不一樣的產品，有一些 特別的設計理念，這個東西可以讓大家在理念層和方向層達成一致，他才會有興趣來找我聊一聊。

第二個層，我希望能跟更多像王歆，還有其他的這種零售行業(yè)的CIO去聊一聊，就像我過去幾年更多跟銀行、保險、基金這些CIO聊得多。就是我們既然要進入一個行業(yè)，一定是要共創(chuàng)。甚至于說剛才歆總提到的說，某些場景大家可以不惜代價去做，然后來創(chuàng)造一個東西，它不是生意，它是一個如何顛覆行業(yè)這樣的事情，我們是愿意去干的。

第三層我覺得可能光找歆總這樣的圈層的人還不夠，因為這個行業(yè)當中有兩種類型，第一種類型是說能力比較強的，而且是很強定制化的需求，還有一部分是比較標準化，它可能是靠ISV（獨立軟件供應商）一套系統(tǒng)就搞定了。

比如說我們現(xiàn)在跟像伯俊，或者是可能像百勝這樣一些公司，可能它就對于這個行業(yè)，有非常好的抽象和洞見。他們也在尋找AI能力加進來以后，怎么樣去改變這個行業(yè)，讓它更高效。所以可能今天只是提了那幾個剛才的案例，其實我們在零售行業(yè)的案例其實還蠻多的，這個案例其實就是在跟他們共創(chuàng)的過程當中發(fā)現(xiàn)的。他說你竟然可以這樣，我如果說在這個場景用了你，我可以更高效、更快速的方式服務于他的一些客戶。再往下down一層的層面，就是頂層的定義，CIO層面上的共創(chuàng)。

另外，OceanBase是開源的，這是一個最細顆粒跟開發(fā)者之間的東西，我也不知道一體化了以后，加了一個向量，一個地理位置信息，放在一個數(shù)據(jù)庫里面，會有什么樣的驚喜。

第三，這個場景，這個能力變成一個插件，插到OceanBase，我覺得這是有可能的。但每一層都有邊界，這個東西是不是插在OceanBase里面，我們確實要考慮一下，但這個東西一定會有。我們可能的想法就是說，這個東西如果適合在數(shù)據(jù)庫上改變，我把它拿下來，集成上去。

今天OceanBase也不一定要只是一家數(shù)據(jù)庫公司，現(xiàn)在最牛的 Oracle，它其實也是非常立體的一家公司的話，有數(shù)據(jù)庫、中間件、PaaS甚至SaaS。今天可能有些東西有價值，有沒有可能跟其他公司一起去合作，做成一個聯(lián)合解決方案。甚至于說我把這個產品我就買進來，不一定要自己做，但是我這個插件是放在另外一層PaaS，甚至于SaaS這層，合在一起，對于零售行業(yè)去提供一種全新的解決方案，所以這也是我們的選項之一。

我希望有一天零售行業(yè)，甚至于其他更多的行業(yè)的CIO，哪天在做技術選型和升級的時候，目前金融行業(yè)已經有一定這樣的現(xiàn)象了，發(fā)現(xiàn)報上來的數(shù)據(jù)庫的列表當中沒有OceanBase，他會問一下你有沒有測過OceanBase？在選型的時候說，這個行業(yè)OceanBase還是有點特色的，你可以試試看。如果說做到這一點，說明我們這條路走對了。

劉湘明：今天其實談了既要、又要、都要、全要，其實從安全、成本、創(chuàng)新、增長大家都在談，而且能夠看到業(yè)務和數(shù)據(jù)已經變得密不可分了，一體兩面。這邊看是業(yè)務，翻過來是數(shù)據(jù)，這兩邊怎么去融合去協(xié)作，結合AI其實還有很多想象的空間……

以上為《數(shù)字價值觀察室2024ITValue Summit特別版：讓業(yè)務用起來，零售數(shù)字化的價值重構及實現(xiàn)》部分內容，完整版請觀看《讓業(yè)務用起來，零售數(shù)字化的價值重構及實現(xiàn)》。（本文首發(fā)于鈦媒體App，作者：唐剛 編輯：華楠）