大数据中台架构栈.docVIP

. Word 文档 近来数据中台概念大火，大家对它的定义也五花八门，不一而足。但无论怎么定义，一个完善的数据技术架构必不可少。了解这些架构里每个部分的位置，功能和含义，不仅能让我们更好了解数据产品的范围和边界，知道技术能帮我们实现什么，能怎么实现得更好，另一方面，很多技术的设计理念对我们认知世界，了解复杂系统也会有所裨益。因此这篇文章旨在梳理市面上常见的开源技术方案，背后原理及应用场景，帮助产品经理对大数据技术体系有个大致全面的了解。 一般来说，我们将数据整个链条区分为四个环节，从数据采集传输，到数据存储，再到数据计算查询，到后续的数据可视化及分析。框架图如下： 1. 数据采集传输 这个一般对应于公司的日志平台，任务是将数据采集后缓存在某个地方，供后续的计算流程进行消费使用。 针对不同的数据来源有各自的采集方式，从 APP/服务器 日志，到业务表，还有各种 API 接口及数据文件等等。其中因为日志数据有数据量多，数据结构多样，产生环境复杂等特点，属于「重点关照」的对象。目前市面针对日志采集的有 Flume，Logstash，Filebeat，Fluentd ，rsyslog 几种常见的框架，我们挑应用较广泛的前两者介绍下： 1.1 Flume 和 Logstash?Flume 是一款由 Cloudera 开发的实时采集日志引擎，主打高并发，高速度，分布式海量日志采集。它是一种提供高可用、高可靠、分布式海量日志采集、聚合和传输的系统。Flume 支持在日志系统中定制各类数据进行发送，用于采集数据；同时，它支持对数据进行简单处理，并写到各种数据接收方。目前有两个版本，OG和NG，特点主要是： 侧重数据传输，有内部机制确保不会丢数据，用于重要日志场景 由java开发，没有丰富的插件，主要靠二次开发 配置繁琐，对外暴露监控端口有数据 Logstash 是 Elastic.co 旗下的一个开源数据收集引擎，可动态的统一不同的数据源的数据至目的地，搭配 ElasticSearch 进行分析，Kibana 进行页面展示，是著名的 ELK 技术栈中的「L」部分。特点主要是： 内部没有一个persist queue，异常情况可能会丢失部分数据 由ruby编写，需要ruby环境，插件很多 配置简单，偏重数据前期处理，分析方便 从两者的设计思想来看，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 数据传输 Kafka Kafka 最初是由领英开发，并随后于 2011 年初开源, 并于 2012 年 10 月 23 日由Apache Incubato 孵化出站。该项目的目标是为处理实时数据提供一个统一、高吞吐、低延迟的平台。其持久化层本质上是一个“按照分布式事务日志架构的大规模发布/订阅消息队列”，这使它作为企业级基础设施来处理流式数据非常有价值。 2. 数据存储 数据库存储方面，有单机/分布式、关系型/非关系型、列式存储/行式存储三个维度的划分，各种维度交叉下都有对应产品来解决某个场景下的需求。 在数据量较小的情况下，一般采取单机数据库，如应用非常广泛，技术成熟的 MySQL。数据量大到一定程度后，就必须采取分布式系统了。目前业界最知名的就是 Apache 基金会名下的 Hadoop 系统，它基本可以作为大数据时代存储计算的经典模型。 HDFS HDFS 作为 Hadoop 里的分布式文件系统，为 HBas