数据湖学习文档
参考资料：https://segment.com/blog/cultivating-your-data-lake/
培育数据湖 我们经常听到企业希望对客户数据做更多的事情。他们想要获得数据信息，他们想要提供更好的客户体验，最重要的是，他们只想了解他们的客户。
到达那里并不容易。您不仅需要收集和存储数据，还需要识别有用的部分并根据洞察采取行动。
在Segment，我们已经帮助成千上万的企业走上了数据获取的道路。我们多次看到的一个成功的技术是建立一个工作数据湖。
数据湖是一个集中的存储库，它存储结构化和非结构化数据，允许您在一个灵活的、经济有效的存储层中存储大量数据。数据湖越来越受欢迎，一方面是因为企业拥有的数据比以往任何时候都多，另一方面也是因为收集和存储数据从来没有像现在这样便宜和容易。
在这篇文章中，我们将深入研究在使用数据湖时要考虑的不同层。
我们将从一个对象存储开始，比如S3或谷歌云存储，作为一个廉价而可靠的存储层。 接下来是查询层，如Athena或BigQuery，它允许您通过一个简单的SQL接口来探索数据湖中的数据。 中心部分是一个元数据存储，如AWS Glue目录，它将所有元数据(其格式、位置等)与您的工具连接起来。 最后，您可以利用顶层的转换层(如EMR)来运行聚合、写入新表或以其他方式转换数据。
作为AWS中所有这些工具的忠实用户，我们将分享一些关于AWS生态系统中客户数据的示例、提示和建议。这些相同的概念也适用于其他云和更远的地方。
S3存储层:
如果您从这篇博客文章中获得了一个想法，那就是:在S3中存储数据的原始副本。
它便宜、可扩展、非常可靠，并且与AWS生态系统中的其他工具配合得很好。S3的全部存储费用很可能每月不到100美元。如果我们纵观我们的整个客户基础，只有不到1%的客户每月为分段收集的数据支付超过100美元的S3账单。
也就是说，S3的简单性是一把双刃剑。虽然S3是保存所有数据的好地方，但它常常需要做大量的工作来收集数据、加载数据并实际获得所需的信息。
在S3上收集和存储数据时，有三个重要的因素需要牢记:
编码——数据文件可以用任意多种方式编码(CSV、JSON、Parquet、ORC)，每种方式都有很大的性能影响。 批处理大小——文件大小对上传策略(和数据新鲜度)和查询时间都有重要影响。 分区方案——分区是指数据的“层次结构”，数据的分区或结构化方式会影响搜索性能。
代码语言：javascript复制 在数据湖中构建数据我们将更深入地讨论其中的每一个，但是首先值得了解的是数据是如何首先进入数据湖的。
有许多方法可以将数据放入S3，例如通过S3 UI或CLI上传数据。但是如果您讨论的是客户数据，那么很容易通过段平台将数据交付给S3。Segment平台提供了收集、清理和控制第一方客户数据的基础设施，并将所需数据准确地发送到所需的所有工具中。
编码
文件的编码对查询和数据分析的性能有重大影响。对于较大的工作负载，您可能希望使用诸如Parquet或ORC之类的二进制格式(我们已经开始在本地支持这些格式了)。如果你想要测试访问，请联系!)。
要理解其中的原因，请考虑一下机器在读取JSON与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中，我们预先定义了模式，并最终将数据列存储在一起。下面是之前以拼花格式转换的JSON文档示例。您可以看到用户一起存储在右侧，因为它们都在同一列中。
右侧显示存储在一起的用户 读取器不必解析并在内存中保留对象的复杂表示形式，也不必读取整个行来挑选一个字段。相反，它可以快速跳转到它需要的文件部分并解析出相关的列。
下面是一些查询JSON和Parquet的具体基准测试，而不只是相信我的话。
在这四个场景中，我们都可以看到使用拼花地板的巨大好处。
如您所见，我们需要在每个实例中查询的数据对于拼花来说是有限的。对于JSON，我们需要每次都查询每个JSON事件的完整体。
批量大小
批处理大小(即每个文件中的数据量)很难调优。批量太大意味着在出现打嗝或机器故障时，您必须重新上传或重新处理大量数据。拥有一堆太小的文件意味着您的查询时间可能会更长。
批量大小也与编码相关，我们在上面已经讨论过了。某些格式如Parquet和ORC是“可分割的”，文件可以在运行时被分割和重新组合。在某些条件下，JSON和CSV是可分割的，但通常不能分割以获得更快的处理速度。
通常，我们尝试和目标文件的大小从256 MB到1 GB不等。我们发现这是最佳的整体性能组合。
分区
当每个批处理中开始有超过1GB的数据时，一定要考虑如何分割或分区数据集。每个分区只包含数据的一个子集。这通过减少使用诸如雅典娜之类的工具查询或使用EMR处理数据时必须扫描的数据量来提高性能。例如，按日期划分数据是一种常见的方法。
查询
最后，值得理解的是，仅仅将数据放在S3中并不能真正直接帮助您完成本文开头所讨论的任何事情。这就像有一个硬盘，但是没有CPU。
有许多方法可以检查这些数据—您可以下载全部数据，编写一些代码，或者尝试将其加载到其他数据库中。
但最简单的是编写SQL。这就是雅典娜发挥作用的地方。
查询层:雅典娜
