以解决问题的角度分析Hadoop生态组件发展

做了一段时间的Hadoop的平台，这里对自己学习的生态组件做一个小结： 1）传统数据存储遇到困难，大数据无法存储，需要分布式存储系统，产生了HDFS。 2）解决了大数据存储，但是分布式情况下如何运算，引出了MapReduce分布式计算框架。 3）Hadoop 1.0时，MapReduce计算框架任务太重，2.0后将管理任务抽出，产生了YARN资源管理框架。 4）为了解决写JAVA程序来编写MapReduce计算的困难，可以通过Pig来编写程序。 5）大数据下的NoSQL新型数据库：HBase 大数据下的分布式仓库：Hive 6）为了解决从传统数据库或数据源将数据采集到大数据平台的组件（Hive，HBase等），产生了Sqoop组件，用于数据双向互导。 7）基于Apache 社区的Hadoop，安装部署、配置都非常复杂困难，HDP开发了Ambari专注于大数据的安装部署及监控运维。 8）大数据需要使用大集群，集群的协调管理复杂，产生了Zookeeper专注于协调集群管理。 9） 因为MapReduce分布式计算框架的性能不高效，所以产生了Spark生态组件用于提供高效的分布式计算，同时解决以前要装大量组件来满足不同业务应用的问题。Spark生态目的是一站式解决计算、查询、流计算、图计算、挖掘等应用问题。 10）为了处理流数据，产生了流数据采集的组件（Flume，Kafak）、流计算框架（Storm， Spark Streaming）。 11）为了解决海量数据的检索问题，产生了ELK（Elastic Search 相关组件）的数据检索解决方案。 12）为了解决海量数据的交互分析，查询等问题，产生了很多专注这方面的组件：HAWQ、Presto、Impala等。 13）为了端到端的提供流程管控或使用方法，产生了HUE，提供页面化的流程管控。 14）为了分析定位问题，监控管理，需要有日志的管理，分析组件，例如：Log Search，Solr等组件。 15）细分还有很多业务场景，例如分析师需要进行关联查询分析，使用HIVE数据仓库效率低，产生了Kylin专注分析的组件。