我们经常听到，企业希望对客户数据做更多的事情。他们希望得到数据信息，他们想提供更好的客户体验，最重要的是他们只想了解他们的客户。您不仅需要收集和存储数据，还需要确定有用的部分并根据见解采取行动。在Segment，我们已经帮助数千家企业走上了一条通向更多数据信息的道路。一个成功的技术我们已经看到一次又一次建立一个有效的数据湖。数据湖是一个集中的存储库，存储结构化和非结构化数据，并允许您在一个灵活、经济高效的存储层中存储大量数据。数据湖变得越来越受欢迎，一方面是因为企业拥有比以往任何时候都多的数据，而且收集和存储所有数据的成本从未像现在这样便宜和容易。在这篇文章中，我们将深入研究数据湖工作时要考虑的不同层面。我们将从对象存储开始，例如S3或Google云存储，作为一个廉价可靠的储藏室层。下一层是查询层，企业系统开发，如Athena或BigQuery，它允许您通过一个简单的SQL接口来探索数据湖中的数据。中心部分是一个元数据存储，如AWS Glue Catalog，它将所有元数据（其格式、位置等）与工具。最后, 您可以利用上面的转换层（如EMR）来运行聚合、写入新表或以其他方式转换数据。As对于AWS中所有这些工具的大量用户，我们将为AWS生态系统中的客户数据共享一些示例、提示和建议。这些相同的概念也适用于其他云和超出存储范围Layer:S3如果你从这篇博客文章中得到一个想法，网站自助建站系统，那就是：在S3中存储数据的原始副本。它便宜，可扩展，积分返现，非常可靠，并且与AWS生态系统中的其他工具配合得很好。你的S3存储账单很可能每月花费不到一百美元。如果我们纵观我们的整个客户群，不到1%的客户的S3账单超过每月100美元，也就是说，云服务器品牌，S3的简单性可能是一把双刃剑。虽然S3是保存所有数据的好地方，海淘客，但收集数据、加载数据并真正获得所需的见解通常需要大量工作。在S3上收集和存储数据时，需要记住三个重要因素：编码-数据文件可以通过多种方式进行编码（CSV、JSON、Parquet、ORC），每个人都能有很大的表现暗示.batch大小–文件大小对上载策略（和数据新鲜度）和查询都有重要影响times.分区scheme–分区是指数据的"层次结构"，数据的分区或结构化方式可能会影响搜索性能。结构data Lakew中的数据将更深入地讨论这些问题，但首先需要了解数据是如何首先进入数据湖的。但是，如果你谈论的是客户数据，那么很容易通过细分平台将数据交付给S3。细分平台提供了收集、清理和控制第一方客户数据的基础设施，并将所需内容准确发送到所有需要的工具编码文件的编码对查询和数据分析的性能有很大的影响。对于大型工作负载，您将希望使用Parquet或ORC之类的二进制格式（我们开始在本机支持这些格式）。如果你想要试用版，请联系！）。为了理解其中的原因，考虑一台机器在读取JSON vs Parquet时需要做什么，当查看JSON时，数据如下所示：{'userId'：'user-1'，'name'：'Lauren'，'company'：'Segment'}{'userId'：'user-2'，'name'：'Parsa'，'company'：'Segment}{'userId'：'user-3'，'company'：'Microsoft'，'name'：'Satya'}{'userId'：'user-4'，'name'：'Elon'，'company'：'Tesla'}在这里，我们不仅要解析整个消息，还要分析每个键和每个值。因为每个JSON对象可能有一个不同的模式（而且是完全无序的），所以我们必须对每个对象执行大致相同的工作行。另外，即使我们只是挑选公司或名称，我们也必须分析所有数据。我们没有"捷径"可以跳到指定行的中间。与拼花地板相比，我们看到了一个非常不同的模式。在Parquet中，我们预先定义了模式，最后将数据列存储在一起。下面是先前以Parquet格式转换的JSON文档的示例。您可以看到用户被存储在右侧，因为它们都在同一列中。请参见右侧的用户存储在一起，读取器不必解析并保留对象的复杂内存表示，也不必读取整行来选择一个字段。相反，它可以快速跳转到它需要的文件部分并解析出相关的列。而不是下面是几个查询JSON和JSON的具体基准测试镶木地板。在在这四个场景中，我们都可以看到使用拼花地板。如您可以看到，我们需要在每个实例中查询的数据是有限的镶木地板。对于JSON，我们需要每时间。批次SizeBatch大小（即每个文件中的数据量）很难调整。如果批处理过大，则意味着您将不得不重新上载或重新处理大量数据，以防出现故障或机器故障。拥有一堆太小的文件意味着您的查询时间可能会很长更长。批量大小也与编码有关，我们在上面讨论过。某些格式如Parquet和ORC是"可拆分的"，其中文件可以在运行时拆分和重新组合。JSON和CSV在某些情况下可以拆分，但通常不能拆分得更快加工。一般，我们尝试将目标文件的大小从256MB到1GB。我们发现这提供了最佳的整体性能组合。分区当您开始在每个批处理中有超过1GB的数据时，考虑如何分割或分区数据集是很重要的。每个分区只包含数据的一个子集。这通过减少使用Athena之类的工具查询或使用EMR处理数据时必须扫描的数据量来提高性能。例如，划分数据的一种常见方法是日期查询最终，值得理解的是，仅仅将数据保存在S3中并不能真正直接帮助您完成我们在文章开头所讨论的任何事情。这就像有一个硬盘，但是没有CPU。有很多方法可以检查这些数据-你可以下载所有的数据，写一些代码，或者尝试将它加载到其他数据库中。但是最简单的方法就是编写SQL。那就是雅典娜来的地方in.查询图层：雅典娜