9个大数据 pain-points

大数据痛点 No.1：通用GPU编程

CPU仍然是比较昂贵的产品，至少相对GPU而言是这样的。如果能更好的理解GPU、为GPU开发的驱动不再那么晦涩难懂，整个市场将会被打开。现在的一个事实是：GPU消耗更小，这足以平衡对它编程很困难、甚至不使用特定的模型都无法编程的缺点。

这是某种情况下，有人在辛苦地写一些看起来像ODBC或JDBC的东西，以使AMD或Nvidia觉得这个市场比独立图形显卡市场更大。假设你拥有一个Spark的通用绑定，你不必考虑真正的硬件，有一天，人们会开始构建“GPGPU” 集群。

人们已经开始着手这方面的工作了。但如果要获得持续的市场，你至少需要两个无情的竞争对手–AMD和Nvidia，说不定Intel也是——来一起合作，它们当中有一个认为保密是通信竞争成功的通道。天哪，我也想要一个！

大数据痛点 No.2：多工作负载扩展

你拥有Docker，你拥有Yarn，你拥有Spark、Tez、MapReduce，无论后面你拥有的是什么。你也可能会有具有不同优先级的池，很多东西都从那里出来。也许你在Paas上部署比如Java war文件时可以“自动缩放”，但是如果你希望使用Hadoop来做到这一点就比较特殊了。

此外，存储和数据处理是怎样互相影响的？有时候你可能需要临时扩大和分配存储。那么，我应该能够运行我的“按月结”批处理，使Docker自动部署所有的空间。然而，当我停止做这些工作时，系统应该取消部署它们，并去部署其它任何需要的资源。应用程序或工作负载应该不需要为此承担任何工作。

这不是我们今天的情况，我希望你喜欢写脚本。

大数据痛点 No.3：更糟糕的，NoSQL部署

为什么我可以使用SSH和sudo将Linux 沙箱打包成镜像、点击它们的Ambari、安装像Hadoop一样复杂的东西，但是，我们仍有必要为它适用于MongoDB和其它数据库而做点实际性的努力吗？当然可以，我可以写点脚本，但是我们为什么要这么做？

大数据痛点 No.4：Query 分析器/修改器

当我在JBoss工作的时候，我参与了很多有关Hibernate的工作，以及后面对JPA/EJB3的调整工作。这主要包括了查看日志、查找哪里出现了n+1式的查询并将其调整为joins查询、删除那些使性能低下的愚蠢缓存配置。

其它时候，它却是相反的：你在系统中添加了一个该死的表并且它一直无法返回。有时，在更复杂的系统中，我想查看一下Oracle企业管理器和它的分析报告，它竟然以一种滑稽搞笑急性怪异的语言描述，而这往往暗示了这些问题。然而，我经常看到两个表一起使用并明确这种模式。我甚至考虑对其编码。

现在，当我调整NoSQL系统的时候，我遇到了这个相同问题的不同变种：复杂查询中太多的坑，或者你的索引与where语句不匹配（范围合并）。总而言之，我们已经对运行的非常糟糕、复杂的查询进行了优化，但是我们从来没有置身于开发者之外来质疑这些查询。它看起来好像你可以这样建立，并对它说：“Hi，你发送了这些查询，我认为它们看起来应该……”

哦，我想一些事情能够被自动化处理完会应该会很有趣。我所能表达的是，非常庆幸我已经走到了食物链的更高层，这样我就没必要再做那些工作了。

大数据痛点 No.5：分布式代码优化

我希望我会开始看到Spark的No.4版，并具有uber功能和其它很多小功能，或者其它一些东西。在编译器中，你可以写个优化器来检测循环中可能出现的非依赖性操作，并自动抽出使它们并行化。我还未见到过分布式计算中非常显著的东西。“数据科学家”写的Python并不能很好的分配计算问题，并且有不必要的内存浪费。这时，需要更加厉害的技术人来理解他或她想要做什么，并手动优化它。

这些问题看起来就像你最喜欢的编译原理书中的技术。我猜想，Zeppelin或Spark下一步可能会帮助优化你糟糕的代码，使得它能在集群中更好的运行。

大数据痛点 No.6：De-distributor

我承认，我第一次了解Hadoop是在Hive中编写select count() from somesmalltable 开始的。我想”天啊，这个大坑”，你可以发现一些问题并且知道它们并未很好的分布，而且有一些你几乎不需要的附加数据（比如行数），分布它们没有任何意义。通常情况下，这些都是比较大的作业（比如查询表），但是无论是Hive、Spark、HDFS或YARN，假设都是所有问题都被分布计算。有些却需要尽可能的不被分布，因为在不是分布式的环境下它们能更快。我所说的是哑巴东西，像select from thousandrowtable 剔除了一个MapReduce作业。

大数据痛点 No.7：机器学习映射

有很多事例我可以告诉你，”Oh，这是一个聚类问题”或者“这是映射”或其它什么。但是，似乎还没有人完成对公共业务部分进行映射、描述问题并将其抽象为你会使用的算法的描述。

在金融之外，也许10%-30%的任何企业实际上是独有的——那就是，我可以将销售、营销、市场、库存、劳动力等映射成通用模型，然后描述算法来供使用。这个工作不仅能改变我们办公的方式，而且可以极大地扩展市场。将它看成是大数据的设计模式，只能更注重业务方面。

大数据痛点 No.8：安全

首先，为什么？为什么Kerberos是获得单点登录的唯一途径？云网络中没有Kerberos。（好吧，人们也都这么做，但是在Reddit 上仍然有个abacus的爱好者地盘。）

其次，奇怪的竞争者以对每个人不利的方式扭曲Hadoop。当涉及到基本的身份验证和授权时，为什么我需要两个完全不同的协议栈、它们不完全支持Hadoop的各个部分，而不是其它呢？好吧，竞争加密（更小、更快、更强）但无论是Ranger或Sentry或其它什么的，为什么不能有个涵盖了所有Hadoop项目的访问和授权机制？公平地说，这是NoSQL领域中比较糟糕的；每个2-bit”我们热爱开源”供应商通过长达100行或企业专有版本的LDAP集成部分来表明它们对开源的热爱。

大数据痛点 No.9：抽取，转换，加载

ETL是每个大数据项目预约的沉默杀手。你有事情要做，但是你要去写Flume、Oozie、Pig、Sqoop和Kettle。这也是你会在那里看到冗余的数据，因为数据在那里是凌乱的。但是没有人会对使这更加无缝有太多的愿景。这个问题不够性感，但是却是大问题。

在大数据技术中，什么是你最喜欢的“OMFSM修复已经”问题？

英文原文：9 big data pain points