我们经常会找到对我们的团队有用的很棒的英语文章，并决定与Habra的读者分享他们的翻译是很好的。 今天，我们准备了Fishtown Analytics创始人Tristan Handy的文章的译文。
数据工程师在现代初创企业中的作用正在迅速变化。 您确定您了解团队何时以及为何需要这样的专家吗？
我经常与分析界的主要代表进行交流，并注意到他们对数据工程师在团队中的角色的理解并不正确。 这会给整个数据分析团队带来困难，我希望公司学习如何避免此类问题。
在本文中，我想分享一下有关何时，如何以及为什么值得雇用数据工程师的想法。 我的推理基于我在Fishtown Analytics的经验，在那里我与一百多家初创公司合作，获得了风险投资的支持，并帮助他们建立了数据分析和处理团队，以及通过与各种数据处理公司的代表进行交流而获得的知识。
如果您领导一个数据专家团队，则此职位适合您。
数据工程师的角色正在发生变化
现代软件使自动化与数据分析和处理相关的无聊工作成为可能。
2012年，至少有一位数据工程师需要在一家风险投资的初创公司中分析整个数据集。 这样的专家必须从不同的系统中提取数据，以便分析师和公司客户可以进一步与他们合作。 通常，需要以某种方式转换数据，以便于分析。 没有数据工程师，数据分析和处理专家将根本无法使用他们可以使用的数据，因此通常是由团队开始组建数据工程师。
到2019年，其中大部分可以通过现成的解决方案完成。 在大多数情况下，您和一组分析人员可以自行建立数据处理管道，而无需具有丰富数据科学经验的人员的帮助。 而且，这条管道一点也不差劲-现代的现成工具非常适合解决此类问题。
分析人员和数据科学家最近才有机会自己建立管道-仅在2-3年前。 发生这种情况的主要原因是Stitch ， Fivetran和dbt这三种产品（值得一提的是dbt是我公司Fishtown Analytics的产品）。 当启动分析团队意识到他们需要创建数据仓库时，它们几乎在Amazon Redshift之后立即发布。 花了几年的时间才能制造出高质量的产品-在2016年，我们仍然是先锋。
现在，使用Stitch，Fivetran或dbt构建的管道比使用Airflow专门设计的管道更加可靠。 我不是从理论上而是从我自己的经验知道这一点。 我并不是说用Airflow建立可靠的基础架构是不可能的，大多数初创公司只是不这样做。 在Fishtown Analytics中，我们已经与不同初创公司中的一百多个分析团队合作，并且这种情况已经重复了很多次。 我们不断地帮助人们从他们自己的管道转换为交钥匙解决方案，并且每次都会带来积极的影响。
数据工程师不应编写ETL
在2016年，Jeff Magnusson写了一篇基础文章《 数据工程师不应该写ETL》 。 这是我记忆中第一篇要求进行此类更改的帖子。 这是我最喜欢的部分：
*“在过去的五年中，数据处理工具和技术得到了发展。 大多数技术已经发展到可以满足您的需求的程度，除非您当然需要每天处理PB级数据或数十亿个事件。
如果您不需要超越这些技术的功能，则很可能不需要一支高度专业的程序员团队来开发其他解决方案。
如果您设法雇用他们，他们很快就会变得无聊。 如果他们感到无聊，他们会将您留在Google，Facebook，LinkedIn，Twitter等真正需要他们的地方。 如果他们不觉得无聊，那很可能他们是平庸的。 平庸的程序员确实成功地构建了大量复杂的，不适合常规工作的废话，他们称之为“解决方案”。” *
我非常喜欢这句话，因为它不仅强调了今天您不需要数据工程师来解决大多数ETL问题，而且还解释了为什么最好根本不请他们解决这些问题 。
如果您雇用数据工程师并要求他们建立管道，他们会认为他们的任务是建立管道。 这将意味着诸如Stitch，Fivetran和dbt之类的工具将对其构成威胁，而不是强大的实力来源。 他们将找到为什么完成的管道不能满足您的个人数据需求的原因，以及为什么分析人员不应独立进行数据转换的原因。 他们将编写易碎，难以维护且效率低下的代码。 您将依赖此代码，因为它是团队其他所有工作的基础。
远离瘟疫之类的专家。 您的分析师团队的增长率将急剧下降，您将花费所有时间来解决基础结构问题，而这根本不是为您的业务带来收入的原因。
如果不是ETL，那又如何？
您的团队真的需要数据工程师吗？ 是的
即使有了允许数据分析师和数据科学专家自己创建管道的新工具，数据工程师仍然是任何专业数据团队的重要组成部分。 但是，他们应该执行的任务已经改变，并且值得雇用员工使用数据的顺序也发生了变化。 下面，我将讨论何时执行此操作，现在让我们讨论一下现代初创公司中的数据工程师所负责的事情。
数据工程师仍然是任何专业数据团队的重要组成部分。
您的数据工程师不应创建已经准备好的解决方案的管道并编写SQL数据转换。 他们应该关注的是：
- 基础数据基础架构的组织和优化，
- 建立和支持定制管道，
- 通过改善管道和查询的设计和性能来支持数据专家团队，
- 构建非SQL数据转换。
基础数据基础架构的组织和优化
尽管初创企业中的数据工程师不再需要管理Hadoop群集或为Vertica配置设备，但在该领域仍需要工作。 确保用于收集，传输和处理数据的技术达到顶峰之后，您将在性能，成本或两者上都得到显着改善。 这通常涉及以下任务：
- 建立监视基础结构以跟踪管道的状态，
- 监视所有影响群集性能的任务，
- 定期保养
- 调整表模式（分区，压缩，分发）以最小化成本并提高生产力，
- 如果没有现成的解决方案，则开发自定义数据基础结构。
这些任务在开发的早期阶段常常被忽略，但是随着团队的成长和数据量的增加，它们变得至关重要。 在一个项目中，我们能够通过优化表分区将BigQuery中构建表的成本从每天500美元逐步减少到每天1美元。 这真的很重要。
优步是成功的公司的典范。 Uber的数据处理专家创建了一个名为Queryparser的工具，该工具可自动跟踪对其数据基础结构的所有请求，并收集有关所用资源和使用方式的统计信息。 Uber数据工程师可以使用元数据来自定义基础架构。
数据工程师通常还负责构建和维护用于管理数据基础结构的CI / CD管道。 在2012年，许多公司的版本控制，管理和测试基础设施非常薄弱，但是现在一切都在变化，这就是数据工程师的背后。
最后，领先公司的数据工程师经常参与创建尚不存在的工具。 例如，Airbnb工程师之所以创建了Airflow，是因为他们无法有效地生成数据处理图 。 Netflix的工程师负责创建和维护复杂的基础架构，以开发和操作成千上万的Jupyter笔记本电脑 。
您可以购买大部分基本基础架构，但仍应有人为其提供服务。 而且，如果您是一家真正进步的公司，则可能要扩展现有工具的功能。 数据工程师可以为您提供帮助。
建立和维护定制管道
尽管数据工程师不再需要手动将数据传输到Postgres或Salesforce，但供应商“仅”有大约100种集成选项。 我们的大多数客户可以立即访问与他们一起使用的数据源的75％至90％。
实际上，整合是通过波浪进行的。 通常，第一阶段包括主应用程序数据库和事件跟踪，第二阶段包括营销系统，例如ESP和广告平台。 如今，这两个阶段的交钥匙解决方案已经上市销售。 当您深入研究主题领域内SaaS供应商的数据时，您将需要数据工程师来构建和维护这些利基数据处理管道。
例如，通过Internet从事销售的公司与ERP，物流和交付领域中的许多不同产品进行交互。 这些产品中有许多是非常特殊的，几乎没有市售产品。 期望您的数据工程师在可预见的将来会开发出类似的产品。
建立和维护可靠的数据处理管道是一项艰巨的任务。 如果您决定将资源投入到创建中，请准备好比预算中最初设想的需要更多的资金，并且维护也需要比您计划的更多的工作。 管道的第一个版本可以简单地构建，但是很难使其保持存储中数据的一致性。 在确定业务正常运行之前，请勿致力于维护自己的数据处理管道。 完成后，请花一些时间使其变得可靠。 考虑使用Singer，这是Stitch的创建者提供的开源框架，我们使用它构建了大约20个集成。
通过改善管道和查询的设计和性能来支持一组数据专家
在过去五年中，我们在数据工程领域看到的变化之一是ELT的出现-ELT的新版本，它在将数据加载到存储中之后而不是在存储之前进行转换。 这种变化的本质和原因已经在其他资料中得到了很好的介绍。 我想强调的是，这种转变对谁建立这些管道产生了巨大影响。
如果在Scalding上编写代码以扫描S3中的TB级事件数据，然后将其上传到Vertica，则可能需要数据工程师。 但是，如果您的事件数据（从Google Analytics 360导出）已经在BigQuery中，那么它已经在高性能，可扩展的环境中完全可用。 区别在于此环境使用SQL。 这意味着分析师现在可以创建自己的数据转换管道。
当Looker发布PDT工具时，这种趋势在2014年得到发展。 在过去两年中，整个数据专家团队开始从500多个节点构建数据处理图并使用dbt处理大型数据集时，这种趋势愈演愈烈。 在此阶段，该模型已扎根于现代团队中，并为分析人员提供了前所未有的独立性。
切换到ELT意味着数据工程师不再需要执行大多数数据转换任务 。 这也意味着没有工程师的团队可以使用为分析人员设计的数据转换工具进行大量工作。 但是，数据工程师在建立数据转换管道方面仍然发挥着重要作用。 在两种情况下，他们的参与非常重要：
1.当您需要提高生产力时
有时，业务流程的逻辑需要进行一些特别复杂的转换，让数据工程师评估创建表的特定方法如何影响性能非常有用。 许多分析师没有在分析数据仓库中优化性能的丰富经验，这是开始与狭窄专家合作的绝佳理由。
2.当代码变得太复杂时
分析师非常擅长使用数据解决业务问题，但通常不会考虑如何编写可扩展代码。 乍一看，开始在数据库中构建表很容易，但是一切很快就会失控。 聘请一位数据工程师，他可以考虑您的存储的一般体系结构并开发特别复杂的转换，否则您将冒着被纠缠而几乎无法解开的风险。
构建非SQL数据转换
SQL最初可以满足大多数数据转换需求，但不能解决所有问题。 例如，通常需要通过获取经度和纬度并将其链接到特定区域来将地理数据添加到数据库中。 许多现代分析存储库仍无法解决此类问题（尽管这种情况已经开始改变！ ），因此最好的解决方案是在Python中构建一条管线，以用有关该区域的信息补充存储库中的数据。
Python（或SQL以外的其他语言）的另一个明显用例是机器学习。 如果您有个性化的产品建议，需求预测模型或流出预测算法（可从存储中获取数据并安排权重），则可以将其添加为SQL数据处理图的最终节点。
大多数使用非SQL解决此类问题的现代公司都使用Airflow。 dbt用于数据图的基于SQL的部分，非SQL节点作为叶子添加。 这种方法采用了两种方法中的最佳方法-数据分析人员仍然仍然主要负责基于SQL的转换，数据工程师可以负责工业用途的ML代码。
您的团队什么时候需要数据工程师？
改变数据工程师的角色还意味着重新考虑雇用员工的顺序。 以前曾认为您主要需要数据工程师，因为如果没有现成的数据处理和分析平台，分析师和数据科学专家将无法工作。 今天，数据分析和处理专家可以独立工作，并使用现成的工具创建数据基础结构的第一个版本。 当您的初创公司具有以下四个规模迹象中的任何一个时，请考虑雇用数据工程师：
- 您的团队中有3位数据科学分析师/专家，
- 您的BI平台有50个活跃用户，
- 您存储中最大的表达到10亿行，
- 您知道在接下来的几个季度中需要构建3个或更多的自定义数据处理管道，而这些管道都是至关重要的。
如果您尚未遇到这些情况，则数据专家团队可能可以使用现成的技术，外部顾问的支持以及同事的建议（例如，在Slack的Local Optimistic或dbt社区 ）自行工作。
要了解的主要是，数据工程师本身对业务没有任何价值，其主要工作是提高分析师的工作效率。 您的数据专家团队与利益相关者进行互动，衡量KPI并创建报告和模型-这些都是每天帮助您的业务朝着正确方向发展的过程。 雇用数据工程师来加强现有的大型团队：如果在雇用数据工程师之后，您的四名分析师的效率提高了33％，那么这很可能是一个很好的解决方案。
数据处理工程师可以通过帮助您的分析师和数据科学家提高生产力来使业务受益。
我认为，如果您决定扩展数据专家团队，则最佳比例约为5比1：每位数据工程师5名数据科学分析师/专家。 如果您使用特别大或不寻常的数据集，则此比率可能会发生变化，但这是一个很好的指南。
谁值得雇用？
随着数据工程师的角色变化，对理想人选的要求也随之变化。 我亲爱的同事迈克尔·卡明斯基 （ Michael Kaminsky）在我们对此主题的书信中对此表示很好，因此，我在这里引用他的话：
“我考虑所有这些变化，首先要考虑数据工程师在团队中的角色。 从基础架构的创建者开始，他成为了更多专家的支持链接。 这是一个重大变化，一些数据工程师（想专注于构建基础架构）并不总是对此感到满意。
我认为对于初创企业而言，最重要的事情是聘请一位充满活力并渴望为一组数据科学分析师/专家创建工具的数据工程师。 如果您聘请了一个数据工程师，而该工程师只想深入研究后端，却讨厌与技术技能较低的人员一起工作，那么结局可能会很糟糕。 我正在寻找愿意与分析师和研究人员合作并愿意说的数据工程师：“在我看来，您的工作完全无效，我想让情况变得更好。”
我完全同意迈克尔。 现在，创业公司中最好的数据工程师是团队的支持和支持，他们几乎参与了数据团队所做的所有事情。 他们应该喜欢团队合作，并且应该激发他们作为团队成功的动力。
如果您到了这个地方，谢谢您的阅读:)这个话题真的让我很担心。 如果您认为我完全错了，请发表评论-我很想知道您与团队中数据工程师一起工作的经验。
最后，如果您决定立即聘用数据工程师，那么我公司将与此类专家进行大量访谈-我们认为这是与行业保持同步的好方法。 如果您想在报价之前安排新的潜在团队成员的最后一次绩效测试，我们将很乐意与您的候选人进行最后面试，只需写信给我们！
Skyeng分析总监Gleb Sologub的评论 ：
Skyeng我们现在有30多名全职分析师，并且还没有数据工程师。 之所以能够做到这一点，是因为我们的整个数据基础架构都建立在 Tristan所说的云服务上。 我们使用Amazon Redshift作为分析存储库，使用Stitch和Matillion ETL从40多个生产数据库中收集数据，使用Segment收集事件，使用Redash和Tableau生成报表和仪表板，使用Amazon SageMaker for ML。
— - . , MVP- , , . , , , Tableau .
, , , - . , , : , .
- -, , , , . 90% , . , Skyeng.