数据集成权威指南——数据来源与类型

数据智能老司机
207 阅读32分钟

数据源是组织在运营或分析中使用的数据起点。它们既可能是结构化也可能是非结构化，格式多样、位置各异。在现代数据集成中，数据源对在需要时为合适的人提供准确、及时、可靠的信息至关重要。

我们将先识别不同的数据源——这些为数据系统提供燃料的信息之泉。从关系型数据库与 NoSQL 数据库，到平面文件与 API，我们会解析它们各自的特性以及最能发挥作用的使用场景。

接着，我们将深入各类数据类型与数据结构。理解它们的差异与细微之处，有助于你更高效地处理数据，并据此调整方法以匹配手头数据的本质。

最后，我们会介绍常见的数据格式，如 CSV（逗号分隔值）、JSON（JavaScript 对象表示法）与 XML（可扩展标记语言）。每种格式都有其表达方式、优点与挑战。深入理解这些格式，将帮助你在具体情境中做出更明智的取舍。

本章涵盖以下主题：

  • 认识数据源：关系型数据库、NoSQL、平面文件、API 等
  • 使用数据类型与数据结构
  • 熟悉数据格式：CSV、JSON、XML 等
  • 数据源：关系型数据库、NoSQL、平面文件与 API

随着组织希望充分释放数据潜能，来自多源的数据集成愈发关键。数据集成有助于打破数据孤岛、提供业务全景视图，并支撑明智决策。它是当今数据栈设计（摄取、转换、存储与分析）的核心组成部分。

认识数据源：关系型数据库、NoSQL、平面文件、API 等

理解多种数据源及其属性，是实现跨源集成的基础。常见数据源包括关系型数据库、NoSQL 数据库、平面文件、流数据与 API。每类数据源都有独特特性与用例，理解其差异是成功集成的关键。

本节我们将介绍各类数据源、它们在数据集成中的作用、优缺点；并讨论数据源在现代数据栈中的重要性，以及数据集成对数据质量、治理与合规的影响。读完后，你将系统理解数据源对数据集成的价值，并学会利用它们获取更好的洞察与决策。

在当今的数据版图中，信息的存储与管理方式多种多样。下面概述主要数据源的特性与差异，并给出常见实例：

  • 关系型数据库 依据关系模型，以**表（行/列）**组织数据，使用 SQL 定义、操作与查询。常见产品有 MySQL、PostgreSQL、Oracle、Microsoft SQL Server。适合管理结构化数据，并通过主外键维护实体间关系。
  • NoSQL（not only SQL）数据库 为应对关系库在可扩展性、灵活性、高可用与性能方面的限制而生，可处理非结构化、半结构化或结构化数据，擅长高写入吞吐的大规模场景。类型包括文档型（如 MongoDB）、列式（如 Cassandra）、键值型（如 Redis）与图数据库（如 Neo4j）。我们将在后文 NoSQL 章节详细展开。
  • 平面文件（Flat files） 以纯文本或二进制形式存储，如 CSV、JSON、XML、Excel。可被多种语言与工具读写，适用于小规模存储与交换；但在大规模处理上，受限于缺乏内置索引/查询能力与可扩展性。
  • API（应用程序编程接口） 作为中介，使不同应用可通信与共享数据。API 便于从 Web 服务、社交平台、SaaS 等多样来源取数。典型 Web API 包括 RESTful 与 GraphQL，常用 HTTP/JSON 进行数据交换。

NOTE
为你的应用选型时，应综合考虑数据结构、可扩展性、性能以及具体用例。不存在放之四海而皆准的方案，实际往往需要多种数据源组合来满足集成需求。

总之，数据源的选择取决于数据结构、规模、性能诉求与具体场景。理解各类数据源的主要特性与差异，有助于组织为其数据集成需求选择最适合的方案。

关系型数据库

关系型数据库是众多企业应用的数据管理基石，因其稳健、易用、可靠而广受青睐。它们用于处理结构化数据，以**表（行/列）**精细组织；配合标准语言 SQL，实现流畅的数据操作与检索。本节概述让关系库不可或缺的关键特性：SQL 如何工作、如何建模与范式化、以及运维与使用时的考量。

发展简史

1970 年，IBM 研究员 Edgar F. Codd 在论文《A Relational Model of Data for Large Shared Data Banks》中提出关系模型，以行列表组织数据，极大简化了数据的操控与检索。随后 SQL 成为与关系库交互的标准语言。

此后出现了 MySQL、PostgreSQL、Microsoft SQL Server、Oracle 等广受欢迎的关系型数据库，各具特色，成为企业应用的中流砥柱。

关键特性

  • 结构化组织：以表存储数据，行代表记录、列代表属性，便于高效存储与查询。
  • 数据完整性与一致性：遵循 ACID（原子性、一致性、隔离性、持久性） ，即使硬件故障也能保障数据可靠。
  • 索引与查询优化：支持 B-Tree、位图、哈希等索引；优化器会为 SQL 选择高效执行计划。
  • 事务与并发：支持多用户并发读写且不互相干扰，满足银行、电商等高并发一致性需求。
  • 安全机制：提供认证、授权与加密，确保只有被授权的用户才能访问或修改数据。

SQL——关系型数据库的语言

SQL 提供一套标准操作来定义、操纵与检索数据：

  • 语法与基本操作：SELECT（查询）、INSERT（插入）、UPDATE（更新）、DELETE（删除）。
  • DDL 与 DML：DDL（数据定义语言）用于创建/修改/删除表、索引、约束等；DML（数据操纵语言）用于对对象中的数据进行增删改查。
  • 复杂查询能力：支持 JOIN（多表连接）、GROUP BY（聚合）、HAVING（聚合后过滤）、子查询，以及窗口函数（如 OVER (PARTITION BY ...)），可实现滑动汇总、移动平均、排名等分析。
  • 存储过程、触发器与视图：存储过程是可复用的预编译 SQL 逻辑（但需注意治理与并发资源瓶颈风险）；触发器在特定事件发生时自动执行，有助于落实数据完整性与业务规则；视图是基于查询的虚拟表，便于抽象与权限控制。

image.png

（图 4.1：SQL 中不同类型查询 —— 略）

下面是一个用 SQL 表达同一用户数据的示例结构：

CREATE TABLE user (
    id INT,
    lastName VARCHAR(50),
    firstName VARCHAR(50),
    age INT,
    email VARCHAR(100),
    street VARCHAR(100),
    city VARCHAR(50),
    country VARCHAR(50)
);
CREATE TABLE phone (
    user_id INT,
    type VARCHAR(50),
    number VARCHAR(20)
);
INSERT INTO user (id, lastName, firstName, age, email, street, city, country)
VALUES (123456, 'Doe', 'John', 30, 'johndoe@example.com', '123 Main Street', 'City', 'Country');
INSERT INTO phone (user_id, type, number)
VALUES (123456, 'mobile', '1234567890');
INSERT INTO phone (user_id, type, number)
VALUES (123456, 'work', '0987654321');

在该示例中，user 表存放用户信息，phone 表存放该用户的电话号码；两者通过外键 user_id 关联。
注意：以上仅是用 SQL 展示结构与数据；实际落地需在 MySQL、PostgreSQL、SQLite 等 DBMS 中执行并持久化管理。

关系型数据库中的数据建模与范式化

关系建模通常以 ER 模型 表达数据结构与关系：实体（表）、属性（列）与关系（外键）。
范式化（Normalization） 是通过拆分表结构减少冗余、提升数据完整性的过程。常见范式如下：

范式（Normal Form）定义（Definition）判定标准（Criteria）
1NF第一范式（First NF）表具有主键；各列为原子值（无重复组/嵌套结构）。
2NF第二范式（Second NF）在 1NF 基础上，所有非主键列完全依赖于整个主键（无部分依赖）。
3NF第三范式（Third NF）在 2NF 基础上，所有非主键列仅依赖于主键（无传递依赖）。
BCNF / 4NF / 5NFBoyce-Codd 范式 / 第四范式 / 第五范式在 3NF 基础上更进一步，解决特定异常，进一步提升一致性与完整性。

表 4.1 —— 各范式对比（后续第 7 章“数据摄取与存储策略”将详细展开）

典型用例

  • 企业应用：如 CRM、HRMS、ERP 等需要管理大量结构化数据的系统
  • 电商平台：库存、客户、订单与支付等核心数据
  • 金融系统：银行、保险、投研等对数据完整性与安全性要求严苛的场景
  • 医疗系统：病历、就诊与治疗方案等敏感信息的安全存取
  • 内容管理系统（CMS） ：网站/博客的文章、页面与用户数据

局限性

  • 可扩展性：数据与并发量上升时性能可能受限；纵向扩容容易，横向分片对事务与 JOIN 依赖较强、难度更大。
  • 非结构化数据处理：对文本、图像、视频等非结构化数据支持不如专门系统高效。
  • 灵活性：模式（Schema）较为刚性，频繁变更成本高，甚至需要停机。
  • 复杂查询：层级/图关系等查询用 SQL 表达与高效执行并不容易。

小结

关系型数据库数十年来一直是数据存储与管理的中坚力量：它为结构化数据提供强大的组织、完整性与复杂查询支持。但在可扩展性与非结构化数据方面仍有短板。

TIP
SQL 功能强大但写好、调优复杂查询并不容易。可通过 SQLZoo、W3Schools、Khan Academy 等在线资源提升技能。随着数据 体量、种类与速度 的增长，已出现针对关系库短板的替代/补充方案，如 NoSQL 数据库、列式数据格式、流式数据平台 等。理解各方案的优劣权衡，对为你的应用选择合适的存储与管理技术至关重要。

NoSQL 数据库

现在我们把目光转向数据管理演进中的一个重要里程碑——NoSQL 数据库。这一部分标志着从传统数据库与关系模型向更灵活、可扩展、类型多样的数据管理方案的关键转变。
NoSQL 数据库诞生于对海量非结构化与半结构化数据的处理需求。它们面向传统关系型数据库难以满足的场景而设计，如可扩展性、速度以及多样的数据类型。

NoSQL 的历史

“NoSQL”一词最早由 Carlo Strozzi 于 1998 年用于描述其不使用 SQL 的轻量级开源关系数据库。但如今的 NoSQL 含义形成于 2000 年代末：随着更具可扩展性与灵活性的存储需求增加而兴起。大数据、社交媒体与云计算的崛起进一步暴露了传统关系库的局限，促成了多种 NoSQL 数据库的诞生。

NoSQL 的类型

NoSQL 主要有四大类型，每类都有其特性与典型场景：

  • 文档型（Document-based） ：以文档（常为 JSON/BSON）存储数据。模式灵活，同一集合中的文档字段与类型可不一致。示例：MongoDB、Couchbase。
  • 列式（Column-based） ：以列而非行存储数据，擅长稀疏数据的高效查询与存储。为分布式高读写吞吐而生。示例：Apache Cassandra、HBase。
  • 键值型（Key-Value） ：以键值对存储，查找极快且简单。适合缓存、会话管理、实时分析。示例：Redis、Amazon DynamoDB。
  • 图数据库（Graph） ：以节点与边建模，擅长实体关系的高效查询。适用于社交网络、推荐引擎、欺诈检测。示例：Neo4j、Amazon Neptune。

混合 SQL/NoSQL：部分数据库把关系库的优势与 NoSQL 的灵活性结合，既支持结构化也支持非结构化数据。例如 PostgreSQL 支持 JSON 存储与全文检索，让开发者在一个系统里同时利用 SQL 与 NoSQL 的长处，适配既要关系又要非关系的广泛应用。

时序数据库（TSDB） ：专为时间序列数据而生（按时间索引的数据点），常见于金融、IoT、监控等领域。此类数据库针对时序数据的存储、查询与分析做了优化。 image.png

（图 4.2：各类 NoSQL 与软件分类 —— 略）

下面给出文档型 NoSQL（如 MongoDB）的表示示例：

{
  "_id": "123456",
  "lastName": "Doe",
  "firstName": "John",
  "age": 30,
  "email": "johndoe@example.com",
  "address": {
    "street": "123 Main Street",
    "city": "Cityville",
    "country": "Countryville"
  },
  "phones": [
    { "type": "mobile", "number": "1234567890" },
    { "type": "work", "number": "0987654321" }
  ]
}

在文档型数据库（如 MongoDB）中，数据以 JSON 文档形式存储。每个文档是独立记录，结构可灵活变更。

NOTE
NoSQL 相比关系库拥有更高的灵活性与可扩展性，但也存在取舍。著名的 CAP 定理指出：分布式系统在一致性（Consistency） 、**可用性（Availability）与分区容错性（Partition Tolerance）**三者中最多同时满足两项。不同 NoSQL 类型会在三者间做不同权衡。

上例文档代表一个用户，字段含义如下：
_id：唯一标识；lastName/firstName/age/email：基本属性；address：子文档（街道/城市/国家）；phones：子文档数组（不同类型的电话号码）。
文档结构的灵活性便于按应用需要增删字段，无需刚性的模式约束，适合字段多变的场景。

NoSQL 的关键特性

  • 模式灵活：支持动态/无模式数据模型，便于适应需求变化。
  • 水平扩展：天然支持向外扩展，通过数据分片部署到多台服务器，承载海量数据与高写入负载。
  • 高性能：围绕特定数据模型与场景优化，面对某些工作负载优于关系库。
  • 多类型数据支持：能处理非结构化、半结构化与结构化数据，适用面广。

典型应用场景

  • 大数据处理：承载高写入、大体量数据（如日志、事件流）。
  • 内容管理与分发：应对多样内容类型（网页、多媒体、元数据），兼顾灵活性与性能。
  • 实时分析：键值/列式 NoSQL 的高读写能力非常适合实时分析与监控。
  • 社交与推荐：图数据库能高效建模并查询用户、内容、商品间的复杂关系。

小结

NoSQL 为关系库提供了有力补充：在特定场景下具备更强的可扩展性、灵活性与性能。

NOTE
也有数据库融合两者优势，既支持结构化又支持非结构化数据。PostgreSQL 就提供 JSON、全文检索 等特性。这种混合路径让你在单一系统内同时利用 SQL 与 NoSQL 的优点，适合既要关系又要非关系存储的应用。

理解各类 NoSQL 的优缺点与权衡，有助于为你的应用选择合适的存储方案。

理解各数据源的差异与数据集成中的适用场景

要高效整合多源数据，必须把握各数据源类型的长短板，并针对具体用例选择最合适的方案。下面按优势/劣势/典型用例进行对比：

数据源优势劣势典型用例
关系型数据库强一致性与完整性、清晰的模式、复杂关系良好支持横向扩展受限、处理非结构化数据不灵活、复杂查询优化难金融系统、库存管理、CRM
NoSQL 数据库高可扩展性、模式灵活、可处理多类型数据、支持高写入负载受 CAP 权衡约束、查询语言与能力差异大大数据分析、社交应用、实时数据处理
TSDB（时序库）高性能、压缩好、时间保留策略、可扩展、内置时序函数数据模型受限、学习曲线、集成复杂、成熟度/支持度不一实时监控/分析、IoT 数据处理、指标采集
平面文件简单易用、与多语言工具兼容可扩展性有限、缺少内置索引/查询、难保一致性与完整性数据交换、配置文件、小规模存储
API标准化交换、实时访问、可用外部数据依赖第三方服务、可能出现性能瓶颈实时集成、Web/移动应用、多服务数据聚合

表 4.2 —— 各类数据源对比

结论：每类数据源都有其独特的优劣与适用面。基于具体用例、可扩展性需求与数据模型做出选择，往往需要组合多种数据源来构建稳健的数据版图。理解整体数据生态并相应制定数据策略，才能最大化收益，用数据驱动更明智的决策。

数据源的选择与用例

在综合前文所有要素后，有必要退一步，用正确的理由选对解决方案。

选择合适的数据源

选型取决于数据结构、可扩展性、性能要求以及具体用例。选择数据源时可自问：

  • 你的数据类型是什么（结构化、半结构化还是非结构化）？
  • 你的可扩展性需求如何（小规模还是大规模）？
  • 你的性能侧重什么（读多、写多，还是读写均衡）？
  • 是否需要特定功能（如复杂关系、实时访问、对外部数据源的支持等）？

用例示例

以下示例有助于理解各类方案适配的场景。

关系型数据库示例：

  • 金融机构使用关系型数据库维护客户记录、交易与账户明细，确保数据一致性与完整性。
  • 电商平台用关系型数据库做库存管理与订单处理，需要维护商品、订单与客户之间的关系。

NoSQL 数据库示例：

  • 社交应用常用 NoSQL 存储用户画像、好友列表与动态流，受益于其灵活性与可扩展性。
  • 流媒体平台用 NoSQL 做实时处理与分析，实现个性化推荐与体验优化。
  • 相比关系型数据库，NoSQL 通常更适合时间序列场景，因其模式灵活、在高速数据检索上表现更佳。

TSDB（时序数据库）示例：

  • 金融市场分析：存储并分析股价、汇率等，用于趋势分析与预测。
  • 物联网与传感器数据：存储分析温度、湿度、能耗等设备数据。
  • IT 基础设施监控：实时存储分析 CPU、内存、带宽等指标，监测系统健康。
  • 环境监测：存储分析气象站采集的温度、降雨量、空气质量等数据。

平面文件示例：

  • 企业以 CSV 或 Excel 交换数据，用于报表、分析与数据迁移。
  • 软件以 JSON 或 XML 存放配置，便于解析与修改。

API 示例：

  • 移动应用通过 API 获取实时天气、定位等外部数据。
  • 数据集成平台用 API 聚合多个 SaaS（如 CRM、营销自动化、项目管理）数据，支持全景分析与 BI。

接下来，我们将讨论数据类型与数据结构。

处理数据类型与数据结构

现在把注意力转向数据旅程中的核心要素：数据类型与数据结构。理解它们并非纯理论，而是像学习一门“数据语言”的语法。

  • 数据类型定义了信息的本质（如整数、布尔、字符串），决定可执行的操作、内存分配与存储格式。
  • 数据结构是组织与存储数据的方式（如数组、链表、树、图），关系到算法实现与高效处理。

引言：为何在数据集成中重要

  • 一致性：跨源集成需了解各自的数据类型与结构，以正确映射与处理，避免损坏或丢失信息。
  • 转换：类型与结构决定可进行的转换操作，指导合理设计转换流程，实现格式与结构的互换。
  • 性能优化：不同类型与结构具有不同性能特性，理解它们有助于优化存储、检索与处理效率。
  • 数据质量：正确处理类型与结构能保持准确性与一致性，进而提升洞察与决策质量。

不同数据结构类型概览

我们从结构化、半结构化、非结构化三类出发，理解其特征、差异与典型来源。

结构化数据

以行列和预定义模式组织，易检索、易处理；多存于关系型数据库。
特点：

  • 高度组织化、模式固定
  • 表格化（行/列）存储
  • 可用 SQL 高效查询
    **示例来源：**关系型数据库、电子表格、CRM 系统等。

半结构化数据

兼具结构化与非结构化特征，有一定标记/标签组织（如键值）。
特点：

  • 结构松散但有标记（标签/键）
  • 比结构化更灵活，但检索相对困难
    **示例来源：**JSON、XML、CSV，及各类日志文件（服务器/应用日志等）。

非结构化数据

最少组织约束的类型，如文本、图片、音视频等，无固定模式，分析较难。
常需 NLP/计算机视觉/机器学习 提取价值。
**示例来源：**文档（Word、PDF、邮件）、社交内容、图片/视频、音频等。

选择合适的数据结构类型

关键差异回顾：

数据结构类型主要特征典型数据源
结构化高度组织、预定义模式、易检索关系型数据库、表格、CRM
半结构化结构+非结构混合、有标记JSON、XML、CSV、日志
非结构化无固定模式、内容多样文档、社交媒体、多媒体

表 4.3 —— 数据结构类型对比

小结： 理解三类数据结构的差异，有助于选择合适的处理与分析工具与方法。正确选型能提升效率与效果，为数据驱动决策提供高质量支撑。

数据类型示例

以下是分析与数据科学的基础数据类型，每类都为洞察带来不同维度：

文本数据（Textual）

亦称非结构化文本，源于邮件、社交帖、新闻、书籍等。分析需 NLP 提取主题、情感与模式。

数值数据（Numerical）

以数字表示，可度量或计数。分为：

  • 离散型（整数，如员工数、销量）；
  • 连续型（实数，如温度、重量、距离）。
    适用于统计分析与建模，揭示趋势与变量关系。

分类型数据（Categorical）

又称定性/名义型，用类别表示（如性别、族别、产品类型）；

  • **有序型（Ordinal）**具天然顺序（如教育水平、满意度）。
    常用频数分布、列联表、卡方检验等分析方法。

时间序列数据（Time Series）

按固定时间间隔记录的观测值（如股价、GDP、气温）。
分析侧重趋势、季节性与周期性，常用移动平均、指数平滑、ARIMA 等方法。

空间数据（Geospatial）

带地理位置/坐标属性的数据（点、线、面），常用 GIS 映射与分析；
技术包括空间自相关、插值、地统计等，用于识别空间模式与关系。

image.png

（图 4.3：数据类型示例 —— 略）

总结与过渡
本节阐明了多类数据类型在分析中的作用。接下来我们将更深入讨论结构化/半结构化/非结构化数据在集成中的影响：它们的优劣、处理方法与实践示例，从而进一步打磨我们的数据处理策略与价值最大化路径。

理解这些数据结构的差异及其对数据集成的影响

在当今数据驱动的世界里，理解结构化、半结构化与非结构化数据之间的差异及其对数据集成的影响至关重要。每种数据结构都有各自的长处与短板，会直接影响你选择的数据集成技术与策略。本节将对这些数据结构进行对比，并给出在集成场景中的处理要点；同时配以真实用例，帮助你理解其落地方式。

下表给出了不同数据结构类型的优缺点：

表 4.4 —— 各数据结构类型的优缺点

数据结构类型优点缺点
结构化易于查询与分析；模式清晰；效率高。灵活性不足；难以处理多样数据类型；模式维护成本高。
半结构化比结构化更灵活；可支持多样数据类型。效率不如结构化；查询更困难；缺乏严格模式。
非结构化高度通用；能容纳多种内容类型。难以分析；需高级工具；组织度低。

在数据集成中处理不同数据结构

集成多源数据时，必须考虑所涉数据结构类型。以下是针对各类型的处理指南：

  • 结构化数据：组织良好、可检索性强，可采用传统 ETL（抽取-转换-加载） 流程：从源系统抽取，按目标格式转化，再装载到数据仓库或目标系统。需注意模式维护：一旦 schema 变化，成本与耗时都会较高。
  • 半结构化数据：常需结合 ETL 与 ELT（抽取-加载-转换） 。因为其多样且更复杂，通常先抽取并加载到合适的存储（如数据湖），再按分析需要进行转换。可使用 Apache NiFi、Apache Kafka 等工具管理半结构化数据集成。
  • 非结构化数据：需要更高级的技术（如机器学习、NLP、计算机视觉）。通常需预处理，提取有价值的信息并转为更结构化的形式，再与其他数据源集成。可用 Apache Tika、OpenCV、TensorFlow 等工具处理。

真实用例

  • 结构化数据：某电商将客户购买数据存于关系型数据库，便于分析与洞察，开展定向营销与商品推荐。
  • 半结构化数据：医疗机构从多来源（EHR、医疗设备）采集患者数据，使用 JSON/XML 存入数据湖，供后续分析。
  • 非结构化数据：媒体公司分析社交帖子、文章与多媒体内容，识别与产品相关的趋势与情绪；需用高级技术从非结构化数据中提炼洞察。

小结：理解三类数据结构的差异及其对集成策略的影响，有助于选择合适的技术与工具，支撑数据驱动决策，释放数据价值。

接下来，我们将讨论数据格式。

走近数据格式：CSV、JSON、XML 等

数据格式决定了数据如何存储、传输与处理，是数据集成成功与否的关键。掌握主流扁平数据格式（如 CSV、JSON、XML）的特点与取舍，有助于系统与应用之间顺畅对接，实现准确高效的数据交换。为便于对比，以下示例将围绕“用户信息明细”的同一数据集展开。

CSV

CSV 是一种简单且广泛使用的表格数据存储与交换格式。其最早可追溯到计算机发展的早期：有文献记载 1972 年在 Fortran 66 中已出现。凭借简单、可读性强、跨平台支持广，CSV 成为应用、数据库与编程语言之间交换数据的常用选择。

CSV 通常用于以表格形式存储与交换数据——每行是一条记录，每列对应一个字段/属性。它是纯文本文件，便于人读、易于程序生成与处理，常见于数据库、表格软件与分析工具之间的数据导出/导入。

虽然 CSV 并无“官方标准”，但也有若干规范可参考：

  • IETF RFC 4180（2005） 给出了一般性的 CSV 定义；
  • ISO/IEC 27025:2019 则对 CSV 与其他分隔符格式在数据交换中的最佳实践作了规定。

CSV 相对 JSON/XML 的优势：

  • 简单易用：容易阅读与创建，适合存储/交换结构化表格数据。
  • 兼容性强：几乎所有表格软件、数据库与编程语言都支持。
  • 体积紧凑：通常比等价的 JSON/XML 文件更小，存储与传输更高效。

CSV 的不足：

  • 不支持复杂结构：仅适合表格；难以表示层级/嵌套结构（JSON/XML 更擅长）。
  • 无统一模式声明：缺乏标准化的结构/类型/关系定义，验证与准确解读较困难。
  • 字符编码受限：不原生支持 Unicode，处理非 ASCII 或国际化数据时可能遇到问题。

结论：CSV 非常适合简单表格数据的存储与交换；若需表达层级结构、携带模式信息或更好的国际化支持，JSON/XML 往往更合适。

示例：以 CSV 表示用户信息

id,lastName,firstName,age,email,street,city,country,type,number
123456,Doe,John,30,johndoe@example.com,123 Main Street,Cityville,Countryville,mobile,1234567890
123456,Doe,John,30,johndoe@example.com,123 Main Street,Cityville,Countryville,work,0987654321

在该示例中，每一行是一条用户记录，字段以逗号分隔。与前文 JSON 示例相同，其字段含义为：

  • id, lastName, firstName, age, email：用户属性；
  • street, city, country：地址属性；
  • type, number：电话号码属性。

CSV 常用于在电子表格与数据库之间存储/交换表格数据：每行表示一条记录，每列对应记录中的一个具体取值。

JSON：一种多用途的数据交换格式

JSON 是一种轻量级的数据交换格式，因其简单、可读、易用而在软件行业被广泛采用。JSON 由 Douglas Crockford 在 2000 年代初提出，作为比 XML 更易读的人类友好型替代方案。它是与语言无关的文本格式，但采用了 C 系家族语言程序员熟悉的约定（如 C、C++、C#、Java、JavaScript、Perl、Python 等）。

JSON 被广泛用于数据存储、客户端与服务端之间的数据交换以及配置文件。由于体积小、与 JavaScript（最常用的 Web 开发语言）天然兼容，JSON 已成为 Web 服务与 API 的事实标准。

JSON 受多项标准规范约束，包括 IETF RFC 8259、ECMA-404 和 ISO/IEC 21778:2017。这些标准定义了 JSON 的语法，确保不同编程语言与平台之间的互操作性。

优势：

  • 可读性强：便于开发者阅读与编写。
  • 轻量：比 XML 更小，传输与解析更快。
  • 与语言无关：几乎所有现代语言均支持，便于跨系统交换数据。
  • 原生 JS 支持：在 JavaScript 中处理极其方便，是 Web 应用与 API 的首选格式。

劣势：

  • 数据类型有限：仅支持字符串、数字、布尔、对象与数组等有限类型。
  • 缺乏原生模式校验：不像 XML 有 XSD 等机制，结构校验需借助外部方案。
  • 元数据支持有限：不支持命名空间等元数据，部分场景需要额外处理。

与 CSV 的对比：

  • 层级结构：JSON 可表达复杂的嵌套结构；CSV 仅限表格型数据。
  • 自描述性：JSON 内含字段名，便于理解结构，无需额外文档。

与 XML 的对比：

  • 更简洁：语法更直观，读写更容易。
  • 性能更佳：通常更紧凑、解析更快，数据交换性能更好。

示例：用 JSON 表示用户信息

{
  "id": 123456,
  "lastName": "Doe",
  "firstName": "John",
  "age": 30,
  "email": "johndoe@example.com",
  "address": {
    "street": "123 Main Street",
    "city": "Cityville",
    "country": "Countryville"
  },
  "phones": [
    { "type": "mobile", "number": "1234567890" },
    { "type": "work", "number": "0987654321" }
  ]
}

上述对象包含如下属性：

  • id：用户唯一标识（整数）
  • lastName/firstName：姓/名（字符串）
  • age：年龄（整数）
  • email：邮箱（字符串）
  • address：嵌套对象，含 street、city、country
  • phones：电话号码数组，每项包含 type 与 number

小结：JSON 以其简洁的人类可读语法与出色的 Web 兼容性，成为现代软件开发中通用的数据交换格式。尽管在模式校验与元数据方面存在不足，但其优势使其适用于大量场景。

XML

XML 是一种灵活的标记语言，用于存储与传输数据。它由 W3C 于 1996 年提出，作为当时以展示为主的 HTML 的更灵活进化形态。XML 允许用户自定义标签与结构，可表达复杂数据，因而被广泛用于多种应用。

历史：XML 源自 SGML（标准通用标记语言），旨在在保留灵活可扩展性的同时，简化 SGML 的复杂度。凭借对复杂文档与层级数据的良好表达能力，XML 成为跨应用与平台的数据交换常用格式。

用途：广泛用于Web 服务、文档存储、配置文件及跨应用数据交换。其对层级与复杂模型的良好支持，使其能通过自定义模式（Schema）精确定义结构与语义，提升交换的准确性与一致性。

规范：XML 由 W3C 的一系列国际标准规范（如 XML 1.0/1.1 等）所治理，这些规范定义了语法、解析与校验机制；此外也有相关 ISO 标准（如 ISO/IEC 19510:2013 等）在特定行业/场景给出指南。

优势：

  • 灵活度高：可自定义标签/属性，表达复杂结构与关系。
  • 可扩展性强：易于加入新元素或属性，适应演进中的模型。
  • 标准化完善：工具链与国际标准齐备，跨平台处理一致。
  • 可读：文本格式，便于人工理解。

劣势：

  • 冗长：语法较冗余，文件更大、处理开销更高。
  • 复杂：灵活与扩展性带来学习与使用门槛，相比 CSV/JSON 更难上手。
  • 性能：解析通常慢于 CSV/JSON，尤其在大体量/高频交换场景。

示例：用 XML 表示用户信息

<user>
  <id>123456</id>
  <lastName>Doe</lastName>
  <firstName>John</firstName>
  <age>30</age>
  <email>johndoe@example.com</email>
  <address>
    <street>123 Main Street</street>
    <city>Cityville</city>
    <country>Countryville</country>
  </address>
  <phones>
    <phone>
      <type>mobile</type>
      <number>1234567890</number>
    </phone>
    <phone>
      <type>work</type>
      <number>0987654321</number>
    </phone>
  </phones>
</user>

主要标签说明：

  • <user>：根元素
  • <id>…</id>、<lastName>…</lastName> 等：基本属性
  • <address>：地址信息（含 street/city/country）
  • <phones>：电话号码集合；每个 <phone> 含 type/number

小结：XML 能力强、标准体系完善，适合表达复杂结构与在特定协议/旧系统中交换数据；与更轻量的 CSV/JSON 相比，代价是体积与复杂度更高。

其他数据格式

除 CSV、JSON、XML 外，还有多种常见格式，各有优劣与适用场景：

  • YAML（YAML Ain’t Markup Language） ：人类可读的序列化格式，常用于配置与跨语言数据交换。与 JSON 类似，但用缩进与更简洁的符号表示结构，更直观易写。
  • Protocol Buffers（Protobuf） ：Google 开发的二进制序列化格式，消息小、解析快，需预先定义模式。适合服务间通信与结构化数据持久化。
  • MessagePack：二进制序列化格式，相比 JSON 更紧凑、编解码更快，适合高性能场景与大规模数据处理。
  • Avro：Apache 出品的二进制序列化格式，支持模式演进，广泛用于大数据与流式场景，高效且版本兼容性好。
  • Thrift：Apache 的跨语言通信与序列化协议，可在一种与语言无关的 IDL 中定义数据结构与服务，再生成多语言代码，适用于大规模、跨语言系统集成。

YAML 示例：用户信息

id: 123456
lastName: Doe
firstName: John
age: 30
email: johndoe@example.com
address:
 street: 123 Main Street
 city: City
 country: Country
 phones:
  -type: mobile
    number: "1234567890"
  -type: work
    number: "0987654321"

说明：

  • id, lastName, firstName, age, email：顶层键，表示用户属性
  • address：地址对象，含 street/city/country
  • phones：电话号码列表；- 表示列表项，每项含 type/number
  • YAML 常用于配置与自动化/配置管理工具中的数据表达，便于人工读写

提示：上述各格式应按性能、可读性、灵活性与兼容性等需求权衡选择：

  • 面向人读与配置：YAML / JSON
  • 面向高性能与强模式：Protobuf / Avro / Thrift / MessagePack
  • 面向复杂结构与标准协议：XML
  • 面向简单表格交换：CSV

总结

本章围绕数据源在运营与分析中的关键作用展开，强调为合适的人在合适时间提供准确、及时、可靠的信息。我们介绍了关系型数据库、NoSQL、扁平文件与 API 等多类数据源，并结合其特性与适用场景进行评估。

随后，我们探讨了多种数据类型与结构，以便更高效地处理数据并据其特性调整策略。接着，系统比较了 CSV、JSON、XML 等常见数据格式，说明其各自的表示方式、优劣与适用场景，帮助你在具体情境下做出明智的格式选择。

此外，我们也简要触及列式数据格式在分析型场景中的优势与挑战，并指出格式选择对性能、兼容与复杂度的影响。
这些内容为下一章做了铺垫：我们将进一步深入列式数据格式，详述其在分析负载中的收益与权衡，并继续探讨格式选择对系统表现与实现复杂度的实际影响，助你为特定的数据集成任务作出更优决策。

avatar
文章
阅读
粉丝