数据湖与数据仓库的未来
数据湖的未来
George: 我想以一个热门话题开始讨论，至少在这个圈子里是热门话题——数据湖。数据湖是一个模糊的术语，不同的人用它来表示不同的东西，但为了本次讨论的目的，让我们将数据湖定义为存储在开源文件格式（如Parquet或ORC）中的表格数据（即表、行和列），这些数据位于公共云对象存储中，如某中心的S3或某机构的云存储。
在一个数据仓库使用对象存储来存储数据并赋予你数据湖部分优势的世界里，数据湖是否还有存在的空间？Martin，从你开始，数据湖有未来吗？
Martin: 我们行业最大的谬误之一是我们看待一个架构时，会说，哦，它能做所有这些事情，因此它将被推去完成所有这些任务。但这并不是技术演进的方式。我们根据技术主要用例在设计空间做出决策。
如果你看看数据仓库的用例，它们主要由分析驱动，这是某种工作流程，某种查询模式。而数据湖则完全不同。它们往往包含更多非结构化数据，专注于操作型AI，计算密集型。如果你看看各自的技术，它们在这个巨大的设计空间中只是针对不同用例进行了优化。
从架构上讲，当然，它们都可以做对方能做的事情，但最终，你有围绕用例优化的产品和公司。我认为操作型AI用例规模更大，增长更快。所以实际上我认为随着时间的推移，可以说是数据湖最终吞噬一切，而不是数据仓库。
George: 你只是想激怒Bob吧，Martin。
Bob: 你成功了。
Martin: 我在观察Bob的表情。
George: 好吧，Bob。听听你的看法。数据湖，它有未来吗？
Bob: 不，我认为这些东西很大程度上会收敛到基于关系型SQL的模型。五年后，数据将位于SQL提示符后面，SQL数据仓库将取代数据湖。
从存储结构化和半结构化数据的角度来看，云SQL数据仓库已经完成了所有必要的工作，人们真的没有理由拥有单独的数据湖，除了历史先例。许多公司来自在Hadoop环境中拥有大量半结构化数据的环境，拥有数据湖是一个自然的过渡。在某种意义上，数据湖（实际上是S3存储加上你想放在其上的任何工具）是一个非常通用的平台。
但是，随着时间的推移，基础设施会演进以承担越来越多的用例。SQL关系型数据仓库已经发展到这样的程度：对于结构化和半结构化数据的存储和查询，它们几乎囊括了今天需要完成的所有工作。剩下的是图像、视频、文档、PDF。
现在我不称那为非结构化数据。我认为这是一个误称。没有非结构化数据这种东西。所有数据都有某种结构。结构化数据是表、行和列。半结构化数据就像JSON，本质上是层次结构的。我认为还有第三类数据，我称之为复杂数据：图像、文档、视频。大多数流式数据都属于这一类，并且越来越多的机器学习可以应用于这些数据源的内容，将其转化为可用于构建复杂数据应用程序和执行预测分析的半结构化数据。
所以今天数据仓库缺失的是对复杂数据的支持。但这将会到来。这被称为一个功能。你能想象如果你能在数据仓库中完全交易所有这些类型的图像、视频和东西以及任何半结构化数据源吗？这将开启的应用程序是惊人的，这将在未来两到三年内到来。
Michelle: 我可以想象图像可以很容易地从数据库中检索。但是你是否真的认为所有的图像处理或视频处理也会在数据库中进行？
Bob: 不是用SQL。SQL做不到这一点。你至少现在会使用过程逻辑和Python或其他东西来做这件事。从长远来看，关系型也会获胜，但那可能更像是8到10年后的事情。
Martin: 我想我们已经等了40年了，Bob。
Bob: 我们有，但看看发生了什么。随着时间的推移，20世纪80年代的导航和层次结构被SQL取代。OLAP在过去10年左右被SQL取代。我们用关系型取代了MapReduce。所有这些事情，关系型总是获胜。
Michelle: 关系型在实际检索方面获胜，但处理呢？处理图像所需的技术与检索数据记录的技术根本不同。
George: Tristan，你有什么想法？
Tristan: 我完全同意SQL将主导数据处理，至少是很大一部分的数据处理，但是数据湖和数据仓库暴露了不同的API。有文件存储层，出于很多原因，我相信组织会一次性存储他们的文件。你不会有一个数据仓库的文件副本和一个数据湖的文件副本，这在今天的一些架构中是可以看到的。这要求你有一个开源文件格式，在你的数据仓库用例和其他用例之间共享。
在这之上，你有索引和元数据，这是数据仓库的核心部分，但也是数据湖的核心部分。我认为这些也必须开始收敛，以便不同的用例可以利用相同的东西。然后你有SQL提示符，也许在SQL提示符层，数据仓库占主导地位，但我认为你也需要允许不同的访问模式，因为一家闭源公司永远无法完成世界上所有的数据处理用例。
Bob: 所有这些都应该以开源和开放格式的方式互操作。但是格式的问题已经基本消失了，因为你可以非常容易地输入和输出任何类型的格式，并导出到任何类型的格式。
问题是：实际上需要对位于数据湖中的数据执行哪些操作？今天任何与复杂数据相关的操作，数据仓库都无法帮助你，所以今天有巨大的理由拥有一个数据湖。到2025年，我不这么认为。
我认为我们全球真正在创建五个平台：某机构、某中心，然后是三大云。某机构和某中心，虽然它们来自非常不同的地方——某机构将始终是SQL和声明式的方法，而某中心历史上肯定是过程式和基于代码的，所以在某种意义上是SQL与代码的版本——你会看到这两家公司以及几乎行业中的其他所有人都在他们的平台内提供两者。
Martin: 所以，你有两种技术，从不同的用例开始，有些不同的架构，但它们显然正在走向一个收敛点，即你有一些声明式的东西，也有一些过程式的东西。无论最终谁在谁之上，它们都能做两者。但是，与此同时，你有这个长达十年的旅程，在这个长达十年的旅程中，有一个围绕用例优化的架构。构建这些系统时所做的权衡和决策的数量是...
Tristan: 是的，比如TimescaleDB具有与某机构非常不同的特性，这些特性是针对工作流优化的。
Martin: 是的，整个公司专注于设计空间的不同点，具有不同的优化参数。是用例驱动技术，因为它周围的所有重力。所以，再次强调，如果事实证明AI/ML和操作型用途增长更快，看起来确实如此，那么从架构的角度来看，这将决定技术。
Tristan: Martin，你已经说了几次AI/ML领域似乎增长更快。我以前实际上没有听过这个说法。
Martin: 让我澄清一下。 broadly，有两个用例。有一个分析用例，由查询和仪表盘驱动。另一个是从数据科学家创建复杂模型，然后在生产中提供该模型。这可以做诸如等待时间预测、欺诈检测、动态定价之类的事情。这些是使用R语言的人在现有数据上构建复杂模型，然后想出一种定制的方式来提供这些模型。这现在非常明显地正在转变为由数据湖服务的模式。
现在它的基数要小得多，但如果你真正观察这个行业，这是一个快速增长的使用案例。
George: Michelle，你在数据科学界和分析界都花过时间，笔记本在某种程度上是这些东西有时汇聚的地方。我很想听听你对这两个堆栈如何演变的看法。也许它们正在收敛。也许它们正在互相构建对方的功能并变得越来越相似，但这会把我们带向何方？五年后我们是否还有两个堆栈？
Michelle: 我认为我们将继续看到越来越大的专业化，因为我们没有能力或预算雇佣足够的数据科学家。这些堆栈将继续演进，并且将根据他们试图做的事情进行专业化。
数据湖将有一席之地。你的图像、你的blob存储，所有这些可能将长期保留在数据湖中并有一个归宿。我只是认为它看起来不会像今天这样。今天，这只是对我们真正需要收集哪些数据缺乏了解。我们从一个极端走到另一个极端。我们过去不收集任何数据。现在我们收集一切，因为我们不知道什么是有价值的。现实是这也不一定是个好主意。
数据的移动，我认为我们会看到停止，但格式将非常重要。我们需要那种互操作性，因为大规模重新处理数据成本高昂，时间上也负担不起。如果我们可以避免，我们不想这样做。
我认为你会在这里看到去中心化，在较低层级，你或者有嵌入的业务单元，或者你有新的产品团队，你有嵌入这些产品团队的数据科学团队。你需要在最顶层有一个统一层，形式是使每个人更容易查询或提供信息的技术。
我认为笔记本可能最适合这个，因为它确实具有语言无关的方法。它让你能够同时查看数据和代码，并拥有所有上下文，丰富的业务上下文，可视化。我们将看到它演变为这种现代数据文档，我们可以将其用作我们统一层的一部分，因为你的数据科学家然后可以使用R工作，你的数据分析师可以使用SQL工作，但我们最终可以真正隐藏所有代码，并真正达到：我们做的这些事情的业务含义是什么？
两个堆栈会合二为一吗？
George: 这确实将我们带到了我想讨论的第二个主要话题，即：我们如何将机器学习、Python、Scala世界与分析、SQL、BI工具世界结合起来？确实有两个堆栈和两个社区，仅仅由于操作原因，将完全相同的数据源同步到Delta Lake和某机构。没有根本的技术原因，但这只是工具演进的方式。跨越那个边界太不方便了。
基本上有三个关于那个世界的愿景。一个是你将把机器学习放入SQL中，可能某机构的BigQuery在这方面走得最远。你基本上创建一堆做线性代数东西的UDF。另一个更多的是某中心的愿景，你把SQL放入Python或SQL放入Scala，并使用数据帧来做这件事。然后也许还有第三个愿景，你使用Arrow，交换格式，一切都可以互相通信，你可以以任何你想要的方式安排它。
你认为这些愿景中哪一个会获胜？
Michelle: 我希望看到类似Arrow的东西获胜，这样你就有互操作性。你会看到机器学习进入SQL，因为你会拥有完全有能力并且需要做一些异常检测或逻辑回归的数据工程师，这对他们来说只是另一种数据转换。但他们在统计方面没有相同的背景，所以他们只能做到这一步。
然后你会看到，在光谱的另一端，你的数据科学家拥有所有这些非常好的数学背景，并且他们懂得如何做更高级的深度学习，但他们没有技术技能。SQL是处理数据最成功的语言，所以你确实会看到两者都变得能够支持这两种用例。最终，你将继续看到专业化，因为如果你试图做深度学习，你想做的事情的类型与如果你只是试图做预测模型的事情根本不同。
Tristan: 我经常思考Arrow世界的愿景，我认为在充足的时间后，它最终会占主导地位，原因与Martin一直在谈论的相同：工具最终会演进到它们所服务的角色和用例。
我想做所有的数据准备和特征工程。然后我希望机器学习模型在上面训练。人们当然这样做。但是做这两件不同事情的基础设施通常是分开的，这造成了这种巨大的缓慢。这纯粹是技术上的缓慢。Arrow并不能解决所有这些问题。Arrow当然有帮助，但是，有一些愚蠢的事情，比如做那些事情的服务器在不同的云中。交换费用，你怎么称呼它们？
George: 出口费用。
Tristan: 出口费用很贵。
George: 它们是犯罪。不仅仅是贵。它们是荒谬的。
Tristan: 随着越来越多的人这样做，它会变得更顺畅。它们将变得更加本地化。
Martin: 你有多种语言是有原因的，不是因为一个是图灵完备的而另一个不是。原因是因为人们围绕语言和所有工具构建他们的整个工作流程，所以你将有一个异构的、碎片化的系统。因此你确实需要有开放的接口。
George: Bob？
Bob: 目前，我坚信拥有以通用格式交互的多个系统的方法。
Arrow在这方面是一个巨大的进步，不仅因为它是一种高效的格式，而且因为它为人们在他们的Spark环境中进行高级分析提供了一致的内存布局。世界现在就是这样运作的，因为大多数客户实际上分别拥有一个数据仓库和一个分析平台，并且他们正在将它们连接在一起。
现在，我将继续成为终极激进分子，然而，并声明我们今天在机器学习方面采取的方法仍然大致是汽车内燃机的方法。Arrow将那些预测系统与声明式数据库连接起来的方法，这实际上是混合动力或普锐斯时代的创造。
混合动力将在未来，比如说三到五年内占主导地位。你将看到每个主要供应商都在构建混合系统，所有系统都将拥有完整的预测堆栈和完整的声明式、关系型、SQL堆栈，使用某种类似的接口构建。但这只持续到关系型真正解决更广泛的问题集。
George: 这是否意味着你将使用SQL函数，PredictX，或者...？
Bob: 不。具有讽刺意味的是，我认为虽然SQL将在2030年代很好地主导数据建模和数据转换，但除此之外还有另一个步骤，即业务建模，这需要用知识图谱来表示。知识图谱是我们在2030年代进行预测分析的方式。需要发生的是基于关系知识图谱的全新一代数据系统来创建那个。
数据网格：去中心化团队，统一架构？
George: Michelle，你早些时候提到了一个我想跟进术语，即数据网格。我想知道你是否能为每个人简要定义一下，因为类似于数据湖与数据仓库，有一个问题，即未来这更多是一个历史现象还是一个我们想要继续的实际良好架构。
Michelle: 数据网格实际上是将数据处理、ETL和分析去中心化到每个独立业务单元的概念，然后在顶部有某种统一的解决方案。要做好这一点需要拥有专业的数据团队，拥有专业的角色，拥有可用于数据处理的基础设施即服务，然后拥有某种 overarching 标准委员会，几乎像你的数据工程师的联邦，以确保你所有的ETL看起来一致，这样当你在某个常见的查询工具上尝试进行数据检索时，你将拥有你需要的熟悉度。
我们将看到像Arrow这样的东西真正走到前台， sooner rather than later。我认为客户会要求它，因为我们现在面临的所有挑战。你有存储和处理的所有成本。试图进行处理的团队没有他们需要的业务上下文。结果，你有这种来回和大量浪费时间。你有很多数据质量错误。你多次拥有数据。最终，我们想把那部分知识体放在技术所在的地方，那里是知识体所在的地方。数据网格是尝试这样做。
Bob: 数据网格人员谈论的一部分是如何组织和构建一个团队来管理大型企业中非常不同和重要的数据源。这非常非常重要，数据网格中有一些好的想法。
在架构上，数据网格有这种奇怪的想法，即数据基本上是流式的，你可以使用像Kafka这样的设施，在数据飞行中进行转换。我不相信这一点。
虽然有流式数据，并且你可以对流式数据（换句话说，仅追加数据）做很多事情，但对我来说，另一个关键的数据源是来自业务系统的事务数据。流式解决方案对此没有答案，他们只是假装数据一致性不重要。我不明白这一点，因为当我考虑管理数据时，我把数据一致性放在我考虑的问题的首位。
Martin: 网格历来是这些将架构与管理域混为一谈的术语之一，以及 distant 服务网格，和 distant Wi-Fi 网格，以及网格网络等。我认为实际上Bob完全正确，即存在一个非常现实的问题，即单独的管理域、单独的处理域、对工具集的单独访问。这与构建完全分布式的架构非常非常不同，后者往往困难且低效。而且通常不是推广网格想法的人，但当人们听到网格这个术语时，他们默认完全分布，这往往只是构建系统的糟糕方式。
George: 说得像个网络家伙。
Martin: 在其他领域看到同样的事情发生了几十年。
Tristan: 我们都是非常注重技术的人类，所以当我们思考数据网格时，我们倾向于思考它的架构部分。Bob，我很高兴你指出了分布式团队和这方面的人员方面。我对数据网格的持续问题是：为什么你不能用一个统一的架构来实现你所说的分布式性质？
Michelle: 我的偏好总是拥有一个非常干净且被很好理解的数据集，我们不需要移动它，它与我们的大批量分析处理一起高性能地工作，这也与我们的数据科学一起工作。那是涅槃。目标是只有一个数据存储，然后有东西坐在它上面，每个不同的东西都针对每个不同的用例进行专业化，但你有一个数据存储。
现代数据堆栈的下一个用例
George: 现代数据堆栈不断吞噬越来越多的用例。它不久前杀死了Cubes。此时它 mostly 杀死了Hadoop。它不断将更多用例拉入其轨道，因为它从根本上如此灵活，如此能够足够好地做许多不同的事情，以至于你并不真的想为一种用例购买另一个系统，构建另一个系统。未来几年，有哪些最有趣、最令人惊讶、最重要的用例可能开始被拉入现代数据堆栈的轨道？
Bob: 复杂数据。我们现在在预测分析中发生了所有这些非常非常有趣的事情。对我来说，我们已经从半结构化数据作为最有趣的数据源，到现在拥有各种各样的数据源。我昨天与一家涉及医疗领域的公司交谈，仅仅是存在的丰富数据量，以及图像，以及医生的笔记，所有这些对我们今天的系统都是不透明的。五年后就不会了。那都将成为现代数据堆栈的一部分，对我来说，这对未来几年将创建的应用程序类型是一个巨大的转变。
Tristan: 我的上一份工作是为一家公司运营营销，我深入参与增长营销。你在那里遇到的问题是你不断编写代码在系统之间来回推送数据，因为不同的操作系统做不同的事情，而你需要在所有系统中拥有相同的数据。
还没有人重新架构系统，在现代数据堆栈中，只是获取所有你已经摄取的工作，现在将其推回你的操作系统或你的操作系统。但我认为我们正处于那的开始。
Bob: Tristan，你真正谈论的是现代数据应用程序的出现，它基本上是一个可以自主为企业做出决策的操作型应用程序。我们见过很少的这些和非常琐碎的示例，但 boy 它们在未来将是重要的。
George: 我见过数据应用程序的两种愿景。其中一种是数据应用程序是一个独立的系统，你从数据仓库中获取重要数据，然后推送它。然后另一种愿景是数据应用程序只是原生构建为运行在数据仓库之上。我很好奇人们是否对这两种模型有意见，以及他们看到那将走向何方。
Bob: 这实际上与我们一直在进行的关于这些东西如何构建的对话相同。数据应用程序是实际上采取自主行动的预测分析。它获取本来会呈现给一个人的数据，而是利用这些数据实际在企业内采取行动。它们今天以各种方式构建，因为很少有好的工具来构建数据应用程序。几年后就不会这样了。
延迟：我们需要多低？
George: 当你尝试构建数据应用程序并自动采取行动时，你遇到的事情之一是延迟变得极其重要。生态系统中的每个人此刻都在与此斗争。我认为关于我们将如何粉碎延迟问题以及我们需要它降到多低有很多不同的愿景。延迟需要多低？在什么点上我们拥有大多数有趣的用例？
Bob: 人们有几十到几百甚至几千个操作系统。越来越多地，它们是SaaS操作。它们在组织外部。它们现在始终是真相源。它们是现在，而数据仓库或数据湖是关于历史或过去。
那个延迟需要是多少？需要是零秒吗？我不这么认为。有些应用程序需要零秒或即时， mostly 与某种事件和警报有关。大多数时候，如果你能在一两分钟内得到它，你可以利用你历史系统中的该数据与预测分析开始对其执行操作。
Martin: 这是一个非常复杂的话题，我认为非常特定于用例。但是系统设计者往往在延迟和吞吐量之间做出严重的权衡。如果你想要更高的吞吐量，你就批处理。你批处理的原因是你没有尽可能多的域交叉。
然而，如果你看看大多数系统，你可以做出权衡。意思是你可以数据湖中做低延迟，你也可以数据仓库中做高吞吐量，或者反之亦然。这些不是架构限制。它们往往只是由于服务任何主要用例而做出的权衡结果。我听过许多这些延迟-吞吐量权衡讨论，你实际上深入到机器层面，它们只是系统投入时所做的权衡的结果。
George: 我们看到的一件有趣的事情是，你开始不得不花费更多来使延迟更低的点实际上比人们想象的要低。我怀疑你可以使用吞吐量优化的架构降到10秒范围内。基本上，我怀疑吞吐量优化的架构将比我们预期的降得更低。
Michelle: 你想象服务层会发生什么？你的网站仍然需要在该数据上运行。你想象那里将继续有一个缓存层吗？或者那将是一个独立的系统？
Bob: 这取决于系统需要具备什么特性。如果某些东西需要非常低的延迟，今天的数据仓库并不总是正确的解决方案。这完全取决于应用程序。这些产品中的延迟将会降低，但正如Martin指出的，一些架构选择使得某机构的延迟特性与，例如，MemSQL的延迟特性有些不同。
Tristan: 我希望在未来看到更多的事情之一是Lambda架构，但是使用现成的工具。所以我的数据流入一个更像流式的系统和一个更像批处理的系统，这样我就可以两全其美。当你构建这些系统时，你正在做出权衡。作为用户，我希望能够选择并拥有它们两者。
George: 嗯，我们只剩下一分钟了。我想问每个人一个是或否的问题：除了某机构、某中心、某机构、某中心和某中心之外，是否会出现另一个主要的数据平台？我们从你开始，Michelle。是或否？
Michelle: 是。
George: Bob？
Bob: 你的时间尺度是多少？
George: 在未来五年内。
Bob: 是。
Michelle: 是。
Bob: 但新的一个可能相对于那些家伙来说相对较小。
George: 嗯，我说的是主要的。那听起来像是一个介于...
Bob: 某机构五年前很小。
George: Tristan？
Tristan: 我认为不。
George: Martin？
Martin: 是。
George: 好的。非常感谢大家的加入。这是一次非常有趣的对话。我真的很感谢你们所有人在这里。我知道我们的观众也一样。
