00-1010，一般对应公司的日志平台，是将采集到的数据缓存在某个地方，供后续计算过程中消耗。不同的数据源有自己的采集方式，从APP/服务器日志到业务表，以及各种API接口和数据文件等。其中，日志数据具有数据量大、数据结构多样、生产环境复杂等特点，属于“重点关注”对象。目前市场上常见的日志收集框架有Flume、Logstash、Filebeat、Fluentd、rsyslog等几种。先来介绍一下前两个广泛使用的框架：1.1 Flume和LogstashFlume是Cloudera开发的实时日志收集引擎，专注于高并发、高速、分布式的海量日志收集。它是一个提供高可用性、高可靠性和分布式海量日志收集、聚合和传输的系统。Flume支持定制日志系统中的各种数据发送进行数据采集；同时，它支持简单的数据处理和写入各种数据接收器。目前有OG和NG两个版本，其特点是：

注重数据传输，有内部机制保证数据不会丢失。它是由java为重要的日志场景开发的，没有丰富的插件。主要依靠二次开发的繁琐配置，数据暴露在外部监控端口

Logstash是http://Elastic.co旗下的开源数据收集引擎，可以将不同数据源的数据动态统一到目的地，用ElasticSearch进行分析，并由Kibana显示页面，这是著名的ELK技术栈的“L”部分。主要特点是：

如果没有持久化队列，一些数据可能会在异常情况下丢失，这是由ruby编写的，需要ruby环境。许多插件配置简单，专注于数据预处理，易于分析

从两者的设计思想来看，Flume最初并不是为了收集日志而设计的，而是为了将数据传输到HDFS，这与Logstash有着本质的区别。所以要重点关注数据传输和安全，需要更多的二次开发和配置工作。Logstash显然侧重于先对日志数据进行预处理，这为后续分析铺平了道路。搭配ELK技术栈使用相对简单，更像是给你准备的饭盒，打开盒子就可以吃了。

回到顶端

00-1010我们以Flume为例，谈谈日志收集代理是如何工作的。水槽由源、道、汇三部分组成，对应采集、缓存、保存三个环节。其中，Source组件用于收集各种类型的数据源，如目录、http、kafka等。组件用于缓存数据，包括内存通道、JDBC通道和卡夫卡通道。最后由Sink组件保存，Sink组件分别支持HDFS、HBase、Hive和Kafka。以下描述了Flume在大数据实时处理系统的实际应用中发挥的重要作用。实时处理系统的整体架构如下：通过在Web服务器中部署Agent，一旦新添加的日志数据发生，就会被Flume程序监控，最后传输到Kafka的Topic，然后进行后续的一系列操作。

回到顶端

1. 数据采集传输 Kafka最初由LinkedIn开发，后来在2011年初开放，2012年10月23日由Apache孵化器孵化出离站。该项目的目标是为处理实时数据提供一个统一的、高吞吐量和低延迟的平台。它的持久层本质上是一个“根据分布式事务日志体系结构的大规模发布/订阅消息队列”，这使得它作为处理流数据的企业级基础设施很有价值。

回到顶端

00-1010数据库存储端

面，有单机/分布式、关系型/非关系型、列式存储/行式存储三个维度的划分，各种维度交叉下都有对应产品来解决某个场景下的需求。在数据量较小的情况下，一般采取单机数据库，如应用非常广泛，技术成熟的 MySQL。数据量大到一定程度后，就必须采取分布式系统了。目前业界最知名的就是 Apache 基金会名下的 Hadoop 系统，它基本可以作为大数据时代存储计算的经典模型。

HDFSHDFS 作为 Hadoop 里的分布式文件系统，为 HBase 和 Hive 们提供了高可靠性的底层存储支持，对应于 Google GFS 的开源实现。一般也会用于一些批次分析的场景。

HBaseHBase 是 Hadoop 数据库，作为基于列的非关系型数据库运行在 HDFS 上。它具备 HDFS 缺乏的随机读写能力，因此比较适合实时分析。HBase 以 Google BigTable为蓝本，以 Key-Value 形式存储，能快速在主机内数十亿行数据中定位所需的数据并访问它。

Hive 和 PigHive 和 Pig 都是集成在 Hadoop 顶层的查询语言，提供静态数据的动态查询，支持类 SQL 语言，底层经过编译转为 MapReduce 程序，省去了自己编写 MR 程序的繁琐。区别是 Hive SQL 是类 SQL 的查询语言，要求数据存储于表中，而 Pig 是面向数据流的一个程序语言，常用于开发简洁的脚本来转换数据流从而嵌入到较大的应用程序中。

MapReduceMR 开创了分布时代计算的先河，使得大批量数据处理成为可能。简单来讲，就是将比较庞大的计算任务先分组，再汇总，提高计算效率。举例来讲，如果你新家需要装修，要在不同地方购置很多东西。你一个人（单机）去买估计得花十天。现在叫了一堆小伙伴（分布式），每个人负责去一个地方买东西（Map），最后再拿到家里分类汇总（Reduce），一天就搞定了。

其他辅助工具上图中的其他工具是为了保证整个大数据计算存储系统更加健壮和开放，如 Zookeeper 提供了稳定服务和 failover 机制，Sqoop 则为 Hadoop 提供了方便的 RDBMS（关系型数据库）数据导入功能，使得传统数据库数据向 HBase 中迁移变的非常方便。值得一提的是，Hadoop 生态其实是建立在 Google 2003 年发表的三大论文的基础之上。可能是当时 Google 有意改善业内落后的现状，让大家稍微跟得上他的脚步才发布的论文…这么多年过去了，不知道 Google 内部对数据的理解和使用又到了什么样的高度。

回到顶部

3. 数据计算&查询

回到顶部

3.1 批计算和流计算

大数据处理场景可分为批处理和流处理两个，分别对应离线分析和实时分析。常见框架分类有：

仅批处理框架：Hadoop MapReduce仅流处理框架：Storm，Samza混合框架：Spark，Flink

篇幅所限，除了上文已经提到的 Hadoop 生态外，我们再简单科普下 Spark：

回到顶部

3.2 Spark 和 Flink

Apache Spark 是一种包含流处理能力的下一代批处理框架。批处理模式下，Spark 与 MapReduce 不同，它将数据处理工作全部在内存中进行，计算性能大幅改善。流处理模式下，Spark 主要通过 Spark Streaming 实现了一种叫做微批（Micro-batch）的概念。该技术可以将数据流视作一系列非常小的“批”，借此即可通过批处理引擎的原生语义进行处理。这种方式的实际效果非常好，但相比真正的流处理框架在性能方面依然存在不足。

综上所述，Spark是多样化工作负载处理任务的最佳选择。Spark批处理能力以更高内存占用为代价提供了无与伦比的速度优势。对于重视吞吐率而非延迟的工作负载，则比较适合使用 Spark Streaming 作为流处理解决方案。

而 Flink 作为更新一代的处理框架，拥有更快的计算能力，更低的延迟，已经慢慢崭露头角。不过一个框架的应用，特别是开源框架，需要足够长的时间进行运行，测试和优化。大数据技术在开源社区的推动下，迭代日新月异。在不久的将来，相信 Flink 会像 Spark 取代 Storm 一样，逐渐成为大数据处理技术的主流。

回到顶部

3.3 数据查询

经过处理后的数据，还需要有高效的查询引擎才能被用户接触和使用。目前 OLAP 的查询技术框架大致可分为三类：

基于 HBase 做预聚合：如 Opentsdb, Kylin 等，均需指定预聚合的指标，在数据接入的时候进行聚合运算，适合相对固定，维度较多的业务报表类需求基于 Parquet 做列式存储：如 Presto, Drill，Impala 等，基本是完全基于内存的并行计算，Parquet 系能降低存储空间，提高IO效率，以离线处理为主，很难提高数据写的实时性，超大表的 Join 支持可能不够好基于 Lucene 做外部索引：如 ElasticSearch，Solr 等，能够满足的的查询场景远多于传统的数据库存储，但对于日志、行为类时序数据，所有的搜索请求都也必须搜索所有的分片，另外，对于聚合分析场景的支持也是软肋

我们以常见的 Presto，Druid，Kylin 三个模型来讲讲各自的特点：

Presto：由 Facebook 开源，是一个分布式数据查询框架，原生集成了 Hive、 Hbase 和关系型数据库。它背后所使用的执行模式与Hive有根本的不同，并没有使用 MapReduce。因其所有的处理都在内存中完成（与上文的 Spark 类似），大部分场景下要比 Hive 快一个数量级Druid：由 MetaMarket 开源，是一个分布式、面向列式存储的准实时分析数据存储系统，延迟性最细颗粒度可到 5 分钟。它能够在高并发环境下，保证海量数据查询分析性能，同时又提供海量实时数据的查询、分析与可视化功能Kylin：Cube 预计算技术是其核心，基本思路是预先对数据作多维索引，查询时只扫描索引而不访问原始数据从而提速。劣势在于每次增减维度必须对 Cube 进行历史数据重算追溯，非常消耗时间。据说 Kylingence 在前几天的新品发布会上已经解决了这个问题，拭目以待

下图引自快手在 OLAP 技术选型时的评价，以供大家参考：

很多时候，在计算和查询这块没有明显的边界区分。这里为了方便阐述分成了两个部分。事实上，对于技术能力比较强的团队，可以针对这些开源系统进行魔改，比如采用 Kylin 的预计算能力+Druid 的查询引擎，来提高查询的速度等等。

回到顶部

4. 数据可视化及分析

在数据可视化这块，一般会采取三个途径来进行数据展示。最基础的利用开源的图表库，如国外的 HighCharts、D3，百度的 ECharts，还有阿里 Antv 的 G2、G6、F2 等。往上一层是各个知名公司开源的可视化框架，如 Airbnb 的 Superset，Redash，Metabase 等等。这些框架一般能够满足从数据源接入，自助制作报表和报表整理展示的功能，接入起来更加方便。再往上一层就是商用的可视化软件，如国外的 Tableau，Qlik ，国内的 FineReport，永洪 BI 等等。这种软件需要付费，但都具备更丰富的可视化功能并提供一些技术支持，对于那些没有精力折腾可视化的公司会是个不错的选择。

回到顶部

4.1 图表库

理解整个图表开源生态，我们得先了解下 SVG 和 Canvas 这两个浏览器提供的原生能力。SVG 全称叫可缩放矢量图，跟 HTML 一样，有自己的命名空间，使用 XML 标签来绘图。而 Canvas 是 HTML5 中的新标签，用于客户端的图形绘制，有一个基于 Javascript 的绘图 API。

D3.js 全称是 Data-DrivenDocuments，支持 SVG 和 Canvas。相对于其他产品，它更偏底层，并没有对图表进行归类。开发者可以通过 D3 丰富的类库来方便的操作 DOM，绘制任何想绘制的图形，以增加开发复杂度的代价，覆盖更加全面的可视化场景。

而国外的 HighCharts 是基于 SVG 开发的图表库，ECharts 和 G2 则均基于 Canvas。ECharts 有完整的图表封装，开箱即用，而 G2 则是一套基于可视化编码的图形语法，以数据驱动，具有高度的易用性和扩展性。阿里后续基于 G2 又往上封装了一套基于 React 的图表库 Bizcharts，主打电商业务图表可视化，沉淀电商业务线的可视化规范。在 React 项目中实现常见图表和自定义图表。

ECharts 和 G2 的对比可借用 ECharts 作者的一句话，G2 是面粉，ECharts 是面条，皆微小但美好。

回到顶部

4.2 可视化框架

这里主要介绍下业内比较出名的 Superset 和 Metabase。前者的方案更加完善，支持集合不同数据源形成对应的指标，再通过丰富的图表类型进行可视化。在时间序列分析上比较出色，支持移动平均及周期偏移等分析方法。同时与 Druid 深度集成，可以快速解析大规模数据集。劣势则是不支持分组管理报表，一旦报表多了使用起来很麻烦。且不提供图表下钻及联动功能，权限管理也不够友好。

Metabase 则比较注重非技术人员（如产品经理和运营人员）的使用体验，让他们能自由地探索数据，回答自己的问题，界面相对来讲更加美观。在权限管理上做得较为完善，甚至无需账号也可以对外共享图表和数据内容。Dashboard 支持分类，便于管理报表。劣势在时间序列分析上不支持不同日期对比，还需要自定义SQL 实现。每次查询仅能针对一个数据库查询，操作比较繁琐。