数据工程师的未来
Apache Airflow 和 Apache Superset 的创建者 Maxime Beauchemin 写了一篇文章讨论数据工程师的未来，其中讲述了他对数据工程师的现状的认知和未来发展的猜测，可供大家参考。
作为 Apache Airflow 和 Apache Superset 的深度使用者，Maxime Beauchemin 这个名字自然是如雷贯耳的，之前读过他的《数据工程师的兴起》这篇文章，讨论了数据工程师的必要性，即
为了有效地扩展数据科学和分析，团队需要一名专业工程师来管理 ETL、构建管道和扩展数据基础设施。
但是 Maxime Beauchemin 也认为数据工程师虽然看起来很美好，但是
工作很辛苦，尊重很少，他们实际的工作与产生的实际见解之间的联系很明显，但很少被人认识到。数据工程师也是一项吃力不讨好的工作，团队在构建基础设施、运行作业以及处理来自分析和 BI 团队的临时请求之间徘徊。因此，成为一名数据工程师既是福也是祸。
这段话道尽了大部分数据工程师团队的心酸，我想那些“取数工程师”应该更有感触。
那么未来数据工程师的发展方向在何处、如何避免这些问题，Maxime Beauchemin 认为现代数据堆栈的去中心化、数据团队的碎片化、云的兴起会有效的改变这种困境。
云的兴起
首先是云的兴起，让 ETL 和数据分析的速度加快了。之前囿于本地资源的有限，每次到了晚上就会运行很多 Hive 的任务时，就会显得很慢，白天任务相对少，资源就会浪费，但是如果在云上运行的话，因为资源是弹性的，可以一次性调取大量资源加速晚上的任务运行，白天的时候释放资源。总体而言，数据处理的速度变快了很多。也就是说，未来
资源是有弹性的，而不是有限的。
导致了数据工程师在未来可能
不再负责管理计算和存储，而是负责管理（而不是构建）数据基础设施并监督基于云的系统的性能。
数据治理的去中心化
其次是认为数据治理不应该集中由数据团队完成，而是根据每个不同业务团队的不同而进行相应的治理。
人们普遍认为治理是分布式的。每个团队都有自己的分析领域，这迫使分散的团队结构围绕“好”数据的广泛标准化定义。
而这是因为达成共识的难度非常大。
现在，不同的团队拥有他们使用和产生的数据，而不是让一个中央团队负责公司的所有数据。当数据在组之间共享并在更广泛的范围内公开时，需要更加严格地提供用于变更管理的 API
那么如何处理这种上下游数据变更导致整个数据链条出问题的情况呢？
当源代码或数据集被更改或更新时，下游会发生破坏，这会使仪表板、报告和其他数据产品在问题得到解决之前实际上无效。这种数据停机时间（数据丢失、不准确或其他错误的时间段）代价高昂、耗时且难以解决。很多时候，停机时间会悄无声息地发生，数据团队会摸不着头脑，试图弄清楚出了什么问题，谁受到了影响，以及他们如何解决问题。
有一个很好的路径是：DevOps 和软件工程最佳实践。再加上数据可观察性和数据血缘。但是工具是有限的，更重要的是文化：
变革管理既是技术又是文化。如果去中心化的团队不遵循让下游消费者甚至中央数据平台团队参与其中的流程和工作流程，那么有效地处理变化就具有挑战性。
数据团队职责正在分裂
未来数据工程师的职责会变得更加细化（其实现在已经开始了）。
数据工程师几乎就像是良好数据习惯的守护者。例如，如果分析工程师在每次运行 dbt 时重新处理仓库，他们就会养成坏习惯。数据工程师是守门人，负责对数据团队进行最佳实践教育，尤其是在效率（处理增量负载）、数据建模和编码标准方面，并依靠数据可观察性和 DataOps 来确保每个人都以相同的方式处理数据勤勉。
因为平时的工作写的SQL其实很多是重复的，但是SQL本身不够抽象，可能未来会诞生一种工具以供数据团队去抽象平时的工作
作为一名分析工程师，如果我要做的只是编写大量 SQL 来解决问题，我可能会使用 dbt，但它仍然是大量模板化 SQL，这使得编写任何可重用或可管理的东西变得困难，但它仍然是我在很多情况下会选择的选项，因为它简单易行。
结语
这是 Maxime Beauchemin 所认为的数据工程师的未来，那么读者是怎么认为的呢？
参考链接：
- https://www.montecarlodata.com/the-future-of-the-data-engineer/