小T導讀：在(zai)生鮮(xian)超市的高效運(yun)營(ying)(ying)中，實時數(shu)據分(fen)(fen)(fen)析至(zhi)關(guan)重要。萬(wan)象云(yun)鼎的“云(yun)鮮(xian)生”通過智能(neng)(neng)秤+網關(guan)+軟件系(xi)統的組合，實現了(le)銷售數(shu)據的精準(zhun)管(guan)理(li)與優(you)化。而在(zai)數(shu)據處理(li)方(fang)面，TDengine 的流(liu)計算能(neng)(neng)力(li)成為了(le)這一方(fang)案的核(he)心支撐。本文詳細分(fen)(fen)(fen)享了(le)“云(yun)鮮(xian)生”如何利用 TDengine 高效存儲和(he)分(fen)(fen)(fen)析海量(liang)銷售數(shu)據，在(zai)優(you)化超市運(yun)營(ying)(ying)、提升用戶體驗的同時，解決高基數(shu)分(fen)(fen)(fen)組、高并發查詢等技術挑戰。

在(zai)生(sheng)鮮(xian)(xian)超市(shi)的主營(ying)業(ye)務(wu)里，生(sheng)鮮(xian)(xian)產品(pin)(pin)如新鮮(xian)(xian)的肉類、蔬菜(cai)、水果(guo)等，大(da)多只(zhi)有較短(duan)的保質(zhi)期，需要(yao)在(zai)特定(ding)的溫度(du)(du)、濕度(du)(du)和環(huan)境(jing)條件下儲存，以(yi)保持其新鮮(xian)(xian)度(du)(du)和品(pin)(pin)質(zhi)。稍(shao)有不慎(shen)便可能導致產品(pin)(pin)變質(zhi)甚至腐(fu)爛(lan)。此(ci)外(wai)，這類產品(pin)(pin)受(shou)季節和地(di)域因(yin)素(su)影響，供應往(wang)往(wang)不穩定(ding)。因(yin)此(ci)，一個優秀的生(sheng)鮮(xian)(xian)超市(shi)雖(sui)然可以(yi)為消費(fei)者(zhe)提供豐富多樣(yang)的選擇，但是其管理難(nan)度(du)(du)同樣(yang)極高。

由我司萬象(xiang)云鼎研發(fa)的(de)“云鮮生”——一套基于“智(zhi)能(neng)秤(cheng)+網關+軟件系統(tong)”的(de)生鮮行業智(zhi)慧門店(dian)管(guan)理(li)方(fang)案，正是為了解決(jue)這(zhe)些管(guan)理(li)難題(ti)而生。我們的(de)智(zhi)能(neng)秤(cheng)能(neng)夠(gou)實(shi)現(xian)自(zi)助(zhu)稱重、結(jie)算(suan)以(yi)及產品(pin)(pin)數據可視化，同時(shi)支持將所售商品(pin)(pin)信(xin)息(xi)、訂單(dan)數據等(deng)實(shi)時(shi)上傳至云端，通過對這(zhe)些數據的(de)高效(xiao)管(guan)理(li)和(he)實(shi)時(shi)分析，助(zhu)力超市(shi)優化運營、提(ti)升客戶(hu)體驗。

產品定位

我們希(xi)望可以為超市經營者解決以下問(wen)題：

1.提高超市的用(yong)戶(hu)購物效率，提升 C 端(duan)用(yong)戶(hu)的滿意度。

2.降低(di)超市人力成本、通過自動化(hua)/數字化(hua)設備技(ji)術，減少收銀、用戶溝通等由人力產生(sheng)的誤(wu)差。

3.提供(gong)動態(tai)的定價策(ce)略(lve)：基于實時的銷售數據和生鮮商品的保質期，給商家提供(gong)充足信(xin)息(xi)，實施動態(tai)定價策(ce)略(lve)，比如立刻開展促(cu)銷/折(zhe)扣活(huo)動。

4.支持各種維度的(de)(de)數據(ju)分(fen)析，包(bao)括(kuo)特(te)定商(shang)品、特(te)定客戶的(de)(de)全部門店(dian)或(huo)分(fen)店(dian)，以及不同攤位類型的(de)(de)實(shi)時與(yu)歷史銷(xiao)(xiao)(xiao)售數據(ju)。通過這些(xie)信息，超市經營者可(ke)以清晰了解暢銷(xiao)(xiao)(xiao)與(yu)滯銷(xiao)(xiao)(xiao)商(shang)品的(de)(de)分(fen)布，并深入分(fen)析為何同款產品在相同時間段內，在 A 店(dian)熱銷(xiao)(xiao)(xiao)，而在 B 店(dian)卻無人問津等運營難(nan)題，使決(jue)策更(geng)加精(jing)準高效(xiao)。

Why TDengine?

TDengine 作為濤思數據的旗艦產品，其核心是一個高性能、分布式的時序數據庫。通過集成(cheng)的緩存、數(shu)(shu)(shu)據訂閱、流計算和(he)數(shu)(shu)(shu)據清洗與轉換等功能(neng)，TDengine 已(yi)經(jing)發展(zhan)成(cheng)為(wei)(wei)一個專為(wei)(wei)物聯(lian)網、工(gong)業互聯(lian)網、金(jin)融和(he) IT 運(yun)維等關鍵行業量(liang)身定制(zhi)的時序大數(shu)(shu)(shu)據平臺(tai)。

在這(zhe)一需求背景(jing)下(xia)，我們發現 TDengine 產品定位與(yu)之高度契合，因此開始(shi)了(le)對 TDengine 的深入探索與(yu)應用。

我們的(de)產品是(shi)一款基于自建(jian)服務器的(de) SaaS 服務，通過 Web/App 提供功能(neng)。在產品諸多特性(xing)中，最重要的(de)一個(ge)核心特性(xing)就(jiu)是(shi)實(shi)時獲取(qu)商品當日(ri)的(de)銷(xiao)售(shou)量/銷(xiao)售(shou)額(e)狀況。經過深入分(fen)析，我們發(fa)現(xian) TDengine 的(de)流計算(suan)是(shi)實(shi)現(xian)這(zhe)一需求(qiu)最合適的(de)選擇(ze)。

流計算的應用

數據經由每家(jia)超市部署的網(wang)關(guan)統一寫入到 TDengine 當中。

接下(xia)來，基于(yu) billsale 表，我們創(chuang)建了一個名為 stream_billsale_day 的流計(ji)算任務，計(ji)算結(jie)果將(jiang)存入另一個庫中的 billsale_day 超(chao)級表中：

create stream stream_billsale_day
 trigger at_once
 IGNORE EXPIRED 0
 fill_history 1
 into possum.billsale_day
 TAGS (tenantid int,shopid int,userid int,stalltype int,productid bigint,subproductid bigint)
 SUBTABLE(CONCAT('saleday_', tbname))
 as
 select _wstart as saledate,
 sum(cast(case when IsReturn=0 then qty else 0 end as bigint)) as saleqty,
 sum(cast(case when IsReturn=0 then money else 0 end as bigint)) as salemoney,
 sum(cast(case when IsReturn=1 then 0-qty else 0 end as bigint)) as refundqty,
 sum(cast(case when IsReturn=1 then 0-money else 0 end as bigint)) as refundmoney,
 max(price) as maxprice,min(price) as minprice,last(saletime) as lastsaletime,first(saletime) as firstsaletime from billsale
 PARTITION BY tbname,tenantid,userid,shopid,stalltype,productid,subproductid 
interval (1d);

該(gai)流計算邏輯如(ru)(ru)下(xia)，通(tong)過對以下(xia)標(biao)簽：tbname（智能秤設(she)備名），tenantid（租戶ID）、shopid（商(shang)店ID）、操作人員編號（userid）、stalltype（攤(tan)位類型）、productid（產(chan)(chan)品ID）、subproductid（子產(chan)(chan)品ID）執行(xing)分組(zu)之后(hou)，再(zai)按照(zhao)一天的時間窗口來統計如(ru)(ru)下(xia)字(zi)段：

1. saleqty：日銷售量，計算方式為將 IsReturn 為 0 的“銷售量”字段求和。
2. salemoney：日銷售額，計算方式為將 IsReturn 為 0 的“銷售額”字段求和。
3. refundqty：日退貨數量，計算方式為將 IsReturn 為 1 的“銷售量”取負值后求和。
4. refundmoney：日退貨金額，計算方式為將 IsReturn 為 1 的“銷售額”取負值后求和。
5. maxprice：日最高價格。
6. minprice：日最低價格。
7. saledate：日窗口開始時間（_wstart）。
8. firstsaletime：日該商品第一次銷售時間。
9. lastsaletime：日該商品最后一次銷售時間。

在我(wo)(wo)們(men)的(de)(de)實際應用中，由于商(shang)品種類繁多(duo)，商(shang)家(jia)眾多(duo) （覆蓋(gai) 260+ 客(ke)戶(hu)、700+ 超(chao)市），因(yin)此衍生出的(de)(de)標(biao)簽也極(ji)為豐富。在對這些(xie)多(duo)字段全(quan)(quan)部進行分(fen)組之后，產生了典型的(de)(de)高基數問題，一共創建了 2600 萬的(de)(de)子(zi)表。只有這樣的(de)(de)分(fen)組，才能滿足我(wo)(wo)們(men)的(de)(de)全(quan)(quan)部分(fen)析需(xu)求(qiu)，也就是(shi)說：靈活(huo)的(de)(de)背后是(shi)全(quan)(quan)量(liang)的(de)(de)覆蓋(gai)。

為了結合實時數(shu)據進(jin)行綜(zong)合分析(xi)，我(wo)們在(zai)創建流計算語(yu)句時也指定(ding)了 fill_history 1 參數(shu)，對如下 5 年的(de)歷(li)史數(shu)據（共計 24 億(yi)條）進(jin)行計算，以確保分析(xi)的(de)完整性和連續性。

盡管我(wo)們能(neng)想(xiang)象到數據庫的壓力非常大，但仍希望(wang)嘗試一下(xia) TDengine 的流(liu)計算，驗證其是否能(neng)夠滿足我(wo)們的業務需求(qiu)。

在 TDengine 官(guan)方(fang)團隊(dui)的支持下，整個調試過(guo)程中，我們做了多項優化(hua)：

1. 和業務側多方多次溝通討論，在分組過程中，精簡不需要的標簽。

2. 把流計算產生的數據，寫入到另一個庫中，這樣就可以針對性的配置建庫參數。由于我們的數據每天只有一條，我們將 duration 參數調整為 1825天，使得即便存儲 5 年的全量數據，也可以只用一個數據文件承載，從而大幅優化存儲效率。

3. 大膽放開 VGROUPS 增加硬件增加并行度（實際值 400）。

由于(yu)我(wo)們對(dui)所有歷史數據都進行了計算，因此我(wo)們的用戶在任何時間(jian)都可以結(jie)合歷史數據進行查詢(xun)分析(xi)。

應用場景一：

查(cha)詢 77 號客戶全部超市 2 年整的銷(xiao)(xiao)售量(liang)、銷(xiao)(xiao)售額(e)、退(tui)貨量(liang)、退(tui)貨額(e)，耗時 5 秒左右。

應用場景二：

查詢 77 號(hao)客戶在 9 個(ge)月內，按(an)照分店ID、操作(zuo)員ID 和產品(pin)ID 進(jin)行(xing)分組后(hou)的(de)，總(zong)銷售量、總(zong)銷售額、總(zong)退(tui)貨(huo)量、總(zong)退(tui)貨(huo)額，除了(le)用作(zuo)常規的(de)業務分析(xi)之(zhi)外(wai)，還可以(yi)計算操作(zuo)員的(de)業績(ji)提成。

總結

以上就(jiu)是我們(men)在使用 TDengine 過(guo)程中的(de)一(yi)(yi)些心得(de)與經驗。作為一(yi)(yi)款出色的(de)國產(chan)時序數據庫，TDengine 在實際應(ying)用中真(zhen)正地為我們(men)智能生鮮行業提(ti)供了巨(ju)大幫(bang)助。遂(sui)整理(li)成(cheng)文，希望 TDengine 發展得(de)越來越好，早日成(cheng)為時序數據領(ling)域的(de) Oracle。