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