名人文章
当前位置:上犹文章网 > 名人文章 >
数据工程师是个有前途的职业么?

最近一直在招聘数据工程师,我们自己的数据平台也有了些眉目,可以写写这个主题了。另外,以前写过一个系列叫做「后端是长久的职位么上」,很多朋友一直问,下呢?今天这篇文章是「下(1)」。

国内公司一般把处理和分析数据的工程师职位叫做数据工程师,或大数据工程师,虽然这个称谓像「数据科学家」一样语焉不详,甚至同样会被过度解读,但总是比科学家低调一点,安全一些。无论是数据科学家还是数据工程师,都是需要和数据打交道的人。他们是一群能够处理和分析海量数据的汉子,或女汉子,每天从手里流过上亿条的数据是稀松平常的事情。

那么,数据工程师是个有前途的职业么?我觉得是,不过这个职业与前端工程师或移动工程师相比,人数的需求可能没有那么多,但要求更高一些,不仅是技术上的要求,而且要对产品和数据敏感,同时具备很好的协调性,因为数据工程师可能要与产品经理、决策者、商务等各种角色打交道。

为什么数据工程师在这个时代会变得炙手可热呢?在移动互联网和云计算的时代,数据正在以几何级数增加,我们每个人每天都在产生大量的数据。当你开车上班的时候,会产生导航和交通数据,我们生病看医生的时候,会产生医疗数据,我们购物的时候,处理邮件的时候,编写文档的时候,查看股价的时候,拿着手机在路上打皮卡丘的时候……都在产生各种数据。未来是一个数据构筑的世界,数据也会改变未来。无论是实业创业还是移动互联网创业,这个趋势将不可逆转。

最近一直在看一些大数据相关的资料,结合我们自己构建数据平台的一些实践活动,谈一下我的几个想法。

要有数据,而且得大。没数据都是扯闲篇的

经常遇到一些读者问,想学习大数据相关的技术,怎么入手?或者想在公司引入 Hadoop、Spark、Presto 等一系列技术框架,怎么出手?我就问,你们数据是什么量级呢?答,几百万吧!几百万条记录您用得上这些技术吗?如果你真的想从事数据相关的工作,最好到一家「有数据」的公司,没有真实数据,你永远不会遇到真实环境和数据给你带来的挑战,甚至,你根本想象不到会有哪些挑战,技术就会变成无水之源。知和行隔着万丈鸿沟,看别人纵马狂奔总是容易的,你得自己骑上去试试。

什么是大数据?这个大是相对的,我们人为的去给大数据设定一个阈值,比如1PB,毫无意义,只有当前的数据规模大到对你现有的软硬件技术构成挑战时,才能称作大数据。比如公司内产生的数据已经无法通过关系数据库处理了,得想别的辙,可以算「大」。而且,大数据和时代息息相关,八十年代的大数据和今天的大数据是不可比拟的(为什么八十年代也有大数据呢?因为数据科学已经存在了几十年了呀)。

可以说,「大数据是一种文化现象,它描述了数据在人类生活中所占的比重,随着科技的发展,数据所占的比重会越来越大」。如何描述大数据的特征呢?有个 4V 原则,分别指容量(Volume)、种类(Variety)、速度(Velocity)和价值(Value),你的公司有没有大数据,大数据的形式和能对公司产生的价值,都可以从这些方面来描述。

无论如何,你得有数据。

进行数据分析是一件困难的事

以前有读者发来邮件和我说,后端有什么挑战呢,几乎所有的技术都有现成框架了啊!首先,这些框架也是工程师设计和研发出来的,我以前说过,「顶级工程师做工具和平台」,想要找挑战,你可以开发出更好的工具啊。其次,即使有了这些工具,我们去处理数据的时候,依然会困难重重。

如果你想成为一个优秀的数据工程师,你需要统计学和线性代数的相关知识,你必须有熟练的编程技巧和数据抽象的能力,还能做数据的可视化。完成了数据平台的构建,还有机器学习等着,还有人工智能等着,还有不可知的未来等着,有时候我一想到这些,就会产生特别绝望的想法:人类终究还是要输给数据吧。

即使是最基础的数据处理链路,比如数据清洗、存储、分析和计算,也会碰到各种问题。我们最早一版的处理应用商店和游戏中心等 App 数据的时候,链路是这样的:数据上报,通过 hash 名称存成 gz 文件,然后用 Python 进行数据清洗,存入 Hadoop 集群的 HDFS,再进行离线计算,通过 Spark SQL 把部分数据存入 MySQL,并提供 HTTP API,给前端做展示。

优化后的策略是:对埋点数据格式进行重新整理和规划,引入 Presto,通过 ETL 程序把 HDFS 文件数据导入 Hive,并做 ORC 压缩处理,形成二进制格式(速度快,节省空间70%),并进行分区。然后通过 Presto jdbc 定时调度任务,将 Hive 数据做统计聚合至 MySQL。优化后的离线分析速度和灵活性都大大增加了。

推荐一下 Presto,这是一个非常优秀的分布式 SQL 查询引擎,可以实现全内存并行计算,动态编译执行计划,进行本地化计算。既适用交互式分析查询,也可以通过 API 实现数据聚合,数据量可以支持 GB 到 PB,非常惊人。

离线分析有了点眉目,还需要实时分析。有人说简单啊,Flume 进行数据采集,Kafka 做数据队列,Storm 作为 MQ 的消费者,对采集到的数据进行实时分析和流式计算,再存 MySQL,就行了。嗯,我就说说……

即使这是一套成熟的技术方案,当你去处理自己的实际业务时,也会遇到各种问题。你需要熟练掌握这些技术和引擎,并熟知你的业务数据,才能抽丝剥茧,层层推进,抵达彼岸。

好了,数据量足够大了,可以做机器学习了……

「嘀嗒嘀嗒」公众号作者朱赟博士曾经为「攻城狮群」写过两篇机器学习入门的文章,有兴趣的可以去围观一下,二爷看了之后都开始沉迷机器学习了。搜索「AngelaTalk」,关注「嘀嗒嘀嗒」后点击中间的自定义菜单,可以找到这两篇文章。对了,朱老师还写过一篇数据科学家的文章,也可以找来对照阅读。

人工智能……算了。

有价值的数据只能提供参考,并不能完全指导工作。

有了数据,有了数据分析结果,是不是就万事大吉了?非也,数据只能做参考,如果只看数据就可能出问题,因为数据会带来误导。

微软研究院的 Kate Crawford 女士曾经提到,如果仅对飓风桑迪到来前后的部分推特采样数据进行分析,可能会得出这样的结论:人们在飓风来临前在购物,飓风过后在聚会。

仔细分析后你会发现,这些推特数据大部分来自纽约州。首先,这些人是推特的重度用户,其次,沿海的新泽西人正在担心他们的房子会不会被飓风吹倒,谁还有心思和时间去发推特呢?换句话说,如果你使用推特数据来分析桑迪飓风的影响,得出的结论可能会是这场飓风危害不大。事实上,真正受到飓风影响的人根本没时间发推。

还有推荐引擎,经常有人在朋友圈抱怨,京东为什么会给我推荐没品位的手机,微博为什么给我推荐不适宜的影片,如果碰巧是个老程序员,还会抱怨这些平台的算法真是烂啊。其实不是这样的。也许你根本就没有评价过人家的商品呢,也许你根本就不是目标用户呢,也许,就是推荐引擎出了问题啊……

总之,数据的相关性不能完全体现因果关系。数据并不会自己说话,它只能够以一种量化的、无力的方式去描述和再现我们身边的社会事件。在现阶段,人还占据绝对主导地位!


一个产品,如果没有数据的反馈和感知,是没有生命力的。一个企业没有数据,估计也很难走的更远。要看数据啊!

今天是卖桃者说 本月开放周期最后一天,敬请关注。


三表发了一篇「不合时宜」的文章,导致「三表龙门阵」被禁言了一个月。「三表蛇门阵」是他的临时避难所,这个月还想看三表的文章,搜索「sanbiao66」关注。



「即刻」是个很有创意的新形态资讯APP。你关心的五花八门的事情被做成了即刻上一个个的主题,可订阅跟踪相关资讯。我自己也在用,基本能替代微博和新闻软件,还经常发现一些让人欣喜的技术主题,值得一试。

    推荐文章