📚 课程目录第3章业务理解与数据需求

3. 数据存储架构：数据库、数据仓库与数据湖

做信用评分模型，第一件事不是调算法，而是搞清楚——你的数据到底藏在哪？我说的是物理层面的存储系统。

先聊个真实经历。我2017年参与过一个银行零售信贷评分项目，对方IT团队说“所有数据都在Oracle里”。结果我去查，发现交易流水、客户基本信息、催收记录、外部征信报告……混在一张大表里，清洗耗时占项目总工期的60%。事后复盘才发现：他们缺的不是数据，而是分层存储的架构意识。

今天咱们就掰开揉碎，讲讲数据库、数据仓库、数据湖这三个核心概念。在信用评分领域，它们分别扮演什么角色，怎么选，怎么搭。

3.1 三者的核心定位

先给个直观对比。你想想看，银行柜台系统每笔交易立刻写入的，那是数据库；分析师做报表、查历史趋势用的，是数据仓库；而数据科学家想要原始日志、非结构化文本、图像，基本全在数据湖里。

我把核心差异整理成了表格，方便你对照着看。

维度	数据库 (OLTP)	数据仓库 (OLAP)	数据湖
典型用途	实时交易、增删改	复杂查询、聚合分析	原始数据存储、探索性分析
数据格式	结构化，范式化	结构化/半结构化，星型/雪花型	结构化/半结构化/非结构化
写入模式	行式存储，实时写入	列式存储，批量ETL	追加写入，Schema-on-Read
数据质量	强一致性（ACID）	清洗、转换后较干净	原始、可能有噪声
信用评分场景	存储客户基础信息、交易流水	存放特征宽表、评分结果	存放征信报告文本、通话录音、图像
典型技术	MySQL, PostgreSQL, Oracle	Snowflake, Redshift, BigQuery	S3, ADLS, HDFS, Delta Lake

个人习惯：我一般把数据库当成“数据源头”，数据湖当作“数据缓存池”，数据仓库才是“特征工厂”。这三层分离后，ETL流水线才清晰。

3.2 信用评分模型的数据流向图

下面这张流程图，画出了我从原始数据到模型特征的全链路。你一看就明白为什么需要三种存储。

避坑指南：我曾经在一个二手车金融项目里，把征信报告PDF直接存在数据湖里。结果模型上线后，发现部分PDF加密，读取失败。后来额外加了一层解析服务。记住——数据湖不是垃圾桶，非结构化数据入湖前至少要做可用性检查。

3.3 具体场景怎么选

实际工作中，你很难一步到位建成完整的三层架构。这里分享几个我过往项目的决策点。

如果团队小（1-3人）：先别碰数据湖。我建议直接用PostgreSQL当数据库，再用Python脚本定期拉数据到本地做特征。等数据量超过500GB，或者非结构化需求出现，再考虑数据湖。
如果已有数据库但查询慢：别急着上数据湖。试试建物化视图、索引优化。实在不行，复制一份到列式数据库（比如ClickHouse）作为查询加速层，成本低、见效快。
如果非结构化数据占比高（语音、图像、PDF）：数据湖几乎是必须的。我用Amazon S3配合Athena做临时查询，非常灵活。
如果要求强一致性（比如反欺诈实时评分）：别把数据仓库当作实时查询库。反欺诈模型的特征计算最好在数据库层面就做完，或者用流处理引擎（如Flink）直接取数据库binlog。

我的经验法则：80%的信用评分特征都可以直接从数据库或数据仓库拿到。只有当你需要“客户在过去3个月内每次投诉的电话录音时长”这种特征时，数据湖才真正登场。

3.4 数据湖的三层分区实践

我习惯在数据湖里按“原始层、清洗层、特征层”来组织。这样下游模型训练时，不用每次都从头处理。

# 这是我常用的数据湖路径结构（以Hive风格为例）
/data_lake/
  /raw/                         # 原始层，保持源数据格式不变
    trade_log/                   # 交易日志
      dt=2024-01-01/
        part-00000.json
    credit_report_xml/           # 征信报告XML
      dt=2024-01-01/
  /clean/                        # 清洗层，去除乱码、填充空值
    trade_log_cleaned/
      dt=2024-01-01/
        part-00000.parquet
    customer_profile_flat/       # 客户画像宽表
      dt=2024-01-01/
  /features/                     # 特征层，直接喂给模型
    rolling_30d_features/
      model_version=v1.2/
        part-00000.parquet
    application_features/
      model_version=v1.2/

你看，这种分层让我在回测或特征回溯时，能直接指定某一天的特征快照。说白了，模型训练数据集 = 特征层的某个时间切片。

一个节省成本的小技巧：原始层的数据保留3个月，清洗层保留6个月，特征层保留12个月。过了这个时间，可以直接归档到冷存储。我在做车贷评分模型时，靠这个策略每年省了30%的云存储费。

3.5 你可能会问：那用Delta Lake或Iceberg呢？

问得好。这些是“湖仓一体”技术，试图把数据湖的灵活性和数据仓库的事务能力结合起来。我这两年参与的项目里，Delta Lake用得最多。

给个小建议：如果你团队技术栈以Spark为主，而且需要做增量更新或回滚，那Delta Lake是个不错的选择。但如果是传统的SQL分析师较多，还是老老实实搭一个数据仓库。

好了，这章内容就到这里。你需要把这三个存储的定位刻在脑子里：数据库是命根子、数据湖是原料库、数据仓库是精炼厂。下一段路，咱们聊聊特征工程里更具体的数据质量控制方法。