尽管对Hadoop和NoSQL的部署做了充分的准备，同样的问题还是一再重演。现在是该行业尽快解决这些问题的时候了。有时，一艘巨轮的船舷破了个洞，但该行业决定等待船体沉没，并将希望寄托在销售救生艇上。也有一些问题看起来并不致命——类似于我在家里的浴室里的情况，只有当水龙头转到一侧时，水才会流出。过一段时间我可能会有机会修复它，但事实是这个问题已经存在12年了。面对大数据业务，我可以列举九个长期以来一直很头疼的问题，直到今天依然存在，困扰着无数用户。大数据痛点一：GPU编程仍未普及。使用CPU的成本还是比较贵的，至少比GPU贵很多。如果我们能够为GPU开发出更理想的执行标准和更好的驱动程序，那么我相信一个新的市场将会诞生。目前，使用GPU的成本优势并没有得到很好的体现，因为很难为它们编程，而且如果不构建特定的模型，几乎没有办法完成这项任务。这种情况类似于有些人希望编写类似于ODBC或JDBC的代码来处理一些高强度的工作，并说服AMD或Nvidia专注于图形产品之外的业务。假设我们习惯使用Spark来实现各种计算任务，我们认为这样做完全没有问题；但仿佛一夜之间，其他人开始构建所谓的“GPGPU”集群，这自然会让我们感到有些措手不及。许多技术人员已经开始在这方面进行探索，但要想真正将成果推向市场，我们至少需要获得两个主要竞争对手——AMD和Nvidia，或许还有英特尔。除非他们愿意合作，否则如果我们继续像现在这样将技术保密作为取得市场成功的途径，那么这个问题将永远找不到理想的答案。大数据痛点2：多工作负载扩展我们有Docker。我们拥有纱线。我们还有Spark、Tez、MapReduce，以及未来可能出现的一系列技术方案。我们还有多种资源池化实现工具，包括各种不同的优先级和其他设置。如果选择部署Javawar文件，则可以在PaaS上“自动缩放”。但是如果你想在Hadoop上达到同样的效果，那么情况就不一样了。此外，存储和处理系统之间的交互应该如何处理？有时您需要以临时方式扩展和分配存储资源。我应该能够运行我自己的“月末统计”批处理作业并自动将Docker映像部署到任何给定位置。在我的工作完成后，系统应该取消部署并将资源重新分配给其他工作负载。应用程序或工作负载根本不需要在这方面浪费太多精力。然而，这些要求尚未得到满足。我希望您习惯于编写Chef食谱和脚本，因为这是实现上述目标的唯一途径。大数据痛点三：NoSQL部署更头疼为什么我已经可以使用ssh和sudo将镜像导入linux设备，指定Ambari，安装Hadoop这样非常复杂的项目，但是还需要在MongoDB和large部署一些其他数据库上浪费时间和精力吗？当然，我也可以写Chef自动化方案，但我还是不认同这一点。大数据痛点No.4：QueryAnalyzer/Repairer我在使用JBoss的时候，在Hibernate和后来的JPA/EJB3上做了很多调试。具体来说，主要工作包括查看日志记录，找出哪里有n+1种类型的查询，包括在join中，以及去除可能影响性能的不良缓存配置。但有时恰恰相反：我们可以将我们需要的每组表添加到系统中，但它返回的速度慢得令人抓狂。有时我打算查看OracleEnterpriseManager及其在更复杂系统上的分析结果，但返回的报告是一堆乱码——这意味着存在问题。但我可以查看两套始终协同工作的手表，并根据它们在分析中找到规律。我什至考虑过以编程方式解决问题。现在，每次我对NoSQL系统进行调整时，我发现上面的问题都以不同的形式表现出来：要么是跳转次数太多，要么是查询太复杂，有时我们的索引无法匹配到where子句（即范围合并）匹配。简而言之，我们投入了大量精力来优化错误或复杂的查询，但我们似乎从不质疑查询本身，除非是在开发人员培训课程中。这个系统似乎有一些神奇的东西，与用户的关系是这样的：“嘿，你发送了这些查询，我认为它们应该看起来像这样......”嗯，我想很多从业者都这样做从事自动化工作谋生。我必须承认，我很庆幸自己已经度过了基层工作时期，不用再为这些琐碎的小事烦恼了。大数据痛点No.5：分布式代码优化我估计Spark中大量的小函数和小设置会导致第四点提到的各种问题。在编译器端，您可以编写一个优化器来检测循环内的非依赖操作，并自动提取和调整并行化。我在分布式计算领域看到了很多这种情况。所谓的“数据科学家”写的Python代码相当垃圾，没有办法有效分配问题，还会造成很多不必要的内存浪费。在这种情况下，技术就很有必要从牛身上站起来，努力理解眼前这位“科学家”的想法，并对其进行优化。问题是上面的情况和你在编译理论书上看到的反例几乎一模一样。我猜随着技术的不断发展，未来Zeppelin甚至Spark本身都会站出来帮助大家修复坏代码，保证其与集群的顺畅配合。大数据痛点No.6：分布式名不副实。不得不承认，我对Hadoop的第一印象是在Hive中输入selectcount(*)fromsomesmalltable。我认为这种用法真的非常糟糕。人们会发现问题，意识到分配效果不理想。有些朋友甚至不需要参考其他数据（比如行数）就发现我们无法实现负载分配。通常，这些只是整体工作的一部分（比如查表），但无论我们实际使用的是Hive、Spark、HDFS还是YARN，它都会首先假设所有的问题都已经被实际分发了。其中一些工作需要尽可能避免，因为它使它运行得更快。我最受不了的就是使用select*fromthousandrowtable等操作拖慢MapReduce任务的运行速度。大数据痛点七：机器学习映射在具体实例中，我们很容易区分聚类问题、聚类问题或其他分类任务。但似乎没有人愿意解决真正困难的部分——映射业务系统的公共部分，描述问题并通过描述映射找到具体应该使用的算法。除了金融行业，只有10%到30%的企业能够保持与行业正常情况不同的特征——也就是说，我们可以将销售、营销、库存、劳动力等因素映射到一组通用模型中，然后描述找到合适的算法来使用。这项工作不仅会改变我们做生意的方式，而且会极大地扩大市场的整体规模。我们可以认为是面向大数据的设计模式，但更多的是强调业务方面。大数据痛点八：安全第一，为什么只能通过Kerberos实现单点登录？云Web环境中没有类似Kerberos的解决方案可用。其次，Hadoop被供应商竞争的奇怪方式所扭曲，这对任何人都不利。说到基本的认证授权层，我们不得不使用两个完全不同的栈来为Hadoop的各个部分提供安全支持。加密方面的产品竞争我能理解（各种方案都在往更小、更快、更强的方向发展），但不管我们选择Ranger、Sentry还是其他方案，为什么不能有一套足够用的？覆盖所有Hadoop项目的认证机制？公平地说，大数据的现状比NoSQL更糟糕；任何说“我们喜欢开源”的公司都可以将几百行开源代码塞进他们的“企业级”版本的LDAP集成部分。大数据痛点九：抽取、转换、加载抽取、转换、加载（简称ETL）可以说是每个大数据项目中无声的预算杀手。我们都清楚我们需要用大数据技术做什么，但现在我们不是专注于业务需求，而是必须得到Flume、Oozie、Pig、Sqoop、Kettle等。造成这种情况的原因是我们的原始数据往往处于杂乱无章的状态。但真正令人惊讶的是，没有供应商愿意提出无缝解决方案。虽然解决这种问题没办法让你得诺贝尔奖，但其实可以帮助到广大的大数据技术用户。你在实际使用中遇到过哪些棘手的大数据技术难题？请在留言区写下你的“抱怨”。
