数据中台讲解第一部分

数据中台通常分为以下几个逻辑层，每一层都有明确的职责：

1. 数据采集层（边缘层/源接入层）

• 目标： 多源异构数据实时/批量接入。

• 大厂实践：

  • 实时采集： Canal（解析MySQL binlog） + Kafka（消息队列），解决业务库数据实时同步问题。

  • 日志采集： 自研或基于Flume的埋点SDK，通过WebServer/App端上报日志。

  • 批量同步： DataX（阿里开源）或SeaTunnel，解决离线全量数据同步。

2. 数据存储与计算层（基础引擎）

• 目标： 提供高可用、弹性伸缩的存储计算资源。

• 大厂实践：

  • 湖仓一体： Hudi/Iceberg + Spark/Flink 构建数据湖，解决传统数仓无法直接管理非结构化数据及实时更新的痛点。

  • 离线计算： Hive/Spark/MaxCompute（阿里云）。

  • 实时计算： Flink（大厂标配，用于秒级延迟的计算）。

3. 数据公共层（核心资产层）

这是数据中台的核心灵魂，也是区别于普通数据平台的关键。严格遵循维度建模（Kimball方法论）。

• ODS（操作数据层）： 原封不动引入源数据，仅作备份。

• CDM（公共维度模型层） —— 核心：

  • DWD（明细层）： 进行事务型事实表建设，对业务过程进行沉淀。关键操作：进行维度退化（将维度属性字段退化到事实表）和实时/离线一致性的处理。

  • DWS（汇总层）： 面向主题的公共汇总层（如：日活汇总表、交易汇总表）。原则：复用而不是复制。如果一个指标在多处使用，必须由中台统一在DWS层加工。

• ADS（应用数据层）： 按需生成个性化的数据表，供特定报表或应用使用。

4. 数据开发治理层（工具平台）

大厂不仅仅是在写SQL，而是构建了一套可视化的平台能力：

• 数据开发IDE： 可视化的离线/实时任务开发、调度系统（DolphinScheduler/Airflow的替代或自研），支持版本控制和自动运维。

• 数据质量中心： 内置监控规则（如：表行数波动率、字段空值率、业务主键唯一性），一旦任务产出数据质量不达标，自动阻断下游任务（避免脏数据扩散）。

• 数据地图与血缘： 自动解析SQL，构建字段级的数据血缘关系。用于定位“这个字段是从哪里来的？”以及“修改这张表会影响下游哪些报表？”

5. 数据服务层（统一出口层）

将DWS/ADS层的数据封装成API。

• 统一API网关： 提供SQL化查询接口、预缓存接口。

• 逻辑模型： 对外屏蔽底层物理表结构，哪怕底层表结构改变，API输出格式不变（解耦）。

• 流控与鉴权： 限流、熔断、黑白名单，防止数据接口被恶意调用拖垮数据库。

6. 数据应用层（价值变现）

• BI报表： 基于公共层的自助取数与固定报表。

• 用户画像/标签： 基于OneEntity构建的标签体系，输出给推荐系统或营销系统。

• 数据洞察/即席查询： 对接Hue、DBeaver或自研SQL查询工具。

经验中的关键落地细节

1. 指标体系的管理（指标规范化）

• 原子指标 + 修饰词 + 维度 = 派生指标。这是阿里的经典做法。

  • 原子指标：支付金额。

  • 修饰词：海外用户。

  • 维度：时间（昨天）。

  • 派生指标：昨天海外用户的支付金额。

• 痛点： 如果没有这套体系，A部门建一个“GMV”（成交总额），B部门建一个“总交易额”，口径对不上，就是“表哥表姐”吵架的根源。

2. 数据治理的血缘与全链路追踪

• 场景： 运营发现今天早上的日报数据异常（暴跌或暴涨）。

• 大厂解法： 打开数据地图，点击指标，查看字段级血缘。系统会自动展示：

  • 上游：ODS原始日志 -> DWD清洗逻辑 -> DWS汇总逻辑。

  • 下游：哪些BI看板、哪些数据API受到影响。

  • 定位问题：是源业务库变更？ETL任务报错？还是逻辑代码BUG？

3. 实时与离线的统一（流批一体）

• 早期大厂通常是两套人（实时组、离线组），导致口径不一致（离线日活和实时日活对不上）。

• 现在趋势： 基于Flink SQL + Iceberg/Hudi，实现流批一体的语义层。同一套SQL逻辑，既可以跑离线T-1（前一天）数据，也可以跑实时数据，保证结果一致性。

4. 组织架构保障（中台部门定位）

• 强中台模式（阿里）： 数据中台是一个独立的技术/产品部门，KPI考核是“数据复用率”和“数据服务调用量”。业务部门不允许自己拉宽表，必须向中台提需求。

• 联邦模式（部分互联网大厂）： 中台建公共层（DWD/DWS），各业务线有自己的数据开发（隶属业务线）负责ADS层，但需遵守中台规范。

• 避坑指南： 如果缺乏组织保障和“一刀切”的治理决心，数据中台往往会沦为“数据ETL工具集”，最终变成数据沼泽。

避坑指南（别人踩过的雷）

1. 不要上来就做中台： 如果企业连基础的BI报表都没有，业务流程都未线上化，先做数仓建设，不要直接建设中台。中台是解决“重复造轮子”问题的，如果只有一辆车（一个业务线），不需要修八车道高速。

2. 警惕指标爆炸： 业务方提一个需求，就建一个指标/一张表。中台需要有“指标评审委员会”，拒绝高度个性化且无复用价值的指标进入公共层。

3. 数据安全与合规： 随着《数据安全法》出台，大厂中台必须内置数据分级分类。例如：手机号、身份证号在DWD层必须脱敏，在API层按权限解密。