原文：
www.kdnuggets.com/2019/01/role-data-engineer-changing.html
comments
特里斯坦·汉迪，Fishtown Analytics 的创始人兼总裁
1. 谷歌网络安全证书 - 快速进入网络安全职业轨道。
2. 谷歌数据分析专业证书 - 提升你的数据分析能力
3. 谷歌 IT 支持专业证书 - 支持你的组织的 IT
我发现自己经常与分析领导者交谈，他们根据过时的思维模式来构建其团队的数据工程师角色。这个错误可能会严重阻碍整个数据团队，我希望看到更多公司避免这种结果。
这篇文章表达了我对何时、如何以及为什么应该将数据工程师纳入团队的看法。它基于我在Fishtown Analytics的经验，与 100 多家风险投资支持的初创公司合作建立他们的数据团队，以及与更广泛的数据社区中的数百家公司进行的对话。
如果你在一家风险投资支持的初创公司管理数据团队，这篇文章是为你写的。
软件正在越来越多地自动化数据工程中的无聊部分。
在 2012 年，如果你想在风险投资支持的初创公司中拥有一个复杂的分析实践，你需要一个或多个数据工程师。这些工程师负责从你的操作系统中提取数据，并将其传输到分析师和业务用户可以获取的地方。他们通常会进行一些转换工作，以便数据更易于分析。如果没有数据工程师，分析师和科学家将没有数据可用，因此工程师经常是新数据团队的第一批成员。
到了 2019 年，你可以购买现成的技术来完成大部分工作。在大多数情况下，你和你的数据分析师以及科学家可以在没有任何硬核数据工程经验的情况下构建整个管道。而且你不会构建一些二流、糟糕的管道：现成的工具实际上是解决这些问题的最佳方式。
数据分析师和科学家构建自服务管道的能力是新的——目前大约有 2-3 年的历史。推动这一变化的有三个具体的产品：Stitch、Fivetran 和 dbt。这些产品最初是在 Amazon Redshift 发布之后推出的，当时初创数据团队发现了构建数据仓库的巨大潜力。尽管如此，这些产品要真正变好还是花了几年时间——在 2016 年，我们还处于早期采用者阶段。
目前，基于 Stitch / Fivetran / dbt 构建的管道比基于自定义 Airflow 任务构建的管道要可靠得多。这是一种经验性的说法，而不是理论性的说法：我不是说构建可靠的 Airflow 基础设施是不可能的，我只是说大多数初创公司并没有这样做。在 Fishtown Analytics，我们与 100 多个风险投资支持的数据团队合作，并且一再看到这种情况。我们一直在将人们从自定义构建的管道迁移到现成的基础设施中，几乎每一个案例的效果都是极其积极的。
2016 年，Jeff Magnusson 写了一篇基础性的博客文章，标题为 工程师不应编写 ETL。这是我知道的第一个有人提到这种变化的帖子。以下是我最喜欢的部分：
数据处理工具和技术在过去五年中经历了巨大的演变。除非你需要处理超过数个 PB 的数据，或每天摄取数百亿的事件，否则大多数技术已经发展到可以轻松满足你的需求的地步。
除非你需要推动这些技术的能力的边界，否则你可能不需要一个高度专业化的工程师团队来构建这些技术上的解决方案。如果你勉强聘请到他们，他们会感到无聊。如果他们感到无聊，他们会离开你，去 Google、Facebook、LinkedIn、Twitter 等——这些地方才真正需要他们的专业知识。如果他们没有感到无聊，可能他们的水平也就只是中等而已。中等水平的工程师确实擅长于构建极其复杂且难以使用的“解决方案”。
我非常喜欢这一部分，因为它不仅突出了为什么你不需要数据工程师来解决大多数 ETL 问题，还说明了为什么你最好不要让他们来解决这些问题。
如果你雇佣一个数据工程师并要求他们构建管道，他们会认为他们的工作就是构建管道。这会导致像 Stitch、Fivetran 和 dbt 这样的工具会被视为对他们存在的威胁，而不是强大的增效器。他们会找到现成管道无法满足你非常定制的数据需求的理由，以及分析师不应构建自己数据转换的理由。他们会编写易碎、难以维护且性能不佳的代码。你将依赖这些代码，因为它在你团队做的其他所有工作之下。
**像瘟疫一样避免这种情况。**你的数据团队的创新速度将急剧下降，你将花费所有时间思考那些实际上不会为业务带来收入的基础设施问题。
那么，你的初创数据团队是否仍然需要数据工程师？确实需要。
即便有新的工具使数据分析师和科学家能够构建自助服务管道，数据工程师仍然是任何高效数据团队中不可或缺的一部分。然而，他们需要专注的任务已发生变化，招聘的顺序也发生了变化。我会在后续部分讨论“何时”招聘的问题；现在，我们来谈谈数据工程师在现代初创数据团队中的责任。
数据工程师仍然是任何高效数据团队中不可或缺的一部分。
与其构建现成的摄取管道和实现基于 SQL 的数据转换，不如让你的数据工程师专注于以下任务：
-
管理和优化核心数据基础设施，
-
构建和维护定制的摄取管道，
-
支持数据团队资源的设计和性能优化，以及
-
构建非 SQL 转换管道。
管理和优化核心数据基础设施
尽管数据工程师不再需要管理 Hadoop 集群或为 VC 支持的初创公司扩展 Vertica 硬件，但在这一领域仍然有真正的工程工作需要做。确保你的数据技术在峰值状态下运行，将会大幅提高性能、降低成本或同时实现两者。通常这涉及到：
-
构建监控基础设施，以便了解数据管道的状态，
-
监控所有作业对集群性能的影响，
-
定期运行维护例程，
-
调整表模式（即分区、压缩、分布）以最小化成本并最大化性能，以及
-
开发无法从现成产品中获得的定制数据基础设施。
这些类型的工作在数据团队的早期阶段常常被忽视，但随着团队和数据集的增长，变得异常重要。在一个项目中，我们通过优化表分区将 BigQuery 的表构建成本从$500/天降至$1/天。 这些工作很重要。
一个在这方面走得很远的公司是 Uber。Uber 的数据工程师开发了一种叫做Queryparser的工具，自动监控所有对其数据基础设施的查询，并收集有关资源使用和利用模式的统计数据。Uber 的数据工程师可以使用元数据来相应地调整基础设施。
数据工程师还常常负责构建和维护运行数据基础设施的 CI/CD 管道。虽然许多数据团队在 2012 年时 VCS、环境管理和测试基础设施极差，但情况正在改变，数据工程师正在引领这一变革。
最后，领先公司的数据工程师通常还会参与构建不存在的工具。例如，Airbnb 的数据工程师开发了 Airflow，因为他们没有有效构建和调度 DAG 的方式。而 Netflix 的数据工程师则负责构建和维护一个复杂的基础设施，用于开发和运行数万份 Jupyter notebooks。
你可以在今天的市场上获得大多数核心基础设施，但仍然需要有人来监控它并确保其性能。如果你真的属于前沿数据组织，你可能还希望在现有工具的基础上推动界限。数据工程师可以在这方面提供帮助。
构建和维护数据摄取管道
虽然数据工程师不再需要手动开发 Postgres 或 Salesforce 数据传输，但现代数据集成供应商提供的现成集成大约只有 100 种。我们合作的大多数公司对其数据源的现成覆盖率在 75%到 90%之间。
实际上，集成通常是分阶段实施的。通常，第一阶段包括核心应用程序数据库和事件跟踪，第二阶段包括如 ESP 和广告平台等营销系统。这两个阶段的解决方案现在完全可以现成获得。一旦你深入到更具领域特定的 SaaS 供应商，你将需要数据工程师来构建和维护这些更专业的数据摄取管道。
例如，电子商务公司通常需要处理大量不同的产品，这些产品涉及 ERP、物流和运输领域。许多产品非常特定于某些行业，并且几乎没有现成的解决方案。预计你的数据工程师需要在可预见的未来构建这些管道。
建立和维护可靠的数据接收管道是困难的。如果你决定投入资源来建立一个，预计会比最初预算的时间更长，而且需要的维护也会更多。达到 V1 很简单，但让管道稳定地向你的数据仓库传送数据却很难。在你确定业务案例之前，不要承诺支持一个自定义的数据接收管道。一旦确定了，投入时间并将其建设得更为稳健。考虑使用 Stitch 的开源 Singer 框架——我们已经使用它构建了约 20 个自定义集成。
支持数据团队资源的设计和性能优化，用于 SQL 转换
在过去五年中，我们在数据工程方面看到的一种变化是 ELT 的兴起：这种 ETL 的新方式是在数据加载到仓库后进行转换，而不是之前。这种变化的具体内容和原因在其他地方有详细介绍；我在这里提到它的原因是 这种转变对 谁 构建这些管道有着巨大的影响。
如果你在编写 Scalding 代码来扫描 S3 中的 TB 级事件数据，并将其聚合到会话级别以便加载到 Vertica 中，你可能需要数据工程师来编写这个作业。但如果你的事件数据已经在 BigQuery 中（由 Google Analytics 360 加载），那么它已经完全可以在高性能、可扩展的环境中访问。不同之处在于 这个环境使用 SQL。这意味着 数据分析师现在可以构建自己的数据转换管道。
这一趋势在 2014 年随着 Looker 的 PDT 功能发布 开始真正兴起。在过去两年中，整个数据团队使用 dbt 构建了 500+ 节点的 DAG，并处理了多个 TB 的数据集。这一模式现在在现代数据团队中根深蒂固，使得分析师能够以前无法实现的方式自助服务。
向 ELT 的转变意味着 数据工程师不必构建大多数数据转换作业。这也意味着没有数据工程师的数据团队仍然可以通过为分析师构建的数据转换工具走得很远。然而，数据工程师在构建这些转换管道中仍然扮演着重要角色。数据工程师应该参与的两个关键领域是：
-
当性能至关重要时。
有时，业务逻辑需要一些特别复杂的转换，数据工程师的参与可以帮助评估特定构建表的方法的性能影响。许多分析师在 MPP 分析数据库的性能优化方面经验不足，这是与更技术性的人进行协作的绝佳机会。
-
当代码变得复杂时。
分析师擅长使用数据回答业务问题，但通常没有训练过如何编写可扩展的代码。很容易在你的数据仓库中开始构建表格，并使整个项目很快失控。让数据工程师参与考虑仓库的整体架构，并对特别棘手的转换进行设计审查，否则你会发现自己需要清理一团麻线。
构建非 SQL 转换管道
虽然 SQL 可以本地完成大多数数据转换需求，但它无法处理所有事情。一种常见需求是通过获取纬度/经度并分配特定区域来进行地理信息增强。目前，这在现代 MPP 分析数据库中尚未广泛支持（尽管这**开始发生变化**！），因此最佳答案通常是编写一个基于 Python 的管道，将数据仓库中的数据与区域信息进行增强。
Python（或其他非 SQL 语言）的另一个明显用例是算法训练。如果你有一个产品推荐器、需求预测模型或流失预测算法，它从你的数据仓库中获取数据并输出一系列权重，你会希望将其作为 SQL 基于 DAG 末尾的一个节点运行。
目前，大多数运行这些非 SQL 工作负载的公司都使用 Airflow 来协调整个 DAG。dbt 用于 DAG 的基于 SQL 的部分，然后在最后添加非 SQL 节点。这种方法提供了最佳的两全其美的结果，数据分析师可以主要负责基于 SQL 的转换，而数据工程师则负责生产级别的机器学习代码。
角色的变化也促使重新思考数据工程师招聘的顺序。以前的公认智慧是你需要先有数据工程师，因为如果没有数据平台，数据分析师和科学家就没有东西可用。今天，数据分析师和科学家应该自助服务，使用现成的工具构建他们的数据栈的第一个版本。在达到规模点时雇佣数据工程师：
-
规模点 #1: 当你的团队中有 3 名数据分析师/科学家时，考虑雇佣你的第一位数据工程师。
-
规模点 #2: 当你有 50 个 活跃 用户使用你的 BI 平台时，考虑雇佣你的第一位数据工程师。
-
规模点 #3: 当你仓库中最大的数据表达到 10 亿行时，考虑雇佣你的第一位数据工程师。
-
规模点 #4: 当你知道在接下来的几个季度中需要构建 3 个或更多定制的数据摄取管道，并且它们都是至关重要的时，考虑雇佣你的第一位数据工程师。
如果你还没有触及到这些点，你的数据分析师和科学家应该可能能够使用现成技术、自外部顾问的支持和你所参与的数据社区（如Locally Optimistic和dbt的 Slack!）进行自助服务。
关键是要认识到数据工程师不提供直接的业务价值——他们的价值在于提高你的数据分析师和科学家的生产力。你的数据分析师和科学家是那些与利益相关者合作、衡量 KPI 以及构建报告和模型的人——他们是每天帮助你的业务做出更好决策的人。雇用数据工程师来作为更广泛团队的增效器：如果增加一名数据工程师能使你的四名数据分析师提高 33%的效率，那这可能是一个好的决定。
数据工程师通过提高你的数据分析师和科学家的生产力来提供业务价值。
当你扩展数据团队时，我通常看到的最佳比例是约 5 名数据分析师/科学家对应 1 名数据工程师。如果你在处理特别大或不寻常的数据集，也许这个比例会有所变化，但这是一个很好的基准。
随着数据工程师角色的变化，理想候选人的档案也在变化。我的尊敬的同事Michael Kaminsky在我们就此话题交换的邮件中比我更好地表达了这一点，所以我在这里引用他的话：
我对这种转变的看法是数据工程师在团队中的角色发生了变化。它从一个基础设施的建设者变成了支持更广泛数据团队的角色。这实际上是一个相当大的转变，一些数据工程师（希望专注于构建基础设施的）并不总是对这种变化感到兴奋。
我实际上认为这对初创公司来说是非常重要的：他们需要聘请一位对为分析/数据科学团队构建工具充满热情的数据工程师。如果你雇用一位只是想在后台混日子并且不喜欢与技术水平较低的人员合作的数据工程师，你会经历一段糟糕的时期。我寻找的是那些愿意与分析师和数据科学家合作，能够发现“你做的事情似乎很低效，我想要构建一些东西来改善它”的数据工程师。
我完全同意这一观点。今天初创公司的最佳数据工程师是支持型角色，他们几乎参与数据团队所做的所有事情。他们应该对这种合作角色感到兴奋，并有动力让整个团队取得成功。
如果你读到这里，非常感谢你:) 这显然是我非常关心的话题。如果你认为我完全错误，请在评论中告诉我——我很想听听你在数据团队中构建数据工程师角色的经历。
最后，如果你目前考虑招聘数据工程师，我公司实际上进行相当多的数据工程师面试——我们发现这是一种保持行业脉搏的好方法。如果你希望在发出录用通知之前进行最后一次理智检查，我们很乐意为你管道中的候选人进行最终轮面试。请 联系 我们，我们可以安排一个面试。
感谢 Drew Banin。
简介：Tristan Handy 是 Fishtown Analytics 的创始人兼总裁。他为高级分析构建开源工具。
原文。经许可转载。
相关：
-
人工智能和数据科学中的前 10 大角色
-
数据集成和数据工程的区别是什么？
-
数据工程入门指南——第 I 部分