简介：这份《数据中台建设方案》文档面向智慧城市、政务与行业大数据项目的架构师、数据平台开发及技术方案编制人员，用于解决数据中台从零规划时缺乏完整架构参考与落地路径的问题，也可作为企业级大数据平台选型、投标方案撰写的参考底稿。压缩包内共1个docx文件，大小约20.78MB，以图文并茂的方案文档形式呈现，便于直接阅读、摘取章节或二次编辑成汇报材料。方案内容围绕星环科技Transwarp Data Hub（TDH）与云操作系统TOS展开，覆盖总体建设方案、大数据平台产品优势与性能优化、数据采集/存储/交换/管理/资源管理五层集成平台建设，以及大数据计算平台、开发平台可视化工具与集成能力，并延伸至大数据运维、安全、高可用、开放性与兼容性等章节，目录层级清晰、模块划分完整。目前已有230人学习下载，适合作为数据中台顶层设计与落地实施的系统化参考资料。
1. 一份数据中台建设方案.docx 交出去之前，先确认冷热数据这条线落没落地
写过数据中台建设方案的人大概都经历过这个场面：架构图六层画得齐齐整整，主题域、指标口径、资产目录、质量规则一样不缺，评审会上所有人都点头。半年后账单出来，对象存储和 HDFS 用量涨了三倍，实际被查询的表不到总量的四成，剩下六成是三年没人动过的明细分区。问题不在架构，在方案里少了一句话——冷热数据怎么分、归档表什么时候建、归档之后下游任务怎么接。这三件事写在文档里是一行字，落到工程上是几百 TB 的差额，也是数据中台从「建起来」到「养得住」的分水岭。下面按落地顺序把它拆开：分层职责怎么划、冷热边界用什么口径、归档表用什么引擎建、迁移和校验的 SQL 怎么写、调度与元数据怎么配套，最后给一组能拿去验收的指标。
2. 数据中台建设方案的分层设计：从贴源层到归档层的职责划分
分层这件事在方案文档里通常只有一张图，但真正决定成本的是每一层的保留策略和存储引擎。图谁都会画，策略写不写得出数字，才是方案能不能落地的差别。
2.1 数据中台的六层职责与选型理由
常见做法是把中台划成六层，前四层是加工链路，后两层是成本治理和合规兜底。方案里如果只写前四层，后面一定会补一份「存储优化专项」，不如一次写全。
| 层 | 职责 | 存储引擎常见选择 | 保留策略参考 |
|---|---|---|---|
| ODS 贴源层 | 原样落地业务库增量/全量，保留原始语义 | Hive / 对象存储 / Hudi | 热存 30～90 天 |
| DWD 明细层 | 清洗、去重、脱敏、统一编码 | Hive / Iceberg | 1～2 年 |
| DWS 汇总层 | 按主题域轻度聚合，指标口径收敛点 | Hive / ClickHouse | 2～3 年 |
| ADS 应用层 | 面向报表与接口的宽表 | ClickHouse / Doris / MySQL | 随业务生命周期 |
| 归档层 | 低频访问明细，列存压缩，可查但慢 | Hive ORC/Parquet + 冷存储 | 3～10 年 |
| 备份层 | 合规留存，几乎不参与查询 | 对象存储归档型 | 按合规要求 |
有两点选型理由值得在方案里写清楚。一是 ODS 不要直接下沉到冷存储，回溯重跑、对账、链路重放都会读它，冷存储的取回延迟会把补数窗口直接顶爆。二是归档层要独立建表，而不是在 DWD 里靠分区过滤「假装归档」——同一张表分区跨到三年，分区元数据膨胀、小文件堆积、NameNode 压力全都跟着来，查询规划阶段就会变慢。
2.2 冷热数据的分界：按访问频次、时间还是成本
三种判定口径各有取舍。时间法最省事，按业务日期一刀切，缺点是会误伤那些虽然老但仍在被频繁引用的分区。访问频次法最准，但要先有查询审计日志，很多团队是在中台建完一年后才补上。成本法最贴近财务，算的是单位 GB 查询成本与单位 GB 存储成本的交叉点。
实际落地一般用组合口径：
| 判定维度 | 数据来源 | 阈值示例 | 适用场景 |
|---|---|---|---|
| 分区年龄 | 分区元数据 | 超过 180 天 | 日增量大、访问随时间衰减明显的事实表 |
| 近 N 天查询次数 | 查询审计日志 | 90 天内被查少于 3 次 | 已有审计日志、查询集中的团队 |
| 下游血缘数量 | 血缘图谱 | 无下游且无 BI 引用 | 僵尸表、僵尸分区治理 |
| 合规分级 | 数据分级标签 | 强制留存年限 | 只能归档不能删除的数据 |
一个反直觉的点：访问频次低不等于可以归档，还要看恢复代价。如果一次回溯要等六小时，业务方会用脚投票，直接在 DWD 上再拉一份宽表，中台白建。所以方案里除了写阈值，还要写「归档后单分区恢复时间目标」，常见做法是不超过 30 分钟，超过就说明归档粒度太粗了，应该按分区而不是整表迁移。
2.3 用 SQL 把冷热标记写进明细表
与其每天现算，不如把分层结果物化成一个字段，下游和治理任务都读它。
-- 在 DWD 明细表上增加分层标记字段，元数据操作，不重写历史数据 ALTER TABLE dwd_order_detail ADD COLUMNS ( storage_tier STRING COMMENT 'hot/warm/archive，由治理任务每日刷新' ); -- 按分区年龄打标，阈值必须与 2.2 的口径表对齐 INSERT OVERWRITE TABLE dwd_order_detail PARTITION (dt) SELECT order_id, user_id, pay_amount, dt, CASE WHEN dt >= date_sub(current_date(), 30) THEN 'hot' -- 30 天内，留在原表 WHEN dt >= date_sub(current_date(), 180) THEN 'warm' -- 30~180 天，观察 ELSE 'archive' -- 超过 180 天，进入归档候选 END AS storage_tier FROM dwd_order_detail_stage WHERE dt = '${bizdate}';这段逻辑的关键在两点。ALTER TABLE ... ADD COLUMNS只动 metastore，不触发数据重写，加的列在旧分区里读出来是 NULL，需要治理任务逐分区回填。CASE里的 30 和 180 不是拍脑袋的数字，要跟 2.2 表格里的阈值一致，改阈值时两边一起改，否则会出现「标记为 hot 但早已被归档」的状态错位。实际生产中我一般还会加一个辅助字段last_query_time，由审计日志回写，让「年龄 + 查询」两个口径能交叉验证。
提示：打标任务本身要幂等，用
INSERT OVERWRITE分区而不是INSERT INTO，否则重跑一次就多一批重复行。
3. 数据中台建设方案里的归档表落地：建表、迁移、校验的三段式命令
分层标记只是判定，真正省下成本的动作是把数据从热存搬到冷存，并且保持可查。这一段是整个数据中台建设方案里最容易写虚、也最容易在半年后返工的部分。
3.1 归档表的三种形态与选型
归档不等于把数据删掉，也不等于原样复制一份。常见三种形态，成本和可查性差别很大。
| 形态 | 做法 | 压缩比参考 | 可查性 | 适用 |
|---|---|---|---|---|
| 同构归档表 | schema 一致，换存储介质和压缩算法 | 2～4 倍 | 直接查，语义不变 | 仍需按明细回溯的数据 |
| 裁剪归档表 | 只留分析必需列，去掉大文本、JSON 明细 | 5～10 倍 | 部分字段不可查 | 日志类、埋点类宽表 |
| 快照归档 | 按年/月导出 Parquet 文件挂外表 | 取决于压缩 | 需按路径查 | 合规留存、几乎不查 |
选型的判断标准是「归档后还有没有人按主键查单条」。有，就老老实实做同构归档表；没有，裁剪归档的收益最大。日志埋点类数据是裁剪归档的典型对象，因为 80% 的存储被少数几个大字段占着，而这些字段在分析里很少被 select。
3.2 Hive 归档表的建表与分区迁移
建表时把压缩和文件块参数一次配好，后面就不用反复重建。
CREATE TABLE IF NOT EXISTS dwd_order_detail_archive ( order_id BIGINT COMMENT '订单ID', user_id BIGINT COMMENT '用户ID', pay_amount DECIMAL(18,2), channel_code STRING, storage_tier STRING ) COMMENT '订单明细归档表，180 天以上分区' PARTITIONED BY (dt STRING) STORED AS ORC TBLPROPERTIES ( 'orc.compress' = 'ZLIB', -- 归档场景优先压缩比，ZSTD 读写更快但压缩略低 'orc.bloom.filter.columns'= 'order_id', -- 单条回溯全靠它 'orc.row.index.stride' = '10000', 'hive.exec.dynamic.partition.mode' = 'nonstrict' );迁移不建议一条INSERT跑到底，按分区逐月搬迁更稳，失败可以断点续跑。
# migrate_archive.py # 逐月搬迁 dwd_order_detail 中 storage_tier='archive' 的分区 from pyspark.sql import SparkSession spark = (SparkSession.builder .appName("dwd_order_detail_archive_migrate") .config("spark.sql.shuffle.partitions", "400") # 单月数据量按 400 分区摊 .config("spark.sql.adaptive.enabled", "true") # 自适应合并小文件 .config("spark.sql.adaptive.advisoryPartitionSizeInBytes", "268435456") # 单分区目标 256MB .enableHiveSupport() .getOrCreate()) months = ["2023-01", "2023-02", "2023-03"] # 由调度传参，不用手写 for m in months: spark.sql(f""" INSERT OVERWRITE TABLE dwd_order_detail_archive PARTITION (dt) SELECT order_id, user_id, pay_amount, channel_code, storage_tier, dt FROM dwd_order_detail WHERE dt LIKE '{m}%' AND storage_tier = 'archive' """)三个参数值得解释。spark.sql.shuffle.partitions默认 200，对月级明细偏小，容易在单分区里堆出超大文件，调到 400～800 更合适。advisoryPartitionSizeInBytes设成 256MB 是让 AQE 把小于这个值的分区合并，直接解决归档表最常见的小文件问题。INSERT OVERWRITE ... PARTITION (dt)用动态分区写入，重跑同一月份不会产生重复文件。
注意：迁移前先把目标表的生命周期（TTL）和冷存储策略绑定，不然数据搬过去了，存储介质还是热存，钱一分没省。
3.3 归档前后的一致性校验
搬完必须校验，三种粒度一起看，缺一种都可能漏。
-- 粒度一：行数对齐 SELECT 'src' AS t, COUNT(*) AS cnt FROM dwd_order_detail WHERE dt LIKE '2023-01%' AND storage_tier='archive' UNION ALL SELECT 'dst', COUNT(*) FROM dwd_order_detail_archive WHERE dt LIKE '2023-01%'; -- 粒度二：主键去重计数，防止迁移过程中因重分区引入重复 SELECT 'src', COUNT(DISTINCT order_id) FROM dwd_order_detail WHERE dt LIKE '2023-01%' AND storage_tier='archive' UNION ALL SELECT 'dst', COUNT(DISTINCT order_id) FROM dwd_order_detail_archive WHERE dt LIKE '2023-01%'; -- 粒度三：金额汇总，用于发现字段截断或精度丢失 SELECT 'src', SUM(pay_amount) FROM dwd_order_detail WHERE dt LIKE '2023-01%' AND storage_tier='archive' UNION ALL SELECT 'dst', SUM(pay_amount) FROM dwd_order_detail_archive WHERE dt LIKE '2023-01%';行数对不上，多半是WHERE条件里storage_tier的边界写错，比如源表用=而目标表用LIKE。去重计数对不上，一般是迁移里混进了重复分区。金额汇总对不上，优先查DECIMAL精度声明，归档表建表时写成DECIMAL(10,2)就会静默截断。三步都过了，再删源分区，删除动作也要按分区来，不要DROP TABLE。
4. 数据中台建设方案的调度与元数据配套：冷热链路不能只做一半
归档表建好只是开始，如果调度、元数据、权限三块没跟上，下游会在两周内把归档表重新读成热表，或者干脆绕过中台自己拉数据。
4.1 调度依赖：归档任务与下游任务错峰
归档任务会占用大量 IO 和 shuffle 资源，跟出报表的任务挤在同一个时间窗，两边都会超时。常见做法是把归档调度放在业务低峰，并且和下游任务建立明确依赖。
| 任务 | 建议时间窗 | 依赖关系 | 超时阈值 |
|---|---|---|---|
| 日常 ETL | 01:00～05:00 | 上游为 ODS 同步 | 60 分钟 |
| 归档迁移 | 05:30～08:00 | 依赖当日 ETL 完成、标记任务完成 | 120 分钟 |
| 一致性校验 | 归档后 30 分钟 | 强依赖归档迁移成功 | 30 分钟 |
| 源分区清理 | 校验通过后 | 强依赖校验任务成功 | 15 分钟 |
依赖链的写法是「归档任务依赖打标任务，清理任务依赖校验任务」，中间任何一环失败就中断，不要用「忽略失败继续跑」，否则会出现「校验没过但源分区已被删」这种不可逆的问题。
4.2 元数据与血缘：让归档表可被搜到
归档表最容易变成「数据沼泽」的原因，是它没进资产目录，没人知道它存在，于是下游重新从 ODS 拉一遍。迁移任务里应该同步写元数据。
-- 把归档表注册进元数据表，标注源表、归档时间、粒度 INSERT INTO meta_table_registry (table_name, source_table, layer, partition_grain, archive_start, owner, ttl_days) VALUES ('dwd_order_detail_archive', 'dwd_order_detail', 'archive', 'day', '2023-01-01', 'data-platform', 3650);partition_grain标清是日分区还是月分区，下游查的时候才不会按天扫全表。archive_start标明最早分区，配合血缘图谱，BI 工具在解析 SQL 时就能提示「该表为归档表，查询延迟较高」，把预期先降下来。
4.3 权限与冷查询成本控制
归档表如果对所有分析师开放，成本会以一种很隐蔽的方式反弹：单次查询慢、扫描量大，但每个人都觉得自己只查了一次。常见做法是给归档表单独设一个只读角色，并强制查询带上分区条件。
-- 归档层专用角色，只读 CREATE ROLE archive_reader; GRANT SELECT ON TABLE dwd_order_detail_archive TO ROLE archive_reader; -- 通过视图收口，强制分区过滤，禁止全表扫描 CREATE VIEW v_dwd_order_detail_archive AS SELECT order_id, user_id, pay_amount, channel_code, dt FROM dwd_order_detail_archive WHERE dt >= date_sub(current_date(), 1095); -- 只暴露近三年用视图收口的好处是策略写在一处，改阈值不用逐个通知用户。代价是视图会隐藏部分分区，需要历史全量的场景要走单独申请流程。这一步在数据中台建设方案里常常被忽略，但它决定了归档之后成本曲线是往下走还是回来。
5. 数据中台建设方案的验收：三类指标验证冷热分层有没有真省钱
方案写完、任务跑完，怎么证明这一套起了作用？不要只看存储总量，那个数字受业务增长影响太大。看三类比值更准。
第一类，存储结构指标。归档层容量占全量比例、热存容量同比增速、单表平均压缩比。正常的组合是归档层占比稳步上升，热存增速明显低于业务数据量增速，压缩比落在 2～5 倍区间。如果归档层占比上去了但总账单没降，先查归档表用的存储介质是不是还在热存桶里。
第二类，访问结构指标。归档层查询占比、单次归档查询平均扫描分区数、P95 恢复时间。归档层查询占比长期低于 5% 说明分层合理；如果单次查询平均扫描分区数在涨，说明视图收口没生效，有人在绕过视图直接查表。
第三类，一致性指标。校验任务通过率、源分区清理滞后天数、血缘覆盖率。清理滞后天数是个容易被忽视的指标，它反映「数据搬了但没删」，等于双份存储，很多团队成本降不下来就卡在这一步。
-- 每日采一次，落到治理看板 SELECT current_date() AS stat_date, SUM(CASE WHEN layer='archive' THEN size_gb ELSE 0 END) / SUM(size_gb) AS archive_ratio, SUM(CASE WHEN layer IN ('ods','dwd','dws') THEN size_gb ELSE 0 END) AS hot_size_gb, COUNT(DISTINCT table_name) AS table_cnt, AVG(compression_ratio) AS avg_compress FROM meta_table_registry WHERE stat_date = current_date();一个具体技巧：阈值别一次调到位。先把归档线从 365 天挪到 180 天，跑两周看恢复请求量，再决定要不要继续降到 120 天。降得太快，业务方的回溯需求会集中爆发，恢复任务排队，反而把归档链路压垮。把这条阈值当成一个需要持续微调的参数，而不是方案文档里写死的一个数，冷热分层的收益才会随业务一起滚起来。
本文还有配套的精品资源，点击获取
