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

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

这里主要分4大核心分支，包括常见的数据工程任务，还有数据分析、数据科学、数据合规与治理，另外包括数据工程架构/数据仓库等核心概念的下探总结。旨在帮助读者系统的了解数据领域相关技能和知识，能运用在企业和前沿技术实践中，助力个人职业发展。

零、全景图

数据领域， 按 “技术属性 + 业务价值” 可拆解为 4 大核心分支，覆盖从底层技术到上层应用的全链条。

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

一、数据工程

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

「划分」

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

1.1 采集与集成

1.1.1 定义

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

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

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

1.1.2 体系架构

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

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

1.1.3 体系详解

「数据来源」

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

「典型工具 / 组件」
数据库同步类： 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 定时同步

「工程最佳实践」

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

1.2 存储与架构

1.2.1 定义

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

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

1.2.2 体系架构

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

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

1.3 处理与计算

二、数据分析

三、数据合规与治理

3.1 数据安全

3.2 数据合规

四、数据科学

五、数据架构/工程/仓库

数据架构、数据工程、数据仓库三者是 “顶层规划→工程落地→核心载体” 的层层支撑关系，共同构成企业数据资产建设的 “从蓝图到落地” 全链路

数据架构（规划层）：负责定义：数据仓库的技术选型（如用 Snowflake 还是 ClickHouse）、数据分层标准（ODS/DWD/DWS）、数据主题边界（如 “销售主题”“用户主题”）；
不直接落地，而是输出 “数据仓库建设规范”，指导数据工程的具体工作。

数据工程（执行层）
按数据架构的规范，落地数据仓库的全流程：
采集：从业务系统 / 日志等多源数据接入；
加工：通过 ETL/ELT 清洗、转换数据，按主题建模（星型 / 雪花模型）；
存储：将加工后的数据加载到数据仓库；
治理：监控数据仓库的质量、维护元数据；
同时，数据工程还会落地数据湖、实时流等其他载体，不局限于数据仓库。
数据仓库（载体层）
是数据工程的核心产出物之一，存储 “结构化、集成化、主题化” 的数据；
支撑下游应用（如 BI 报表、业务分析），是数据价值释放的关键节点。

5.2 数据架构与建模

核心关系：数据架构是数据建模的 “前提与约束”，数据建模是数据架构的 “具象化落地”
数据建模将数据架构的 “蓝图转化为实体”（无建模，架构是空壳）
两者协同迭代（架构指导建模，建模反哺架构）

数据架构和数据建模是 “一体两面”：数据架构是 “道”（规则与方向），数据建模是 “术”（落地与实现）；

todo： 分别做一个 数据架构 、数据建模的 事情。