数据存储

核心原理与架构设计

存储层的重要性与核心挑战

存储层是大数据系统的基础与性能瓶颈所在，其设计直接决定系统能否支撑 PB 级数据处理。设计的最大挑战是"容量-性能-成本的不可能三角"：

• **追求容量** → 成本上升
• **追求性能** → 容量受限
• **控制成本** → 性能或容量受影响

因此，设计需兼顾技术前瞻性，避免未来高成本的架构重构。

存储抽象

数据仓库（Data Warehouse）

数据仓库是面向主题、集成、非易失、随时间变化的数据集合，其本质是通过严格的Schema-on-Write模式，在数据写入时进行ETL处理，确保数据的结构性、一致性和高质量。

核心设计原理

• **架构模式**：采用维度建模（星型/雪花模型），面向分析场景优化
• **数据治理**：通过标准化建模保障数据质量，支持BI报表、财务分析等严格一致性场景
• **存储特点**：列式存储 + MPP架构，优化复杂聚合查询性能
• **适用场景**：BI分析、报表系统、财务风控等要求数据严格一致的业务场景

稳定性知识

数据仓库的核心价值在于数据治理成熟度和高质量数据输出，其设计哲学是"先治理，后使用"。

数据湖（Data Lake）

数据湖是为应对大规模、多类型数据（结构化、半结构化、非结构化）而出现的集中式存储库，其核心思想是Schema-on-Read模式，允许数据以原始形式存储，在读取时进行处理。

核心设计原理

• **存储灵活性**：支持多种数据格式（CSV/JSON/图片/视频等），降低数据接入门槛
• **成本优势**：基于HDFS或对象存储，存储成本显著低于传统存储系统
• **探索型分析**：特别适合机器学习、大模型训练等需要原始数据的探索型场景
• **治理挑战**：缺乏有效治理时易形成"数据沼泽"，导致数据重复、含义不明、血缘不清

风险与挑战

数据湖的主要风险是"数据沼泽"问题，即数据缺乏管理与治理，导致可用性急剧下降。这是数据湖从"数据资产"退化为"数据垃圾场"的根本原因。

湖仓一体（Lakehouse）

湖仓一体是为融合数据仓库治理能力强与数据湖灵活性高的优势而产生的架构模式，其核心思想是通过统一存储、统一元数据和ACID事务保证，实现批流一体、多引擎共享的统一平台。

核心设计原理

• **统一存储基础**：基于对象存储的低成本、高扩展性
• **统一元数据管理**：通过Delta Lake、Iceberg、Hudi等表格式实现元数据一致性
• **ACID事务保障**：支持并发读写，保证数据一致性和可靠性
• **多计算引擎支持**：一份数据可同时用于BI分析、机器学习、实时处理等多种场景

架构演进意义

湖仓一体体现了数据架构从专业化分工向统一平台演进的趋势，代表了数据治理能力逐步完善后对灵活性的更高追求。

架构选型决策框架

1. 业务场景驱动

• **BI报表为主**：优先选择数据仓库
• **探索型分析为主**：优先选择数据湖
• **多场景并存**：考虑湖仓一体

2. 数据治理成熟度

• **无治理体系**：从数据湖开始积累数据资产
• **初步治理体系**：采用数据仓库快速建立规范
• **成熟治理体系**：可考虑湖仓一体化统一管理

3. 成本与复杂度权衡

不同架构的建设与运维成本差异显著，需结合团队技术能力与预算进行综合评估。

4. 企业演进实践案例

案例1：百度的演进路径（数据湖→数据沼泽→湖仓一体）

• 问题：数据无序堆积，多版本、无血缘，上游指标含义不清
• 解决：在湖上构建用户数据仓库，引入统一元数据、调度、血缘管理
• 本质：从数据湖演进到湖仓一体的治理强化

案例2：神策的演进路径（数仓→湖仓一体）

• 做法：从源头实现强治理，所有数据必须符合严格schema才入库
• 演进：基于业务需求（ELT、多模态数据）演进到湖仓一体
• 经验：从源头避免数据沼泽，比后期治理成本更低

核心认知：三种架构不是替代关系而是互补关系，架构选择取决于业务需求、治理水平、成本预算、团队能力，而非技术潮流。

数据平台

提供了可互操作的工具的生态系统，与核心数据存储层紧密结合。

数据湖可以看作是一种开放的数据平台

存储系统

数据库

分布式存储

文件存储

• 本地磁盘
• NAS
• 云文件系统

块存储

• RAID
• SAN
• 云虚拟块存储
• VPS本地实例卷

对象存储

核心特征

• 键值存储：对象存储使用键值对来存储数据对象。
• 不可变性：一旦写入，对象变为不可更改，要修改数据必须重写整个对象。
• 无随机写入或追加操作：对象不支持随机写入或追加操作，只能作为字节流一次性写入。
• 范围请求：支持通过范围请求进行随机读取。
• 无服务器：作为"无服务器"服务，工程师不需要管理底层服务器集群或磁盘。
• 并行流写入和读取：支持在多个磁盘上进行高性能的并行流写入和读取。
• 跨可用区存储：数据通常保存在多个可用区，提高数据的耐用性和可用性。
• 可扩展存储空间：存储空间高度可扩展，几乎无限制。

主要优点

• 简化管理：无需管理底层硬件，工程师可以直接管理和使用存储服务。
• 高可用性和耐用性：数据保存在多个可用区，降低数据丢失的风险。
• 弹性扩展：存储和处理能力可以根据需求灵活扩展，适应大流量和并行处理需求。
• 成本效益：按需付费，避免了提前为硬件做计划的成本，对预算有限的小型组织尤为有利。
• 分离计算和存储：允许使用短暂的计算集群处理数据，进一步优化资源利用。
• 大数据支持：适用于处理大数据，支持大规模并行处理和存储。
• 无限存储：存储空间几乎无限，工程师可以快速存储大量数据，不受物理硬件限制。
• 数据持久性：数据写入后不可更改，确保数据的持久性和完整性。

分布式文件系统

HDFS（Hadoop分布式文件系统）

HDFS是为大数据批处理场景设计的分布式文件系统，特点包括：

• 支持PB级批量处理、顺序写入、扩展性强
• 采用主从架构，NameNode管理元数据，DataNode存储数据块
• 不适合小文件存储（小文件会占用大量NameNode内存）和低延迟访问
• 常用于离线分析、数据湖底层存储

NoSQL存储

主要类型与特点

• **HBase**：基于HDFS的列式存储，支持高并发读写和毫秒级查询
• **MongoDB**：文档数据库，支持半结构化数据和复杂查询
• **Cassandra**：分布式列式存储，具有高可用性和线性扩展能力
• **适用场景**：实时计算、日志存储、用户特征存储等

列式分析数据库

主要特点

• 查询优化、压缩率高、支持并行分析
• 针对OLAP场景优化，支持复杂聚合查询
• 代表产品：ClickHouse、Doris、Kudu等
• 常用于BI分析、指标计算、数据仓库查询层

流式存储

像Apache Kafka这样的分布式、可扩展的流框架现在允许极长的流数据保留。Kafka通过将旧的、不经常访问的消息推送到对象存储中来支持无限期的数据保留

区块链

存储设计的六大考量

1. 可扩展性与成本弹性

架构应支持线性扩容，避免迁移与重构。扩容应为低成本操作，可利用公有云弹性资源。

2. 多样化数据类型支持

• **结构化数据**：列式存储（Parquet、ORC、Kudu）
• **半结构化数据**：文档数据库（MongoDB）、数据湖
• **非结构化数据**：对象存储或分布式文件系统

3. 分层存储策略

数据按访问频率分为：热、温、冷、归档。各层采用不同技术与成本结构，实现总体最优。

4. 数据生命周期管理

自动迁移与清理过期数据，冷数据采用高压缩、低成本存储。

5. 读写模式优化

• **批处理场景**：列式存储 + 分区分桶 + 向量化计算
• **流式场景**：写优化系统（HBase、Kafka、LSM-Tree）
• **交互式查询**：内存计算 + 物化视图 + 预计算

6. 成本与可运维性控制

成本由硬件、软件、运维三部分构成。运维复杂度（如扩容、迁移、故障恢复）是隐性成本的主要来源。安全合规设计需从第一天考虑（加密、权限、审计等）。

主流存储方案对比

设计思想与趋势

数据目录

一个集中存储元数据的平台，用于管理和查询整个组织的数据。它与各种系统集成，跨运营和分析数据源工作，提供数据脉络和关系，并允许用户编辑数据描述。数据目录通常提供一个中央场所，用户可以查看、查询和存储元数据

数据共享

允许组织和个人与特定实体共享特定的数据和精心定义访问权限

模式

数据的预期形式是什么？文件的格式是什么？是结构化的、半结构化的，还是非结构化的？预计有哪些数据类型？数据如何融入一个更大的层次结构？它是否通过共享键或其他关系与其他数据相连？

计算与存储分离

将数据存储系统（如对象存储、数据湖）与计算资源（如虚拟机、容器、数据处理引擎）分离管理和运行。数据存储在一个独立的存储系统中，而计算资源可以根据需要动态分配和释放，处理存储中的数据

数据存储生命周期