摘要：向数据分析师问几个简单的问题数据增长的有多快这个数据增长的步伐很快么数月或数年之后，这个数据将会达到什么样的尺寸许多公司的数据增长是以数年而非数月或数日计算的。如果你的数据分析师不懂应从中提取什么出来，就将几乎无用。
为你的业务使用大数据技术是一个非常有吸引力的事情，现在Apache Hadoop使得它更加吸引人了。
Hadoop是一个大规模可伸缩的数据存储平台，被用作许多大数据项目的基础。Hadoop很强大，但是它有一个很陡峭的学习曲线，需要公司在时间和其他资源上作大量的投资。如果正确地应用它，对你的公司来说，Hadoop可以成为一个真正的游戏规则改变者，但它存在很多被错误使用的可能。
另一方面，许多企业(不像是谷歌、Facebook或Twitter)都没有真正的“大数据”来需要用一个巨大的hadoop集群分析事物，然而 hadoop 这个流行语却吸引着他们。
如大卫惠勒所说的：“所有计算机科学的问题都可以用另一个间接的中间层来解决”。 Hadoop提供了这样一种间接层；作为一个软件架构师，当你的较高管理层对一些流行语有很不专业的偏颇认识时，也许真的很难采取正确的决定。
在本文中，我想要建议“应在投资到Hadoop之前尝试一些替代品”。
了解你的数据
1.总体数据的大小
Hadoop被设计用来在大型数据集上能进行有效的工作。简单给点提示：
Hadoop有一个专为大尺寸文件（如几G）设计的文件系统(HDFS)。因此，如果你的数据文件尺寸只是几M的话，建议你合并(通过zip或tar)多个文件到一个文件中，使其尺寸在几百M到几G范围内。
HDFS把大文件们拆分存储到以64MB或128MB或更大的块单元中。
如果你的数据集相对较小，那它就不会是hadoop的巨型生态系统的较佳使用之地。这需要你去对你的数据比以往理解更多一些，分析需要什么类型的查询，看看你的数据是否真得“大”。
另一方面，只是通过数据库的大小来测量数据可能是骗人的，因为你的计算量可能会更大。 有时你可能会做更多的数学计算或分析小数据集的排列，这些可以远远大于实际的数据。所以关键是要“了解你的数据，并且很清楚它”。
2.数据增长数度（增长速率）
你的数据仓库或是其它数据源中可能拥有数个TB的数据。然而，在建立 Hadoop 集群前，你必须考虑到数据的增长。
向数据分析师问几个简单的问题：
数据增长的有多快？这个数据增长的步伐很快么？
数月或数年之后，这个数据将会达到什么样的尺寸？
许多公司的数据增长是以数年而非数月或数日计算的。如果你的数据增长数度非常快，我见建议你考虑一下归档及清理技术（将在本文后面的内容中详述），而非立即上马 Hadoop 集群。
3.如何减少你的数据量
如果你觉得你的数据实在是太大了，你可以考虑使用下面的方法将数据减少到相对可控的规模上。下面的几个选项都已经被业内成功使用多年。
4.归档
数据归档是将陈旧数据移动到一个独立数据储存器以长期保留（如果需要）的过程。
这需要对数据、对应用使用情况的充分了解。处理大数据的电子商务公司在现场数据库中保存近期3个月的订单细节数据，而早期订单则保存在一个独立的数据存储器中。
这个方法也可以使用到你的数据仓库中。你可以保存近期的数据以便更快的查询和报告，而将访问频率较低的数据保存在一个其它不同的存储设备中。
5.考虑清除数据
我们忙于收集数据时经常并不真正确定我们应该保留多少。如果你存储大量可能不是很有用的数据，它就会拖慢你近期数据的处理。弄清你的业务需求,看看是否可以删除旧的数据，把从那些数据分析的趋势存储起来以供后用。这不仅会节省你的空间,而且还可以在分析近期数据时帮助你加快速度。
对这种情况的一个常见的较佳实践是在您的数据仓库中有一些标准列，像创建日期，创建者，更新日期，更新者。现在根据这些列创建一个每日/每月的cron作业，用它清除你不想在你的数据仓库中看到的时段的数据。清除数据的逻辑基于你的领域可能不同，因此在实施它之前应作一些考虑。
如果您正在使用一个归档工具,它也可能是通过很轻松地配置就能清除无用的存档数据。
6.所有的数据都不重要
你可能受不了为你的业务保留所有数据的诱惑。你的数据有各种各样的来源，比如日志文件、现场交易、供应商整合、ETL工作、营销活动数据等等。但你应该知道，不是所有的数据都是关键业务，把它们都保存在一个数据仓库中可能不是很有帮助反而有害。在它们被存储到你的数据仓库之前，应从源头上过滤不需要的数据。如果你真需要在你的数据库的表里每一列存储和分析那些数据，就准备好发疯吧。
7.想好你想收集哪些作为数据
假设你进入一个在线视频编辑的业务。你想保存你的用户在每个视频上做的全部更改吗？这会产生巨大的体积。当你感觉到你的数据仓库可能无法处理它的情况下，你可能需要考虑只存储元数据。视频编辑是一个很可能的例子,不过它可能适用于许多其他与你存储数据相关的信息。
一般来说,如果你有一些有关系的数据，你就有机会从多个来源得到它们，而且不是所有的都需要存储在你的数据仓库中。
更智能的分析
1.聘请理解业务的分析师
现在,你可能已经明白“了解数据”对于有效地管理它们来说是非常重要的。相信我，当你觉得我已经试了所有这些东西时，这一步会帮到你。是时候让我们进入一个如Hadoop这样的大数据解决方案中了。
如果你的数据分析师不懂应从中提取什么出来，Hadoop就将几乎无用。应寄希望于那些理解业务的人。鼓励他们做实验和学习新的方法来看待相同的数据。找出哪些可以与现有基础设施取得唾手可得的收益。
2.为制订决策使用统计抽样
统计抽样是研究人员和数学家为了对大型数据推断合理结论而使用的一种非常古老的技术。
通过执行一个统计的样本，我们的体积可以极大地减少。不用跟踪数百万或数十亿的数据点，我们只需要随机挑选几千或几百个即可。
该技术不能提供准确的结果,但是它可以被用于对一个大型数据集获得高水平的理解。
3.定标技术
你真地把关系数据库的处理发挥到极致了吗？
在你真去探索其他技术之前，我希望你去看看关系型数据库是否能够处理它。人们使用关系数据库已经很久了，已经托管了一些几T字节大小的数据仓库。在你决定进入hadoop之前，你可以对关系数据库尝试以下方法。
4.数据分区
数据分区就是逻辑上和/或物理上把数据划分成一些更容易维护或访问的部分的过程。分区支持最流行的开放源代码关系数据库(MySQL 分区 和 Postgres 分区 )。
5.对关系数据库尝试数据库分片的方法
数据库分片可以作为对关系数据库的处理速度发挥到极限的最后一个手段。这种方法可以应用于你可以逻辑上分离数据到不同的节点，并在你的分析中有更少的交叉节点连接的时候。在web应用程序中,一个常见的分片方法是基于把用户和所有与一个用户相关的信息存储在一个节点上来确保较佳的速度。
分片并不容易，如果你有很多复杂的关系，并且没有简单的方法来分离数据到不同的节点上，这个方案可能不适合你。如果你的应用需要有很多交叉节点连接，分片的打算可能会失败。
结论
我曾在不同的公司被高层管理人员要求把Hadoop作为一个可选项去做某些事。要说服他们总是很难，但是当我把这个信息告诉他们后，他们不得不三思而后行。我很幸运，能为我工作的这些公司节省一些钱。
如果你发现为了扩大你的关系数据库，你已经尝试了所有可能的选项，这才是你应该开始考虑建立一个Hadoop集群的时候。
首先,您可能应该使用cloudera提供的虚拟机镜像。它们对于在你现有的基础设施上使用hadoop做快速的概念证明真的是很方便。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/3819.html
摘要：微服务架构模式使得每个微服务独立部署，且每个服务独立扩展，开发者不再需要协调其它服务部署对本服务的影响。微服务架构模式使得持续化部署成为可能。所以使用微服务不是必须的，而是在适当的实际，架构适应应用场景的一种改变。 近段时间离职，跟同事们讲解我之前所做的微服务相关产品，对于同事们提出的问题，做了如下整理出来，加上自己的理解，分享出来跟大家一起探讨下： 问题预览 我为什么要换微服务？能...
摘要：对于程序员来说，更意味着代码的组织，工作成员之间的协作方式。我常犯的一个错误是直接在或分支上直接，而团队是不允许这样做的。 先介绍下背景，博主由运营转行前端，入职一个月，完成了一个相对较大的模块。由于基础相对薄弱，犯下了不少错误，故想记录下来警醒自己和分享各位。 前端技术栈是 ES6 + backbone + react + antdUI,后端使用的 Ruby on Rails。 1....
摘要：对于程序员来说，更意味着代码的组织，工作成员之间的协作方式。我常犯的一个错误是直接在或分支上直接，而团队是不允许这样做的。 先介绍下背景，博主由运营转行前端，入职一个月，完成了一个相对较大的模块。由于基础相对薄弱，犯下了不少错误，故想记录下来警醒自己和分享各位。 前端技术栈是 ES6 + backbone + react + antdUI,后端使用的 Ruby on Rails。 1....
摘要：对于程序员来说，更意味着代码的组织，工作成员之间的协作方式。我常犯的一个错误是直接在或分支上直接，而团队是不允许这样做的。 先介绍下背景，博主由运营转行前端，入职一个月，完成了一个相对较大的模块。由于基础相对薄弱，犯下了不少错误，故想记录下来警醒自己和分享各位。 前端技术栈是 ES6 + backbone + react + antdUI,后端使用的 Ruby on Rails。 1....
摘要：对于程序员来说，更意味着代码的组织，工作成员之间的协作方式。我常犯的一个错误是直接在或分支上直接，而团队是不允许这样做的。 先介绍下背景，博主由运营转行前端，入职一个月，完成了一个相对较大的模块。由于基础相对薄弱，犯下了不少错误，故想记录下来警醒自己和分享各位。 前端技术栈是 ES6 + backbone + react + antdUI,后端使用的 Ruby on Rails。 1....
阅读 1988·2023-04-25 15:00
阅读 2179·2021-11-18 13:14
阅读 861·2021-11-15 11:37
阅读 2929·2021-09-24 13:55
阅读 1088·2019-08-30 15:52
阅读 2519·2019-08-29 12:35
阅读 3206·2019-08-29 11:04
阅读 1047·2019-08-26 12:13
