一个理想的数据湖应该具备哪些功能
发布时间：2023-02-16 09:47:11 所属栏目：云计算 来源：互联网
导读：从数据库到数据仓库，最后到数据湖，随着数据量和数据源的增加，数据格局正在迅速变化。数据湖市场预计增长近 30%，将从 2020 年的 37.4 亿美元增长到 2026 年的 176 亿美元。此外从 2022 年数据和人工智能峰会来看，数据湖架构显然是数据管理和治理的未来。
|
从数据库到数据仓库，最后到数据湖，随着数据量和数据源的增加，数据格局正在迅速变化。数据湖市场预计增长近 30%，将从 2020 年的 37.4 亿美元增长到 2026 年的 176 亿美元。此外从 2022 年数据和人工智能峰会来看，数据湖架构显然是数据管理和治理的未来。由于 Databricks发布了 Delta 2.0，该趋势可能会增长，该平台的所有 API 都将是开源的。此外Snowflakes在其峰会上宣布了一些改变游戏规则的功能，使数据湖成为该行业的支柱。治理、安全性、可扩展性以及对分析和交易数据的无缝分析，将会推动该领域创新。 根据 Hay、Geisler 和 Quix（2016 年）的说法，数据湖的三个主要功能是从多个数据源提取原始数据，将其存储在安全的存储库中，并允许用户通过直接查询数据湖来快速分析所有数据。数据湖由三个部分[7]组成。数据存储、数据湖文件格式和数据湖表格式。所有这些都有助于实现上述功能，并作为数据湖的基石。 数据湖架构[8]通过其数据存储组件存储来自各种来源的数据，例如传统数据库、Web 服务器和电子邮件。数据湖文件格式用作数据处理单元，其中数据源以面向列的格式压缩以优化查询和探索。最后数据湖表格式通过将所有数据源聚合到一个表中来帮助进行数据分析。因此更新一个数据源将更新所有其他数据源，就好像它们都在一个表中一样。典型的数据存储平台包括 AWS S3、Google Cloud Storage 和 Azure数据湖。Apache Parquet 或 Avro 是一些通用的数据湖文件格式，Apache Hudi、Apache Iceberg 和 Delta Lake是众所周知的数据湖表格式。  数据湖已成为必需品，而不是可有可无的东西。但这并不意味着组织会盲目地对其进行投资。不同的情况需要不同的功能集。下面列出了理想情况下数据湖应具备的所有功能。 不支持 ACID 事务的数据湖可能会给数据治理带来相当大的麻烦。ACID 代表 Atomicity、Consistency、Isolation 和 Durability 的首字母缩写词。 • 原子性确保只有完成的数据进程才会影响数据源。因此如果更新中途失败，则不会添加任何行 • 一致性通过施加唯一标识符、支票账户中的正余额等约束来维护数据完整性 • 隔离可防止并发操作交互 • 持久性有助于即使在系统出现故障后也能保持最新的数据状态 数据库操作语言 (DML)[16]是一组命令，可让用户操作数据库中的数据。例如 SQL 是一种 DML，允许用户编写 SELECT、INSERT、DELETE、UPDATE 和 MERGE 等命令来对数据执行特定操作。支持 DML 的数据湖通过让用户轻松保持源表和目标表之间的一致性，简化了治理和审计以及变更数据捕获 (CDC)。例如用户可以使用 UPDATE 命令以根据特定过滤器将源表中检测到的变更传递到目标表。 Delta Lake 和 Snowflake等数据湖允许用户在行级别跟踪和捕获对表所做的更改。该功能是 CDC 的一部分，其中数据湖在单独的日志中记录由于 UPDATE、DELETE 或 INSERT 事件对源表所做的任何更改。这种跟踪在多个用例中都有帮助，例如通过仅处理更改来优化 ETL 过程，仅使用新信息而不是整个表更新 BI 仪表板，以及通过将所有更改保存在更改日志中来帮助审计。 当今的企业经常将大量数据从一个环境迁移到另一个环境，以使用经济高效的数据解决方案。但是在数据湖上进行此类临时迁移可能会导致不可逆转的挫折，从而导致企业失去宝贵的数据资产。因此数据湖应该具有内置的恢复功能，让用户可以通过简单的命令使用安全备份恢复相关表的先前状态。 大多数数据湖架构中缺乏有效的数据清理机制是一个明显的弱点，会导致数据湖迅速变成数据沼泽。由于数据湖在没有预定义模式的情况下摄取数据，因此随着数据量和类型的增加，数据发现会变得复杂。因此，像 Snowflake这样的数据湖平台在数据摄取阶段施加了一定的约束，以确保传入的数据没有错误或不一致，否则可能会在以后导致分析不准确。 索引表可以使数据湖加速查询执行，使用索引而不是遍历整个数据集来提供结果。在 SQL 查询中应用过滤器时，索引特别有用，因为它简化了搜索。元数据管理也可以发挥作用，因为它定义了数据表的特定属性以便于搜索。但是像 Snowflake 这样的数据湖不使用索引，因为在庞大的数据集上创建索引可能很耗时[27]。相反，它计算表的列和行的特定统计信息，并将这些信息用于查询执行。 数据湖中的数据摄取功能有时没有明确的优先级，因为数据湖的工作原则是“现在存储，以后分析”[29] 然而这很快就会成为瓶颈，数据湖将变成数据沼泽而无法进行数据分析。因此数据湖应该有一些机制来提供数据的早期可视化，让用户了解数据在摄取过程中包含的内容。 虽然不是必须的，但当数据需要偶尔大量加载到数据湖时，批量加载非常有必要。与增量加载数据不同，批量加载有助于加快流程并提高性能。然而更快的速度有时可能只是一件好事，因为批量加载可能会忽略确保只有干净数据进入湖中的约束。 本地数据架构的问题之一是它们无法提供高并发性，这意味着同时为多个用户提供服务是一件麻烦事。云平台解决了这个问题，但由于数据仓库的限制，高并发仍然是一个问题。以大数据分析着称的Apache Spark等开源平台无法支持高并发。然而 Databricks 等数据湖解决方案是为数不多的支持高并发的解决方案之一，尽管它们在低延迟（响应用户请求所需的时间）方面还可以继续改进。 随着数字化步伐的不断加快，数据共享已成为当下的需求。由于数据被不同的团队用于多个用例，通过数据目录系统进行无缝数据共享对于数据驱动的决策制定和防止业务领域之间的孤岛是必要的。数据湖不仅应该提供跨平台无缝共享数据的方法，而且还应该安全可靠地这样做，因为由于访问控制薄弱，数据安全可能成为一个问题。 数据分区为跨多个表或站点分布数据以加速查询处理并简化数据管理。AWS 等 Lakehouse平台建议对数据进行分区以实现可扩展性和安全性，因为分区可以防止单个数据源占用大量空间并将敏感数据与非敏感数据分开。 有效的数据治理对于数据湖存储有价值的数据至关重要。事实上组织需要构建一个数据湖解决方案，在数据访问和数据控制之间提供基础。随着数据共享成为跨多个平台的常态，数据湖架构必须具有维护数据质量和完整性的流程。对于多个用户同时访问不同类型数据的云数据湖，这些流程变得特别有用。 （编辑：甘南站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
