1.3 大数据人才

1.3.1 供需失衡

大数据产业既然如此炙手可热,那么大数据人才的待遇如何呢?这一点其实不用多说,只要大家时常关注一些猎头QQ群的状态,或者猎头朋友的签名档内容,再或者干脆到“猎聘网”、“前程无忧”等专业的人才中介网站去看看就会了然于胸——30万年薪找不到人,40万年薪找不到人,50万、60万还是找不到人,一时间可谓洛阳纸贵,似乎市场上的大数据人才是“一将难求”。这也从一个侧面说明,很多公司愿意花这么多薪水雇佣一位大数据人才,不管他的头衔是大数据科学家,还是大数据架构师,抑或是大数据产品经理,很显然这些公司都是把大数据产业发展作为自己的经营战略的重要组成部分来看待。

大数据人才的一将难求其实不奇怪,因为人才既然是市场的一部分,是一种特殊的“商品”,那就必然受到市场因素的调节,供需严重失衡才会有这样的现象。但是,为什么大数据人才会供需严重失衡呢?原因有以下两个。

(1)大数据产业发展迅速,很多公司都越来越意识到要将大数据作为自己公司经营战略不可或缺的一部分,就像销售、生产、公关这样的重要环节一样缺一不可。人才需求旺盛!

(2)大数据人才培养成本居高不下,培养周期长,成材率相对较低,这也是导致大数据人才缺乏的一个非常重要的原因。人才供应不足!

icon2

1.3.2 人才方向

从目前市场上的人才需求观点来看,大数据人才大致可以分为以下3个方向。

(1)偏重基建与架构的“大数据架构”方向。

(2)偏重建模与分析的“大数据分析”方向。

(3)偏重应用实现的“大数据开发”方向。

当然,也有理想主义者会认为能来个三合一的人才就更好了,但是知识宽度和知识深度本身就是一组矛盾,毕竟对于有限的学习时间和精力,能够在一方面做到运用自如已属不易。

1.大数据架构方向

大数据架构方向的人才更多注重的是Hadoop、Spark、Storm等大数据框架的实现原理、部署、调优和稳定性问题,以及它们与Flume、Kafka等数据流工具以及可视化工具的结合技巧,再有就是一些工具的商业应用问题,如Hive、Cassandra、HBase、PrestoDB等。能够将这些概念理解清楚,并能够用辩证的技术观点进行组合使用,达到软/硬件资源利用的最大化,服务提供的稳定化,这是大数据架构人才的目标。

以下是大数据架构方向研究的主要方面。

(1)架构理论:关键词有高并发、高可用、并行计算、MapReduce、Spark等。

(2)数据流应用:关键词有Flume、Fluentd、Kafka、ZMQ等。

(3)存储应用:关键词有HDFS、Ceph等。

(4)软件应用:关键词有Hive、HBase、Cassandra、PrestoDB等。

(5)可视化应用,关键词有HightCharts、ECharts、D3、HTML5、CSS3等。

大数据架构师除了最后可视化的部分不需要太过注意(但是要做基本的原理了解)以外,其他的架构理论层面、数据流层面、存储层面、软件应用层面等都需要做比较深入的理解和落地应用。尤其是需要至少由每一个层面中挑选一个可以完全纯熟应用的产品,然后组合成一个完整的应用场景,在访问强度、实现成本、功能应用层面都能满足需求,这是一个合格的大数据架构师必须完成的最低限要求。

2.大数据分析方向

大数据分析方向的人才更多注重的是数据指标的建立,数据的统计,数据之间的联系,数据的深度挖掘和机器学习,并利用探索性数据分析的方式得到更多的规律、知识,或者对未来事物预测和预判的手段。

以下是大数据分析方向研究的主要方面。

(1)数据库应用:关键词有RDBMS、NoSQL、MySQL、Hive、Cassandra等。

(2)数据加工:关键词有ETL、Python等。

(3)数据统计:关键词有统计、概率等。

(4)数据分析:关键词有数据建模、数据挖掘、机器学习、回归分析、聚类、分类、协同过滤等。

此外还有一个方面是业务知识。

其中,数据库应用、数据加工是通用的技术技巧或者工具性的能力,主要是为了帮助分析师调用或提取自己需要的数据,毕竟这些技巧的学习成本相对较低,而且在工作场景中不可或缺,而每次都求人去取数据很可能会消耗过多的时间成本。

数据统计、数据分析是分析师的重头戏,一般来说这两个部分是分析师的主业,要有比较好的数学素养或者思维方式,而且一般来说数学专业出身的人会有相当的优势。最后的业务知识方面就是千姿百态了,毕竟每家行业甚至每家公司的业务形态都是千差万别的,只有对这些业务形态和业务流程有了充分的理解才能对数据分析做到融会贯通,才有可能正确地建立模型和解读数据。

3.大数据开发方向

大数据开发方向的人才更多注重的是服务器端开发,数据库开发,呈现与可视化,人机交互等衔接数据载体和数据加工各个单元以及用户的功能落地与实现。

以下是大数据开发研究的主要方面。

(1)数据库开发:关键词有RDBMS、NoSQL、MySQL、Hive等。

(2)数据流工具开发:关键词有Flume、Heka、Fluentd、Kafka、ZMQ等。

(3)数据前端开发:关键词有HightCharts、ECharts、JavaScript、D3、HTML5、CSS3等。

(4)数据获取开发:关键词有爬虫、分词、自然语言学习、文本分类等。

可以注意到,大数据开发职种和大数据架构方向有很多关键词虽然是重合的,但是措辞不一样,一个是“应用”,一个是“开发”。区别在于,“应用”更多的是懂得这些这种技术能为人们提供什么功能,以及使用这种技术的优缺点,并擅长做取舍;“开发”更注重的是熟练掌握,快速实现。

最后一个方面——数据获取开发与前面的数据库开发、数据流工具开发、数据前端开发略有不同,它出现的时间相对较晚,应用面相对较窄。现在很多数据公司,如汤森路透、彭博等咨询公司的数据除了从专业行业公司直接得到以外,很多也是从互联网上爬取的,这个过程中也涉及一些关键技术。

icon2

1.3.3 环节和工具

前面提到过,大数据从数据的生命周期的传导和演变上可以分为这样几个部分:数据收集,数据存储,数据建模,数据分析,数据变现,如图1-1所示。

图1-1 数据生命周期中的环节

1.数据收集

完成数据收集是做大数据的第一步,这里请注意,数据的收集和平时在业务生产库上的做法不太一样,而是更像以前数据仓库里的收集方式。

方法一:快照法。可以每天、每周、每月用数据快照的方式把当前这一瞬间的某数据的状态复制下来放入相应的位置——这个位置就是大数据的数据中心所采用的数据容器,可以用Hive实现,也可以用Oracle或者其他专业的数据仓库软件实现。

方法二:可以使用一些工具来进行流式的数据导入,如TCP流或者HTTP长/短链接。

2.数据存储

数据存储的方式也是比较多样的,当数据收集进入数据中心时,可以考虑使用HDFS或者Ceph等开源并且低成本的方案,数据量较小的时候可以采用NAS直接mount到一台Linux服务器的某挂载点。比较推荐HDFS和Ceph主要是因为这两种框架在业界已经有了长时间的应用,社区活跃,方案成熟稳定,部署价格低廉且扩展性极好。

3.数据建模

数据建模是一个人为因素影响比较大的环节,我们这里提到的数据建模是指数理关系的梳理,并根据数据建立一定的数据计算方法和数据指标。一般来说,在一个比较成熟的行业里,数据指标相对是比较固定的,只要对业务有足够的了解是比较容易建立起运营数据模型的。使用人们熟悉的SQL语言就可以对存储容器中的数据进行筛选和洗涤,如果数据存储的容器是其他的异构容器,如HBase或者Mongodb等,就只能使用它们自己的操作Shell去操作了。

在这里需要提一句,有一个比较重要的环节是数据清洗。不同的业务习惯下,清洗有着不同的解释,但核心思想都是让数据中那些由于误传、漏传、叠传等原因产生的数据失真部分被摒弃在计算之外。此外,原始数据从非格式化变成格式化需要一个“整形”的过程,目的是让它能够和其他数据进行参照来运算,清洗同样涵盖这个“整形”的过程。也有人习惯把这个环节直接放在数据收集的部分一次性完成,究竟哪种方式比较好不能一概而论:在数据收集的时候就直接“整形”完毕,可能会使后面的数据存储、建模等环节处理起来成本更低一些,这是它的好处;但是在这个过程中会发生一部分数据裁剪的动作,而裁减掉的数据所蕴含的信息以后再想找回是不可能的。孰优孰劣还是因地制宜地进行讨论比较好。

4.数据分析

数据分析是这些环节里面一个比较重要的环节。“分析”两个字的含义可以包含两个方面的内容:一个是在数据之间尝试寻求因果关系或影响的逻辑;另一个是对数据的呈现做适当的解读。

这两个方面或许有重叠的部分,但是笔者认为这两个方面还是可以分开来理解的,前者偏重数据挖掘、试错与反复比对;后者偏重业务结合、行业情景带入等。但是两者都是货真价实的分析工作,这点毫无疑问。数据分析的工具在“市面”上有不少,有开源的,也有收费的,到现在其实没有特别好用的,大多使用的时候门槛较高而且使用习惯十分西方化。目前收费的软件里比较好的有IBM的SPSS、SAP的BW/BO,以及微软的SSAS和SSRS;开源的软件里有Mahout、Spark ML Lib、Python Pandas等。收费软件里通常会把挖掘分析和可视化结合得比较好,而开源软件里主要是封装的算法比较多,但是环节较为孤立,绘图的丰富程度和美观程度会大打折扣或者干脆没有,那么这个环节就需要使用者自己想办法了。

icon2

1.3.4 门槛障碍

大数据开发不是一个由大数据带来的新方向,它更多是迁移性地使用旧有技术,技术突破也比较有限,所以这里不做过多的介绍。

1.大数据架构方向

对于大数据架构方向,在资料方面虽然近两年涌现出很多翻译资料,也有很多国内高手写出不少实战心得,但是对于层出不穷的优秀开源框架来说,资料的更新多少显得有些跟不上脚步。这大概是自学成才的大数据架构师们很多不得不一边翻看着英文文档,一边翻看着源代码,一边试来试去的原因。而同时,越来越多的架构师们也将自己的心得写成越来越多的参考书籍,这些书籍的丰富也使大数据架构领域奋战的同行们有了更多的参考,有了更快进步的动力。

2.大数据分析方向

对于大数据分析方向,在淘宝或者京东上试着翻看一下,其实书籍比前者要缺乏得多。虽然有一些不错的数据挖掘与机器学习的书,也有一些关于Mahout、Spark ML Lib和文本挖掘、神经网络的书被摆上货架,但是笔者也经常听一些同行抱怨这类书有不少问题不尽如人意。英译中版本的书有不少翻译生涩、阅读困难,而且解析不够细致,默认读者已经掌握了大量的数理统计或概率学的知识;而Mahout之类开源数据挖掘项目的书籍,要么就是由官方文档翻译而来新意全无,要么就是由于成书较慢早已落后于当前的最新版本,所以让人读起来如吮鸡肋。

3.市场参与

在我看来,大数据行业目前不够繁荣的原因众多,但是究其根本就是因为它目前还不是一门“生意”,距离大量自由交易有价值的数据这一目标还相差太远。这种交易既存在于公司和组织之间,也存在于公司内部。现在去看身边最繁荣的市场,如大超市、大型网店,它们火爆的原因关键在于流量大、交易自由、交易成本低、交易参与方众多。大数据行业想要真正实现良性和快速发展,关键在于提高行业的市场化普及度。换句话说,大数据市场供需越丰富市场就越繁荣。而市场供需的繁荣靠的是参与方的丰富,以及交易内容的丰富。

那么支持参与方的不断丰富和交易内容不断丰富的源动力是什么呢?当然是人们经常说的去中心化和降低参与门槛。说到底,让尽可能多的人成为大数据行业中的价值制造者,这可能才是大数据行业进步的关键点所在。大数据产业中最有价值的层面在哪里?应该说,在数据收集、数据存储、数据建模、数据分析、数据变现这几个主要环节中,只有数据建模和数据分析这两个环节离数据变现,即创造价值更近;而数据收集和数据存储这两个环节做得再好也只是离节约成本更近,而对促进市场化普及的帮助较为间接。

因目前数据分析书籍的缺乏,阅读门槛的障碍,业内人士对知识的渴求,种种因素使我决心尝试着写一本门槛更低,更易理解,更“平民化”的数据挖掘与机器学习的书籍。