阻碍大数据发展的九大痛处（我的角度）

前言

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

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

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

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

分享以前我仍是要推荐下我本身建立的大数据学习交流Qun531629188

不管是大牛仍是想转行想学习的大学生

小编我都挺欢迎，今天的已经资讯上传到群文件，不按期分享干货，

包括我本身整理的一份最新的适合2018年学习的大数据教程，欢迎初学和进阶中的小伙伴。

大数据痛点一号：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并移除可能影响运行效果的糟糕缓存配置。

但有时候状况又彻底相反：咱们能够将每一套须要的表添加到系统当中，但其返回速度却慢得让人抓狂。有时候，我打算在复杂程度更高的系统之上查看Oracle Enterprise Manager及其分析结果，但返回的报告却彻底是一堆胡言乱语——这意味着其中存在问题。不过我能够同时着眼于两套始终共同协做的表，并据此找到分析当中存在的规律。我甚至考虑过利用编程方式解决问题。

而如今，每次对NoSQL系统进行调整时，我都会发现上述问题以不一样形式表现出来：要么是跳转次数太多、要么是查询太过复杂，有时候咱们的索引没法与where子句（即范围合并）相匹配。简而言之，咱们将大量精力投入到了糟糕或者复杂查询的优化当中，但除了开发者培训课程、咱们彷佛历来不会对这些查询自己提出质疑。这套系统彷佛有种魔性，它同用户的关系相似于：“嘿，你发来了这些查询，我认为它们看起来应该像这样……”

好吧，我猜不少从业者都以完成这些本能够经过自动化方式实现的工做为生。必须认可，我很庆幸本身已经渡过了基层工做时期，不再用为这些杂事烦恼了。

大数据痛点五号: 分布式代码优化

我估计Spark当中的大量小功能及小设定会带来第四点里提到的各种问题。在编译器方面，你们能够编写优化器来检测循环内的非依赖性操做，同时自动对其进行提取与并行化调整。我在分布式计算领域常常会见到这类状况。所谓“数据科学家”们编写出的Python代码至关垃圾，根本没办法有效进行问题分配，并且会形成大量没必要要的内存浪费。在这种状况下，须要由技术从牛自告奋勇，尝试理解前面那位“科学家”的想法并进行优化。

问题在于，上述情况几乎跟你们在编译原理书里看到的反而实例如出一辙。我猜随着技术的不断发展，将来Zeppelin甚至是Spark自己会站出来帮助你们修复糟糕的代码，并保证其与集群顺畅协做。

大数据痛点六号：分布式名存实亡

我得认可，我对Hadoop的第一印象就是在Hive当中输入select count(*) from somesmalltable。我以为这种使用方式真的很是差劲。你们会发现其中存在问题，并意识到其分布效果并不理想。有些朋友甚至没必要参考其它数据（例如行数）就能发现咱们没办法实现负载分布。一般来说，这些只是总体工做当中的一部分（例如查找表），但不管咱们实际使用的是Hive、Spark、HDFS仍是YARN，其都会首先假设全部问题都已经获得切实分发。其中部分工做须要尽量避免被分发，由于这样能使其运行速度更快。最让我受不了的就是用select * from thousandrowtable这样的操做拖慢MapReduce任务的运行速度。

大数据痛点七号：机器学习映射

在具体实例当中，咱们都能轻松分清集群化问题、聚类问题或者其它一些归类工做。但彷佛没人愿意解决真正有难度的部分——对业务体系中的常见部分进行映射、描述问题并经过描述映射找到应当使用的具体算法。

除了金融行业以外，只有10%到30%的企业可以保持有不一样于行业常规状况的特点——换言之，咱们能够将销售、市场推广、库存、劳动力等因素映射至一套通用模型，然后描述出适合使用的算法。这项工做不只会改变咱们处理业务的方式，同时也能极大扩展市场的总体规模。咱们能够将其视为一种面向大数据的设计模式，只不过其更可能是在强调业务方面的内容。

大数据痛点八号：安全性

首先，为何咱们只能经过Kerberos实现单点登陆？云Web环境之下根本没有相似于Kerberos的方案可用。

其次，厂商之间奇怪的竞争方式对Hadoop形成了极大的扭曲，而这对任何人都不是件好事。在涉及到基础性身份验证及受权层面时，咱们不得不使用两套彻底不一样的堆栈，才能为Hadoop的所有组成部分提供安全性支持。加密方面的产品竞争我还能够理解（各种方案都在以更小、更快、更强为发展目标），但不管是选择Ranger、Sentry或者是其它什么方案，为何咱们就不能拥有一套足以涵盖所有Hadoop项目的验证机制？公平地讲，大数据领域目前的情况比NoSQL还要糟糕; 随便拉来一家宣称“咱们热爱开源”的企业都能在本身“企业级”专用版本的LDAP集成部分当中塞进几百行开源代码。

大数据痛点九号：提取、转换与加载

提取、转换与加载（简称ETL）能够说是每一个大数据项目当中悄无声息的预算杀手。咱们都很清楚本身到底须要利用大数据技术作些什么，但相较于将注意力集中在业务需求身上，如今咱们首先得搞定Flume、Oozie、Pig、Sqoop以及Kettle等等。之因此面临这样的状况，是由于咱们的原始数据每每处于混乱的状态。但真正使人惊讶的是，没有哪家厂商愿意拿出一套无缝化处理方案来。虽然解决这类问题没办法让你拿到诺贝尔奖，但却可以切实帮助到广大大数据技术用户。