【热点】Hadoop已死,后Hadoop时代的数据战略
从去年开始,网上对Hadoop的消极评论铺天盖地。这股思潮的导火索源自2018年10月全球两大数据服务商Cloudera与Hortonworks的合并。行业巨头在那个冬天选择抱团取暖,意味着一个新的垄断巨头的出现的同时,也表明某种模式下市场竞争的告一段落。 Hadoop市场的萎缩从其始创者Google的搜索趋势分析就可见一斑,从2015年开始Apache Hadoop的Google搜索量就开始明显下滑,到今天只有甚至不如巅峰时期的一半。
而从地域来看,去年搜索量还高居首位的中国先后被印度、新加坡和韩国赶超,位列第四。
中国的趋势下滑其实挺好理解,首先是本地大数据市场的萎缩,随着各种公有云服务商相继推出大数据产品以及配套的服务体系的成熟,加上IPV6, SDWAN,5G网络技术的发展,越来越多的企业将无法承载的大数据直接交由云服务商代理。举例来说阿里飞天系统以及MaxCompute的推出,予力企业以处理大数据高并发的能力;其次是本地Hadoop大数据平台的没落,Hadoop始终无法解决多节点写入的问题,以及写入实时性的问题。随着MongoDB和ElasticSearch生态系统的成熟,更加高效的大数据处理平台逐渐取代了Hadoop的位置。国外有MoogSoft,国内有擎创、日志易等产品化的ELK体系,Hadoop越来越沦为这些数据的归档系统。 相较Hadoop的没落,企业对MongoDB与ElasticSearch的兴趣在近两年显现突飞猛进趋势。
然而,即便与Hortonworks合并,依然没有改变Cloudera的命运,在经历了短暂井喷效应后,今年开始的股价一路下跌至历史最低点。
不久前Cloudera宣布2020财年的第一季度损失了1.03亿,之后其CEO和联合创始人兼首席战略官相继辞职,表达了对目前现状的无能为力。 同样作为之前紧随其后的MapR,虽然由于前两强的合并蹿升到了第二的位置,也在精兵减员,缩小规模,甚至在去年五月份传出了要关门(Shut down)的消息。
随着大数据时代走到尽头,我们现在可以少关注收集大量数据的机制,多关注处理、分析海量数据并与之实时交互方面的无数挑战。我们迈入大数据驱动的新时代时,请牢记以下几个概念。 **首先,Hadoop在企业数据界仍占有一席之地。**据外媒预计,MapR最终会被一家以管理IT软件出名的公司收购,比如BMC、冠群或MicroFocus;并认为Cloudera已采取了措施,不仅限于企业Hadoop,以支持数据的下几个时代。但技术的步伐不可阻挡,Cloudera的问题在于它的行动是否够快、随势而变。Cloudera在将其企业数据平台完善成下一代洞察力和机器学习平台方面面临数字化转型挑战。过去几十年,公司能够为转型敲定时间表。现在正如我们从亚马逊、Facebook和微软等公司看到的那样,仅仅为了活命,成功的科技公司必须准备好每十年就要转型,可能甚至牺牲掉自己的部分业务。 **其次,对多云分析和数据可视化的需求比以往任何时候都要大。**谷歌和Salesforce刚斥资180亿美元收购了Looker和Tableau,那些收购基本上是针对颇具规模和收入增长的公司的市场价值收购。会投入更多的巨额资金,以克服这一挑战:针对众多数据源提供分析技术,并支持与多云有关的日益分散且多样的存储、计算和集成需求。这意味着企业需要慎重地搞清楚数据集成、数据建模、分析及/或机器学习/数据科学团队可以在多大程度上应对这个挑战,因为处理和分析异构数据变得越来越困难、复杂,但要支持战略业务需求并将数据用作真正的战略优势又势必需要这么做。而仅看国内发展,企业对多云分析和数据可视化的需求也是一样剧增。2006年成立的国产BI软件厂商帆软软件自2016年300人左右的团队短短三年内成长到现在的1100余人,据知为了应对更多的市场需求其团队还在不断扩大。这样的成长速度源自市场需求的增多和帆软对于市场需求走势的判断。 第三,机器学习和数据科学是下一代分析技术,需要各自做好新的数据管理工作。大规模创建测试数据、合成数据和掩蔽数据,以及数据沿袭、治理、参数和超参数定义以及算法假设,这些都超出了传统大数据假设的范畴。这里最重要的考量因素是,使用由于种种原因未能很好地服务于企业的数据:样本量小、缺乏数据源、数据定义不清晰、数据上下文不明确,或者算法和分类假设不准确。换句话说,不使用失实的数据。失实的数据会导致有偏见、不合规、不准确的结果,还可能导致诸多问题:比如Nick Leeson在1995年导致巴林银行(BaringsBank)垮台,或法国兴业银行因Jerome Kerviel精心操纵交易而蒙受70亿美元的交易损失。AI现在是新的潜在“流氓交易者”,需要得到适当的治理、管理和支持。 **第四,需要将实时和无处不在的上下文既视为协作和技术上的挑战,又视为数据挑战。**我们正进入这样一个世界:每个对象、流程和对话都可以用附加的上下文加以标记、标注或增强,可以实时处理数GB的数据,以生成简单的两个单词警报,可能就像“减慢速度”或“立即购买”这么简单。我们看到“数字孪生”(digital twin)这个概念方兴未艾:在工业界,PTC、GE及其他产品生命周期和制造公司为设备创建数字孪生;而在销售界,Gong、Tact和Voicera等公司借助额外的上下文以数字方式记录、分析和增强模拟对话。 关于国内对大数据行业发展的讨论也是一直没有停止,而对于实时、增强和交互型的数据分析,对在大行业背景下小行业的场景化应用,帆软每年都会组织国内数据行业规格最高的一场听觉盛宴,近千家企业高管参与讨论。针对数据治理和准备、数据挖掘、数据人才培养等多个部分进行深度探讨。本次大会以“数据有引力”为主题,以国内现在的大行业发展为背景,真正来落地数据对企业的真实价值,旨在帮助更多的企业对“已死的大数据”重新认识,从以上四个方面来使得数据建设更加落地。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
云服务器为什么淘汰了传统服务器
阿里云ECS云服务器如何选择?可以根据应用场景来选择云服务器规格及配置,新手站长网分享业务场景选择ECS云服务器实例对照表: 根据应用场景选择ECS云服务器实例 阿里云ECS云服务器有多种实例规格,不同ECS实例规格适用于不同的应用场景,例如:GPU云服务器适用于AI深度学习或图形可视化等业务场景,新手站长网分享业务场景和ECS实例规格对照表: ECS实例规格族 实例规格 业务场景 通用计算型 通用型g6/通用型g5/通用网络增强型sn2ne 中小型数据库/数据处理任务/企业后台应用 通用计算型 计算型c6/计算型c5/计算网络增强型sn1ne 高性能网站前端节点/Web服务器,批量计算/分布式分析,对战类游戏/高性能科学,工程类应用/平台广告,视频编解码 通用计算型 内存型r6/内存型r5/内存增强型re4/内存网络增强型se1ne/内存型se1 高性能数据库/数据挖掘和分析/Redis、Memcached等缓存/内存型数据库 通用计算型 高主频hfc6/高主频hfc5/高主频hfg5/高主频c4 高性能科学计算/高性能前端节点 通用计算型 本地SSD型i2/本地SSD型i2g/本地...
- 下一篇
【观察】常用的流式框架(一)-- Storm与Samza
相较数据处理的两大阵营,批量处理(Batch)和流式处理(Stream):批量处理比较经济,且只对全量数据进行处理;但数据延时较大,因为只有跑批之后数据才提供给应用系统。 流式处理延时小,但由于24小时运作,因此不许有宕机时间,并且由于只处理增量数据,所以难免会遗漏部分数据的处理。 在两相权宜之下,演化出了以下两种混合架构: Lambda架构:有流式处理以提供低延时的数据访问,同时定期跑批以覆盖流式处理中可能带来的不完整的数据。但这会造成企业中有两套代码库。 Kappa架构:在原有流式处理的管道中加入数据保留(Retention)以减小数据未处理的风险,但这就约束了使用者只能在处理中加入增量算法,不然无法识别新旧数据。 流式处理可以集成一些简单的算法,他们体量很小在完成算法的同时又不会影响到数据的实时性,例如: 数据的过滤与转换; 数据的分类; 简单的数学计算(求和、计数、求平均等)及逻辑运算 滑动窗口大小设定(比如只对过去5分钟的数据做运算等) Twitter有业界知名的流式处理框架(从Yahoo学来的),它需要定期汇报给客户广告投放的效果,怎么做呢?首先从Kafka中提取广告跟踪的...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS8编译安装MySQL8.0.19
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- SpringBoot2整合Redis,开启缓存,提高访问速度
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- Hadoop3单机部署,实现最简伪集群
- CentOS7,CentOS8安装Elasticsearch6.8.6
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果