分析工程师 – 数据团队中的新角色 - KDnuggets

在不断变化的环境中，对于许多公司，数据工程师、分析师和数据科学家的角色和职责正在发生变化，这迫使我们引入一个新角色：分析工程师。

分析工程师处于数据科学家、分析师和数据工程师技能集的交叉点。他们为分析师和数据科学家的工作带来了正式而严格的软件工程实践，他们为数据工程的工作带来了分析和业务成果的思维方式。他们的工作是构建工具和基础设施来支持整个分析和数据团队的工作。

在我们进一步深入了解该角色之前，我们应该先介绍一些有关数据团队“传统”角色的背景知识。

• 数据工程师：传统上，这是将字节从 A 点移动到 B 点的“管道”工作，通常被误称为“ETL”。他们关心的是为摄取和存储数据构建健壮且可扩展的基础设施，但通常不关心“业务逻辑”——一旦数据进入仓库，这不再是他们的问题。
• 分析师：传统上，这是一项报告和纯粹的分析工作。使用少量 SQL 和大量 excel，分析师将维护仪表板并执行一次性战略分析以支持关键业务计划。
• 数据科学家：有点喜忧参半，但数据科学家传统上花时间使用统计编程语言（如 R 或 SAS）来执行更复杂或更复杂的分析。他们可能会将机器学习模型“原型化”，然后交给“真正的工程师”在生产中实施。

在过去几年中，我们看到分析领域出现了许多令人兴奋的发展，这些发展导致这些传统职责发生了转变。他们是：

• MPP SQL 数据仓库技术（如 Redshift、BigQuery 和 Snowflake）的兴起
• Stitch 和 Fivetran 等数据管道即服务公司的诞生
• 出现 SQL-first BI 工具，如 Looker、Mode 和 Periscope
• 公司将重点放在预测和个性化上

前两者加在一起，极大地改变了分析师的角色。现在分析师 必须 知道如何编写 SQL，使用 git/github，并且通常将大部分时间花在 编写代码上. 虽然他们不一定接受过软件工程师的培训，但他们现在负责管理大量代码库。

类似地，虽然数据工程师过去常常花费大量时间在系统之间构建新的数据集成或在平台上工作以进行可扩展计算，但现在大部分工作都可以转移到 Stitch/Fivetran（集成）或仓库本身（只是让 BigQuery 找出最佳查询计划）。

最后，数据科学家突然开始负责管理复杂的生产系统，这些系统正在制作具有重大业务影响的实时生产。

那么新的角色和职责是什么？

• 数据工程师：仍然负责数据基础设施和管道代码，但现在的团队总体上比过去小了很多。许多公司一开始只需要使用承包商和顾问就可以了，他们可能只需要一两个数据工程师来“填补”他们无法从现成的解决方案中购买的东西
• 分析师：除了执行临时分析外，分析师还负责编程和管理 BI 工具并编写一些 ELT 作业（在 Looker PDT 中或通过dbt 之类的工具 ）
• 数据科学家：除了完成一次性的研究任务外，数据科学家还管理复杂的数据清理和编排管道，这些管道输入机器学习模型和复杂的测试平台。

那些以前在这样的组织中工作过的人可能会感受到缺少角色的压力。尽管数据科学家和分析师正在编写大量代码，但成为出色的软件工程师并不是他们所接受的培训，而且通常也不是他们的首要任务。同样，虽然数据工程师是出色的软件工程师，但他们没有接受过如何实际使用数据方面的培训  ，因此无法始终与分析师和数据科学家有效合作。

我相信这个差距应该由分析工程师来填补。他们的工作是：

• 着眼于性能和可维护性编写生产质量的 ELT 代码
• 指导分析师和数据科学家了解软件工程最佳实践（例如，构建测试套件和 CI 管道）
• 构建帮助数据科学家和分析师更高效工作的软件工具（例如，编写供分析师使用的内部 R 或 Python 工具包）
• 与数据工程师合作开展基础设施项目（他们倡导并强调应用程序的商业价值）