20世纪90年代，商业智能（也就是我们熟悉的BI系统）诞生，它将企业已有的业务数据转化成为知识，帮助老板们进行经营决策。比如零售场景中：需要分析商品的销售数据和库存信息，以便制定合理的采购计划。

显然，商业智能离不开数据分析，它需要聚合多个业务系统的数据（比如交易系统、仓储系统），再进行大数据量的范围查询。而传统数据库都是面向单一业务的增删改查，无法满足此需求，这样就促使了数据仓库概念的出现。

传统的数据仓库，第一次明确了数据分析的应用场景，并采用单独的解决方案去实现，不依赖业务数据库。

很显然，传统数据仓库无法支撑起互联网时代的商业智能。2003年，Google公布了3篇鼻祖型论文（ 俗称「谷歌三驾马车」 ），包括：分布式处理技术MapReduce，列式存储BigTable，分布式文件系统GFS。这3篇论文奠定了现代大数据技术的理论基础。

苦于Google并没有开源这3个产品的源代码，而只是发布了详细设计论文。2005年，Yahoo资助Hadoop按照这3篇论文进行了开源实现，这一技术变革正式拉开了大数据时代的序幕。

Hadoop相对于传统数据仓库，有以下优势：

随着Hadoop技术的成熟，2010年的Hadoop世界大会上，提出了「 数据湖 」的概念。

关于数据湖的理论，大家可以看我的这篇博客。

商用Hadoop包含上十种技术，整个数据研发流程非常复杂。为了完成一个数据需求开发，涉及到数据抽取、数据存储、数据处理、构建数据仓库、多维分析、数据可视化等一整套流程。这种高技术门槛显然会制约大数据技术的普及。

此时，大数据平台（平台即服务的思想，PaaS）应运而生，它是面向研发场景的全链路解决方案，能够大大提高数据的研发效率，让数据像在流水线上一样快速完成加工，原始数据变成指标，出现在各个报表或者数据产品中。

2016年左右，已经属于移动互联网时代了，随着大数据平台的普及，也催生了很多大数据的应用场景。

此时开始暴露出一些新问题：为了快速实现业务需求，烟囱式开发模式导致了不同业务线的数据是完全割裂的，这样造成了大量数据指标的重复开发，不仅研发效率低、同时还浪费了存储和计算资源，使得大数据的应用成本越来越高。

极富远见的马云爸爸此时喊出了「 数据中台 」的概念，「One Data，One Service」的口号开始响彻大数据界。 数据中台的核心思想是：避免数据的重复计算，通过数据服务化，提高数据的共享能力，赋能业务。

关于阿里数据中台，可以参考这篇转载自 谭虎、陈晓勇老师 的：

大数据的概念比较抽象，而大数据技术栈的庞大程度将让你叹为观止。

大数据技术的体系庞大且复杂，基础的技术包含数据的采集、数据预处理、分布式存储、NoSQL数据库、数据仓库、机器学习、并行计算、可视化等各种技术范畴和不同的技术层面。首先给出一个通用化的大数据处理框架，主要分为下面几个方面： 数据采集与预处理、数据存储、数据清洗、数据查询分析和数据可视化。

通过上述的内容，可能大家对大数据都有了初步的了解，接下来就是核心的部分，因为任何学习过程都需要一个科学合理的学习路线，才能够有条不紊的完成我们的学习目标。大数据所需学习的内容纷繁复杂，难度较大，有一个合理的大数据学习路线图帮忙理清思路就显得尤为必要。

以Java语言为基础掌握面向对象编程思想所涉及的知识，以及面向对象编程，然后主流的SSM、Spring Boot等开源框架最好也能掌握。

MySQL数据库掌握关系型数据库的原理，主要是各种复杂SQL语句的编写，这会对后面学Hive数仓的HQL起到事半功倍的效果。

因为大数据相关软件都是在Linux上运行的，所以Linux要学习的扎实一些，学好Linux对你快速掌握大数据相关技术会有很大的帮助，能让你更好的理解Hadoop、Hive、HBase、Spark等大数据软件的运行环境和网络环境配置，能少踩很多坑，学会Shell就能看懂脚本这样能更容易理解和配置大数据集群。

这是现在流行的大数据处理平台几乎已经成为大数据的代名词，所以这个是必学的。Hadoop里面包括几个组件HDFS、MapReduce和Yarn。

HDFS是存储数据的地方就像我们电脑的硬盘一样文件都存储在这个上面，MapReduce是对数据进行处理计算的，它有个特点就是不管多大的数据只要给它时间它就能把数据跑完，但是时间可能不是很快所以它叫数据的批处理。Yarn是体现Hadoop平台概念的重要组件有了它大数据生态体系的其它软件就能在Hadoop上运行了，这样就能更好的利用HDFS大存储的优势和节省更多的资源，比如我们就不用再单独建一个Spark的集群了，让它直接跑在现有的HadoopYarn上面就可以了。

4.1 学会百度与Google

不论遇到什么问题，先试试搜索并自己解决。Google首选，翻不过去的，就用百度吧。

4.2 参考资料首选官方文档

特别是对于入门来说，官方文档永远是首选文档。相信搞这块的大多是文化人，英文凑合就行，实在看不下去的，请参考第一步。

4.3 先让Hadoop跑起来

Hadoop可以算是大数据存储和计算的开山鼻祖，现在大多开源的大数据框架都依赖Hadoop或者与它能很好的兼容。

关于Hadoop,你至少需要搞清楚以下是什么：

Hadoop 1.0、Hadoop 2.0 MapReduce、HDFS NameNode、DataNode
JobTracker、TaskTracker Yarn、ResourceManager、NodeManager

自己搭建Hadoop，请使用第一步和第二步，能让它跑起来就行。建议先使用安装包命令行安装，不要使用管理工具安装。另外：Hadoop1.0知道它就行了，现在都用Hadoop 2.0。

4.4 试试使用Hadoop

HDFS目录操作命令；上传、下载文件命令；提交运行MapReduce示例程序；
打开Hadoop WEB界面，查看Job运行状态，查看Job运行日志。知道Hadoop的系统日志在哪里。

4.5 你该了解它们的原理了

MapReduce：如何分而治之；HDFS：数据到底在哪里，什么是副本；Yarn到底是什么，它能干什么；NameNode到底在干些什么；ResourceManager到底在干些什么；

4.6 自己写一个MapReduce程序

请仿照WordCount例子，自己写一个（照抄也行）WordCount程序，打包并提交到Hadoop运行。你不会Java？Shell、Python都可以。如果你认真完成了以上几步，恭喜你，你的一只脚已经进来了。 呐，下面是我Hadoop专题的系列博客，希望能帮助到你打怪兽哈！ …(*￣０￣)ノ

这个东西对于会SQL语法的程序猿来说简直就是神器，它能让你处理大数据变的很简单，不会再费劲的编写MapReduce程序。

通过前面的学习，我们已经了解到了，HDFS是Hadoop提供的分布式存储框架，它可以用来存储海量数据，MapReduce是Hadoop提供的分布式计算框架，它可以用来统计和分析HDFS上的海量数据，而Hive则是SQL On Hadoop，Hive提供了SQL接口，开发人员只需要编写简单易上手的SQL语句，Hive负责把SQL翻译成MapReduce，提交运行。

简单点来说就是，Hive的底层是MapReduce，你只要写HQL（和SQL差不了多少）就完事了！ Σ(っ °Д °;)っ

Sqoop主要用于把MySQL里的数据导入到Hadoop里的。当然你也可以不用这个，直接把MySQL数据表导出成文件再放到HDFS上也是一样的，当然生产环境中使用要注意MySQL的压力。

Flume是一个分布式的海量日志采集和传输框架，因为“采集和传输框架”，所以它并不适合关系型数据库的数据采集和传输。Flume可以实时的从网络协议、消息系统、文件系统采集日志，并传输到HDFS上。因此，如果业务有这些数据源的数据，并且需要实时的采集，那么就应该考虑使用Flume。

阿里开源的DataX也非常好用，有兴趣的可以研究和使用一下。

其实大家都已经发现Hive后台使用MapReduce作为执行引擎，实在是有点慢。Spark SQL 应运而生，它是用来弥补基于MapReduce处理数据速度上的缺点，它的特点是把数据装载到内存中计算而不是去读慢的要死进化还特别慢的硬盘。

特别适合做迭代运算，所以算法流们特别稀饭它。它是用scala编写的。Java语言或者Scala都可以操作它，因为它们都是用JVM的。

你还需要：

是不是有些慌张，哈哈哈，慢慢学啊，Spark 超级重要！（；´д｀）ゞ

这是个比较好用的队列工具，队列是干吗的？排队买票你知道不 ？数据多了同样也需要排队处理，这样与你协作的其它同学不会叫起来，你干吗给我这么多的数据（比如好几百G的文件）我怎么处理得过来。

你别怪他因为他不是搞大数据的，你可以跟他讲我把数据放在队列里你使用的时候一个个拿，这样他就不在抱怨了马上灰流流的去优化他的程序去了，因为处理不过来就是他的事情，而不是你给的问题。 ㄟ( ▔, ▔ )ㄏ

这时，使用Flume采集的数据，不是直接到HDFS上，而是先到Kafka，Kafka中的数据可以由多个消费者同时消费，其中一个消费者，就是将数据同步到HDFS上。

目前 Flume + Kafka，在实时流式日志的处理非常常见，后面再通过Spark Streaming等流式处理技术，就可完成日志的实时解析和应用。

不仅仅是分析任务，数据采集、数据交换同样是一个个的任务。这些任务中，有的是定时触发，有点则需要依赖其他任务来触发。当平台中有几百上千个任务需要维护和运行时候，仅仅靠crontab远远不够了，这时便需要一个调度监控系统来完成这件事。调度监控系统是整个数据平台的中枢系统，类似于AppMaster，负责分配和监控任务。

在前面讲Kafka的时候提到了一些需要实时指标的业务场景，实时基本可以分为绝对实时和准实时，绝对实时的延迟要求一般在毫秒级，准实时的延迟要求一般在秒、分钟级。

对于需要绝对实时的业务场景，用的比较多的是Storm，对于其他准实时的业务场景，可以是Storm，也可以是Spark Streaming，简单业务场景 Kafka Streams 也能搞定，当然现在最火的是Flink 。

是不是晕了，这么多流式处理框架，我该怎么选择呢？::>_<::

离线：比如，每天将前一天的数据提供到指定的数据源（DB、FILE、FTP）等；离线数据的提供可以采用Sqoop、DataX等离线数据交换工具。

实时：比如，在线网站的推荐系统，需要实时从数据平台中获取给用户的推荐数据，这种要求延时非常低（50毫秒以内）。

根据延时要求和实时数据的查询需要，可能的方案有：HBase、Redis、MongoDB、ElasticSearch等。

分布式数据库HBase，这是Hadoop生态体系中的NOSQL数据库，它的数据是按照key和value的形式存储的并且key是唯一的，所以它能用来做数据的排重，它与MySQL相比能存储的数据量大很多。所以他常被用于大数据处理完成之后的存储目的地。

了解MongoDB及其它分布式数据库技术，能够掌握分布式数据库原理、应用场景、HBase数据库的设计、操作等，能结合Hive等工具进行海量数据的存储于检索。

OLAP分析：OLAP除了要求底层的数据模型比较规范，另外，对查询的响应速度要求也越来越高，可能的方案有：Impala、Presto、SparkSQL、Kylin。如果你的数据模型比较规模，那么Kylin是最好的选择。

即席查询：即席查询的数据比较随意，一般很难建立通用的数据模型，因此可能的方案有：Impala、Presto、SparkSQL。

这么多比较成熟的框架和方案，需要结合自己的业务需求及数据平台技术架构，选择合适的。原则只有一个：越简单越稳定的，就是最好的。

在我们的业务中，遇到的能用机器学习解决的问题大概这么三类：

入门学习线路：

机器学习确实牛逼高大上，也是我学习的目标。

至此，可以把机器学习部分也加进你的“大数据平台”了。

数据仓库是从业务角度出发的一种数据组织形式，它是大数据应用和数据中台的基础。数仓系统一般采用下图所示的分层结构。

按照这种分层方式，我们的开发重心就在dwd层，就是明细数据层，这里主要是一些宽表，存储的还是明细数据；到了dws层，我们就会针对不同的维度，对数据进行聚合了，按道理说，dws层算是集市层，这里一般按照主题进行划分，属于维度建模的范畴；ads就是偏应用层，各种报表的输出了。

首页，收下一本看书学习指南