我们在过去一年看到的主要主题是整合。
1、数据摄取
该层包括提供从操作系统到数据存储的管道的流技术和 SaaS 服务。
这里值得一提的演变是Airbyte的急剧崛起。Airbyte 成立于 2020 年，直到当年年底才转向目前的产品，它是一个开源项目，如今已被 15,000 多家公司使用。社区有超过 600 名贡献者。很少看到使用和社区呈指数级增长。
Airbyte 刚刚推出了其商业产品，并通过收购反向 ETL 连接器的开源软件 Grouparoo 扩展至反向 ETL（我们的图表中未涵盖的类别）。我们认为反向 ETL 与 ETL 是一个非常不同的产品，因为它需要以有利于用户在该系统中的工作流程的方式将数据集成到操作系统中。
2、数据湖
2021 年，我们将数据仓库和湖屋纳入数据湖层。但今年，我们决定仅将数据湖类别保留为用作数据湖的对象存储技术。我们将所有仓库和 Lakehouses 移至分析引擎类别。
为什么？
如今，数据工程师处理的大多数架构都足够复杂，包括对象存储和分析引擎。因此，您要么只需要一个分析数据库（在这种情况下，您没有数据湖，而是一个用作分析引擎的数据仓库），或者两者都需要。当您需要两者时，您通常会在对象存储上执行一些分析，而在分析引擎上执行一些分析。这就是为什么他们需要很好地合作。
这种依赖性发生在不同的层。大型数据集将在您的对象存储中进行管理，而工件和服务层数据集将存储在分析引擎和数据库中。他们中的一个会征服另一个的想法是我们在我们周围的建筑中没有看到的。
我们在现实中看到的是这些解决方案并存。这种架构背后有几个原因，其中之一肯定是成本考虑。在Snowflake或BigQuery中查询大量数据的成本很高。因此，您无需使用分析数据库管理整个湖，而是使用更便宜的计算来管理对象存储中的所有内容，并将所有必需品留给分析引擎。
我们认为 Lakehouse 是一个分析引擎（尽管在 Databricks 中它包括数据湖和分析引擎）。此架构具有 Spark SQL 的优化版本，可在 Delta 表格式上创建分析引擎。这提供了分析引擎预期的更高性能和成本。
相同的规则适用于基于Iceberg的Dremio，或支持Iceberg作为其数据库的外部表的Snowflake 。
3、元数据管理
元数据空间发生了很多事情！元数据的两层，这一层和我们图表顶部的组织层，正在成为许多组织的焦点。
回顾我们作为可扩展数据从业者所面临的挑战的演变，我们在过去十年中围绕存储和计算机进行了创新——所有这些都是为了确保它们支持数据规模。
今天，我们主要面临可管理性问题，可以通过生成和管理元数据来解决这些问题。这一层包括元数据的不同方面，让我们来看看它们：
表格格式：
- 在过去的一年中，我们看到了开放式表格格式的有趣进步。它们正在成为在数据湖中保存结构化数据的标准。
- 一年前，Delta Lake是一个Databricks项目，其中包含一个名为 Delta 的实际商业产品。然后今年，我们有Onehouse商业化的Apache Hudi和Tabular商业化的Apache Iceberg。两家公司都是由这些开源项目的创建者创立的。
- 因此，整个空间从开源变成了商业实体的完全支持。这给其他参与者对开源项目的影响力带来了一个问号，因为它背后有商业利益。
- 由于所有三个开源项目都是 apache/Linux 基金会的一部分，因此对社区的风险很低。这似乎并不能平息这三个项目的创建者和粉丝之间关于谁是“真正的”开源以及谁拥有最佳解决方案的激烈争论。Netflix 很快就会将这个故事作为戏剧节目的绝佳素材。
- Metastore 的未来仍不明朗……
用于数据的 Git：
- 用于数据的 Git 概念正在社区中占据一席之地。dbt 鼓励分析师对不同版本的数据（开发、阶段和生产）使用最佳实践，但不支持在数据湖中创建和维护这些数据集。
- DataOps 团队越来越需要提供跨组织的数据版本控制，以管理随着时间的推移具有不同修订的数据集。对数据集进行不同修订的一些示例是：重新计算，算法和 ML 模型所必需的，或在 BI 中经常发生的操作系统回填，或由于 GDPR 下的被遗忘权等法规而删除子集.
- 从我亲眼目睹的LakeFS及其社区采用的急剧增长中可以清楚地看出这一趋势。LakeFS 同时服务于结构化和非结构化数据操作，在两者都存在的情况下闪耀。
- 不幸的是，很难获得有关 Dremio 的Project Nessie使用情况的公开数据。有趣的是，它也可以作为名为北极的免费服务提供。这很可能是为了与 Tabular 竞争而做出的战略决策。
4、计算
今年我们对计算层进行了一些更改，以更好地反映生态系统。首先，我们将虚拟化作为一个类别完全删除。目前它似乎没有流行起来。
然后，我们将计算引擎分为两类：分布式计算和分析引擎。它们之间的主要区别在于这些工具对其存储层的看法。
虽然分布式计算包括对存储不执着的计算引擎，但分析引擎类别包含自以为是的计算引擎（分布式或非分布式）。
分布式计算：
- 通用分布式计算引擎允许工程师分发任何 SQL 或任何其他代码。当然，他们可能对编程语言固执己见，但他们会对（通常）联合数据进行一般分布。这可能是跨多种格式和来源存储的数据。
- 分布式计算类别的两个有趣的补充是Ray和Dask。
- Ray 是一个开源项目，允许工程师扩展任何计算密集型 Python 工作负载，主要用于机器学习。Dask 也是一个基于 Pandas 的分布式 Python 引擎。
- 您可能会认为Spark将成为在看不到竞争对手的情况下统治现场的分布式引擎。因此，目睹新技术的兴起在这一类别中获得关注是非常令人兴奋的。
分析引擎：
- 分析引擎类别包括所有的数据仓库，如Snowflake、BigQuery、Redshift、Firebolt和良好的旧PostgreSQL。它还包含像Databricks lakehouse、Dremio或Apache Pinot这样的湖泊仓库。所有的人对他们支持的数据格式都很有主见，以便为他们的查询引擎提供更好的性能。
- 由于所有的分析引擎都使用数据湖作为他们的深度存储或存储，值得一提的是，Snowflake现在支持Apache Iceberg作为外部表格式之一，可以由Snowflake直接从湖中读取。
5、编排和可观察性
这是一个由现有类别填充的新层。编排工具是去年元数据层的一部分，但我们将其移至它真正属于的计算引擎——它是关于跨计算引擎和数据源编排管道。
编排：
- Airflow仍然是最大的开源产品。Astronomer已经支持它几年了，自从该公司加入云计算的潮流以来，它现在直接与托管 Airflow 前沿的云提供商竞争。
- Astronomer 的另一个非常有趣的举措是收购了提供数据沿袭的 Datakin 。这让人不禁想知道——当编排工具具有沿袭功能时会发生什么？
从理论上讲，这可以帮助数据团队构建更安全、更有弹性的管道。通过了解哪些数据集依赖于丢失、损坏或低质量的数据，通过将逻辑（由编排工具管理）及其输出（在沿袭工具中管理）结合在一起，影响分析变得相当容易。这是否会成为编排生态系统的一个组成部分，还有待观察。
可观察性：
- Monte Carlo数据建立的可观测性类别也由它主导。蒙特卡洛 Monte Carlo频繁的筹资表明其产品在市场上的迅速采用。该产品不断发展，提供更多集成，例如数据块生态系统，以及额外的可观察性和根本原因分析功能。至少从今天探索这一领域的公司数量的角度来看，正是这种成功可能推动了该类别的增长。
- 2021 年有几家公司成立或隐身，最有趣的是Elementary，另一个 YC 之外的开源项目
6、数据科学 + 分析可用性
该层适用于通过前几层创建的数据架构的用户：从数据中挖掘洞察力的数据科学家和分析师。我们将此类别分为三个子类别：
- 端到端 MLOps 工具，
- 基于以数据为中心的机器学习方法的工具，
- ML 可观察性和监控。
端到端 MLOps 工具：
以数据为中心的机器学习：
这个子类别也没有摆脱端到端的陷阱，但其中列出的工具对它们提供的功能采取了不同的方法。他们将数据本身及其管理置于其任务的中心。
- 这个空间的两个新加入者是Activeloop和Graviti。它们由经验丰富的数据从业者构建，他们了解数据管理对任何数据操作成功的重要性。我们在lakeFS 分享了这种观点。
- DagsHub采用了一种独特的方法，它提供了一个以数据为中心但基于开源解决方案的端到端解决方案。它们在每个 ML 生命周期阶段都表现出色，提供了独特的可用性和易于集成的特点。在如此混乱的空间中，这是获得良好的端到端解决方案的可靠方法，该解决方案也令用户满意。我们满怀期待地注视着这家公司……
机器学习可观察性和监控：
- 该子类别包括专注于模型质量监控和可观察性的工具。与数据可观察性类别非常相似，这个领域正在增长并获得动力。2022 年初， Deepchecks开源，并迅速获得了关注、贡献者和合作伙伴。
结论
尽管该领域的公司数量不断增长，但我们可以看到其中几个类别的产品有整合的迹象。
MLOps 正朝着端到端的方向发展，笔记本正在进入编排，而编排正在转向沿袭和可观察性。同时，我们看到开放表格式进入 Metastore 功能。在治理层，安全和权限工具进入目录，反之亦然……
这些迹象是否表明市场（仍然）有限，可能在 MLOps 中？这种整合是否反映了由于激烈的竞争而需要差异化（在编排中可能就是这种情况）？还是有机会填补开放表格格式或以数据为中心的机器学习可能出现的空白？也许这一切都是因为用户希望使用更少的工具来做更多的事情？