简介面向计算机相关专业毕业设计、课程作业及大数据实战项目练习者的金融信贷风控系统源码。项目基于Hadoop与Spark构建涵盖数据采集、流处理、风险控制等模块以金融信贷业务为场景帮助学习者理解大规模数据处理与风控模型落地的完整流程。资源包共68个文件以Java、Scala源码为主辅以XML配置、SQL脚本及Properties配置文件涵盖核心逻辑、MyBatis映射与系统运行参数压缩包仅90KB结构精简便于本地编译调试。当前已有279人学习使用项目经导师指导并获98分评审代码均本地编译验证适合作为高分毕业设计参考或企业级风控原型学习的入门素材。内容包含项目工程文件、依赖配置、数据库脚本及关键接口实现便于研究者快速还原项目结构并在此基础上扩展功能或撰写设计文档。1. 这个题目到底在做什么一套不靠玄学的信贷风控系统毕业设计选“基于HadoopSpark的大数据金融信贷风险控系统”本质上是把三件事焊在一起用Hadoop承接海量原始信贷数据的存储与清洗用Spark做高维特征计算和模型推理再叠一层可解释的规则引擎输出“通过/拒绝/人工复核”的决策。它解决的问题不是“预测谁一定违约”而是在千万级流水、多头借贷、异常操作等数据下给信贷审核一个能解释、能回溯、能调参的风险评分。适合手里已有Java/Scala基础、想往大数据方向靠的本科生或研究生也适合想快速搭一套可演示的离线风控Demo的入门工程师。这个题目的价值在于它不像纯算法题那样只交一个模型文件也不像纯工程项目那样只写CRUD——它天然覆盖HDFS、YARN、Spark RDD/DataFrame、特征工程、逻辑回归与规则引擎答辩时每个环节都能展开讲而且都有据可查。衡量它是否值得做的标准也很简单你的Hadoop集群能不能稳定跑完一次全量ETLSpark任务在千万级数据上有没有明显的内存压力以及最后的风控规则是否能让老师一眼看出“这是业务逻辑不是玩具”。2. 先立框架HadoopSpark信贷风控系统的架构与数据流设计2.1 为什么是HadoopSpark而不是一台机器跑MySQL很多人在做毕设时会纠结数据量不过几十万条为什么非要上Hadoop和Spark这个质疑在答辩时几乎一定会被问到所以你得先想明白架构选型的逻辑而不是简单回答“题目要求的”。真实的信贷业务里原始数据来自多个渠道——用户申请表、征信报文、交易流水、催收记录、第三方黑名单格式有结构化表、JSON日志、CSV导出甚至有不规则的文本备注。把这些数据统一进HDFS是为了让后续计算不依赖单一数据库的连接数限制也为了让清洗逻辑可以重复作用于全量数据。Spark的定位是“计算引擎”它替代的是传统MapReduce的繁琐开发。在信贷风控场景里特征加工往往需要多表Join、时间窗口聚合、行为序列排序这些用MapReduce写会非常痛苦而Spark的DataFrame API和SQL天然适合这类清洗逻辑。你不需要在答辩时装作处理过PB级数据但要能说清楚如果未来数据量增长到日增千万条这个架构的扩展点在哪里——是给HDFS加DataNode还是给Spark调executor内存还是把计算从离线批处理迁移到Spark Structured Streaming。能讲出这一层架构题就稳了。2.2 核心模块拆解数据接入、特征加工、模型推理、规则决策一套完整的信贷风控系统无论大厂还是毕设拆开看都是四层。第一层是数据接入与会话。常见做法是用Flume或直接写Spark作业读HDFS上的原始文件我一般建议直接用Spark读取减少一个中间组件的部署负担。文件落地格式推荐Parquet列式存储能省一半以上的扫描时间而且天然支持Schema演化。第二层是特征加工。信贷风控里最高频的特征是“多头借贷”——同一手机号、身份证号在短时间内出现在多少笔申请里“关联风险”——紧急联系人的手机号是否命中黑名单“行为稳定性”——近3个月登录次数、借款金额的方差。这些特征都需要按用户维度做GroupBy和窗口聚合产出的是“用户特征宽表”。第三层是模型推理。毕设里最常见的做法是用Spark MLlib训练一个逻辑回归或随机森林得出违约概率也可以简化成规则打分——每个命中项加一定分值超过阈值直接拒绝。两条路线不冲突规则负责硬性拦截如黑名单命中、年龄不符模型负责综合评估。第四层是决策输出。这里要落一个MySQL库或HBase表记录每个申请单的评分、命中规则、决策结果和拒绝原因码。答辩时老师一定会点开这张表看“这条记录为什么被拒”你必须在代码里预留reason字段而不是只输出一个pass/reject。2.3 离线批处理与准实时计算的分工标题里没有提实时但“风险控系统”四个字在实际业务里躲不开时效问题——用户点击“借款”按钮后风控结果不可能等一个小时的批处理任务跑完。所以毕设的系统建议做双轨离线批处理负责全量模型训练和T1的存量用户重评准实时通道用Spark Streaming或Structured Streaming读取Kafka里的申请事件只对当天的新申请做规则判断和模型预测。这里要克制不要一开始就上Structured Streaming加Kafka先把离线链路跑通再考虑加实时模块。很多毕设翻车在实时部分——因为Kafka和Streaming的版本兼容问题比Hadoop集群本身还难排查。我见过一个学生花了两周调Spark和Kafka的依赖冲突最后发现是Kafka客户端版本和Spark内置版本不一致。所以第一版架构建议控制在“HDFS Spark SQL离线处理 MySQL结果导出”实时部分作为加分项写在设计和论文里代码实现了更好没实现也要能讲清楚设计思路。3. 把环境从零跑起来Hadoop伪分布式与Spark本地模式的最小可复现方案3.1 伪分布式还是集群毕设阶段如何选毕设阶段的集群规模先别急着搭三台虚拟机。个人经验是所有代码在本地跑通再上集群验证一次即可。因为Spark是内存计算框架很多问题在本地IDE里就能暴露等你把逻辑都调对了再放到集群上不会有什么意外。Hadoop选择伪分布式模式也就是在一台机器上同时运行NameNode、DataNode、ResourceManager和NodeManager。伪分布式的意义不是模拟真实集群而是让你完整走一遍“上传文件到HDFS、写MapReduce/Spark作业读取、查看YARN日志”的链路。具体步骤# 1. 下载并解压Hadoop 3.3.x到/opt/hadoop tar -zxvf hadoop-3.3.6.tar.gz -C /opt/ mv /opt/hadoop-3.3.6 /opt/hadoop # 2. 配置SSH免密登录伪分布式需要ssh localhost ssh-keygen -t rsa -P -f ~/.ssh/id_rsa cat ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys # 3. 配置core-site.xml configuration property namefs.defaultFS/name valuehdfs://localhost:9000/value /property /configuration # 4. 配置hdfs-site.xml指定副本数为1 configuration property namedfs.replication/name value1/value /property property namedfs.namenode.name.dir/name value/opt/hadoop/data/namenode/value /property property namedfs.datanode.data.dir/name value/opt/hadoop/data/datanode/value /property /configuration # 5. 格式化NameNode后再启动 hdfs namenode -format start-dfs.sh这里几个参数最容易踩坑。fs.defaultFS决定了HDFS的访问入口如果你后面要用Spark读写HDFS这个地址必须和Spark配置文件里的master一致。dfs.replication在伪分布式下必须设为1否则3个副本会因为没有额外DataNode而一直处于UNDER_REPLICATED状态Health页面会一片红。dfs.namenode.name.dir不要放在/tmp下系统重启会清空你的NameNode元数据就没了只能重新格式化——这是最典型的“没跑几天集群就坏了”的原因。Spark本地模式更简单直接下载解压就好。要点是确认Spark版本和Hadoop版本的兼容性Spark 3.x默认支持Hadoop 3.x不需要额外编译。验证环境的关键命令如下# 检查HDFS是否健康 hdfs dfsadmin -report # 启动Spark的历史服务器能看到作业的executor和执行日志 $SPARK_HOME/sbin/start-history-server.sh # 用spark-shell跑一个SQL验证Spark能读HDFS $SPARK_HOME/bin/spark-shell --master local[2] \ --conf spark.ui.port40403.2 提交第一个Spark作业从读取CSV到出宽表环境起来后不要急着写风控代码。先用一个最小作业验证链路读HDFS上的CSV文件做一次筛选和聚合写出Parquet文件。这个作业跑通后面的风控逻辑只是它的扩展。import org.apache.spark.sql.SparkSession val spark SparkSession.builder() .appName(CreditRiskETL) .master(local[2]) // 本地两个线程跑集群模式删除此行 .config(spark.sql.shuffle.partitions, 4) .getOrCreate() // 读取HDFS上的原始申请数据 val raw spark.read.option(header, true) .csv(hdfs://localhost:9000/data/loan_apply.csv) // 按身份证号聚合统计近30天申请次数多头借贷特征 raw.createOrReplaceTempView(loan_apply) val feature spark.sql( SELECT id_card, COUNT(*) AS apply_cnt_30d, SUM(CASE WHEN loan_amount 5000 THEN 1 ELSE 0 END) AS big_loan_cnt FROM loan_apply WHERE apply_date date_sub(current_date(), 30) GROUP BY id_card ) // 写出为Parquet按id_card分区便于后续Lookup feature.write.mode(overwrite) .partitionBy(id_card) .parquet(hdfs://localhost:9000/warehouse/user_feature)这段代码在做什么要能三两句话讲清楚createOrReplaceTempView是Spark SQL的临时表方便你用SQL思维写清洗逻辑date_sub(current_date(), 30)做时间窗口过滤这是信贷风控里最常用的“近30天”窗口partitionBy(id_card)是按身份证号做物理分区后续按用户查询时可以只读取对应分区避免全表扫描。几个调参经验spark.sql.shuffle.partitions默认是200小数据量下会产生大量空task调度开销反而拖慢作业。本地跑建议设成48集群跑按数据量的实际大小来算一个partition处理100MB200MB是常见经验值。如果你的数据量大这个参数可以写成spark-submit --conf的形式动态传入而不是硬编码在代码里。3.3 Spark读JSON、连接MySQL的边界条件热词里有人搜“Spark中读取JSON”这在风控里对应的是“用户行为日志”——APP端埋点日志大多是JSON格式里面记录用户每一步操作的时间、页面、停留时长。这个模块也常被老师追问写一下标准做法// JSON文件如果每行一个对象直接用Spark读 val logs spark.read.json(hdfs://localhost:9000/data/user_click_log/) // 展开嵌套字段 logs.selectExpr(user_id, click_time, page_id, stay_seconds) .filter(stay_seconds 3) // 过滤掉误触 .groupBy(user_id) .agg(avg(stay_seconds).as(avg_stay_seconds))注意Spark读JSON默认按“每行一个完整JSON对象”的格式解析如果你拿到的文件是美化过的多行JSON需要先做预处理——每个对象独立一行否则作业会直接报解析错误。处理方式可以是用Linux命令jq -c . file.json file_line.json转换或者在代码里用textFile读入后自己逐行解析。另一个高频场景是结果落MySQL。很多学生第一次写会直接在每个executor里建JDBC连接结果并发一高就报“Too many connections”。正确做法是让每个partition共享一个连接池或者用Spark自带的write.jdbc接口。后者会把每个分区的数据按批写入适合结果集不大的场景df.write.jdbc( urljdbc:mysql://localhost:3306/risk_db, tablerisk_result, modeoverwrite, properties{user: root, password: 123456, driver: com.mysql.cj.jdbc.Driver} )这里MySQL端的max_allowed_packet要调大否则写入大字段时报“Packet too large”。一般调到64M足够毕设用了。另外mode选overwrite还是append取决于你的批处理语义——T1全量重算用overwrite实时增量用append写错了会丢数据或重复写入。4. 写核心计算逻辑信贷特征工程、评分卡与规则引擎的代码实现4.1 特征宽表的构建从原始表到可直接入模的字段集特征宽表是整个风控系统的地基也是代码量最大的部分。它的核心逻辑是把分散在多个表里的用户信息——申请记录、还款行为、操作日志、通讯录信息——按用户维度合并成一张“一行一用户、一列一特征”的表。宽表设计得好后续建模和规则引擎都只是查表。常见做法是写三个Spark DataFrame分别处理不同来源的数据最后用join合并。注意几个细节第一粒度必须统一——所有特征必须聚合到“用户”这一级每次申请记录只是用户的一次行为样本第二时间窗口的特征要分开计算近7天、近30天、近90天因为不同风险特征的周期敏感度完全不同——多头借贷看7天就够收入稳定性要看90天第三缺失值不要直接填0信贷数据里“没有申请记录”和“申请了0次”含义不同建议用-1区分并在特征说明里标注。from pyspark.sql import functions as F # 申请记录表近30天申请次数、最大借款金额、平均借款金额 apply_feat spark.table(loan_apply) \ .filter(F.col(apply_date) F.date_sub(F.current_date(), 30)) \ .groupBy(id_card) \ .agg( F.count(*).alias(apply_cnt_30d), F.max(loan_amount).alias(max_loan_amt), F.avg(loan_amount).alias(avg_loan_amt) ) # 逾期记录表是否存在90天以上逾期、逾期次数 overdue_feat spark.table(overdue_record) \ .groupBy(id_card) \ .agg( F.sum(F.when(F.col(overdue_days) 90, 1).otherwise(0)).alias(overdue_90d_cnt), F.max(overdue_days).alias(max_overdue_days) ) # 合并成宽表左连接保证所有申请用户都在 wide_table apply_feat.join(overdue_feat, id_card, left) \ .fillna({overdue_90d_cnt: 0, max_overdue_days: 0})F.when(...).otherwise(...)是Spark里的条件计数常用写法等价于SQL的CASE WHENfillna只针对逾期特征补0因为“没有逾期记录”才是真实的0含义这和前面申请次数缺失用-1是两套逻辑。宽表建议以Parquet格式写入HDFS并带上partitionBy(dt)按日期分区——这样后续每次重算只覆盖当天的分区不会污染历史数据。4.2 MLlib逻辑回归训练与模型落盘特征宽表生成后训练模型就水到渠成了。Spark MLlib的Pipeline机制非常契合毕设展示——它把“特征标准化、模型训练、模型保存”串成一条流水线复试老师问起“你的模型是怎么训练的”你可以直接打开Pipeline定义讲。from pyspark.ml.feature import VectorAssembler, StandardScaler from pyspark.ml.classification import LogisticRegression from pyspark.ml import Pipeline feature_cols [apply_cnt_30d, max_loan_amt, avg_loan_amt, overdue_90d_cnt, max_overdue_days] # 汇总特征列到向量 assembler VectorAssembler( inputColsfeature_cols, outputColraw_features ) # 标准化消除量纲影响 scaler StandardScaler( inputColraw_features, outputColfeatures, withStdTrue, withMeanTrue ) # 逻辑回归训练二分类违约概率 lr LogisticRegression( featuresColfeatures, labelColis_default, maxIter100, regParam0.01 ) pipeline Pipeline(stages[assembler, scaler, lr]) # train_test_split按用户ID做分层抽样避免同一用户出现在训练和测试集 train_df, test_df wide_table.randomSplit([0.8, 0.2], seed42) model pipeline.fit(train_df) # 保存模型到HDFS便于后续离线推理复用 model.save(hdfs://localhost:9000/models/credit_lr_model)这段代码想拿高分核心在于“为什么选逻辑回归”的答案。逻辑回归在信贷风控里地位非常稳一是可解释性极强——每个特征的系数直接对应“该特征每增加一个单位违约概率的相对变化”监管审计时说不清理由的模型是上不了线的二是在特征标准化后收敛非常快毕设数据集上几十轮迭代就够三是和后面的规则引擎天然互补规则负责硬性拦截逻辑回归负责给“灰名单”用户排序。随机森林可以提一嘴作为对照实验但不要替换掉逻辑回归。randomSplit这里要特别说明不要用简单的随机抽样做训练集测试集划分因为同一个用户可能有多条申请记录随机划分会导致模型“见过这个人”再考这个人指标虚高。正确做法是先按用户去重在用户层面划分再回拼全部记录——我见过不少项目翻车在这一步测试集AUC接近0.9答辩时被追问才发现是数据泄漏。4.3 规则引擎的落地刚性拦截与模型得分融合模型输出的是违约概率但信贷系统不会只靠概率做决策——比如命中法院被执行人名单的用户无论模型给多少分都必须拒绝年龄超过60岁的用户按监管要求需要人工复核。这些逻辑用规则引擎来表达比硬编码在业务代码里更清晰。毕设阶段不必上Drools这类重量级规则引擎用Spark的when表达式或者Java的LinkedListRule就能实现。规则引擎设计要注意两点第一规则要有“代码”即拒绝原因码方便事后追溯和统计第二规则要有“优先级”比如黑名单命中优先级最高直接短路后面的规则不再判断。// 规则引擎核心按优先级顺序执行返回决策结果 public class RiskRuleEngine { private ListRiskRule rules new ArrayList(); public RiskDecision evaluate(RiskContext ctx) { int score 0; ListString hitRules new ArrayList(); // 规则按优先级排序后执行 for (RiskRule rule : rules) { if (rule.matches(ctx)) { score rule.getScore(); hitRules.add(rule.getCode()); // 刚性拦截规则直接返回拒绝不再累加后续规则 if (rule.isBlocking()) { return RiskDecision.reject(score, hitRules); } } } // 得分规则累加后与阈值比较 if (score ctx.getRejectThreshold()) { return RiskDecision.reject(score, hitRules); } if (score ctx.getReviewThreshold()) { return RiskDecision.review(score, hitRules); } return RiskDecision.pass(score, hitRules); } }规则引擎和模型融合的常见做法是刚性规则用上面的isBlocking()直接短路非刚性规则把“命中条数”和“命中总分”作为两个新特征拼进模型输入。在Spark端实现就是when表达式的追加列。毕设里不必做复杂融合但要在论文里写清楚两类决策路径的优先级关系——这一点被问到的概率极高。5. HadoopSpark风控系统避坑六个高频翻车点与排查路径5.1 环境类NameNode元数据丢失、Spark内存溢出、端口被占现象一重启虚拟机后执行hdfs dfs -ls /直接报Failed to retrieve data from NameNodeDatanode状态全灰。原因是NameNode元数据目录放在了/tmp下系统重启清空。解决修改dfs.namenode.name.dir和dfs.datanode.data.dir到持久化目录重新格式化NameNode全量重跑数据。这是毕设里最冤枉的翻车点格式化后所有HDFS文件没了离线宽表要重新生成——务必及早改配置。现象二Spark作业报java.lang.OutOfMemoryError: Java heap space。原因通常是executor内存设得过大但物理机器不够或spark.sql.shuffle.partitions太大导致shuffle数据溢出。解决本地模式先降并发——--master local[2]控制在2个线程同时加--conf spark.memory.offHeap.enabledtrue --conf spark.memory.offHeap.size1g把部分内存挪到堆外减少GC压力。数据量在几百万条以内2G内存的executor绝对够用。现象三启动Spark任务时端口被占如4040或8088。原因之前的SparkContext没有正常关闭或多个作业同时启动抢端口。解决先执行jps看进程列表杀掉残留的SparkSubmit和Application进程再检查YARN的yarn.nodemanager.resource.memory-mb是否配得和本机内存一致配小了作业会一直卡在ACCEPTED状态。5.2 数据类JSON解析失败、Parquet Schema对不上、时间字段时区现象四spark.read.json报SparkException: Malformed line in json。原因文件里有空行或者某个JSON对象跨了多行。解决不要直接读原始文件先用textFile读入过滤空行再逐行处理也可以用spark.read.option(multiLine, true)但性能会下降建议数据预处理阶段就压成一行一个对象。现象五写Parquet再读时报org.apache.spark.sql.AnalysisException: cannot resolve loan_amount。原因第一次写入时某列全为nullSpark推断该列类型为string或直接丢弃——是Parquet的Schema推断坑。解决在读取CSV时手动指定每个字段的类型.option(inferSchema, true)只对CSV头部生效最稳妥的做法是定义StructType显式声明每个字段类型。宽表写入时也不要依赖默认先printSchema()检查一遍字段名和类型确认无误再写。现象六时间窗口统计偏差——date_sub(current_date(), 30)在不同时区下得到的结果不一致。现象是昨天跑的作业和今天跑的作业近30天数据差了一天。原因是Spark默认使用JVM系统时区集群各节点时区如果不一致时间聚合结果就会错位。解决提交任务时加--conf spark.driver.extraJavaOptions-Duser.timezoneGMT8并把spark.sql.session.timeZone显式设为Asia/Shanghai。这个坑在单机伪分布式下不会暴露但换了节点或容器部署就会出现属于典型的“本地没毛病、一上集群就翻车”。5.3 模型类数据泄漏、样本不均衡、特征穿越现象七模型AUC高达0.98但上线后表现远差于预期。原因大概率是数据泄漏。最常见的泄漏源有三个——训练集测试集没有按用户划分、特征里包含了“未来信息”如用还款结果反推的特征、用整个申请周期的数据计算窗口统计、以及宽表创建时把目标列is_default也当成了特征。排查方法把特征列表逐一过一遍凡是“该特征在预测时点不可能拿到”的全部删掉。对应地训练集测试集要按用户ID做分层而不是随机切分——这一点在答辩时一定要主动讲出来是加分项。现象八数据集里违约样本只占3%模型全部预测“不违约”准确率虚高但没有任何风控价值。解决不能只看accuracy要报告KS值、AUC、召回率。毕设阶段常用做法是负样本过采样——用sample.withReplacement把违约样本复制几份但更严谨的做法是给逻辑回归设置weightCol把少数类的权重调高510倍这样不改变数据分布也不易被老师说“数据造假”。权重系数怎么设可以做一个小的参数扫描实验写进论文的对比章节。6. 验收与加分技巧把毕设从“能跑”做到“能答辩”系统跑通只是起点答辩时拉开差距的是“验证方法论”和“边界描述”。先说验证不要只展示一个result目录下的CSV而是准备三张证据——第一张是HDFS的文件目录截图显示原始数据、中间宽表、模型文件各自的位置第二张是Spark作业的UI截图HistoryServer或4040端口页面上面能看到每个stage的shuffle读写量、GC时间和执行耗时第三张是AUC/KS曲线图配合随机森林做一条对照线。这三件套比一百行代码都更能证明你确实跑通了分布式链路。指标选择上风控不看准确率看的是KS和AUC。一个0.75的AUC在信贷场景里已经是有区分度的模型了关键是你能不能解释这个数意味着什么AUC 0.75等价于“随机抽一个违约用户和一个正常用户模型给违约用户打更高风险分的概率是75%”。这句话说出来老师就知道你不是只调了调库。调参技巧上逻辑回归的正则系数regParam值得做一次扫描分别试0.001、0.01、0.1观察训练集和测试集的AUC差距。差距大说明过拟合调大正则差距小且绝对值低说明特征不够要回宽表加特征。这个实验写进论文等于给“模型训练”章节加了实打实的工作量。最后提一个容易被忽略的验收点手动构造几条“命中黑名单”“近30天申请20次”“收入与借款不匹配”的样本跑一遍规则引擎确认每一条都被正确的拒绝原因码拦截。这是你答辩时的“演示预案”——万一现场网络不好、集群起不来你至少可以用提前跑好的日志和结果截图讲完整个风控流程。我自己的习惯是把这个验证写成一段bash脚本一键跑完并输出结果表一旦现场演示翻车立刻切到这段脚本既展示工程能力又化解突发状况。希望这篇笔记能帮你把这个毕设从“能跑”真正做到“能讲、能答、能扛追问”。本文还有配套的精品资源点击获取