作者:
(1) Sasun Hambardzumyan,Activeloop,加利福尼亚州山景城,美国;
(2) Abhinav Tuli,Activeloop,美国加利福尼亚州山景城;
(3) Levon Ghukasyan,Activeloop,美国加利福尼亚州山景城;
(4)Fariz Rahman,Activeloop,美国加利福尼亚州山景城;
(5) Hrant Topchyan,Activeloop,美国加利福尼亚州山景城;
(6)David Isayan,Activeloop,美国加利福尼亚州山景城;
(7)Mark McQuade,Activeloop,美国加利福尼亚州山景城;
(8) Mikayel Harutyunyan,Activeloop,美国加利福尼亚州山景城;
(9) Tatevik Hakobyan,Activeloop,加利福尼亚州山景城,美国;
(10) Ivo Stranic,Activeloop,加利福尼亚州山景城,美国;
(11)Davit Buniatyan,Activeloop,加利福尼亚州山景城,美国。
在本节中,我们讨论非结构化或复杂数据管理的当前和历史挑战。
通常不建议将二进制数据(例如图像)直接存储在数据库中。这是因为数据库并未针对存储和提供大文件进行优化,并且可能导致性能问题。此外,二进制数据不太适合数据库的结构化格式,因此很难查询和操作。这可能会导致用户加载时间变慢。与其他类型的存储(例如文件系统或云存储服务)相比,数据库的运营和维护成本通常更高。因此,在数据库中存储大量二进制数据的成本可能比其他存储解决方案更高。
大规模分析和 BI 工作负载的增加推动了压缩结构化格式(如 Parquet、ORC、Avro)或临时内存格式(如 Arrow [79, 6, 20, 13])的开发。随着表格格式的普及,出现了扩展这些格式的尝试,例如 Petastorm [18] 或 Feather [7] 以用于深度学习。据我们所知,这些格式尚未得到广泛采用。这种方法主要得益于与 Modern Data Stack (MDS) 的本机集成。但是,如前所述,上游工具需要进行根本性的修改才能适应深度学习应用程序。
目前,用于存储大型非结构化数据集的云原生选择是对象存储,例如 AWS S3 [1]、Google Cloud Storage (GCS) [3] 或 MinIO [17]。与分布式网络文件系统相比,对象存储确实提供了三个主要优势。它们是 (a) 成本高效、(b) 可扩展和 (c) 用作与格式无关的存储库。然而,云存储并非没有缺点。首先,它们会带来显著的延迟开销,尤其是在迭代许多小文件(例如文本或 JSON)时。其次,没有元数据控制的非结构化数据提取会产生“数据沼泽”。此外,对象存储具有内置版本控制;它很少用于数据科学工作流程。最后,对象存储上的数据在训练之前会被复制到虚拟机中,从而导致存储开销和额外成本。
以 Delta、Iceberg、Hudi [27, 15, 10] 为首的第二代数据湖通过管理具有以下主要属性的表格格式文件来扩展对象存储。
(1)更新操作:在表格格式文件顶部插入或删除一行。
(2)流式传输:具有 ACID 属性的下游数据提取和公开 SQL 接口的查询引擎的上游集成。
(3)模式演化:在保持向后兼容性的同时演化柱状结构。
(4)时间旅行和审计日志跟踪:使用回滚属性保留历史状态,查询可以重现。此外,还支持对数据沿袭进行行级控制。
(5)布局优化:内置功能可优化文件大小和数据压缩,并支持自定义排序。显著加快查询速度。
然而,第二代数据湖仍然受到深度学习所用固有数据格式的限制,如前文第 2.2 节所述。因此,在本文中,我们通过重新考虑格式和上游功能(包括查询、可视化和与深度学习框架的本机集成)来扩展第二代数据湖在深度学习用例中的功能,以完成如图 2 所示的 ML 生命周期。