尽管在Hadoop与NoSQL部署方面做足了准备，同样的问题仍然一次又一次反复出现。现在业界是时候尽快搞定这些麻烦事了。
在面对大数据业务时，我可以列出九个长久以来一直令人头痛的问题，时至今日它们依然存在并困扰着无数用户。
痛点1 GPU编程仍未得到普及
CPU的使用成本仍然较为昂贵，至少与GPU相比要贵得多。如果我们能够面向GPU开发出更理想的执行标准以及更多表现出色的驱动程序，那么相信 一个新的市场将由此诞生。就目前来讲，GPU的使用成本优势并没能得到很好的体现，这是因为我们难以针对其进行编程，而且几乎没办法在不建立特定模型的前 提下完成这项任务。
这种情况类似于，有些人希望编写出类似于ODBC或者JDBC的代码来处理某些高强度工作，并说服AMD或者英伟达将业务着眼点放在显卡产品之 外。假设我们原本已经习惯了使用Spark实现各类计算任务，而且压根不觉得这么做有什么问题； 但仿佛在一夜之间，其他人都开始构建所谓“GPGPU”集群，这自然会让我们有点措手不及。
不少技术人员都开始在这方面做出探索，但要想真正让成果实现市场化，我们至少需要搞定两大竞争对手――AMD以及英伟达，也许再加上英特尔。除非它们愿意联手合作，否则如果继续像现在这样把技术保密看作市场成功的实现途径，那么问题永远也找不到理想的答案。
痛点2 多工作负载缩放
我们拥有Docker、Yarn、park、Tez、MapReduce以及未来可能出现的一系列技术方案。我们还拥有多种 资源池化实现工具，其中包含各类不同优先级及其它设定。如果大家选择部署一个Java war文件，则可以在PaaS上进行“自动伸缩”。但如果大家希望在Hadoop上实现同样的效果，那么情况就不太一样了。
再有，存储与处理体系之间的交互该如何处理？有时候大家需要以临时性方式对存储资源进行扩展与分发。我应该有能力运行自己的“月末统计”批量任务， 并将Docker镜像自动部署到任意指定位置。而在我的任务完成之后，系统应当对其进行反部署，并将资源重新分配给其它工作负载。应用程序或者工作负载应该根本不需要在这方面浪费太多精力。但目前这些要求尚无法实现。我希望大家习惯了编写Chef方案与脚本，因为这是达到以上目标的惟一办法。
痛点3 NoSQL部署更令人头痛
为什么我已经能够利用ssh与sudo将镜像导入Linux设备、为其指定Ambari并安装像Hadoop这样复杂度极高的项目，但却仍然需要在MongoDB以及大部分其它数据库的部署工作中浪费时间与精力？当然，我也可以编写Chef自动化方案，但恕我仍对此无法认同。
痛点4 查询分析器/修复器
当初在使用JBoss的时候，我曾经对Hibernate以及后来的JPA/EJB3进行过大量调试。具体来讲，主要工作包括查看日志记录、找出存在n+1类查询的位置、将其纳入join并移除可能影响运行效果的糟糕缓存配置。
但有时候情况又完全相反：我们可以将每一套需要的表添加到系统当中，但其返回速度却慢得让人抓狂。有时候，我打算在复杂程度更高的系统之上查看 Oracle Enterprise Manager及其分析结果，但返回的报告却完全是一堆胡言乱语――这意味着其中存在问题。不过我可以同时着眼于两套始终共同协作的表，并据此找到分析当中存在的规律。我甚至考虑过利用编程方式解决问题。
而现在，每次对NoSQL系统进行调整时，我都会发现上述问题以不同形式表现出来：要么是跳转次数太多、要么是查询太过复杂，有时候我们的索引无法与where子句相匹配。我们将大量精力投入到了糟糕或者复杂查询的优化当中，但除了开发者培训课程、我们似乎从来不会对这些 查询本身提出质疑。这套系统似乎有种魔性，它同用户的关系类似于：“嘿，你发来了这些查询，我认为它们看起来应该像这样……”
痛点5 分布式代码优化
我估计Spark当中的大量小功能及小设定会带来第四点里提到的各类问题。在编译器方面，大家可以编写优化器来检测循环内的非依赖性操作，同时自动对其进行提取与并行化调整。我在分布式计算领域经常会见到这类情况。所谓“数据科学家”们编写出的Python代码相当垃圾，根本没办法有效进行问题分配，而且会造成大量不必要的内存浪费。在这种情况下，需要由技术从牛挺身而出，尝试理解前面那位“科学家”的想法并进行优化。
问题在于，上述状况几乎跟大家在编译原理书里看到的反而实例一模一样。我猜随着技术的不断发展，未来Zeppelin甚至是Spark本身会站出来帮助大家修复糟糕的代码，并保证其与集群顺畅协作。
痛点6 分布式名不副实
我得承认，我对Hadoop的第一印象就是在Hive当中输入select count * from somesmalltable。我觉得这种使用方式真的非常差劲。大家会发现其中存在问题，并意识到其分布效果并不理想。有些朋友甚至不必参考其它数据 （例如行数）就能发现我们没办法实现负载分布。
通常来讲，这些只是整体工作当中的一部分，但无论我们实际使用的是Hive、Spark、 HDFS还是YARN，其都会首先假设所有问题都已经得到切实分发。
其中部分工作需要尽可能避免被分发，因为这样能使其运行速度更快。最让我受不了的就是用select * from thousandrowtable这样的操作拖慢MapReduce任务的运行速度。
痛点7 机器学习映射
在具体实例当中，我们都能轻松分清集群化问题、聚类问题或者其它一些归类工作。但似乎没人愿意解决真正有难度的部分――对业务体系中的常见部分进行映射、描述问题并通过描述映射找到应当使用的具体算法。
除了金融行业之外，只有10%到30%的企业能够保持有不同于行业常规情况的特色。这项工作不仅会改变我们处理业务的方式，同时也能极大扩展市场的整体规模。我们可以将其视为一种面向大数据的 设计模式，只不过其更多是在强调业务方面的内容。
痛点8 安全性
首先，为什么我们只能通过Kerberos实现单点登录？云Web环境之下根本没有类似于Kerberos的方案可用。
其次，厂商之间奇怪的竞争方式对Hadoop造成了极大的扭曲，而这对任何人都不是件好事。在涉及到基础性身份验证及授权层面时，我们不得不使用 两套完全不同的堆栈，才能为Hadoop的全部组成部分提供安全性支持。加密方面的产品竞争我还可以理解， 但无论是选择Ranger、Sentry或者是其它什么方案，为什么我们就不能拥有一套足以涵盖全部Hadoop项目的验证机制？公平地讲，大数据领域目 前的状况比NoSQL还要糟糕； 随便拉来一家宣称“我们热爱开源”的企业都能在自己“企业级”专用版本的LDAP集成部分当中塞进几百行开源代码。
痛点9 提取、转换与加载
提取、转换与加载（简称ETL）可以说是每个大数据项目当中悄无声息的预算杀手。我们都很清楚自己到底需要利用大数据技术做些什么，但相较于将注意力集中在业务需求身上，现在我们首先得搞定Flume、Oozie、Pig、Sqoop以及Kettle等等。之所以面临这样的情况，是因为我们的原始 数据往往处于混乱的状态。但真正令人惊讶的是，没有哪家厂商愿意拿出一套无缝化处理方案来。虽然解决这类问题没办法让你拿到诺贝尔奖，但却能够切实帮助到 广大大数据技术用户。
