共计 2503 个字符，预计需要花费 7 分钟才能阅读完成。
摘要：本文回顾了“湖仓一体”概念提出的相干背景，具体地论述了为什么须要“湖仓一体”以及“湖仓一体”数据架构的具体构想。最初对数据仓库、数据湖以及“湖仓一体”进行了具体的比拟。
自 20 世纪 80 年代末以来，数据仓库在决策反对和商业智能应用领域中施展了重要作用。
数据湖
尽管数据仓库非常适合结构化数据，但许多古代企业必须解决非结构化数据，半结构化数据。
数据湖是企业卸载所有数据的中央，因为其低成本存储系统具备文件 API，能够保留通用和凋谢文件格式的数据，例如 Apache Parquet 和 ORC。凋谢格局的应用还使数据湖中的数据能够间接被各种其余剖析引擎（如机器学习零碎）拜访。
一开始，人们认为所须要的只是提取数据并将其放入数据湖中。一旦进入数据湖，最终用户就能够潜入并找到数据并进行剖析。然而，组织很快发现，应用数据湖中的数据与仅仅将数据搁置在湖中齐全不同。换句话说，最终用户的需要与数据科学家的需要有很大不同。
最终用户遇到了各种各样的阻碍：
- 须要的数据在哪里？
- 一个数据单位如何与另一个单位的数据相分割数据？
- 数据是否是最新的？
- 数据的准确性如何？
因为不足一些要害的基础设施性能，数据湖的许多承诺尚未实现：不反对事务，不强制执行数据品质或治理，以及性能优化不佳。后果，企业中的大多数数据湖都变成了数据沼泽。
以后数据架构的挑战
以后常见的数据架构是应用多个零碎（一个数据湖、多个数据仓库和其余专用零碎）来均衡数据仓库和数据湖的优劣势。
然而，这会导致三个常见问题：
低廉数据挪动老本
超过 90% 的模仿 / 物联网数据存储在数据湖中，因为它具备凋谢间接拜访文件的灵活性和低成本，因为它应用便宜的存储。为了克服数据湖不足性能和品质问题，企业应用 ETL（提取 / 转换 / 加载）将数据湖中的一小部分数据复制到上游数据仓库，用于最重要的决策反对和 BI 应用程序。这种双系统架构须要对数据湖和仓库之间的 ETL 数据进行继续工程设计。每个 ETL 步骤都有产生故障或引入升高数据品质的谬误的危险 — 保持数据湖和数据仓库的一致性既艰难又低廉。同时，ETL 能够整合数据。
限度了对机器学习的反对
只管对机器学习和数据管理的交融进行了大量钻研，但没有一个当先的机器学习零碎，如 TensorFlow，PyTorch 和 XGBoost，在仓库之上工作得很好。与提取大量数据的商业智能（BI）不同，机器学习零碎应用简单的非 SQL 代码解决大型数据集。
不足开放性
数据仓库将数据锁定为专有格局，这会减少将数据或工作负载迁徙到其余零碎的老本。鉴于数据仓库次要提供仅 SQL 拜访，因而很难针对数据仓库运行任何其余剖析引擎，例如机器学习零碎。
“湖仓一体”的呈现
在数据湖的根底上，呈现了一种新的数据架构，称为”湖仓一体“。
采取 Lake-First 的方法论
利用数据湖中已有的模仿和物联网数据，因为数据湖曾经将大多数结构化、文本和其余非结构化数据存储在低成本存储（如 Amazon S3、Azure Blob Storage 或 Google Cloud）上。
为数据湖带来可靠性和品质 - 反对 ACID
- 反对 Sechema，提供星型、雪花等模型剖析能力，提供弱小的治理和审计机制。
- 反对 Sechema 强制查看，从而避免谬误数据导致数据损坏。
- 架构演进容许数据一直更改，使最终用户可能对可主动利用的 schema 进行更改，而无需繁琐的 DDL。
- 增加治理和安全控制
- 通过 Scala、Java、Python 和 SQL API 反对 DML，以合并、更新和删除数据集，从而合乎 GDPR 和 CCPA，并简化变更数据捕捉等用例。
- 历史记录提供无关对数据所做的每个更改的记录详细信息，从而提供更改的残缺审核跟踪。
- 数据快照使开发人员可能拜访和复原到晚期版本的数据，以进行审核、回滚或重现试验。
- 基于角色的访问控制为表的行 / 列级别提供细粒度的安全性和治理。
优化性能
通过利用文件统计信息和数据压缩来调整文件大小，实现各种优化技术，例如缓存、多维聚类、z-ordering、data skipping 等。
反对机器学习 - 反对多种数据类型来存储、优化、剖析和拜访许多新应用程序的数据，包含图像、视频、音频、半结构化数据和文本。
- 高效间接读取大量数据（非 SQL），以便应用 R 和 Python 库运行机器学习试验。
- 通过内置反对 DataFrame API 申明性 DataFrame API，可针对机器学习工作负载中的数据拜访进行查问优化，因为 TensorFlow、PyTorch 和 XGBoost 等机器学习零碎已采纳 DataFrames 作为操作数据的次要形象。
- 机器学习试验的数据版本控制，提供数据快照，使数据迷信和机器学习团队可能拜访和复原到晚期版本的数据以进行审核和回滚或重现机器学习试验。
提供开放性 - 凋谢文件格式，如 Apache Parquet 和 ORC。
- Open API 提供了一个凋谢的 API，能够间接高效地拜访数据，而无需专有引擎和供应商锁定。
- 语言反对，不仅反对 SQL 拜访，还反对各种其余工具和引擎，包含机器学习和 Python/ R 库。
数据仓库 vs 数据湖 vs 湖仓一体
下图表是对数据仓库、数据湖、湖仓一体的比拟：
思考与探讨
你认为湖仓一体架构必须具备哪些性能，能力称为真正的”湖仓一体“，而不是炒作概念。 - 事务（ACID）反对
- 凋谢文件格式
- 数据安全、数据治理
- 其它
HashData 湖仓一体利用实际
随着企业数字化转型的推动，越来越多的企业视湖仓一体为数字化改革的契机。当然，关注度越高，市场上嘈杂的声音也就越多。
在理论业务场景中，数据的挪动不只是存在于数据湖和数据仓库之间，湖仓一体不仅须要把数仓和数据湖集成起来，还要让数据在服务之间按需流动。
HashData 采纳湖仓一体化架构，能够不便、快捷地将大量数据从数仓转移至数据湖内，同时这些移到湖里的数据，依然能够被数仓查问应用。
目前，HashData 已广泛应用于金融、电信、交通等行业，服务超过 50 家行业客户。在能源畛域，HashData 为某大型央企设计了基于计算存储拆散的架构数据湖, 相比计算存储绑定的架构，HashData 云端数据湖在保障查问需要的同时，缩小了服务器资源老本。在 PB 级的数据量下，能够为企业节俭上百万的服务器洽购老本，充沛实现了降本提效的指标。
