基于大数据的房产中介服务管理系统设计与实现

1. 项目概述与整体设计思路选择“基于大数据的房产中介服务管理系统设计与实现”这个题目不是拍脑袋定的。我在决定做这个项目之前认真盘过一遍大数据方向的毕设或者项目实战最常见的坑是“为了大数据而大数据”——用Hadoop算了个词频统计用Spark做了个离线报表然后包装成“XXX系统设计与实现”一答辩就被问住。房产中介这个场景不一样它是天然的数据密集型业务房源信息、客源需求、带看记录、成交数据、经纪人业绩、区域房价走势每一类数据都有明确的业务含义和计算价值而且业务链路完整从数据采集、清洗、存储、分析到可视化展示每一个技术环节都能落到真实场景里。再说说这套系统到底解决什么问题。传统的中介门店管理房源登记靠Excel客源维护靠通讯录带看记录靠手写成交数据散落在不同人手里。管理者想回答“这个月哪个区域的带看转化率最高”“最近三周哪个板块的挂牌价明显波动”“成交周期超过60天的房源有什么共性”基本只能靠经验拍脑袋。我的目标很明确把业务数据统一收口用一套大数据平台完成离线分析再用一个可视化管理端把结果呈现给门店运营人员让管理决策有数可依同时把经纪人的日常工作流房源录入、客源跟进、带看安排、成交审核固化到系统里。这套设计既不是纯数据平台也不是普通CRUD系统而是“业务管理系统 数据仓库 可视化分析”三合一这也正是这类题目的核心价值所在。适合谁来参考这份思路如果你正打算做大数据方向的毕业设计或者准备面试时需要讲一个有说服力的项目又或者在小团队里想搭一套轻量级的房源数据分析系统但不知道从哪下手这篇文章都会对你有用。下面所有内容都以可复现为原则每一步给到的配置、代码、参数都是我在实际搭建过程中验证过的你拿回去改改路径和IP就能用。2. 技术选型与架构拆解2.1 大数据组件选型为什么是Apache全家桶技术选型这块我先踩过一轮坑最后老老实实回到了Apache开源生态HDFS做分布式存储YARN做资源调度Hive做数据仓库Spark做离线计算Flume做日志采集MySQL存业务关系数据Flask提供接口服务ECharts做前端可视化。这套组合是当前大数据离线分析方向最经典、也是网上资料最全的配置对毕设和项目实战来说稳定性高于一切出了问题能搜到答案比什么都重要。为什么不直接用CDH或者HDP这两个发行版确实省事但对企业用户收费而且版本老、社区活跃度在下降。为什么不直接用云上的大数据服务比如各类EMR托管集群如果你只是为了交作业那开一台云主机装个单机Hadoop其实更省心但如果想把集群部署、组件调优这些环节也作为项目的展示点我建议还是在本地虚拟机或者物理机上从零搭一套因为你面试被问“你们集群怎么部署的、参数怎么调的”时亲手装过和看文档装过答出来的深度完全不一样。组件版本的选择也有讲究。我的建议是不要追新用经过大量生产验证的稳定版本组合。我自己用的是Hadoop 3.3.4、Hive 3.1.3、Spark 3.4.1、Flume 1.11.0、Zookeeper 3.7.1JDK 1.8。这里提醒一句Hive 3.x和Spark 3.x整合时需要把Spark的hive-exec相关依赖处理干净否则跑INSERT OVERWRITE的时候会被各种类冲突折磨这个坑后面单讲。2.2 系统整体架构五层设计整个系统按职责划分为五层数据从下往上单向流动每一层只干一件事。采集层负责把业务日志、数据库变更、外部房源数据收进来存储层用HDFS兜底原始文件和Hive数仓表用MySQL存储实时性要求高的业务数据计算层跑Spark离线任务完成ETL和指标计算服务层由Flask提供REST接口供前端和管理后台调用应用层是面向门店管理员和经纪人的可视化看板与业务操作界面。我画架构图的时候习惯用一句话概括数据流向业务操作写入MySQL日志同步到FlumeFlume落盘HDFSHive做清洗分层Spark算指标结果写回MySQL的统计表Flask读MySQL出接口ECharts渲染成看板。这个链路每一步都有明确的输入输出答辩或者面试被问“数据怎么流转的”照这个顺序讲逻辑非常清晰。功能模块上系统拆成六个子模块房源管理小区、户型、面积、朝向、挂牌价、状态流转、客源管理购房预算、意向区域、联系方式、需求等级、带看管理带看时间、经纪人、房源、结果反馈、成交管理成交价、佣金、合同信息、报表中心区域供需、价格走势、转化漏斗、经纪人排行、系统管理账号、角色、权限、操作日志。前端页面和API接口全部围绕这六个模块展开没有冗余功能也不会出现“为了凑功能硬加页面”的情况。2.3 数据库设计思路业务库和统计库分开数据库这块我踩了一个印象很深的坑一开始图省事把所有表都放在MySQL里结果Spark算完指标后直接往业务表里写导致业务查询越来越慢房源列表页打开要好几秒。后来把库拆成两个house_biz存业务表负责支撑日常操作house_stats存统计结果表负责支撑报表展示。两个库物理隔离互不影响业务库用小字段索引优化统计库用宽表冗余加工效果立竿见影。业务库的核心表有这些house_info房源主表、customer_info客源主表、visit_record带看记录、deal_record成交记录、employee_info经纪人、dict_area区域字典。其中house_info和customer_info是一对多关系visit_record是中间关联表一条房源可以被多个客户看一个客户也可以看多个房源。状态字段我用的是TINYINT枚举值比如房源状态0待审核、1在售、2已预定、3已成交、4下架这样查询走索引时比字符串快得多而且代码里用常量类统一管理不会出现“魔法值散落各处”的情况。统计库的表反规范化设计直接用指标明确定义表结构比如stat_region_daily区域每日供需与价格统计、stat_employee_monthly经纪人月度业绩、stat_deal_funnel转化漏斗各环节数量。Spark计算时先查出结果再按照“先删后插”的策略写入避免增量更新带来的数据不一致问题。3. 数据收集与预处理实战3.1 造数据与Flume日志采集项目里最现实的问题是我没有真实中介门店的数据。学校不可能给你脱敏数据网上也没有现成的大规模房产交易数据集所以只能自己造。我的做法是写一个Java数据生成器按照业务规则随机生成近一年的模拟数据房源5万条、客源3万条、带看记录20万条、成交记录8000条涉及12个行政区、300多个小区房价按照真实分布核心区高、远郊低加随机噪声生成。数据生成器同时输出两类内容一类直接写入MySQL业务库模拟在线业务另一类以JSON格式滚动写入日志文件模拟业务系统的行为日志供Flume采集。为什么这么设计因为这样才能把数据采集链路跑通你总不能答辩时说“我的数据是写SQL插进去的”那大数据平台部分就立不住了。Flume的配置我贴一下核心片段用的是spooldir源加HDFS sink监控日志目录发现新JSON文件就抓取并下沉到HDFS的ODS层目录。需要注意hdfs.path里的%Y%m%d会用当天日期动态创建目录实现按天分区。# flume-hdfs.conf a1.sources r1 a1.sinks k1 a1.channels c1 a1.sources.r1.type spooldir a1.sources.r1.spoolDir /opt/data/logs a1.sources.r1.fileHeader true a1.sources.r1.channels c1 a1.sinks.k1.type hdfs a1.sinks.k1.hdfs.path /warehouse/ods/house_log/%Y%m%d a1.sinks.k1.hdfs.filePrefix log_ a1.sinks.k1.hdfs.fileType DataStream a1.sinks.k1.hdfs.writeFormat Text a1.sinks.k1.hdfs.rollInterval 3600 a1.sinks.k1.hdfs.rollSize 134217728 a1.sinks.k1.hdfs.rollCount 0 a1.sinks.k1.channels c1 a1.channels.c1.type memory a1.channels.c1.capacity 10000 a1.channels.c1.transactionCapacity 1000启动命令没什么好说的flume-ng agent -n a1 -f flume-hdfs.conf但要注意给agent足够的内存默认堆太小跑一会儿就会OOM。我一般设置JAVA_OPTS-Xms512m -Xmx1024m日志量大的时候调到2G以上。还有一个细节spooldir源扫描完文件会重命名加后缀不会重复采集但目录里千万不要放正在写入的文件否则会报“file not readable”的错日志先写好再扔进监视目录是最稳的。3.2 数仓分层与Hive建表数仓这一层很多人直接跳过觉得“不就是建几张表”。但面试官真正想听的恰恰是这里。我的项目用标准四层模型ODS层存原始日志DWD层做清洗去重后的明细数据DWS层按业务主题汇总ADS层面向应用输出指标结果。ODS层就是Flume导进来的原始JSON日志加上MySQL业务表快照分区按天表结构保持原样此层不做事后修改。DWD层是重点把订单、房源、带看等事实表做清洗核心操作包括去掉字段缺失的记录、修正价格小于0的脏数据、统一日期格式、解析JSON嵌套字段、用字典表替换区域编码。DWS层以“房源-客源-带看-成交”为主线按区域、时间、经纪人三个维度预先聚合。ADS层直接产出看板所需的指标宽表。Hive建表我贴一个DWD层房源表的例子存储格式用了ORC加Snappy压缩分区字段是dt。这样做的理由很实在ORC列式存储在跑聚合时只扫描需要的列Snappy压缩比高且解压快按天分区让数据裁剪更精确三层叠加查询效率比TextFile高好几个量级。CREATE EXTERNAL TABLE dwd_house_info ( house_id STRING COMMENT 房源编号, community_id STRING COMMENT 小区编号, district_id STRING COMMENT 区域编号, house_type STRING COMMENT 户型如3室2厅, area DOUBLE COMMENT 建筑面积(平米), orientation STRING COMMENT 朝向, listing_price DOUBLE COMMENT 挂牌价(万元), decoration_status STRING COMMENT 装修情况, house_status INT COMMENT 状态 0待审 1在售 2预定 3成交 4下架, listing_date STRING COMMENT 挂牌日期, listing_agent STRING COMMENT 维护经纪人ID ) COMMENT 房源明细清洗表 PARTITIONED BY (dt STRING COMMENT 数据日期) STORED AS ORC LOCATION /warehouse/dwd/dwd_house_info TBLPROPERTIES (orc.compressSnappy);这里要提醒一个实操细节用CREATE EXTERNAL TABLE而不是内部表。内部表删表时数据文件会被一起删掉外部表删表只删元数据HDFS上的文件还在。做数据重跑、备份恢复的时候外部表安全得多这也是生产环境的标准做法。3.3 Spark数据清洗遇到的三个典型问题数据清洗阶段我用Spark SQL跑离线ETL每天凌晨定时执行把前一天ODS层数据洗干净写入DWD和DWS。实际操作中遇到三个问题频率高、都很典型。第一个是中文乱码。Hive表字段注释里的中文、数据文件里的中文在Spark SQL跑完后显示问号原因是Spark和Hive连接时的字符集设置不一致。解决办法是在spark-defaults.conf里强制指定spark.sql.session.timeZone和文件编码另外建表语句统一加COMMENT并确保hive-site.xml设置了utf-8。我检查发现根源是HDFS文件用UTF-8写入、但Spark读入时默认按系统编码解析加了--conf spark.driver.extraJavaOptions-Dfile.encodingUTF-8和同样的executor参数后彻底解决。第二个是状态字段没对齐。业务库MySQL里房源状态存在house_info表但日志产生的JSON文件里状态码有中文和英文混杂比如“已在售”“Sold”DWD清洗时需要先用UDF统一成数字枚举。清洗规则写清楚后这类问题就变成单纯的代码逻辑不涉及架构调整。第三个是数据倾斜。按区域聚合带看量的时候核心城区一个区的数据占了40%导致某个reduce任务跑了半小时其他任务早结束了。处理方案是两阶段聚合先给区域字段加随机前缀打散局部聚合一次再去掉前缀做全局聚合。加了这步之后整个Spark作业的耗时从40分钟降到11分钟效果立竿见影。4. 后端服务与核心业务实现4.1 Flask服务架构与接口设计服务端我用Flask而不是SpringBoot原因很实际项目技术栈已经够重了再引入Spring全家桶和Java后端会让部署工作量翻倍。Flask轻量、和Python数据分析生态无缝衔接、写接口效率高对这类以数据展示为核心的中后台场景完全够用。为了生产可用性我做了三层封装路由层只负责接收请求和参数校验服务层写业务逻辑DAO层封装SQL操作。后来证明这个分层很有用因为统计接口的SQL多且复杂集中写在DAO层方便优化。from flask import Blueprint, jsonify, request from dao.stats_dao import StatsDao stats_bp Blueprint(stats, __name__) dao StatsDao() stats_bp.route(/api/stats/region/daily, methods[GET]) def region_daily(): 区域每日供需与价格统计接口 start_date request.args.get(start_date, ) end_date request.args.get(end_date, ) district request.args.get(district, ) data dao.query_region_daily(start_date, end_date, district) return jsonify({code: 0, data: data})接口设计上我坚持一个原则前端能一次拿到的数据就不要拆成多次请求。比如看板首页的“区域供需总览”直接后端拼好按区域分组的数据返回前端拿数组渲染不要前端再调多个接口做聚合。还有一个容易被忽略的坑所有统计接口必须支持时间范围和区域筛选报表页面的筛选器都得走后端重查不能前端filter数据因为数据集很大前端Javascript处理性能会很差、容易卡死浏览器。4.2 核心业务流程房源、客源与成交闭环业务部分我重点说三个关键流程这也是答辩时最容易被追问的环节。第一是房源发布流程经纪人录入房源信息系统自动调用字典校验小区是否存在、地址格式是否合法、挂牌价是否在合理区间同小区近三个月均价的0.7到1.5倍校验通过进入待审核状态门店经理审核后转在售。第二是客源需求登记客户提出需求后系统按“区域户型预算特征标签”四要素进行匹配给经纪人推送符合条件的在售房源Top10同时记录推荐行为用于后续评估推荐算法的准确性。第三是带看-成交闭环经纪人创建带看计划到店扫码确认带看完成客户反馈结果有意向、再考虑、放弃有意向则推进价格谈判成交后录入实际成交价与佣金比例同时将房源状态自动置为已成交。以下几个参数的设定值得留意。带看转化率 成交客户数 ÷ 带看客户数我系统里统计出来的行业常识区间是5%到15%成交周期 成交日期 - 挂牌日期单位按天计算用来评估房源定价合理性超过90天就需要预警佣金计算 成交价 × 佣金费率费率按城市等级和房屋类型分档核心城区2%、郊区1.5%、商业地产3%系统里用配置表管理支持随时调整。这三个流程我都是用状态机来管理流转的。比如房源状态一个状态只能经过合法的动作跳到另一个状态待审核只能被“审核通过”或“审核驳回”在售只能被“预定”或“下架”预定只能被“成交”或“取消预定”。我用一张状态流转表加代码里的合法性校验来保证状态不会跳错这比在每个接口里写繁琐判断要清晰得多后续加新功能也不用到处改判断逻辑。4.3 RBAC权限设计与安全细节权限模型采用RBAC基于角色的访问控制做了三层角色管理管理员、店长、经纪人、权限点管理房源咨询、客户查看、成交修改、报表访问等20多个权限点、角色-权限关联表。用户登录后后端根据角色返回对应的权限点编号集合前端用它来控制菜单显示后端在每个接口的装饰器上做权限校验双保险。关于权限校验我贴一个核心代码片段。这里要说的重点是接口鉴权必须放在服务端前端隐藏按钮只是体验层面的处理不能作为安全保障。我之前测试时就发现如果后端不校验直接手工构造请求就能越权查看其他门店的数据这在实际生产环境是非常严重的安全漏洞。from functools import wraps from flask import request, jsonify def require_perm(perm_code): def decorator(view_func): wraps(view_func) def wrapper(*args, **kwargs): user get_current_user() if not user: return jsonify({code: 401, msg: 未登录}) if perm_code not in user.perm_codes: return jsonify({code: 403, msg: 无权限访问}) return view_func(*args, **kwargs) return wrapper return decoratorJWT令牌我这里也提一笔登录成功后签发JWTtoken有效期设2小时Redis里维护一个黑名单用来实现“修改密码后强制退出”和“管理员踢人”。很多人图省事不做黑名单导致用户改密码后旧token还能用这是个隐藏的安全风险项目里最好处理掉。5. 数据可视化与前后端集成5.1 ECharts看板设计一张图说清数据价值可视化是整个项目最出彩的部分也是“看起来最像系统”的部分。我做了四个核心看板页面数据总览、区域分析、经纪人绩效、趋势监控。总览页用卡片放关键指标在售房源、累计客户、本月成交、成交总价、佣金收入下方是近30天成交趋势折线图和区域成交量排行柱状图。区域分析页核心是行政区地图热力图鼠标移到某个区显示在售房源数、均价、供需比和成交周期。经纪人绩效页用表格加柱状图展示个人带看量、成交量、佣金排名。趋势监控页关注挂牌均价和成交均价的走势关系用来判断市场冷暖。前端代码以ECharts为核心配合Vue.js和Element UI组件库。有个经验ECharts的option设置项非常多不建议全部手写直接用官方示例改是最快的但是代码里要把配置和数据源分离数据通过axios请求接口动态获取不要写死。axios.get(/api/stats/region/daily, { params: { start_date: 2024-06-01, end_date: 2024-06-30 } }).then(res { const data res.data.data; const chart echarts.init(document.getElementById(regionChart)); chart.setOption({ tooltip: { trigger: item }, visualMap: { min: 0, max: Math.max(...data.map(d d.count)), text: [高, 低], inRange: { color: [#e0e0e0, #ff6b6b] } }, series: [{ type: map, map: district, data: data.map(d ({ name: d.district_name, value: d.avg_price })) }] }); });5.2 指标口径统一数据准确性怎么保证这块我要特别强调一下。可视化的前提是指标口径统一否则不同页面同一个指标数字对不上整套系统在业务人员眼里就失去信任了。我在项目里做了三件事来保证指标一致性第一所有指标在数据字典里定义清楚包括计算公式、单位、涉及的表和字段第二Spark计算层的SQL统一从DWS层取值不允许多个业务方各写一套统计逻辑第三统计表里的指标与前端展示字段一一对应前端只展示统计表已经算好的数据不自行计算这样即使某个指标有误差也能在数据层面快速定位到是哪一步算错了。我再列一下系统里几个核心指标的计算逻辑供你设计时参考区域供需比 某区域在售房源数 ÷ 该区域近90天累计求购客户数比值越高说明客户竞争越小越低说明房源越稀缺。带看转化率 某时间段内成交客户数 ÷ 同时段内产生带看记录的客户数用于评估整体业务效率。挂牌价指数 当日挂牌房源挂牌价中位数 ÷ 基准日挂牌价中位数 × 100比平均价更抗异常值干扰。成交周期 成交日期 - 挂牌日期平均成交周期按月统计和带看频次结合可以判断议价空间。5.3 部署方案与集群参数配置部署这块很多人栽跟头。我的集群规划是三台CentOS 7虚拟机节点名和分工如下master节点跑NameNode、ResourceManager、HiveServer2、Spark on YARN的Driver侧、MySQL和Flask服务worker1跑DataNode、NodeManager、Zookeeper和Flumeworker2跑DataNode、NodeManager、Hive Metastore和Zookeeper。三节点是成本和功能平衡下来最舒服的配置——单节点耍不开分布式五节点对虚拟机资源要求又太高。部署顺序我建议严格按照先Zookeeper再Hadoop的HDFS再YARN再Hive再Spark最后才是Flume和业务服务。每一步启动后都要用命令确认状态正常再走下一步比如HDFS启动后用hdfs dfsadmin -report看DataNode是否全部在线YARN用yarn node -list确认NodeManager注册成功。Hive启动时用schematool -initSchema -dbType mysql初始化元数据库这一步漏了后面查任何表都会报错我第一次搭的时候在这里卡了整整一下午。内存参数是新手最容易忽视的。虚拟机建议每台至少给8G内存。YARN的ResourceManager需要统筹整个集群资源默认配置经常不够用我把关键三个参数设为yarn.scheduler.maximum-allocation-mb为7168MB、yarn.scheduler.minimum-allocation-mb为1024MB、yarn.nodemanager.resource.memory-mb为7168MB。Spark on YARN模式下每个executor内存建议2到3G太多会拖垮NodeManager太少任务频繁GC我最终定在2G加两个executor跑百万级房源数据稳定在十几分钟。6. 常见问题与排查技巧实录6.1 集群与组件层面以下问题都是我在开发过程中真实遇到的不是网上拼凑的按出现频率排序放在表格里方便你快速对照排查问题现象可能原因排查方法解决办法HDFS DataNode启动失败集群ID不一致查看datanode日志报错信息删除各节点current/VERSION目录后重新格式化NameNodeSpark提交任务后一直ACCEPTED不执行YARN资源不足执行yarn application -list查看申请资源调大yarn.nodemanager.resource.memory-mbHive查询全表扫描很慢表没分区或没启用分区裁剪EXPLAIN看执行计划建表时设置分区查询条件加分区字段Flume采集数据有丢失channel容量太小或并发写入检查Flume日志中的EventTakeFromChannel指标调大channel容量改用file channel持久化Spark作业报OOMexecutor内存不足或数据倾斜查看Spark UI的Stage执行时间分布增加executor内存先解决数据倾斜MySQL连接数爆了统计接口SQL慢导致连接堆积SHOW PROCESSLIST看慢查询给查询字段加索引统计结果走DWS宽表集群ID不一致这个问题我专门说一下。我在搭集群第二天就遇到DataNode起不来日志显示Incompatible clusterIDs。原因是格式化NameNode后DataNode的数据目录里还残留着第一次初始化时的集群ID。解决办法是把dfs.namenode.name.dir和dfs.datanode.data.dir指向的目录全部清空后重新格式化或者在数据目录里直接把current/VERSION文件删除再重启DataNode。生产环境不能随便重新格式化所以初始化配置时最好一次做对避免反复横跳。6.2 业务与数据质量层面业务层面的坑更多是“当时没发现事后看数据对不上”。比如统计“经纪人本月新增房源数”时我一开始直接用house_info表按listing_agent分组count后来发现审核驳回的房源也被算进去了导致数据虚高。后来统一口径为“已审核通过的房源”在SQL里加上状态过滤条件再重跑。这类口径问题一定要在指标字典里写清楚并且DS层查询时加注释说明否则三个月后你自己都忘了当初为什么这么算。另一个经典坑是时区问题。Spark跑批时用UTC时间写入Hive分区而业务系统时间是UTC8导致统计结果晚8个小时前端看着“今天的量怎么这么少”。排查半天才发现是Java进程的时区没设置在启动参数里加了-Duser.timezoneGMT8就正常了。类似这种环境时区、编码、语言设置建议在所有组件的启动脚本里统一固定住不要依赖操作系统默认值。6.3 前后端联调与性能优化联调阶段我遇到最多的是跨域问题。Flask服务跑在8080端口前端页面跑在Vite的5173端口浏览器直接请求会被CORS拦截。开发环境我用了Flask-CORS扩展生产环境用Nginx做反向代理让前端静态页面和后端接口同源一步到位解决跨域。另外前端接口请求务必加超时设置timeout: 15000因为大数据量的聚合接口首次查询可能需要几秒如果用户网络不好会一直转圈看起来像系统挂了。性能优化方面我最重要的经验是把“热点数据”缓存到Redis。看板首页的“区域分布”“近30天趋势”这类接口Spark已经算好结果写在统计表里MySQL查询本身只要几十毫秒但并发一高还是会扛不住。我给统计接口加了一层Redis缓存查询参数相同且数据日期未变化时直接命中缓存生效后首页接口的P99延迟从260毫秒降到20毫秒左右体验提升非常明显。缓存失效策略用“业务时间”驱动每天凌晨Spark跑批完成后主动删除当日相关的缓存Key下次请求时自然回源查询。7. 项目复盘与经验总结整个项目从设计到落地用了大约三周我最有感触的一点是大数据项目最耗时间的不是写代码而是处理环境问题和数据质量问题。Flume配置调通用了一天Spark与Hive的兼容性折腾了整整一个晚上最后发现是spark.sql.catalogImplementation需要显式设置为hive而数据清洗规则的设计和验证又挤占了两天时间。所以我建议你规划时间时把环境部署和联调测试的占比放大到40%以上否则最后几天会非常紧张。技术层面这套架构让我个人在大数据领域建立了完整的知识体系。跑通全链路之后你对HDFS的数据分布机制、YARN的资源调度流程、Spark的执行计划优化、Hive的元数据管理都会有真实的体感这种体感不是看文档能获得的。你还能清楚理解为什么数据仓库要分层、为什么离线计算不能扛实时查询、为什么说数据治理的核心不在技术而在口径规范。这些认知在面试中非常加分因为大多数候选人只停留在“会用工具”的层面。最后分享一个实际经验项目代码提交到Git仓库时一定要把log、data、target、__pycache__这类目录加到.gitignore特别是Flume采集用的日志目录里面有大量测试时的脏数据如果被提交上去仓库体积会迅速膨胀后续拉代码的同事会非常痛苦。我吃过这个亏仓库从几十兆变成几个G最后只能重写Git历史来清理非常费劲。这个项目后续还可以继续扩展的方向也很多引入实时计算引擎处理经纪人行为日志流做实时带看提醒用协同过滤算法做房源个性化推荐把移动端小程序接上现有API经纪人可以在手机上录房源、报带看。我已经在规划把房源推荐的Spark任务改成周级增量计算配合Redis缓存实现“登陆即推荐”有兴趣的读者可以从这套架构里继续延伸。