共计 6524 个字符，预计需要花费 17 分钟才能阅读完成。
编者按：本文探讨了数据工程畛域的将来趋势和挑战，以及其一直变动、甚至经常出现“重塑”的特点。在数据工程畛域，大数据的性能、容量晋升总是有肯定的下限，每一次提高都会带来肯定的技术晋升，从而进步下限。然而很快咱们就能达到这个下限，直到下一次技术跃升。
以下是译文，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-wa…
3.https://aws.amazon.com/about-aws/whats-new/2022/11/amazon-aur…
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#foo…
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-big…
13.https://www.explainxkcd.com/wiki/index.php/1883:_Supervillain…
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-dataengi…
21.https://www.montecarlodata.com/blog-data-lineage/
22.https://www.montecarlodata.com/blog-what-is-a-data-mesh-and-h…
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-engine…
本文经原作者受权，由 Baihai IDP 编译。如需转载译文，请分割获取受权。
原文链接：
https://towardsdatascience.com/zero-etl-chatgpt-and-the-futur…
