好吧，我猜很多从业者都以完成这些本可以通过自动化方式实现的工作为生。必须承认，我很庆幸自己已经渡过了基层工作时期，再也不用为这些琐事烦恼了。
大数据痛点五号: 分布式代码优化
我估计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等等。之所以面临这样的情况，是因为我们的原始数据往往处于混乱的状态。但真正令人惊讶的是，没有哪家厂商愿意拿出一套无缝化处理方案来。虽然解决这类问题没办法让你拿到诺贝尔奖，但却能够切实帮助到广大大数据技术用户。