选择数据湖格式：实际上需要看什么
选择数据湖格式：需要看什么
最近我们看到了很多关于各种不同数据湖文件格式的帖子。有Delta Lake、Hudi、Iceberg和QBeast等等。
要跟踪所有这些数据湖格式是很困难的——更不用说弄清楚为什么（或者是否！）我们真的需要如此广泛的选择，更重要的是，对于给定的使用情况来说，哪个数据湖是最好的。
简短的答案是：所有这些特殊的数据湖格式都是为了让您的数据可以直接查询。
- ChatGPT的行为随时间变化吗？研究人员评估了GPT-3.5和GPT-4的2023年3月版和2023年6月版在四个不同任务上的表现
- 游戏领域中的8个现代人工智能示例
- 使用FastAPI和PyTorch模型在Amazon EC2 Inf1和Inf2实例上优化AWS Inferentia的利用
这是一件好事，但它不应该是你的数据湖的主要目的。
让我们更详细地讨论一下：如何选择最佳的数据湖格式，同时，为什么你不应该太担心格式。我们——Estuary的工程师们认为还有更重要的东西。
我很好奇你是否会同意。
直接查询和您的数据湖选项
有很多优秀的工具可用于执行各种类型的查询。
你有像Elasticsearch用于全文搜索，TimescaleDB用于时间序列数据，Pinecone + ChatGPT用于询问有关您的数据的对话性问题，PostGIS用于地理空间数据等等。
针对索引和查询数据，存在大量不同的系统、策略和算法。而且这完全有道理！数据的世界是巨大的。即使在一个小型到VoAGI的企业中，您所拥有的数据类型以及您希望利用数据的方式都会有很大的多样性。
因此，尽管直接查询数据湖的工具很强大，有时非常有用，但它们充其量只是一个不错的附加功能。
无论您的数据湖格式有多棒，它都无法击败PostGIS的地理空间查询，或者Elasticsearch的全文搜索，或者……你懂的。即使在直接查询数据湖可以工作的情况下，它很少是最佳工具。
更重要的数据湖特性
那么，如果我们不担心直接查询，那么如何选择——或者说设计——一个数据湖呢？
在一个较高的层面上，我和我的团队认为，数据湖应该优先考虑集成而不是查询能力。
与其试图构建整个基础架构围绕一个声称能够做到一切的全包式数据存储系统，更重要的是，您的数据湖能够轻松利用更广泛的分析工具生态系统。
您可以反过来使用这些工具来做它们擅长的事情：对您的数据提问。
我们如何相信这一点…
我们Estuary团队之所以如此坚信数据湖的特性，是因为我们建立了一个数据湖。
对于那些新来的人：我们的平台Flow实际上是一个实时ETL工具，但它也是一个具有事务支持的实时数据湖。在构建Flow时，我们没有使用任何上述的数据湖格式。
相反，我们只使用了换行分隔的JSON。我们之前曾写过为什么JSON是一个好选择，但我想进一步扩展这个特定的方面：优先考虑集成而不是直接查询。简而言之，这就是Flow方法的不同之处——无论是在ETL和数据湖的世界中。
我们知道，无论我们多努力，我们都不能为所有或大多数用例提供足够的查询能力。
相反，我们专注于集成。当您将Flow作为您的数据湖时，您可以轻松地将数据从您的湖中材料化到日益增长的其他各种系统中，这些系统会自动实时更新。
这样，您可以使用最适合您场景的工具查询您的数据。
实际上为您选择最佳的数据湖
在您开始点亮火炬之前，我想澄清一点，查询您的数据湖并不是坏事。我也不能坐在这里断言我们在Flow中使用的先集成的方法对您的需求是正确的。那样会有点傲慢，更不用说在不了解您的情况下无法确定。
直接查询可能是您特定场景下最佳的方法有很多原因。如果您就是这样的情况，您已经知道自己是谁。您已经知道您需要运行的查询类型和您的期望结果。对您来说，从市场上各种数据湖格式中进行选择只是一个比较功能和测试查询的问题。
但是，如果您希望从整体上为不同的业务领域提取更多的数据价值，改进直接查询数据湖的性能可能不会给您带来很大的好处。
另一方面，使数据更容易移动到其他系统确实会产生很大的影响。这意味着您可以自由地为每个场景使用最佳工具。也许同等重要的是，它使您能够尝试不同的系统，以找出什么才是最佳工具。
对于您，在搜索数据湖时，我的建议是：不要过于关注数据格式或查询能力。相反，更仔细地看看集成和数据进出湖的方式。您将获得更好的查询能力，更快乐的用户以及更大的灵活性。
对于选择数据湖的讨论您有什么想法吗？我们很乐意听取。
虽然我们几乎总是关闭博客上的评论（即使是大部分工程师的团队也会受到评论机器人的困扰，难以置信），但我们的大门始终敞开在Slack上。
文章作者：Estuary的工程师Phil Fried
