我们很高兴在公开预览版中引入一个新功能—Auto Loader—和一组合作伙伴集成，它允许Databricks用户从各种数据源增量摄取数据到Delta Lake。autoloader是apachespark的一个优化的云文件源，它在新数据到达时从云存储中连续有效地加载数据。合作伙伴集成的数据接收网络允许您将来自数百个数据源的数据直接摄取到Delta Lake中。把所有的数据汇集在一起组织在各种数据源中都有大量的信息。从数据库（例如Oracle、MySQL、Postgres等）到产品应用程序（Salesforce、Marketo、HubSpot等）都可能有所不同。大量的分析用例需要来自这些不同数据源的数据来生成有意义的报告和预测。例如，一份完整的漏斗分析报告需要来自各种来源的信息，从hubspot中的潜在客户信息到Postgres数据库中的产品注册事件。只将所有数据集中在数据仓库中是一种反模式，因为Python/R库中的机器学习框架无法有效地访问仓库中的数据。由于您的分析用例从构建简单的SQL报告到更高级的机器学习预测，因此您必须以开放格式使用来自所有数据源的数据构建一个中央数据湖，并使其可用于各种用例。自从去年我们开放了Delta Lake的源代码以来，有成千上万的组织以一种比以前更可靠、更高效的开放格式来构建这个中央数据湖。Delta Lake on Databricks提供ACID事务和高效的索引，这对于为各种访问模式（从BI工具中的即席SQL查询到预定的离线培训作业）公开数据至关重要。我们将这种以开放格式为数据构建一个集中、可靠和高效的单一真实源的模式称为"湖边小屋"，该模式适用于从BI到ML的各种用例，并将其分离存储和计算。图1。Delta Lake的通用数据流。数据被加载到摄取表中，在连续的表中细化，然后被用于ML和BI用例。建造湖边小屋的一个关键挑战是将来自不同来源的所有数据汇集在一起。根据您的数据旅程，数据团队有两种常见的场景：从第三方数据源摄取数据：您通常在各种内部数据源（从Hubspot到Postgres数据库）中拥有有价值的用户数据。您需要为它们编写专门的连接器，以便从源中提取数据并将其存储在Delta Lake中。云存储中的数据摄取：您已经有了一种将数据从您的源拉入云存储的机制。当新数据到达云存储时，您需要识别这些新数据并将它们加载到Delta-Lake中进行进一步处理。从第三方来源摄取数据从内部数据源摄取数据需要为每个源编写专用的连接器。使用源API构建连接器并将源模式映射到Delta Lake的模式功能，这可能是在时间和精力上的巨大投资。此外，随着源代码的api和模式的发展，您还需要维护这些连接器。维护问题与您拥有的每一个额外的数据源都有关系。为了让您的用户更方便地访问Delta Lake中的所有数据，我们现在与一组数据摄取产品合作。这个由数据摄取合作伙伴组成的网络已经构建了与Databricks的本地集成，以便直接在您的云存储中摄取和存储Delta Lake中的数据。这有助于您的数据科学家和分析师轻松地开始处理来自不同来源的数据。azuredataricks客户已经从与azuredatafactory的集成中获益，可以将来自不同来源的数据摄取到云存储中。我们非常高兴地宣布新的合作伙伴集—Fivetran、Qlik、Infoworks、StreamSets和Syncsort—帮助用户从各种来源获取数据。我们还正在扩展这一合作伙伴的数据接收网络，不久将有来自Informatica、Segment和Stitch的更多集成。图2。数据摄取合作伙伴生态系统和一些流行的数据源，您可以通过这些合作伙伴产品将数据拉入Delta Lake。从云存储获取数据ETL工作负载中的一个常见工作流程是在数据到达云blob存储时增量处理新数据并使其准备好进行分析。然而，以低成本、低延迟和最少的DevOps工作，从云blob存储连续加载数据是很难实现的。一旦数据进入Delta表，多亏了Delta Lake的ACID事务，就可以可靠地读取数据。要从Delta表流式传输数据，可以使用Delta源（Azure | AWS），它利用表的事务日志来快速识别添加的新文件。然而，主要的瓶颈是将落在云存储中的原始文件加载到Delta表中。天真的基于文件的流源（Azure | AWS）通过反复列出云目录并跟踪看到的文件来识别新文件。由于重复列出文件，越来越多的文件被添加到目录中，因此成本和延迟都会迅速增加。为了解决这个问题，数据团队通常会解决以下问题之一：高端到端数据延迟：尽管数据每隔几分钟到达一次，但您可以将数据批处理在一个目录中，然后按计划处理它们。使用基于日或小时的分区目录是一种常见的技术。这就延长了SLA的长度，以使数据对下游消费者可用。手动DevOps方法：为了保持较低的SLA，您还可以利用云通知服务和消息队列服务在新文件到达消息队列时发出通知，然后处理新文件。这种方法不仅涉及所需云服务的手动设置过程，而且在需要加载数据的多个ETL作业时，管理起来也会很快变得复杂。此外，重新处理目录中的现有文件包括手动列出文件并在云通知设置之外处理它们，从而增加设置的复杂性。Auto Loader是一种优化的文件源，它克服了上述所有限制，并为数据团队提供了一种无缝的方式，以低成本和低延迟加载原始数据，而DevOps的工作量最小。您只需要提供源目录路径并启动流作业。新的结构化流媒体源名为"cloudFiles"，它将自动设置文件通知服务，从输入目录订阅文件事件，并在新文件到达时处理它们，还可以选择处理该目录中的现有文件。图3。使用低sla实现一次数据摄取需要手动设置多个云服务。自动加载器可以直接处理所有这些复杂的问题。使用自动加载器的主要优点是：无文件状态管理：当新文件在云存储上着陆时，源文件将以增量方式处理。您不需要管理关于到达的文件的任何状态信息。可伸缩性：源代码将利用云服务和RocksDB有效地跟踪到达的新文件，而不必列出目录中的所有文件。即使目录中有数百万个文件，这种方法也是可伸缩的。易于使用：源将自动设置增量处理文件所需的通知和消息队列服务。你这边不需要设置。使用自动加载器进行流式加载通过利用Apache Spark熟悉的load API，您可以从对流作业进行最小的代码更改开始：spark.readStream.format（"云文件"）.选项（"cloudFiles.format"，"json"）.load（"/input/path"）自动加载器的定时批量加载如果您的数据每隔几个小时才来一次，那么您仍然可以在使用结构化流式处理的计划作业中利用自动加载器触发器。一次模式。值df=spark.readStream.format（"云文件"）.选项（"cloudFiles.format"，"json"）.load（"/input/path"）df.writeStream.trigger(触发器。一次).格式（"delta"）.start（"/output/path"）您可以使用Databricks Jobs Scheduler（Azure | AWS）将上述代码安排为每小时或每天运行一次，以增量加载新数据。使用上述方法，您不必担心延迟到达的数据场景。使用COPY命令调度批加载喜欢使用声明性语法的用户可以使用sqlcopy命令按计划将数据加载到Delta-Lake中。COPY命令是幂等的，因此在发生故障时可以安全地重新运行。该命令会自动忽略先前加载的文件，并保证只执行一次语义。这使得数据团队能够轻松地构建健壮的数据管道。命令的语法如下所示。有关更多详细信息，请参阅COPY命令（Azure | AWS）的文档。复制到表标识符FROM{location |（从location选择identifierList）}FILEFORMAT={CSV | JSON | AVRO | ORC |拼花}[文件=（''[，''][。。。] ) ][模式=''][格式选项（'dataSourceReaderOption'='value'，…）][复制选项（'force'={'false'，'true'}）]图4。具有新特征的三角洲湖数据摄取。使用自动加载器的流式加载保证了一次数据摄取。可以等幂重试使用COPY命令的批加载。数据摄取功能入门将所有数据放入数据池对于机器学习和业务分析用例的成功至关重要，对每个组织来说都是一项巨大的任务。我们很高兴引入Auto Loader和合作伙伴集成功能，以帮助我们成千上万的用户构建一个高效的数据湖。这些功能今天作为预览版提供。我们的文档提供了有关如何开始合作伙伴集成（Azure | AWS）、自动加载程序（Azure | AWS）和