人工智能领导者数据策略建造互操作湖屋

目录 前言：人工智能时代需要互联互通的架构. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 数据架构难题：为什么企业停滞不前（或思考他们（是）. . . . . . . . . . . . . . . . . .重新思考建筑——从数据孤岛到开放的、互操作的数据湖. . . . .. . . . . . . . . . .6 无妥协连接数据. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10 声明式数据处理实现规模简化. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .治理安全与信任的人工智能时代. . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17种可互操作的数据湖架构模式. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20 企业湖仓的商业模式. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .第25节：建筑师的力量. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29 序言人工智能时刻需要互联架构 的压力。他们正在超越实验阶段，进入生产阶段，最终发现成功的AI并非从模型开始——而是从数据开始。这正是为何以信心迎接这一时刻的关键恰恰在于您数据基础设施的准备好程度。 供灵活的配置，又能保持数据中心所有权、普遍的治理以及提供人工智能准备能力。请进入可互操作的数据湖屋。 向互操作性意味着能够安全地将任何引擎带入你的数据或访问任何数据以进行读写操作。可互操作的湖泊屋建立在开放标准之上，旨在实现供应商中立连接，企业可以自由构建而不妥协——在一个平台上实现无缝互操作性、加强治理并解锁企业级AI。 跟踪所有数据源的可追溯性和质量检查，所有这些都在努力使数据始终清洁、精心整理、标记、可访问并在系统间进行管理。但在实践中，许多企业最终拥有跨越系统、云和地区碎片化和重复的数据资产，这使得其难以扩展，几乎无法进行管理。看到公司利用不同的数据仓库、数据湖和引擎并不罕见，因为每个团队或业务单元都是孤立地构建其架构，以在首选的堆栈上标准化。这种方法迫使中央数据团队在平台之间切换或创建薄弱的联系。 数据架构难题：企业为何停滞不前（或认为自身处于停滞状态） 他们只是最终建立了一条新路径，这是一种短期解决方案，通常会导致脆弱、昂贵且耗时的管道，这些管道依赖于数据复制。这不仅会引起对真相来源的无谓困惑，还限制了人工智能的效果和准确性。 可能会转向数据仓库，而数据科学则优先考虑数据湖。再加上企业级SaaS工具的庞大生态系统，如Workday和Salesforce，它们都在产生对商业AI项目至关重要的数据。然而，结果却是，现代技术栈与其说是堆叠，不如说是迷宫。每个新工具都增加了整体系统的复杂性，尽管它可能必要地在一个区域上减少了摩擦。但随着每一次技术升级和在每个新层上增加，工程团队很快就会意识到他们陷入了一个由碎片化系统构成的复杂迷宫中。 实际上，缺失的遗产湖屋方法实际上是可以实现的：一个连接但开放的数据和治理基础，为团队提供选择他们喜欢的引擎和工具的灵活性，同时集中治理和语义。 在这本书中，我们将探讨开放且可互操作的数据湖屋——作为一个概念，其起源以及一些旨在帮助企业成功利用人工智能而非仅仅对其做出反应的最佳实践。我们将探讨支撑这一架构的三个基本支柱——双向互操作性、规模化简化和人工智能的通用治理——所有这些都是为了展示专为使任何企业人工智能就绪而设计的湖屋几乎无限的威力。我们将分享真实企业如何通过在Snowflake上建立正确的湖屋基础来实现人工智能投资回报率的故事，并从我们的主要云合作伙伴亚马逊网络服务（AWS）、谷歌云和微软那里提供见解和架构模式。 展示企业如何重新获得对本数据中心资产的完全所有控制权，摆脱那种所谓的迷路的恐惧。 重新思考建筑——从数据孤岛到开放的、互操作的湖屋 作，无穷无尽地管理着结构化数据的数据库，同时还有非结构化图像、视频或文档的数据湖。在实践中，这往往导致更多的隔阂，迫使架构师陷入复杂性。然而，随后湖屋（lakehouse）的出现有助于解决这些问题——带来了性能、灵活性、成本效益以及降低供应商锁定风险的前景。 这种能够容纳各种结构数据存储方式被称为数据湖。 数据仓库 vs. 液态屋 vs. 数据湖为了帮助您理解传统湖屋和互操作湖屋之间的区别，我们首先需要回顾一下当今大多数数据系统中存在的三 然后是第三种类型：数据湖屋。继续这个比喻，这个车库沿墙有可调节的金属架子，还有几个井然有序的塑料箱子，但并不是所有东西都能整齐地放进盒子里——这没关系。总的来说，车库是井井有条的，每个物品都有自己的位置。 种核心架构。想想人们是如何使用他们的车库来储存物品的。想想那些极度有条理的人，他们沿着每面墙都安装了内置的架子，并把他们所有的物品整齐地收纳进每个都清晰标记的塑料箱中。如果有什么东西放不进箱子里或抽屉里，就会被丢弃。这就是数据仓库，一个用于存储结构化和有序数据的存储库。 能力！），因此评估哪种架构适合任何特定情况变得非常重要。但对于许多具有前瞻性的组织来说，一个越来越明确的事实是，互操作性的湖屋正在证明自己是选项实现了灵活性的承诺现代化并且扩大规模，同时不牺牲可靠性和性能。 自行车侧躺，周围散落着各种体育纪念品，积满了灰尘。 Delta Lake方法 Delta Lake 是一个针对 Apache Spark™ 工作负载优化的开源开放表格格式。因此，典型的实现提供了一种单写多读的模型。这意味着这个表格非常适合寻求在单一供应商或作者上标准化的企业，但在尝试实现开放湖仓和表格格式所承诺的完全双向互操作性时，会遇到摩擦。 用户束缚在单一供应商手中。这个领域的供应商通常要求特定的目录来实现完全功能，或者限制写入能力，从而阻止其他工具更新或管理数据。同样，他们将关键的性能优化仅限于自己的专有计算引擎。 ，只是形式不同，结果是功能锁定，这最终迫使进行迁移和数据移动。突然之间，将工具带到数据而不是将数据带到工具的好处几乎丧失殆尽。 这正是Apache Iceberg——凭借其供应商中立、互操作性——成为一大启示的原因。与Delta Lake不同，Iceberg提供多写多读的规范。这意味着客户可以在一个平台上实现标准化，同时利用他们偏好的计算引擎和工具 进行任何操作。 太频繁的，湖景房子的建筑因设计决策基于不同的开放式表格格式而无法全面实现数据所有权和互操作性。 开式表格格式（在第 following 章节中将有更深入的解释）是关于从兼容的计算引擎访问磁盘上的文件应该如何 大多数现代架构的开放性和互操作性提供了基准：Delta Lake 和 Apache Iceberg™。事实是，如今仅仅声称开放是不够的；企业湖屋必须具备开放性和互操作性。 •Cortex CodeCLI 和雪花智能赋予您的技术和业务团队使用Snowflake原生智能和全面管理的平台，将复杂的数据、互操作性和基础设施任务提炼成简单的自然语言交互和自动化的能力。 雪花的Lakehouse企业愿景 一个建立在双向互操作性基础上的开放和兼容的湖屋，就像是没有Wi-Fi接入或SIM卡的高端智能手机一样；没有连接的情况下，它的实用性会大大受限。这正是为什么Snowflake不断地考虑系统如何协作——以及如何做到更好。 格式，解锁所有互操作性，而无需管理云存储的复杂性。 。现在，无论表在哪里，用户都可以在完整性能下进行数据交易、查询和修改，无需其他平台通常要求的只读限制或复杂的摄入管道。 型直接带到数据所在之处，从开放表中直接提取洞察，无需数据迁移。 开放数据。 放的、基于元数据的治理和安全模型，无需锁定即可在表格、行和列级别隔离数据。 ——它本应归属的地方，并最终实现开放数据湖一直承诺的好处。 无妥协连接数据 数不同来源的众多不同数据类型，能够使其全部标准化并可供各种系统和目的使用，归根结底就是——没错——互操作性。 ，作为唯一的连接组织。然而，挑战在于，如今的数据领地是碎片化的；它们的连接点薄弱。实际上，每个新的业务数据请求都变成了一项复杂的项目。数据团队最终成为进步的瓶颈，加深了它阻碍创新的印象。因此，为了解决这个问题，我们必须从存储开始。 为什么冰山？ 开放表格格式简介为了理解开放表格格式的重要性，从数据湖的不足之处开始是有帮助的。如前所述，数据湖有许多优点——其 Apache Iceberg在众多开源表格格式中脱颖而出，因为它从第一天起就是围绕互操作性、开放性和引擎独立性进行设计的——不受任何单一计算引擎或供应商路线图的限制。 中包括成本效益、灵活性和可扩展性——但也有显著的权衡。因为它们本质上是一个没有共同事务元数据层的文件集合，数据湖无法原生支持ACID（原子性、一致性、隔离性、持久性）事务。这意味着，如果在写入过程中工作失败，它就会戛然而止；然后，你将面临半成品、损坏的数据。而且因为没有版本控制，清理这些数据需要花费大量时间和精力。此外，数据湖的“读取时模式”方法常常导致管道故障，因为即使是一点小的模式更改——添加一个列或更改数据类型——也会导致下游所有内容失败。这些问题带来的麻烦比解决方案多，不久之后，许多数据湖变成了浑浊、混乱的数据沼泽。 在本质上，Iceberg 是以规范为先。也就是说，它是通过一个开放且严格管理的规范来定义的，而不是通过参考实现。这意味着任何引擎——无论是 Spark、Flink、Trino、Snowflake、Hive 还是未来的引擎——都可以一致地实现 Iceberg，无需逆向工程。相比之下，Delta Lake 和 Hudi 历来与其主要引擎紧密耦合，这可能会微妙地影响有效互操作性。 ake和Apache Hudi，提供了一层元数据，使得ACID事务、模式演化和时间旅行成为可能。它们还支持多引擎访问，以便不同的查询和处理引擎可以针对一致的表表示进行工作。但如前所述，选择正确的开放式表格式对于互操作性至关重要。Apache Iceberg（见侧边栏），特别是由于其支持任何操作的全套供应商中立访问，除ACID保证和高效的文件级操作外，已经获得了巨大的吸引力。这允许分析引擎在规模上自信地读取和写入共享数据集，将原始文件集合转换为一个可靠、可治理和互操作的数据层。 行级删除等功能以干净、与引擎无关的方式实现，避免了查询端的复杂性以及分区泄漏。模式和分区演变是一等、可预测且安全的。 放式数据架构和多引擎分析的理想基础。 这些表格，然而，需要一个目录作为元数据存储库和所有数据湖中数据的权威真相来源。目录不是将所有表元数据内部存储，而是维护每个表的当前元数据文件的指针，并对其进行原子更新（使用比较和交换操作）。当涉及到冰山目录——例如，Apache Po