Stories

Detail Return Return

得物管理類目配置線上化：從業務痛點到技術實現 - Stories Detail

一、引言

在電商交易領域，管理類目作為業務責權劃分、統籌、管理核心載體，隨着業務複雜性的提高，其規則調整頻率從最初的 1 次 / 季度到多次 / 季度，三級類目的規則複雜度也呈指數級上升。傳統依賴數倉底層更新的方式暴露出三大痛點：

  • 行業無法自主、快速調管理類目；
  • 業務管理類目規則調整，不支持校驗類目覆蓋範圍是否有重複/遺漏，延長交付週期；
  • 規則變更成功後、下游系統響應滯後，無法及時應用最新類目規則。

本文將從技術視角解析 “管理類目配置線上化” 項目如何通過全鏈路技術驅動，將規則迭代週期縮短至 1-2 天。

二、業務痛點與技術挑戰：為什麼需要線上化？

2.1 效率瓶頸：手工流程與

高頻迭代的矛盾

問題場景：業務方需線下通過數倉提報規則變更，經數倉開發、測試、BI需要花費大量精力校驗確認，一次類目變更需 3-4 周左右時間才能上線生效，上線時間無法保證。

技術瓶頸：數倉離線同步週期長（T+1），規則校驗依賴人工梳理，無法應對 “商品類目量級激增”。

2.2 質量風險：規則複雜度與

校驗能力的失衡

典型問題：當前的管理類目映射規則，依賴業務收集提報，但從實際操作看管理三級類目映射規則提報質量較差(主要原因為：業務無法及時校驗提報規則是否準確，是否窮舉完善，是否完全無交叉)，存在大量重複 / 遺漏風險。

2.3 系統耦合：底層變更對

下游應用的多米諾效應

連鎖影響：管理類目規則變更會需同步更新交易後台、智能運營系統、商運關係工作台等多下游系統，如無法及時同步，可能會影響下游應用如商運關係工作台的員工分工範圍的準確性，影響商家找人、資質審批等場景應用。

三、技術方案：從架構設計到核心模塊拆解

3.1 分層架構：解耦業務與數據鏈路

圖片

3.2 核心模塊技術實現

規則生命週期管理： 規則操作流程

圖片

圖片

圖片

圖片

提交管理類目唯一性校驗規則

新增：id為空，則為新增

刪除：當前db數據不在提交保存列表中

更新：名稱或是否兜底類目或規則改變則發生更新【其中如果只有名稱改變則只觸發審批，不需等待數據校驗，業務規則校驗邏輯為將所有規則包含id，按照順序排序拼接之後結果是否相等】

多級類目查詢

圖片

構建管理類目樹

/**
 * 構建管理類目樹
 */
public List<ManagementCategoryDTO> buildTree(List<ManagementCategoryEntity> managementCategoryEntities) {
    Map<Long, ManagementCategoryDTO> managementCategoryMap = new HashMap<>();
    for (ManagementCategoryEntity category : managementCategoryEntities) {
        ManagementCategoryDTO managementCategoryDTO = ManagementCategoryMapping.convertEntity2DTO(category);
        managementCategoryMap.put(category.getId(), managementCategoryDTO);
    }
    
    // 找到根節點
    List<ManagementCategoryDTO> rootNodes = new ArrayList<>();
    for (ManagementCategoryDTO categoryNameDTO : managementCategoryMap.values()) {
        //管理一級類目 parentId是0
        if (Objects.equals(categoryNameDTO.getLevel(), ManagementCategoryLevelEnum.FIRST.getId()) && Objects.equals(categoryNameDTO.getParentId(), 0L)) {
            rootNodes.add(categoryNameDTO);
        }
    }
    // 構建樹結構
    for (ManagementCategoryDTO node : managementCategoryMap.values()) {
        if (node.getLevel() > ManagementCategoryLevelEnum.FIRST.getId()) {
            ManagementCategoryDTO parentNode = managementCategoryMap.get(node.getParentId());
            if (parentNode != null) {
                parentNode.getItems().add(node);
            }
        }
    }
    return rootNodes;
}

填充管理類目規則



/**
 * 填充規則信息
 */
private void populateRuleData
(List<ManagementCategoryDTO> managementCategoryDTOS, List<ManagementCategoryRuleEntity> managementCategoryRuleEntities) {
    if (CollectionUtils.isEmpty(managementCategoryDTOS) || CollectionUtils.isEmpty(managementCategoryRuleEntities)) {
        return;
    }
    List<ManagementCategoryRuleDTO> managementCategoryRuleDTOS =managementCategoryMapping.convertRuleEntities2DTOS(managementCategoryRuleEntities);
    // 將規則集合按 categoryId 分組
    Map<Long, List<ManagementCategoryRuleDTO>> rulesByCategoryIdMap = managementCategoryRuleDTOS.stream()
            .collect(Collectors.groupingBy(ManagementCategoryRuleDTO::getCategoryId));
    // 遞歸填充規則到樹結構
    fillRulesRecursively(managementCategoryDTOS, rulesByCategoryIdMap);


}


/**
 * 遞歸填充規則到樹結構
 */
private static void fillRulesRecursively
(List<ManagementCategoryDTO> managementCategoryDTOS, Map<Long, List<ManagementCategoryRuleDTO>> rulesByCategoryIdMap) {
    if (CollectionUtils.isEmpty(managementCategoryDTOS) || MapUtils.isEmpty(rulesByCategoryIdMap)) {
        return;
    }
    for (ManagementCategoryDTO node : managementCategoryDTOS) {
        // 獲取當前節點對應的規則列表
        List<ManagementCategoryRuleDTO> rules = rulesByCategoryIdMap.getOrDefault(node.getId(), new ArrayList<>());
        node.setRules(rules);
        // 遞歸處理子節點
        fillRulesRecursively(node.getItems(), rulesByCategoryIdMap);
    }
}

狀態機驅動：管理類目生命週期管理

image.png

超時機制 ：基於時間閾值的流程阻塞保護

其中，為防止長時間運營處於待確認規則狀態，造成其他規則阻塞規則修改，定時判斷待確認規則狀態持續時間，當時間超過xxx時間之後，則將待確認狀態改為長時間未操作，放棄變更狀態，並飛書通知規則修改人。

image.png

管理類目狀態變化級聯傳播策略

類目生效和失效狀態為級聯操作。規則如下：

  • 管理二級類目有草稿狀態時，不允許下掛三級類目的編輯；
  • 管理三級類目有草稿狀態時，不允許對應二級類目的規則編輯；
  • 類目生效失效狀態為級聯操作，上層修改下層級聯修改狀態，如果下層管理類目存在草稿狀態，則自動更改為放棄更改狀態。

規則變更校驗邏輯

當一次提交，可能出現的情況如下。一次提交可能會產生多個草稿，對應多個審批流程。

新增管理類目規則：

  • 一級管理類目可以直接新增（點擊新增一級管理類目）
  • 二級管理類目和三級管理類目不可同時新增
  • 三級管理類目需要在已有二級類目基礎上新增

只有名稱修改觸發直接審批，有規則修改需要等待數倉計算結果之後，運營提交發起審批。

image.png

交互通知中心：飛書卡片推送

  • 變更規則數據計算結果依賴數倉kafka計算結果回調。
  • 基於飛書卡片推送數倉計算結果，回調提交審批和放棄變更事件。

image.png

飛書卡片：

卡片結果

image.png

卡片操作結果

image.png

審批流程：多維度權限控制與飛書集成

提交審批的四種情況：

  • 名稱修改
  • 一級類目新增
  • 管理類目規則修改
  • 生效失效變更

審批通過，將草稿內容更新到管理類目表中，將管理類目設置為生效中。

審批駁回，清空草稿內容。

image.png

審批人分配機制：多草稿並行審批方案

一次提交可能會產生多個草稿，對應多個審批流程。

image.png

審批邏輯

public Map<String, List<String>> buildApprover(
        ManagementCategoryDraftEntity draftEntity,
        Map<Long, Set<String>> catAuditorMap,
        Map<String, String> userIdOpenIdMap,
        Integer hasApprover) {
    
    Map<String, List<String>> nodeApprover = new HashMap<>();


    // 無審批人模式，直接查詢超級管理員
    if (!Objects.equals(hasApprover, ManagementCategoryUtils.HAS_APPROVER_YES)) {
        nodeApprover.put(ManagementCategoryApprovalField.NODE_SUPER_ADMIN_AUDIT,
                queryApproverList(0L, catAuditorMap, userIdOpenIdMap));
        return nodeApprover;
    }
    
    Integer level = draftEntity.getLevel();
    Integer draftType = draftEntity.getType();
    boolean isEditOperation = ManagementCategoryDraftTypeEnum.isEditOp(draftType);
    
    // 動態構建審批鏈（支持N級類目）
    List<Integer> approvalChain = buildApprovalChain(level);
    for (int i = 0; i < approvalChain.size(); i++) {
        int currentLevel = approvalChain.get(i);
        Long categoryId = getCategoryIdByLevel(draftEntity, currentLevel);
        
        // 生成節點名稱（如：NODE_LEVEL2_ADMIN_AUDIT）
        String nodeKey = String.format(
                ManagementCategoryApprovalField.NODE_LEVEL_X_ADMIN_AUDIT_TEMPLATE,
                currentLevel
        );
        
        // 編輯操作且當前層級等於提交層級時，添加本級審批人 【新增的管理類目沒有還沒有對應的審批人】
        if (isEditOperation && currentLevel == level) {
            addApprover(nodeApprover, nodeKey, categoryId, catAuditorMap, userIdOpenIdMap);
        }
        
        // 非本級審批人（上級層級）
        if (currentLevel != level) {
            addApprover(nodeApprover, nodeKey, categoryId, catAuditorMap, userIdOpenIdMap);
        }
    }
    
    return nodeApprover;
}


private List<Integer> buildApprovalChain(Integer level) {
    List<Integer> approvalChain = new ArrayList<>();
    if (level == 3) {
        approvalChain.add(2); // 管二審批人
        approvalChain.add(1); // 管一審批人
    } else if (level == 2) {
        approvalChain.add(2); // 管二審批人
        approvalChain.add(1); // 管一審批人
    } else if (level == 1) {
        approvalChain.add(1); // 管一審批人
        approvalChain.add(0); // 超管
    }
    return approvalChain;
}

3.3 數據模型設計

image.png

3.4 數倉計算邏輯

同步數據方式

方案一：

image.png
每次修改規則之後通過調用SQL觸發離線計算

優勢：通過SQL調用觸發計算，失效性較高

劣勢：ODPS 資源峯值消耗與SQL腳本耦合問題

  • 因為整個規則修改是三級類目維度，如果同時幾十幾百個類目觸發規則改變，會同時觸發幾十幾百個離線任務。同時需要大量ODPS 資源；
  • 調用SQL方式需要把當前規則修改和計算邏輯的SQL一起調用計算。

方案二：

image.png

優勢：同時只會產生一次規則計算

劣勢：實時性受限於離線計算週期

  • 實時性取決於離線規則計算的定時任務配置和離線數據同步頻率，實時性不如直接調用SQL性能好
  • 不重不漏為當前所有變更規則維度

技術決策：常態化迭代下的最優解

考慮到管理類目規則平均變更頻率不高，且變更時間點較為集中（非緊急場景佔比 90%），故選擇定時任務方案實現：

  • 資源利用率提升：ODPS 計算資源消耗降低 80%，避免批量變更時數百個任務同時觸發的資源峯值；
  • 完整性保障：通過全量維度掃描確保規則校驗無遺漏，較 SQL 觸發方案提升 20% 校驗覆蓋率；
  • 可維護性優化：減少 SQL 腳本與業務邏輯的強耦合，維護成本降低 80%。

數據取數邏輯

生效中規則計算
image.png

草稿+生效中規格計算

image.png

如果是新增管理類目，直接參與計算。

如果是刪除管理類目，需要將該刪除草稿中對應的生效管理類目排除掉。

如果是更新：需要將草稿中的管理類目和規則替換生效中對應的管理類目和規則。

數倉實現

image.png

數據流程圖

image.png

四、項目成果與技術價值

預期效率提升：從 “周級” 到 “日級” 的跨越

  • 管理一級 / 二級類目變更開發零成本，無需額外人力投入
  • 管理三級類目變更相關人力成本降低 100%，無需額外投入開發資源
  • 規則上線週期壓縮超 90%，僅需 1 - 2 天即可完成上線

質量保障：自動化校驗替代人工梳理

  • 規則重複 / 遺漏檢測由人工梳理->自動化計算
  • 下游感知管理類目規則變更由人工通知->實時感知

技術沉澱：規則模型化能力

沉澱管理類目規則配置模型，支持未來四級、五級多級管理類目快速適配。

五、總結

未來優化方向：

  1. 規則衝突預警：基於AI預測高風險規則變更，提前觸發校驗
  2. 接入flink做到實時計算管理類目和對應商品關係

技術重構的本質是 “釋放業務創造力”

管理類目配置線上化項目的核心價值，不僅在於技術層面的效率提升，更在於通過自動化工具鏈，讓業務方從 “規則提報的執行者” 轉變為 “業務策略的設計者”。當技術架構能夠快速響應業務迭代時，企業才能在電商領域的高頻競爭中保持創新活力。

往期回顧

  1. 大模型如何革新搜索相關性？智能升級讓搜索更“懂你”｜得物技術
  2. RAG—Chunking策略實戰｜得物技術
  3. 告別數據無序：得物數據研發與管理平台的破局之路
  4. 從一次啓動失敗深入剖析：Spring循環依賴的真相｜得物技術
  5. Apex AI輔助編碼助手的設計和實踐｜得物技術

文 /維山

關注得物技術，每週更新技術乾貨

要是覺得文章對你有幫助的話，歡迎評論轉發點贊～

未經得物技術許可嚴禁轉載，否則依法追究法律責任。

數據分析 , 效率 , 後端 , 效率工具 , 數據挖掘
user avatar u_16640205 Avatar soroqer Avatar weidewei Avatar huangmingji Avatar yian Avatar gomi Avatar cbuc Avatar quanzhikeji Avatar java_3y Avatar compose_hub Avatar coderleo Avatar faurewu Avatar
Favorites 22 users favorite the story!
Favorites

Add a new Comments

Some HTML is okay.