数据工程终极设计模式——数据工程中的存储设计模式

引言

在任何数据平台中，存储架构都是一项基础性决策。数据的存储方式决定了它能够被多高效地查询、系统能够多容易地扩展、数据能够多可靠地被治理，以及当 workload 演进时，系统还能保持多强的适应性。随着组织从 transactional systems、applications、devices 和 external sources 中收集数据，存储必须同时与数据结构以及数据的使用方式对齐。

因此，本章将考察现代系统中使用的主要存储范式，包括 relational databases、NoSQL databases、data lakes、data warehouses、lakehouse architectures，以及 time-series 和 graph databases 等 specialized systems。每一种都服务于不同的 workload profile。

Relational databases 面向 structured data 和 transactional consistency 设计，因此适合 OLTP systems，在这些系统中 correctness 和 atomicity 是必须实现的关键优先事项。NoSQL systems 则适用于需要 flexible schemas、horizontal scalability 或 high write throughput 的场景。Data lakes 为 raw 和 semi-structured data 提供可扩展的 object storage，并常常构成 batch analytics 和 Machine Learning（ML）的基础。Data warehouses 针对 structured analytical workloads 进行优化，尤其适合涉及复杂 joins 和 aggregations 的场景。最后，lakehouse architectures 试图将 scalable object storage 与 transactional guarantees 和 analytical performance 统一起来。此外，time-series 和 graph databases 等 specialized systems 针对特定 query patterns 做了优化，而这些 query patterns 往往不是 general-purpose systems 擅长处理的。

存储选择应由 workload characteristics 驱动，而不是由偏好驱动。数据结构、查询的频率和类型、update patterns、consistency requirements，以及预期增长规模，都会影响合适的设计。随着分析需求扩展，系统也可能演进，以支持新的 processing engines、更大的规模，或者 hybrid operational and analytical workloads。

因此，本章提供一个评估 storage architectures 的框架，基于这些约束做出知情决策，在 performance、scalability 和 operational complexity 之间取得平衡。

结构

本章将覆盖以下主题：

• Relational vs. NoSQL Databases
• Data Lake Design Principles
• Data Warehouse Modeling
• Hybrid Storage Solutions
• Time-Series and Graph Databases

Relational vs. NoSQL Databases

当选择 database 时，很容易把它看成一个二元决策：SQL 或 NoSQL、structured 或 flexible、rows 或 documents。然而，真实情况更细致，因为 relational 和 non-relational databases 都同样有价值；它们只是适合不同场景。

Relational Database

Relational databases 通常也被称为 SQL databases，自 20 世纪 70 年代以来就已经存在。它们使用 tables，以及 rows 和 columns，非常适合 structured data。每张 table 都有预定义 schema，tables 之间的关系通过 primary keys 和 foreign keys 执行。

可以把 relational database 想象成一个组织良好的文件柜，其中每个抽屉，也就是 table，都清楚知道自己保存什么类型的文件，也就是 rows。

此外，relational databases 具有以下 keys：

Primary Key：每条 record 在 table 中的唯一标识符，它确保该 column 中不会有两行拥有相同 value。

Foreign Key：通过引用另一张 table 的 primary key，在两张 tables 之间建立 link 的 column，从而建立 relational connection。

例如，假设你正在管理一家金融服务机构的 loan disbursements。你可以有两张 tables，例如：

-- Customer table
CREATE TABLE customers (
customer_id SERIAL PRIMARY KEY,
name VARCHAR(100),
email VARCHAR(100)
);

-- Loan table
CREATE TABLE loans (
loan_id SERIAL PRIMARY KEY,
customer_id INT REFERENCES customers(customer_id),
amount DECIMAL(10, 2),
status VARCHAR(50),
disbursement_date DATE
);

如果你想获取 customer ID 为 1 的所有 loans：

SELECT * FROM loans
WHERE customer_id = 1;

如果你想获取更多 details，可以 join customers 和 loans tables：

SELECT c.name, l.amount, l.status
FROM customers c
JOIN loans l ON c.customer_id = l.customer_id
WHERE c.customer_id = 1;

此外，relational databases 具有以下优势：

Data Integrity：通过 foreign keys 和 constraints 执行。

Complex Querying：使用 SQL 进行 filter、group、join 和 aggregate。

Consistency：ACID transactions 确保强 data integrity 和 reliability，但通常会在 horizontal scalability、operational complexity，以及某些 enterprise systems 中的 licensing costs 方面引入取舍。

Security：包括对 user access 和 data visibility 的细粒度控制。

Non-Relational（NoSQL）Database

Non-relational databases，也就是 NoSQL databases，不依赖 table-and-row format。相反，它们使用 documents、key-value pairs、graphs 或 columns 等灵活结构。这使它们非常适合 data models 经常变化，或者 relationships 对传统 tables 来说过于简单或过于复杂的应用场景。

因此，下面是 NoSQL databases 类型的简要拆解：

Type	Description	Examples
Document Store	存储 JSON-like documents，schema-flexible	MongoDB、CouchDB
Key-Value Store	简单 key-value pairs，提供极快 lookup	Redis、DynamoDB
Column Store	按 columns 存储数据，以加快 analytics	Cassandra、HBase
Graph DB	使用 nodes 和 edges 表示高度连接的数据，例如 social graphs	Neo4j、ArangoDB

表 5.1：Non-Relational Databases 类型

现在，我们用 MongoDB 中的 NoSQL setup 重新审视 loan disbursement 示例：

{
"customer_id": 1,
"name": "Anita Raj",
"email": "anita@example.com",
"loans": [
{
"loan_id": "LN5001",
"amount": 50000,
"status": "active",
"disbursement_date": "2024-09-20"
}
]
}

现在，获取所有 active loans 就很直接，可以这样做：

db.customers.find({ "loans.status": "active" });

注意 loan data 是如何直接嵌套在 customer record 里的？这就是 NoSQL 的“魔法”：更少 joins、更快 reads，以及 flexible schemas。

Databases 没有 one-size-fits-all。这里不是 SQL vs. NoSQL，而是 SQL and NoSQL，取决于你正在处理的具体工作。

因此，理解数据的 structure、access patterns 和 scale 非常重要。一旦做到这一点，合适的 database，无论 relational 还是其他类型，就会变得清晰。

Denormalization 的重要缺点包括：

Denormalized models 可能引入 update anomalies，也就是同一份信息被复制到多个 records 中。因此，当某个 value 发生变化时，它必须在每一个出现的位置都被更新。如果任何一个实例被遗漏，就会导致 data inconsistency。

在 MongoDB 等 document databases 中，大型 denormalized documents 可能接近或超过 document size limits，例如 MongoDB 强制执行 16 MB document limit。因此，在单个 document 中嵌入过多相关数据，可能会造成硬性 storage constraints。

随着 documents 中 nested arrays 增长，query complexity 和 performance 可能下降。对 deeply nested 或非常大的 arrays 进行 filtering、updating 或 indexing 会变得越来越昂贵。大型 arrays 还可能增加 query execution 期间的 memory usage，并使 partial updates 变得复杂。

因此，尽管 denormalization 在某些场景中可以提升 read performance，但必须谨慎平衡 data consistency risks、document growth limits 和 long-term query maintainability。

Data Lake Design Principles

设计 data lake 并不只是选择一个 storage system，然后把数据倒进去。事实上，它是在构建一个 secure、scalable、flexible 且 analytics-ready 的基础，同时还必须能够支持 enterprise-grade workloads、real-time insights，以及长期演进的数据使用场景。

因此，在本节中，我们将结合 design principles、layered architecture，以及 Netflix、Uber 和 Airbnb 等行业领导者的案例，理解成功的 data lakes 实际上是如何被构建和维护的。

此外，为了让你的 data lake 可持续并产生价值，必须围绕以下关键原则进行设计：

Data Governance：定义谁拥有数据、谁可以访问数据，以及如何管理数据质量和隐私。根据 data sensitivity 使用 access control、encryption 和 tagging。

Scalability and Flexibility：Cloud-native object storage，例如 S3、Blob 或 GCS，确保你的 lake 可以随业务增长扩展，同时容纳 structured、semi-structured 和 unstructured data。

Data Ingestion：使用 ETL pipelines 和 Apache Kafka、Fivetran 或 Azure Data Factory 等工具，同时支持 batch 和 real-time ingestion。

Metadata Management：实施 data catalog，帮助用户发现和理解 datasets。AWS Glue Data Catalog、Apache Atlas 或 Amundsen 可以在这里发挥关键作用。

Partitioning and Organization：使用有意义的 folder structures 和 partitions 存储数据，例如按 year、month、region，以提升 performance 和 manageability。

Data Quality and Lineage：使用 profiling、validation 和 transformation tools，确保数据干净可信。使用 OpenLineage、Great Expectations，或 Spark 和 Glue 内置工具追踪 lineage。

Schema-on-Read：通过在 query time 解释 schema 来拥抱灵活性。这能保持 raw data 不被修改，同时支持不同用户进行各种 transformations。

Security and Compliance：对数据进行加密，并且不要忘记使用 fine-grained access policies（IAM）。还要记得 audit 所有 actions，以满足 regulatory compliance，例如 GDPR、HIPAA 等。

Integration with BI and ML Tools：确保 curated datasets 能无缝连接到 Power BI、Tableau、Looker，以及 SageMaker 或 Vertex AI 等 ML platforms。

Data Lifecycle Management：定义每一层数据保留多长时间。将 aged data 移动到 cold storage 或 archive zones，以节省成本。

Self-Service Access：为 analysts 和 data scientists 提供 SQL editors、Jupyter notebooks 或 visualization dashboards 等工具，使他们无需经过瓶颈即可探索数据。

Blueprint of a Modern Data Lake

为了让这些原则落地，可以采用 layered architecture，将 lake 划分为 purpose-specific zones。这种结构支持从 raw data collection 到 refined insights 的完整过程。

Data Ingestion Layer

这是所有数据进入系统的地方。

Technologies：Apache Kafka、AWS Kinesis、Azure Event Hubs、REST APIs 和 ETL tools

Sources：CRM systems、mobile apps、IoT sensors 和 third party APIs

# Example of a Kafka Producer in Python:
from kafka import KafkaProducer

producer = KafkaProducer(bootstrap_servers='localhost:9092')
producer.send('loan_applications', b'{"app_id": 12345, "amount": 50000}')

Raw Data Storage Layer

这是一个成本高效的数据水库，用于以原始形式存储数据。

Storage：Amazon S3、Azure Blob、Google Cloud Storage 和 HDFS

Format：JSON、Avro、Parquet、XML 和 Logs

Folder Layout：

s3://data-lake/raw/loan_applications/2025/04/12/

Data Processing Layer

这是 data lake 的 transformation engine。

Technologies：Apache Spark、Flink、Databricks、AWS Glue 和 Azure Data Factory

Tasks：Cleaning、joining、deduplication 和 enrichment

# Basic Spark Transformation Example:
df = spark.read.json("s3://data-lake/raw/loan_applications/")
df_cleaned = df.filter("amount IS NOT NULL").withColumn("status", lit("pending"))
df_cleaned.write.parquet("s3://data-lake/processed/loan_applications/")

Curated Data Layer

这里存放 analytics-ready datasets，它们经过组织、结构化和优化。

Schema：Hive-compatible tables、Delta Lake、Iceberg

Access：BI tools、data APIs 和 ML platforms

该 zone 中的数据支持 dashboarding、forecasting 和 model training 等功能。

因此，设计 data lake 不只是倾倒数据；它是让数据可发现、可使用并有价值。

因此，通过结合合适的 architectural layers、强 governance 和智能 tooling，你可以将混乱的数据洪流转化为一个优雅、可用的平台，为整个组织赋能。

无论你是一家希望简化 reporting 的中型企业，还是一家管理 PB 级用户交互数据的企业，设计良好的 data lake 都会成为你的 source of truth，因为它支持从 dashboards 到 data science 的各种场景。

Data Warehouse Modeling

组织不仅需要存储信息；它们还需要信任这些信息、快速查询这些信息，并将其转化为洞察。这就是 data warehouse 发挥作用的地方。

Data warehouse 是一个结构化、集中式 repository，其中存放清洗后的、整合后的、business-ready data。这些数据专门为 querying、reporting 和 analytics 构建。它充当企业的 analytical brain，驱动 dashboards、forecasting models、compliance reports 和 executive decisions。

因此，为中型到企业级组织设计 scalable 和 sustainable data warehouse，需要在 structure、performance 和 governance 之间仔细平衡。

Principles of Data Warehouse Design

Data Modeling：Warehouse 的基础

使用 dimensional modeling 简化复杂数据，以便 analytics：

Fact Tables：捕获 quantitative data，例如 sales、revenue、transactions。

Dimension Tables：为 facts 增加 context，例如 time、customer 或 region。

可以在 star schema 和 snowflake schema 之间选择：star schema 更简单、查询更快；snowflake schema 则 normalized 且更节省空间。

Design with Flexibility：预见不断变化的业务需求，并记得允许 schema extensions，而不破坏 reports。

-- Star Schema Example (Sales Fact Joined with Customer and Product Dimensions):
SELECT c.customer_name, p.product_name, f.sales_amount, f.transaction_date
FROM sales_fact f
JOIN customer_dim c ON f.customer_id = c.customer_id
JOIN product_dim p ON f.product_id = p.product_id
WHERE f.transaction_date >= '2025-01-01';

Data Integration and ETL Pipelines

Data warehouse design 中的一个关键步骤，是整合来自多个来源的数据，例如 ERP systems、CRM platforms、web applications、APIs 和 legacy systems。为了实现这一点，组织必须实施稳健的 ETL（Extract、Transform、Load）或 ELT（Extract、Load、Transform）pipelines。这些 pipelines 应该能够在数据加载到 warehouse 之前或之后，对数据进行 cleansing、standardizing、deduplicating 和 enriching。此外，维护 data lineage 并建立 audit trails 对追踪数据来源和监控 integration process 中应用的每一次 transformation 至关重要。因此，构建和编排这些 pipelines 的常用工具包括 Apache Airflow、dbt、Talend、Informatica 和 Fivetran。

Data Governance and Security

建立清晰的 data governance policies，可以确保 data warehouse 以一致性、accountability 和 compliance 的方式运行。因此，为所有 critical datasets 定义 ownership 和 stewardship roles 非常重要。数据应根据 sensitivity 进行分类，并执行合适的 role-based access controls（RBAC）以限制访问。敏感信息必须在 at rest 和 in transit 状态下都被加密。此外，应通过 continuous auditing 和 access monitoring，主动维护对 GDPR、HIPAA 和行业特定 mandates 等监管框架的合规性。

Performance Optimization

为了确保 analytical queries 具备 high performance 和 low latency，data warehouse 应利用 indexing、materialized views 和 columnar storage。按 date 或 region 等 dimensions 对大型 fact tables 进行 partitioning，可以显著提升 query performance。因此，应用 data compression techniques 有助于降低 storage costs，同时也提升 read performance。此外，实施 caching layers 可以进一步加快 frequently accessed data 的响应速度。

Scalability and High Availability

Data warehouse 必须设计为能够 vertical 和 horizontal scale，以适应不断增长的数据量和越来越高的用户并发数。Snowflake、Google BigQuery、Amazon Redshift 和 Azure Synapse 等 cloud-based 和 distributed data warehouses 提供 scalable 且 elastic 的基础设施。因此，为了确保 high availability 和 business continuity，架构应支持 redundancy、multi-zone replication，以及用于 disaster recovery 的 automated backups。

Metadata and Cataloging

稳健的 metadata management system 对记录并暴露 datasets 细节至关重要，包括 table definitions、data lineage、data owners 和 refresh timestamps。Metadata 支持 self-service discovery，使 analysts 和其他 users 能够理解并信任他们正在访问的数据。因此，与 Amundsen、DataHub 或 Collibra 等现代 data cataloging tools 集成，可以增强 governance，并提升组织整体 data transparency。

Data Quality and Profiling

维护 data quality 是确保 analytics 可靠性的基础。这包括对 incoming data 进行 profiling，以识别 inconsistencies；应用 validation rules 检测 errors；并在 ingestion 期间标记 anomalies。Great Expectations 和 Deequ 等工具可以自动化这些任务。因此，建立一个 feedback loop，将问题反馈给 source systems 或 data owners，有助于随着时间提升 upstream data quality。

Reporting and Analytics

Data warehouse 必须通过支持一系列 reporting 和 analytics 能力，服务多样化的用户需求。Business users 应获得 pre-built dashboards，用于 operational 和 strategic insights。因此，analysts 应能够访问 ad-hoc querying tools，而 data scientists 可能需要 raw data exports 或 SQL interfaces 进行更深入分析。此外，与 Tableau、Power BI、Looker 或 Apache Superset 等 business intelligence platforms 的无缝集成，对释放 warehouse 的全部潜力至关重要。

Data Lifecycle Management

高效 data lifecycle management 有助于优化 storage 和 performance，同时确保符合 data retention policies。因此，组织应基于 data relevance 和 regulatory requirements 定义 retention timelines。Archiving 或 purging obsolete data 有助于管理成本，也能保持 data warehouse 的性能。因此，维护 time-based snapshots 可以支持 historical analysis，并在需要时启用 rollback 或 audit scenarios。

在 data warehousing 中，用于优化 query performance 并简化 data analysis 的一项基础设计技术是 dimensional modeling。这种方法将数据组织成 fact tables 和 dimension tables。Fact table 存储 quantitative data，例如 sales amounts、transaction counts 或 revenue。它通常很大，并且持续更新。相比之下，dimension tables 存储 descriptive attributes，为 facts 提供 context，包括 product names、customer locations 和 time periods。

最常用的两种 dimensional modeling techniques 是 star schema 和 snowflake schema。解释如下：

Star Schema

Star schema 更简单，因此被更广泛采用。在 star schema 中，fact table 位于中心，所有 dimension tables 都直接连接到它。这非常像星星的各个点。这些 dimension tables 通常是 denormalized 的，也就是说所有相关 attributes 都存储在一张 table 中，而不会拆成 sub-tables。该设计优先考虑 query speed，非常适合 dashboarding 和 ad-hoc analysis 等 performance 重要的场景。

例如，考虑一个 sales data warehouse。中心的 Sales fact table 可能包含 sales_amount、units_sold 和 transaction_date 等 metrics。它会连接 Product、Time 和 Location 等 dimension tables。Product dimension 可能包含 product_id、product_name 和 brand 等 attributes。Time dimension 可能包含 date、month、quarter 和 year。因此，这种结构让用户可以快速回答类似这样的问题：“Q1 全部 regions 中，每个 product category 的 total sales 是多少？”

Snowflake Schema

另一方面，snowflake schema 是 star schema 的一种更 normalized 的版本。在这种设计中，dimension tables 会进一步拆分成额外相关 tables，形成类似雪花的结构。例如，与其使用一张包含所有 attributes 的扁平 Product table，不如将其拆成 Product、Product_Subcategory 和 Product_Category 等多张 tables，每张代表层级中的不同级别。这些 normalized dimension tables 可以减少 data redundancy，因此在复杂数据环境中更有利于 storage 和 maintenance。

现在继续 sales 示例。假设业务不仅想按 product 分析 sales，还希望按 product category 和 subcategory 分析。Snowflake schema 不会把所有 product-related information 存储在一张 table 中，而是为每个分类层级创建独立 tables。Product table 会连接到 Subcategory table，而 Subcategory table 又会连接到 Category table。虽然这种结构会增加查询所需的 joins 数量，但当处理大型复杂 dimensions 时，它可以提供更好的 data integrity，并减少 duplication。

总结来说，star schema 为 analytical queries 提供 simplicity 和更快 performance，因此适合大多数 BI scenarios。Snowflake schema 虽然稍微更复杂，但提供更好的 normalization，并且可以更高效地处理 hierarchical relationships。二者之间的选择取决于 data complexity、performance requirements，以及数据将如何被 users 和 tools 消费。

Hybrid Storage Solutions

在当前不断演进的业务数据存储环境中，企业不再必须在 data lake 和 data warehouse 之间二选一。如今，它们更多地实施 hybrid storage systems，也就是 lakehouse architectures。这些结构借鉴了二者的优点。这类系统既可以处理 data lakes 的 scale 和 flexibility，也可以提供 data warehouses 的 speed 和 reliability。

这种组合方法为数据的 consumption、storage、processing 和 analysis 提供了一个 integrated platform。它帮助组织处理多样活动，例如 real-time dashboards、ML pipelines、ad-hoc reporting，以及遵守规则和法规。

传统上，data warehouses 针对 structured data 和 analytical queries 进行了优化，非常重视 data quality、governance 和 performance。然而，它们通常扩展成本较高，并且可能不太适合存储 logs、JSON documents、images 或 video files 等 unstructured 或 semi-structured data。

另一方面，data lakes 是 cost-effective、schema-flexible 的 repositories，专为以 native format 存储大量 raw、多样化数据而设计。虽然它们非常适合 big data ingestion 和 storage，但 data lakes 缺少 real-time decision-making 和 analytics 所需的 transactional integrity 和 query performance。

因此，hybrid storage solution 会整合这两种范式，使企业能够：

• Ingest and Store All Types of Data：structured、semi-structured 或 unstructured。
• 直接在 raw 或 curated data 上运行 analytical queries。
• 减少 systems 之间的 data duplication 和 movement。
• 从单一平台支持 BI 和 AI/ML workloads。

最突出的 hybrid architectures 之一是 lakehouse。这个术语由 Databricks Delta Lake、Apache Iceberg 和 Apache Hudi 等平台推广。这些系统提供：

• ACID Transactions
• Schema Enforcement and Evolution
• Time Travel（Versioning）
• Unified Batch and Streaming Processing

这意味着 users 可以在 data lake 之上执行带 data governance 的 SQL analytics，而不必将数据复制到独立 warehouse 中。

Time Travel

Time travel 允许查询 table 的历史版本。每次 write operation 都会创建一个记录在 transaction log 中的新版本。因此，queries 可以引用特定 version 或 timestamp。

Time travel 尤其适用于：

• Reproducing historical reports
• Debugging data corruption
• Auditing changes

它通过在 transaction log 中跟踪 file-level additions 和 removals 来实现。因此，每次 commit 都会生成一个新的 table snapshot，而无需物理复制整个 dataset。

不过，每个被保留的 version 都会消耗 storage，因为旧 files 会一直保持可访问状态，直到被显式清理。

Compaction（Optimize）

在 lakehouse systems 中，数据经常以 small files 写入，尤其是在 streaming 或 incremental pipelines 中。过多 small files 会因为 metadata overhead 和 file open costs 而降低 query performance。

Compaction 会将许多 small files 合并为更少、更大的 files。这会提升：

• Scan Efficiency
• Query Planning Performance
• Predicate Pushdown Effectiveness

此外，compaction 不会删除 historical versions；它只是将当前 active data 重写为优化后的 file sizes。

Vacuum（Garbage Collection）

Vacuum 会删除 obsolete data files，这些 files 不再被 current table version 引用，并且已经超出 retention window。

如果没有 vacuum：

• Storage 会持续增长。
• Historical versions 可能无限累积。

Vacuum 会执行 retention period，例如 7 天。超过这个时间后，旧 files 会被永久删除。一旦 vacuum 完成，这些 historical versions 就无法再用于 time travel。

Architecture Overview

典型 hybrid storage solution 包含以下组件：

Cloud Object Storage，例如 Amazon S3、Azure Blob 或 GCS：作为 raw 和 processed data storage 的 foundational layer，提供 durability、scalability 和 cost-effectiveness。

Data Lakehouse Engine，例如 Delta Lake、Iceberg 和 Hudi：直接在 object storage 中的 files 之上提供 transactional capabilities 和 metadata management。

Compute Layer，例如 Spark、Presto、Dremio 和 Trino：跨 structured 和 unstructured data 执行 SQL queries、data transformations 和 ML workloads。

BI and ML Tools，例如 Power BI、Tableau、Databricks 或 SageMaker：支持 visualization、interactive analytics 和 ML model development。

Catalog and Governance Layer，例如 Unity Catalog、Hive Metastore、AWS Glue：维护 schema definitions、lineage、access control 和 auditability。

Hybrid storage solutions 代表了数据架构领域中的自然演进。随着组织持续生成多样且高 volume 的数据，对既 flexible 又 performant 的系统需求变得关键。因此，通过融合 data lakes 和 data warehouses 的优势，lakehouse 这类 hybrid models 为现代 analytics 提供了一种强大且可扩展的方法。

无论你是在构建 real-time recommendation engine、支持 regulatory audits，还是为 business teams 启用 self-service BI，一个设计良好的 hybrid storage solution 都可以成为数据驱动型企业的统一基础。

Use Case

目标是通过整合并分析来自多个来源的数据，例如 CRM systems、website clickstreams、transaction history、support tickets 和 social media activity，创建 customer 的 360-degree view。该 solution 必须同时支持 business intelligence 的 ad-hoc analysis，以及 customer segmentation 和 churn prediction 的 ML models。

Challenges：

• 数据有多种 formats，例如 structured CRM data、semi-structured logs，或 unstructured support tickets。
• Business teams 需要基于 curated data 的快速 interactive dashboards。
• Data science teams 需要访问 raw 和 granular data 进行 feature engineering。
• 组织希望避免将数据复制到多个 platforms 中，以控制 cost 和 complexity。

我们将使用 lakehouse pattern 实现这个 hybrid solution。

Step 1：Ingest Raw Data into S3

使用 Fivetran 或 Apache Airflow ETL pipelines，从 CRM 和 transactional systems 摄入 structured data。

使用 Kafka 或 Kinesis 将 website clickstream data 流式传输到 S3 的 raw zone。

使用 serverless function，例如 AWS Lambda，收集 unstructured support data，例如 emails、tickets，并将其以 JSON 或 text 格式存入同一个 lake。

Step 2：Process and Transform Data with Delta Lake

使用 Apache Spark，例如 EMR 或 Databricks，读取 raw data、清洗并丰富它。

将 processed data 以 Delta Lake format 输出，以启用 ACID transactions 和 schema enforcement。

Example PySpark Code：

from pyspark.sql import SparkSession

spark = SparkSession.builder.appName("Customer360").getOrCreate()

raw_crm_df = spark.read.json("s3://company-lakehouse/raw/crm/")
processed_df = raw_crm_df.withColumnRenamed("id", "customer_id")

processed_df.write.format("delta").mode("overwrite").save("s3://company-lakehouse/processed/crm/")

Step 3：Curate for BI and Analytics

使用 dbt 或 Spark SQL，将 enriched datasets，例如 CRM、transactions 和 engagement，join 成 fact-dimension model。

Step 4：Enable BI and ML Use Cases

将 curated Delta tables 注册到 Hive Metastore 或 Unity Catalog。

使用 Power BI 或 Superset 通过 Trino / Presto 连接，并为 marketing 和 sales teams 创建 dashboards。

Data scientists 访问 raw 和 processed Delta tables，在 Databricks ML 或 SageMaker 中构建 churn prediction models。

这个 hybrid solution 利用了 data lakes 的 scalability 和 cost-efficiency，同时确保了类似 data warehouses 的 structure、governance 和 performance。因此，它使多样 data consumers 能够访问同一个基础，同时支持 analytics 和 AI。这是任何希望 data-driven 的现代企业所必需的能力。

Time-Series and Graph Databases

虽然传统 relational 和 NoSQL databases 可以很好地服务 general-purpose storage，但某些 specialized scenarios 需要 purpose-built databases。Time-series databases 和 graph databases 这两类系统，正越来越多地被用于管理特定数据类型和 workloads。

这些系统不仅针对存储独特数据结构进行了优化，也针对传统系统经常难以处理的 query patterns、performance 和 scalability 进行了优化。

Time-Series Databases

Time-Series Database（TSDB）用于高效存储和查询按时间索引的数据。这类数据通常涉及 chronological events，例如 temperature readings、stock prices、server CPU usage 或 IoT sensor output。

Time-series data 的核心特征是：time 是 first-class dimension，并且数据通常按 sequential order 到达，需要在 time windows 中查询，例如 last 24 hours、last 7 days、hourly aggregates 等。

Popular Time-Series Databases：

• InfluxDB
• TimescaleDB（PostgreSQL Extension）
• Prometheus
• OpenTSDB

Use Case：使用 Time-Series Database 监控 Customer App Behavior

想象你是某家 fintech company 的数据团队成员。这家公司提供一个 mobile app，让农村客户申请 loans、查看 balances 和进行 repayments。Product team 希望监控用户随时间如何与 app 交互，因此他们想获得如下 insights：

• 每天有多少 users 登录？
• 哪些 features 被使用最多？
• 是否出现 usage 的突然下降，这可能表明 app issues 或 customer dissatisfaction？

这就是 Time-Series Database（TSDB）非常有价值的地方。

传统 relational databases 可以存储这些数据，但当处理数百万条 timestamped events 时，查询性能会很快下降。你还需要编写多个 indexes 和复杂 queries，这会让 real-time dashboards 变慢且消耗大量资源。

你需要一个针对 high write throughput、time-window aggregations 和 low-latency queries 设计的系统。

你决定实施 InfluxDB，这是一个流行的 time-series database。每当 user 与 app 交互，例如登录、查看 balance、提交 loan request，系统都会记录一个 event，并将其与 timestamp 和相关 metadata 一起推送到 InfluxDB 中。

Writing Data to InfluxDB（Python Example）：

from influxdb_client import InfluxDBClient, Point, WritePrecision

client = InfluxDBClient(url="http://localhost:8086", token="my-token", org="my-org")
write_api = client.write_api()

point = Point("user_activity") \
.tag("user_id", "U101") \
.tag("region", "Tamil Nadu") \
.tag("app_version", "v1.3.2") \
.field("event_type", "login") \
.time("2025-04-12T09:15:00Z", WritePrecision.NS)

write_api.write(bucket="app_analytics", org="my-org", record=point)

Querying Time-Based Insights

现在，假设 business team 想要一个 dashboard，展示过去 7 天的 daily active users。

在 InfluxQL，也就是 InfluxDB 的 SQL-like query language 中，可以这样写：

SELECT COUNT(DISTINCT("user_id"))
FROM "user_activity"
WHERE time >= now() - 7d
GROUP BY time(1d)

你也可以回答更复杂的问题，例如：

• 哪些 regions 在新 app version rollout 后 activity 下降？
• 某个 state 每小时发生多少 loan_submit events？

SELECT COUNT("event_type")
FROM "user_activity"
WHERE event_type = 'loan_submit' AND region = 'Karnataka'
AND time >= '2025-04-10T00:00:00Z' AND time <= '2025-04-12T23:59:59Z'
GROUP BY time(1h)

这种细粒度、基于时间的切片，在传统 RDBMS 中会很痛苦且很慢，但在 time-series setup 中则非常快速且表达力强。

由于数据带有 timestamps，并针对 time-window queries 优化，你可以轻松支持 near real-time dashboards 和 anomaly detection。

Graph Databases

Graph database 用于使用 nodes、edges 和 properties 表示并查询具有复杂关系的数据。

不同于 relational databases 中 joins 成本高昂，graph databases 将 relationships 作为 first-class citizens。这使它们在 traversal 和 network analysis 上非常快速且表达力强，无论网络是 people、products 还是 systems。

Key Concepts：

• Nodes 表示 entities，例如 Person、Product。
• Edges 表示 relationships，例如 “FRIEND_OF”、“BOUGHT”。
• Properties 存储 nodes 和 edges 上的 attributes。

Popular Graph Databases：

• Neo4j
• Amazon Neptune
• ArangoDB
• TigerGraph
• OrientDB

Use Case：使用 Graph Databases 检测 Loan Fraud

想象你在一家 non-banking financial company（NBFC）工作，这家公司为农村地区的个人提供 micro-loans。你最近注意到 fraudulent loan applications 增加了，其中一些人会创建多个身份、用不同名字重新申请，或利用 credit-check process 中的漏洞。

你现有的 relational database 可以告诉你 Ravi Kumar 和 Rajesh K. 住在同一个村庄，并且在一周内都申请了 loans。但是，如果他们共享同一个 mobile number、经常互相 referral，或者使用同一个 nominee，该怎么办？用 SQL queries 揭示这些隐藏关系，就像在没有盒面图案的情况下拼一副缺少拼片的拼图。

因此，你需要一个将 relationships 作为 first-class citizen 的系统。这正是 graph databases 发挥作用的地方。

Neo4j 等 graph databases 以一种模仿人类思维方式的形式存储数据：用 connections 来理解世界。它们用 nodes 表示 entities，例如 people 或 phone numbers；用 edges，也就是 relationships，表示这些 entities 如何连接；并用 properties 存储额外 details。

在我们的 fraud detection use case 中，nodes 可以表示：

• Customers
• Phone Numbers
• Addresses
• Guarantors
• Nominees

Edges，也就是 relationships，可能包括：

• USES_PHONE
• LIVES_AT
• REFERRED_BY
• HAS_NOMINEE

因此，通过可视化和查询这些 connections，你可以检测 suspicious behavior clusters，例如：

• 多个人使用同一个 phone number。
• 一个 nominee 关联多个无关 borrowers。
• 一小群 borrowers 之间存在交叉 referral。

假设你有以下 relationships：

• Ravi Kumar 和 Rajesh K. 都将 +919898989898 列为 contact number。
• Ravi 在 loan application 中 referral Rajesh。
• 二者都将 Sita Devi 列为 nominee。

这些数据在 graph 中可视化如下：

(Ravi) —[USES_PHONE]→ (+919898989898)
│
└── [HAS_NOMINEE]→ (Sita Devi)
↑
(Rajesh) —[HAS_NOMINEE]→
│
└── [REFERRED_BY]→ (Ravi)

现在，下面是你可以如何查询 Neo4j，以检测同一个 nominee 是否被多个 borrowers 使用：

MATCH (n:Nominee)<-[:HAS_NOMINEE]-(c:Customer)
WITH n, collect(c.name) as customers, count(c) as count
WHERE count > 1
RETURN n.name as Nominee, customers

这会给出关联到多个 customer 的 nominees 列表，这可能是一个 red flag。它也可以用于查找通过同一 phone number 连接的所有 customers：

MATCH (p:Phone)<-[:USES_PHONE]-(c:Customer)
WITH p, collect(c.name) as customers, count(c) as count
WHERE count > 1
RETURN p.number as Phone, customers

你也可以使用 Neo4j Graph Data Science Library 中内置的 connected components 或 community detection 等 graph algorithms，检测 fraud rings，也就是一组相互 referral 并共享数据点的人所形成的 interconnected clusters。

因此，Neo4j 等 graph databases 打开了一种新的洞察维度，尤其当你处理 interconnected entities 时，例如 fraud detection、recommendation engines 或 supply chain networks。

因此，如果你的数据中存在等待被发现的 hidden relationships，那么可能是时候考虑 graphs 了。

结论

任何数据驱动系统的基础，都在于数据如何被有效存储。因此，本章探索了广泛的 storage design patterns，每一种都针对特定 data structures、use cases 和 processing needs 设计。

我们从 relational 和 non-relational databases 的比较开始，学习了何时 structure 和 integrity 比 flexibility 更重要，以及何时相反。随后，我们进入 data lakes 的世界，理解 raw 和 curated datasets 如何在 Amazon S3 和 HDFS 等 scalable storage solutions 中共存。我们还探索了 Delta Lake 和类似技术如何通过 schema enforcement 和 ACID guarantees 增强这些架构。

接下来，我们转向 data warehouse design，考察了 star 和 snowflake schemas 等 modeling techniques，以及它们如何支持规模化 analytical workloads。我们也涉及了 governance、ETL integration、performance tuning 和 lifecycle management。

随后，我们通过 hybrid storage solutions，尤其是 lakehouse architectures，弥合了二者之间的差距。Lakehouse architectures 将 data lakes 的灵活性与 warehouses 的可靠性结合起来。最后，我们揭示了 specialized storage systems 的力量，例如用于 event 和 sensor data 的 time-series databases，以及用于发现复杂 networks 中隐藏 relationships 和 patterns 的 graph databases。

下一章中，我们将把重点转向 batch processing。Batch processing 是数据工程中的一项基石技术，用于执行大规模、周期性的 transformations。我们将深入了解 Apache Spark 和 Hadoop MapReduce 等 frameworks 如何在 TB 级数据上驱动 distributed processing。在那里，你还将学习如何设计稳健、高效的 workflows，如何针对 performance 进行优化，以及如何处理 scheduling、fault tolerance 和 resource allocation 等 operational challenges。

因此，到下一章结束时，你将有能力构建 batch pipelines，这些 pipelines 不仅 scalable 和 reliable，而且针对今天 data-intensive environments 得到了良好优化。