数据治觥貶adoop+NoSQL,不妨先看完善现有技术的10条捷径.docx

/article/2013-07-19/2816277-hadoop-when-to-use数据分析≠Hadoop+NoSQL，不妨先看完善现有技术的10条捷径摘要：Hadoop让大数据分析走向了大众化，然而它的部署仍需耗费大量的人力和物力。在直奔Hadoop之前，是否已经将现有技术推向极限？这里总结了对Hadoop投资前可以尝试的10个替代方案，省时、省钱、省力，何乐而不为？ 让业务搭乘大数据技术确实是件非常有吸引力的事情，而Apache Hadoop让这个诱惑来的更加的猛烈。Hadoop是个大规模可扩展数据存储平台，构成了大多数大数据项目基础。Hadoop是强大的，然而却需要公司投入大量的学习精力及其它的资源。如果得到正确的应用，Hadoop确实能从根本上提升你公司的业务，然而这条Hadoop的应用之路却充满了荆棘。另一个方面，许多企业（当然不是Google、Facebook或者Twitter）的数据体积并没有大到需要巨型Hadoop集群去做分析，他们纯粹是被“大数据”这个热门的词语给吸引的。就像Dabid Wheeler所说“计算机科学的所有问题都有另一个层次间接的解决方案”，而Hadoop正是类似间接解决方案；当你的上司被一些流行词汇所吸引时，做正确的软件架构决策将变的非常艰难。下文将给出一些对Hadoop进行投资前需要尝试的替代方案：了解你的数据 数据的总体积 Hadoop是为大型数据集所建立的有效解决方案。GB级以上的文件系统HDFS。因此如果你的文件只是MB级的，你最好对数个文件进行整合（zip或者tar），让其达到数百兆或者是几GB。HDFS会将文件分割，并以64MB、128M或者更大的块进行存储。如果你的数据集非常的小，那么使用这个巨型生态系统将不会很适合。这需要对自己的数据有足够的了解，并且分析需要什么类型的查询以及你的数据是否真的够大。另一方面，鉴于你的计算指令可能很大，只通过数据库去测量数据的体积可能会存在误差。有时候数学计算或者分析小型数据集的排列可能会让得出的结果远大于实际数据体积，所以关键在于你对数据有切实的了解。数据增长的速度 你可能在数据仓库或者其它的数据源中存有数TB数据，然而在建立Hadoop集群前有一个必须考虑的因素就是数据的增长速度。对你的分析师提出几个简单的问题，比如：数据增速究竟有多快？这些数据是否以非常快的速度增长？几月或者几年后数据的体积究竟会有多大？许多公司的数据增长都是按年算的。这种情况下，你的数据增长速度其实并不快；所以这里建议考虑归档和清除选项，而不是直接的奔往Hadoop。如何减少需处理的数据 如果你确实有非常大体积的数据，你可以考虑通过以下的途径将数据缩减到非常适合管理的体积，以下的几个选项已经过产业几十年考验。考虑归档 数据存档是对过期的数据进行分开存储，当然存储的时间根据实际需求制定。这需要对数据以及应用程序对数据的使用情况，有非常充分的了解。比如电子商务公司的大数据处理只将3个月内的数据存入活跃数据库，而旧订单则被存入单独的存储。这个途径同样可以运用于你的数据仓库。当然你可以存储更多的近期数据用于报告和查询，使用频度少的数据可以被存入单独的存储设备。考虑清除数据 有时候我们一直忙于收集数据而不清楚究竟需要保存多少数据，如果你存储了非常多用不到的数据，那么这将毫无疑问的降低你有效数据的处理速度。弄清你的业务需求并且审查数据是否可以被删除，从中分析出你需要储存数据的类型，这不仅会节省你的存储空间，同样会提升有效数据的分析速度。一个经常用到的最佳实践就是给数据仓库建立附加列，比如created_date、created_by、update_date及updated_by。通过这些附加列可以对数据进行阶段性的访问统计，这样就可以清楚数据的有效周期。这里需要着重对待的是数据清除的逻辑，切记先思考再实现。如果你使用了一个归档工具，那么数据的清除将会变得非常容易。不是所有的数据都很重要 你可能受不了储存所有业务相关数据的诱惑，你可能有很多的数据来源，比如：日志文件、营销活动数据、ETL作业等。你需要明白不是所有数据都对业务起关键作用，而且在数据仓库中保存所有的数据并不是有益的。在数据源过滤掉不需要的数据，甚至是在储存到数据仓库之前。不要对所有的数据进行存储，只分析你所需的数据。注意哪些数据是你想要收集的 拿在线视频编辑业务来说，你会需要保存你用户做出的所有操作吗？这样的话可能会产生非常大的数据体积，如果你发现你的数据仓库不足以应对这些数据，你可能会考虑只存储元数据。虽然视频编辑是个非常极端的例子，然而并不妨碍我们在其它用例中考虑这些信息。总而言之，根据业务的需求只收集所需要的数据。智能分析 聘请了解业务的分析师 到目前为止，你应该已经清楚理解数据的重要性；所以在你做了上面所