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