如果你不喜欢改变，数据工程可能不适合你。在这个领域中，几乎没有什么东西逃脱了重新设计的改革浪潮。
最明显的、最近的例子是Snowflake和Databricks，它们颠覆了数据库的概念，引领了现代数据堆栈时代的到来。
作为这一运动的一部分，Fivetran和dbt从ETL到ELT根本性地改变了数据流水线。Hightouch改变了SaaS主导世界的趋势，试图将重心转移到数据仓库上。Monte Carlo加入战团，并说：“也许工程师手动编写单元测试并不是确保数据质量的最佳方式。”
如今，数据工程师继续摒弃硬编码的流水线和本地服务器，向现代数据堆栈的启蒙之路迈进。无可避免的整合和失望谷似乎在安全的距离上出现在地平线上。
所以，新的创意已经不公平地出现，颠覆者们已经出现：
- Zero-ETL将数据摄入视为目标
- AI和大型语言模型可以改变转换
- 数据产品容器正在以数据的核心构建模块的姿态出现
我们是否必须重建一切（再一次）？Hadoop时代的事物还没有冷却下来。
答案是，当然我们必须重建我们的数据系统。在我们的职业生涯中可能有多次。真正的问题是为什么、何时以及如何（按顺序）。
我不自称拥有所有的答案或者有一颗水晶球。但本文将详细考察一些最明显的未来潜在观点，这些观点可能成为后现代数据堆栈的一部分，以及它们对数据工程的潜在影响。
实用性和权衡
照片由Tingey Injury Law Firm拍摄，来自Unsplash
现代数据堆栈的出现并不意味着它在所有方面都比它的前任做得更好。存在真实的权衡。数据变得更多、更快，但也更加混乱和不受约束。成本效益对仍存疑。
现代数据堆栈之所以占主导地位，是因为它支持使用案例，并以以前甚至不可能的方式释放数据的价值。机器学习从热词变成了收入的来源。分析和实验可以更深入地支持更大的决策。
对于以下每个趋势来说也是如此。它们将有利有弊，但驱动采纳的是它们以及或者我们尚未发现的黑马想法，它们如何解锁数据的新用途。让我们更详细地看一下。
Zero-ETL
它是什么：一个错误的名称；数据流水线仍然存在。
今天，数据通常由某个服务生成，并写入事务性数据库。部署了一个自动的数据流水线，它不仅可以将原始数据移动到分析型数据仓库，还可以在途中对其进行轻微的修改。
例如，API将以JSON格式导出数据，而接收入流水线不仅需要传输数据，还需要进行轻微的转换，以确保数据处于可以加载到数据仓库的表格格式中。接入阶段中常见的其他轻微转换包括数据格式化和去重。
虽然您可以通过在Python中硬编码流水线来进行更重的转换，并且有些人建议只需这样做就能将数据预建模到数据仓库，但为了迅速性和可见性/质量原因，大多数数据团队选择不这样做。
Zero-ETL通过让事务数据库在自动加载到数据仓库之前进行数据清洗和规范化来改变此摄取过程。重要的是要注意数据仍处于相对原始的状态。
目前，这种紧密集成是可能的，因为大多数零 ETL 架构要求事务数据库和数据仓库来自同一个云提供商。
优点：减少延迟。无重复数据存储。减少了一种故障来源。
缺点：在摄取阶段处理数据的定制能力较弱。一些供应商锁定。
谁在推动：AWS 是这个噱头的驱动者 (Aurora 到 Redshift)，但 GCP (BigTable 到 BigQuery) 和 Snowflake (Unistore) 也提供类似的功能。Snowflake (Secure Data Sharing) 和 Databricks (Delta Sharing) 也在追求他们所称的“无需复制数据共享”。这个过程实际上不涉及 ETL，而是在数据存储的地方提供了扩展访问权限。
实用性和价值释放潜力：一方面，并且基于技术巨头的支持和成熟的功能，零 ETL 看起来只是个时间问题。另一方面，我注意到数据团队在防止意外架构更改导致整个操作崩溃时，更倾向于解耦操作和分析数据库，而不是更加紧密地集成它们。
这种创新可能会进一步降低软件工程师对他们所产生的数据的可见性和责任。当数据在代码提交后不久就已经在其途中前往仓库时，他们为什么还要关心架构呢？
随着数据流和微批处理方法似乎满足大多数对“实时”数据的需求，我认为这种创新的主要商业驱动因素是基础架构简化。虽然这也不容忽视，但无需复制数据共享消除了需要进行漫长的安全审查的障碍，从而可能导致长期更广泛的采用（虽然必须明确，这不是非此即彼的）。
One Big Table and Large Language Models（一个大表格和大型语言模型）
这是什么：目前，业务利益相关者需要向数据专业人员表达他们的要求、指标和逻辑，然后再将所有这些转化为 SQL 查询，甚至可能是仪表盘。即使所有数据都已经存在于数据仓库中，这个过程也需要时间。更不用说对于数据团队来说，即席数据请求在喜爱的活动列表上，介于根管治疗和文件编写之间。
一些初创公司致力于利用大型语言模型（如 GPT-4）的能力，通过允许用户在一个流畅界面上“查询”它们的数据来自动化这个过程。
至少在我们的新机器人霸主将二进制作为新的官方语言之前。
这将极大简化自助分析过程，进一步实现数据的民主化，但在更高级的分析的数据管道的复杂性方面，解决这个问题将很困难。
但是，如果将所有原始数据都存储在一个大表格中，这个复杂性会被简化吗？
这是数据的最佳和前瞻性作者/创始人之一Benn Stancil提出的想法。没有人对现代数据堆栈的终结抱有更多的想象力。
作为一个概念，这并不是那么难以置信。一些数据团队已经使用了一大表格 (OBT) 策略，这在一定程度上有支持者和反对者。
利用大型语言模型似乎克服了使用单个大表格的最大挑战之一，即发现困难、模式识别困难和完全无组织。对于人类来说，拥有目录和明确标记的章节是有帮助的，但AI并不在乎。
优势：或许最终实现了自助数据分析的承诺。洞察力的速度。使数据团队能够更多时间解锁数据价值和构建，而不是花费时间应对特定查询。
劣势：是否自由过度？数据专业人员熟悉数据的痛苦特点（时区！“账户”是什么？），而大多数业务利益相关者则不然。我们是否从代表性数据民主而非直接数据民主中获益？
驱动者：Delphi和GetDot.AI等早期初创公司。Narrator等初创公司。像亚马逊QuickSight、Tableau Ask Data或ThoughtSpot等更具规模的参与者正在进行某种形式的尝试。
实用性和价值释放潜力：令人耳目一新的是，这不是为了寻找用途的技术。价值和效率是显而易见的，但技术挑战也同样明显。这个愿景仍在建设中，并需要更多时间来发展。采用这一方法可能面临的最大障碍可能是所需的基础设施破坏，这对于更具规模的组织来说可能太冒险了。
数据产品容器
定义：数据表格是数据产品构建的基本模块。事实上，许多数据领导者认为生产表格是他们的数据产品。然而，要将数据表格视为产品，需要添加许多功能，包括访问管理、发现和数据可靠性。
容器化对于软件工程中的微服务运动至关重要。它们提高了可移植性、基础设施抽象，最终使组织能够扩展微服务。数据产品容器的概念设想了对数据表格的类似容器化处理。
数据产品容器可能证明是一种有效的机制，可以使数据更可靠和可管理，特别是如果它们能更好地呈现与底层数据单元相关的语义定义、数据血统和质量指标等信息。
优势：数据产品容器似乎是更好地打包和执行四个数据网格原则（联邦治理、自助数据服务、将数据视为产品、领域优先基础设施）的方法。
劣势：这个概念是否会使组织更容易或更困难地扩展其数据产品？另一个基本问题是，这种未来派的数据趋势的副产品（代码、数据、元数据）是否包含对数据团队有价值的内容，值得保留？
驱动者：Nextdata，数据网格创始人Zhamak Dehgahni创建的初创公司。Nexla也在这个领域有所涉足。
实用性和价值释放潜力：虽然Nextdata最近才刚刚从隐蔽状态出现，数据产品容器仍在发展中，但许多数据团队已从数据网格实施中看到了实际结果。数据表格的未来将取决于这些容器的确切形态和执行方式。
数据生命周期的无尽再想象
为了窥探数据的未来，我们需要回顾过去和现在的数据。过去、现在、未来 – 数据基础设施处于不断被颠覆和重塑的状态（尽管也许我们需要一些更多的混乱）
数据仓库的含义从1990年代比尔·因蒙引入的术语发生了巨大的变化。ETL管道现在变成了ELT管道。数据湖不再像两年前那样不确定。
在现代数据栈带来的这些创新中，数据工程师仍然在决定数据的移动方式和数据使用者的访问方式方面发挥着核心的技术角色。但是有些变化比其他变化更大、更可怕。
零ETL这个术语似乎威胁人们（虽然不准确地）暗示了管道的死亡，而没有管道，我们还需要数据工程师吗？
对于ChatGPT能够生成代码的所有炒作，这个过程仍然非常依赖于技术数据工程师，他们仍然需要审核和调试。关于大型语言模型的可怕之处在于它们可能如何根本性地扭曲数据管道或我们与数据使用者的关系（以及如何为他们提供数据）。
然而，如果有这样的未来，它依然严重依赖于数据工程师。
从时间的黎明以来一直存在的是数据的一般生命周期。它被发出，被塑造，被使用，然后被归档（最好避免在这里思考我们自己的终结）。
虽然基础设施可能会发生变化，自动化将使时间和注意力转移到正确或错误的地方，但人类数据工程师将在可预见的未来继续在从数据中提取价值的过程中扮演关键角色。
这不是因为未来的技术和创新不能简化当今复杂的数据基础设施 – 而是因为我们对数据的需求和使用将继续变得更加复杂和规模化。
大数据一直在前后摇摆。我们在容量上取得了一次巨大的飞跃，然后我们迅速想出一种方式来达到那些界限，直到需要下一次飞跃。在这个循环中找到安慰 – 很高兴能有所需。
原文最初发布于此。已经以许可重新发布。