近来数据中台概念大火，大家对它的定义也五花八门，不一而足。

但无论怎么定义，一个完善的数据技术架构必不可少。

了解这些架构里每个部分的位置，功能和含义，不仅能让我们更好了解数据产品的范围和边界，知道技术能帮我们实现什么，能怎么实现得更好，另一方面，很多技术的设计理念对我们认知世界，了解复杂系统也会有所裨益。

因此这篇文章旨在梳理市面上常见的开源技术方案，背后原理及应用场景，帮助产品经理对大数据技术体系有个大致全面的了解。

一般来说，我们将数据整个链条区分为四个环节，从数据采集传输，到数据存储，再到数据计算&查询，到后续的数据可视化及分析。

框架图如下：1. 数据采集传输这个一般对应于公司的日志平台，任务是将数据采集后缓存在某个地方，供后续的计算流程进行消费使用。

针对不同的数据来源有各自的采集方式，从APP/服务器日志，到业务表，还有各种API 接口及数据文件等等。

其中因为日志数据有数据量多，数据结构多样，产生环境复杂等特点，属于「重点关照」的对象。

目前市面针对日志采集的有Flume ，Logstash ，Filebeat ，Fluentd ，rsyslog 几种常见的框架，我们挑应用较广泛的前两者介绍下：1.1 Flume 和Logstash Flume 是一款由Cloudera 开发的实时采集日志引擎，主打高并发，高速度，分布式海量日志采集。

它是一种提供高可用、高可靠、分布式海量日志采集、聚合和传输的系统。

Flume 支持在日志系统中定制各类数据进行发送，用于采集数据；同时，它支持对数据进行简单处理，并写到各种数据接收方。

目前有两个版本，OG和NG，特点主要是：1. 侧重数据传输，有内部机制确保不会丢数据，用于重要日志场景2. 由java 开发，没有丰富的插件，主要靠二次开发3. 配置繁琐，对外暴露监控端口有数据Logstash 是 Elastic.co 旗下的一个开源数据收集引擎， 可动态的统一不同的数据源的数据至目的地， 搭 配 ElasticSearch 进行分析， Kibana 进行页面展示，是著名的 ELK 技术栈中的「 L 」部分。

特点主要是： 1.内部没有一个 persist queue ，异常情况可能会丢失部分数据 2.由 ruby 编写，需要 ruby 环境，插件很多 3. 配置简单，偏重数据前期处理，分析方便从两者的设计思想来看， Flume 最初并不是为了采集日志而设计，而是定位在把数据传入 HDFS 中，这和 Logstash 有根本的区别。

所以它理所应当侧重于数据的传输和安全，且需要更多的二次开发和配置工作。

而 Logstash 明显侧重先对日志数据进行预处理， 为后续的解析做铺垫。

它搭配 ELK 技术栈使用起来比较 简单，更像是为你准备好的便当，开盒即食。

1.2 日志采集如何工作我们以 Flume 为例子讲些日志采集 Agent 是怎么工作的。

Flume 由三个部分组成： Source ， Channel 和 Sink，对应于采集，缓存和保存三个环节其中，Source 组件用来采集各种类型的数据源，如directory 、http 、kafka 等。

Channel 组件用来缓存数据，有memory channel ，JDBC channel 和kafka channel 三种。

最后再通过Sink 组件进行保存，分别支持HDFS，HBase，Hive 和Kafka 四种存储方式。

下面结合一个大数据实时处理系统阐述下Flume 在实际应用中所扮演的重要角色。

该实时处理系统整体架构如下：通过将Agent 部署在Web 服务器，一旦发生新增的日志数据，就会被Flume 程序监听到，并且最终会传输到Kafka 的Topic 中，再进行后续的一系列操作。

1.3 数据传输KafkaKafka 最初是由领英开发，并随后于2011 年初开源, 并于2012 年10 月23 日由Apache Incubato 孵化出站。

该项目的目标是为处理实时数据提供一个统一、高吞吐、低延迟的平台。

其持久化层本质上是一个“按照分布式事务日志架构的大规模发布/ 订阅消息队列”，这使它作为企业级基础设施来处理流式数据非常有价值。

2. 数据存储数据库存储方面，有单机/ 分布式、关系型/ 非关系型、列式存储/ 行式存储三个维度的划分，各种维度交叉下都有对应产品来解决某个场景下的需求。

在数据量较小的情况下，一般采取单机数据库，如应用非常广泛，技术成熟的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 批计算和流计算大数据处理场景可分为批处理和流处理两个，分别对应离线分析和实时分析。

常见框架分类有：1. 仅批处理框架：Hadoop MapReduce2. 仅流处理框架：Storm ，Samza3. 混合框架：Spark ，Flink篇幅所限，除了上文已经提到的Hadoop 生态外，我们再简单科普下Spark ：3.2 Spark 和FlinkApache Spark 是一种包含流处理能力的下一代批处理框架。

批处理模式下，Spark 与MapReduce 不同，它将数据处理工作全部在内存中进行，计算性能大幅改善。

流处理模式下，Spark 主要通过Spark Streaming 实现了一种叫做微批( Micro-batch )的概念。

该技术可以将数据流视作一系列非常小的“批”，借此即可通过批处理引擎的原生语义进行处理。

这种方式的实际效果非常好，但相比真正的流处理框架在性能方面依然存在不足。

综上所述，Spark 是多样化工作负载处理任务的最佳选择。

Spark 批处理能力以更高内存占用为代价提供了无与伦比的速度优势。

对于重视吞吐率而非延迟的工作负载，则比较适合使用Spark Streaming 作为流处理解决方案。

而Flink 作为更新一代的处理框架，拥有更快的计算能力，更低的延迟，已经慢慢崭露头角。

不过一个框架的应用，特别是开源框架，需要足够长的时间进行运行，测试和优化。

大数据技术在开源社区的推动下，迭代日新月异。

在不久的将来，相信Flink 会像Spark 取代Storm 一样，逐渐成为大数据处理技术的主流。

3.3 数据查询经过处理后的数据，还需要有高效的查询引擎才能被用户接触和使用。

目前OLAP 的查询技术框架大致可分为三类：1. 基于HBase 做预聚合：如Opentsdb, Kylin 等，均需指定预聚合的指标，在数据接入的时候进行聚合运算，适合相对固定，维度较多的业务报表类需求2. 基于Parquet 做列式存储：如Presto, Drill ，Impala 等，基本是完全基于内存的并行计算，Parquet 系能降低存储空间，提高IO 效率，以离线处理为主，很难提高数据写的实时性，超大表的Join 支持可能不够好3. 基于Lucene 做外部索引：如ElasticSearch ，Solr 等，能够满足的的查询场景远多于传统的数据库存储，但对于日志、行为类时序数据，所有的搜索请求都也必须搜索所有的分片，另外，对于聚合分析场景的支持也是软肋我们以常见的Presto ，Druid ，Kylin 三个模型来讲讲各自的特点：1. Presto ：由Facebook 开源，是一个分布式数据查询框架，原生集成了Hive 、Hbase 和关系型数据库。

它背后所使用的执行模式与Hive 有根本的不同，并没有使用MapReduce。

因其所有的处理都在内存中完成（与上文的Spark 类似），大部分场景下要比Hive 快一个数量级2. Druid ：由MetaMarket 开源，是一个分布式、面向列式存储的准实时分析数据存储系统，延迟性最细颗粒度可到 5 分钟。

它能够在高并发环境下，保证海量数据查询分析性能，同时又提供海量实时数据的查询、分析与可视化功能3. Kylin ：Cube 预计算技术是其核心，基本思路是预先对数据作多维索引，查询时只扫描索引而不访问原始数据从而提速。

劣势在于每次增减维度必须对Cube 进行历史数据重算追溯，非常消耗时间。

据说Kylingence 在前几天的新品发布会上已经解决了这个问题，拭目以待下图引自快手在OLAP 技术选型时的评价，以供大家参考：很多时候，在计算和查询这块没有明显的边界区分。

这里为了方便阐述分成了两个部分。

事实上，对于技术能力比较强的团队，可以针对这些开源系统进行魔改，比如采用Kylin 的预计算能力+Druid 的查询引擎，来提高查询的速度等等。