大数据厂商鱼龙混杂 企业选择切勿陷入迷思

现今不管从网络或媒体,用户皆不难看到一缸子能扯得上”大数据”的解决方案,有的被归类在Log数据应用、商业智能、分析及可视化等范畴,有的专注发展数据分析、数据管理等基础架构,也有来自开原码阵营的HadoopMapReduceHBaseMahout或Cassandra等技术方案,让人看得目不暇给,一时之间真不知该如何做出正确抉择。

只因Big Data实在太过火热,眼见机不可失,许多来自四面八方的信息系统供货商,都纷纷齐聚这个饶富潜力的新战场,从各自擅长的角度,推出不同功能取向的产品,极力争取成为客户端大数据平台的一环。

大数据分析

虽然选项众多,看似对用户十分有利,但不可否认,大数据仍算一门极为新颖、又有些抽象的技术,真能将其Landscape搞得一清二楚的企业,其实并不算多,即使能弄懂这整个构图,对于单一领域所存在的眉眉角角,也未必能通盘了解;于是在这个略显浑沌不明的偌大场域中,滋生了若干陷阱或迷思,亟需加以厘清。

中小企业难入Big Data之门?
第一道迷思,由于大数据产品要价偏高、技术偏难,且几乎所有研讨会的诉求对象,听起来都一面倒倾向中大型企业,合理推测,中小企业似乎不适合导入此项技术,况且也未必有殷切需求(因无TB等级庞大数据需要处理)。

然而,这真的是一番误解。首先,中小企业也需要做营运管理,也需运用批处理方式产出报表,而其所面对的市场竞争压力,也不会比大企业来得小,所以先撇开大数据的Volume或Variety不谈,光是在于Velocity方面,即可因为善用大数据技术而受用无穷,让原本得耗时数天处理的工作,急缩到半天内完成,何乐而不为?

其次,有些MPP(Massively Parallel Processing)数据库被包裹成Appliance型式提供,里头集结了不少节点,的确逾越中小企业的数据胃纳需求,但并非所有产品个个如此,有的甚至可在单一实体或虚拟主机环境中运转,中小企业可朝着这类型产品做思考;否则,现阶段有一些关于大数据主题的IaaS云端服务,例如Amazon Web Services或微软Windows Azure,也俾使中小企业能以低廉租赁费用,换取可观运算资源,亦是不错的选项。

开原码vs.商用系统,哪个好?
Hadoop挟着擅长于分散平行运算的特质,因而掀起阵阵旋风,但凡事讲求稳健的企业,一方面对于Hadoop这类型开放原始码技术颇感疑虑,二方面也对于Hadoop略显缓慢的查询速度不敢恭维,但如果把分散平行运算工交由纯商用系统来进行,又得负担庞大财务支出,没几个企业有福消受。

两难之间如何抉择?最好的方式,就是把它们混在一起,取Hadoop之于分散平行运算的优点,又因商用系统(例如MPP数据库)而得以满足实时查询需求,实为相得益彰的解决之道。

但是必须切记,有些商用系统,未必能与Hadoop家族的一干徒子徒孙做整合,值此时刻,企业要嘛以Hardcode方式”蛮干”,但容易导致数据平台的底层架构趋于紊乱,日后恐有后遗症产生,要嘛就是另行购置ETL工具,徒增一笔不算低廉的开销,都有其不利因素存在;所以最好的方式,就是利用POC严加测试,凡是整合出现问题的,就只好予以剔除。

然而如果可接受以Hardcode或ETL等方式进行整合,则后者是相对理想的选项。有人曾说,运用Hadoop即可取代ETL功能,但此话其实只说对了3分之1,因为ETL三个字代表Extract-Transform-Load的缩写,主要用以描述将数据从来源端,经过萃取、转换、加载至目的端之过程,Hadoop充其量只具备强大的”Load”功能,对于E或T则并不拿手,所以才这么容易在异质系统整合过程中碰壁,但ETL则无此顾虑。

既有的BI投资,如何处理?
不少人误以为,大数据解决方案与现存的BI系统,两者之间一定有互斥关系,有了新的,就得淘汰旧的,但这实在是天大的谬思。

可以这么形容,一只翩翩飞舞的彩蝶,一定得靠头、身体、翅膀同时存在,才会展现生命力,而Hadoop MapReduce、MPP数据库(或In-Memory数据库)、OLAP、报表系统、数据探勘、企业绩效管理(EPM)等新旧工具之间,全都是构筑这个生命力的重要元素,任何环节都有其存在价值,根本无所谓相互取代的关系,而且这些环节之间,都肯定存在数据交换的需求;甚至是只能处理传统结构式数据的关系数据库,都不该因此而遭舍弃。

主因在于,有些沿用许久的应用软件,不见得依平行架构进行系统设计,所以某些应用场景,在关系数据库得以运行顺畅,到了平行数据库,反倒步履蹒跚;因此应该针对何等用途采用大数据技术,需要审慎考虑,避免用一竿子打翻整艘船。

唯一较有取代意味的场景,会出现在低效率的旧式数据仓储,即将被转为高效率的新式平行数据库;不过这是一个颇为浩大的工程,用户在进行评估测试的过程中,务必需要有严格的把关程序,以及正确的测试题目,才能如愿享受到转换效益。

导入大数据,方知带宽资源困窘?
若干企业在部署大数据解决方案,才惊觉既有的企业网络资源,根本不敷所需,导致塞车现象时有所闻。

为何如此?可能的原因之一,平行运算架构多为Master-Node模式,好比一个首脑率取一群士兵(即大批运算节点),如果不做高可用性(HA)部署情况倒还好,一旦施作了HA,所有事情都得等到”两个首脑”做完同步再说,岂有不拖慢网络效能之理?

可能的原因之二,虽然大家都强调支持数据压缩,但部分产品要等到把数据处理完,才执行压缩程序,下回用户想调出这个处理结果,又重新解开压缩,假使档案过大,访问速度自然快不起来。

可能的原因之三,也是最棘手的状况,有些Big Data Appliance系以一个个整柜方式输出,在相同机柜内的不同节点,彼此交换数据,只需1 Gigabit速率便绰绰有余,但只要跨柜做交换,带宽需求立即爆涨到10 Gigabit、甚至InfiniBand,值此时刻,倘若客户端原本的核心交换器规格不够高,可想而知当然会出现网络壅塞现象。

很简单的道理,底下的不同机柜或服务器之间,都已经10 Gigabit来、10 Gigabit去,位居制高点的核心交换器,若还不到10 Gigabit速率,怎能不失控?但对多数用户而言,只因导入Big Data Appliance,居然得将网络骨干进行升速,实在兹事体大,早知如此,肯定不会轻易导入,但不幸的是,在部署过程中,不管是原厂或经销商,怎么都没人做出善意提醒?

为了避免这3个可能性发生,用户在挑选产品的过程中,自然需要睁大眼睛。首先,既然要做HA,就得将此列为POC重要考题,不容厂商和稀泥蒙混过去,毕竟不是所有平行运算架构都走Master-Node路线,就算是,也未必个个都会造成如此大影响;其次,大家都标榜压缩,有的做足了全套,有的却只做半套,用户务必需要看得清楚分明,而真正做到全程压缩者,吞吐需求自然较小,较不会造成网络壅塞;再者,在导入任何产品的同时,谨记得要再三确认其对于网络拓朴的影响性。

移动信息化交流QQ群:一号群:211029692 二号群:344692795 CIO交流群:316076815(需认证)

移动化问答社区:wenda.yidonghua.com



1 星2 星3 星4 星5 星 (还没有打分,快来打分吧!)
Loading...
 
已有 0 条评论
返回顶部

无觅相关文章插件,快速提升流量