湖南省拾牛网络科技有限公司
  • 咨询热线:400-8116-098
在线QQ 返回顶部
  • 联系方式
  • 公司电话:0731-85208681
  • 公司地址: 长沙高新开发区青山路699号军民融合产业园8B栋17楼

你是否懂我的忧伤:八大痛点架空大数据
  • 来源: 来源网络      作者:拾牛网络      时间:2015-08-26
  •   父辈婚姻长久的比率高,老一辈人处理问题的态度是积极改进而不是抛弃不顾,这或许也是他们能够维持婚姻长久的原因之一。
    处理问题的态度除了积极应对、抛弃不顾当然还有一种态度是长久的隐忍,在问题发生后的很长一段时间后才进行处理。
    从婚姻联想到大数据,大数据运用同样存在很多问题,但很多专家抱着却置之不理的态度,听之任之。针对大数据运用上的问题我们应该正视。只有正视的态度方能换回解决的方案。
    面对大数据业务时,我们可以列出九个长久以来一直令人头痛的问题,时至今日它们依然存在着并困扰着无数用户。
    一号痛点:查询分析器/修复器
    我们可以将每一套需要的表添加到系统当中,但其返回速度却慢得让人抓狂。有时候,我们打算在复杂程度更高的系统之上查看 Oracle Enterprise Manager及其分析结果,但返回的报告却完全是一堆胡言乱语——这意味着其中存在问题。
    我们将大量精力投入到了糟糕或者复杂查询的优化当中,但除了开发者培训课程、我们似乎从来不会对这些查询本身提出质疑。这套系统似乎有种魔性,它同用户的关系类似于:“嘿,你发来了这些查询,我认为它们看起来应该像这样……”
    二号痛点:GPU编程仍未得到普及
    CPU的使用成本仍然较为昂贵,至少与GPU相比要贵得多。如果我们能够面向GPU开发出更理想的执行标准以及更多表现出色的驱动程序,那么相信一个新的市场将由此诞生。就目前来讲,GPU的使用成本优势并没能得到很好的体现,这是因为我们难以针对其进行编程,而且几乎没办法在不建立特定模型的前提下完成这项任务。
    不少技术人员都开始在这方面做出探索,但要想真正让成果实现市场化,我们至少需要搞定两大竞争对手——AMD以及英伟达,也许再加上英特尔。除非它们愿意联手合作,否则如果继续像现在这样把技术保密看作市场成功的实现途径,那么问题永远也找不到理想的答案。
    三号痛点:分布式名不副实
    我们得承认,对Hadoop的使用的第一印象就像在Hive当中输入select count(*) from somesmalltable。我觉得这种使用方式真的非常差劲。大家会发现其中存在问题,并意识到其分布效果并不理想。有些朋友甚至不必参考其它数据(例如行数)就能发现我们没办法实现负载分布。通常来讲,这些只是整体工作当中的一部分(例如查找表),但无论我们实际使用的是Hive、Spark、 HDFS还是YARN,其都会首先假设所有问题都已经得到切实分发。其中部分工作需要尽可能避免被分发,因为这样能使其运行速度更快。最让我受不了的就是用select * from thousandrowtable这样的操作拖慢MapReduce任务的运行速度。
    四号痛点: 多工作负载缩放
    我们拥有Docker。我们拥有Yarn。我们还拥有Spark、Tez、MapReduce以及未来可能出现的一系列技术方案。我们还拥有多种资源池化实现工具,其中包含各类不同优先级及其它设定。如果大家选择部署一个Java war文件,则可以在PaaS上进行“自动伸缩”。但如果大家希望在Hadoop上实现同样的效果,那么情况就不太一样了,因为在目前这些要求尚无法实现。我们智能寄希望大家习惯了编写Chef方案与脚本,因为这是达到以上目标的惟一办法。
    五号痛点:安全性
    首先,为什么我们只能通过Kerberos实现单点登录?云Web环境之下根本没有类似于Kerberos的方案可用。
    其次,厂商之间奇怪的竞争方式对Hadoop造成了极大的扭曲,而这对任何人都不是件好事。在涉及到基础性身份验证及授权层面时,我们不得不使用两套完全不同的堆栈,才能为Hadoop的全部组成部分提供安全性支持。加密方面的产品竞争我还可以理解(各类方案都在以更小、更快、更强为发展目标),但无论是选择Ranger、Sentry或者是其它什么方案,为什么我们就不能拥有一套足以涵盖全部Hadoop项目的验证机制?公平地讲,大数据领域目前的状况比NoSQL还要糟糕; 随便拉来一家宣称“我们热爱开源”的企业都能在自己“企业级”专用版本的LDAP集成部分当中塞进几百行开源代码。
    六号痛点: 分布式代码优化
    在编译器方面,大家可以编写优化器来检测循环内的非依赖性操作,同时自动对其进行提取与并行化调整。所谓“数据科学家”们编写出的Python代码相当垃圾,根本没办法有效进行问题分配,而且会造成大量不必要的内存浪费。在这种情况下,需要由技术从牛挺身而出,尝试理解前面那位“科学家”的想法并进行优化。
    问题在于,上述状况几乎跟大家在编译原理书里看到的反而实例一模一样。我猜随着技术的不断发展,未来Zeppelin甚至是Spark本身会站出来帮助大家修复糟糕的代码,并保证其与集群顺畅协作。
    七号痛点:机器学习映射
    在具体实例当中,我们都能轻松分清集群化问题、聚类问题或者其它一些归类工作。但似乎没人愿意解决真正有难度的部分——对业务体系中的常见部分进行映射、描述问题并通过描述映射找到应当使用的具体算法。
    除了金融行业之外,只有10%到30%的企业能够保持有不同于行业常规情况的特色——换言之,我们可以将销售、市场推广、库存、劳动力等因素映射至一套通用模型,而后描述出适合使用的算法。这项工作不仅会改变我们处理业务的方式,同时也能极大扩展市场的整体规模。我们可以将其视为一种面向大数据的设计模式,只不过其更多是在强调业务方面的内容。
    八号痛点:提取、转换与加载
    提取、转换与加载(简称ETL)可以说是每个大数据项目当中悄无声息的预算杀手。我们都很清楚自己到底需要利用大数据技术做些什么,但相较于将注意力集中在业务需求身上,现在我们首先得搞定Flume、Oozie、Pig、Sqoop以及Kettle等等。之所以面临这样的情况,是因为我们的原始数据往往处于混乱的状态。但真正令人惊讶的是,没有哪家厂商愿意拿出一套无缝化处理方案来。虽然解决这类问题没办法让你拿到诺贝尔奖,但却能够切实帮助到广大大数据技术用户。
        这些痛点我们避无可避,也是大数据本身无法落地的几大重要原因。这些痛点无法解决就无法改变大数据被架空,留着空洞的概念而无法落到实处的局面。 相关热词搜索:大数据时代数据空大数据分析海量信息