Zero-ETL、大模型和数据工程的未来

2023-05-04
湖北
本文字数：5350 字
阅读完需：约 18 分钟

编者按：本文探讨了数据工程领域的未来趋势和挑战，以及其不断变化、甚至经常出现“重塑”的特点。在数据工程领域，大数据的性能、容量提升总是有一定的上限，每一次进步都会带来一定的技术提升，从而提高上限。但是很快我们就能到达这个上限，直到下一次技术跃升。
以下是译文，Enjoy!

作者 | Barr Moses

编译 | 岳扬

图片由作者提供

如果你不喜欢拥抱变化，那么数据工程应该不适合你。在这个领域里，很少有东西能够逃脱被重塑的命运。

最典型、最新的例子是 Snowflake 和 Databricks 颠覆了传统数据库的概念，引领了现代数据栈（Modern Data Stack）时代的到来。

作为这一颠覆性运动的一部分，Fivetran 和 dbt 根本性地改变了从 ETL 到 ELT 的数据流程（data pipeline）。Hightouch 试图将重心转移到数据仓库（data warehouse），中断了 SaaS“吞食世界”的进程。Monte Carlo 也加入战局，表示“手工编写单元测试可能不是确保数据质量的最佳方式[1]。”

如今，数据工程师继续依靠着硬编码的管道和私有服务器（hard coded pipelines and on-premises servers），向现代数据栈（Modern Data Stack）的高峰进军。

新的想法已经如雨后春笋般涌现，颠覆了之前的颠覆者，这似乎显得不公平：

Zero-ETL 有意将数据获取（data ingestion）作为其关注重点
人工智能和大型语言模型可以改变数据转换（transformation）流程
数据产品容器正在努力成为数据构建的核心

我们是否需要再次重塑一切？Hadoop 时代的行业体系仍然还保持着很高的热度。

答案是当然，必须要不断重塑数据系统。这种情况在我们每个人的职业生涯中可能都会有几次，主要是为什么重塑，何时重塑以及如何重塑。

我并不是一个专家，也不能预测所有的结果。但是本文将会仔细研究一些最突出的、可能会成为未来数据栈一部分的想法，同时探讨它们对数据工程的潜在影响。

01 需要考虑的具体因素和取舍的决策

图片来源：Tingey Injury Law Firm on Unsplash

现代数据栈的出现并不是因为在所有方面的表现都比之前的数据栈好。实际上，存在着很多需要考虑的具体因素。数据量更加庞大和数据生成更加快速，但也伴随着更加杂乱和难以管控。 在性价比方面的对比目前还没有定论。

现代数据栈之所以占据统治地位，是因为它可以支持用例（use cases），并以之前几乎不可能或者非常困难的方式从数据中释放价值。机器学习已经从一个热门词汇变成了一个创收工具。现在分析和实验可以更加深入进行，帮助做出更加重大的决策。

下面列出的每一种趋势都是如此。每种趋势都有利有弊，但是推动它们被广泛采用的原因是解锁新的利用数据的方式。或者，可能还有我们尚未发现的“黑马”观点，也可以帮助推动数据领域的发展。接下来，我们详细地研究每一种趋势。

02 Zero-ETL

What it is：Zero-ETL 其实是一个错误的名称——数据管道仍然存在。

目前，数据通常由服务生成并写入事务性数据库。部署了自动化流水线（automatic pipeline），不仅将原始数据移动到分析数据仓库（analytical data warehouse）中，而且在途中稍微修改了一下。

例如，API 以 JSON 格式导出数据，摄取管道（ ingestion pipeline ）不仅需要传输数据，还需要进行简单的转换，以确保数据以可加载到数据仓库的表格格式呈现。在采集阶段内常见的其他转换包括数据格式化（data formatting）和去重（deduplication）。

虽然可以通过在 Python 中对管道硬编码来进行转换，有些人提倡这样做[2]以便将****数据预建模（pre-modeled）到数据仓库中，但大多数数据团队出于快捷性（expediency）和可见性或质量原因（visibility/quality）选择不这样做。

Zero-ETL 通过使事务性数据库（transactional database）在自动加载到数据仓库之前进行数据清洗（data cleaning）和归一化（normalization）来改变这个数据接入过程。需要注意的是，数据仍处于相对原始的状态。

目前，这种集成是可能实现的，因为大多数 Zero-ETL 架构需要事务性数据库和数据仓库来自同一云服务提供商。

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

缺点：在数据采集阶段中，能够进行自定义数据处理的能力较少。可能会有一些云供应商的限制。

谁在推动 Zero-ETL：AWS 是 Zero-ETL 背后的推手（从 Aurora 到 Redshift[3]），但 GCP（从 BigTable 到 BigQuery[4]）和 Snowflake（Unistore[5]）都提供类似的功能。Snowflake（Secure Data Sharing[6]）和 Databricks（Delta Sharing[7]）也在追求所谓的“无复制数据共享”。这个过程实际上不涉及 ETL，而是提供了对存储数据的扩展访问。

实用性和价值潜力：一方面，由于技术巨头的支持和现在已经实现的功能，Zero-ETL 似乎只是时间问题。另一方面，我观察到数据团队正在持续将其数据操作和分析型数据库解耦，而不是更紧密地集成，这样可以防止意外的模式变化（schema changes）导致整个操作流程崩溃。

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

随着数据的流式处理（steaming）和微批处理（micro-batch）方法在当前似乎能够满足绝大多数“实时”数据需求，我认为这种创新的主要业务驱动力在于简化基础设施。虽然这没有什么可嘲笑的，但“无复制数据共享”的可能性消除了冗长的安全审查障碍，从长远来看可能会导致更广泛的使用。

03 One Big Table 和大语言模型

What it is：目前，业务相关者需要向数据专业人员描述他们的需求、指标和逻辑，然后专业人员将其翻译成 SQL 查询语句，甚至是一个仪表盘（dashboard）。即使所有数据已经存在于数据仓库中，这个过程也需要时间。更不用说在数据团队的最喜爱的工作清单中，临时数据请求排在 root canal 和文档（documentation）之间。

有许多初创公司旨在利用像 GPT-4 这样的大型语言模型的能力，通过让消费者在一个流畅的界面中“查询”自然语言中的数据来自动化这个过程。

至少在将二进制作为新的官方语言之前是英语

这将从根本上简化自助式分析流程（self-service analytics process），并进一步实现数据的民主化（democratize）。但是，考虑到更高级分析的数据管道复杂性，解决这个问题将会很困难，除了基本的“指标抓取（metric fetching）”之外。

但是，如果将所有原始数据都存储在 one big table，这个复杂性会得到降低，这是 Benn Stancil 提出的想法[8]，他是数据领域最好的和最具前瞻性的作家和创始人之一。没有人想象[9]过现代数据栈的死亡[10]是什么样子的。

其虽然是一个概念，却并不是那么遥不可及。有些数据团队已经利用了 one big table（OBT）策略，这既有支持者也有反对者[11]。

使用大型语言模型似乎可以克服使用 one big table 的最大困难之一（即数据探索分析、模式识别等方面以及其完全缺乏组织的困难）。对人类来说，为他们的故事制定一个目录和标记清晰的章节是很有帮助的，但人工智能并不关心这些。

优点： 也许最终实现了自助式数据分析（self service data analytics）[12]的承诺，进行数据洞察的速度更快，使数据团队可以花更多时间挖掘数据价值和去构建业务，而不是回应临时查询。

缺点： 自由度是不是太高了？数据专业人员熟悉数据的痛苦（比如时区问题[13]！以及什么是“账户”的问题？）在某种程度上超出了大多数业务相关者的范围。我们是否受益于具有代表性的例子而不是直接的数据民主化（Democratizing Data）？

谁在推动它：像 Delphi[14]和 GetDot.AI[15]这样的超早期初创公司和像 Narrator[16]这样的初创公司。还有一些更成熟的做这样业务的公司，如 AWS QuickSite[17]、Tableau Ask Data[18]或 ThoughtSpot。

实用性和潜力：令人耳目一新的是，这不是用于寻找用例（use cases）的技术[19]。价值和效率显而易见，但技术挑战也是如此。这个愿景仍在建设中，需要更多时间来发展。也许被采用的最大障碍将是这种方案所需的基础设施中断（infrastructure disruption），这对于更成熟的公司来说可能过于冒险。