TileDB 2.0与数据科学的未来

TileDB是一个开源的云原生存储引擎，用于分块、压缩、多维数组。它引入了一种通用的数据格式，该格式对所有应用程序域都足够通用，并且具有内置的数据版本控制功能。它提供了许多API和数据科学工具集成。今天，我们宣布TileDB2.0，这对我们的社区和公司来说是一个巨大的里程碑。

这些功能标志着我们为所有应用程序和数据科学工具提供通用数据存储引擎，并塑造数据科学的未来之旅迈出了重要的一步。

TileDB是一个数组存储引擎，提供超高效的多维(密集和稀疏)数组切片。但是它能处理数据帧吗？

很容易看出数据帧如何等同于稀疏数组。选择数据帧列的任何子集(选择用于快速切片的列)，并将它们定义为“维”。然后，您的数据帧记录将成为稀疏多维空间(即稀疏数组)中的点。因此，这是TileDB的理想情况。

到目前为止，TileDB支持同构维度，即具有相同数据类型的维度。这对于像LiDAR(具有双坐标的三维点)这样的数据很有效。然而，我们意识到它对数据帧是有限制的，在数据帧中，人们可能希望分割不同类型的列，比如Date(DateTime)和Price(Double)。此外，许多数据帧还具有用户需要切片的字符串列(例如，Name或StockSymbol)。TileDB 2.0添加了异构和字符串维，现在完全支持DataFrame用例。

数据科学家使用流行的柱状数据帧格式已经有一段时间了。向TileDB 2.0添加数据帧支持的重要性源于其他特性，这些特性使TileDB成为一个强大的存储引擎，而不仅仅是一种平面文件格式。更具体地说：

TileDB高效地支持内置到其格式和存储引擎中的本地数据版本控制。其他格式不支持数据更新或时间旅行；您需要在应用程序层构建自己的逻辑，或者使用额外的软件来充当文件顶部的数据库。

TileDB围绕云对象存储上的并行IO和多线程计算(如排序、压缩等)实现了各种优化。

TileDB也是“列式”的，但它提供了更高效的多列(即多维)搜索。

有了TileDB，您可以继承越来越多的API(C、C++、Python、R、Java、Go)、后端支持(S3、GCS、Azure、HDFS)和集成(例如Spark、MariaDB、PrestoDB、Dask)，所有这些都由TileDB团队开发和维护。

TileDB 2.0不仅仅是一种专栏格式；它还是一个成熟的数据管理解决方案，它从单一的数据库发展而来，充当一个可与您喜欢的所有数据科学工具配合使用的可嵌入库。

数据科学家正处于十字路口。一方面，跨应用程序域和特定于域的软件有多种数据格式用于解析和分析数据。另一方面，数据科学家希望拥抱越来越多的通用开源数据科学工具，以实现快速分析、可视化和可伸缩性。他们面临的挑战是，他们的数据需要从遗留格式转换成通用工具可以理解的“东西”，这是一个漫长、繁琐和低效的过程。

使用任何流行的数据科学工具。您会注意到，它希望数据采用两种数据格式中的一种。数据帧(即，表)或多维阵列(例如，特征向量、2D图像、3D视频等)。例如，所有传统的关系数据库和工具(如Pandas和data.table)都在数据帧上操作；NumPy、Xtensor和所有基于线性代数的机器/深度学习工具都在数组上操作。

键值商店呢？可以将键值存储视为包含一个或多个“键”列和一个或多个“值”列的数据帧，其中对键列的快速搜索(切片)非常重要。

因此，绝大多数应用程序和工具都在数据帧和阵列上工作。如上所述，数据帧也是数组。数据帧支持的增加，再加上云优化格式以及内置的数据版本控制和元数据处理，使TileDB 2.0成为在单个开源、可嵌入的库中提供通用数据格式的唯一存储引擎。

存储引擎，无论功能多么强大，与独立库相比都没有意义。数据科学家使用分析工具快速进行科学发现，并不真正关心文件、格式或存储后端。此外，每个数据科学家在编程语言和工具方面都有自己的偏好。为此，我们花了巨大的精力来构建和扩展TileDBAPI集(C、C++、Python、R、Java、Go)和集成(Spark、Dask、MariaDB、PrestoDB、GDAL、PDAL)。

TileDB 2.0为您带来了一个完全改版的TileDB R API。我们很幸运，Dirk Eddelbuettel，几个流行的R包的(共同)作者/维护者，也是R基金会的董事会成员，加入了我们的行列，完成了这项工作。我们想让TileDB成为R生态系统中不可或缺的一部分，并且刚刚开始与其他关键的R包进行集成，比如tidyverse和Bioconductor。

我们看到越来越多的用户和客户转向云，以获得负担得起的存储和可扩展性。TileDB 2.0在现有的AWS S3支持的基础上增加了对Google云存储和Azure Blob存储的支持。

TileDB为所有支持的后端抽象化IO。与传统文件系统相比，云对象存储带来了额外的挑战，例如最终一致性、对象不变性、增加的网络延迟和成本等等。TileDB针对此类云对象存储进行了优化，可以处理所有细节-高效地更新您的阵列并管理底层云存储对象。此外，TileDB这样做不会影响其他后端的性能，例如笔记本电脑上的文件系统或Lustre和HDFS等分布式文件系统。

最重要的是，即使出现了新的文件系统，TileDB抽象体系结构也是可扩展的，可以无缝地支持新的文件系统，从而允许您使用相同的TileDB API和集成。

70年代的单一数据库，2020年的遗留文件格式。我们是不是回到了70年代，构建了比平面文件格式更多的东西？不用谢!。有了TileDB，我们可以将两个世界中最好的一个连接起来。

我们都知道，存储和计算必须分开，这样它们才能独立扩展。而且存储必须是开源和可互操作的。而且，今天很明显，计算必须不仅仅是SQL。TileDB是一个成熟的数据引擎，可以处理“所有事情的存储”：压缩、切片、高效IO、版本控制、元数据。无论您使用的是关系数据库还是Spark、Dask等工具，这些因素都保持不变。因此，我们决定超高效地一次性构建此存储引擎，供所有人使用。

下一个挑战是计算。数据科学家在语言和工具上有不同的偏好，所以我们选择了与一切集成。您可以使用MariaDB、PrestoDB和Spark执行SQL，或者使用Dask运行分布式线性代数，所有这些都在同一个TileDB阵列上，从而避免多次数据转换和复制。

我们正在进行的工作更进一步：我们不断识别跨语言和工具的公共操作，并将它们推向TileDB。例如，过滤操作在MariaDB、Spark、Dask和NumPy中很常见；我们意识到不需要多次实现它。我们正在努力使此类操作更接近存储，以提高性能。

数据科学的未来就在这里。我们既是软件开发人员，又是数据科学社区的协作者，我们的愿景是将数据争论中浪费的时间降至最低。卓越的性能和易用性始于多维数组和围绕数组构建的通用API。TileDB 2.0是一个重要的里程碑。请查看我们的Github，并与我们一起踏上这段旅程。