企业官网建设流程全解析

去年某段时间，我手上接过一套农产品批发市场的销量分析需求。最开始大家想得很简单——把每个市场每天的订单导出来，用Python写个脚本，pandas处理，再画几张图。真等数据铺开之后才发现，光三个农批市场群累积半年的历史流水就超过了亿级行，单机Python脚本连读都读不进去，更不用说跑聚合和出报表。后来我梳理了一整套链路：HDFS负责原始数据的存储与归档，Spark做大规模的聚合运算，Python接住聚合后的结果去做指标提取和可视化呈现——这也就是标题里那套“python hadoop spark”组合的由来。

这套系统做下来，最大的收获不是某个组件用得多熟，而是摸清了“农产品销售数据分析”这一类项目的通用套路：数据从哪里来、哪些地方最脏、哪些计算必须在分布式框架里跑、哪些分析交给pandas就够、可视化到底该怎么设计才不变成一块没人看的屏。这篇文章就按这条链路从头到尾讲一遍，包括关键代码、参数设置和踩过的坑。

1. 从“Excel能算”到“不得不搭平台”：农产品销售数据到底难在哪

1.1 一张典型的农批市场流水表长什么样

做农产品销量分析，绕不开的第一件事就是看交易流水。以我接手的那套农批市场销售系统为例，每个市场每天都会产生大量电子结算订单，来源主要是档口结算终端和部分手工补录，偶尔还有产地直发过来的物流单。一张标准的流水表，核心字段无非是这几类：订单编号、交易日期、市场编号、档口编号、采购商编号、品类、单品名称、规格等级、成交数量、成交单价、成交金额。

看起来简单，但实际数据比这脏得多。同一个单品在不同市场叫法不一样，西红柿有人写“番茄”，有人写“西红柿”，还有人把“圣女果”也归到这一类；数量单位更是混乱，有的按公斤，有的按斤，部分大宗交易直接按吨写；单价和金额对不上的情况也时有发生。这些字段在后续清洗环节能造成大量重复劳动，所以我在设计一开始就把“双方约定的规范字段”提前定死，让上游系统按这个口径导出。

除了订单流水，分析系统通常还要关联几张维度表：市场表（市场编号、名称、所在区域、市场类型）、商品表（品类、单品名、规格等级、默认单位）、采购商表（采购商编号、类型、归属地）。其中采购商表非常有分析价值，因为农产品批发市场的交易高度依赖老客复购，采购商的数量和结构往往比档口数量更能反映市场活跃度。

1.2 为什么单机方案先撑不住

最开始我也想过，几个市场的数据而已，用Python加pandas跑不就行了。真等数据导出来，半年历史订单超过一亿行，压缩前的CSV就有四十多GB，pandas一次性读进来内存直接爆掉。就算勉强读进来了，之后每次调整聚合口径都要重跑一次全量，一跑就是几个小时，报表根本跟不上业务节奏。

我办公室同事常说，pandas处理数据就像把整个仓库搬进客厅再慢慢整理，客厅小的时候没问题，仓库大了就麻烦了。这个比喻很贴切。单机方案的问题不只是内存，还有“反复迭代的成本”——你每多试一个分析维度，就要把所有数据再扫一遍。而分布式框架解决的就是两件事：数据放得下、计算扛得住。这正是Hadoop加Spark在这套系统里的核心价值。

到这里，处理链路就变成三块：Hadoop负责把原始数据放到底层分布式存储上，Spark负责大规模聚合计算，Python只接住聚合后的数据做指标提取和可视化。这个架构不一定最花哨，但它足以让分析工作从“白天导数据、晚上出报表”变成“数据每天自动跑，上班直接看结果”。

1.3 这套组合到底适合什么规模

后面我逐步验证，这套组合真正适合的是“单日几十万行、历史累计过亿行”这个量级。如果一天只有几千行订单，用一个普通数据库就行，完全不需要分布式架构。要警惕的是为了用技术而用技术，Hadoop生态一旦搭起来，运维成本是实打实的。

我判断是否需要上分布式的标准很简单：单机方案内存占用是否稳定超过可用内存的一半；计算任务是否要跨多小时才能出结果；是否要反复调整口径导致每次全量重算。三个条件只要命中两条，就值得上Hadoop加Spark。否则，越简单的架构越是好架构。

2. 数据先入湖：HDFS上的原始存储与分区治理

2.1 原始数据为什么要放HDFS

业务库每天产生的流水是给交易系统用的，不能因为分析任务而拖垮它。我在项目里做了两层隔离：业务方的结算系统继续用自己的数据库，分析系统通过定时导出，把当天增量文件推到HDFS的原始目录下。

HDFS在这里承担的是“原始档案室”的角色。它的设计是写一次、读很多次，数据以块的形式分布在多个节点上，默认存三份副本。副本机制有点像图书馆里的同一本书买三份放在不同房间，一本被水泡了，另外两本还能顶上。

很多刚接触这类架构的人会问：直接放在服务器本地磁盘不就行了？本地磁盘的问题是没有横向扩展能力——磁盘满了要手工清理，节点挂了数据就没了；HDFS的好处是扩容方便，数据可靠性由框架保证。至少对我这个场景来说，每天定时拷贝、按月归档，比手工维护一台快塞满的服务器省心得多。

2.2 分区和文件格式定了，后面改起来会哭

原始数据落进去之后，我习惯立刻做一层轻量的“标准化落盘”，把流水的CSV转成Parquet列式存储，并按日期分区。推荐的目录结构是：

/data/raw/agri_sales/20250101.csv /warehouse/agri_sales/dwd_daily/dt=20250101/

用Parquet而不是CSV有三个理由：一是列式存储只读取查询需要的列，省I/O；二是内置压缩，体积能压到原来的三分之一左右；三是Spark对它支持得很成熟，谓词下推能自动跳过无关分区的文件。压缩层面我用的是Snappy，因为它在压缩比和解压速度之间比较均衡，实测对亿级数据的聚合任务，时间开销比gzip低不少。

分区字段一定不要乱设。我们按交易日期dt做主分区、市场编号market_id做次级分区。如果决定按日期分区，就要约束上游必须每天至少一次推送数据，否则第二天计算任务会因为缺分区而失败或产出不完整的数据。这个坑我在上线第二周踩过，后面专门写了一个分区完整性校验，每天先检查分区是否存在、数据量是否达到阈值，再启动计算任务。

2.3 清洗这一层做的不是魔法，是规则

清洗看起来不高级，但直接决定分析结果准不准。这一层我总结了四个必做动作。

第一是统一编码。多个市场的导出文件里，有的按UTF-8导出，有的按GBK导出。我在Spark读取时统一指定编码，并把GBK转UTF-8的文件先做一次转码，避免后续接Python时中文乱码。

第二是统一单位。把“斤”“吨”全部换算成公斤。这里的教训是不要试图在分析阶段再换算，一定要在入库前就换算好，否则每个分析SQL都要带一次转换逻辑，出错的概率成倍增加。

第三是过滤异常值。金额小于等于0、数量小于等于0的记录，我直接过滤掉，同时保留一条审计日志，记录被清洗的行数。这里不能简单删除，要留痕，否则月底对账时找不到责任方。

第四是字段类型统一。交易日期全部转成标准日期字符串，单价保留两位小数，数量用double。很多报表数字串成乱码，追根究底就是字段类型没统一。

这一段核心逻辑用PySpark表达的话大概是这样的：

from pyspark.sql import SparkSession from pyspark.sql.functions import col, to_date, trim from pyspark.sql.types import DoubleType spark = SparkSession.builder.appName("agri_sales_daily_etl").getOrCreate() raw = ( spark.read.option("header", True) .option("encoding", "UTF-8") .csv("hdfs://hadoop-nn:9000/data/raw/agri_sales/20250101.csv") ) cleaned = ( raw.filter(col("amount").cast(DoubleType()) > 0) .filter(col("qty").cast(DoubleType()) > 0) .withColumn("dt", to_date(col("trade_date"), "yyyy-MM-dd")) .withColumn("category", trim(col("category"))) .withColumn("qty", col("qty").cast(DoubleType())) .withColumn("amount", col("amount").cast(DoubleType())) ) cleaned.write.mode("overwrite").format("parquet").partitionBy("dt").save( "hdfs://hadoop-nn:9000/warehouse/agri_sales/dwd_daily" )

注意这段代码用了mode("overwrite")，配合按日期分区，每次跑同一个日期的任务都会覆盖该日期的分区，天然实现了幂等。这样即使当天凌晨调度失败，补跑也不会产生重复数据。

3. Spark上场：亿级流水下的聚合计算与调度

3.1 为什么我直接选了Spark而不是写MapReduce

Hadoop生态里最早能算东西的是MapReduce，但它有一个让开发效率很低的点：每次map和reduce之间都要落一次磁盘，中间结果还要反复写读。对农产品销量这种“同一份数据要按多组维度反复聚合”的场景，MapReduce每调整一个维度就要重读一遍全部文件，会非常痛苦。

Spark的思路完全不同。它先把数据切块分布到各个executor，利用内存做计算，算子之间形成一个有向无环图，能尽量把多个环节放在内存流水线上跑完。说白了，MapReduce像是走到一个路口就要把行李卸下来重新写地址，Spark是出发前把整条路线都规划好，一口气跑完。在实际聚合任务里，同样扫一遍亿级流水，Spark的耗时通常是MapReduce的三分之一甚至更低。

3.2 核心聚合逻辑：每天按什么维度算、算哪些指标

分析系统的第一张底表就是“日维度商品汇总”。我在这一步把粒度定为：日期、市场、品类、单品、规格等级。指标至少包括：成交量、成交额、加权均价、成交笔数、涉及的采购商数量。

Spark SQL写起来并不复杂，关键是明确权重的计算口径。加权均价不是把各笔单价做平均，而是用总成交金额除以总成交量。如果只取简单平均，就会被少量高价订单带偏。代码大致是这样的：

from pyspark.sql.functions import round, sum as _sum result = ( cleaned.groupBy("dt", "market_id", "category", "product_name", "spec_level") .agg( round(_sum("qty"), 2).alias("total_qty"), round(_sum("amount"), 2).alias("total_amount"), round(_sum("amount") / _sum("qty"), 3).alias("weighted_avg_price"), _sum("order_cnt").alias("order_cnt"), _sum("buyer_cnt").alias("buyer_cnt"), ) )

这就是整套分析系统的“主表”来源。所有报表、趋势、排名，都先拿这张表，再跟市场维度表、日期维度表做关联。之所以敢把粒度做得这么细，是因为聚合后的行数已经降到百万级以内，对任何后续组件都不是压力。

3.3 聚合任务里最该处理的三个性能问题

第一，内存溢出。亿级数据如果shuffle分区数设低，每个executor要处理的块就很大。我通常把spark.sql.shuffle.partitions设成200到400之间，并让每个executor的内存尽量在任务提交时通过参数固定住，动态分配反而容易造成任务之间互相挤内存。

第二，数据倾斜。农产品数据里有明显的“热点”，比如某个市场的西红柿销量可能占了晒菜、茄果等好几个分类的30%以上，按单品名分组时，这个key会同时涌向同一个reduce任务，造成其他任务几十秒跑完、这个任务二三十分钟还在跑。我处理的办法是对热点key做加随机后缀打散，再按两层聚合合并结果。这种操作解释起来复杂，但代码不长，核心思想就是把“一个超大队列”拆成“多列队伍分别处理后汇总”。

第三，小文件问题。清洗写入时如果按日期分区但spark的并行度设置太高，很容易产生几千个几十KB的小文件，后续读取时会因为文件数太多拖慢速度。我在写入前用coalesce控制输出文件数，按分区大小大概每个文件控制在200MB左右，既方便后续读取，也不会让元数据过载。

调度层面我用的是定时触发。分析任务一般固定在凌晨跑，因此依赖“前一天”的数据分区必须完整。我在调度脚本前面加了一个分区检查命令，一旦发现缺分区就发告警，不启动清洗计算，避免产出半成品指标表。

4. 分层输出：Spark算完之后，数据应该怎么给下游

4.1 聚合结果分几层，各层的用途是什么

Spark算完的结果不能一股脑塞给可视化系统。我习惯分成三层：明细层、汇总层、应用层。

明细层就是刚才说的“日维度商品汇总”，按日期和市场两级分区，仍然存放在HDFS上，它解决的是“任何新指标都能回溯重算”的问题。比如说后来业务方提出要看“每个档口的月度环比”，我只需要在这个明细层上加group by，不需要再动原始流水。

汇总层是把明细层的核心指标，按月、按品类、按市场做预聚合，输出到MySQL。这个数据量已经很小，可能只有几万行，但对日常报表足够。应用层则是把Top榜单、同比环比、异常告警等业务要直接看的指标算好，也是直接给Python端读的数据。

为什么聚合结果要落到MySQL而不是继续留在HDFS？因为分析端和可视化端更习惯SQL和pandas，MySQL查询延迟毫秒级，连接工具也多。HDFS适合大批量扫描，但单条查询其实不合适。两层叠加的坏处是要多写一份数据同步任务，但换来的是下游极低的折腾成本。每次指标口径变了，最多重跑一个Spark任务，再同步一次MySQL，几分钟搞定。

4.2 Python读取的边界：永远别拿pandas去读HDFS原始数据

Python在整个链路里是“轻量分析”的定位，不是“大计算”的定位。我个人给项目定了一条红线：pandas只允许读取MySQL里的汇总层和应用层数据，原始流水和明细层一律不直接碰。

如果哪一天分析需求特别复杂，例如要算所有单品在每一天的最终成交价波动，我会回到Spark先算好一张中间表，再同步到MySQL让Python读。这么做的好处是，pandas内存占用永远可控，报表接口也稳定。很多项目的失败不是分析逻辑不会写，而是某一层越权去处理了自己不该处理的量级，最后把内存跑爆，整个服务跟着宕掉。

4.3 指标口径对齐是怎么落地的

农产品销售行业经常遇到“这个月销量为什么和业务系统对不上”的质疑。核心原因通常是口径不一致：财务按开票金额算，市场按结算流水算，如果系统里有退货单、冲单，两边自然对不上。

我在建表时把所有指标的算法写进了表注释，并且在可视化页面每个数字附近加了一个小问号说明口径。比如“销售量”明确为“成交订单中实际交割数量之和，单位公斤”；“销售额”明确为“同口径下成交金额之和，单位元”。上述口径都来自清洗后的联分明细，不做任何二次估算。一开始业务方觉得多此一举，等出现几次对账分歧后，这套注释成了双方沟通的依据。这里把几个核心指标的口径列在下面，方便大家在实战中直接复制：

5. Python接手：品类画像、价格弹性和销量预判

5.1 分析核心不再是“处理数据”，而是“解释数据”

到了Python这一层，数据已经从亿级压到了百万级甚至万级。我们要做的就不是再写Spark任务，而是从业务视角找出问题和规律。

我用pandas按月份、品类、单品做透视，看每个品类的季节波动。以某市场西红柿为例，月度销售指数在7到8月明显高于全年均值，12月到次年2月则跌到全年六成左右。这背后其实是产季逻辑：夏季本地大棚和露地菜集中上市，量大价格低；冬季主要靠长途运输，量小价高。农民和采购商对这个规律其实心知肚明，但系统把指数量化之后，大伙看报表就能直接安排采购节奏。

季节指数的计算也不复杂，就是每个月的平均日销量除以全年的平均日销量，再乘以100：

import pandas as pd sales = pd.read_sql( "SELECT dt, total_qty FROM ads_agri_daily " "WHERE market_id='M001' AND product_name='西红柿' ORDER BY dt", conn, ) sales["month"] = sales["dt"].str[:7] monthly_avg = sales.groupby("month")["total_qty"].mean() season_index = (monthly_avg / sales["total_qty"].mean()) * 100

算出来之后会发现很多品类都有自己的“脾气”：叶菜类进入高温季节后销量明显下滑，菌菇类秋冬季上升，水果类在春节前一个月冲高。这些规律单独看不算新发现，但做成指数之后，市场管理方就能给定点采购、仓储安排提供量化依据。

5.2 价格弹性和滞销品识别

销量和价格之间不是简单的从属关系。菜价上涨时销量不一定立即下滑，因为供应量会先涨；等到大量到货砸价，销量又可能冲高。我建议用“周均价”和“周销量”做相关性观察，并区分蔬菜和水果两类分别建模，因为水果礼品属性强，节假日拉动明显，蔬菜相对刚性。

滞销品识别是另一项实用功能。我给每个品类设置一个“周销量低于该品种近三个月均值20%以上且价格持续下行”的规则，命中即进入滞销清单。这套规则比人工肉眼盯表靠谱，我在试运行阶段真抓出来两个受天气影响导致大量到货的滞销单品，反馈给市场后及时调整了后续到车安排，减少了档口损失。

5.3 销量预测：先从简单的指数平滑开始

很多做预测的人喜欢一上来就上LSTM，但农产品销售数据波动受天气、节假日、产地供应影响极大，数据不规整时复杂度成倍上升。我建议先做一套务实的预测：用7日移动平均去掉短期波动，再用带季节分量的指数平滑拟合数据，最后给出未来7天的预测区间。

以下是我经常用的简化代码：

import pandas as pd from statsmodels.tsa.holtwinters import ExponentialSmoothing df = pd.read_sql( "SELECT dt, sum(total_qty) AS qty FROM ads_agri_daily " "WHERE market_id='M001' AND category='茄果类' GROUP BY dt ORDER BY dt", conn, ) df["dt"] = pd.to_datetime(df["dt"]) series = df.set_index("dt")["qty"].astype(float) model = ExponentialSmoothing( series, seasonal_periods=7, trend="add", seasonal="add" ).fit() forecast = model.forecast(7)

这套模型跑下来，对多数叶菜类、小规模市场的日销量预测误差能控制在15%上下。对预测结果的使用也要克制：它只能作为采购计划的参考输入，不能直接自动下单。因为春节、暴雨、台风这类极端情况，模型是不知道的，必须保留人工修正环节。我在系统里专门留了一个“预测结果人工修正”的入口，修正记录会累积下来，后续可以作为特征辅助模型优化。

5.4 维度补充：把天气和节假日放进分析

如果说有什么值得进阶的方向，就是把外部数据纳入分析。我这里所说的外部数据不是多高深的东西，而是天气和节假日。

某个叶菜品类连续一周阴雨，批发市场的到货量通常会下降，价格上涨，而销量本身不会急剧变化。把产地天气和到货量做联动分析，对采购决策有直接帮助。但需要提醒的是，接入天气数据要从权威气象接口按日拉取历史数据，且生产端要带时间戳落库。我第一次做的时候没有保留抓取时间，后来每次指标对不上都怀疑模型，最后才查到是天气数据更新延迟导致的错位。所以任何外部数据都要有快照时间，这算是一个实用经验。

6. 可视化系统：让数据从“能算出来”到“能看明白”

6.1 选了Flask加ECharts而不是重型BI

可视化这一层，市面上可选方案很多，从Power BI、帆软到自研React大屏。我最终选了Python生态比较顺手的Flask配ECharts。理由有三：团队技术栈本来就是Python，维护成本低；聚合数据已经在MySQL里，Flask写几个查询接口非常直接；ECharts交互成熟，各类图形不需要从零造轮子。

页面上按照业务方的习惯分成三组：总览大屏、市场明细、单品分析。总览大屏是给市场管理人员看的，市场明细是给各业务科室看的，单品分析则是给采购商做行情参考的。这里的关键不是功能数量，而是每个角色的页面里只放他关心的内容。一个页面全是图不代表有价值，有价值的页面是让人在5秒内找到当前最该关注的东西。

6.2 四个核心视图到底怎么设计

我实际做了四个最常用的视图。

第一块是当日总览卡，包含四个指标卡：今日成交量、今日成交额、今日加权均价、今日交易笔数。这四个卡片占屏空间不大，但决策者第一眼就要看到当天生意是升是降。我在每个卡下面都放了环比箭头，数字升绿降红，符合农产品市场运营方的直觉。

第二块是品类占比环形图，按成交量看蔬菜、水果、鲜肉、水产等品类的占比。环形图适合快速看结构，但要注意当品类过多时颜色会系混乱，所以我把占比低于2%的归入“其他”。

第三块是近30天销量趋势折线图，可以先按品类范围选择，再叠加一条7日移动平均线。移动平均线和实际线的分离程度，本身就是一种信号：如果实际线远低于均线，说明近期行情异常。

第四块是市场排名柱状图，按当日或当月成交量对各市场排名，点击某个市场柱子后可以进入该市场的明细页，继续下钻到品类、单品。

下钻层级设计为：市场 → 品类 → 单品 → 日趋势。ECharts本身支持事件绑定，我在单品名称上加了click事件，跳转到带日期范围的单品页，同时单品页再按日展示趋势。这一步从用户角度看只多了一次点击，但从实现看却要把页面路由、筛选条件、图表联动都处理好，是整个可视化系统里最复杂的部分。

6.3 接口与缓存：别让每一次看报表都重新跑一遍聚合

可视化页面最怕的就是慢。日汇总数据本身不大，但如果每次打开页面都由Flask实时查MySQL，前端还会因为多个图表并行请求把后端压出大量慢查询。我加了一层Redis缓存，按接口和参数生成缓存key，设置10分钟过期，过期后再回源MySQL查询并重建缓存。这样页面第二次打开时基本没有数据库压力。

缓存实现很简单，核心思路就是先查缓存再查库：

import redis, json from flask import jsonify cache = redis.Redis(host="127.0.0.1", port=6379, db=1) def get_market_daily(date): key = f"kpi:market_daily:{date}" cached = cache.get(key) if cached: return jsonify(json.loads(cached)) rows = query_mysql( "SELECT market_id, total_qty, total_amount, avg_price " "FROM ads_agri_daily WHERE dt = %s", date, ) cache.setex(key, 600, json.dumps(rows, ensure_ascii=False)) return jsonify(rows)

这个模式不复杂，但它把大部分报表接口的响应时间稳定压到了3秒以内。如果某些页面真的需要看实时数据，再单独开实时接口，不要全部混用。缓存一致性在这个场景下不用做得很精细，因为分析报表本身允许分钟级延迟。

6.4 权限和导出：可视化之外容易忽略的两件事

报表平台上线之后，业务方首先要求的是权限。不同科室只看自己所辖市场的数据，不能越权查看其他市场报价。我在Flask里做了一个极简的角色过滤中间件，登录后把角色与市场列表绑定，所有查询都强制加上market_id IN (...)条件。宁可代码写重一点，也不要在前端隐藏字段，因为前端隐藏只是视觉欺骗。

导出功能同样容易踩坑。直接把接口暴露给Excel下载，会让大查询把数据库拖慢。我的处理是把导出做成异步任务：用户点击导出后，后端生成一份CSV放到临时目录，然后给用户一个下载链接，导出文件按天清理。这样既满足业务习惯，也避免同步查询把服务打挂。

7. 落地复盘：哪些设计值得保留，哪些环节走了弯路

7.1 值得保留的三个决定

回看整套系统，我觉得最值得保留的是“分层输出”这个决定。它让每个环节都只处理自己擅长量级的数据：HDFS存原始，Spark算大的聚合，MySQL承载报表，Python做轻量分析和建模。只要某一层的数据量开始飙升，我就知道要去上一层把它压缩掉，而不是让下游偷偷扩容扛住。

第二个值得保留的是“清洗规则版本化”。清洗规则我不仅写进代码，还写进了表格注释和项目文档，每次调整规则都有记录。农产品数据口径太容易变了，一旦业务方对某个指标不认可，可以顺着清洗链路倒查问题出在哪个环节。这比凭记忆解释口径可靠得多。

第三个是“先聚合分析，后可视化”的顺序。很多类似的系统一开始就急着画大屏，结果大屏上的数字经不起推敲。我的做法恰好反过来——先把指标定义清楚、计算逻辑验证通过，再让页面去做呈现。可视化永远是最后一公里，前面任何一步的地基不牢，最终页面都会变成花了屏。

7.2 踩得最深的坑和绕行建议

第一个坑是编码乱码。某次上游换了Excel转CSV的导出工具，输出的文件从UTF-8变成了带BOM的UTF-8，Spark读取时第一列列名多了一个不可见字符，导致所有SQL查出来的字段都是null。排查花了整整一个下午。后来我在读取配置里显式加上处理BOM的选项，并在清洗后的日志里打印表结构和行数，字段问题马上暴露。

第二个坑是凌晨调度失败。上线初期某天凌晨，因为业务系统当天没有准时完成日切，导出的文件根本没生成，定时任务还在傻等，等不到文件就报错；到了白天业务看报表时发现数据缺失，才有人通知我。后来我在调度任务前面加了分区探测，探测失败直接触发告警，绝不让下游产出脏数据。

第三个坑是数据倾斜。聚合任务从30分钟优化到5分钟的过程里，下功夫最多的就是数据倾斜问题。我强烈建议做亿级group by时，先跑一遍按主维度的数据量分布；如果某个key占比超过20%，就要考虑加盐打散或拆成子查询。这个问题不做，后面无论怎么加资源都会很浪费。

7.3 如果我给中小型农产品企业重新做，会怎么简化

最后说点实在的。如果数据量没那么大，比如日订单只有几万笔，历史总量不超过几百万行，那么我不建议照搬Hadoop加Spark这套组合。一个PostgreSQL、一张宽表、pandas加一个轻量可视化框架，完全够用，而且运维负担小得多。分布式架构只有在数据量大到单机内存放不下、或者计算时长超出业务容忍时才有必要引入。

判断标准上面已经说过：单机方案内存占用是否稳定超过可用内存的一半；计算任务是否要跨多小时才能出结果；是否要反复调整口径导致每次全量重算。三个条件只要命中两条，就值得上，否则先别碰。

做完这套系统后，我最大的体会是：“大数据”不一定是数据量大，而是数据规模超过你当前工具的单机承受极限。Hadoop、Spark、Python，本质上不是在炫技，而是把不同量级的计算任务放到合适的位置。数据清洗和口径管理占了整个项目的一大半工作量，反而是Spark和Hadoop的调优，在数据量达到亿级之后才真正体会出价值。如果读者也要上手类似项目，我的建议是从一张最值得关注的表开始，先把口径理顺，再谈计算引擎和可视化，最后再考虑要不要堆更多的组件。这套思路不仅适用于农产品销售，其他行业销售数据的分析链路，大概也是这么长出来的。