大数据技术领域的九大痛点.docx

《大数据技术领域的九大痛点.docx》由会员上传分享，免费在线阅读，更多相关内容在教育资源-天天文库。

1、大数据技术领域的九大痛点尽管在Hadoop与NoSQL部署方面做足了准备，同样的问题仍然一次又一次反复出现。现在业界是时候尽快搞定这些麻烦事了。有时候一艘巨轮的侧方出现了破洞，但业界却决定坐等船体下沉、并把希望寄托在销售救生艇身上。也有些时候，这些问题似乎并没到要闹出人命的地步——类似我家里浴室的状况，只有往一边拧龙头才会出水。过一阵子我可能会找机会修理一下，但事实上这个问题已经存在了12年之久了。而在面对大数据业务时，我可以列出九个长久以来一直令人头痛的问题，时至今日它们依然存在着并困扰着无数用户。大数据痛点一号：GP

2、U编程仍未得到普及CPU的使用成本仍然较为昂贵，至少与GPU相比要贵得多。如果我们能够面向GPU开发出更理想的执行标准以及更多表现出色的驱动程序，那么相信一个新的市场将由此诞生。就目前来讲，GPU的使用成本优势并没能得到很好的体现，这是因为我们难以针对其进行编程，而且几乎没办法在不建立特定模型的前提下完成这项任务。这种情况类似于，有些人希望编写出类似于ODBC或者JDBC的代码来处理某些高强度工作，并说服AMD或者英伟达将业务着眼点放在显卡产品之外。假设我们原本已经习惯了使用Spark实现各类计算任务，而且压根不觉得这么

3、做有什么问题;但仿佛在一夜之间，其他人都开始构建所谓“GPGPU”集群，这自然会让我们有点措手不及之感。不少技术人员都开始在这方面做出探索，但要想真正让成果实现市场化，我们至少需要搞定两大竞争对手——AMD以及英伟达，也许再加上英特尔。除非它们愿意联手合作，否则如果继续像现在这样把技术保密看作市场成功的实现途径，那么问题永远也找不到理想的答案。大数据痛点二号:多工作负载缩放我们拥有Docker。我们拥有Yarn。我们还拥有Spark、Tez、MapReduce以及未来可能出现的一系列技术方案。我们还拥有多种资源池化实现工

4、具，其中包含各类不同优先级及其它设定。如果大家选择部署一个Javawar文件，则可以在PaaS上进行“自动伸缩”。但如果大家希望在Hadoop上实现同样的效果，那么情况就不太一样了。再有，存储与处理体系之间的交互该如何处理？有时候大家需要以临时性方式对存储资源进行扩展与分发。我应该有能力运行自己的“月末统计”批量任务并将Docker镜像自动部署到任意指定位置。而在我的任务完成之后，系统应当对其进行反部署，并将资源重新分配给其它工作负载。应用程序或者工作负载应该根本不需要在这方面浪费太多精力。但目前这些要求尚无法实现。我希

5、望大家习惯了编写Chef方案与脚本，因为这是达到以上目标的惟一办法。大数据痛点三号:NoSQL部署更令人头痛为什么我已经能够利用ssh与sudo将镜像导入Linux设备、为其指定Ambari并安装像Hadoop这样复杂度极高的项目，但却仍然需要在MongoDB以及大部分其它数据库的部署工作中浪费时间与精力？当然，我也可以编写Chef自动化方案，但恕我仍对此无法认同。大数据痛点四号：查询分析器/修复器当初在使用JBoss的时候，我曾经对Hibernate以及后来的JPA/EJB3进行过大量调试。具体来讲，主要工作包括查看日

6、志记录、找出存在n+1类查询的位置、将其纳入join并移除可能影响运行效果的糟糕缓存配置。但有时候情况又完全相反：我们可以将每一套需要的表添加到系统当中，但其返回速度却慢得让人抓狂。有时候，我打算在复杂程度更高的系统之上查看OracleEnterpriseManager及其分析结果，但返回的报告却完全是一堆胡言乱语——这意味着其中存在问题。不过我可以同时着眼于两套始终共同协作的表，并据此找到分析当中存在的规律。我甚至考虑过利用编程方式解决问题。而现在，每次对NoSQL系统进行调整时，我都会发现上述问题以不同形式表现出来：

7、要么是跳转次数太多、要么是查询太过复杂，有时候我们的索引无法与where子句（即范围合并）相匹配。简而言之，我们将大量精力投入到了糟糕或者复杂查询的优化当中，但除了开发者培训课程、我们似乎从来不会对这些查询本身提出质疑。这套系统似乎有种魔性，它同用户的关系类似于：“嘿，你发来了这些查询，我认为它们看起来应该像这样……”好吧，我猜很多从业者都以完成这些本可以通过自动化方式实现的工作为生。必须承认，我很庆幸自己已经渡过了基层工作时期，再也不用为这些琐事烦恼了。大数据痛点五号:分布式代码优化我估计Spark当中的大量小功能及小

8、设定会带来第四点里提到的各类问题。在编译器方面，大家可以编写优化器来检测循环内的非依赖性操作，同时自动对其进行提取与并行化调整。我在分布式计算领域经常会见到这类情况。所谓“数据科学家”们编写出的Python代码相当垃圾，根本没办法有效进行问题分配，而且会造成大量不必要的内存浪费。在这种情况下，需要由技术从牛挺身而出，