编者按：本文探讨了数据工程领域的未来趋势和挑战，以及其不断变化、甚至经常出现“重塑”的特点。在数据工程领域，大数据的性能、容量提升总是有一定的上限，每一次进步都会带来一定的技术提升，从而提高上限。但是很快我们就能到达这个上限，直到下一次技术跃升。
以下是译文，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），这对于更成熟的公司来说可能过于冒险。
04 数据产品容器
数据产品容器是什么：数据表（data table）是构建数据产品的基本单元。 实际上，许多数据行业领导者（data leaders）认为production table是他们的数据产品[20]。但是，为了将数据表视为产品，需要添加许多功能，包括访问管理、数据洞察和数据可靠性。
容器化对于软件工程中的微服务趋势至关重要。它们增强了可移植性（portability）、基础设施抽象（infrastructure abstraction），并最终能够扩展微服务。数据产品容器的概念设想了数据表的容器化。
数据产品容器可能已经被证明是一种有效的机制，可以使数据更加可靠和可管理，特别是如果它们可以更好地呈现与底层数据单元相关的语义定义（semantic definition）、数据沿袭（data lineage）[21]和质量度量（quality metrics）等信息。
优点：数据产品容器似乎是更好地包装和执行四个数据网格[22]原则（面向领域的分散数据所有权和架构，数据作为产品，自助数据平台，联合计算治理）的一种方式。
缺点：这个概念会让公司更容易还是更难扩展他们的数据产品？另一个基本问题是未来的数据趋势，即数据管道的副产品（代码、数据、元数据）对数据团队来说是否拥有值得保留的价值？
谁在推动它：由数据网格创始人Zhamak Dehgahni创立的创业公司Nextdata[23]。Nexla[24]也在这个领域发挥着较大的作用。
实用性和潜力：虽然Nextdata最近才渐渐出现在大家的视线内，数据产品容器仍在不断发展，但许多数据团队已经从数据网格的实现中看到了经过验证的结果。数据表的未来将取决于这些容器的确切形状和执行。
05 对数据生命周期的无尽重构
Photo by zero take on Unsplash
为了展望数据未来，我们需要回顾数据的过去和现在。过去、现在、未来——数据基础设施处于不断的破坏和重生状态（尽管也许我们需要更多的混乱[25]）。
数据仓库（data warehouse）的含义已经由比尔·因蒙（Bill Inmon）在1990年代引入的术语发生了巨大变化。ETL管道现在变成了ELT管道。数据湖（The data lake）不再像两年前那样模糊不清。
随着现代数据栈带来的这些创新，数据工程师仍然在发挥着中心的技术角色，决定数据如何流动以及数据使用者如何访问它。
Zero-ETL这个术语似乎很有威胁性，因为它（不准确地）暗示了管道的死亡，而如果没有管道，我们还需要数据工程师吗？
尽管ChatGPT生成代码的能力备受炒作，但这个过程仍然非常依赖数据技术工程师的审核和调试。大型语言模型的可怕之处在于它们可能会从根本上扭曲数据管道（data pipeline）或我们与数据使用者（data consumers）的关系（以及数据向他们提供的方式）。
然而，如果这个未来真的到来，它仍然强烈依赖于数据工程师。
自从人类诞生以来，数据的一般生命周期就始终存在。数据被发出，被塑造，被使用，然后被存档。
虽然基础设施可能会发生改变，自动化技术会将时间和注意力转移到一边，但是在可预见的未来，人类数据工程师将继续在从数据中挖掘价值方面发挥关键作用。
这不是因为未来的技术和创新不能简化今天复杂的数据基础设施，而是因为我们对数据的需求和用途将继续增加，变得更加复杂和规模更大。
大数据始终是一个来回摆动的钟摆。我们在容量方面取得了一大步，然后我们很快就会找到了一种方法来达到这个边界，直到需要下一次飞跃。
END
参考资料
1.https://www.montecarlodata.com/blog-what-is-data-observability/
2.https://medium.com/towards-data-science/is-the-modern-data-warehouse-broken-1c9cbfddec3e
3.https://aws.amazon.com/about-aws/whats-new/2022/11/amazon-aurora-zero-etl-integration-redshift/
4.https://www.infoq.com/news/2022/08/bigtable-bigquery-zero-etl/
5.https://www.snowflake.com/en/data-cloud/workloads/unistore/
6.https://docs.snowflake.com/en/user-guide/data-sharing-intro
7.https://www.databricks.com/product/delta-sharing
8.https://benn.substack.com/p/the-rapture-and-the-reckoning#footnote-anchor-12-99275606
9.https://benn.substack.com/p/how-fivetran-fails
10.https://benn.substack.com/p/how-dbt-fails
11.https://twitter.com/pdrmnvd/status/1619463942392389632
12.https://www.montecarlodata.com/blog-is-self-service-datas-biggest-lie/
13.https://www.explainxkcd.com/wiki/index.php/1883:_Supervillain_Plan
14.https://www.delphihq.com/
15.https://getdot.ai/
16.https://www.narratordata.com/
17.https://www.delphihq.com/
18.https://help.tableau.com/current/pro/desktop/en-us/ask_data.htm
19.https://en.wikipedia.org/wiki/Blockchain
20.https://www.linkedin.com/posts/shanemurray5_datamesh-dataengineering-dataquality-activity-7023310666983735296-4W3Y?utm_source=share&utm_medium=member_desktop
21.https://www.montecarlodata.com/blog-data-lineage/
22.https://www.montecarlodata.com/blog-what-is-a-data-mesh-and-how-not-to-mesh-it-up/
23.https://www.nextdata.com/
24.https://www.nexla.com/nexsets-modern-data-building-blocks/
25.https://medium.com/towards-data-science/the-chaos-data-engineering-manifesto-5dc09a182e85
本文经原作者授权，由Baihai IDP编译。如需转载译文，请联系获取授权。
原文链接：
https://towardsdatascience.com/zero-etl-chatgpt-and-the-future-of-data-engineering-71849642ad9c
