50万年薪都招不来的大数据开发工程师是什么样的?
从2010年至今,大数据投资热潮与大数据岗位开始集中爆发。从360指数我们可以看出,目前大数据在市场的热度远远高于前几年特别火的产品经理。
大数据之火热,以致身边很多人对于大数据相关热门趋势及词汇都能随口就来。但如果问他大数据和他之间的关系,却很难能说出一二三来。
究其原因,大家置身于大数据环境下,耳濡目染各种新的概念,但是真正参与实践大数据的案例少之又少,造成了对大数据整体认知的缺失。
下面讲讲大数据行业不同角色对大数据的观点,希望能够还原出来一个较为全面的认识,了解不同角色对大数据的需求背景。
大数据开发
2010开始,大数据成为了分布式技术框架的别名,Hadoop开始频繁进入大家眼中,从此以后,hive,spark,flink等分布式计算框架如雨后春笋进入大家的开发工作环境中(当然大数据的薪资也开始水涨船高,远远高于其他同类开发)。
那么在大数据开发的眼中,大数据应该是长这样的:
-
第一:数据体量巨大。大数据的起始计量单位至少是P(1000个T)、E(100万个T)或Z(10亿个T);
-
第二:数据类型繁多。比如,网络日志、视频、图片、地理位置信息等等;
-
第三:需要不同的框架解决不同的问题。
在大数据开发眼里,大数据是一堆框架的集合。
数据分析及算法工程师
随着大数据技术的发展,传统基于关系型数据库的BI底层逐步被大数据替代。
数据采集全面进入线上化,公司开始全量采集线上数据,全量存储用户行为数据作为分析数据源。传统的基于抽样的统计方式逐步被全量统计方式替换,原有技术框架支持不了的用户行为分析也逐步成为大数据分析场景的标准流程,基于单机的数据挖掘算法逐步被替换成分布式的机器学习和深度学习替代。
在分析师和算法工程师眼里,数据又表现为如下几个方面:
-
第一:数据记录全面,能够分析的场景越来越多;
-
第二:数据价值密度很低、挖掘难度变大;
-
第三:单机无法解决,需要借助大数据相关工具。
在他们眼里,大数据意味着更多的场景可以被分析量化。
数据产品经理
随着工具及算法的逐步完成,基于大数据做到千人千面的推送及定价方案已经成为可能。
有一个非常经典的案例:为提高在主营产品上的赢利,亚马逊在2000年9月中旬开始了著名的差别定价实验。
亚马逊选择了68种DVD碟片进行动态定价试验,试验当中,亚马逊根据潜在客户的人口统计资料、在亚马逊的购物历史、上网行为以及上网使用的软件系统确定对这68种碟片的报价水平。例如,名为《泰特斯》(Titus)的碟片对新顾客的报价为22.74美元,而对那些对该碟片表现出兴趣的老顾客的报价则为26.24美元。
通过这一定价策略,亚马逊提高了销售的毛利率。在此我们不考虑这个定价策略是否妥当,但是大数据技术的确已经验证可以为企业带来更多的收益。
在产品经理眼里,我们发现了另外一种大数据的看法:
大数据意味着更好的产品优化及产品收益已经成为可能,至于具体的技术细节和算法,并不是他们关注的点。
当然,除了如上三个岗位,其实还有很多大数据相关的配套岗位,他们对大数据亦有各自的理解。
但是如果作为一个企业落地大数据项目,我们唯一需要综合考虑的是如何在最低投入的情况下,保证长期与短期效益的均衡,举个例子来说:
1、 如果过分重于技术,会导致技术费用投入过大, 成本急剧放大
2、 如果过分重于分析,缺乏有效产品整合的话,可能牺牲长期效应
3、 过分重于产品的话,投入较长的时间产品化,可能牺牲短期收益
为了平衡三个岗位偏差造成的需求差异,大数据架构师、数据科学家相关岗位应运而生。
与传统商业智能领域类似,大数据架构师及数据科学家需要解决的核心问题还是如何构建一套稳定高效的大数据技术组件下的数据仓库。
我从落地的多个企业级大数据项目总结出,设计一个高效可靠的数据仓库会成为一个企业大数据项目成败的最关键因素,为什么这么说呢?
我们邀请了网易资深大数据开发工程师-王潘安,给大家诠释大数据仓库的重要性,介绍构建企业级数据体系的标准化流程。帮助大家在学习大数据的道路上有迹可循,形成体系化的思维。避免陷入大量的大数据工具和框架中无法自拔。
本文作者:大数据前沿
本文来自云栖社区合作伙伴“大数据前沿”,了解相关信息可以关注“大数据前沿”
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
DevOps组件高可用的思路
引言: 以往部署的应用或服务基本都是自成体系不会被其他影响。而在DevOps下这种部署方式也正在发生改变。因为应用或服务本身所涉及的组件越来越多。DevOps串联着应用或服务以及应用和服务所涉及的组件,以保证所有应用和服务的正常运行。 目录: 一、传统高可用 二、DevOps 简述 三、传统高可用架构模式 四、DevOps 带来的改变 一、传统高可用 传统生产模式下,如应用、中间件以及数据库等服务都需要有高可用。以避免业务服务出现宕机的问题。 常见的部署方法,有服务主备、服务集群,还有两地三中心的高可用方案。 高可用常见的指标,以及服务宕机时间。 https://en.wikipedia.org/wiki/Mean_time_between_failures MTBF = MTTF + MTTR 365*24*(1-0.99)=87.6,在实际情况下当然故障时间越短越好 系统可用性比率 = MTTF/MTBF 二、DevOps简述 1、DevOps带来的变化就是整个部署过程是自动化的、部署的周期变短了。开发和运维所关注的焦点也发生了变化。开发人员从提交代码,到看到本次修改的内容可以在很...
- 下一篇
架构设计之「数据库集群方案」
在之前的文章中,我们知道数据库服务可能已经成为了很多系统的性能关键点,甚至是瓶颈了。也给大家介绍了数据库服务器从主备架构、到主从架构、再到主主架构的基础方案。但如果单台机器已经不能满足完整业务数据存储的时候,我们就需要考虑采用多机甚至多中心的部署方案了。 今天我们就再来聊一聊,在多机环境下,数据库集群的架构方案。 同样,这里先不看细节,不管底层数据源是什么数据库,我们先谈架构方案。因为无论底层是 Mysql 还是 Redis、MongoDB,我们在架构设计上都是相通的。 针对多机的架构,常见有如下做法: 单中心数据集群 多中心数据分区 下面我们来具体看看: 一、单中心的数据集群架构(单中心多机) 单数据中心多机器的集群又可以分为: 数据集中模式 数据分散模式 这两种的主要区别在于集群中的完整业务数据是全部集中在一台机器上,但是分散在多台机器上。 数据集中模式 如图, 这种模式与「一主一从式」(主从式)比较类似,完整的业务数据还是存储在一台主机的上,主机承担读服务和写服务,从机只承担读服务。但是从机有多台机器,从机实时的从主机同步数据。所以这种模式,也可以理解为「一主多从」式。 因为有多...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- CentOS8编译安装MySQL8.0.19
- MySQL8.0.19开启GTID主从同步CentOS8
- SpringBoot2全家桶,快速入门学习开发网站教程
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- CentOS7,CentOS8安装Elasticsearch6.8.6
- Red5直播服务器,属于Java语言的直播服务器
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- CentOS6,CentOS7官方镜像安装Oracle11G