后现代数据堆栈已经到来。我们准备好了吗？

图片由作者免费提供

如果你不喜欢改变，数据工程不适合你。在这个领域没有任何东西能够保持一成不变。

最近最重要的例子是Snowflake和Databricks，它们颠覆了数据库的概念，开创了现代数据堆栈时代。

作为此次变化的一部分，Fivetran和dbt从根本上上将数据管道从ETL(Extract, Transform, Load)变为ELT。高接触中断软件即服务(SaaS)以一种将重心转移到数据仓库的尝试席卷了整个世界。蒙特卡洛也加入这场争论之中，并认为“让工程师手动编写单元测试可能并非保证数据质量的最佳方式”。

今天，数据工程师们沿着现代数据堆栈启蒙的上坡路前进过程中继续死磕硬编码管道和企业预置型服务器。而必将到来的兼并与幻灭的低谷已经在尚且称之为安全的远处显现。

所以干扰破坏者的新观点已经不断涌现的事实，这貌似看起来不太合理：

• Zero-ETL在自己的视域中有数据摄取

• AI和大型语言模型可以变形

• 数据产品容器将数据表视为数据的核心基本要素

我们要（再一次）重建一切吗？Hadoop（分布式计算）的时代还没到完全凉透的程度。

答案是当然的。我们可能会在职业生涯中多次重建我们的数据系统。真正的问题是为什么、何时以及怎样（以此为序）。

我不会妄称自己知道所有答案或者拥有能够预知答案的水晶球。但是本文将会深入分析一些短期内最热门的观点，这些观点可能会成为后现代数据堆栈的组成部分，并对它们对数据工程的潜在影响进行论述。

图片来自Unsplash上的Tingey Injury Law Firm

现代数据堆栈的出现并非因为它比之前的技术做得更好。权衡就在于此。数据更大、更快，但它也更混乱，管理更差。关于成本效益的审判仍然没有定论。

现代数据堆栈之所以一骑绝尘，因为它能支持用例并以在从前可能是非同寻常的难度情况下将数据价值释放出来。机器学习一词已经从单纯的流行语变成了“财富密码”。而分析和实验则可以更深入地支持决策更大化。

同样的情况也适用于以下每一种趋势。虽然毁誉参半，但是主导采纳的是他们或者那些我们还未发现的黑马们如何解锁新的方法来利用数据。让我们进一步来看一下。

它是什么：一则用词不当;数据管道仍然存在。

如今，数据通常由服务生成并写入事务数据库。部署的自动管道不仅将原始数据移动到分析数据仓库，而且在此过程中对其进行了轻微修改。

例如，API 将以 JSON 格式导出数据，引入管道不仅需要传输数据，还需要应用轻度转换，以确保数据采用可加载到数据仓库中的表格式。在引入阶段完成的其他常见轻量级转换是数据格式化和重复数据删除。

虽然您可以通过在 Python 中对管道进行硬编码来进行更繁重的转换，并且有些人主张这样做以将预先建模的数据交付到仓库，但大多数数据团队出于权宜之计和可见性/质量原因选择不这样做。

Zero-ETL 通过让事务数据库在自动将其加载到数据仓库之前执行数据清理和标准化来更改此引入过程。请务必注意，数据仍处于相对原始的状态。

目前，这种紧密集成是可能的，因为大多数zero-ETL架构要求事务数据库和数据仓库来自同一云提供商。

优点：减少延迟。没有重复的数据存储。少一个故障源。

缺点：在引入阶段自定义数据处理方式的能力较差。部分供应商锁定。

谁在推动它：AWS是流行语（Aurora到Redshift）背后的驱动力，但GCP（BigTable到BigQuery）和Snowflake（Unistore）都提供类似的功能。Snowflake（安全数据共享）和Databricks（Delta共享）也在追求它们所谓的“无复制数据共享”。此过程实际上不涉及 ETL，而是提供了对存储数据的扩展访问。

实用性和价值释放潜力：一方面，由于背后的科技巨头和随时可用的能力，Zero-ETL的推广似乎只是时间问题。另一方面，我观察到数据团队正在解耦，而非更紧密地集成操作和分析数据库，以防止意外的架构更改而使整个操作崩溃。

这种创新可能会进一步降低软件工程师对其服务产生的数据的可见性和责任感。数据在提交代码后不久就已经在运往仓库的途中，他们为什么还要关心架构？

随着流数据和微批量方法满足了目前对“实时”数据的绝大多数需求，我认为此类创新的主要业务驱动力是基础设施简化。虽然无可厚非，但从长远来看，没有副本数据共享以消除冗长的安全审查障碍的可能性可能会导致对此种机制报复性使用（尽管需要明确的是，这不是此消彼长的选项）。

*博客内容为网友个人发布，仅代表博主个人观点，如有侵权请联系工作人员删除。