大规模使用结构化流Lakehouse实现

托马斯Magdansk…:你好。我要告诉你,你不会找到任何书籍或一个博客。我将与你分享真正的障碍你会试图建立大型数据时遇到湖。我将简要谈谈Asurion。我们是如何走到这一步的?如何运行可伸缩的和具有成本效益的lakehouse吗?最重要的是,教训。
我们是一家大型保险公司和支持。每天超过10000的专家参与支持会话来帮助世界各地的超过3亿人,从技术支持和服务跨越同一天设备修理和更换。只是给你一个想法关于这个项目的大小,我们lakehouse吸入超过4000表,从100 +数据库。我们创建七个半千datalake只有两个表的表里面,我以后再谈。我们摄取流数据从卡夫卡、运动、社交和SQS,以及文件、平面文件和数据api。
我们甚至做其他云提供商的数据。从SQL server数据库来源,甲骨文,PostGreSQL, MySQL动态开始红移。在数据仓库中,我们把成千上万的那些表生产超过300 600年数据模型和数据集市。最后,在我们的消费层中,我们有超过10000个数据视图和超过2000报告。我们之前的架构是基于Lambda架构。正如你可能知道,λ架构包含速度层和批处理层,还有几个问题。首先,你有两次来处理一切。你也必须验证数据两次,通常你需要使用不同的技术。或者你必须处理后期数据到不同的方面,你需要担心后处理的数据在大多数不变的空间。你必须担心调度,重写和查询。 Data updates are also really difficult, which makes the data compliance more difficult.
我们没有电脑存储分离的困难和昂贵的可伸缩性。我们的数据延迟主要是d 1,我们也有一个非常广泛的技术堆栈。从红移到λ,运动,运动消防带,EMR, rds,蜂巢,频谱。很难管理。然后我们看了看湖的房子建筑只有一个单一的管道。我们有一个实时数据延迟功能,可伸缩性的Apache火花,一个很高程度的综合生态系统,技术堆栈真的非常狭窄。这是非常,非常有前途。
另一个重要的进步,帮助开发了利用直接的生产数据。我们旨在尽可能最小化数据运动和利用计算机存储分离。开发数据平台,获得真实的生产数据bob体育客户端下载来识别并修复许多微妙的问题,以及处理实际规模是我们在开发环境中无法复制。这个结果对我们来说是非常可取的。我们用我的角色和挂载点透明连接pre-product计算集群在只读模式,我们也生产数据写入数据回生产包。因此,数据没有长期居住环境,真正的计算和存储部分分离。这张照片很重要,我们会回到吸取的一个教训。
现在在我们之前的体系结构中,我们有一个ETL每表映射工作,使平台非常严格。bob体育客户端下载4000年我们有有效的映射,如果你需要做出改变在许多映射,这是一个大量的工作平台是抵制改变,因为改变事物的复杂性。bob体育客户端下载在湖边的房子,我们想创建一个火花摄入的工作是能流和批处理和阅读所有的来源和完全可配置的,我们写这份工作在Scala中使用设计模式和依赖注入允许非常富有的可配置性。我们选择结构化流利用检查点,确切或至少一个语义和我们统一的接口,我们的着陆区,S3和卡夫卡。数据库,疾控中心管道、api、平面文件都上传到S3和SNS SQS和运动都是上传到卡夫卡。然后我们安排我们的摄入工作使用砖作为股工作和临时性集群。这完全允许高度测试,易于维护和非常灵活的代码。
我们的数据湖三角洲表中的所有表。作为数据湖的一部分,我们需要保持一个缓慢变化维度只类型附加表跟踪更改所有行和列和分数,我们称之为L1表,但是我们也需要存储相关版本的每一行,像搜索引擎(听不清)类型通过合并更改目标表和我们称之为L2表。我们有一个选择。你从着陆区结构流流数据从L1, L2 L1,然后呢?但这将有效工作从4000年到8000年的两倍。因此,广泛的测试后,我们决定利用权力为每个批处理API来编写两个表在同一时间。如果你…智力盒大大地简化,但我们不实际使用裸火花。我们的读者和作家环绕火花。我们也装修我们的数据大量增加强制性元列在打造一批。
下一个选择,我们必须在触发选择和一种原生方法问题是取出摄入的工作,这是一个流媒体工作,把它作为一个短暂的工作。的挑战,现在的我们有4000个表运行和砖碎片只允许1000个工作岗位。和最重要的是,这些短暂的集群会有司机和至少两个节点,这将使我们在12000个节点环境中,这有点奢侈,我们不觉得这是最好的利用资源。下一步我们看着结合许多流工作在笔记本和运行作为一个短暂的工作,我们发现了一种甜点司机处理大约40流。
当然集群必须大处理所有流,但是我们也已经注意到相当高度的电脑浪费因为在这些40流,可能会有流经常没有数据,但我们让他们运行所有的时间。这种方法的另一个问题是,如果我们想要禁用一个单独的数据流,我们有效地不得不停止工作,将停止所有40的流。所以我们想找出一种更好的方式能够换一份工作或者把它从笔记本笔记本或集群,集群不需要停止所有其他工作。最后,我们选定了一个触发器,以及那些可能不知道触发一个选择结构化流,将收集的所有数据到你的马克斯•流或数量的文件或字节的过程数据,然后检查点进程终止工作。
所以你真的负责调度微批次当你想让他们运行。这意味着没有连续执行,这允许我们在笔记本上把数以百计的工作在一个短暂的集群。现在,因为这些工作是运行在时间表,我们可以迁移他们的笔记本轮之间。我们还可以刷新在每一轮每一轮冲突,所以唯一的配置更改我们没有任何重启立即生效。我们也正在使用机器学习振兴工作在不同的集群,以确保我们满足我们学校图书馆的数据。我们有五种类型的笔记本电脑运行短暂的工作,和那些笔记本有一个小组分配给他们。他们去数据库,配置数据库,他们收集所有属于这个群体的工作要处理,然后运行(听不清)系列的这些工作,或通过使用集合力量,我们可以麻痹工作执行所有课程的数量,司机,这通常是16和32两个工作同时运行。
我们有5个口味的笔记本。我们有一个经常更新的东西,我们可以把大约60个表每一个笔记本。我们的目标是在60分钟内完成所有的更新和合并。我们有更少的频繁更新的表,我们可以把300年到500年。然后经常更新表,我们可以把多达一千。这种方法的好处是,我们可以在频率和表,日益增长的移动这些组之间无缝和无缝地平衡这些工作没有资源或影响其他工作,组内运行的。
我们也可以实现我们称之为伪流通过y-loop笔记本运行工作,我们测试和性能非常接近只是运行处理触发,让火花处理micro-batches的执行。除了我们可以检查每个y-loop的配置上,这意味着如果我们有五个工作运行,我们想禁用其中之一,我们只是禁用其中一个,和下一个迭代是不会在其他四个没有重新启动运行。
好吧。所以让我们继续我们的教训而建立这样一个大规模的湖环境。嗯,首先,让我们来谈谈云文件。对于那些不知道,云文件自动加载程序的一部分,提供的砖,当你使用AWS和试图读取一个文件夹,砖的文件夹将自动创建一个S3通知将使它成为一个社交网站,然后它会的SNS, SQS订阅订阅一个社交网络。现在,首先,AWS只允许每斗100通知。所以你要写一些自动化来知道你已经饱和通知后端,你可能需要部署一个新类型的工作在接下来的桶。
接下来,SQS和SNS不是标记在默认情况下,至少今天。如果你像我们一样或需要标记的所有你的资源,你要骑某种λ或某种功能的通知和检测到砖创建资源在您的帐户,并适当地标记它们。最后,AWS api, SNS已经硬限制ListSubscriptions ListSubscriptionsByTopic,砖使用这些api来检查是否已经有…SNS已经一个SQS订阅。如果你运行足够的就业机会,就像我们运行成千上万的工作同时,我们已经看到时间达到这些限制,我们的工作失败。今天唯一的选择就是为了解决这一问题是是否存在非常缓慢的表不改变很多,在那里我们可以做禁用通知,或者只是传播他们更多的时间来努力避免这样做。但在某种程度上,我们将达到的规模,我们只是会遇到这些问题。
好吧。另一个教训,我们了解了云文件。我回到数据计算隔离幻灯片,我之前讲过。从另一个账户,所以当你pre-prod计算请求数据从生产账户,砖将设立一个通知,它将建立一个社交网站,然后它会建立一个SQS。但是如果你注意到,SNS和SQS的账户计算,不是的账户存储。
这工作和你的测试工作,太好了,你准备部署到生产环境。你你的工作部署到生产环境中。你犯同样的请求数据,而这一次砖创建一个SQS队列仅仅是因为一个SNS已经存在,对吗?现在,是的,你的生产数据,但是整个云通知和文件贯穿pre-prod环境中,当然有问题。我们部署期间我们要做的是清理通知,生产运行工作第一,让生产工作建立了SNS和SQS,然后开始SNS的预生产跳订阅的主题。这是最后一步,但这是一个额外的步骤在我们我们要做和自动化部署过程。
好的,下一个。我们把数据从成千上万的数据库表通过AWS DMS,和我们使用CDC变化数据捕获流动。所以当你第一次去尝试使疾病预防控制中心在桌上,你必须做两件事。你必须使负载和疾控中心。负载是什么意思是,这是一个表的快照在那个特定的时间,然后疾控中心是一个过程,需要被记录的数据库后跳过每个角色的变化。现在,我们发现这个设置的挑战是加载文件可能需要数小时和疾控中心文件正在被跟踪一旦你开始你的工作。所以有机会有一个对象(听不清)的中心部分管道之前,将有一个时间戳,加载文件完成,现在加载文件分配的时间戳。
所以你有一个加载文件版本的时间戳的行之前,疾病预防控制中心更新版本的行。所以我们重置DMS加载文件的时间戳为零,以避免这种竞争条件。再上一节课我们学过DMS和疾病预防控制中心是数据类型转换,因为DMS可以连接到任何数据库,我们发现有时候不交谈正确的数据类型。举个例子,我们是一个SQL服务器,一个小小的Int转换为单位,我们已经看到一些溢出,我们必须应用的规则,你可以看到在底部幻灯片来迫使它返回一个整数。在Oracle中,例如数字转换为小数(38岁,10),有一个选项来设置到38岁,38岁,但举个例子,在Oracle数据库、数字列是一个精密的50。所以我们没有办法把数据。我们必须设置设置称为numberDataTypeScale - 2,这有效地转换成一个字符串。
另一个教训。加载文件可以大,他们可以当你读斜数据。所以你可能需要做一些盐。DMS文件不分区,所以考虑压实或只是意识到将会有很长一段时间被火花读过你的DMS桶。如果你几个月后重新启动,会有成千上万的小文件。我们将DMS删除所有的文件当我们开始任务,只是一张白纸,试图缓解这问题,减少数据重复。数据库上有消息来源可能有大量的事务。
让我带你回去。当我们有多个更新在一个micro-batch一行,我们必须决定哪一个是延迟。这个说我们想要合并到目标表,和开始的时候我们认为我们能使用时间戳,因为通常他们去毫秒或微秒,但我们发现,如果你手动打开一个大型事务数据库中,和你把很多更新事务的同一行到你关闭交易,所有的更新有完全相同的时间戳。所以你是不可能的,以确定哪些是最新的。所以我们必须把所有数据库的LSN通过DMS,以确保我们有某种确定的合并和获得最新的行。
现在,我们已经学会了另一个教训是,如果数据库没有主键,但有一个独特的约束,您可以使用合并,约束包含null值,源的null值很多,Databrick合并三角洲不会认识到零,零匹配的时候,它会插入新行。所以我们必须做的是替换所有的null字符串null或空字符串确定的合并。
关于卡夫卡教训。如果你使用卡夫卡对于某种疾病预防控制中心管道模式,也有可能,你可能已经表没有很多交通,和你不想配置大量的分区和浪费大量的资源对卡夫卡的小桌子,但实际上初始加载的数据实际上可能带来数百万行到主题。现在你有一个主题,没有大量的分区,但它有很多的数据和你不一定想re-partition主题仅一读。所以我们建议设置最低分区和马克斯抵消/触发高数。在我们的例子中,我想我们分区4000和抵消10000强制引发瘫痪的重量这个话题,无需重新分配速度。
我们也使用我们的第一个我们写的L1表。我们优化表内每一批,然后我们把它作为一个源L2合并。这是为了避免一个动作,第二个动作,回到源,因为源可以是缓慢的。DMS可以停止因为这个数字的文件或卡夫卡在这种特殊情况下也可以是缓慢的。总之,我们采用了模式添加一批数据帧ID列,我们写L1,我们优化如果需要,然后使用相同的批ID来过滤数据从L1合并。我们发现这个模式比回到源,更快或者缓存如果你有大量的数据,也会慢一些。
我们学会了与卡夫卡的其他课程。嗯,我们想要使用触发器一旦一切尽可能多我们有选择,运动和其他来源不支持这个的。所以我们必须将所有的SNS, SQS,运动到卡夫卡使用卡夫卡连接,然后我们可以使用支持…我们可以用卡夫卡触发一次做这份工作完全相同的方式为我们所做的工作,例如,在DMS。
对三角洲的教训。第一次,当你把数据表手动优化你的,因为你会更快(听不清),然后使三角洲优化写道,因为合并重写大量的数据。优化写非常好合并和找出文件的大小,所以你不需要经常做压实优化。移动你的批处理ID和合并列dataframe面前。
所以Databrick收集统计数据帧的第一行。如果你有一个很宽的数据帧,你不会得到末期可能列上的统计信息,特别是如果你只是增加了批ID,这将是最后一列。你需要批量ID过滤,例如。所以移动一切你要合并,寻找dataframe的前面。如果你使用一个合并列增量,像汽车更新的数字,例如,等等,您还可以使用命令数据在同一个地点协同工作,进一步减少文件数量,需要阅读和跳过它的数据。我们也一直推荐使用分区和使用i3与IO缓存实例类型三角洲。
所以其他的教训。如果你有任何其他的工具,需要阅读三角洲,像我们,例如,我们使用很快,你必须写S3路径,当你注册你的蜂巢中δ表。因为很快不会理解DBFS,它不会明白(听不清),所以我们必须手动创建表定义,把S3路径。如果你想让你的三角洲文件读写的雅典娜,或者只是蜂巢一般来说,或者频谱,您需要生成manifest文件manifest文件和启用自动更新。这种方式,non-Delta或non-Delta事务,地方(听不清)技术仍然可以manifest文件读取铺文件。
转眼间和火花视图不兼容。只是需要注意的东西,因为如果你创建一个视图在火花,转眼间不会能够利用它和其它的方法。我们还发现,提取δ统计行数,最后修改成热缓存实际上是非常可取的,因为我们需要很多的工作负载前表更新,许多依赖表更新。假设你有任何TL要求30岁,40表更新。拥有一个运行集群和发行40描述命令是缓慢的只是为了确定你可以运行工作。所以通过提交这些统计数据的每一个热缓存,下一份工作只是读取现金和决定了我所有的表都更新,我很好,我现在可以去安排工作。
好吧。最后,三角洲和火花一起流的δ表,但目前,截至今天,它只适用于附加。它是有意义的,因为当你添加三角洲表,您将新文件插入到表和事务日志,和任何人听表知道有新文件和读取新文件。这很有道理。现在与合并,这是更复杂,因为合并重写所有的数据。是的,有一个新创建的文件和文件可能有一百万行,但我们只在该文件更新一千行。如果你在该文件下管道,你必须过滤下来的几百万行几千行,实际上已经改变了。和我们如何做呢?
再次,我们利用批处理ID,我们添加了早先知道新批,27岁,我只接27日的数据,因此过滤大量小文件。这不是最有效的,但它工作得很好。最后,SQL分析一下我们如何使用SQL分析。所以我们的数据集市是由超过1000个SQL查询和语句的集合。我们需要一个数据集市的方式解除,从以前的实验室平台转移到这个平台,所以我们需要良好的可扩展的SQL执行引擎。bob体育客户端下载当然,火花,我们想利用现有的框架我们已经到位并提交SQL语句通过JDBC连接器火花集群。第一个选项是使用交互式集群,但是他们是相当昂贵的。
所以我们更向也许EMR开源火花和和三角洲。当SQL分析产品走进我们的范围和它仍然支持JDBC连接,所以这是一个完美的适合我们能够发送这些SQL查询和创建数据集市。一些经验教训到目前为止,因为它是一个早期的产品是我们必须收集所有的度量api和把它们放在三角洲表监视和性能。你是只允许使用一元店/ SQL工作区,这意味着如果您有多个不同的SQL端点,他们都要分享一元商店,这是不同于集群,我们可以在每个集群配置不同的元商店。所以我们有点约束的分离计算和存储和跨帐户和使用元店真的绑在一起。
它还不支持UDF。所以如果你需要一个(听不清),你仍然要依靠集群互动引发SQL,您可以附加罐子和这次将没有罐子SQL分析。最后,你还要学会排除火花。所以你还是要学会理解熟练的技艺和火花的工作和SQL意见火花UI,因为这仅仅是一个引发下面工作。因此可有效发现瓶颈在你的查询,你仍然要这样做。
好的,非常感谢。这是问答时间。谢谢你,请提供你的反馈。我们想要听的。我们想提高内容的质量,我们与你分享,如果你有任何问题,如果你想联系我离线,请随时联系我在LinkedIn。谢谢你！