Diego Link是倾斜点工程副总裁Tilling Point是新一代游戏合作伙伴，为顶级开发工作室提供专家资源、服务和运营支持，以优化高质量的直播游戏以获得成功。通过其用户收购基金和其世界一流的技术平台，倾点基金和经营业绩营销管理和现场游戏运营，帮助开发商实现盈利规模。在倾斜点，我们运行每日/每小时的批处理作业，以报告游戏分析。我们想让我们的报告接近实时，并确保我们能在5到10分钟内了解情况。我们还希望根据玩家的实时行为做出游戏内的实时操作决策，以便向捆绑和提供系统提供实时数据，对LiveOPs的变化提供最新的警报，这些变化实际上可能会产生不可预见的有害影响，甚至对游戏操作中的服务中断发出警报。此外，为了GDPR的目的，我们必须单独存储加密的个人识别信息（PII）数据。数据流动方式及相关挑战我们有一个专有的SDK，开发人员可以将数据从游戏服务器发送到AWS托管的摄取服务器。此服务删除所有PII数据，然后将原始数据发送到Amazon Firehose端点。然后firehouse将JSON格式的数据连续地转储到S3。为了清理原始数据并使其快速用于分析，我们考虑将连续数据从Firehose推送到消息总线（例如Kafka、Kinesis），然后使用Apache Spark的结构化流式处理数据并写入Delta Lake表。虽然这种体系结构听起来很适合于在几秒钟内处理数据的低延迟要求，但我们的摄取管道并没有这么低的延迟需求。我们想在几分钟内，而不是几秒钟内，将数据用于分析。因此，我们决定通过消除消息总线来简化我们的架构，而是使用S3作为结构化流作业的连续源。但是使用S3作为连续源的关键挑战是识别最近更改的文件。每隔几分钟列出所有文件有两个主要问题：更高的延迟：列出目录中包含大量文件的所有文件的开销很高，并且会增加处理时间。更高的成本：每隔几分钟列出大量的文件会很快增加S3的成本。利用结构化流媒体，以Blob Store作为源，Delta-Lake表作为接收器为了连续地从像S3这样的云blob存储中传输数据，我们使用Databricks的S3-SQS源。S3-SQS源代码为我们提供了一种简单的方法，可以增量地从S3流式传输数据，而无需对最近处理的文件编写任何状态管理代码。以下是我们的摄取管道：配置amazons3事件通知，通过SNS向SQS发送新的文件到达信息。我们使用S3-SQS源来读取到达S3的新数据。S3-SQS源从SQS读取到达S3的新文件名，并使用这些信息来读取S3中的实际文件内容。下面的示例代码：spark.readStream\.格式（"s3 sqs"）\.option（"fileFormat"，"json"）\.option（"queueUrl"，…）\.schema（…）\.加载（）然后，我们的结构化流作业会清理和转换数据。基于游戏数据，流作业使用Spark streaming的ForeachBatchAPI，写入30个不同的Delta Lake表。流作业生成大量小文件。这会影响下游消费者的表现。因此，每天都会运行一个优化作业来压缩表中的小文件，并将它们存储为正确的文件大小，这样数据的使用者在从Delta Lake表中读取数据时具有良好的性能。我们还为第二轮压缩运行每周优化作业。显示连续数据摄取到Delta Lake表中的体系结构上述三角洲湖摄取结构在以下方面有帮助：增量加载：S3-SQS源以增量方式加载S3中的新文件。这有助于快速处理新文件，而不会在列表文件中增加太多开销。没有显式的文件状态管理：不需要显式的文件状态管理来查找最近的文件。较低的操作负担：由于我们使用S3作为firehoose和结构化流作业之间的检查点，因此停止流和重新处理数据的操作负担相对较低。可靠的摄取：deltalake使用乐观并发控制来提供ACID事务保证。这有助于可靠的数据摄取。文件压缩：流式接收的一个主要问题是，表的结尾有大量小文件，这些文件可能会影响读取性能。在三角洲湖之前，我们必须设置一个不同的表来写入压缩数据。使用deltalake，由于ACID事务，我们可以压缩文件并安全地将数据重写回同一个表中。快照隔离：Delta Lake的快照隔离允许我们在数据被流作业附加并在压缩过程中修改时向下游消费者公开摄取表。回滚：如果写得不好，Delta Lake的时间旅行可以帮助我们回滚到表的前一个版本。结论在这个博客中，我们介绍了我们的用例，以及如何使用Databricks的S3-SQS源高效地将流式接收到Delta-Lake表中，而不需要太多的操作开销，从而使高质量的数据易于分析。 对开源的三角洲湖感兴趣吗？访问Delta Lake在线中心了解更多信息，下载最新代码并加入Delta Lake社区。 免费试用Databricks。今天就开始吧