把数据当做产品来对待。

神译局是36氪旗下编译团队，关注科技、商业、职场、生活等领域，重点介绍国外的新技术、新观点、新风向。

编者按：数据工程师是一份好工作还是一份费力不讨好的工作？数据工程师的职责正在分化得越来越专业。随着先进工具的发展，数据工程师的工作也在迎来变化。本文来自编译，希望对您有所启发。

Image courtesy of Tom Stodge on Unsplash.

在数据工程领域，马克西姆·博谢明(Maxime Beauchemin)是一个人尽皆知的人。

作为Facebook和Airbnb的首批数据工程师之一，他编写并开放了广受欢迎的Apache Airflow，随后不久又推出了Apache Superset，这是一款数据探索工具，在数据领域掀起了一场风暴。目前，马克西姆是Preset的首席执行官和联合创始人，该公司是一家快速发展的初创公司，正在为现代企业的人工智能数据可视化铺平道路。

毫不夸张地说，马克西姆经历了，甚至是构建了过去十年中许多最具影响力的数据工程技术，并通过他在2017年发表的具有里程碑意义的博客文章《数据工程师的崛起》(the Rise of the data Engineer)开创了数据工程师这一角色，他在文中记录了许多他的观察。简而言之，马克西姆认为，为了有效地扩展数据科学和分析，团队需要一个专门的工程师来管理ETL、构建数据管道和扩展数据基础设施。这就是数据工程师的职责。

几个月后，马克西姆又对数据工程师面临的一些最大挑战进行了反思：数据工程师的工作很艰难，受到的尊重很少，他们的工作与实际产生的见解之间的联系很明显，但很少被认可。数据工程师是一项吃力不讨好、但越来越重要的工作，团队要在构建基础设施、运行作业和处理来自分析和BI团队的特别请求之间游走。因此，成为一名数据工程师既是一件好事，也是一件坏事。

事实上，在马克西姆看来，数据工程师是“地位最差的人”。那么，五年过去了，数据工程师处在什么位置了呢？

在《影响力：数据可观测性峰》的主题演讲之前，我们与马克西姆（Maxime）坐下来讨论了当前的事态，包括现代数据栈的去中心化、数据团队的碎片化、云计算的兴起，以及所有这些因素会如何永远改变数据工程师的角色。

1. ETL(Extract Transform and Load，即提取、转换和加载)和分析的速度提高了

马克西姆回忆说，就在不久以前，数据工程师还会一次运行几个小时的Hive作业，这就需要频繁地在作业之间上下文切换（Context Switching），并管理数据管道的不同元素。

说白了，这既无聊又累人。

他说：“这种无休止的上下文切换和运行数据操作所需的时间太长，让人精疲力竭。通常情况下，晚上11:30工作5-10分钟可以为第二天节省2-4个小时的工作时间。这并不一定是好事。”

2021年，得益于BigQuery、Snowflake、Firebolt、Databricks和其他云仓储技术的计算能力，数据工程师可以很快地完成大型工作。这种从on-prem和开源解决方案向云和托管SaaS的转变释放了数据工程资源，用于与数据库管理无关的任务。

另一方面，成本受到了更多的限制。

马克西姆说：“以前在on-prem上运行相当便宜，但在cloud上，你必须注意你的计算成本。资源是有弹性的，而不是有限的。”

随着数据工程师不再负责管理计算和存储，他们的角色正在从基础设施开发转变为数据堆栈中更基于性能的元素，甚至是专门的角色。

“我们可以从数据可靠性工程的兴起中看到这种转变，数据工程师负责管理(而不是构建)数据基础设施，并监督基于云的系统的性能。”

2. 在治理方面更难达成共识——不过这没关系

在以前的时代，数据团队结构非常集中化，数据工程师和精通技术的分析师充当整个公司的数据“图书管理员”。数据治理是一个孤立的角色，数据工程师实际上成为了数据信任的守门人——不管他们是否愿意。

马克西姆认为，现在人们普遍认为治理是分布式的。每个团队都有他们自己的分析领域，围绕“好”数据的广泛标准化定义，强制分散的团队结构。

他说：“我们承认，并非所有领域都需要寻求共识，但这并没有让事情变得更容易。在许多方面，数据仓储是组织的镜像。如果人们对他们在数据仓储中的东西或指标的定义不一致，那么这种缺乏共识将会在下游反映出来。但也许这没关系。”

马克西姆认为，也许数据团队不一定要为业务寻找共识，尤其是在数据被公司以不同方式使用的情况下。除非团队仔细考虑哪些数据是私有的(换句话说，只被特定的业务领域使用)，哪些需要与更广泛的组织共享，否则这将不可避免地导致重复和不一致。

“现在，不同的团队拥有属于他们自己的数据，这些数据是由这个团队产生并使用的，而不是让一个中心团队负责公司的所有数据。当数据在不同群体之间共享，并在更大范围内开放时，就需要更严格地为变更管理提供API。”

这就引出了下一点……

3. 变更管理仍然是一个问题——但正确的工具有助于解决这个问题

2017年，马克西姆写了他的第一篇文章，“当数据发生变化时，会影响整个公司，但却不会通知任何人。”缺乏变更管理是由技术和文化差异造成的。

当源代码或数据集被更改或更新时，下游就会发生问题，这些问题将导致仪表板、报告和其他数据产品无效。这种数据宕机(数据丢失、不准确或时间段错误)的代价是昂贵的，它在短时间内密集出现，而且很难解决。通常情况下，宕机会悄无声息地发生，数据团队会挠头，需要想办法弄清楚哪里出了问题，谁受到了影响，以及如何解决问题。

如今，数据团队越来越依赖DevOps和软件工程最佳实践来构建更强大的工具和文化，优先考虑通信和数据可靠性。

马克西姆说：“数据的可观察性和系统无疑帮助了团队识别和解决问题，甚至揭示了什么出现了问题，谁受到了影响。不过，变更管理既是技术上的，也是文化上的。如果去中心化的团队没有遵循将下游消费者甚至是中心数据平台团队留在循环中的工作流程，那么有效处理变更问题将是一个挑战。”

如果没有划分哪些数据是私有的(仅由数据域所有者使用)，哪些数据是公共的(由更广泛的公司使用)，那么就很难知道谁使用了哪些数据，如果数据泄露了，是什么原因造成的。根因定位可以帮你做到一半。例如，当马克西姆在Airbnb工作时，Datportal的建立是为了让数据访问民主化，并让所有Airbnb员工能够探索、理解和信任数据。尽管Datportal能告诉他们，通过端到端沿袭，谁会受到数据更改的影响，但它仍然没有使管理这些更改变得更容易。

4. 数据应该是不可变的，否则就会出现混乱

数据工具在很大程度上依赖于软件工程来获得灵感——总的来说，这是一件好事。但是有一些数据元素使得使用ETL管道与使用代码库有很大的不同。

“如果我想更改一个列名，这是相当困难的，因为你必须重新运行ETL和更改SQL，”马克西姆说，“这些新的管道和数据结构会影响你的系统，所以很难做出改变，尤其是当某些东西出现问题的时候。”

例如，如果你有一个定期将数据加载到一个非常大的表中的增量过程，并且你想要删除其中的一些数据，那么你必须暂停管道，重新配置基础设施，然后在删除新列之后部署新的逻辑。

工具真的帮不上什么忙，尤其是在负载差异的情况下。回填仍然会很痛苦，但保留它们还是有一些好处的。

他说：“保存你的数据历史记录实际上是有好处的。旧逻辑与新逻辑并存，可以进行比较。你不需要打破和改变过去已经发布的东西。”

保留重要的数据资产(即使它们没用了)可以提供有用的上下文。当然，目标是随着时间的推移，所有这些更改都应该明确地记录下来。

5. 数据工程师的角色正在分化

就像在软件工程中一样，数据工程师的角色和职责正在发生变化，特别是对于更成熟的公司来讲。随着数据仓储需求向云转移，数据库工程师正在消失，数据工程师越来越多地负责管理数据性能和可靠性。

根据马克西姆的说法，这可能是一件好事。在过去，数据工程师是“地位最差的人”。现在，出现了各种各样的新职位，让数据工程师的工作变得容易一些。比如说，分析工程师。由local Optimistic的编辑迈克尔·凯米思科（Michael Kaminsky）创造的分析工程师职位是一个跨数据工程和数据分析的角色，并使用一种分析的、面向业务的方法来处理数据。分析工程师负责确保数据不会脱离商业智能和分析。

“数据工程师几乎变成了良好数据习惯的守护者。例如，如果分析工程师在每次运行时都用dbt重新处理仓储，他们可能会养成坏习惯。数据工程师是看门人，负责向数据团队传授最佳实践，最重要的是关于效率、数据建模和编码标准，并依赖数据可观察性和DataOps，以确保每个人都以同样的勤勉对待数据。”

6. 操作蠕变并没有消失，只是被分散了

正如马克西姆在之前的文章中所讨论的，操作蠕变指的是职责随着时间的推移而逐渐增加，不幸的是，对于数据工程师来说，这是非常普遍的现实。虽然现代工具可以帮助工程师提高效率，但这些工具也并不总是能让他们的工作更轻松。事实上，随着时间的推移，工具通常会带来更多的工作或技术问题。

然而，即使有了更专业化的职位和分布式数据团队的出现，操作蠕变并没有消失。例如，马克西姆认为，分析工程师优先考虑的东西不一定是数据工程师优先考虑的东西。

“分析工程师关心运行管道的成本吗？他们关心如何优化你的堆栈吗？”他说，“操作蠕变是一个行业问题，因为数据工程师很有可能仍然需要管理‘不太吸引人的’事情，比如监控存储成本或处理数据质量。”

在分析工程师的世界里，操作蠕变也存在。

马克西姆说：“作为一名分析工程师，如果我要做的只是写一堆SQL来解决问题，我可能会使用dbt，但它仍然是一堆模板SQL，这使得编写任何可重用或可管理的东西都很困难。但在很多情况下，这仍然是我的选择，因为它简单明了。”

他建议，在理想的情况下，我们希望一些看起来更像现代代码的东西，因为我们可以以更可变的方式创建抽象概念。

7. 那么，数据工程师的下一步是什么呢？

我和马克西姆的谈话让我有很多东西要思考，但总的来说，我倾向于同意他的观点。当数据团队报告结构和操作层次变得越来越垂直时，数据工程师的范围变得越来越水平，并关注性能和可靠性——这最终是一件好事。

专注孕育了创新和速度。数据团队中分化出更多的职位意味着传统的数据工程任务不需要完全由数据工程师承担。相反，他们可以专注于重要的事情：确保数据在生命周期的每个点上都是可信的、可访问的和安全的。

不断变化的工具环境反映了向更专注和专门化职位的转变。DataOps使调度和运行作业变得容易；云数据仓储使得在云存储和处理数据变得容易；数据湖允许更加微妙和复杂的处理用例；数据可观察性使许多与数据质量和可靠性相关的机械和重复任务自动化了，允许整个数据组织平稳运行。

随着这些新技术和工作流程的兴起，工程师们也有了一个极好的机会，可以把数据当作产品来对待。只有在数据本身经过不断发展的迭代产品后，才能构建可操作的、可扩展的、可观察的和弹性的数据系统。这里有特定于用例的元数据、ML驱动的数据发现和工具，这些工具可以帮助我们更好地理解哪些数据是真正重要的。

译者：Jane

本文来自翻译, 如若转载请注明出处。