大数据平台架构及主流技术栈

互联网和移动互联网技术开启了大规模生产、分享和应用数据的大数据时代。面对如此庞大规模的数据，如何存储？如何计算？各大互联网巨头都进行了探索。Google的三篇论文 GFS(2003)，MapReduce(2004)，Bigtable(2006)为大数据技术奠定了理论基础。随后，基于这三篇论文的开源实现Hadoop被各个互联网公司广泛使用。在此过程中，无数互联网工程师基于自己的实践，不断完善和丰富Hadoop技术生态。经过十几年的发展，如今的大数据技术生态已相对成熟，围绕大数据应用搭建的平台架构和技术选型也逐渐趋向统一。

上图是目前国内各大互联网公司普遍采用的大数据平台架构和技术选型。康威定律指出，技术架构与组织架构是相匹配的（延伸阅读《从康威定律看技术管理》）。许多互联网公司的大数据平台部门的组织架构也会长成这样。大型互联网公司中，上图中的每个组件甚至都会对应一个团队。当然对于大部分公司而言，技术主要是为了解决业务问题，构建庞大的大数据平台成本太高，还是需要根据实际情况灵活设计。下面对各个组件做一个简单介绍，希望能对实际场景的技术取舍提供帮助。

数据采集

“巧妇难为无米之炊”，没有数据也就没有后面的一切，数据采集作为基础至关重要。采集的数据主要由业务系统产生，包括存储在关系型DB中的结构化数据和记录在日志文件中的半结构化数据。Sqoop用于从关系型DB中采集数据，Flume用于日志采集。实时计算由于对时效性要求比较高，它一般采用Kafka和业务系统建立实时数据通道，完成数据传输。

Sqoop是Apache的一个独立项目，始于2009年。Sqoop是一个用来将Hadoop和关系型数据库中的数据相互转移的工具，可以将一个关系型数据库（例如 ：MySQL ,Oracle ,Postgres等）中的数据导进到Hadoop的HDFS中，也可以将HDFS的数据导进到关系型数据库中。其官方地址是 http://sqoop.apache.org/。官网介绍如下：

Flume最早是Cloudera提供的日志收集系统，是Apache下的一个孵化项目。Flume是一个高可用的，高可靠的，分布式的海量日志采集、聚合和传输的系统，Flume支持在日志系统中定制各类数据发送方，用于收集数据；同时，Flume提供对数据进行简单处理，并写到各种数据接受方（可定制）的能力。其官方地址是 http://flume.apache.org/。官网介绍如下：

离线计算

离线计算是指在计算开始前已知所有输入数据，输入数据不会产生变化，且在解决一个问题后就要立即得出结果的前提下进行的计算。离线计算处理的数据是静态不变的，但是数据量非常大。因此如何存储和计算海量数据是离线计算最大的技术挑战。这也是Hadoop技术生态核心解决的问题。

HDFS是基于谷歌GFS论文实现的开源分布式文件系统，主要解决海量数据的存储问题。系统架构上，HDFS是一个典型的主从分布式架构。主节点叫NameNode，从节点叫DataNode。NameNode负责集群的全局管理，处理来自客户端的读写请求。DataNode是实际存储文件的数据块，执行来自主节点的读写命令。HDFS保证了CAP中的CP，追求强一致高吞吐设计，不适合低延迟的应用场景。此外，HDFS采用流数据模式访问和处理文件，只支持追加（append-only）的方式写入数据，不支持文件任意offset的修改。它的主要使用场景是作为数仓的底层存储系统。

离线计算的核心计算模型基于MapReduce实现。Hive用类SQL的方式，简化了MapReduce的脚本实现过程，目前已成为搭建数仓的首选工具。Spark将MapReduce对磁盘的多点I/O改为内存中的多线程实现，将中间处理数据存于内存来减少磁盘IO操作，速度比传统MapReduce快10倍。此外，Spark还支持流式计算，使它在实时计算中也占有一席之地。Presto也是完全基于内存的并行计算模型，查询性能好，但是受内存大小限制，更多用于OLAP查询。由于离线计算对时延要求不高，完全基于内存的计算支撑不起数仓大量的ETL过程，在实际场景中，ETL过程大部分还是基于Hive的HSQL实现。

实时计算

实时计算与离线计算相对应。离线计算在计算开始前已经知道所有的输入数据。实时计算在计算开始前并不知道所有的输入数据，输入数据以序列化的方式一个个输入并进行处理。实时计算过程处理的数据量不大，但是要求数据处理的速度非常快。如果说离线计算看重的是高吞吐能力，那么实时计算看重的就是快响应能力。为了实现快响应，实时计算通常会采用流计算（Stream Computing）方式。

流计算与批计算（Batch Computing）相对应，两者区别在于处理的数据粒度不同。批计算以数据块为单位进行数据处理，流计算以单条数据记录为单位进行数据处理。批处理的吞吐效率高于流处理，但是由于数据到达不会立即处理，所以延迟比流处理要高。批处理主要用于离线计算，流处理主要用于实时计算。但这不是绝对的，实时计算有时为了提高吞吐率，也会牺牲一些延时，比如Spark Streaming采用微批量（micro-batch，spark中称为Discretized Stream）的方式进行实时计算。除Spark外，Storm和Flink也是主流的实时计算框架，它们都是基于Native Streaming实现，延迟（latency）非常低，Storm在几十毫秒级别，Flink在百毫秒级别。

Flink计算的主流方向被定位成流计算，但它和Spark一样是流批一体的。Spark用批模拟流实现流计算，Flink用流模拟批来支持批处理。与Storm和Spark相比，Flink最大的优势在于它实现了有状态（Stateful）的计算，这个能力让它可以提供Exactly-Once语义保证，大大提高了程序员的编程效率。在众多的流计算框架中，Flink是最接近 Dataflow 模型的流计算框架，业内评价它是继Spark之后的第四代大数据计算引擎。现在国内互联网公司，包括BAT和TMD都选择了Flink。

除了计算问题外，对于实时计算还有一个很重要的问题：如何建立实时输入的数据流通道。
Kafka就是解决这个问题的最佳利器技术选型上，经常会拿Kafka跟MQ中间件（比如RabbitMQ、RocketMQ）进行比较。但Kafka设计的初衷是做日志统计分析，不是以可靠消息传输为设计目标。比如Kafka中消息可能会重复或乱序，它也不支持事务消息等。​另外，Kafka采用批处理的方式传递消息，吞吐量高，但会有延迟，时效性不如MQ中间件，这也是为什么不建议用Kafka替代MQ中间件的原因。

OLAP

大数据的主要应用之一就是做数据分析，更专业的表述叫OLAP。OLAP是On Line Analytical Processing（联机分析处理）的缩写，与OLTP（On Line Transaction Processing, 联机事务处理）相对应。OLTP是传统的关系型数据库的主要应用，是一种操作型数据处理。OLAP是数据仓库的主要应用，是一种分析型数据处理。

OLAP分析处理的数据一般采用维度建模（延伸阅读：《数仓架构设计方法论》），基于“维度”的分析操作包括：钻取（上钻roll up和下钻drill down）、切片(slice)和切块(dice)、以及旋转(pivot)等。按数据存储方式不同，OLAP引擎分为ROLAP、MOLAP和HOLAP三种（如下图所示）。按实现架构不同，OLAP引擎可分为：MPP（Massively Parallel Processor, 大规模并行处理）架构、预处理架构和搜索引擎架构。

基于MPP架构的ROLAP引擎：Presto

利用关系模型来处理OLAP查询，通过并发来提高查询性能。Presto是Facebook于2012年开发，2013年开源的，完全基于内存的并⾏计算，分布式SQL交互式查询引擎。其官网地址是：https://prestodb.io/ 。

基于预计算架构的MOLAP引擎：Druid、Kylin

Kylin是完全的预计算引擎，通过枚举所有维度的组合，建立各种Cube进行提前聚合，以HBase为基础的OLAP引擎。其官网地址是：http://kylin.apache.org/ 。
Druid则是轻量级的提前聚合(roll-up)，同时根据倒排索引以及bitmap提高查询效率的时间序列数据和存储引擎。其官网地址是：https://druid.apache.org/ 。

基于搜索引擎架构的OLAP：ES

ES是典型的搜索引擎类的架构系统，在入库时将数据转换为倒排索引，采用Scatter-Gather计算模型提高查询性能。- 对于搜索类的查询效果较好，但当数据量较大时，对于Scan类和聚合类为主的查询性能较低。

看数：敏捷BI工具

看数解决数据可视化问题，帮助BI进行数据分析，支持企业决策，实现商业价值。这个领域，国内外已经有很多成熟的软件，比如QlikView、TableAU、FineBI、PowerBI、QuickBI等。大部分BI软件都是商业软件，不支持私有化部署或者私有化部署成本很高。并且，BI工具的用户定位偏专业数据分析师，对普通人来说有一定的学习使用门槛。随着前端数据可视化组件的不断完善（比如Highcharts、百度的Echats、阿里的antV(G2)等），许多互联网公司会选择定制的数据可视化方案。一些大公司也会自研BI工具，比如滴滴的数易。

延伸阅读
《数仓架构设计方法论》
《从康威定律看技术管理》