数据工程师的未来

在数据工程的世界里, 分析师马克西姆Beauchemin 是不需要介绍的人吗. 

脸谱网和Airbnb的首批数据工程师之一, 他为这位广受欢迎的管弦乐家写作并开源, Apache气流,此后不久 Apache 超集,这是一个数据探索工具,可以通过风暴来获取数据. 目前,马克西姆是 预设, 这是一家快速发展的初创公司,正在为现代企业的人工智能数据可视化铺平道路. 

公平地说,马克西姆经历了——甚至设计了——过去十年中许多最具影响力的数据工程技术, 他在2017年发表了一篇具有里程碑意义的博客, 数据工程师的崛起在书中,他记录了自己的许多观察结果. 简而言之, 马克西姆认为,为了有效地扩大数据科学和分析的规模, 团队需要一个专业的工程师来管理ETL, 构建管道, 并扩展数据基础设施. 输入,数据工程师

几个月后, 马克西姆在那篇文章之后反思了数据工程师面临的一些最大挑战:工作很艰难, 尊重是最少的, 他们的工作和产生的实际见解之间的联系是显而易见的,但很少被认可. 数据工程师是一份吃力不讨好但却越来越重要的工作, 团队跨越构建基础设施, 运行作业, 以及处理分析和BI团队的特别请求. 因此,成为一名数据工程师既是一件好事,也是一件坏事.

事实上,在马克西姆看来,数据工程师是“最糟糕的职位”.”

所以,五年后,推荐一个正规滚球网站的处境如何? 

在他发表主旨演讲之前 影响:数据可观测性峰会, 我和马克西姆坐下来讨论目前的形势, 包括现代数据堆栈的去中心化, 数据团队的分裂, 云的升起, 以及所有这些因素如何永远改变了数据工程师的角色.

ETL和分析的速度已经提高

马克西姆回忆起一段时间, 不久以前, 当数据工程师一次运行Hive任务几个小时, 需要频繁地在作业之间切换上下文,并管理数据管道的不同元素. 

说白了,这既无聊又累人. 

这种无休止的上下文切换和运行数据操作所花费的绝对时间导致了耗尽,”他说. “经常是晚上11点半工作5-10分钟.m. 能帮你在第二天省下2-4个小时的工作——这不是一件好事吗.” 

In 2021, 由于BigQuery的计算能力,数据工程师可以非常快速地运行大型任务, 雪花, 火弩箭, 砖, 以及其他云存储技术. 这种从在线和开源解决方案向云和托管SaaS的转移解放了数据工程资源,使其可以从事与数据库管理无关的任务.

另一方面,成本更受约束. 

“过去在prem上运行相当便宜, 但在云里, 你必须注意你的计算成本,“马克西姆说. “资源是有弹性的,而不是有限的.”

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

“推荐一个正规滚球网站可以从中国的崛起中看到这种转变 数据可靠性工程, 数据工程师负责管理(而不是构建)数据基础设施,并监督基于云的系统的性能.”

在治理上达成共识比较困难——这没关系

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

如今,马克西姆认为,治理是分布式的这一观点已被广泛接受. 每个团队都有自己的分析域, 强迫分散的团队结构围绕着什么是“好”数据的广泛标准化定义. 

“推荐一个正规滚球网站已经承认,寻求共识并非在所有领域都是必要的, 但这并没有让事情变得更容易,”他说. “在许多方面,数据仓库是组织的镜子. 如果人们对数据仓库中的东西的名称或度量标准的定义不一致, 那么,这种缺乏共识的情况将会在下游反映出来. 但也许这没关系.” 

也许, 马克西姆认为, 为业务找到共识不一定是数据团队的唯一责任, 特别是当这些数据在整个公司以不同的方式使用时. 这必然会导致重复和不对齐,除非团队仔细考虑哪些数据是私有的(换句话说), 仅由特定的业务领域使用)或与更广泛的组织共享. 

“现在, 不同的团队拥有他们使用和生产的数据, 而不是由一个中央团队负责公司的所有数据. 当数据在组间共享并在更大范围内公开时, 需要更严格地为变更管理提供API,”他说.

这就引出了下一点……

变更管理仍然是一个问题——但是正确的工具会有所帮助

In 2017, 马克西姆写第一篇文章的时候, 当数据发生变化时, 这将影响整个公司,但没有人会被通知.这种变革管理的缺失是由技术和文化差异造成的. 

当源代码或数据集被更改或更新时, 损坏发生在下游,将渲染仪表板, 报告, 在问题解决之前,其他数据产品实际上是无效的. 这 数据停机时间 (数据丢失的时间段, 不准确的, 或其他错误的)是昂贵的, 耗时, 解决起来很痛苦. 经常, 停机时间将悄然来临, 数据团队会挠头试图找出问题出在哪里, 谁是影响, 以及他们如何解决这个问题. 

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

“数据可观察性和传承性无疑帮助团队识别和解决了问题, 甚至是表面信息,比如什么东西坏了,谁受到了影响,马克西姆说. 尽管如此,变革管理是文化的,也是技术的. 如果去中心化的团队没有遵循流程和工作流,那么下游消费者甚至中央数据平台团队就会处于循环中, 然后,有效地处理变更是一项挑战.” 

如果没有区分哪些数据是私有的(仅由数据域所有者使用),哪些数据是公共的(由更广泛的公司使用), 那么就很难知道谁使用了什么数据, 如果数据中断, 是什么导致了它. 血统和根本原因分析可以让你达到一半的目标. 比如,马克西姆在Airbnb的时候, Dataportal 是为了让数据访问民主化,并让所有Airbnb员工能够探索, 理解, 和信任的数据. 仍然, 而工具告诉他们谁会受到端到端沿袭的数据变化的影响, 这仍然没有使管理这些更改变得更容易. 

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

总的来说,数据工具在很大程度上依赖于软件工程来获得灵感, 这是一件好事. 但是有一些数据元素使得使用ETL管道与代码库有很大的不同. 一个例子? 编辑代码之类的数据. 

"如果我想改变一个列名, 这很难做到, 因为你必须重新运行你的ETL和改变你的SQL,马克西姆说. “这些新的管道和数据结构会影响您的系统, 而且很难部署一个改变, 特别是当东西坏了的时候.” 

例如, 如果您有一个增量进程,周期性地将数据加载到一个非常大的表中, 你想要删除一些数据, 你必须暂停你的管道, 重新配置的基础设施, 然后在删除新列之后部署新的逻辑. 

工具并不能真正帮助您,特别是在差异负载的情况下. 回填仍然是非常痛苦的,但保留它们有一些好处. 

“维护数据的历史记录实际上是有好处的,”他说. “旧逻辑与新逻辑并存,可以进行比较. 你不需要改变过去已经发布的一堆资产.”

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

所以,选择你的毒药? 数据债务或数据管道混乱.

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

就像在软件工程中一样, 数据工程师的角色和职责正在发生变化, 特别是对于更成熟的组织. 数据库工程师正在逐渐消失, 随着数据仓库需要迁移到云, 数据工程师越来越多地负责管理数据性能和可靠性. 

马克西姆认为,这可能是一件好事. 在过去,数据工程师是“餐桌上最差的位子,“负责运营其他人的工作,他们使用的工具和流程不能完全满足业务需求. 

现在,出现了各种各样的新角色,让这个过程变得简单一些. 分析工程师就是一个很好的例子. 创造的 迈克尔Kaminsky的编辑 本地乐观, 分析工程师是一个跨数据工程和数据分析的角色, 并应用分析, 使用面向业务的数据处理方法. 

分析工程师就像数据耳语者, 负责确保数据不会与业务智能和分析隔离. 

“数据工程师几乎成了良好数据习惯的守护者. 例如, 如果分析工程师在每次使用DBT运行时重新处理仓库, 他们会养成坏习惯. 数据工程师是看门人, 负责对数据团队进行最佳实践的教育, 最显著的是效率(处理增量负载), 数据建模, 和编码标准, 并依赖数据的可观察性和DataOps,以确保每个人都以同样的努力对待数据.” 

行动蔓延并没有消失,只是被分配了

行动蠕变,马克西姆的 之前的文章, 指的是随着时间的推移责任逐渐增加, 不幸的是, 对于数据工程师来说,这是一个非常普遍的现实. 而现代工具可以帮助工程师提高生产力, 他们并不总是让他们的生活变得更轻松或更少负担. 事实上,随着时间的推移,它们通常会引入更多的工作或技术债务. 

仍然, 即使随着更专业化的角色和分布式数据团队的兴起, 行动上的蔓延并没有消失. 随着技术能力的增长和越来越多的功能投入到数据素养中,其中一些已经被转移到其他角色. 

例如, 马克西姆认为, 分析工程师的优先级与数据工程师的优先级不一定相同. 

“分析工程师关心运营管道的成本吗? 他们关心的是优化你的堆栈还是他们最关心的是提供下一个洞察? 我不知道.”他说. “运营蠕变是一个行业问题,因为, 机会是, 数据工程师仍然需要处理一些“不那么吸引人”的事情,比如关注存储成本或处理数据质量.” 

在分析工程师的世界中,运营蠕变也存在. 

“作为一名分析工程师, 如果我要做的只是写一大堆SQL来解决问题, 我可能会用dbt, 但它仍然是一个模板化SQL的山, 是什么让编写可重用或可管理的东西变得困难呢,“马克西姆说. “但在很多情况下,这仍然是我的选择,因为它简单明了.”

在理想的情况下, 他建议, 推荐一个正规滚球网站想要一些看起来更像现代代码的东西,因为推荐一个正规滚球网站可以以更可伸缩的方式创建抽象.  

那么,数据工程师的下一步是什么呢? 

我和马克西姆的谈话让我想了很多, 但, 总的来说, 我倾向于同意他的观点. 而数据团队的报告结构和操作层次变得越来越垂直, 数据工程师的工作范围正变得越来越横向,并专注于性能和可靠性——这最终是一件好事. 

专注孕育创新和速度, 是什么阻止了数据工程师试图煮沸海洋, 盘子转得太多, 或者一般都烧坏了. 数据团队中更多的角色意味着传统的数据工程任务(处理特别的查询), 建模, 转换, 甚至建造管道)并不需要完全落在他们的肩上. 而不是, 他们可以专注于重要的事情:确保数据是值得信任的, 可访问的, 并且在生命周期的每个点都是安全的. 

不断变化的工具环境反映了向更专注和专业化角色的转变. DataOps makes it easy to schedule and run jobs; cloud data warehouses make it easy to store and process data in the cloud; data lakes allow for even more nuanced and complex processing use cases; and 数据可观测性, 就像之前的应用程序监视和可观察性, 自动化许多与数据质量和可靠性相关的机械和重复的任务, 提供允许整个数据组织平稳运行的基线运行状况级别. 

随着这些新技术和工作流程的兴起, 工程师也有一个极好的机会来拥有运动走向 将数据视为产品. 建设运营, 可伸缩的, 可观测的, 只有当数据本身被勤奋地不断演变时,才有可能有弹性的数据系统, 迭代的产品. 这里是特定于用例的元数据, ML-driven数据发现, 这些工具可以帮助推荐一个正规滚球网站更好地理解什么数据真正重要,什么会像渡渡鸟一样消亡. 

至少,这是推荐一个正规滚球网站在水晶球里看到的. 

你在你的作品中看到了什么? 🙂   

接触 马克西姆 or Lior 用你的数据工程预测. 推荐一个正规滚球网站都是耳朵.