你的数据存放在哪里?解码现代数据生态系统
Source: Dev.to
1. 数据库
想象一下你刚刚创办了一家企业。你需要一个系统来记录每日运营——每当客户购买产品、更新密码或提交支持工单时,都要有记录。这就是 标准数据库 的工作。
数据库类型
| 类别 | 用例 | 示例 |
|---|---|---|
| 关系型 (SQL) | 以固定行列的表格形式存储结构化数据 | PostgreSQL、MySQL |
| 非关系型 (NoSQL) | JSON 文档等非结构化或半结构化数据 | MongoDB、Couchbase |
核心特性
-
ACID 属性 – 在事务期间保证绝对的数据完整性。
- 原子性 – 事务要么全部成功,要么全部不做。
- 一致性 – 数据从一个有效状态转移到另一个有效状态,不会违反用户定义的规则。
- 隔离性 – 并发事务之间不会相互干扰。
- 持久性 – 一旦提交,修改即使在系统崩溃后也能保留。
-
查询语言 – 大多数数据库提供一种语言(通常是 SQL)用于检索、过滤、聚合或更新数据。
-
索引 – 类似教科书背后的索引,索引提供快捷方式,使引擎能够瞬间定位行,而无需扫描整张表。
-
规范化 – 将大型数据集拆分为更小、相互关联的表,消除重复信息并降低冗余。
-
数据备份与恢复 – 强大的机制可防止硬件故障、软件缺陷或意外停机导致的数据丢失。
-
数据建模 – 设计数据库分为三个阶段:
- 概念建模 – 高层次的数据关系。
- 逻辑建模 – 技术细节(属性、数据类型)。
- 物理建模 – 在 DBMS 中实际实现的模式。
数据库的使用场景
当需要 实时数据处理 和 高事务量 时,数据库表现尤为出色。
| 场景 | 描述 |
|---|---|
| 实时事务处理 | 如 POS 支付或银行转账等即时操作。 |
| 客户关系管理 (CRM) | 管理实时的客户订单、互动和支持工单。 |
| 企业资源规划 (ERP) | 为日常运营软件(工资、库存等)提供动力。 |
2. 数据仓库
数据库非常适合实时存储记录,但如果需要将今天的销售额与五年前的数据进行比较怎么办?这时 数据仓库 就派上用场了。数据仓库不处理实时事务,而是从多个来源存储海量的 结构化、历史数据,帮助组织发现长期趋势并做出数据驱动的决策。
关键特性
- 集中式数据 – 将来自众多系统的信息整合,为分析师提供全面的高层视图。
- 时变数据 – 保留历史记录,支持跨期分析和趋势识别。
- 非规范化架构 – 表数量更少,关系更简化,提高分析查询的读取性能。
- 聚合数据 – 通常在不同粒度上预先汇总,便于快速概览或深入钻取。
- 查询优化 – 使用索引、数据分段、物化视图等技术,高效处理海量分析工作负载。
- BI 集成 – 原生连接商业智能平台,实现仪表盘、报表和可视化。
数据仓库的使用场景
| 使用场景 | 为什么选择仓库? |
|---|---|
| 商业智能 (BI) | 整合大量历史数据,用于分析、报表和预测。 |
| 趋势分析与报告 | 生成业务报告、仪表盘,发现随时间变化的模式。 |
| 预测分析与数据挖掘 | 支持预测客户行为、市场趋势等的高级模型。 |
示例: Amazon Redshift, Google BigQuery, Snowflake.
3. 数据湖
数据仓库组织得非常严密,但这种刚性也可能是一把双刃剑。虽然它们能保证数据干净、结构化,却在处理 大规模、非结构化或半结构化数据集(例如原始网站点击日志、JSON 文件)时捉襟见肘。当数据过大或过于非结构化而不适合放入仓库时,就会被倾倒到 数据湖 中。
数据湖的提供功能
- 支持多种格式 – 以原始形式存储数据(JSON、Parquet、Avro、CSV、图片、视频等)。
- 可扩展性 – 能处理 PB 级别的数据,无需预定义模式。
- 实时分析准备 – 直接在原始数据上为下游机器学习管道和流式分析提供支持。
简而言之,数据湖是“原材料”库;数据仓库是“精炼产品”库;而数据库是支撑日常运营的“事务引擎”。
快速回顾
| 层级 | 主要目标 | 典型数据 | 典型查询 |
|---|---|---|---|
| 数据库 | 实时事务处理 | 结构化、当前数据 | CRUD(创建、读取、更新、删除) |
| 数据仓库 | 历史分析与报告 | 结构化、聚合、随时间变化的数据 | 复杂分析查询、BI 仪表盘 |
| 数据湖 | 原始数据摄取与灵活分析 | 非结构化/半结构化、大规模数据 | 机器学习、流式分析、临时探索 |
理解这些区别有助于你为数据工程中遇到的每个问题选择合适的存储方案。祝构建愉快!
Source: …
数据湖 vs. 数据仓库 vs. 数据集市 vs. 数据湖仓
数据湖
- 目的: 在大规模下存储原始、非结构化或半结构化数据。
- 水平可扩展性: 使用成本高效的存储解决方案,如 Amazon S3、Azure Blob Storage 或 Google Cloud Storage,能够随着数据量的增加无缝扩展。
数据湖示例:
- AWS S3
- Azure Data Lake Storage Gen2
- Google Cloud Storage
数据仓库
随着假设中的公司不断壮大,数据仓库也变得庞大。营销团队现在抱怨,在所有财务、HR 和工程数据中查找他们需要的特定活动指标耗时过长。
解决方案: 数据集市 —— 为单个业务单元(如营销或财务)提供专门服务的较小规模数据库。其主要目标是将组织庞大的数据池过滤为高度聚焦、易于管理的存储库,以实现快速访问。
数据集市类型
| 类型 | 描述 |
|---|---|
| 依赖型数据集市 | 直接从企业的中央数据仓库中划分。采用自上而下的方法,数据集市在部门需要进行分析时提取特定的、预定义的主数据子集。 |
| 独立型数据集市 | 完全独立的存储库,不依赖于中央数据仓库。团队直接从各种内部或外部来源提取、处理并存储数据。 |
| 混合型数据集市 | 通过从现有数据仓库和外部运营系统两方面获取信息,融合了两种方法。这既提供了自上而下方法的速度和结构化接口,又保持了独立设置的灵活集成。 |
从数据湖和数据仓库到数据湖仓
历史上,公司必须同时维护 Data Lake(用于原始、低成本的机器学习存储)和 Data Warehouse(用于快速、结构化的 BI 报告)。在两者之间移动数据既困难又昂贵。
Data Lakehouse
Data Lakehouse 是一种现代混合架构,结合了数据湖的大规模、成本效益存储和数据仓库的强大数据管理能力。通过弥合原始数据存储与高速分析之间的差距,湖仓能够同时支持:
- 非结构化机器学习工作负载
- 结构化商业智能(BI)工作流
关键特性
- ACID 合规 – 确保可靠事务,保持严格的数据一致性和完整性。
- 灵活的模式 – 同时支持 schema‑on‑write 和 schema‑on‑read,让工程师在摄取原始数据时拥有灵活性,同时为分析师提供刚性、可靠的结构。
- 原生 BI 集成 – 可无缝连接流行的 BI 平台,如 Tableau、Power BI 和 Looker,使决策者能够直接从源头可视化数据。
最后思考
| Component | Role |
|---|---|
| Database | 捕获实时销售。 |
| Data Lake | 存储客户如何找到你的混乱原始网站日志。 |
| Data Warehouse | 分析这些销售趋势的五年数据。 |
| Data Mart | 为营销团队即时提供他们关心的指标。 |
通过了解并利用这些层——Data Lake、Data Warehouse、Data Mart和Data Lakehouse——组织可以构建一个灵活、可扩展且具成本效益的分析生态系统。