分析工程作为一门学科的兴起是数据领域最热门的趋势之一。如果您不熟悉,分析工程涉及“向最终用户提供干净的数据集,以使最终用户能够回答自己的问题的方式对数据进行建模…以及转换、测试、部署和记录数据。”该角色包括许多领域,与传统的数据分析相比,它更接近于软件工程,因为它涉及到编写编程脚本,并通常将数据作为一组软件生成的工件进行维护。


虽然有一些关于分析工程和数据分析角色将如何演变的争论,但我坚信分析工程是分析的关键一步:使人类能够解决分析中最棘手的计算机科学问题之一。


尽管在自动化数据建模过程和提取负载转换/提取转换负载(ELT/ETL)方面做出了巨大的努力,但这些任务对于计算机来说仍然太难执行。事实上,它们可能永远不会是自动化的(或者很可能是人工智能完成的)。

研究表明分析工程师将会崛起

为什么?每个企业和组织都是不同的,有不同的概念和实体来建模,而这些组织中数据的表示方式只受人类创造力的限制。在数据建模中有一些常见的模式(从规范化的指导,如星型模式,到事件的规范化表示,如服务器日志),但是,在有限的范围内,没有一种真正的方法来为每个业务建模。因此,即使是作为一名学者,我也将数据清理和规范化的算法尝试领域视为一个焦油坑,在那里“一切都是可能的,但没有什么有趣的事情是容易的。”


分析工程师的崛起向数据清理和语义建模的复杂性致敬。仅仅将比特运送到一个公共仓库(即数据工程)是不够的——这些比特需要被组织起来,并映射到组织其他成员可以使用和依赖的概念中。业务用户不在乎将产品参与度指标与保留率挂钩是否需要加入两个表或七个表;他们只想把他们关心的指标和属性摆出来,准备好进行分析。


从这个角度来看,分析工程角色是连接业务上下文和组织数据的缺失粘合剂——由于该任务的内在复杂性,将业务上下文连接到数据需要人员和一定数量的代码来为每个组织定制。此外,分析工程师的角色正在得到更好的定义和更高效的发挥,这要归功于设计用于在云级别与人合作的工具,包括用于定义自定义转换(如dbt)、将语义概念导出到业务(如度量层)和监控结果(如。,数据可观测系统)。


分析工程对于现代组织内部的数据分析来说是一件好事。


劳动力市场缺少分析师已经成为一种比喻,但值得重复:在现代组织中,不仅没有足够的分析师,而且雇佣足够的分析师来解决问题实际上也不划算。与FAANG的一些最先进的团队合作,比如斯坦福大学的谷歌Adwords,让我震惊的是,实际上很少有人有专门的分析师——大多数人只是能够访问数据,但却无法接触到人为他们解释数据的人。今天,作为一家数据分析初创公司的首席执行官,我很难决定在分析上投资多少:如果分析师是免费的,每个部门都会有一个,也许两个分析师。但分析不是免费的——我们有数据,但没有资源。


通过标准化给定组织内的数据集和数据模型,分析工程师减少了下游分析中的摩擦。分析师不必花费数小时或数天的时间来定义正确的指标,也不必拉正确的列并仔细检查它们的含义,他们可以直接跳到他们想问的问题上。而且,对于常规和重复分析,分析师可以将分析置于自动驾驶仪上。


后一点特别有趣:大多数业务用户关心一些关键指标。因此,如果分析师能够识别代表业务部门内关键指标的规范数据源、指标和表,那么,从理论上讲,每天出现的报告和问题比以往任何时候都更容易自动化。”为什么敬业度下降了?“检查分析工程团队建立的大平面表格的第七列到第十列,以及第七十列到第九十列。”上周亚太地区发生了什么?”检查另一张大平板桌子的第四、十七和二十二栏。


在这个“自动驾驶仪”场景中,分析师仍然扮演着一个关键角色:业务和数据之间的转换器。要真正理解与给定的业务运营商相关的内容,通常不在数据或元数据中,比如部门的OKR和给定的一周或一个季度的关键活动,需要大量的上下文。因此,分析员的工作通常是将业务上下文与可用的数据联系起来,并通过授权数据工程师管理和处理底层数据,使分析员能够最终为更多的业务提供服务。


分析工程的结果是,作为一门学科,分析工程实际上是对当今分析师所扮演的多方面角色的更广泛认可,是分析工作流程的一个层次,它最终拥有一些体面的、以人为中心的工具来专门化和提高效率。随着时间的推移,这种分层可能会继续下去:一些分析师将是分析工程师,另一些将是度量工程师、根本原因分析师、场景规划人员和/或演示文稿构建人员。而且,随着分析工具的最后一英里变得更好,我们将看到一个每个人都是分析师的世界。分析工程师恰好拥有现代数据堆栈中最快速发展和最热门的工具包之一——堆栈的其余部分必须迎头赶上!

免责声明

我来说几句

不吐不快,我来说两句
最新评论

还没有人评论哦,抢沙发吧~