在企业数据建设的征程中，一个残酷的现实是：拥有同样一套先进技术组件的两家企业，其数据中台的成效可能天差地别。其分野往往不在于技术本身，而在于驱动技术被正确使用的方法论。一个完整的数据中台，除了全链路的工具覆盖，还必须伴有一套成熟、可落地的建设与运营方法论。这是确保中台从一项昂贵的“技术项目”，成功跃...

在生物学的宏大叙事中，基因是构建生命、决定性状、传承遗传信息的核心蓝图。它决定了生命的健康、演化与关联。当我们审视企业的数据宇宙时，会发现其中同样存在一种名为 “元数据” 的基因序列。它定义了数据的含义、脉络与关系，从根本上决定了企业数据的健康度与价值潜力。然而，大多数企业的数据基因正处在一种自然...

本文将详细介绍五种重要的数据格式： •CSV •JSON •Parquet •Avro •ORC 在大数据时代，数据源之间的数据迁移和存储需要更具策略性的方法。如果没有优化的决策，通过 ETL 流程处理 TB 级数据可能会耗费大量时间和成本。本地部署系统虽然相对容易发现问题，但其基础设施不会自动适应新的情况，问题必须手动解决。 然而，在云端，资源可以自动扩展。虽然我们可能认为一切运行顺畅，但一些被忽略的小步骤却可能导致数万元的不必要成本。在我看来，根据项目需求选择合适的数据格式是大数据时代最关键的决策之一。 存储在 S3 中的物联网数据应该采用 CSV 格式还是 Parquet 格式？每周销售报告文件的最佳格式是什么？大小文件是否应该使用相同的格式？只有充分了解每种数据格式的特性，才能有效地做出这些决策。 近年来，某些格式——尤其是 Parquet 和 Avro——越来越受欢迎。尽管它们存在一些缺点，但它们的灵活性，尤其是在云环境中，极大地促进了它们的应用。在本文中，我将解释这些格式的特性、优势和劣势，并讨论哪种格式最适合特定场景。 一 CSV CSV是一种基于文本的表格数据格式，其中每一行代表一条记录。记录中的列或字段通常用分隔符（最常见的是逗号）分隔。第一行通常包含列名作为标题。CSV 格式被广泛支持，因此成为数据交换的热门选择。 1.编码 CSV 文件通常采用UTF-8编码，这样可以确保字符兼容性并使文件可压缩。 2.优势 •易于阅读： CSV 文件易于阅读和理解。 •通用性强： 几乎所有编程语言和工具都支持它。 •易于使用：可以手动生成、编辑和检查。 •兼容性：与电子表格和临时分析工具兼容。 3.缺点 •我认为，这种格式最大的缺点之一是它不存储元数据，不强制执行模式或数据类型，并且默认情况下将所有数据都视为文本。（例如，当使用其他工具读取 CSV 文件时，包含年龄等数值的列可能会被解释为整数，但这完全是一种解释，可能不正确，需要手动验证。否则，错误在所难免。） •由于其体积庞大且 I/O 速度慢，因此对于大型数据集来说效率低下。与 Parquet 格式相比，根据具体情况，它可能占用大约 10 倍的空间。 •CSV格式不适用于嵌套数据，这是由于CSV格式本身的设计缺陷造成的。例如，在更适合嵌套数据的格式（例如JSON）中，嵌套结构如下所示： { "user" : { "id" : 123 , "name" : "Alice" } , "actions" : [ { "type" : "click" , "time" : "2025-11-05T12:00Z" } ] } 相同的 CSV 数据必须以 JSON 字符串的形式表示在单个单元格中： user_id,user_name,actions 123,Alice,"[{""type"":""click"",""time"":""2025-11-05T12:00Z""}]""[{" "type" ":" "click" "," "time" ":" "2025-11-05T12:00Z" "}]" 这使得阅读、筛选和分析变得更加困难。 4.何时选择 CSV 格式 •适用于对人类可读性要求较高的中小型数据集。 •应用程序、分析师或团队之间轻松共享数据。 •不支持二进制或列式格式的系统或工具。 •快速原型制作或从电子表格（Excel、Google Sheets）导出。 二 JSON 多年来，JSON 一直是最流行的数据格式之一。它可以被视为一种通用语言，使不同的应用程序能够相互理解。其主要目的是促进 Web 服务和应用程序之间的数据交换。在 JSON 出现之前，XML 曾被广泛用于此目的，但它存在诸多缺陷。 XML格式非常冗长，难以阅读，尤其是在处理冗长且嵌套结构的情况下。它占用大量存储空间，解析XML文件会消耗大量的CPU和内存资源，因此不适合处理大数据。此外，XML的兼容性也有限，通常需要专门的库才能解析。 一个简单的 XML 结构示例： <user> <id> 1 </id> <name> Alice </name> <is_active> true </is_active> <address> <city> Berlin </city> <postal_code> 10115 </postal_code> </address> <hobbies> <hobby> music </hobby> <hobby> cycling </hobby> </hobbies> </user> JSON 随后应运而生，它是一种更简洁、更紧凑、人机可读且通用兼容的格式，极大地简化了跨语言数据交换。JSON以文本格式存储键值对数据。它支持嵌套和层级结构，能够自然地表示复杂且深度嵌套的数据。其通用性使其被广泛用于 API 数据传输和配置文件。 一个简单的JSON结构示例： { "id" : 1 , "name" : "Alice" , "is_active" : true , "address" : { "city" : "Berlin" , "postal_code" : "10115" } , "hobbies" : [ "music" , "cycling" ] } 1.编码 UTF-8 通常被使用，因为它既兼容 ASCII，又支持国际字符。由于采用了 UTF-8 编码，JSON 文件可以在不同的平台上无缝共享。 2.优势 •人类可读： JSON 文件是基于文本的，易于人类阅读。 •支持嵌套数据：可以自然地表示复杂和分层的数据结构。 •通用互操作性：几乎所有现代编程语言都支持。 •无模式灵活性：每条记录可以有不同的字段；不需要严格的模式。 •API友好： REST和GraphQL服务的标准格式。 3.缺点 •存储效率低下：每个记录中都重复出现键，这会增加大型数据集的大小。虽然它适用于消息传递，但并不适合大规模存储。 •不强制类型：数字、布尔值或空值均被视为文本；正确的类型由应用程序自行决定。这种缺乏强制的做法可能是一个缺点，尤其是在 ETL 流程中，新数据可能需要持续关注以避免类型错误。 •解析成本：与二进制格式相比，CPU 和 RAM 使用率更高，尤其是对于大文件而言。 •无元数据： JSON 中不包含最小值、最大值或空计数等信息。 •大文件处理：大文件需要流式传输或分块传输；一次性将整个文件加载到内存中是不切实际的。 4.何时选择 JSON •API 数据交换（REST/GraphQL）： JSON 非常适合在不同系统和编程语言之间传输数据。它为 Web 服务、微服务和移动应用程序提供了一种标准、快速且易于解析的格式。 •适用于快速原型设计和共享的中小型数据集：虽然 JSON 不是存储大型数据的最佳选择，但对于中小型数据集来说效果很好。 •人的可读性很重要：与 XML 或二进制格式相比，其基于文本的键值结构使得错误和缺失字段更容易识别和调试。 •嵌套和分层数据： JSON 自然地支持嵌套对象和数组，可以轻松地以清晰有序的方式表示复杂的结构，例如包含地址和订单的用户对象。 三 Parquet Parquet 是当今最流行的数据格式之一，专为Apache Hadoop 生态系统中的大数据分析而设计。它的主要目标是在高效存储大型数据集的同时，优化查询和分析性能。其最重要的特性是列式结构，这显著提升了查询和存储性能。从很多方面来看，Parquet 都可以被视为大数据时代的主流。 Parquet文件的结构 Parquet文件由三个主要层组成： Parquet 文件 •行组： Parquet 文件的一部分（例如，100 万行一组）。 •列块：行组中特定列的数据(e.g., user_id, age, country)。 💡注意：每一列（例如，country）并没有存储在整个文件的单个连续块中，而是作为每个行组中的单独列块存储。 行组允许并行读取和基于行的过滤（谓词下推），从而只读取必要的行块，降低 I/O 成本并提高读取性能。 1.编码 Parquet 格式以二进制列式结构存储数据。虽然 Parquet 中的文本数据可能使用 UTF-8 编码，但其效率并非源于编码本身，而是源于其他特性，我们将在下文讨论这些特性。 2.优势 （1）列式结构 采用列式结构可以显著提高 Parquet 格式的效率。其最大的优势在于，在大型查询中，系统只会读取所需的列，而忽略不必要的列。这不仅提高了I/O 性能，还降低了成本。 对基于行的格式（例如 CSV）和基于列的格式（例如 Parquet）的数据进行查询的方式如下： （2）基于行的查询（CSV） 在 CSV 文件中，所有行都以文本形式存储： 1，爱丽丝，30，美国，100 2，鲍勃，25，美国，200 3，卡罗尔，40，德国，150 4，戴夫，35，德国，300 5，伊芙，28，美国，250 查询： “美国客户总消费额”→ 仅需要列country和spend 因为 CSV 是基于行的，所以会读取和解析所有行，包括id、name、age。 I/O 成本： 5 行 × 5 列（读取整个文件）。 （3）列式查询（Parquet） 在 Parquet 格式中，列存储在单独的块中： 列ID：1、2、3、4、5 ； 列名称：Alice、Bob、Carol 、Dave 、Eve； 列年龄：30、25、40、35、28 ； 列国家/地区： US 、US、DE 、DE、US ； 列消费金额：100、200、150、300、250 •查询： “美国客户总支出”→ 仅读取country和spend列块。 •id、name 和 age 不会从磁盘读取，从而降低了 I/O 和 CPU 开销。 •列式格式结合字典编码、游程编码（RLE）和位打包（bit-packing）可减小文件体积并加速读取。 格式 ｜ 读取的数据 ｜I/O -----｜-------------｜------ CSV（行式）｜所有行 + 所有列｜高 Parquet（列式）｜仅 country 和 spend 的数据块｜低 （4）行组 行分组不仅按列划分数据，还按行划分数据，具体如下： •提高I/O 性能 •减少过多的随机磁盘访问 例如：一个文件有 3 个行组，每个行组有 50 万行： 如果我们只查询 ` idA` 和 ` ageB`，就不会访问 `C` name、country`D` 和 `D`salary中的 450 万行数据，从而节省大量资源。行组也可以并行读取，进一步提升性能。 如果我们需要的数据只在一个行组中，则跳过其他行组，从而节省高达 80-90% 的 I/O。 （5）字典编码 Parquet 的另一个效率提升之处在于字典编码。重复值存储在字典中，并通过索引进行引用，从而减少了高度重复数据的存储空间。 例子： 列：[美国, 美国, 德国,美国,德国, … ] 字典：{ 0 :美国, 1:德国} 编码列： [ 0 , 0 , 1 , 0 , 1 , … ] 如果我们有 10K 行：6K United States+ 4K Germany，我们存储索引而不是完整的字符串，最多可以节省约 90% 的空间。 原始文本（CSV）： 6,000 × 13 = 78,000字节4,000 × 7 = 28,000字节总计：106,000字节≈ 103.5 KB字典编码（Parquet ） 10,000行→ 2个类别→每行1字节（或至少1位）总编码：10,000字节≈ 9.8 KB （6）游程编码（RLE） RLE 对连续重复的值进行数值计数： 列： [ 0 , 0 , 0 , 1 , 1 , 2 , 2 , 2 , 2 ] RLE： [ (0 , 3 ) , (1 , 2 ) , (2 , 4 ) ] # 前三个值为 0 等 •数值使用最少位数。 例如：值为 0-3 的列只需要2 位而不是 32 位。（7）模式强制执行与元数据 Parquet 文件包含有关文件及其数据类型的元数据。 元数据存储模式和数据类型，以便下游消费者可以信任数据类型，而无需重新定义模式或依赖自动检测（自动检测容易出错）。 元数据还包括 Parquet 版本、创建者、写入工具（Spark、Pandas 等）、列最小值/最大值（启用谓词下推）、空值计数和值计数。 3.缺点 Parquet 格式不具备可读性：它是一种二进制格式；直接读取它只会显示原始二进制数据。需要使用专门的工具（例如 PyArrow、Pandas、Spark、DuckDB）来检查或处理数据。 小型数据集的写入开销：元数据、编码信息和字典表会使 Parquet 文件比小型 CSV 文件大得多。例如，一个包含几百行的 CSV 文件可能只有 10 KB，而相同数据的 Parquet 文件则可能需要 100 KB。 兼容性问题：并非所有系统或轻量级工具都直接支持 Parquet 格式，包括： •遗留系统 •基本电子表格或商业智能工具 •小型嵌入式或基于脚本的解决方案 •通常需要中间库（例如 Pandas、PyArrow、Spark）才能读取。 4.何时选择Parquet •大规模分析和大数据查询： Parquet 格式非常适合拥有数百万甚至数十亿行数据的数据集，尤其适用于对查询性能和 I/O 效率要求极高的情况。其列式结构允许仅读取必要的列，从而减少磁盘和内存使用量。 •嵌套或复杂的数据结构： Parquet 支持结构体、数组和映射等复杂数据类型，使其适用于分层或半结构化数据，而这些数据在 CSV 等基于行的格式中会显得很繁琐。 •云存储和成本效益：在云环境中，仅读取所需列可降低 I/O 和计算成本。Parquet 的压缩和编码特性可进一步减少存储占用。 •ETL管道和分析框架： Parquet可与Spark、Hive、Presto和DuckDB等大数据工具无缝集成。当数据将被多个下游分析系统使用时，它堪称完美之选。 •基于列值过滤场景：当查询涉及基于列值进行过滤时（例如，WHERE country = 'US'），Parquet 的行组和元数据允许跳过不相关的数据块，从而大幅提高查询速度。四 Avro Apache Avro 是 Apache Hadoop 生态系统中最古老、最成熟的数据格式之一。它由 Hadoop 的创建者 Doug Cutting 开发。其主要目的是解决数据可移植性和模式定义方面的不足。Avro基于行，与早期格式不同的是，它采用二进制而非文本格式。这使其更高效、更快速、更节省空间。 例如，考虑一个 10 位数： 1234567890 •在 CSV 或 JSON 格式中，每个数字都存储为一个字符（每个数字占用 1 个字节）： '1' → 00110001 '2' → 00110010 ... '0' → 00110000 •总计：10 字节。解析需要将每个字符转换回整数。 •在像 Avro 这样的二进制格式中，该数字以 int32（4 字节）形式存储，节省了约 6 个字节，并且允许直接内存访问而无需解析，从而显著提升了速度。 Avro 也像 Parquet 一样提供模式强制执行，这意味着模式存储在文件元数据中。 1.文件结构 Avro 文件由三个主要部分组成： Avro 文件 •头部：包含描述数据结构的“魔数”和模式定义（JSON 格式）。 •数据块：以压缩二进制形式存储实际数据。数据块支持并行处理；程序可以跳过不需要的数据块以加快访问速度。 •同步标记：充当断点，帮助在文件损坏时恢复数据。 编码 •Avro 以二进制格式存储数据，比 JSON 或 CSV 格式小得多。 •无需进行文本解析，因此CPU 使用率低。 2.优势 •模式演化与类型强制执行 •该模式嵌入在文件中，确保类型安全和向前/向后兼容性。 向后兼容性示例： 旧模式： { "type" : "record" , "name" : "User" , "fields" : [ { "name" : "id" , "type" : "int" } , { "name" : "name" , "type" : "string" } ] } 旧数据（二进制表示，以 JSON 格式显示）： { "id" : 1 , "name" : "Alice" } { "id" : 2 , "name" : "Bob" } 新增模式，添加了字段（is_active）及其默认值true： { "type" : "record" , "name" : "User" , "fields" : [ { "name" : "id" , "type" : "int" } , { "name" : "name" , "type" : "string" } , { "name" : "is_active" , "type" : "boolean" , "default" : true } ] } 使用新模式读取旧文件会产生以下结果： { "id" : 1 , "name" : "Alice" , "is_active" : true } { "id" : 2 , "name" : "Bob" , "is_active" : true } •旧数据不包含新字段，但Avro 会使用默认值填充该字段，从而确保向后兼容性。向前兼容性则以相反的方向实现。 紧凑二进制格式 •比文本格式小得多（大约是 JSON 大小的 10-20%），但比 Parquet 大。 快速序列化和反序列化 •序列化和反序列化数据时 CPU 使用率极低，使其成为Kafka、Flink 和 Spark Streaming 等实时系统的理想选择。 与语言无关 •模式在 JSON 中定义，数据是二进制的 → 可以轻松地在 Python、Java、Go、C++、Scala 等中使用。 非常适合流媒体播放 •基于行的结构意味着每个记录都是独立的，非常适合基于事件的处理（Kafka 主题、消息传递系统）。 3.缺点 人类无法阅读 二进制格式无法直接读取；需要 PyArrow、Avro 工具或 Spark 等工具进行检查。 基于行的结构 SELECT AVG(price)对于分析查询（例如，在大数据集上），列式格式（Parquet/ORC）效率较低。 读取模式所需 没有模式就无法读取数据。模式必须嵌入在文件中或可从外部获取。 压缩技术不如Parquet/ORC先进 行式存储限制了压缩效率；列式格式可以实现更好的存储空间缩减。 4.何时选择 Avro 流式传输和消息传递系统： Kafka、Flink、Pulsar 等，其中事件需要快速序列化。 模式管理和向后兼容性：跨版本自动模式演化。 类型安全：与 JSON 不同，Avro 强制执行数据类型。 适度的存储优化：比文本格式小，但不需要列式压缩。 高频 ETL 和微服务：适用于服务间数据流密集的系统。 五 ORC（优化行列式） ORC 是一种专为 Hadoop 生态系统开发的高性能列式二进制数据格式。它专为分析海量数据而设计，因此具有很高的查询效率和压缩率。它也像 Parquet 一样具有模式强制执行功能。 1.文件结构 ORC 文件包含三个主要部分： Postscript：数据以大块形式存储，每列都是独立的。也就是说，一个条带包含一组行的逐列数据。 Footer：包含所有架构、统计信息和条带位置。 Stripes：提供有关压缩、文件格式版本和页脚长度的信息。 下面我们通过一个例子来更清楚地理解这三个部分； 假设我们有一个客户表； ORC 文件 2.编码方法 ORC 的编码方式与 Parquet 非常相似；我们在此不再赘述。您可以在上面的 Parquet 部分阅读相关内容。不过，我们可以大致讨论三种基本方法； 字典编码：对于重复值，创建一个字典，并存储字典中的索引而不是数据本身。 游程编码（RLE）：连续相同的值用一个值及其重复次数表示。 位打包：对于数值，使用最少的位数，例如，对于 0 到 3 之间的值，只需 2 位就足够了。 3.优势 •高压缩比： ORC 具有很高的压缩比。这主要是因为数据是按列存储的，并且相似的数据是连续存储的。我们在 Parquet 部分已经提到过这一点，并指出这种方法称为游程编码 (Run-Length Encoding)。 •模式强制执行：与 Parquet 格式一样，ORC 也具有模式强制执行机制。我们前面已经讨论过它的重要性。 •快速分析： ORC 与 Parquet 类似，仅在需要时才访问数据，从而显著提升读取性能。更多详细信息，请参阅 Parquet 部分。 4.缺点 ORC的缺点与Parquet的缺点非常相似；简而言之，这些缺点包括： •不可读：由于 ORC 是二进制格式，因此无法浏览或读取。 •基于行的更新很困难：它专为追加或批量分析而设计，而非事务性的行级更新。它更侧重于分析，因此不适合行级更新。这是因为数据以列为单位存储在较大的数据块（条带或行组）中；更改单行需要重写所有相关的列数据块。 •小数据集的元数据开销：对于非常小的表，元数据和条带开销可能会使 ORC 比 CSV 或 Avro 更大。 •工具依赖性：某些轻量级工具或旧系统可能不支持 ORC 原生支持。 5.何时选择 ORC •对大型数据集进行分析查询： ORC 在读取密集型分析工作负载（如 Hive 或 Spark 中的聚合、过滤和连接）中表现出色。 •需要高压缩率：重复性或低基数数据集可受益于 ORC 的列式压缩。 •Hadoop 生态系统集成：与 Hive、Spark、Presto、Impala 或 HDFS/S3 存储配合使用时非常理想。 •谓词下推/更快的过滤： ORC 的条带级元数据可以高效地跳过不必要的数据。 •具有批量追加功能的稳定模式：非常适合追加密集型管道，但不太适合事务性行更新。 6.Parquet 与 ORC区别 这两种文件类型都是二进制、列式存储，并且在许多方面都使用非常相似的方法。然而，它们在某些方面也存在差异。首先，ORC 格式的优化更为激进。因此，在某些情况下，ORC 格式可以获得更好的压缩效果，并且由于其元数据更详细、更全面，因此也能提供更好的读取性能。 我们将在平台上使用的工具也很重要。ORC 主要面向 Hive 和 Hadoop，因此在这里速度可能更快；而 Parquet 在云端和异构系统中表现更佳，具有更强的平台兼容性和通用性。虽然这两种工具通常都适用于批量分析，但使用 ORC 添加少量数据或进行基于行的数据更改效率较低。Parquet 在这方面则更加灵活，可以根据具体情况用于此类操作。让我们简要比较一下这两种工具： 今天，我们介绍了大数据生态系统中的关键数据格式：CSV、JSON、Parquet、Avro 和 ORC。我们分析了它们的主要特性、优势、劣势以及各自最适用的场景，包括存储、性能、模式强制执行、压缩和兼容性等方面的考量。您可以在下方找到总结表。 来源（公众号）：数据驱动智能

在数字经济时代，数据已成为企业的核心资产，然而如何让数据真正产生价值，却始终是困扰企业的难题。传统的数据使用流程复杂冗长，业务人员需要经过申请资源、技术取数、人工加工、报表开发等多个环节，整个过程耗时数天甚至数月。这种低效的用数模式严重制约了企业的决策速度和业务创新能力。随着人工智能技术的快速发展，...

数据中台作为企业数字基建的核心，承担着整合数据资源、提升数据质量、赋能业务创新的关键使命。当前企业数据环境日趋复杂，多源异构数据并存，传统烟囱式数据管理难以满足实时决策与业务敏捷响应需求。数据中台通过统一的数据治理体系和标准化服务能力，将数据转化为可复用资产，支撑企业从信息化向数智化转型，成为数字化...

在当今数字化浪潮席卷全球的背景下，数据已成为企业核心资产之一，而数据中台作为数据驱动业务的核心基础设施，其选型工作直接关系到企业能否高效利用数据、提升决策水平并实现创新突破。数据中台不仅是一个技术平台，更是一种组织架构和业务模式的变革，它通过整合、治理和分析数据，赋能企业从数据中挖掘价值。因此，在选...

数据中台的选型评估需要建立系统化的理论框架，技术前瞻性、落地能力与服务支持构成三维评估体系。技术前瞻性衡量平台架构的先进性与可持续演进能力；落地能力评估产品功能与企业实际需求的匹配度，强调可实施性与效果验证；服务支持考察厂商的持续赋能体系，包括知识传递与运营保障。这三者相互关联，共同决定数据中台建设...

在数字经济时代，数据已成为企业的核心战略资产。然而，随着数据量的爆发式增长和数据源的多样化，企业面临着数据质量参差不齐、数据交换共享困难、数据安全风险加剧等严峻挑战。构建完善的数据治理体系，不仅关乎数据价值的有效释放，更直接影响企业的数字化转型成效和核心竞争力。 数据治理的理论基础与价值维度 数据治...

在数字经济时代，数据已成为企业的核心战略资产。然而，原始数据往往分散在异构系统中，呈现出碎片化、低质量、难共享的特征。数据集成平台作为打通数据孤岛、构建数据价值链的关键基础设施，正日益成为企业数字化转型的必备工具。一个成熟的数据集成平台，不仅需要实现技术上的连通性，更要构建从接入到共享的完整数据治理...

在大数据时代，数据仓库作为企业数据架构的核心组成部分，其治理水平直接决定着数据分析的准确性和业务决策的有效性。随着数据规模的不断扩大和数据应用的日益复杂，数据仓库治理已成为企业数据管理的重要课题，需要从技术、管理、流程等多个维度系统推进。 数据仓库治理的必要性与挑战 数据仓库治理的核心目标是确保数据...