数据工程师的崛起

 

本篇是对博文《The Rise of the Data Engineer》的译说和解读 这篇文章发于2017年,但依然有指导性和建议性,以及前瞻性。原文作者在Airbnb,Facebook,雅虎工作,与Google、亚马逊等多个各种规模的合作过,这篇文章是他的发现和见解。建议大家去读一读原文,我这里是带了我自己的体会和总结,但一千个人的眼中有一千个哈姆雷特。

原文:https://www.freecodecamp.org/news/the-rise-of-the-data-engineer-91be18f1e603/ By Maxime Beauchemin

很重要的一点,“数据工程”正在发展出新一代,与互联网革命一样,要发展出新的工具、新的方法,新的套路。也正是这种不断推陈出新的“新技术”的出现才使互联网以及计算机技术推动社会的进步和发展。

当商业智能工程师的工作逐渐超越了“经典”的商业智能,就开始创造出了新的的学科——数据工程师。 而新学科的出现,则意味着要开发新技能、新的工作方式、新的工具,而这些往往要背弃传统方法。

数据科学与数据工程

数据科学(Data Science)当下在经历“青春期”,自我肯定和定义自身的阶段。 数据工程(Data Engineering)比数据科学更为年轻些,也正在经历类似的事情。(下统称DE)

DS 与 DE 相同的部分:codeing, 深入分析,数据可视化 但是DE比DS更接近软件工程(有争议),DE还需要进行工程建模、基础设施、框架和服务。

DE还不成熟的理解:可以被视作是商业智能、数据仓库以及部分软件工程的超集,同时集成了“大数据”分布式系统、扩展Hadoop生态系统、流处理和大规模计算的概念。

对于较小的公司,没有数据基础架构团队,仅是设置和运营公司的数据,常用的平台有Hadoop,Hive,HBase,Spark等。 对于大公司而言,对数据基础架构团队的需求增长,则开始创建正式的角色来管理此类工作,自动化数据工程流程,解决更高级别的问题。同时,也出现了更好的自助服务工具,不再仅仅是制作和维护报告、仪表板等简单的任务。

数据仓库技术(ETL)的变化

代码允许任意级别的抽象,允许以熟悉的方式的进行所有逻辑操作,与源代码一起进行良好的集成,易于版本和写作。

在过往,ETL工具演变为图形界面,这是数据处理历史上的一个弯路。抽象“数据处理”,在计算和存储上都有一定的复杂性,但解决方案不是将ETL的原语(如聚合、过滤等)变成以“拖放方式”展现,而是更加抽象的级别。

比如,在现代数据环境中所需抽象的一个例子是A/B测试框架中的实验配置:什么是实验?什么是相关的治疗方法?应该暴露多少百分比的用户?每项实验预计会影响哪些指标?实验什么时候生效? 我们现在有一个框架,可以接受高级的、精确的,然后执行复杂的统计计算,并提供计算结果。显然,这个抽象的输入参数不是ETL提供的。

所以,对于现代数据工程师来说,传统的ETL工具在很大程度上已经过时,因为逻辑无法用代码表示,这导致工具不能直观的表达所需的抽象。这迫使数据工程师的角色要来重新定义“ETL”,并且建立一套全新的工具、方法和约束等,以及新一代的“数据工程师”。

数据建模发生的变化

经典、传统的建模技术,定义了我们数据建模方法,进行数据仓库相关的分析工作。现在,存储和计算比以往任何时候都便宜,随着分布式数据库的出现,线性扩展等,稀缺资源就是“工程时间”。

数据建模技术发生的变化:

1、“非规范化”的进一步发展:维护Surrogate keys(主键)可能会很困难,而且会降低事务表(fact tables)的可读性。使用自然的、人类可读的键和纬度属性变得越来越普遍,这减少了分布式数据库链接的需求,这个需求是很高昂的。 像ORC,Parquet等序列格式化,或是Vertica等数据库引擎,支持编码和压缩,可以解决“非规范”的大部分性能损失,这些系统已经被教导自行规范数据存储。

2、blob:现在数据库通过本机和函数对blob的支持越来越多,这将融入到数据建模中,开启新的动作,允许事务表在需要时一次存储多个。

3、动态模式:map的出现减少、文档存储日益普及,对数据库中blob的支持,于是,在不执行DML的情况下,发展数据库模式变得更容易,采用迭代方法进行存储更容易,并且无需在开发之前获得完全的共识和支持。

4、 系统化快照维度:存储每个ETL调度周期的维度的完整副本,通常在不同的表分区当中。用一种简单的方法,作为处理缓慢变化的维度(SCD),在编写ETL和查询时都很容易掌握。 将维度的属性反规范化到事实表中,这方便在事务处理时跟踪其值,也很容易,且相对便宜。 反观,复杂的SCD建模技术并不直观,降低了可访问性。

5、一致性:在数据环境中,一致性一直都是非常重要的,但是数据仓库需要快速移动,且有更多的团队被邀请作这项工作,所以不是很必要,更多情况下是进行权衡。

可以说,随着计算周期的商品化,以及更多的人精通数据,不需要在仓库中预先计算和存储结果。比如,我们可以有复杂的Spark,该任务只能按需计算复杂分析,而不能安排成为仓库的一部分。

角色与责任

数据仓库是专门用于查询和分析的事物数据的副本 数据仓库是面向主题的、集成的、时变的和非易失性的数据集合,以支持管理层的决策过程

数据仓库与以往一样重要,数据工程师的焦点是数据仓库,负责其构建、运营等方方面面,同时还与数据科学家、分析师和软件工程师参与其建设和运营。

数据工程团队通常会在数据仓库中拥有经过认证的高质量区域。比如在Airbnb,有“核心”模式,明确定义和测量服务级别协议(SLA),严格遵循命名约定,业务员数据和文档质量最高,相关的管道代码遵循一套明确的定义。

通过数据对象的标准、最佳实践和认证过程的定义,这些成为数据工程团队很重要的组成部分,成为“卓越中心”。团队可以发展为分享或领导教育计划,分享核心竞争力,以帮助其他团队成为数据仓库的更好公民。比如,Facebook有一个数据阵营的教育计划,airbnb在开发一个类似的数据大学的计划,数据工程师领导会议,教会人们如何熟练掌握数据。

数据工程师也是数据仓库的“图书馆员”,编目和组织元数据,定义一个文件或从仓库中提取数据。在快速发展、略微混乱的数据生态系统中,元数据管理和工具成为现代数据平台的重要组成部分。

性能调优和优化

数据,在当下比以往任何时候都更具有挑战性,公司的数据基础设施预算正在不断增加。这使得数据工程师在性能调优和数据处理、存储有划伤,花费周期越来越合理。在这一领域的预算很少收缩,因此优化通常是实现更多的资源,或尝试线性化资源利用率和成本的指数增长。

数据工程堆栈的复杂性跨度很大,呈爆炸式增长,我们可以假设优化这种堆栈和流程的复杂性,具有同样变化的挑战程度。我们只需要很少的努力,就可以轻松获得巨额的成功,所以这适用递减收益法。

建议:基础设施与公司一起扩展,并始终保持资源意识。

数据集成

数据集成是通过数据交换整合业务和系统的实践,与以往一样重要,且具有挑战性。在新的标准方式下,我们希望将服务软件(如SaaS)生成的数据,也带入到我们的仓库,以便可以根据其余数据进行分析。Saas通常拥有自己的分析产品,但缺乏公司其他的数据,因此需要将其产生的分析数据,提取回来。

在这样的情况,Saas产品重新定义参考数据,而没有集成和共享。没有人想在两个不同的系统中,手动维护两个员工或客户列表,而且在提取数据导进仓库时,必须进行模糊匹配。

但即使这样,公司高管没有真正考虑数据集成的挑战,与Saas提供商签订协议,提供商也低估了集成工作量,以促进他们的销售,使数据工程师陷入大量且混乱的工作中。Saas api通常设计不当,文档不清晰,而且“敏捷”,也就是说,您可以在不事先通知的情况下,进行更改。

服务

数据工程师在更高的抽象层次上运行,在一些情况下,要提供服务和工具来自动化底层的工作类型,底层的含义是可以手动完成的。

1、数据提取:抓取数据库,加载日志,从外部存储或API获取数据的服务和工具

2、度量计算:用于计算和汇总参与度,增长或细分相关度量的框架

3、异常检测:自动化数据消耗,提醒人们发生异常事件或趋势发生显著变化。

4、元数据管理:允许生成和使用元数据的工具,可以轻松地在数据仓库内和周围查找信息。

5、实验:具有重要的数据工程组件,A/B测试和实验框架

6、仪表:分析记录事件和与这些事件相关的属性,确保上游捕获高质量数据有既得利益。

7、会话:专门用于及时了解一系列操作的管道,允许分析人员了解用户行为

就像软件工程师一样,数据工程师应该不断寻求自动化他们的工作,构建抽象参数,然后做更为复杂的内容。虽然自动化的工作流程的性质因环境而异,但自动化他们的需求基本上都是通用的。

技能

1、SQL

2、数据建模技术

3、ETL设计:编写高效、有弹性、可演化的ETL

4、架构预测

字数:3635     

赞助我

一饮一啄 / 皆为因果
WeChat 微信
Alipay 支付宝

评论区