大数据技术综述
首先，在学习大数据之前，需要了解什么是大数据？它是如何诞生的？它有哪些应用场景？只有了解了这些，才能窥视大数据的技术全貌。一个技术的诞生，是顺应时代的，是用于解决某些问题的，它的发展也一定是有内在逻辑的。接下来，一起去看看。
诞生背景
传统数据处理架构
在大数据诞生之前，对数据的处理技术就已经被很广泛的应用了。数据一般被分为结构化数据、半结构化数据、非结构化数据。
对于结构化数据的处理，传统的数据处理方式是由数据库、数据仓库负责存储，使用SQL（结构化查询语言）进行处理。
而非结构化、半结构化数据，传统的处理方式是由NoSQL数据库负责数据存储，但处理时，一般使用并发程序将数据读取后进行处理。
大数据背景下存在的问题
传统数据处理架构，能满足在一定数据规模下的处理效率。但在移动互联网快速发展的背景下，数据的量级也在不断的提升。
在数据规模超过一定量级后，传统数据处理架构便暴露出来一些问题。
首先是结构化数据，海量数据下，单节点数据库显然已经无法支撑；但由单节点数据库通过改变架构方式，组成的MPP集群，虽然能解决燃眉之急，但因为其扩展性和热点问题，无法满足日益增长的数据处理需要。
非结构化、半结构化数据，它本身就存在一些问题。因为传统的NoSQL数据库一般只负责数据存储，提供良好的查询性能。但对于这类数据，用途较为灵活、广泛，在做数据处理时，需要编写额外的并发程序，先从NoSQL数据库中读取数据，然后再进行自定义处理。这种处理模式下，会涉及到大量的数据移动，对于磁盘和网络都是很大的消耗，进而影响处理效率。
那是否存在一套整体的解决方案，即可以存储并处理海量结构化、半结构化、非结构化数据；并且在处理海量数据的速度很快，且扩展性可以适应数据规模的不断增长？
答案是肯定的，这就是大数据技术要解决的问题。
大数据的基本特征
什么是大数据？大数据是一种在海量数据规模下，满足数据存储与运算的一种技术。
一提到大数据，必然会提到大数据的四个特征。数据量、速度、多样性、价值。
第一个特征：数据规模巨大（Volume）；这也是大数据的字面意思，能够对大规模数据进行存储和运算。在企业中，至少是TB、PB级别以上。像仅仅是2018年，携程平台就已经拥有50PB规模的数据，而且还在不断增长。
但这也是一个提示，最好数据量达到一定规模的企业，再考虑大数据技术，否则大数据这种原生为大规模数据处理而生的技术，在中小规模数据上的效率并不高；海量数据才是它的应用场景。
但终归来说，在互联网快速发展的现代，企业的数据量终究会达到某个量级，所以大数据一定是未来的一个趋势。
第二个特征：生成和处理速度极快（Velocity）；摩拜单车在2017年，数据日增量为30TB；携程在2018年，数据的日增量就已经达到400TB。在大数据场景下，数据的生成速度是极快的，那生成的这些数据，也必然要在规定的时间内处理完成。比如金融行业，对当日数据，必须在第二天营业前处理完成，否则数据无法到达业务系统，业务也无法正常展开。所以大数据技术的处理速度一定是远超传统的数据处理方式，以满足企业需要。
所以速度这个特征，有两个维度，第一是生成速度快，第二是处理速度快。
第三个特征：数据类型多样（Variety），对于传统数据分析领域，主要面向的是结构化数据处理，使用SQL来进行。而在大数据领域，处理的数据除了结构化数据，还包括非结构化、半结构化数据，非结构化数据常见的有视频、图像，而半结构化数据则是日志、json等。
所以大数据背景下，数据的多样性是一个挑战。而且非结构化、半结构化数据，因为本身大小原因，在所有数据中占较高的比重。而大数据技术可以完成对这些多样化数据的存储于处理。
第四个特征：价值巨大但密度较低（Value），传统的数据分析，主要对数据进行处理、可视化，最终形成报表等形式，辅助企业进行决策。这种方式，是对过去的数据进行总结，吸取经验。而在海量数据规模下，使用人工智能方式进行处理，却能发现其中的规律，进行预测，预测用户的喜好，预测未来的情况。
这说明，在海量数据场景下，数据蕴含的价值是巨大的；但 价值密度 = 价值 / 总数据量 ，因为总数据量是海量的，所以密度被稀释了，所以说大数据的价值巨大，但密度较低。
最后，附上一句权威的大数据定义，与大家共勉：
应用场景
大数据的应用场景分为两种，离线处理场景和事实处理场景。
离线处理与实时处理的本质，其实并不是速度快慢的不同；而是离线处理时，数据需要先落地（存储到磁盘），然后再对数据进行处理，处理方式一般选择批处理技术，最后将处理结果保存起来。
而实时处理，数据不需要落地（存储到磁盘），便直接进行处理，处理方式一般采用流式处理，然后将处理结果进行存储。
因为离线处理的数据需要先落地，所以整体体现出来的延迟就高一些。但并不是放之四海皆准，因为有时候微批处理这种离线方式，在吞吐量大的情况下，反而比实时处理速度要快。
其中离线处理场景包括数据仓库、搜索与检索，而实时处理场景包含实时流处理。
基于大数据的数据仓库
离线处理场景的典型应用是数据仓库，但基于大数据的数据仓库与传统意义上的数据仓库有本质的区别。
传统数据仓库，数据源是业务数据库端的结构化数据，将它们定期抽取汇总到一起，然后再对数据进行处理、可视化。当单节点架构满足不了需求，便逐渐发展为MPP（大规模并行处理）这种集群模式。但MPP模式，它本质上是单机架构经过一定的改造形成的，本身存在扩展性、热点问题，所以在数据量达到一定规模之后，处理性能便成为了瓶颈。
而基于大数据的数据仓库，它诞生之初就是为了海量数据处理而设计的架构，是纯天然的分布式架构，处理模式更为粗狂；注重移动计算而非移动数据的设计理念。所以它并不会有传统数据库架构所带来的限制，数据源支持结构化，也支持非结构化、半结构化数据，因为它粗狂的模式可以直接将数据单纯的看做文件进行保存；而数据进行存储时，对文件进行切分，并分布式存储。
大数据的数据仓库，在进行计算任务时，因为海量数据的移动会耗费大量的资源；所以会将计算任务拆分，并分发到数据节点进行运算，这也体现了移动计算而非移动数据的理念。那各个节点计算出来的结果必然是部分结果，于是额外需要一个过程将部分结果合并，但此时数据移动的开销就少很多了，因为仅涉及到结果的汇总。
在大数据技术中，将大任务拆分，分发到数据节点进行运算的行为称为Map；而将各个Map节点的部分结果进行汇总，这个行为称为Reduce。
所以大数据的数据仓库，因为底层存储和计算方式较为粗犷，所以它扩展性强，天然适合大规模数据的处理。但也正是因为这样，它在小数据规模下效率很低，因为文件拆分存储、任务拆分调度等过程，会占用大量时间；这些过程占用的时间远大于数据处理时间时，它的效率当然会大打折扣，但调度过程占用的时间远小于数据处理时间时，它的威力才会显示出来。
基于大数据的搜索与检索
传统搜索与检索，一般是将数据存储到结构化数据库、NoSQL数据库中，通过数据库支持的语法（SQL、API）进行数据查询，并在此基础上可能会使用程序进行进一步筛选。但此种方式因为受限于数据库端的功能，一般只能实现模糊匹配、正则匹配，而且在大规模数据集中，查询效率会因为瓶颈而降低。
而在大数据搜索与检索中，首先是分布式文件存储可以满足海量数据存储的要求；其次因为计算任务是分发到数据节点进行计算的，所以它没有传统数据库的限制，更为灵活，可以自定义计算任务，从而实现很丰富的功能，如语义匹配。而且在大数据产品中，有如ElasticSearch这种开箱即用的搜索与检索的产品，极大的降低了开发难度，可以完成大规模数据的搜索检索任务。
基于大数据的实时流处理
在实时场景中，因为对低延迟的实时性要求，数据不落地而直接进行处理，对数据处理的效率、安全性、可靠性有极大的挑战。
在大数据的实时流处理技术中，它将传统的流处理技术转换成了分布式运算，而且保证了数据的处理效率，提升了数据的安全性、可靠性，极大的降低了开发难度。
在大数据的实时计算过程中，数据源是实时产生数据的，这些实时产生的数据首先要进入到分布式消息队列中，然后再由分布式流集群从消息队列中获取数据进行分布式处理，最后将运算结果保存到数据库中。
不是说数据不落地吗？为什么要进入到分布式消息队列中？
首先分布式队列的吞吐很高，甚至于内存相当，如知名的Kafka集群，单条消息1KB，每个节点的吞吐量可以达到10W/S，所以进入分布式消息队列近乎于不落地，实时性有很好的保障。
其次分布式消息队列在这里起到了两个作用：解耦合、削弱峰值。
假设现有ATM机、POS机的实时数据，这些数据如果直接发送到分布式流集群中进行运算，耦合度很高，那么如果分布式流集群出现问题，数据就可能存在丢失情况；同样，ATM、POS的功能升级也会变得相当麻烦，而且可能存在泄漏分布式流集群信息的情况。再一个，ATM、POS机可能有成千上万台，这些数据流推送到流集群中进行处理，对于运维管理也是一个大的挑战。
所以增加分布式消息队列，与后台分布式流集群解耦合；而且分布式消息队列是可以设置消息主题，对消息进行分类存储，比如消息队列中设置了ATM和POS机两个主题队列，那么所有ATM机的数据就直接推送到ATM主题队列中，而POS机数据则推送到POS机主题队列中，这样减轻了对数据流运维管理的负担。
而且在互联网场景中，实时数据的流量会不定期出现峰值，比如著名的双十一、春运12306购票，这些海量的峰值数据在某一个时刻如果直接传到分布式流集群中，可能会直接导致流集群宕机，从而致使数据丢失等问题出现。为了避免这种情况发生，数据先进入到高吞吐的分布式消息队列中进行缓冲，消息队列先减缓了压力，然后分布式流集群再按照自己的处理能力按需从消息队列获取数据进行运算。
分布式消息队列的扩展性很强，吞吐量也非常大，所以在削弱峰值场景中起到了重要的作用。
数据经过分布式消息队列之后，便交由分布式流集群进行分布式实时运算，然后最终将运算结果存储起来；存储结果的数据库集群，需要满足实时读写性能出色的特性，因为每一批的数据在处理时可能会用到上一批数据的处理结果，所以需要保证结果写入后就可以立即读取，以满足实时流处理的需要。
编年史
不了解大数据的历史，就没有真正掌握大数据。接下来，一起看一下开源大数据的发展历程，看它是如何顺应时代而诞生的。
发展初期
首先在2002年的时候，Doug Cutting、Mike Cafarella创建了开源网页爬虫项目Nutch，而爬虫的特征就是源源不断的爬取数据，那这样就急需一种解决方案来存储这些海量的数据，并且可以随着数据量的增长而扩展。
恰好在第二年（2003年），Google发表了Google File System论文，论述的就是一种新型的分布式文件系统，可以满足海量数据的存储。
于是2004年，Doug Cutting、Mike Cafarella在Nutch中实现了GFS的功能，这就是著名的HDFS（Hadoop Distributed File System）的前身。
但数据存储起来之后，只有经过处理运算，才能发挥其应有的作用。在2004年07月，Google发表了MapReduce论文，论述了如何在分布式文件系统GFS上进行分布式运算。
依然是第二年，Mike Cafarella在Nutch中实现了MapReduce的功能。
至此，其实大数据就已经初具成型了，因为海量数据的存储有了，在数据存储之上的分布式运算也解决了，接下来就等待这两种技术的逐渐成熟。之后，有一个公司，为开源大数据打了一针强心剂，引领了大数据的发展。
2006年，Doug Cutting加入Yahoo，将Hadoop（HDFS MapReduce）发展成一个可在网络上运行的系统；在Yahoo的推动下，Apache Hadoop项目正式启动，并支持MapReduce和HDFS独立发展。同年，Yahoo的网格计算团队采用Hadoop技术；而且Yahoo建立了第一个用于开发的Hadoop集群。此时，Yahoo已经开始将Hadoop技术在生产环境中进行淬炼，逐渐将它推向成熟。
2006年04月，第一个Apache Hadoop版本发布，标志着Hadoop正式走进开发者的视野。
2006年11月，Google发表了Bigtable论文，阐述了如何在分布式文件系统上，实现NoSQL数据库。后来Google的GFS、MapReduce、Bigtable论文也被称为Google的三驾马车，它极大的推动了开源大数据的进程。但其实仔细想想，在大数据未开源之前，Google才是真正的大数据先行者。
发展时期
Yahoo将Hadoop大数据技术推向社区之后，便逐渐将Hadoop技术推向正式的生产环境。2007年04月，Yahoo Hadoop集群发展成两个1000个节点的集群；2008年01月，Hadoop成为Apache的顶级项目；2008年02月，Yahoo运行了世界最大的Hadoop应用，宣布其搜索引擎产品部署在一个拥有一万个内核的Hadoop集群上。这也意味着，Hadoop技术已经逐渐稳定并走向成熟。
在此之后，2008年到2012年，是Hadoop生态圈百花齐放的景象，围绕着分布存储HDFS、分布式计算MapReduce，各种在海量数据规模下的解决方案层出不穷。开源大数据的生态得到了极大的发展。
在此期间，也就是2008年08月，第一个Hadoop商业化公司Cloudera成立。既然Hadoop是开源产品，那为何会有商业化公司成立？商业化就意味着付费。其实是因为Hadoop各个框架是由不同开发组去维护的，并不是统一开发的，所以这些框架之间的整合会有一些问题（如依赖冲突）；而且大数据集群环境在运维过程中，会比较麻烦；而这些痛点，也就是Cloudera的商机。它在2009年推出的Hadoop发行版CDH，至今依然是Hadoop学习时，环境安装最好的推荐，只需要安装同一个CDH版本，大数据框架之间的整合便不会存在问题。
成熟期
在Hadoop诞生时期，因为硬件成本的原因，内存造价很高；所以分布式处理框架MapReduce在设计时，为了节约内存，会与磁盘进行大量的交互。但随着硬件成本的降低，这种设计反而成为限制分布式处理速度的瓶颈。于是在2014年，Spark诞生了，它基于内存设计，大量使用内存空间，使得分布式处理的速度得到了极大的提升，成为Hadoop的缺省计算引擎；意味着分布式计算框架，可以选择MapReduce或者Spark。
而分布式存储HDFS也存在一些诟病，主要是设计陈旧、延时较高。但其实在大数据处理领域，离线批处理场景更重视处理速度和吞吐；而实时流处理场景，最终的数据结果也会存储到分布式数据库中（如HBase），并不直接存储在分布式文件系统中，而建立在分布式文件系统上的分布式数据库的延迟一般都很低。
在2015年10月，Cloudera公布了继HBase以后的第一个Hadoop原生存储替代方案——Kudu，它也是主要依托于内存，提升了分布式文件系统的速度，并提供了很多优秀的功能。
现在，大数据依然在随着时代继续发展，未来的大数据是什么样的，请拭目以待吧。
小结
这一节主要讲了大数据的诞生背景，还有它的基本特征、应用场景，最后讲述了大数据的编年史，希望大家在阅读之后，对大数据有一个更清晰的认知。
