侵权投诉
当前位置:

OFweek安防网

其它

正文

细数大数据技术领域的九大痛点

导读: 在面对大数据业务时,我可以列出九个长久以来一直令人头痛的问题,时至今日它们依然存在着并困扰着无数用户。

  尽管在Hadoop与NoSQL部署方面做足了准备,同样的问题仍然一次又一次反复出现。现在业界是时候尽快搞定这些麻烦事了。

  有时候一艘巨轮的侧方出现了破洞,但业界却决定坐等船体下沉、并把希望寄托在销售救生艇身上。

  也有些时候,这些问题似乎并没到要闹出人命的地步——类似我家里浴室的状况,只有往一边拧龙头才会出水。过一阵子我可能会找机会修理一下,但事实上这个问题已经存在了12年之久了。

  而在面对大数据业务时,我可以列出九个长久以来一直令人头痛的问题,时至今日它们依然存在着并困扰着无数用户。

  大数据痛点一号:GPU编程仍未得到普及

  CPU的使用成本仍然较为昂贵,至少与GPU相比要贵得多。如果我们能够面向GPU开发出更理想的执行标准以及更多表现出色的驱动程序,那么相信 一个新的市场将由此诞生。就目前来讲,GPU的使用成本优势并没能得到很好的体现,这是因为我们难以针对其进行编程,而且几乎没办法在不建立特定模型的前 提下完成这项任务。

  这种情况类似于,有些人希望编写出类似于ODBC或者JDBC的代码来处理某些高强度工作,并说服AMD或者英伟达将业务着眼点放在显卡产品之 外。假设我们原本已经习惯了使用Spark实现各类计算任务,而且压根不觉得这么做有什么问题; 但仿佛在一夜之间,其他人都开始构建所谓“GPGPU”集群,这自然会让我们有点措手不及之感。

  不少技术人员都开始在这方面做出探索,但要想真正让成果实现市场化,我们至少需要搞定两大竞争对手——AMD以及英伟达,也许再加上英特尔。除非它们愿意联手合作,否则如果继续像现在这样把技术保密看作市场成功的实现途径,那么问题永远也找不到理想的答案。

  大数据痛点二号: 多工作负载缩放

  我们拥有Docker。我们拥有Yarn。我们还拥有Spark、Tez、MapReduce以及未来可能出现的一系列技术方案。我们还拥有多种 资源池化实现工具,其中包含各类不同优先级及其它设定。如果大家选择部署一个Java war文件,则可以在PaaS上进行“自动伸缩”。但如果大家希望在Hadoop上实现同样的效果,那么情况就不太一样了。

  再有,存储与处理体系之间的交互该如何处理?有时候大家需要以临时性方式对存储资源进行扩展与分发。我应该有能力运行自己的“月末统计”批量任务 并将Docker镜像自动部署到任意指定位置。而在我的任务完成之后,系统应当对其进行反部署,并将资源重新分配给其它工作负载。应用程序或者工作负载应 该根本不需要在这方面浪费太多精力。

  但目前这些要求尚无法实现。我希望大家习惯了编写Chef方案与脚本,因为这是达到以上目标的惟一办法。

  大数据痛点三号: NoSQL部署更令人头痛

  为什么我已经能够利用ssh与sudo将镜像导入Linux设备、为其指定Ambari并安装像Hadoop这样复杂度极高的项目,但却仍然需要 在MongoDB以及大部分其它数据库的部署工作中浪费时间与精力?当然,我也可以编写Chef自动化方案,但恕我仍对此无法认同。

  大数据痛点四号:查询分析器/修复器

  当初在使用JBoss的时候,我曾经对Hibernate以及后来的JPA/EJB3进行过大量调试。具体来讲,主要工作包括查看日志记录、找出存在n+1类查询的位置、将其纳入join并移除可能影响运行效果的糟糕缓存配置。

1  2  下一页>  
声明: 本文由入驻维科号的作者撰写,观点仅代表作者本人,不代表OFweek立场。如有侵权或其他问题,请联系举报。

我来说两句

(共0条评论,0人参与)

请输入评论内容...

请输入评论/评论长度6~500个字

您提交的评论过于频繁,请输入验证码继续

暂无评论

暂无评论

文章纠错
x
*文字标题:
*纠错内容:
联系邮箱:
*验 证 码:

粤公网安备 44030502002758号