Data 领域分工及避坑指南，看这一篇就够了！

最近跟朋友忆当年，聊起初入 Data 行业的场景，发现包括当时的我们在内，对于行业的具体分工并不了解。

最核心的原因在于 Data 的分工的确很复杂，哪怕同为研发也不一定了解其中的区别。公司在招人的时候也会用一份 JD 招各个方向的人，很容易出现把人招进公司后才出现预期不匹配的情况，造成人才流失的情况。此外，这也和不同公司所在的阶段有关，很多公司会使用复合型的打工人，也就是一个角色身兼数职。

为了方便大家进一步了解行业分工，太可研究所（techinstitute）将详细介绍一下在 Data 领域不同方向的打工人都在干什么、会用到哪些技术、哪些岗位之间是可以互换的，希望能为在”金三银四“找工作的朋友带来一些启示。

Vol.1

Data 本质上可以分为生产者和消费者。

生产者往往是各类业务应用，其会使用各类数据库，而绝大部分企业都不会自研数据库，能把各类数据库用明白就很不错了，所以出现的第一个职位是 DBA。

这几年随着云计算的兴起，DBA 的角色发生了不少变化，但不妨碍这类职能的本质。DBA 的职责主要包括安装、部署、运维、调优各类数据库，跟数据库供应商扯皮，制定数据库使用规范……总体而言，做的事情很多，一般情况下不用写代码，即使写也是写脚本代码。

DBA 是很吃经验工种，现在各类层出不穷的新型数据库对 DBA 来说是个冲击：一方面是新数据库很容易出问题；另一方面是文档、最佳实践、避坑指南很少，DBA 作为数据库的用户要不停地踩坑。此外，早年间在Oracle、PostgreSQL、MySQL 上积累的经验无法直接迁移。

第二部分就是消费者，其需要对数据进行分析帮助老板们做经营决策，所以出现了第二个职业数据分析师（Data Analyst）。DA 是个非技术更偏运营的角色， 需要把老板们的需求转化成指标，进而把指标转换成对应的数据看板，一般会使用各种 BI 工具如 Tableau、Superset、Excel 等。

DA 是比较传统的数据消费者，随着 AI 的兴起，又诞生了一类新型的数据消费者——数据科学家（Data Scientist）。与 DA 不同的是，DS 需要有更深入的统计学、机器学习和编程技能，能够进行复杂的数据建模和算法开发（DA 更注重数据可视化和基本的统计分析）。可以这样朴素地理解，DS 会写一点 Python 代码，而 DA 只会写 SQL，这是两者最大的区别。

Vol.2

出于稳定性、扩展性、安全等等方面的考虑，数据往往不会只在一个库里，相对正规一些的企业都会将分析库和业务生产库隔离，而且会选用不同类型的数据库。

数据不会自己长腿从 A 库到 B 库，肯定需要技术人员做数据的搬迁，这就诞生了第四个职业数据工程师（Data Engineer），这个职位就和大数据有关系了。在大数据技术出来之前，Data Engineer 就已经存在很久了，使用各类作者没听说过的工具做 ETL，把数据从业务库清洗到数仓。在 Hadoop 等大数据生态兴起之后，技术栈就全面切到了 Hadoop、Spark、Flink、Presto、Kylin 等技术。而随着 Hadoop 生态的退潮，Data Engineer 的技术栈又在迁移中，切换到各类云原生的 k8s、对象存储、doris、clickhouse 等技术。

不难看出，每次技术的迭代，Data Engineer 都要紧跟着时代快速更新技术。对于 Data Engineer 来说，技术广度和快速学习能力尤为重要，市面上的数据存储、数据库、计算引擎、调度框架、数据平台层出不穷，需要快速熟悉各个产品的优劣势、适用场景、性能调优、故障排查等。从写代码角度看，Data Engineer 的代码能力不一定多出众，但需要熟悉各类产品的 SDK，可以快速将需求转换成对应的代码。

Data Engineer 的工作内容要使用各种工具移动数据，但这些工具有的是开源版本，有的是商业版，使用十个以上的工具再正常不过了。不过工具彼此之间协同起来往往会有些别扭，例如，每个工具都会有自己的权限系统，有自己的多租户，也都会有自己的一套表、数据集、任务、自定义脚本的概念，如果全靠数据工程师手工一个个的维护，肯定不可持续。因此，不少企业就会研发一套数据平台对接各类产品，对外提供统一的用户体验，这就需要第五个职业数据平台工程师（Data Platform Engineer）。数据平台工程师需要对各个产品有代码级别的了解，能够进行适量的改造，把它们统一到一个平台。

如果企业规模进一步扩大，业务复杂度再提升一个量级，大数据的另一个“大”复杂度就变成了主要矛盾，此时需要进行数据治理，否则数据会变成一片沼泽。数据治理的理论可以追溯到数仓建模理论，到目前为止数仓产品迭代了好几轮，但这套理念一直都不过时，伴随着这套理论和业界的实践逐渐产生了新职位——数仓工程师（Data Warehouse Engineer）。

数仓工程师更关注数仓设计、存储治理等工作，会和前文提到的分析师、科学家紧密配合，然后定期给数据工程师“派活”。数仓工程师一般不写代码，但对 SQL、数据治理理论和业务特别熟。不少公司会把数据工程师和数仓工程师二合一，或者数仓工程师和数据分析师二合一、或者三合一。

BI 是数据可视化、数据分析的利器，但企业往往会有各类自定义的需求和场景，或者是 BI 产品过于通用很多新场景支持不足，比如用户旅程、营销分析、用户画像、归因分析等。此时就需要自研一些内部的数据产品，这类产品与非数据类的产品无异，都需要前后端、产品经理、UX 等角色。如果只是打一份工，对工程师来讲技能天花板比较低，因为企业内部产品往往重流程、用户量很少而与市场上要求的用户体验、高并发、微服务可能都不沾边，核心竞争力在对数据和业务的理解上，这个岗位一般被称为数据产品研发工程师（Application Engineer）。

Vol.3

以上的分工是建立在企业不大、数据规模尚可的基础上，使用各类开源或商业产品就能满足需求。对于巨头来讲，现有的产品总会碰到这样或那样的问题，此时就会走上自研的路径，国内的大厂、海外的巨头无一例外。此时会引入各类内核研发工程师：

如果是数据库就会找数据库内核工程师；

• 如果是 Spark、Flink 这类计算引擎会找计算引擎工程师；
• 如果是自研类似 hdfs、对象存储会找存储研发工程师；
• 如果数据体系太多、太复杂会需要更多的研发工程师。

这几种不同类型的工程师都各有特点，例如研发工程师，他们通常对自己研发的产品很熟悉，顶多对竞品、上下游产品也很熟，但对整个数据体系会缺乏认知，会在自己的方向上持续深耕，职业生涯比较长，直到自己方向的产品彻底被历史淘汰。

又例如计算引擎工程师，工作内容会包括对单一的计算产品如 Spark 做深度的改造，包括调度模型、并发逻辑、扩展SQL语法、native执行引擎改造、对接各类自研的产品、性能优化、可观测性、安全等深度优化。更有甚者需要走完全自研的路径，比如从头写一个数据库。

分享一个小插曲，很多 HR、猎头分不清楚数据平台工程师、数据工程师和内核研发工程师，因为他们简历里的关键词都差不多，会有 Spark、Flink、Presto、Doris 等关键词，但工作内容天差地别。

Vol.4

至于哪个类型的工程师在行业里更受欢迎，其实没有标准答案，毕竟这都是由市场供需关系决定。举个例子，如果再过十年市面上没有了解 Oracle 的 DBA 了，还在使用 Oracle 的企业只能出高价招人维护；再比如前两年数据库赛道投资火热，市场上一下子多了很多数据库内核的需求，相应的研发薪资就水涨船高。

目前，市场上数据类的研发工程师相对短缺，而且门槛也比较高，所以打工人的薪资会更高。但如果有更高的职业发展目标，就需要更高的视野，而单一产品的内核研发工程师天然就会有局限，反倒是不如其他岗位，所以内核研发很适合一门心思搞技术的"I人"。

太可研究所（techinstitute）真心希望这篇文章能帮助刚开始工作的同学对职业选择有更清晰的认识，希望能帮助 HR、猎头对 JD 有更高的辨识度，也希望帮到要招人的老板们理清楚人才画象，以上。