hadoop集群可以处理数据的大小 搭建私有云平台：Hadoop还是选择OpenStack？
搭建私有云平台：Hadoop还是选择OpenStack？
首先建议题主描述不清楚应用场景，要不然别人做的方案很有可能都不符合需求。
就Hadoop和OpenStack的纠结而言，支撑数据分析用前者，做资源管理用后者。
补充
题主的需求，实质是垒建一个IoT实时自动大数据平台，而不是一般意义的私有云。IoTa大数据平台之外数据采集和结果反馈，其余部分和好象的大数据平台相应该差不多。OpenStack兼通管理方面VM资源管理，Hadoop兼通批处理，不擅长实时自动去处理，因此必须这里有一种更加完善的解决方案。这里帮我推荐考虑到Storm或是ApacheFlink。
OpenStack是一个开源的IaaS实现，由Nova、Cinder、Neutron、Swift、Glance等一系列相互影响的子项目分成，可以解释为云计算领域的Linux。OpenStack架构松耦合，高可扩展，能适应差别企业的需求，早就下一界IaaS私有云事实标准。国内外各大厂都在OpenStack上有太大的投入。当然了项目成长的同时，也受到大厂激烈博弈的一些影响，但项目本身就是大家求同存异的结果，我们相信OpenStack会在竞合中有更幸福的未来。
大数据平台可以不完全不鸟OpenStack，分布式文件系统有HDFS，资源调度和管理YARN就行。YARN都也接受Docker，只希望细粒度调度模式这个可以决定Mesos，Mesos可以提供良好的道德的API，支持很多成熟的框架，只不过Mesos在Hadoop生态中，这是一个缺憾。Apache Hadoop都能够以低成本通过海量数据的多维统计分析，我还是很有优势。
核心流式计算部分，有Storm、Spark、Flink也可以中,选择。
Storm编程模型简单，毫秒级别延迟，容错性、扩展性和可靠性都也很好，在国内有很多团队常规。当然了Storm只不过是流换算框架，且又不能直接借用YARN。
ApacheSpark是和Hadoop完全不一样最流行开放源代码大数据框架，社区亢奋状态，在流可以计算、图处理、机器学习方面都上缴很大，允许对SQL的优化，很合适多种大数据平台的需求，但SparkStreaming本质还是批处理，把数据流可分解成一系列小的RDD，通过时间窗来再控制数据块的大小，有测量说不能意见秒级可以计算。
ApacheFlink是可扩展的批处理和流式数据处理的数据处理平台，能基于组件同一个Flink启动时提供允许流处理和批处理两种类型应用的功能。不只是Spark，Flink把批处理两年前特珠的流一次性处理，而且允许增量迭代，这是非常赞的设计，这个可以飞快地全面处理数据密集型和迭代任务，性能很有保证。但是目前Flink用户群和社区还没有Spark这样强横。但Flink的未来很值得期待，可能会要时间的沉淀。
Spark和Flink的对比，ApacheFlink现在在大数据处理方面还能够和ApacheSpark相抗衡么这个问题的最佳的位置答案质量很棒，如需转载深悔乎，汉语翻译的这篇文章：IntroductionneedApacheFlinkanySpark Developers:FlinkvsSpark
最后，上张网易猛犸大数据平台架构图，供可以参考。
高级数据库，数据仓库有哪些关键技术？
一直想收拾好帮一下忙这块内容，既然如此是漫谈，就想起什么说什么吧。我始终是在互联网行业，就以互联网行业来说。先至少列下互联网行业数据仓库、数据平台的用途：
重新整合公司所有业务数据，建立统一的数据中心；
提供各种报表，有给高层的，有给各个业务的；
为网站运营提供运营上的数据支持，是数据，让运营及时所了解网站和产品的运营效果；
为各个业务能提供线上或线下的数据支持，蓝月帝国公司统一的数据交换与提供给平台；
分析什么用户行为数据，按照数据挖掘来降低投入成本，增强耗去效果；例如广告自选专业精准投放、用户个性化推荐等；
开发数据产品，直接与间接为公司赢利；
大力建设开放数据平台，开放的公司数据；
。。。。。。
上面列下的内容看起来和传统行业数据仓库用途差不多吧，但是都具体的要求数据仓库/数据平台有很好的稳定性、可靠性；但在互联网行业，除了数据量大之外，越来越多的业务要求时效性，甚至还很多是具体的要求动态实时的，至于，互联网行业的业务变化太快，不可能像传统行业一般，这个可以使用自顶向下的方法组建数据仓库，两全其美，它那些要求新的业务一下子能融入虚空数据仓库中来，老的下线的业务，能很更方便的从可以做到的数据仓库中不上线；
不过，互联网行业的数据仓库那是有所谓的敏捷数据仓库，反而没有要求能飞速的响应数据，也那些要求能急速的响应业务；
建设魔防数据仓库，以外对架构技术上的要求之外，还有一个很最重要的方面，那是数据建模，如果不是一上来就想着组建一套能兼容性问题所有数据和业务的数据模型，那你又又回到现代数据仓库的建设上了，很难满足的条件对业务变化的快速响应。防范状况，像是是先将核心的持久度化的业务接受深度适宜建模（比如说：实现网站日志组建的网站统计分析模型和用户打开浏览器轨迹模型；基于公司核心用户数据成立的用户模型），其它的业务好象都常规维度宽表的来建立起数据模型。这块是后话。
整体架构下面的图是我们目前建议使用的数据平台架构图，当然大多公司肯定都差不多：
逻辑上，好象都有吧数据采集层、数据存储与分析层、数据共享层、数据应用层。很有可能叫法有所有所不同，本质上的角色都我不是很清楚。
我们往外看：
数据采集数据采集层的任务就是把数据从各种数据源中再采集和存储位置到数据存储上，期间有可能会做一些简单的可以清洗。
数据源的种类比较多：
网站日志：
另外互联网行业，网站日志占的份额的最，网站日志储存在多台网站日志服务器上，
象是在每台网站日志服务器上布署flumeagent，实时动态的收集网站日志并存储到HDFS上；
业务数据库：
业务数据库的种类都是形态不同，有Mysql、Oracle、SqlServer等，这时候，我们深切的需要一种能从各种数据库中将数据同步到HDFS上的工具，Sqoop是一种，可是Sqoop极为繁重的劳动，但是无论数据量大小，都不需要起动MapReduce来执行，但是必须Hadoop集群的每台机器都能访问业务数据库；防范此场景，淘宝开源的DataX，是另一个很不错的解决方案（可参考文章《异构数据源海量数据交换工具-Taobao DataX 下载和使用》），有资源的话，可以基于组件DataX之上做二次开发，就能的很好的解决，我们目前使用的DataHub也是。
当然，Flume配置与开发，也是可以实时地的从数据库中网络同步数据到HDFS
充斥于Ftp/Http的数据源：
有可能一些合作伙伴需要提供的数据，必须/Http等定时获取，DataX也也可以行最简形矩阵该需求
其他数据源：
诸如一些手工录入的数据，只不需要提供一个接口或小程序，即可能完成
数据存储与分析毋庸质疑，HDFS是大数据环境下数据仓库/数据平台最完美的艺术品数据存储解决方案。
自动更新数据分析与计算，也就是对实时性要求不高的部分，在我现在看来，Hive那就紧随其后的选择，丰富地的数据类型、内置函数；压缩比的很高的ORC文件存储格式；非常方便的SQL意见，以至于Hive在基于结构化数据上的统计分析远远的比MapReduce要高效率的多，一句SQL可以成功的需求，变更土地性质MR肯定必须上百行代码；
其实，使用Hadoop框架很自然也提供了MapReduce接口，如果没有是真的很领情变更土地性质Java，也可以对SQL不熟，那么也可以不不使用MapReduce来做分析与计算；Spark是这两年的很火的，当经过实践，它的性能并不比MapReduce要强很多，不过和Hive、Yarn结合的越贴越好，而，需要意见在用Spark和SparkSQL来做分析和计算。是因为早就有HadoopYarn，可以使用Spark不过是更加太容易的，不需要单独防御部署Spark集群，关与Spark On Yarn的相关文章，可建议参考：《Spark On Yarn系列文章》
实时计算部分，后面另说。
数据共享这里的数据共享，不过指的是前面数据分析与计算后的结果储存时的地方，反正应该是关系型数据库和NOSQL数据库；
前面可以使用Hive、MR、Spark、SparkSQL总结和算出的结果，那就在HDFS上，但大都业务和应用不可能然后从HDFS上声望兑换数据，这样的话就不需要一个数据共享的地方，以至于各业务和产品能方便啊的某些数据；和数据采集层到HDFS刚好而是，这里不需要一个从HDFS将同步数据至其他目标数据源的工具，同时，DataX也这个可以柯西-黎曼方程。
同时，一些实时计算的结果数据很可能由实时计算模块就中写入数据共享。
数据应用
业务产品
业务产品所在用的数据，也存在地于数据宽带共享层，他们就从数据共享层访问即可；
报表
同业务产品，报表所在用的数据，一般都是巳经汇总统计好的，贮存于数据共享层；
即席查询
即席可以查询的用户有很多，有可能是数据开发人员、网站和产品运营人员、数据分析人员、甚至于是部门老大，他们应该有即席可以查询数据的需求；
这种即席可以查询大多数是可以做到的报表和数据共享层的数据并没法行最简形矩阵他们的需求，要从数据存储层直接查询。
即席查询一般是按照SQL完成，比较大的难度取决于人响应速度上，可以使用Hive有点儿慢，目前我的解决方案是SparkSQL，它的响应速度较Hive快很多，但能很好的与Hive兼容问题。
当然，你也可以不可以使用Impala，假如不在乎平台中再多一个框架的话。
OLAP
目前，很多的OLAP工具不能不能很好的支持从HDFS上就某些数据，大都是从将要的数据同步到关系型数据库中做OLAP，但假如数据量庞大无比的话，关系型数据库显然再不行；
这时候，需要做你所选的开发，从HDFS或则HBase中某些数据，成功OLAP的功能；
比如：参照用户在界面上选择类型的只怕的维度和指标，开发接口，从HBase中资源数据来可以展示。
其它数据接口
这种接口有通用的，有定制的。诸如：一个从Redis中获取用户属性的接口是通用的，所有的业务都也可以全局函数这个接口来某些用户属性。
实时计算现在业务对数据仓库实时性的需求越来越密集，例如：动态实时的了解网站的是一个整体流量；实时地的查看一个广告的曝光和再点；在海量数据下，依靠现代数据库和传统实现方法基本结束不了，必须的是一种分布式的、高吞吐量的、显示延迟低的、高可靠的实时计算框架；Storm在这块是也很能成熟了，但我选择类型SparkStreaming，原因很简单，想多引入一个框架到平台中，别外，SparkStreaming比Storm延时性高那你一点点，那对此我们的需要可以不遗漏掉。
我们目前在用SparkStreaming利用了实时自动的网站流量统计、实时的广告效果统计两块儿功能。
做法也很很简单，由Flume在前端日志服务器上收集到网站日志和广告日志，实时自动的你的邮箱给SparkStreaming，由SparkStreaming成功统计，将数据存储至Redis，业务通过ftp访问Redis动态实时声望兑换。
任务调度与监控在数据仓库/数据平台中，有数不清相当多的程序和任务，.例如：数据采集任务、数据同步任务、数据分析任务等；
这些任务以外按时调度，还必然的很古怪的任务依赖关系，比如说：数据分析任务要等相应的数据采集任务内容后才能开始；自动同步任务是需要等数据分析任务失败后才能又开始；这就不需要一个太完备的任务调度与监控系统，它另外数据仓库/数据平台的中枢，你们负责调度和监控所有任务的分配与运行。
前面有写过文章，《大数据平台中的任务调度与监控》,这里不再累赘。
归纳在我很显然架构并不是技术到最后越新越好，反而在可以满足自身需求的情况下，越简单的越比较稳定越好。目前在我们的数据平台中，的新一些的是查哈业务，而不是技术，他们把业务和需求弄清楚了，基本都只不需要做简单的SQL开发，后再配置到调度系统就可以了，如果不是任务无比，会送来告警。这样，是可以使更多的资源专注心于业务之上。
版权声明：本文内容由互联网用户自发贡献，本站不承担相关法律责任.如有侵权/违法内容,本站将立刻删除。
