大数据架构和技术链分析

一、概述
当下，互联网+、云计算、大数据、O2O、可穿戴智能设备……一个个热词扑面而来。信息技术的变革已经渗透到当今每一个行业和业务职能领域，改变着我们的生活乃至思维方式。
乱花渐欲迷人眼，当我们抛开各种炒作，各种软文，各种轰炸，一层一层剥开这些“洋葱”时，总会发现数据的身影。人们渴望通过海量数据的挖掘和运用，释放出其所蕴含的巨大价值。
据报道，2014年，国家统计局与阿里巴巴、百度在内的17家大数据企业签署大数据战略合作框架协议。在生产资料价格统计、CPI调查、贸经统计、建设领域统计、交通运输统计等领域，广泛利用网上公共平台搜集、整理数据。
大数据绝对算得上是当今技术密集度最高的产业之一，由众多的框架、产品、组件、算法组成，或资深或初创的大小公司活跃其中。各种概念满天飞，初入行的技术人员特容易钻到技术的大海里，摸不清方向。而大数据的使用者，如政府或企业客户，却不知所云，一头雾水。
本文主要从技术的角度，首先介绍一下大数据的产生，再分析一下大数据架构Hadoop。最后从大数据技术生态链（采集、存储、计算、分析、可视化）的角度，介绍一下每个环节可用的技术选择。
二、大数据的产生
传统的企业级应用中，数据的存储和计算主要是使用关系型数据库RDBMS，以oracle、sql server为代表的数据库产品以优秀的事务性、可靠性、安全性，支撑起日常业务处理所对应的频繁的增删改查和报表统计、BI分析。当时数据量较小，运行多年的系统积累的数据可能也就几T。RDBMS运行速度也是有保障的。
随着互联网的兴起，数据规模不断增长，数据格式丰富多彩。竞争的加剧也导致管理者需要做更多的用户研究、提供更好的用户体验。更多的数据需要更大的存储空间。而更高的数据计算量、分析时效性，则需要分布式计算来解决。同时，适当的价格也是重要的因素，比如在以往处理大量数据，可选的方案有IBM的大型机，目前银行系统还有很大一部分在使用大型机上，但价格昂贵。
另外对数据的处理方式也发生了重大变化，传统的RDBMS关注的是数据的变化，即数据的增加、删除和修改。而在大数据时代，数据的作用更多的是分析和挖掘其价值，即一次写入、多次读取（分析）。
时势造英雄。 Google 在 2003 年开始陆续公布了关于 GFS、MapReduce 和 BigTable三篇技术论文,成为大数据发展的重要基石,开启了大数据时代。
三、大数据架构Hadoop
Hadoop得以大行其道，乃至成为大数据的代名词，主要得益于以下几点：
（1）解决实际问题。Hadoop核心要解决的问题是海量数据的存储和分析，即：如何使用廉价的设备支持高速增长的数据存储，Hadoop设计了分布式文件系统HDFS。如何高效的从海量数据中提取出有价值的信息，Hadoop提出了分布式并行计算架构MapReduce。
（2）成本低
硬件成本：Hadoop是架构在廉价的PC服务器上，无需采购昂贵的专用服务器做支撑。
软件成本：开源产品，只要遵守其协议，可免费使用、自由修改，可控性强。
开发成本：基于开源产品的二次开发，同时有非常活跃的社区讨论，学习和开发成本不高。
（3）成熟的生态圈。国内外IT巨头，如Google、IBM、Intel，国内的BAT等，都投入其中，并且贡献了大量成熟的开源、免费产品，共同推动着大数据技术的发展和应用。
（4）起步早。这也是一个很重要的因素，具有先发优势。
先看一个实际应用案例，感受一下Hadoop的威力。下图是淘宝网实际使用Hadoop的情况：

Hadoop应用实例
我们常去的购物网站的背后就有这位“老黄牛”的耕耘，有所触动吗？下面我们了解一下这个神奇的存在：
Hadoop是一个由Apache基金会所开发的分布式计算平台。用户可以使用Hadoop框架提供的各组件开发和运行处理海量数据的应用程序。到现在已超过10年的发展历史。截止到发文时，最新版本是2.7。

Hadoop2框架图

Hadoop体系结构图

Hadoop本身是一个庞大的项目家族，其核心成员是HDFS和MapReduce。其它的项目，例如Hive、HBase等都是基于HDFS和MapReduce，是为了解决特定类型的大数据处理问题而提出的子项目。Hadoop的其它子项目还包括Common, Avro, Pig, ZooKeeper, Sqoop, Oozie 等，随着时间的推移一些新的子项目会被加入进来，一些关注度不高的项目会被移除Hadoop家族，不断更新，充满活力。
Hadoop已经发展出了比较完整的大数据生态系统，包括了分布式文件系统HDFS、分布式数据库Hbase、分布式计算架构MapReduce、分布式集群管理和任务调度系统YARN、Common组件等。其中最核心的设计就是HDFS和MapReduce。分别介绍如下：
HDFS：提供了一种跨服务器的弹性数据存储系统。一台机器放不下的数据，用多台机器来解决，分而治之。
MapReduce：大规模分布式计算服务。通俗的说就是将任务切分为若干份小任务，并分配到不同的处理节点，由集群的每台服务器来计算，最后把结果合并。因此具有更强的并行处理能力。
YARN：Hadoop2.0的主要变化是将旧版本 MapReduce 中的任务调度和资源管理功能分离，形成一层与任务无关的资源管理层（YARN）。YARN 对下负责物理资源的统一管理，对上可支持批处理、流处理、图计算等不同模型。几乎所有常用的应用程序和框架，比如MapReduce、Storm和Spark等，均可运行在YARN之上。
Hadoop Common: Hadoop的基础库。
Hadoop 还包含了其它一些技术，如Hive、Pig、Hbase 、Sqoop、ZooKeeper等。
Hive：基于MapReduce的数据仓库基础构架。它提供了一系列的工具，用来进行数据提取、转化、加载，实际上是基于MapReduce的一个应用。它提供了类似于SQL的查询语言，通过使用该语言，可以方便地进行数据存储，查询和分析。
Hive将元数据存储在RDBMS中，一般为mysql、Derby。Hive中的所有数据都存储在HDFS中。
Pig：它与Hive有类似之处， 但更简单。目前应用已经很少。
Hbase：一种分布的、可伸缩的、大数据储存库，支持随机、实时读/写访问。将文件建于HDFS上的分布式Key-Value数据库
Sqoop：为高效传输批量数据而设计的一种工具，其用于Apache Hadoop和关系数据库之间的数据传输。
ZooKeeper：分布式应用程序协调服务,用于维护配置信息，命名服务，提供分布式同步，以及提供分组服务。
Oozie是一个工作流调度工具,用于运行MapReduce和Pig 任务工作流，把多个MapReduce作业连接到一起。类似的还有Azkaban,操作比Oozie要简单很多而且非常直观,提供的功能比较简单。
四、大数据技术链
在大数据技术领域，除了Apache基金会主导的Hadoop、Spark框架之外，很多公司都贡献了大量的开源产品。其中很多产品在性能方面已经超越了Hadoop家族中的某一产品，非常值得考察和使用。目前，业界也基本上都是优选组合使用。下面从技术链着手，分别介绍优秀的产品。
1、数据采集
应用场景：
很多公司的平台每天都会产生大量日志（一般为流式数据，如用户行为：访问量，搜索关键词、用户点击记录等）。这些数据很有商业价值，比如对搜索关键词加以分析，可以看出用户的喜好、倾向，进而调整商业策略。快速有效的将分散在各个服务器上的日志数据汇总和分析，已成为网站运营的重要环节。
知名产品：
Flume：Cloudera提供的一个高可用的，高可靠的，分布式的海量日志采集、聚合和传输的系统。支持在日志系统中定制各类数据发送方，用于收集数据。同时，Flume提供对数据进行简单处理，具备定制写入各种数据接受方(可定制)的能力。目前是Apache下的孵化项目，受到了业界的认可与广泛应用。
Scirbe：Facebook开源项目，具备高扩展性和高容错能力。
Chukwa：Apache开源项目，用于Log日志收集与分析，建立在Hadoop至上。
TimeTunnel：淘宝开源实时数据传输平台。基于thrift通讯框架搭建，具有高性能、实时性、顺序性、高可靠性、高可用性、可扩展性等特点（基于Hbase）。目前TimeTunnel在淘宝广泛的应用于日志收集、数据监控、广告反馈、量子统计、数据库同步等领域。
上述这些工具均采用分布式架构，能满足每秒百MB的日志数据采集和传输需求。
2、数据存储
大数据存储主要分为分布式文件系统存储HDFS和NoSQL数据库存储。HDFS前面已有介绍。本部分重点介绍NoSQL数据库。
应用场景：
关系数据库虽然很强大，但是它并不能很好的应付所有的应用场景。典型的缺点为扩展性差（需要复杂的技术来实现），大数据下IO压力大，表结构更改困难。很多WEB实时系统并不要求严格的数据库事务管理，有些场合对读、写一致性的要求不高，关系型数据库的事务管理反而成为高负载下的沉重的负担。
在这种情况，一种新的存储思路NoSQL应运而生。NoSQL泛指非关系型数据库。具备高扩展性、大数据量、高性能、高可用和灵活的数据格式。
NoSQL数据库种类众多，不同的应用场景可以选择不同的NoSQL数据库。
知名产品：
主要有四类：键值数据库、列式数据库、文档数据库和图形数据库。
Key-Value键值数据库：数据以键值的形式存储的，速度非常快。根据数据的保存方式可以分为临时性（内存）、永久性（硬盘）和两者兼具三种。
Redis：临时性和永久性兼具。Redis首先把数据保存在内存中，在满足特定条件的时候将数据写入到硬盘中，这样既确保了内存中数据的处理速度，又可以通过写入硬盘来保证数据的永久性，这种类型的数据库特别适合处理数组类型的数据。
列式数据库：
关系型数据库是以行为单位来存储数据的。相反，面向列的数据库是以列为单位来存储数据的，即将同一列数据存在一起，同时擅长以列为单位读取数据。典型代表：Cassandra、Hbae。具备查找速度快，可扩展性强，更容易进行分布式扩展，主要应用于需要处理大量数据的情况。
文档数据库：
类似键值数据库。以JSON格式存储数据。对数据结构要求不严格，表结构可变，无需事先设定表结构。跟键值存储不同的是，面向文档的数据库可以通过复杂的查询条件来获取数据。典型代表：MongoDB、CouchDB。
图形数据库：
图形结构的数据库使用图形模型（节点、边线、属性）来存储数据，并且能够扩展到多个服务器上。利用图结构相关算法。比如最短路径寻址，N度关系查找，专注于构建关系图谱等。典型代表：Neo4J, InfoGrid, Infinite Graph。
3、数据计算
名称解释：
大数据计算主要有两种最常见的计算形态：批处理和流式计算。
批处理：批处理计算是先积累大量数据，存储在磁盘上（HDFS）。然后再进行数据计算（拆分和聚合等）。这种计算方式属于磁盘级计算，计算时数据在磁盘上，需要读写磁盘；这种先存储后计算的模式, 适用于对实时性要求不高, 对数据的准确性、全面性要求较高。
流式计算：流式计算是无需先存储,可以直接进行数据计算。这种计算方式属于内存级计算，数据直接通过网络导入内存。读写内存比读写磁盘速度快N个数量级。这种不存储直接计算的模式, 适用于实时性要求很高，要求计算在非常短的时延内完成。对计算结果不要求绝对精确。
这两种计算方式有个形象的比喻：批处理可以看作是桶装水，一桶桶的搬。而流式计算是用水管，预先接好，然后打开水龙头，水就源源不断地流出来了，不需要水桶存储。
流式计算和批量计算具有明显的互补特征,在多种应用场合下可以将两者结合起来使用。通过发挥流式计算的实时性优势和批量计算的计算精度优势,以满足不同应用场景下的数据计算要求。
应用场景：
流式计算：互联网服务中，每时每刻都会有大量客户进行服务请求，需要在极短的响应时间内，给出数据计算结果。比如：
在浏览网站时，根据客户的查询关键词、浏览历史、地理位置等综合语义，推荐合适的广告。
在互联网金融领域，根据客户信用卡消费记录,掌握客户的消费习惯和偏好,预测客户未来的消费需求,并为其推荐个性化的产品和服务。
微博上，当我们关注一位朋友,会准确给出新推荐朋友,以提升微博活力。
批处理：适用于离线批量计算。比如：
阶段性用户特征、行为分析。
数据密集型计算。
其它对实时性要求不高，适用放在线下计算的业务。
知名产品：
Hadoop-MapReduce：Hadoop设计之初就是为批处理式的计算任务提供支持的，属于典型的大数据批量计算架构,由HDFS分布式文件系统负责静态数据的存储,并通过MapReduce将计算逻辑分配到各数据节点进行数据计算和价值发现。
Storm：分布式实时计算系统的代表。Twitter开源产品，现属Apache顶级项目。具备可伸缩性强，每秒处理的消息量达到100 万个数据元组。健壮性强，Storm 集群较容易进行管理。高容错性，Storm 可以对消息的处理过程进行容错处理，如果一条消息在处理过程中失败，那么Storm 会重新安排出错的处理逻辑。语言无关性，任何语言的开发者都可以使用Storm。
Spark：后起之秀，受到业界强烈关注。现属Apache顶级项目。能适应批处理，迭代，流式计算。能与Hadoop很好的结合（可构建在HDFS上，使用YARN对资源进行调度）。与Hadoop最大的不同点在于，Hadoop使用硬盘来存储数据，而Spark使用内存来存储数据，后续的任务可以直接读取内存中的数据。据测试可以大大超过Hadoop(MapReduce)的运算速度。与Storm的区别在于，Spark流模块先汇聚批量数据然后进行数据块分发，而Storm是只要接收到数据就实时处理并分发。Spark是一套快速出色、可扩展能力极强且极具灵活性的开源分布式计算框架。目前稳定性还需提升，但发展迅速。

Spark架构图
4、数据分析
应用场景：
大数据的核心价值之一就是商业智能BI，对大数据进行数据分析、发现价值的应用场景比比皆是，不再赘述。
知名产品：
Hive：前面已有介绍。直接构建在Hadoop之上，虽然也提供了SQL语义，但由于Hive底层执行使用的是MapReduce引擎，仍然是一个批处理过程，难以满足查询的交互性。适用于批处理查询分析。目前应用较为广泛。
Impala：Cloudera开源产品。它提供了一种通用的SQL查询语法，能查询存储在Hadoop的HDFS和HBase中的PB级大数据。Impala采用了自己的执行引擎，把一个查询拆分分布到各个节点执行，不依赖MapReduce，不采用批处理形式处理数据。适合于实时交互式SQL查询，查询效率比Hive有很大提升。
Spark SQL：SparkSQL构建在Spark框架之上，前身是shark。与shark相比，摆脱了对hive的依赖性（可兼容Hive SQL），在数据兼容、性能优化、组件扩展方面都得到了极大提升，性能表现优异。可以通过RDD良好的扩展性, 方便的扩展Spark支持的数据源。目前数据源方面已经支持HDFS, JDBC, 数据格式支持JSON, Parquet等。
5、数据可视化
应用场景：
发现数据之美--数据可视化是科学和艺术的和谐统一。人们对单调保守的讲述方式失去兴趣，期待更加直观、高效的信息呈现形式，数据图表，立体化的动态演示等丰富的数据可视化元素让科技与形象感更加饱满；

数据可视化示意图
知名产品：
R：一款开源免费的用于统计计算和统计制图的优秀工具。具备数据操作、计算和图形展示功能。包括：有效的数据存储和处理功能，一套完整的数组（特别是矩阵）计算操作符，拥有完整体系的数据分析工具，为数据分析和显示提供的强大图形功能，一套完善、简单、有效的编程语言（R语言）。R拥有强大的社区和组件库，而且还在不断成长。但使用比较复杂，需要一定的实践过程。
D3： D3.js是一个JavaScript库，是非常流行的轻量级可视化库之一，它主要用于对数据的动态图表展示。通过HTML、SVG以及CSS，D3可以让数据展现得更加鲜活。D3使得数字的图形化展示变得异常简单。应用非常广泛。
其它比较常用的还有Processing等。
另外，业界还是一种处理数据可视化的方式，将数据计算的结果存入关系数据库，通过常规的BI工具进行数据可视化展示。
6、消息队列
应用场景：
分布式各个子系统为了减轻相互之间的依赖，需要通过消息传递来减少相互之间的耦合（解耦）。消息队列MQ就是在消息传递过程中保存消息的容器或中间件，其主要目的是提供消息路由并保障消息传递的可靠性和效率。
MQ除了解耦，还有异步通信、缓冲（削减峰值）、扩展性和冗余的作用。以缓冲为例：由于采集数据的速度和数据处理的速度不一定同步，需要添加一个消息中间件来作为缓冲。
知名产品：
Kafka：Linkedin开源项目，目前是Apache下的项目。Kafka是一种高吞吐量的分布式发布订阅消息系统，即使对TB级以上数据也能保证常数时间复杂度的访问性能。在非常廉价的商用机器上也能做到单机支持每秒100K条以上消息的传输。同时支持离线数据处理和实时数据处理。
MetaQ：淘宝开源的分布式的消息中间件，它是纯Java开发，具有高吞吐量、高可用性、适合大规模分布式系统应用的特点。MetaQ在淘宝每日有十亿级别的消息流转，在支付宝有百亿级别的消息流转，在阿里B2B也有部分应用。
其它MQ：
其它常用的MQ 有ZeroMQ、RabbitMQ、ActiveMQ、Kafka/Jafka、Kestrel、HornetQ、memcacheq、beanstalkd等。产品很多，侧重点各有不同。比如HornetQ和ActiveMQ是为了企业级应用设计的消息中间件，这类MQ的特点是对事务一致性的要求很高。而互联网应用为了处理大量请求，通常采用集群处理的方式，通常对事务一致性的要求相对较弱。具体选择时可根据场景和需求的不同，选择合适的产品。
7、数据总线
应用场景：
数据总线，顾名思义就是在各系统之间架起信息交互的中间层，将数据的变化及时通知与之相关的系统。
知名产品：
Databus：Linkedin开源项目，可以在MySQL以及Oracle数据源上捕获数据变化。当数据库发生变化时，Databus会从数据库日志中找出数据变化信息，然后通知给相关应用系统。
Wormhole：Facebook开源项目，与Databus类似。性能优异，具备高度可扩展性。据报道，在Facebook内部，Wormhole每天处理多达1T的消息，高峰时每秒超过1千万条消息。
8、数据迁移
应用场景：
数据迁移：解决异构数据源的数据迁移问题，比如关系型数据库和HDFS之间的数据相互导入导出。常见场景：将关系型数据库中的数据导入到HDFS中，进行批处理计算或其它处理后，再将计算结果导出回关系数据库。数据迁移工具可形象的比喻为：我们不生产数据，我们只是数据的搬运工。
知名产品：
Sqoop：Hadoop家族成员。是Hive、HDFS、HBase与关系数据库之间导入和导出工具。任务并行，利用MapReduce加快数据传输速度；可自动或用户自定义数据类型映射与转换。支持多种常用数据库：MySQL、Oracle、PostgreSQL。
五、结语

在历史的长河中，对未知的探索是永恒的主题之一。易经、八卦、推背图代表着传统的、高深莫测的预知智慧。而今，预测和决策走向了基于事实、科学预测的大数据时代。合作共赢，优势互补不仅是时代的主旋律，在大数据技术领域也得到了体现。在不同的应用场景下选择不同的技术组合，共同构筑坚实的大数据地基。

（作者：石在辉）