去年某段时间我手上接过一套农产品批发市场的销量分析需求。最开始大家想得很简单——把每个市场每天的订单导出来用Python写个脚本pandas处理再画几张图。真等数据铺开之后才发现光三个农批市场群累积半年的历史流水就超过了亿级行单机Python脚本连读都读不进去更不用说跑聚合和出报表。后来我梳理了一整套链路HDFS负责原始数据的存储与归档Spark做大规模的聚合运算Python接住聚合后的结果去做指标提取和可视化呈现——这也就是标题里那套“python hadoop spark”组合的由来。这套系统做下来最大的收获不是某个组件用得多熟而是摸清了“农产品销售数据分析”这一类项目的通用套路数据从哪里来、哪些地方最脏、哪些计算必须在分布式框架里跑、哪些分析交给pandas就够、可视化到底该怎么设计才不变成一块没人看的屏。这篇文章就按这条链路从头到尾讲一遍包括关键代码、参数设置和踩过的坑。1. 从“Excel能算”到“不得不搭平台”农产品销售数据到底难在哪1.1 一张典型的农批市场流水表长什么样做农产品销量分析绕不开的第一件事就是看交易流水。以我接手的那套农批市场销售系统为例每个市场每天都会产生大量电子结算订单来源主要是档口结算终端和部分手工补录偶尔还有产地直发过来的物流单。一张标准的流水表核心字段无非是这几类订单编号、交易日期、市场编号、档口编号、采购商编号、品类、单品名称、规格等级、成交数量、成交单价、成交金额。看起来简单但实际数据比这脏得多。同一个单品在不同市场叫法不一样西红柿有人写“番茄”有人写“西红柿”还有人把“圣女果”也归到这一类数量单位更是混乱有的按公斤有的按斤部分大宗交易直接按吨写单价和金额对不上的情况也时有发生。这些字段在后续清洗环节能造成大量重复劳动所以我在设计一开始就把“双方约定的规范字段”提前定死让上游系统按这个口径导出。除了订单流水分析系统通常还要关联几张维度表市场表市场编号、名称、所在区域、市场类型、商品表品类、单品名、规格等级、默认单位、采购商表采购商编号、类型、归属地。其中采购商表非常有分析价值因为农产品批发市场的交易高度依赖老客复购采购商的数量和结构往往比档口数量更能反映市场活跃度。1.2 为什么单机方案先撑不住最开始我也想过几个市场的数据而已用Python加pandas跑不就行了。真等数据导出来半年历史订单超过一亿行压缩前的CSV就有四十多GBpandas一次性读进来内存直接爆掉。就算勉强读进来了之后每次调整聚合口径都要重跑一次全量一跑就是几个小时报表根本跟不上业务节奏。我办公室同事常说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/dt20250101/用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而不是写MapReduceHadoop生态里最早能算东西的是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和pandasMySQL查询延迟毫秒级连接工具也多。HDFS适合大批量扫描但单条查询其实不合适。两层叠加的坏处是要多写一份数据同步任务但换来的是下游极低的折腾成本。每次指标口径变了最多重跑一个Spark任务再同步一次MySQL几分钟搞定。4.2 Python读取的边界永远别拿pandas去读HDFS原始数据Python在整个链路里是“轻量分析”的定位不是“大计算”的定位。我个人给项目定了一条红线pandas只允许读取MySQL里的汇总层和应用层数据原始流水和明细层一律不直接碰。如果哪一天分析需求特别复杂例如要算所有单品在每一天的最终成交价波动我会回到Spark先算好一张中间表再同步到MySQL让Python读。这么做的好处是pandas内存占用永远可控报表接口也稳定。很多项目的失败不是分析逻辑不会写而是某一层越权去处理了自己不该处理的量级最后把内存跑爆整个服务跟着宕掉。4.3 指标口径对齐是怎么落地的农产品销售行业经常遇到“这个月销量为什么和业务系统对不上”的质疑。核心原因通常是口径不一致财务按开票金额算市场按结算流水算如果系统里有退货单、冲单两边自然对不上。我在建表时把所有指标的算法写进了表注释并且在可视化页面每个数字附近加了一个小问号说明口径。比如“销售量”明确为“成交订单中实际交割数量之和单位公斤”“销售额”明确为“同口径下成交金额之和单位元”。上述口径都来自清洗后的联分明细不做任何二次估算。一开始业务方觉得多此一举等出现几次对账分歧后这套注释成了双方沟通的依据。这里把几个核心指标的口径列在下面方便大家在实战中直接复制指标口径说明单位统计粒度成交量清洗后有效订单的实际交割数量之和kg日/市场/品类/单品销售额同口径订单的成交金额之和元日/市场/品类/单品加权均价销售额 / 成交量元/kg日/市场/品类/单品成交笔数清洗后有效订单数量之和笔日/市场/品类/单品采购商数去重后的采购商编号数量家日/市场/品类/单品5. Python接手品类画像、价格弹性和销量预判5.1 分析核心不再是“处理数据”而是“解释数据”到了Python这一层数据已经从亿级压到了百万级甚至万级。我们要做的就不是再写Spark任务而是从业务视角找出问题和规律。我用pandas按月份、品类、单品做透视看每个品类的季节波动。以某市场西红柿为例月度销售指数在7到8月明显高于全年均值12月到次年2月则跌到全年六成左右。这背后其实是产季逻辑夏季本地大棚和露地菜集中上市量大价格低冬季主要靠长途运输量小价高。农民和采购商对这个规律其实心知肚明但系统把指数量化之后大伙看报表就能直接安排采购节奏。季节指数的计算也不复杂就是每个月的平均日销量除以全年的平均日销量再乘以100import pandas as pd sales pd.read_sql( SELECT dt, total_qty FROM ads_agri_daily WHERE market_idM001 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_idM001 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_periods7, trendadd, seasonaladd ).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(host127.0.0.1, port6379, db1) def get_market_daily(date): key fkpi: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_asciiFalse)) 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-8Spark读取时第一列列名多了一个不可见字符导致所有SQL查出来的字段都是null。排查花了整整一个下午。后来我在读取配置里显式加上处理BOM的选项并在清洗后的日志里打印表结构和行数字段问题马上暴露。第二个坑是凌晨调度失败。上线初期某天凌晨因为业务系统当天没有准时完成日切导出的文件根本没生成定时任务还在傻等等不到文件就报错到了白天业务看报表时发现数据缺失才有人通知我。后来我在调度任务前面加了分区探测探测失败直接触发告警绝不让下游产出脏数据。第三个坑是数据倾斜。聚合任务从30分钟优化到5分钟的过程里下功夫最多的就是数据倾斜问题。我强烈建议做亿级group by时先跑一遍按主维度的数据量分布如果某个key占比超过20%就要考虑加盐打散或拆成子查询。这个问题不做后面无论怎么加资源都会很浪费。7.3 如果我给中小型农产品企业重新做会怎么简化最后说点实在的。如果数据量没那么大比如日订单只有几万笔历史总量不超过几百万行那么我不建议照搬Hadoop加Spark这套组合。一个PostgreSQL、一张宽表、pandas加一个轻量可视化框架完全够用而且运维负担小得多。分布式架构只有在数据量大到单机内存放不下、或者计算时长超出业务容忍时才有必要引入。判断标准上面已经说过单机方案内存占用是否稳定超过可用内存的一半计算任务是否要跨多小时才能出结果是否要反复调整口径导致每次全量重算。三个条件只要命中两条就值得上否则先别碰。做完这套系统后我最大的体会是“大数据”不一定是数据量大而是数据规模超过你当前工具的单机承受极限。Hadoop、Spark、Python本质上不是在炫技而是把不同量级的计算任务放到合适的位置。数据清洗和口径管理占了整个项目的一大半工作量反而是Spark和Hadoop的调优在数据量达到亿级之后才真正体会出价值。如果读者也要上手类似项目我的建议是从一张最值得关注的表开始先把口径理顺再谈计算引擎和可视化最后再考虑要不要堆更多的组件。这套思路不仅适用于农产品销售其他行业销售数据的分析链路大概也是这么长出来的。