数据仓库与数据挖掘

业务系统每天都在产生订单、支付、库存、访问日志和客户服务记录。把这些记录保存下来只是第一步。真正困难的是：数据分散在不同系统里，字段含义不统一，历史版本不断变化，而管理者希望在几秒钟内回答跨年度、跨区域、跨产品的问题。

数据仓库把多源数据整理到适合分析的统一结构中，联机分析处理负责从不同维度快速汇总，数据挖掘则用历史样本发现关联、类别与群组。三者不是彼此独立的工具。没有稳定的仓库和清楚的口径，算法只会更快地放大数据问题；没有可以验证的业务问题，再复杂的模型也很难转化成可靠决策。

下面用一个零售分析平台贯穿全文。交易库负责接单和扣减库存，分析平台需要回答“哪个地区的哪类商品正在增长”“哪些商品经常一起购买”“哪些客户可能流失”等问题。我们会从数据进入仓库开始，一直走到模型上线后的质量与漂移监控。

从事务数据到分析决策

两类工作负载关心不同的事情

联机事务处理面向正在发生的业务。一次结算通常读取少量行、更新少量行，并要求低延迟、并发控制和故障恢复。查询模式比较稳定，例如按主键读取订单、插入支付记录、扣减一个仓库的库存。这里最重要的是每一笔业务都正确完成。

分析处理面向一段时间内的整体规律。一次查询可能扫描数月订单，连接商品、门店和日期信息，再按多个维度分组。它通常以读取和聚合为主，单次计算量大，但查询数量远少于事务请求。这里最重要的是历史完整、口径一致和批量扫描效率。

图：事务处理和分析处理都使用业务数据，但访问粒度、更新方式和性能目标不同。

为什么要把分析负载隔离出来

如果年度销售报表直接扫描生产订单库，它会占用缓冲区、I/O 带宽和 CPU，还可能与正在提交的订单争用资源。更麻烦的是，生产库经常只保留当前状态：订单地址被修改后，旧地址可能已经消失；商品分类调整后，过去的报表也会随之改变。

数据仓库把多个数据源的记录汇集到一个地点，按统一口径保存较长时间，并向报表与模型提供稳定接口。它让分析查询不必逐一适配每个业务系统，也避免大型扫描拖慢核心交易。仓库中的数据可以看成源系统记录经过清洗、转换和持久化后的分析快照，而不是生产表的简单复制。

数据采集、ETL 与新鲜度

数据何时进入仓库

采集可以由源端推动，也可以由仓库拉取。源端推动时，业务系统在事件发生后持续发送变更，或者每天定时输出增量文件；仓库拉取时，调度器按水位线请求“上次成功时间之后”的数据。前者接近实时，后者控制简单。无论采用哪一种，只要不是同步复制，仓库就会落后于源端一段时间。

新鲜度不是越实时越好。库存告警可能要求分钟级更新，月度经营复盘使用前一日数据已经足够。同步链路会增加源系统负担，也把源端故障更快传到分析端。因此应先定义服务目标，例如“订单明细延迟不超过 15 分钟”“财务日报在次日 7 点前完成”，再选择批量、微批或流式采集。

ETL 与 ELT 的职责边界

ETL 按“抽取、转换、加载”的顺序工作。抽取负责从数据库、文件或消息流取得原始记录；转换负责字段映射、类型转换、单位统一、重复消除和业务规则校验；加载负责以可重试、可追踪的方式写入仓库。

ELT 先把数据装入分析平台，再利用平台的并行计算能力完成转换。它适合原始数据量大、转换逻辑经常迭代的场景，但“先加载”不意味着原始区可以失去管理。原始数据仍应有分区、保留期限、访问控制和血缘记录。

图：质量规则作用于清洗和转换，血缘记录贯穿数据源、处理步骤与最终结果。

工程上还要解决三件事：

1. 增量边界：记录最大时间戳、日志序号或版本号，防止漏读和重复读。
2. 幂等加载：同一批次重跑时结果不重复，可使用业务键合并或先删除目标分区再写入。
3. 迟到数据：事件发生时间与到达时间分开保存，允许已关闭的日期分区在规则范围内重新计算。

数据质量、口径与治理

清洗不是删除所有“不整齐”的记录

各源系统独立建设后，同一实体可能使用不同编码、字段名和单位。一个系统用“北京”，另一个用“北京市”；一个系统以元存金额，另一个以分存金额；同一客户还可能因空格、拼写或证件格式差异出现多条记录。清洗要依据可说明的规则纠正这些差异，而不是看到异常就直接丢弃。

模糊匹配可以借助地址词典、邮编或相似度寻找候选纠错；合并清除用于识别重复记录；同户归并可以把一个家庭的多条邮寄记录归为一次触达。这些方法都可能误合并，所以应保存原始值、规则版本、匹配得分和人工复核状态。

指标口径必须能够追溯

“销售额”可能指下单金额、支付金额、发货金额或扣除退款后的净额。“活跃客户”可能按登录、购买或使用核心功能定义。如果报表只展示数字却没有口径，两个看似冲突的结果可能只是定义不同。

治理可以落到一组具体控制上：

质量至少要观察完整性、唯一性、有效性、一致性和及时性。更重要的是把失败记录隔离出来：一批数据即使只有 0.1% 失败，也不能悄悄吞掉。任务应报告失败数量、失败原因和对关键指标的影响，让使用者知道结果是否适合当前决策。

事实表、维度表与粒度

先写清一行事实代表什么

维度建模的第一步不是画表，而是确定粒度。例如“销售事实一行代表一个订单”与“一行代表订单中的一个商品明细”是两种不同模型。前者方便统计订单数，后者才能正确分析商品数量、品类组合和单品折扣。粒度含糊时，连接后很容易重复计算。

事实表记录业务事件，通常行数很大。它包含连接维度的键和可以聚合的度量，如数量、原价金额、优惠金额、实付金额。维度表提供分析上下文，例如日期、商品、门店、客户。维度键一般使用短标识，事实表通过外键引用它们。

一个零售明细事实可以写成：

销售事实(
  日期键, 商品键, 门店键, 客户键, 订单号,
  数量, 原价金额, 优惠金额, 实付金额
)

日期维度保存日、周、月、季度和年份；商品维度保存名称、品类、品牌和规格；门店维度保存城市、省份和区域。这样，度量可以沿不同维度分组，也能沿层级从城市上卷到省份和区域。

图：星型模式让事实表直接连接维度；雪花模式继续拆分维度层级，减少重复但增加连接。

星型还是雪花取决于查询与维护

星型模式的维度相对宽，查询路径短，业务人员容易理解。雪花模式把品类、部门或地理层级继续规范化，减少维度中的重复值，却让查询包含更多连接。两者没有绝对优劣：经常交互分析且维度规模适中时，星型更直接；层级需要独立治理或被多个维度共享时，雪花拆分更合适。

历史维度还要回答“按当时属性还是当前属性分析”。若商品今天从“数码配件”调整到“办公用品”，直接覆盖维度会改写过去报表。常见做法是为属性版本分配新的代理键，并记录生效区间，让旧事实继续指向旧版本。

为扫描和聚合设计存储

行式与列式布局解决不同访问模式

行式存储把一条记录的各列放在一起。读取或更新一个完整订单时，一次定位就能取得大部分字段，因此适合点查询和小范围写入。列式存储把同一列的值连续放置。若报表只需要数十列中的“地区、品类、实付金额”，系统可以跳过其余列，显著减少磁盘读取和内存带宽。

同一列的数据类型相同、重复值多，字典编码、游程编码和压缩通常更有效。压缩不仅节省空间，还能减少从存储读取的字节数。代价是拼装一整行需要访问多个列块，频繁单行写入也更复杂，所以分析仓库常以批量追加、分区替换或合并小文件的方式更新。

分区、摘要与数据湖的边界

仓库通常按日期分区，再根据常用过滤条件组织数据。分区裁剪可以让“查询上月数据”只读取一个月的分区。原始明细太大时，可以保留较细时间窗口的明细，同时保存更长期的日、月汇总，但必须明确哪些问题需要回到原始事实。

数据湖允许结构化记录、日志和非结构化文件以原始格式进入，减少预先统一模式的成本。它把一部分工作从写入时推迟到查询时：使用者需要知道格式、字段演化和质量差异。仓库强调统一模式和稳定口径，数据湖强调保留多种原始形态；实际平台常让两者协作，而不是把任一方当成万能替代。

多维数据与 OLAP

维度、度量和交叉表

多维数据把可以汇总的数值称为度量，把观察度量的角度称为维度。在销售分析中，数量和金额是度量，时间、商品、地区和客户类型是维度。二维交叉表把一个维度放在行上、另一个放在列上，每个单元格保存满足组合条件的聚合值；没有放到表面的维度则取某个固定值或“全部”。

数据立方体把交叉表推广到多个维度。三维立方体的一个单元格可以表示“某月、某地区、某商品”的销售额。若某个维度取“全部”，该单元格就是沿这一维聚合后的摘要。真实系统不必真的画出高维几何体，立方体只是理解分组组合的方式。

图：切片与切块选择立方体的一部分，上卷和下钻改变粒度，旋转改变观察维度。

五个常用交互动作

• 切片固定一个维度的单个值，例如只看华东区。
• 切块同时限制多个维度的值域，例如华东和华南、最近三个月、两个品类。
• 旋转改变交叉表的行列维度，例如把地区换到列、月份换到行。
• 上卷从细粒度聚合到粗粒度，例如城市到省份、月份到季度。
• 下钻从汇总回到更细层级。细节不能凭空从粗汇总恢复，必须读取原始数据或更细摘要。

维度层级决定上卷路径。时间可以按“日期 → 月份 → 季度 → 年份”，地理可以按“城市 → 省份 → 国家 → 区域”。层级必须处理好一对多关系和历史变化，否则同一城市或组织结构变更会让汇总结果失真。

物化视图与预计算

用空间和刷新成本换查询时间

很多分析问题反复计算相同摘要，例如每日门店销售、每月品类销售和地区客户数。若每次都扫描明细事实，响应时间会随历史增长。物化视图把查询结果实际保存下来，查询时读取较小的汇总结果，从而把计算成本从“每次查询”转移到“预先计算和刷新”。

数据仓库本身也可以理解为源数据经过转换后保存的物化结果。更细一层，仓库内部还会保存按常用维度组合得到的摘要。选择哪些摘要不是越多越好，因为每个结果都占用存储，并要随新事实到达而刷新。

图：预计算结果缩短常见查询路径，但同时带来存储和刷新成本。

为什么不能保存完整立方体

若有 $n$ 个维度，只考虑“参与分组或取全部”两种状态，就可能形成 $2^n$ 种维度子集。层级和不同取值进一步增加单元格数量。维度很少时完整预计算可行，维度增加后，完整立方体可能比原始事实大得多。

较稳妥的做法是部分物化：保存访问频繁、计算昂贵、能派生其他结果的摘要。例如已有“月份、地区、商品”摘要，就能继续聚合成“月份、地区”，不必回扫全部订单。选择时要同时估计查询频率、明细扫描成本、摘要大小、刷新频率和允许延迟。

SQL 中常见三种分组表达：

-- 所有维度子集
GROUP BY CUBE(月份, 地区, 商品)
 
-- 按给定顺序形成层级摘要
GROUP BY ROLLUP(地区, 省份, 城市)
 
-- 只计算明确需要的组合
GROUP BY GROUPING SETS (
  (月份, 地区),
  (地区, 商品)
)

增量刷新只重算受新数据影响的分区或分组；完全刷新则重新生成全部结果。若迟到订单修改了上月数据，系统不仅要更新明细，还要同步修正所有相关摘要。物化视图的“快”依赖正确维护，过期摘要必须带有明确的新鲜度标记。

数据挖掘是半自动发现过程

从业务问题到可检验模式

数据挖掘在大规模数据中寻找有用规则、模型和群组。它不是让算法在数据里随意“找惊喜”，而是先明确任务：预测客户是否流失属于分类，预测下月金额属于回归，发现经常同时购买的商品属于关联规则，把相似客户分群属于聚类。

真实流程包含大量人工判断。分析人员要选择观察总体、时间窗口、标签和特征，处理缺失与异常，再判断模式是否新颖、稳定、可行动。算法可以自动搜索候选模式，却无法替代业务定义和结果审查，因此整个过程更接近“人设定问题与约束，系统搜索和计算，人再验证”的闭环。

先划定时间，再划分训练与测试

预测任务必须模拟真实使用时点。若要在 6 月 1 日预测客户未来 30 天是否流失，特征只能使用 6 月 1 日之前可获得的信息，标签来自之后的观察窗口。把未来退款、最终状态或人工处置结果混入特征，就是数据泄漏。

训练集用于学习参数，验证集用于比较方案和阈值，测试集只用于最终评估。随机划分并不总合适：时间序列、用户重复记录和门店分布都可能让相似样本跨集合泄漏。必要时应按时间、用户或组织分组划分。

关联模式也不等于因果关系。雨伞销量与交通拥堵可能同时上升，是因为下雨共同影响两者。一个模式能用于推荐或预警，并不自动证明改变前件就会导致后件变化。因果决策通常还要结合实验、自然实验或更强的识别假设。

关联规则与 Apriori

支持度和置信度回答两个不同问题

设购物篮总体为 $N$，规则写成 $X \Rightarrow Y$。支持度表示同时包含 $X$ 和 $Y$ 的购物篮在总体中的比例：

置信度表示已经包含 $X$ 的购物篮中，有多少也包含 $Y$：

假设 1000 笔交易中，300 笔买牛奶，400 笔买面包，240 笔同时购买。规则“牛奶 → 面包”的支持度为 24%，置信度为 80%；反向规则“面包 → 牛奶”的支持度仍为 24%，置信度却变成 60%。支持度不区分方向，置信度区分方向。

如果面包本来就出现在 40% 的交易中，提升度为 $0.8/0.4=2$，说明在已买牛奶的条件下，面包出现概率是总体基线的两倍。提升度接近 1 时，高置信度可能只是后件本身很常见。

图：先找达到最低支持度的频繁项集，再从中产生并评估有方向的规则。

Apriori 怎样减少候选集合

商品有成千上万种时，枚举所有组合不可行。Apriori 使用一个单调性质：如果一个项集不频繁，那么包含它的任何更大项集都不可能频繁；反过来，一个频繁项集的所有子集都必须频繁。

基本步骤如下：

1. 扫描交易，保留达到最小支持度的单商品集合 $L_1$。
2. 连接 $L_{k-1}$ 产生大小为 $k$ 的候选集合 $C_k$。

阈值过低会产生海量偶然组合，阈值过高又会漏掉小众但重要的模式。还要先定义“一个实例”是什么：按单次结算、按客户一周内购买还是按整个客户历史，得到的规则含义完全不同。

分类、回归与模型评估

分类从带标签样本学习边界

分类任务已知若干类别和过去样本的真实类别，再根据其他属性预测新样本属于哪一类。信用风险可以分为“低、中、高”，客户流失可以分为“会流失、不会流失”。标签必须在训练时可确认，在真实预测时却尚未知。

决策树从根节点开始检查条件，沿分支到达带类别的叶节点。它的路径容易解释，但树过深可能记住训练噪声。贝叶斯分类器计算观察到特征后各类别的后验概率：

朴素贝叶斯进一步假设给定类别后各特征条件独立，用各条件概率的乘积近似 $P(d\mid c)$。这一假设并不总成立，却能降低高维联合分布的估计难度。

支持向量机寻找与两类最近样本距离尽量大的分隔边界，核函数可以把非线性关系映射到更高维空间。神经网络通过多层加权变换学习复杂表示，使用反向传播调整权重。算法名称不是选型结论：数据规模、特征类型、可解释要求、推理延迟和误判成本都会改变选择。

图：测试数据不参与训练，预测结果要通过混淆矩阵和业务代价共同检查。

准确率不够时看混淆矩阵

二分类结果可以分为真正例、假正例、真反例和假反例。精确率回答“预测为正的样本中有多少是真的”，召回率回答“真实正样本中有多少被找出”。欺诈或罕见故障的正样本很少时，即使模型全部预测为负，准确率也可能很高，所以必须根据业务代价选择指标和阈值。

回归预测连续数值，例如下月销售额或违约损失金额。最简单的线性模型写成：

分类输出类别或类别概率，回归输出数值。两者都需要在未参与训练的数据上评估，并在上线后检查输入分布、误差和阈值是否变化。

聚类与可信分析闭环

聚类没有预先给定的类别标签

聚类把相似对象放入同一组。客户分群可以根据购买频率、最近购买时间和消费金额形成若干群组；电影推荐可以先找兴趣相近的用户，再参考同群用户喜欢的新内容。与分类不同，聚类没有训练标签，得到的簇需要事后解释和验证。

距离定义决定“相似”的含义。如果消费金额以万元计、购买次数只有个位数，未标准化时金额会主导欧氏距离。数值特征常先做标准化，类别、文本和稀疏行为则需要合适的编码与距离。缺失值也不能简单当作零，因为“没有记录”和“真实为零”可能不同。

图：聚类依据距离或相似度形成群组，坐标尺度和异常点会直接影响结果。

给定簇数 $k$ 时，常见目标是最小化每个点到所属簇中心的平方距离：

层次聚类则形成从细到粗的树状结构，可以观察对象在不同层级怎样合并。算法收敛不代表业务分群有效，还要检查簇规模、稳定性、可解释性，以及分群是否能支持差异化行动。若每次换一个样本就完全改变分群，结果很难用于运营。

从一次分析走向持续可信

分析结果进入业务后，数据和环境仍在变化。商品结构、渠道、客户群和采集规则变化会造成输入漂移；人工策略又会反过来改变标签分布。可信闭环至少包括：

1. 明确业务问题、观察总体和成功指标。
2. 固定数据口径，运行完整性、唯一性和及时性检查。
3. 记录特征、模型、阈值与训练数据版本。
4. 在独立数据上验证，并按人群、地区和时间切片检查误差。
5. 上线后监控数据延迟、特征漂移、预测分布和实际效果。
6. 触发阈值后回滚、降级或重新训练，并保留审批和审计记录。

权限和隐私贯穿所有步骤。分析只应读取完成任务所需的数据；展示和导出时要控制明细粒度；模型使用个人数据时要说明目的、保留期限和访问范围。可解释性也不是一张特征重要性图就结束，而是让业务人员知道输出能回答什么、不能回答什么，以及出现错误时由谁处理。

图：数据质量、权限、隐私、可解释和漂移监控共同决定分析结果能否长期使用。