Lakehouse的崛起

与数据的快速进化湖,比利博斯沃思和阿里Ghodsi分享彼此的想法的五大常见问题被问到关于数据仓库,数据lakehouses和湖泊。来自不同的背景,他们每个人都为这一市场提供独特而有价值的见解。阿里已经花了十多年的前沿研究分布式数据管理系统;加州大学伯克利分校的副教授;现在的联合创始人兼首席执行官数据砖。比利已经花了30年的数据作为一个开发者,数据库管理员和作者;曾担任首席执行官和高级主管软件公司专门从事数据库;在上市公司董事会任职,目前Dremio的首席执行官。

与数据湖泊出现了什么问题?

阿里Ghodsi
让我们先从一个好事之前的问题。他们使企业捕获所有他们的数据-视频/音频/日志——不仅仅是关系数据,他们这样做,在一个廉价的和开放的方式。今天,多亏了这一点,绝大多数的数据,特别是在云中,在数据湖泊。因为他们是基于开放格式和标准(例如拼花和兽人),还有一个巨大的生态系统的工具,通常开源(例如Tensorflow, Pytorch),可直接作用于这些数据湖泊。bob下载地址但在某种程度上,只是为了收集数据收集不是很有用,没有人关心你收集多少pb,但你做了什么生意?你提供什么业务价值?

结果很难提供业务价值,因为数据沼泽湖泊经常成为数据。这主要是由于三个因素。首先,很难保证数据的质量是好,因为数据只是甩了进去。第二,很难管理,因为它是一个文件存储,和推理关于数据安全是困难的如果你唯一看到的文件。第三,很难得到性能,因为数据布局可能不是组织的性能,例如,数以百万计的微小comma-separated-files (csv)。

比利博斯沃思
所有技术进化,而不是思考“什么错”我认为这是更有用的理解就像第一个迭代。首先,单词之间有高度的相关性湖“数据”和“Hadoop。协会“这是可以理解的,但现在的能力可以在数据架构湖更先进、更容易比我们看到的on-prem Hadoop生态系统。第二,数据湖泊变得像沼泽,数据只是坐在和积累对业务没有提供真正的洞察力。我认为这是由于过于复杂的本地生态系统不正确的技术无缝和快速让消费者得到的数据洞察力他们需要直接从数据在湖里。最后,任何新技术一样,它缺乏一些成熟健壮的治理和安全等方面的数据库。发生了很多变化,尤其是在过去的几年里,但这些似乎是早期的一些常见问题。

你认为最大的变化在过去几年来克服这些挑战?

比利
事实上的上游架构决定是真正得到了球滚动。在过去的几年里,应用程序开发人员只是最简单的路径存储大型数据集,这是抛售他们在云存储。便宜,可伸缩,非常容易使用,云存储成为人们土地的默认选择云级别的数据网络和物联网的应用程序。数据的大量积累推动了创新是必要的,以直接访问数据,这生活与试图跟上传统数据库副本。今天,我们有一组丰富的功能交付的事情以前只能在关系数据仓库。

阿里
大技术突破是在2017年,当时三个项目同时启用建筑warehousing-like功能直接在数据:湖三角洲湖,Hudi和冰山。他们把结构、可靠性和性能湖泊坐在这些大规模数据集数据。开始支持ACID事务,但很快超越,与性能、索引、安全等等。这个突破是如此深刻,它发表在顶级学术会议(VLDB, CIDR等等)。

为什么要使用另一个新术语,“Lakehouse”来描述数据的湖泊?

阿里
因为它们是完全不同的从数据湖泊,认股权证不同的术语。湖泊往往成为数据沼泽的三个原因我之前提到的,所以我们不希望鼓励更多的,作为企业的还不是很好。新学期也让我们有机会引导这些企业土地数据策略,可以提供更多的商业价值,而不是重复过去的错误。

比利
如果你看看像维尔纳•沃格尔博客从2020年1月强调开放数据湖的巨大优势和功能架构,你看到一个巨大的进化从如何数据甚至湖泊被认为仅仅几年前。主要适用于数据分析用例只认为是可能的在数据仓库。因此,术语“Lakehouse”带来的新内涵,当前世界开放数据架构,允许新的协会丰富的数据分析功能。当底层技术大幅进化,新创建的名字往往代表新功能。这就是我认为我们看到的术语“Lakehouse。”

为什么考虑Lakehouses吗?为什么不继续使用数据仓库?

比利
今天的数据问题只是有点不同于过去,他们是根本,绝对不同。在许多问题上与数据仓库是时间。不是时间运行一个查询,但是所花费的时间数据团队获取数据的数据仓库使用ETL作业的迷宫。这个高度复杂的数据移动和复制链引入了繁重的变更管理(“简单”改变仪表板绝非简单),增加了数据治理风险,最终减少数据可供分析的范围,因为子集会创建与每个副本。

我经常听到人们谈论“简单”的数据仓库。缩小一点,你总能找到令人目眩的相互连接的网络数据复制和移动工作。这不是简单的。问题是,为什么要通过复制和移动如果你没有?在一个Lakehouse设计原则是,一旦点击数据存储、湖那是它停留的地方。湖和数据已经达到数据存储、分析团队之前也不愿透露太多。为什么?因为我之前说的,开发人员现在使用它作为事实上的目的地数据尾气。一旦它的存在,为什么把它别的地方吗?Lakehouse,你不需要。

阿里
最重要的原因是机器学习和人工智能,这是非常对大多数企业战略。数据仓库不支持稀疏数据集ML / AI用途,如视频、音频和任意文本。此外,与他们交流的唯一方法是通过SQL,这对许多目的是惊人的,但不是ML /人工智能。今天,一个巨大的开放的生态系统软件是建立在Python, SQL是不够的。今天最后,绝大多数的数据存储在数据湖泊,所以迁移到数据仓库的成本几乎是不可能的,。

除了消除数据拷贝,你个人认为Lakehouse的最大优点是什么?

阿里
直接对ML /人工智能的支持。这是冰球。谷歌不会在今天如果不是人工智能或毫升。这同样适用于Facebook, Twitter,乳房,等软件正在吞噬这个世界,但AI会吃所有的软件。本地Lakehouses可以支持这些工作负载。如果我可以提一个以上的优势,我认为已经有大规模数据集数据湖泊、和Lakehouse范式使利用这些数据。简而言之,它让你清理你的数据沼泽。

比利
我花了我的整个职业生涯与数据库,以及几乎所有的操作。我最近搬更多的数据分析的世界,坦率地说,我觉得我是在一个时间机器当我看到数据仓库模型仍然被使用。世界在操作方面,架构早已从大、整体服务。采用这些基于服务的体系结构是完整的,它几乎不值得一提。然而,当你看一个数据warehouse-centric架构,就像看着一个从2000年应用程序体系结构。基于服务的体系结构的所有优点适用于分析世界就像他们所做的操作。Lakehouse旨在使您的数据可访问任意数量的服务你希望,开放格式。真正关键的今天和未来。基于模块化、最佳服务架构已被证明是卓越的运营工作负载。Lakehouse架构允许分析世界迅速赶上。

实现Lakehouse意味着“撕裂和替换”数据仓库吗?

比利
也许最好的关于实现Lakehouse架构可能是您的应用程序团队已经开始了旅程。公司数据集已经可用,可以很容易地开始实施Lakehouse架构。解除从数据仓库是没有必要的。最成功的客户实现我们看到的从单个用例开始,成功地实现它,然后问“我们其他用例应该实现直接在Lakehouse而不是复制数据在数据仓库中?”

阿里
不,它不。我们还没见过有人这么做。相反,数据仓库成为Lakehouse的下游应用,就像许多其他的事情。你的原始数据落在湖的数据。Lakehouse允许您牧师到精炼数据集模式和治理。的子集,然后可以进入数据仓库。每个人都是这样开始的,但随着用例Lakehouse获得更多的成功,几乎所有的企业我们最终与越来越多的直接工作负载Lakehouse移动。