data

2025-12-07

...

整站

数据领域知识体系

「背景」当下无论是企业需求还是社会发展趋势，数据领域的知识都非常重要。具体体现在企业决策与创新需要、数字化转型的适应、前沿技术和趋势的探索。「企业需求」数据已成为现代企业的核心资产，企业通过数据驱动决策、通过数据推动业务创新(掌握数据帮助企业发现新的商业模式和市场机会)；「社会发展趋势」另外随着数字化转型的浪潮，数据作为其核心要素发挥重要作用、推送技术和业务的融合；「前沿技术基础」在如今人工智能迅速发展，数据也作为其基础，为探索前沿技术奠定基础。

「目的」因此，本部分主要围绕数据领域的知识，逐一拆解核心分支的技术属性和业务价值。让读者有清晰、完整、详细的认识，以提升数据相关的职业竞争力。

首先是数据体系概述，介绍演进过程中的核心概念和和解决的问题。其次围绕4大核心分支，展开具体的定义和实践，其中包括常见的数据工程任务，还有数据分析、数据科学、数据合规与治理，另外包括数据工程架构/数据仓库等核心概念的下探总结。旨在帮助读者系统的了解数据领域相关技能和知识，能运用在企业和前沿技术实践中，助力个人职业发展。

一、数据体系概述

每一个技术概念和体系，到底解决了什么问题？先定义问题，再介绍是什么，以及怎么做（why、what、how）

黄金圈法则（Golden Circle）的实践。「这里有些偏差，Golden Circle是why、how、what」
“问题驱动 → 概念定义 → 落地实践” 的逻辑链，既符合技术研发的底层逻辑，也适合学习、求职、项目落地等场景。
「核心项解决的问题」
大数据平台：作为技术基础，在数字化时代数据驱动决策，解决决策效率/风险问题、趋势预判、成本问题、核心资产问题等。
数据仓库：数据杂乱无章、使用效率低；企业的账算明白、数据驱动的实现基础；是大数据平台的核心组成部分。
数据湖：数据仓库互补、非结构化数据、AI依赖的数据
湖仓一体：数据湖无法解决数据仓库的规矩，未治理的数据湖就是Data Swamp，不能发挥价值。
数据中台：重复造轮子、烟囱式发展。What：方法论、组织、技术架构的顶层设计和融合。OneData！OneService！

1.1 企业数据蓝图

如今数据的核心价值主要作用在商业智能和人工智能，以及各行业智能化应用。BI方面包括：决策支持、趋势分析、实时分析；AI方面包括自动化、智能应用等
数据不仅是企业做出决策的基础，还推动了AI技术的发展，改变了企业的运营方式和市场竞争方式。(对决策的支持和对智能化应用的推动作用)

那数据到底是如何推动的？以及如何在企业实践数据架构以解决BI和AI的问题呢？
以下从(多层次的)企业数据架构及数字化蓝图，系统的介绍下数据的价值和如何构建数据架构。

顶层的是业务价值：解决企业BI、AI、创新与产品研发、运营效率、风险控制等业务问题。
左侧的核心问题：是在构建数据仓库/数据体系过程中涉及的核心数据问题，主要影响数据效率和数据成本
中间层：是核心的数据架构，包括数据仓库以及自底向上的数据构建链路
右侧的大数据平台：是企业数据架构的核心技术实现，助力数据生命周期高效安全的发挥价值「技术基础」
数据中台：在大数据平台基础上，提供更加业务导向的、高效的数据服务。「面向业务的数据服务化」
核心解决效率和成本问题、实现数据可信、为业务赋能(驱动创新与智能决策)

1.2 核心概念决策

1.概念轰炸：隔壁老张的公司都上“湖仓一体”了！咱们现在到底是个啥？是还在搞仓库？还是上了中台？能不能给个准活！
回答：A，老板我们底层是大数据平台； B，不核心架构是数据仓库！ C，明年规划做数据湖！
2.灵魂拷问：别管那些词。我就问一句：销售部要的那个新指标，从提需求到看见数，周期缩短了吗？口径赫尔财务对上了吗？
3.尴尬的沉默：如果都没有解决，那你堆砌再多名词，也是给破车刷绿漆——-假装新能源。
4.一图破迷障：这五个词根本不是线性升级的关系！大家之所以晕，是因为没想清楚
是因为没想清楚自己是想“算账”、“存货”、还是“搞政治”

概念（角色定义）	问题定义	解释
(1)数据仓库 Data Warehourse	(老会计)就是给老板算账的地方。是企业的“后视镜”。	别跟我谈什么“探索”! 我要的是确定性！入库必须清洗！口径必须统一！模型必须星型！
	(老会计)严苛的门槛（新业务非结构化数据）拿走！格式不对！字段补全！这脏数据进来了，老板的额报表就不准了！我容不得沙子！
	(市场变化)现实的痛点市场都变了！我要看实时的！我要改指标！	改模型要走流程，排期三周。痛点：业务野蛮生长时，这位严谨的老爷子就是最大的瓶颈。
(2)大数据平台 Big Data Platform	(光有厨房没有初始)（秀肌肉的误区）海量数据随便存！亿级计算秒级跑！我是基础设施！	有肌肉没脑子？不关心报表什么时候出

数据湖：是“后路”还是“沼泽”？？囤积癖的狂欢：来着不拒！先存进来再说（Schema-on-read）！
万一以后有用呢？这叫保留数据的原汁原味！

理想VS现实：（核心问题）没有治理的数据湖，就是垃圾场。它现在的唯一作用就是做做个心里安慰备份盘———-看着东西都在，其实谁也不敢用！

Data Swamp（数据沼泽）。问题如何解决。

数据中台：其实是场“权利的游戏”。为什么每个部门都在重复造轮子？！为什么数据大家？！
中台真面目：以后公共指标我说了算！轮子统一去库里领！（OneData！OneService！）

激烈的博弈：凭什么把我的数据拿出来共享？这是我的私产！（数据资产）「中台本质是组织变革」

很多中台烂尾，不是技术不行，是“人”搞不定。没人愿意为公共资产负责。

湖仓一体：“成年人务实折中”。混血儿诞生。仓的规矩不能丢，湖的便宜和灵活也饿想要。于是搞出了这个折中的方案。

1.3 数据架构介绍

数据领域架构，除了常见的数据处理架构之外，还包括数仓架构。另外还包括数据中台架构、数据湖架构、数据治理架构、实时数据架构、湖仓一体架构、云原生数据架构、数据安全架构等。以上架构的理解以及核心架构的深入，是数据架构师必备的技能和知识体系。

架构理解。对这些架构的核心关联理解，可以用 “底座 - 处理 - 服务 - 保障” 四层逻辑串联所有架构：

存储底座层：数据湖架构、数仓架构、湖仓一体架构
数据处理层：Lambda/Kappa 架构、实时数据架
能力服务层：数据中台架构
安全保障层：数据治理架构、数据安全架构
部署形态层：云原生数据架构

它们并非孤立存在，而是相互支撑、层层递进，共同构成企业数据能力的完整技术底座。

具体的架构介绍和实践在[5]数据架构中详细展开。

1.4 四大核心分支

企业级数据架构主要从更高层面解决数据流转问题。但除此之外，数据领域的核心应用及工作也围绕各个环节、各个应用分支展开，
按 “技术属性 + 业务价值” 可拆解为 4 大核心分支，覆盖从底层技术到上层应用的全链条。

核心分支	核心定义	典型工作/岗位	解决的问题
(1)数据工程 Data Engineering	负责数据 “采集、存储、流转、加工” 的底层技术搭建，是数据领域的 “基础设施建设”	数据开发工程师、ETL 工程师、数据平台运维、数据架构师	数据湖 / 数仓搭建、实时流计算链路设计、数据治理
(2)数据分析 Data Analysis	衔接数据与业务，负责 “数据解读、报表呈现、业务诊断”，是数据领域的 “业务连接器”	业务分析师、商业分析师、BI 分析师	销售报表制作、业务问题诊断（之前的描述性 / 诊断性问题）
(3)数据合规与治理 Data Governance	负责数据 “质量、安全、合规” 的规则制定与落地，是数据领域的 “安全保障”	数据治理专员、数据安全专家、合规顾问	数据标准制定、隐私脱敏、合规审查（之前的跨组织数据协同合规问题）
(4)数据科学 Data Science	聚焦数据 “规律挖掘、预测、决策支持”，是数据领域的 “价值提炼核心”	数据科学家、数据挖掘工程师、算法工程师（偏分析）	用户分群、销量预测、风险识别（之前的预测性 / 决策性问题）

除了以上 4 大核心分支，大家常关注和工作相关的的内容还包括：数据架构/工程/仓库的建设，数据平台架构、存储等架构。

二、数据架构概述

2.1 企业数据蓝图

2.2 数据平台架构

2.3 专项子架构

三、四大核心分支

数据架构和数据领域的四大核心分支（数据工程、数据分析、数据科学、数据合规治理）是相互联系的，共同构成了数据管理与应用的完整体系。

数据架构为数据的各个领域提供了支持的框架，而四大核心分支分别从不同的角度管理和利用数据，协同工作形成了完整的数据管理和应用体系。在实际操作中，数据架构与各个领域紧密相连，确保数据从采集到使用的全过程中能够高效、合规、准确地流动和分析。

3.1 数据工程

「定义」
用工程化手段打通数据全链路，把 “原始数据” 变成 “可信资产”，为所有数据相关工作提供稳定、高效的底层支撑，解决业务的实际问题
数据工程涵盖了数据的整个生命周期，包括采集集成、存储架构、处理计算、治理质量、平台服务等；数据架构是更高层次的设计，以高效、可靠、高质量的交付数据

「划分」

数据工程工作的2大核心方向（从业务价值落地和技术效率角度看），可以划分为：
（1）数据链路的建设（业务导向）：通过数据工程链路解决业务实际问题
（2）数据平台开发（效率导向）：解决数据链路的效率问题，包括数据开发、生产、分析、使用等全链路的效率

从技术属性、业务价值角度看，可拆解为以下几个核心的分支：
（其它抽象的核心关键词：(方法论)[数据建模、数仓建模] ）

核心分支	核心定义	解决的问题	业务价值	典型场景 / 工具
采集与集成	多源异构数据接入（批量 / 实时）、数据源对接、数据传输链路搭建与监控	数据 “拿不到、传不畅”：跨系统数据孤岛、实时数据延迟、异构数据源格式不兼容	全渠道数据统一汇聚，标准化。为后续所有数据工作提供 “源头活水”，支撑实时 / 离线业务需求	APP 埋点实时采集(Kafka)、ERP 与 CRM 数据批量同步（CDC 工具）、物联网传感器数据接入（Flume）
存储与架构	存储方案选型、分布式存储搭建、数据分层建模（数仓 / 数据湖 / 中台）、存储性能优化	数据 “存不下、查的慢”：海量数据存储成本高、结构化/非结构化数据存储冲突、查询响应慢	构建灵活可扩展的数据存储底座，平衡存储成本与访问效率，支撑多场景数据应用（离线分析 / 实时决策）	湖仓一体架构搭建（Delta Lake+Snowflake）、数仓分层设计（ODS/DWD/DWS）、非结构化数据存储（MinIO）
处理与计算	批量 / 实时数据处理、ETL/ELT 流程开发、数据清洗 / 转换 / 标准化、分布式计算性能优化	数据 “用不了、算得慢”：原始数据质量差、海量数据计算效率低、数据格式不统一	把原始数据转化为 “干净、标准、可用” 的数据集，降低下游分析 / 建模的数据准备成本，提升数据处理效率	订单数据批量清洗（Spark）、实时销量计算（Flink）、用户 ID 统一标准化处理（Python 脚本）
治理与质量	数据标准制定、数据质量监控、元数据管理、数据血缘追踪、数据安全合规（脱敏 / 权限）	数据 “不可信、不合规”：数据质量低导致决策偏差、敏感数据泄露风险、数据权责不清晰	保障数据的准确性、一致性、安全性，让数据成为 “可信资产”，规避合规风险，提升数据使用效率	订单金额完整性监控（Great Expectations）、用户手机号脱敏（DataMasking 工具）、数据血缘可视化（Atlas）
服务与平台	数据接口开发、数据服务封装、数据平台搭建（含运维监控）、BI 工具对接、自助数据服务支撑	数据 “不好用、用不起”：业务人员取数门槛高、数据接口不稳定、平台运维成本高	降低数据使用门槛，实现数据 “按需取用”，支撑业务快速决策与创新，同时保障数据平台稳定运行	用户画像查询 API 开发（Spring Boot）、数据可视化看板搭建（Superset）、大数据平台监控告警（Prometheus）

3.1.1 采集与集成

「「定义」」
「数据采集」
数据采集（Data Collection / Data Ingestion）
是整个数据体系的第一层，用于将不同来源、不同格式、不同协议的数据获取并传输到数据平台或数据湖（存储层）内。
数据采集是整个数据中台、数仓、MLOps Pipeline 的入口

「数据集成」
采集 = 把数据拉/推出来
集成 = 把拉出来的数据洗好、分发好、落库好

各企业包括大厂的完整链路：数据源 → 采集 → 集成 → 存储 → 消费

「「体系架构」」
数据采集&集成体系：把几百上千个异构数据源的数据可靠、可控、可观测地搬到数据湖/数据仓库里

1.数据采集（Ingestion）：把数据从源头“搬出来”。提供多源的数据采集能力，实现不同渠道的数据高效采集
2.数据集成（Integration / Pipeline）：通过集成平台化，实现把采集到的“脏数据”清洗、标准化、再路由。
3.存储层：数据仓库和数据湖，核心的数据存储（提供高效读写）
4.数据治理层：纵向贯穿整个数据生命周期的“全局控制层”（绘图工具限制）

集成通道-消息队列：Streaming Bus(Kafka) 统一消息队列，实现缓冲、解耦、支持重放
采集层负责“把数据搬出来” → 交给Kafka → 集成层（Flink为主）负责“把数据洗好用好” → 落湖（Hudi/Iceberg为主）

flowchart LR
    style B1 fill:#FFE599
    style B4 fill:#FFE599
    style B2 fill:#FFE599
    style A1 fill:#FFE599
    style A2 fill:#FFE599
    style A5 fill:#FFE599
    style Governance fill:#FFE599
    style Ingestion fill:#e8f6f0
    style Pipeline fill:#e8f6f0
    style C0 fill:#e8f6f0,stroke:#D6B656;
    style E0 fill:#FFE599,stroke:#D6B656;
    style D0 fill:#ffffde,stroke:#D6B656;
    style Table fill:#FFE599
    %% =========== 数据来源 ==============
    subgraph Sources[数据来源层-Sources]
        A1[业务数据库
MySQL / PostgreSQL / Oracle]
        A2[日志系统
Nginx / App Log]
        A3[消息系统
MQ / Kafka]
        A4[第三方服务
API / Webhook]
        A5[IoT设备
传感器 / APP埋点]
    end

    %% =========== 数据采集方式 ==============
    subgraph Ingestion[数据采集层-Ingestion]
        B1[批量采集
Sqoop / DataX]
        B2[实时采集
Flume / Filebeat]
        B3[日志采集
Logstash / Fluentd]
        B4[CDC 变更数据捕获
Debezium / Canal]
        B5[API 拉取
Airflow / Python 脚本]
    end

    %% =========== 数据接入通道 ==============
    subgraph Pipeline[数据集成-接入/加工通道]
        C0[数据清洗 / 标准化]
        C1[消息队列
Kafka / Pulsar]
        C2[实时处理引擎
Flink / Spark Streaming]
        C4[Airflow + Python
dbt]
        C3[批处理引擎
Spark / Hive]
    end

    %% =========== 数据落地存储 ==============
    subgraph Storage[存储层-Lakehouse]
        D1[对象存储
S3 / OSS / COS]
        D0[数据存储]
        D2[数据湖
Hudi / Iceberg / Delta Lake]
        Table[Hudi表、Iceberg表、Delta Lake]
        D3[数据仓库
Hive / ClickHouse / Snowflake]
    end

    %% =========== 数据治理（纵向） ==============
    subgraph Governance[数据治理层-Governance]
        direction TB
        E1[元数据管理
Atlas / DataHub]
        E0[数据合规与治理-贯穿全局]
        E2[数据质量
DQ / Great Expectations]
        E3[数据血缘
Amundsen]
        E4[审计 & 安全
Ranger]
    end

    %% =========== 数据消费 ==============
    subgraph Consumption[数据消费层]
        F1[指标平台
Superset / Grafana]
        F2[数仓模型
DIM / DWD / DWS / ADS]
        F3[数据服务
API Gateway]
        F4[机器学习
Feature Store / MLflow]
    end

    %% ============== 把“数据接入通道-集成”大框改成虚线 ==============
    classDef dashedBox stroke-dasharray: 8 4, stroke:#555, stroke-width: 1px
    class Pipeline dashedBox
    class Governance dashedBox

    %% ======== 数据流动 ===========
    A1 --> B1
    A1 --> B4
    A2 --> B3
    A3 --> B2
    A4 --> B5
    A5 --> B2

    B1 --> C3
    B2 --> C1
    B3 --> C1
    B4 --> C1
    B5 --> C3

    C1 --> C2
    C2 --> D1
    C2 --> D2
    C3 --> D3
    C2 -.-> D3

    D0 --> E0
    Storage --> Governance

    Governance --> F1

「「体系详解」」

「数据来源」

分类	核心定义
① 业务数据库（OLTP）	结构化数据：MySQL、PostgreSQL、SQL Server、Oracle、MariaDB 采集方式：CDC（Change Data Capture）
② 日志与事件数据	非结构化或半结构化：Nginx / Apache Logs、App 埋点数据、SDK 上传事件、Server Logs（业务日志）、业务事件流（event logs）格式：JSON、KV、Text、Protobuf
③ 第三方 API / SaaS 服务	微信小程序、Stripe / PayPal、阿里云 / AWS Cloudwatch、Google Analytics、CRM（Salesforce、Hubspot）方式：Pull / Webhook / Batch
④ IoT 与传感器数据	设备传感器（温湿度、心率、GPS）；车辆、工业、智能硬件特点：高频、实时、持续流式
⑤ 文件系统数据	CSV、Excel；图片、音频、视频；文档（PDF、文本）来源：FTP / SFTP；企业 NAS；Object Storage（S3 / OSS / COS / MinIO）用于 ML（CV、NLP）时尤其关键。
⑥ 消息队列 / 流系统	Kafka、Pulsar、RabbitMQ、Kinesis、MQTT（IoT 常用）这里的数据本身已经是流式数据。

「采集方式」
按照时间维度

方式	核心定义
① 批处理（Batch Ingestion）	周期：分钟、小时、天常见工具：DataX（阿里）、Sqoop（Hadoop：大量数据导入）、Airflow 批作业特点：数据量大、延迟高、成本低；适合：报表、数仓数据
② 实时采集（Streaming Ingestion）	采集延迟：毫秒 - 秒级常见工具：Flume、Flink、Kafka Connect、Logstash 特点：高吞吐、连续流式；适合：监控、风控、实时推荐系统
③ CDC（Change Data Capture）	捕获数据库增量变化工具：Debezium（通用 CDC（强推荐））、Maxwell（MySQL CDC → JSON）、Canal（阿里）、 Kafka Connect（标准化 CDC 组件）特点：实时同步、对源库压力小；适合：业务库到数仓的同步（强烈推荐）

「典型工具 / 组件」
数据库同步类： DataX、Sqoop、Canal、Maxwell、Debezium、Kafka Connect
日志 / 事件流采集：Flume[日志采集 → HDFS / Kafka]、Logstash[日志解析与转换]、Filebeat[轻量日志采集]、Fluentd[日志收集与转发]、Vector（Datadog 开源）[高性能日志采集（新趋势）]
流处理与实时加工：Flink[实时计算 + 流式 ETL]、Spark Streaming[微批处理]、Kafka Streams[轻量实时逻辑]、Pulsar Functions[事件函数]
API / 外部数据获取：Airflow[定时调用 API 抓取]、Prefect[编排 + API 抓取]、python[requests / aiohttp]
IoT 数据采集：MQTT Broker（EMQX、Mosquitto）、AWS IoT / 阿里云 IoT Hub
文件数据采集：MinIO Client (mc)、S3 API、Hadoop FS、FTP/SFTP 同步工具、Airflow 定时同步

「工程最佳实践」

优先使用 CDC，同步成本最低、稳定性最高
日志 → 优先 Kafka + Flink，保证实时性 + 容错
多来源 → 用 Kafka Connect 形成标准化 Connector 系统
所有数据最终进入数据湖（Iceberg/Hudi）再分层处理
ML 场景：数据采集要关联元数据（s3 路径、标签、特征版本）
配合 MLOps → 接入 MLflow、Feature Store（Feast）
构建统一 Data Ingestion API，避免大量 ad-hoc 脚本

3.1.2 存储与架构

「「定义」」
作为采集集成的目的地，存储是以“数据资产化”为最高目标，实现低成本、高性能读写、一体化(批流)、事务一致性与的企业级统一存储底座。

同时兼顾Schema演化、多场景查询加速。提供分层、分格式、分时效管理。
也是下游分析、报表、AI、实时服务的数据唯一来源。

「「体系架构」」
存储架构 = 采集集成的终点站 + 数据资产的托管银行 + 全公司所有分析场景的唯一数据源

我们的存储架构不是简单的磁盘，而是全公司数据资产的银行金库——采集集成只管把钱（数据）存进来，我们负责保值、增值、随时取用、还能生利息（新业务、新模型）。

flowchart LR
    %% 采集与集成
    subgraph Ingestion[数据采集与集成]
        direction TB
        In[全量数据
统一接入

Kafka 
 Flink 
 Spark]
    end


    %% 核心：大数据存储架构（重点高亮）
    subgraph Storage[大数据存储架构\n唯一目的地 & 唯一来源]
        direction TB
        Raw[Raw Zone
原始落地区]
        Bronze[Bronze 层
原始结构化副本]
        Silver[Silver 层
清洗宽表区
Hudi / Iceberg / Delta]
        Gold[Gold 层
业务指标区
高性能聚合表]
    end

    %% 消费场景
    subgraph Down[消费场景]
        BI[BI 大屏 / 报表]
        API[实时 API 服务]
        ML[机器学习 / 推荐]
        SEARCH[日志 / 站内搜索]
    end

    %% 连线
    Ingestion --> Raw
    Raw --> Bronze --> Silver --> Gold
    Gold --> BI
    Gold --> API
    Gold --> ML
    Silver --> SEARCH

    %% 高亮存储架构金库
    classDef core fill:#e3f2fd,stroke:#1976d2,stroke-width:1px
    class Storage core

    %% 可选：把采集集成也标个颜色
    classDef up fill:#fff3e0,stroke:#ef6c00
    class Up up