大数据中台架构栈

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Flume由三个部分组成：Source，Channel和Sink，对应于采集，缓存和保存三个环节。

其中，Source组件用来采集各种类型的数据源，如directory、http、kafka等。

Channel组件用来缓存数据，有memorychannel，JDBCchannel和kafkachannel三种。

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

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

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

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

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

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

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

在数据量较小的情况下，一般采取单机数据库，如应用非常广泛，技术成熟的MySQL。

数据量大到一定程度后，就必须采取分布式系统了。

目前业界最知名的就是Apache基金会名下的Hadoop系统，它基本可以作为大数据时代存储计算的经典模型。

HDFSHDFS作为Hadoop里的分布式文件系统，为HBase和Hive们提供了高可靠性的底层存储支持，对应于GoogleGFS的开源实现。

一般也会用于一些批次分析的场景。

HBaseHBase是Hadoop数据库，作为基于列的非关系型数据库运行在HDFS上。

它具备HDFS缺乏的随机读写能力，因此比较适合实时分析。

HBase以GoogleBigTable为蓝本，以Key-Value形式存储，能快速在主机内数十亿行数据中定位所需的数据并访问它。

Hive和PigHive和Pig都是集成在Hadoop顶层的查询语言，提供静态数据的动态查询，支持类SQL语言，底层经过编译转为MapReduce程序，省去了自己编写MR程序的繁琐。

区别是HiveSQL是类SQL的查询语言，要求数据存储于表中，而Pig是面向数据流的一个程序语言，常用于开发简洁的脚本来转换数据流从而嵌入到较大的应用程序中。

MapReduceMR开创了分布时代计算的先河，使得大批量数据处理成为可能。

简单来讲，就是将比较庞大的计算任务先分组，再汇总，提高计算效率。

举例来讲，如果你新家需要装修，要在不同地方购置很多东西。

你一个人（单机）去买估计得花十天。

现在叫了一堆小伙伴（分布式），每个人负责去一个地方买东西（Map），最后再拿到家里分类汇总（Reduce），一天就搞定了。

其他辅助工具上图中的其他工具是为了保证整个大数据计算存储系统壮，如Z o o k e e p e r 提供了稳和 f a i l v e r 机制，S q 为H a d o o p 提供了方便的R D B M S （关系型数据库）数据导入功能，统数据 库HBase 中迁移变的非常方便。

值得一提的是，H a d o o p 生态其实在G o o g l e 2003年发表的三大论的基础之上。

可时 G o o g l e 有意改善业内落后的现状，让大家稍微跟得上他的脚步才发布的文⋯这么多了道 Google 内部对数据的理解和使用又到了什么样的高度。

7.数据计算&查询3.1批计算和流计算 大数据处理场景可分为批处理和流处理两个，分别对应离线分析和实时分析框有： 1.3仅批处理框架：HadoopMapReduce 1.4仅流处理框架：Storm ，Samza 1.5混合框架：Spark ，Flink 篇幅所限，除了上文已经提到的H a d o o p 生态外，我们下Spark ： 4.Spark 和Flink ApacheSpark 是一种包含流处理能力的下一代批处理框架。

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

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

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

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

综上所述，S p a r k 是多样化工作负载处Spark 批处理能力以更高内存占用为代价提供 了无与伦比的速度优势。

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

而F l i n k 作为更新一代的处理框架，拥有更快的计算能力，更低的延迟，已经慢。

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

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

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

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

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

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

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

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

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

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

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

1.9数据可视化及分析在数据可视化这块，一般会采取三个途径来进行数据展示。

最基础的利用开源的图表库，如国外的HighCharts、D3，百度的ECharts，还有阿里Antv的G2、G6、F2等。

往上一层是各个知名公司开源的可视化框架，如Airbnb的Superset，Redash，Metabase等等。

这些框架一般能够满足从数据源接入，自助制作报表和报表整理展示的功能，接入起来更加方便。