我一直在用Python做數(shù)據(jù)分析類的項目最近一段時間把整套外賣配送分析流程搬到了Django上從訂單數(shù)據(jù)清洗、指標統(tǒng)計到圖表可視化全部在一個Web項目里閉環(huán)完成。這個系統(tǒng)說到底解決的是一個很常見的尷尬運營手里攢著大量訂單數(shù)據(jù)、配送記錄和商家信息但每次想看某個時段的配送情況、哪個區(qū)域單量爆發(fā)、哪位騎手效率下降都得讓技術(shù)臨時跑SQL或手動拉Excel數(shù)據(jù)口徑換一個就要重新算一遍。把分析固化成一個Django系統(tǒng)之后日常運營打開瀏覽器就能看到所有關(guān)鍵指標這比我以前用腳本處理數(shù)據(jù)再生成報告要直觀得多。適合誰看兩個方面一是剛學(xué)完Django基礎(chǔ)、想找一個完整體驗數(shù)據(jù)建模、接口開發(fā)、圖表渲染全流程的新手二是需要用Web方式做數(shù)據(jù)分析可視化的開發(fā)人員比如餐飲、即時配送、本地生活這類業(yè)務(wù)場景。如果你只是想把CSV文件畫個圖那用Jupyter Notebook就夠沒必要上系統(tǒng)但如果你希望最終交付的是“一個能給別人用的產(chǎn)品”這篇文章的經(jīng)驗應(yīng)該對你有價值。項目代號里的“35k9z86f”不用糾結(jié)就是當(dāng)時內(nèi)部倉庫的一個標識編號跟技術(shù)方案沒有關(guān)系。1. 系統(tǒng)整體設(shè)計與技術(shù)選型思路1.1 外賣配送分析系統(tǒng)到底要解決什么問題外賣配送的本質(zhì)是“訂單-商家-配送員-時間-位置”五要素的協(xié)同。單看一張訂單表沒有任何意義把訂單、配送員、商家、時間、位置聯(lián)合起來才能回答以下問題門店的訂單集中在哪些時段午高峰和夜宵時段是不是同樣需要運力外賣平均配送時長是多少哪個環(huán)節(jié)拖后腿是接單慢、到店慢還是送達慢哪些商圈或配送區(qū)域單量密集需不需要調(diào)整配送運力每個騎手每天承接多少單平均配送用時多少有沒有異常超時單哪些商家貢獻了主要銷售額客單價水平又如何這些問題的共同點是它們都不是單表查詢可以解決的必須把多張表關(guān)聯(lián)起來做分組聚合。所以數(shù)據(jù)建模時就要按“業(yè)務(wù)流程”去建模而不是按“報表需求”去建。一開始如果只想著“我要一個訂單表”最后做出來的系統(tǒng)一定會在統(tǒng)計時處處碰壁比如想分析騎手效率時發(fā)現(xiàn)訂單表里根本沒有騎手ID。先把業(yè)務(wù)鏈路理清楚再設(shè)計表結(jié)構(gòu)這套思路放到任何數(shù)據(jù)分析項目里都通用。1.2 為什么選擇Django而非Flask或Node我經(jīng)常被問到一個問題做數(shù)據(jù)分析可視化為什么不用Flask說實話Flask確實也能做但我更看重Django的自帶能力。下面這個對比表可以直觀看出來能力DjangoFlaskNode/ExpressORM內(nèi)置遷移機制完善需要自己選配SQLAlchemy需要單獨選型Admin后臺自帶可直接錄入數(shù)據(jù)需要擴展包需要額外開發(fā)用戶認證內(nèi)置User/Permission自己集成自己集成模板渲染自帶模板引擎Jinja2可選自己選適合場景完整業(yè)務(wù)系統(tǒng)輕量API/原型高并發(fā)實時系統(tǒng)Django是水電齊全的精裝房Flask是毛坯房。做外賣配送分析系統(tǒng)時我們需要的東西——用戶管理、數(shù)據(jù)庫遷移、模型關(guān)系、后臺錄入、模板渲染——Django全都提供了我只需要把業(yè)務(wù)邏輯填進去。這也是我在眾多方案里選Django的核心原因。而且對新手來說Django的“約定優(yōu)于配置”特性會減少很多決策成本對團隊來說Django的項目結(jié)構(gòu)規(guī)范性對后期維護幫助很大。1.3 可視化方案ECharts還是Chart.js還是AntV數(shù)據(jù)可視化分兩層后端負責(zé)把統(tǒng)計結(jié)果算出來前端負責(zé)把統(tǒng)計結(jié)果畫出來。選型時我主要考慮三點圖表類型是否覆蓋需求需要折線圖、柱狀圖、餅圖、熱力圖、地圖ECharts覆蓋最全。中文資料與社區(qū)成熟度ECharts文檔很完善遇到問題可以快速找到解決方案。部署與定制成本ECharts支持按需引入構(gòu)建也支持直接用靜態(tài)js文件很適合企業(yè)內(nèi)部系統(tǒng)。Chart.js能畫基礎(chǔ)圖表但熱力、地圖類較弱AntV功能強但學(xué)習(xí)成本高。最終選擇ECharts核心原因是它的“開箱即用”程度最高。另外一個實際經(jīng)驗是ECharts的官方示例庫非常豐富很多需求直接改官方示例代碼就能完成這對不擅長前端樣式的后端開發(fā)者尤其友好。2. 環(huán)境準備與項目骨架搭建2.1 開發(fā)環(huán)境與版本選擇指南寫代碼首先是環(huán)境。我的建議是Python版本3.10、3.11、3.12都行。Django 4.2 LTS官方支持到2026年Django 5.x支持到2029年生產(chǎn)環(huán)境優(yōu)先選LTS版本本地開發(fā)可以用較新版本。數(shù)據(jù)庫本地演示用SQLite部署用MySQL 8.0或PostgreSQL。如果是面向正式運營的系統(tǒng)不建議用SQLite因為并發(fā)寫入能力有限多個后臺用戶同時錄單時容易鎖庫。代碼編輯VSCode搭配Python插件或PyCharm選哪種都行只要把虛擬環(huán)境和Django環(huán)境跑通。安裝步驟python -m venv venv source venv/bin/activate pip install django4.2.16 pip install pillowPillow是后面處理圖片和地圖素材時需要用到的基礎(chǔ)庫。Windows下如果使用MySQL安裝mysqlclient容易編譯失敗有兩個解決路徑安裝whl包或者改用pymysql在項目的__init__.py中加入import pymysql; pymysql.install_as_MySQLdb()。我個人的習(xí)慣是項目早期統(tǒng)一用SQLite讓團隊先跑通功能等數(shù)據(jù)量上來或者并發(fā)需求出現(xiàn)再遷移到MySQL。Django遷移工具在兩種數(shù)據(jù)庫之間切換成本很低這也是選Django的一個明顯好處。2.2 創(chuàng)建Django項目和App項目名叫takeout_analysis下面建兩個業(yè)務(wù)apporders和analysis。命令如下django-admin startproject takeout_analysis . python manage.py startapp orders python manage.py startapp analysis有人會問“為什么把orders和analysis分開用一個app不行嗎”這里有一個模塊劃分的考慮。orders只負責(zé)數(shù)據(jù)實體Store、Courier、Order、DeliveryRecordanalysis負責(zé)統(tǒng)計視圖、API接口和圖表頁面。后續(xù)如果需要把orders換成其他業(yè)務(wù)系統(tǒng)analysis能獨立復(fù)用。數(shù)據(jù)、分析兩個模塊的解耦比一個app里所有代碼堆在一起好維護得多。2.3 settings配置要點打開settings.py重點改三塊。第一塊是INSTALLED_APPSINSTALLED_APPS [ django.contrib.admin, django.contrib.auth, django.contrib.contenttypes, django.contrib.sessions, django.contrib.messages, django.contrib.staticfiles, orders, analysis, ]第二塊是數(shù)據(jù)庫。本地先用SQLiteDATABASES { default: { ENGINE: django.db.backends.sqlite3, NAME: BASE_DIR / db.sqlite3, } }第三塊是靜態(tài)文件。ECharts的js文件放到static目錄STATIC_URL static/ STATICFILES_DIRS [ BASE_DIR / static, ]把這三塊配置寫在項目早期能避免后面開發(fā)到一半再去補基礎(chǔ)配置。這里特別注意一定要提前配好時區(qū)TIME_ZONE Asia/Shanghai USE_TZ False統(tǒng)計折線圖按時段聚合時如果時區(qū)不對你會很痛苦地發(fā)現(xiàn)數(shù)據(jù)全部偏移了幾個小時。第5章我會專門說這個坑。3. 數(shù)據(jù)模型設(shè)計與業(yè)務(wù)邏輯實現(xiàn)3.1 外賣配送分析需要哪些核心數(shù)據(jù)表數(shù)據(jù)模型設(shè)計是整個系統(tǒng)的地基。我建議首版先建下面五張表表名主要字段說明Shop 店鋪表name、category、address、longitude、latitude、rating保存商家基礎(chǔ)信息供訂單關(guān)聯(lián)和區(qū)域分析Courier 配送員表name、phone、status、region配送員信息關(guān)聯(lián)配送記錄Order 訂單表order_no、shop、customer_phone、created_at、amount、delivery_fee、status訂單主體分析業(yè)務(wù)量、銷售額DeliveryRecord 配送記錄表order、courier、accepted_time、arrived_shop_time、delivered_time、distance_km配送鏈路的時間戳用于計算各環(huán)節(jié)耗時Region 區(qū)域表city、district、name、latitude、longitude、radius商圈/區(qū)域定義用于熱力分析與運力規(guī)劃這里有一個設(shè)計經(jīng)驗不要把所有東西都塞在訂單表里尤其是配送時間戳。原因在于訂單的“交易屬性”和“配送履約屬性”是兩類數(shù)據(jù)交易屬性相對固定配送履約屬性變更頻繁如果都放一張表一個騎手改派訂單會導(dǎo)致記錄不斷被更新歷史報表追蹤會很麻煩。拆分之后訂單表只管訂單本身配送記錄可以保留多條歷史軌跡甚至能給同一條訂單保留改派前后兩條配送記錄分析時取最新一條即可。ORM示例from django.db import models class Shop(models.Model): name models.CharField(max_length100) category models.CharField(max_length50, blankTrue) longitude models.FloatField() latitude models.FloatField() rating models.FloatField(default0) class Order(models.Model): STATUS_CHOICES [ (pending, 待接單), (delivering, 配送中), (completed, 已完成), (cancelled, 已取消), ] order_no models.CharField(max_length32, uniqueTrue) shop models.ForeignKey(Shop, on_deletemodels.CASCADE, related_nameorders) created_at models.DateTimeField(db_indexTrue) amount models.DecimalField(max_digits10, decimal_places2) delivery_fee models.DecimalField(max_digits8, decimal_places2) status models.CharField(max_length20, choicesSTATUS_CHOICES, defaultpending)在訂單的created_at上加db_indexTrue因為后面所有趨勢分析都會按這個字段分組聚合有索引和沒索引的區(qū)別非常明顯。3.2 用Django ORM完成日常查詢、刪除與聚合熱搜詞里有“django執(zhí)行查詢-刪除對象”這里展開說。Django ORM最常用的幾個操作。新增一條訂單shop Shop.objects.get(id1) Order.objects.create( order_no202501010001, shopshop, created_at2025-01-01 12:00:00, amount35.50, delivery_fee5.00, statuscompleted, )查詢已完成訂單數(shù)量completed_count Order.objects.filter(statuscompleted).count()刪除對象# 刪除單條 order Order.objects.get(order_no202501010001) order.delete() # 批量刪除delete() 會返回(coll_count, {model_name: count}) Order.objects.filter(statuscancelled).delete()刪除時需要注意外鍵行為。在on_deletemodels.CASCADE下刪除店鋪會連帶刪除該店鋪的訂單如果只想保留歷史訂單選models.PROTECT或SET_NULL更安全。聚合統(tǒng)計是分析系統(tǒng)的核心用aggregate和annotatefrom django.db.models import Count, Sum, Avg total_amount Order.objects.filter( statuscompleted ).aggregate(totalSum(amount), avgSum(amount) / Count(id))按店鋪統(tǒng)計訂單數(shù)result ( Order.objects.filter(statuscompleted) .values(shop__name) .annotate(order_countCount(id)) .order_by(-order_count) )看到shop__name這種寫法代表跨表關(guān)聯(lián)查詢。Django ORM可以用雙下劃線把關(guān)系鏈串起來這是分析系統(tǒng)里最常用的寫法。我經(jīng)常跟新手強調(diào)數(shù)據(jù)量不大的時候先在Django shell里驗證SQL的結(jié)果對不對再寫進視圖不要直接在瀏覽器里刷頁面調(diào)試。3.3 Admin后臺快速錄入與CSV批量導(dǎo)入Django自帶Admin是這套方案的一個隱性優(yōu)勢。orders/admin.pyfrom django.contrib import admin from .models import Shop, Order, Courier, DeliveryRecord admin.register(Order) class OrderAdmin(admin.ModelAdmin): list_display (order_no, shop, created_at, amount, status) list_filter (status, created_at)這樣運營人員就能直接用后臺錄單、查單。但是手動錄入大量歷史數(shù)據(jù)不現(xiàn)實最好做一個CSV導(dǎo)入接口。最簡單的版本import csv from django.http import HttpResponse from django.db import transaction def import_orders(request): ... with transaction.atomic(): for row in reader: shop Shop.objects.get(idrow[shop_id]) Order.objects.create( order_norow[order_no], shopshop, created_atrow[created_at], amountrow[amount], delivery_feerow[delivery_fee], statusrow[status], )用transaction.atomic()包住整個導(dǎo)入過程萬一中間有一行數(shù)據(jù)異常要么全部回滾要么全部寫入不會出現(xiàn)“導(dǎo)了一半數(shù)據(jù)庫里臟數(shù)據(jù)”的情況。另外CSV導(dǎo)入前建議先做字段完整性校驗比如訂單號是否重復(fù)、店鋪ID是否存在減少入庫后才發(fā)現(xiàn)問題的概率。4. 數(shù)據(jù)分析指標與可視化實現(xiàn)4.1 外賣配送分析的指標怎么定義才不跑偏在寫聚合查詢之前先把指標口徑統(tǒng)一否則后面返工特別痛苦。我常用的口徑定義訂單量趨勢按天或按小時統(tǒng)計“已完成”訂單數(shù)取消單不計入業(yè)務(wù)量。平均配送時長delivered_time - created_at只統(tǒng)計已完成訂單。高峰時段按小時分桶統(tǒng)計訂單量找出top10時段往往午高峰和夜宵時段一起出現(xiàn)。騎手效率統(tǒng)計每位騎手的日均完成單量、平均配送時長、超時率。區(qū)域熱度把所有完成訂單的店鋪經(jīng)緯度聚合到區(qū)域網(wǎng)格用熱力圖表示。商家貢獻按店鋪聚合銷售額、訂單量、客單價。這里我特別建議加一個“取消率”指標某一時段取消率突然升高很可能代表配送壓力過大或惡劣天氣影響比單純看訂單量更早發(fā)現(xiàn)問題。比如周五晚高峰突降暴雨訂單量可能沒變但取消率翻倍這時候運營就應(yīng)該提前安排增援運力而不是等到訂單積壓才反應(yīng)。4.2 后端API如何返回可視化需要的數(shù)據(jù)把統(tǒng)計邏輯放在視圖函數(shù)里返回JSON給前端。一個訂單量趨勢接口的完整寫法from django.http import JsonResponse from django.db.models import Count from django.db.models.functions import TruncHour from .models import Order def order_trend_api(request): trend_data ( Order.objects.filter(statuscompleted) .annotate(hourTruncHour(created_at)) .values(hour) .annotate(order_countCount(id)) .order_by(hour) ) items [{ hour: item[hour].strftime(%Y-%m-%d %H:00), count: item[order_count], } for item in trend_data] return JsonResponse({items: items})注意幾個細節(jié)TruncHour是Django 2.2之后內(nèi)置的數(shù)據(jù)庫函數(shù)可以在數(shù)據(jù)庫層面按小時截斷時間比Python里循環(huán)處理快很多。不能用item[hour]直接丟給JsonResponsedatetime對象不是JSON可序列化類型所以要先用strftime格式化。如果列表里中文亂碼在JsonResponse里加上json_dumps_params{ensure_ascii: False}即可。如果要做騎手效率排行接口可以仿照這種寫法from django.db.models import Count, Avg, F def courier_stats_api(request): stats ( DeliveryRecord.objects .values(courier__name) .annotate( order_countCount(id), avg_minutesAvg(F(delivered_time) - F(accepted_time)) ) .order_by(-order_count)[:20] ) items [{ name: item[courier__name], count: item[order_count], avg_minutes: round(item[avg_minutes].total_seconds() / 60, 1) if item[avg_minutes] else 0, } for item in stats] return JsonResponse({items: items})F表達式用于在數(shù)據(jù)庫層面對同一行的多個字段做運算不需要把整行加載到Python內(nèi)存中性能上更優(yōu)。這也是熱詞里“django執(zhí)行查詢”被頻繁搜索的原因——ORM的查詢能力直接決定了分析系統(tǒng)的開發(fā)效率。4.3 前端渲染讓圖表動起來前端需要兩張核心圖表訂單趨勢折線圖和店鋪排行柱狀圖。模板頁面templates/analysis/dashboard.htmldiv idtrendChart stylewidth:100%; height:400px;/div div idshopChart stylewidth:100%; height:400px;/div script src{% static echarts.min.js %}/script script function renderTrend(items) { var chart echarts.init(document.getElementById(trendChart)); chart.setOption({ title: { text: 訂單量趨勢 }, tooltip: { trigger: axis }, xAxis: { type: category, data: items.map(item item.hour) }, yAxis: { type: value }, series: [{ type: line, smooth: true, areaStyle: {}, data: items.map(item item.count) }] }); } fetch(/analysis/order-trend/) .then(res res.json()) .then(data renderTrend(data.items)); /script前端拿到數(shù)據(jù)后只用負責(zé)把數(shù)組映射到坐標軸數(shù)據(jù)計算邏輯全在后端這個分離結(jié)構(gòu)對后期維護友好得多。改圖表類型、加第二個Y軸都不需要動后端代碼。不建議在服務(wù)端動態(tài)拼接大段JS調(diào)試起來非常痛苦。模板里的console和onerror在開發(fā)階段可以保留等穩(wěn)定了再清理掉。4.4 大屏模式的擴展思路做演示的時候會發(fā)現(xiàn)單張卡片式圖表不夠直觀。我的做法是在dashboard頁面基礎(chǔ)上再做一個大屏頁面三行多列頂部放核心數(shù)字卡片今日訂單量、平均配送時長、訂單完成率中部放訂單趨勢折線圖和商家餅圖底部放熱力圖和時間維度切換按鈕。ECharts的grid布局可以自由控制每張圖的位置。如果需要大屏自動刷新用setInterval(() { refreshData(); }, 30000)每30秒重新請求一次接口。這樣業(yè)務(wù)團隊把大屏投到會議室電視上不需要手動刷新就能實時掌握運力情況。5. 常見問題與排查技巧實錄5.1 時區(qū)問題直接導(dǎo)致統(tǒng)計折線圖偏移8個小時這個是新手最容易崩潰的問題。本地測試的時候數(shù)據(jù)正常部署到服務(wù)器后圖表全部比實際晚8小時或早8小時。原因就是Django的USE_TZ默認是True數(shù)據(jù)庫保存的是UTC時間你看到的本地時間其實是模板渲染時轉(zhuǎn)換的但分組統(tǒng)計TruncHour按UTC截斷后算出來的自然不是北京時間。我的處理方式是把項目定位為“本地業(yè)務(wù)系統(tǒng)”直接在settings里設(shè)TIME_ZONE Asia/Shanghai、USE_TZ False所有時間戳在錄入時先統(tǒng)一轉(zhuǎn)成本地時間再入庫。如果以后要展示給海外用戶再把USE_TZ改成True并在模板里調(diào)用localtime過濾器。用USE_TZFalse犧牲了一點國際化彈性但換來的是統(tǒng)計口徑簡單直接尤其在按小時聚合這種場景下能避免大量誤判。5.2 N1查詢列表頁面卡成PPT當(dāng)我在店鋪列表頁面展示所有店鋪及其訂單量時一開始直接寫循環(huán)shops Shop.objects.all() for shop in shops: shop.order_count shop.orders.count()表面上看沒問題實際上每循環(huán)一次就執(zhí)行一條SQL100個店鋪就是101條查詢。優(yōu)化方法是在查詢時用annotate一次性搞定from django.db.models import Count shops Shop.objects.annotate(order_countCount(orders))使用Django調(diào)試工具django-debug-toolbar可以在頁面底部看到SQL查詢數(shù)量和耗時。我通常把這個工具當(dāng)作性能檢查的第一道關(guān)卡。如果發(fā)現(xiàn)查詢次數(shù)激增優(yōu)先檢查循環(huán)內(nèi)部有沒有調(diào)用ORM查詢?nèi)缓蟀淹怄I關(guān)聯(lián)的取值改成select_related或prefetch_related比如orders Order.objects.select_related(shop, deliveryrecord).all()這樣關(guān)聯(lián)表會通過JOIN一次取回避免循環(huán)中觸發(fā)額外SQL。5.3 圖表不顯示的幾種原因我遇到過幾種情況ECharts的容器高度是0。div設(shè)置了寬度但沒設(shè)置高度或者高度百分比失效圖表直接不顯示。記得給圖表容器寫固定高度。js文件路徑404。模板里寫了{% static %}但settings沒配STATICFILES_DIRS或者沒執(zhí)行collectstatic。本地開發(fā)時用python manage.py runserver會自動找靜態(tài)目錄生產(chǎn)環(huán)境必須執(zhí)行collectstatic并把文件復(fù)制到STATIC_ROOT。數(shù)據(jù)為空時數(shù)組為空圖表坐標軸沒有分類數(shù)據(jù)看起來像“白屏”。后端保證返回的數(shù)組不為空前端可以增加空數(shù)據(jù)提示。script放在head里DOM還未渲染完就初始化圖表也會導(dǎo)致不顯示。我習(xí)慣把圖表相關(guān)script放到body的最后或者用window.onload包一層。5.4 接口中文亂碼與跨域JSON返回的數(shù)據(jù)如果含中文需要return JsonResponse(data, json_dumps_params{ensure_ascii: False})如果不指定默認會把中文轉(zhuǎn)成\uXXXX格式瀏覽器里顯示為“亂碼”。這個其實不影響功能但排障時很難讀。后來考慮把前端獨立做成Vue或React應(yīng)用就需要CORS跨域支持。用pip安裝django-cors-headerssettings里加CORS_ALLOW_ALL_ORIGINS True開發(fā)環(huán)境生產(chǎn)時改成白名單。這步提前配好不虧。5.5 數(shù)據(jù)庫索引統(tǒng)計查詢慢的元兇訂單表數(shù)據(jù)量起來后Order.objects.filter(statuscompleted, created_at__range[start, end])這類查詢會變慢。解決方式很簡單class Order(models.Model): ... created_at models.DateTimeField(db_indexTrue) status models.CharField(max_length20, db_indexTrue)對于經(jīng)常做group by shop_id的場景可以添加聯(lián)合索引class Meta: indexes [ models.Index(fields[status, created_at]), ]用聯(lián)合索引可以讓“按狀態(tài)時間”的過濾和聚合都更快。我在數(shù)據(jù)達到幾十萬行時做過對比加索引前后單次統(tǒng)計從秒級下降到了毫秒級這個優(yōu)化成本很低收益卻很明顯。6. 部署上線與后續(xù)擴展思路6.1 使用Gunicorn和Nginx把系統(tǒng)跑起來開發(fā)環(huán)境runserver只適合調(diào)試正式上線用Gunicorn。流程pip install gunicorn gunicorn takeout_analysis.wsgi:application --bind 0.0.0.0:8000 --workers 3workers數(shù)量一般按CPU核心數(shù)*21設(shè)置。然后配置Nginx反向代理server { listen 80; server_name your_domain; location /static/ { alias /path/to/takeout_analysis/static/; } location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }靜態(tài)文件交給Nginx托管動態(tài)請求轉(zhuǎn)發(fā)給Gunicorn。如果服務(wù)器是Linux系統(tǒng)提前安裝Python環(huán)境和相關(guān)依賴操作流程與本地安裝類似。Docker部署也是常見的路線把項目寫成Dockerfile創(chuàng)建鏡像后運行容器環(huán)境一致性問題能大幅減少。6.2 后續(xù)可以擴展哪些能力讓系統(tǒng)更完整第一個是實時推送。如果業(yè)務(wù)希望大屏頁面能實時更新訂單數(shù)據(jù)可以在Django基礎(chǔ)上引入Channels用WebSocket把新訂單推送前端。Django和WebSocket的整合并不復(fù)雜核心是配置ASGI應(yīng)用、定義消費者前端用WebSocket對象接收消息再刷新圖表數(shù)據(jù)。第二個是權(quán)限管理。熱搜詞里提到的“django rabc”本質(zhì)上是基于角色的訪問控制。Django自帶User、Group和Permission可以在管理員后臺分配權(quán)限比如運營只能看報表但不能修改歷史數(shù)據(jù)管理員才能管理店鋪和配送員。這個模塊做好后系統(tǒng)就不再只是開發(fā)者的工具可以放心交給業(yè)務(wù)部門。第三個是定時任務(wù)。每天凌晨跑一次數(shù)據(jù)匯總把前一日的訂單量、配送時效、取消率寫入一個匯總表頁面只讀匯總表而不是實時聚合并表響應(yīng)速度會更快。實現(xiàn)方式可以用Celery的beat任務(wù)或者簡單點用crontab調(diào)用管理命令。第四個是地理圍欄。給店鋪配置半徑判斷用戶下單地址是否在配送范圍內(nèi)超范圍自動提示這個對實際運營有直接價值。整體來看這套“Django ECharts 分析指標”的組合做外賣配送分析系統(tǒng)綽綽有余而且很容易擴展成其他業(yè)務(wù)場景的可視化分析平臺。寫到這里我想分享一個真實的體會這類分析可視化項目技術(shù)?？蚣懿⒉皇亲铍y的真正決定成敗的是數(shù)據(jù)指標口徑是否清晰、數(shù)據(jù)模型設(shè)計是否合理。我一開始拿到“外賣配送分析”需求時第一版系統(tǒng)什么都想展示結(jié)果做了幾個圖表后發(fā)現(xiàn)口徑互相矛盾——有的按北京時間統(tǒng)計有的按UTC統(tǒng)計有的把取消訂單也計算進銷售額返工的時間遠超預(yù)期。后來我把所有指標口徑寫進項目README每一個接口注釋里寫清楚計算邏輯項目才真正穩(wěn)定下來。所以如果你準備上手做這樣一個系統(tǒng)先花兩天時間整理清楚指標定義和字段含義絕對比急著寫代碼有價值得多。另外再分享一個小技巧一定要把系統(tǒng)里所有查詢放在數(shù)據(jù)庫層面聚合用Django ORM的annotate和aggregate不要在Python端循環(huán)求和。我踩過的坑是剛開始圖省事把數(shù)據(jù)拉到Python里算結(jié)果訂單只有幾萬條還能忍受到了幾十萬條接口直接卡到十幾秒。優(yōu)化到數(shù)據(jù)庫層面之后同一套統(tǒng)計邏輯穩(wěn)定在幾百毫秒。這是我個人在這個項目里收獲最大的一點希望對你也有幫助。