WORD格式近来数据中台概念大火,大家对它的定义也五花八门,不一而足。但无论怎么定义,一个完善的数据技术架构必不可少。了解这些架构里每个部分的位置，功能和含义,不仅能让我们更好了解数据产品的范围和边界，知道技术能帮我们实现什么,能怎么实现得更好,另一方面,很多技术的设计理念对我们认知世界,了解复杂系统也会有所裨益。因此这篇文章旨在梳理市面上常见的开源技术方案，背后原理及应用场景，帮助产品经理对大数据技术体系有个大致全面的了解。一般来说，我们将数据整个链条区分为四个环节,从数据采集传输，到数据存储，再到数据计算&查询，到后续的数据可视化及分析。框架图如下：1.数据采集传输这个一般对应于公司的日志平台,任务是将数据采集后缓存在某个地方,供后续的计算流程进行消费使用。针对不同的数据来源有各自的采集方式,从ＡＰＰ／服务器日志,到业务表，还有各种APＩ接口及数据文件等等。其中因为日志数据有数据量多,数据结构多样,产生环境复杂等特点,属于「重点关照」的对象。目前市面针对日志采集的有Flｕｍｅ,Logｓtａsh,Filebｅat,Fluｅｎtd，rsｙｓｌog几种常见的框架，我们挑应用较广泛的前两者介绍下：1.1Flume和ＬoｇstashＦlume是一款由Ｃｌｏudera开发的实时采集日志引擎,主打高并发,高速度,分布式海量日志采集。它是一种提供高可用、高可靠、分布式海量日志采集、聚合和传输的系统。Flume支持在日志系统中定制各类数据进行发送,用于采集数据；同时,它支持对数据进行简单处理,并写到各种数据接收方。目前有两个版本，ＯＧ和ＮG，特点主要是:1.侧重数据传输,有内部机制确保不会丢数据，用于重要日志场景2.由jaｖa开发，没有丰富的插件,主要靠二次开发3.配置繁琐，对外暴露监控端口有数据Z专业资料整理WORD格式Logstash是Elastic．co旗下的一个开源数据收集引擎,可动态的统一不同的数据源的数据至目的地,搭配EｌasticSearch进行分析,Kibana进行页面展示，是著名的ＥLK技术栈中的「L」部分。特点主要是:2.内部没有一个persｉstqueｕe,异常情况可能会丢失部分数据3.由rｕbｙ编写，需要ｒubｙ环境,插件很多4.配置简单，偏重数据前期处理,分析方便从两者的设计思想来看,Flume最初并不是为了采集日志而设计,而是定位在把数据传入HDＦS中，这和Loｇstash有根本的区别。所以它理所应当侧重于数据的传输和安全，且需要更多的二次开发和配置工作。而Lｏgｓtaｓｈ明显侧重先对日志数据进行预处理,为后续的解析做铺垫。它搭配ＥLK技术栈使用起来比较简单,更像是为你准备好的便当，开盒即食。1.2日志采集如何工作我们以Ｆｌuｍe为例子讲些日志采集Agｅnt是怎么工作的。Flｕmｅ由三个部分组成：Sourcｅ,Ｃhａnnel和Sink,对应于采集,缓存和保存三个环节。Z专业资料整理WORD格式其中，Source组件用来采集各种类型的数据源，如ｄireｃtory、http、ｋafｋa等。Chanｎel组件用来缓存数据，有mｅmｏrychaｎnｅl，ＪＤBCchａnnel和ｋafkachａnnｅl三种。最后再通过Ｓinｋ组件进行保存,分别支持HDFＳ,HＢaｓe，Hｉve和Kaｆka四种存储方式。下面结合一个大数据实时处理系统阐述下Flume在实际应用中所扮演的重要角色。该实时处理系统整体架构如下：通过将Aｇenｔ部署在Wｅb服务器，一旦发生新增的日志数据，就会被Fｌume程序监听到，并且最终会传输到Kafka的Ｔopiｃ中,再进行后续的一系列操作。5.数据传输ＫafｋaKafｋa最初是由领英开发，并随后于2０11年初开源,并于2０１2年10月23日由ApａcheIncｕbａto孵化出站。该项目的目标是为处理实时数据提供一个统一、高吞吐、低延迟的平台。其持久化层本质上是一个“按照分布式事务日志架构的大规模发布／订阅消息队列”,这使它作为企业级基础设施来处理流式数据非常有价值。Z专业资料整理WORD格式6.数据存储数据库存储方面，有单机／分布式、关系型/非关系型、列式存储／行式存储三个维度的划分,各种维度交叉下都有对应产品来解决某个场景下的需求。在数据量较小的情况下，一般采取单机数据库，如应用非常广泛，技术成熟的ＭySQL。数据量大到一定程度后,就必须采取分布式系统了。目前业界最知名的就是Ａｐaｃhe基金会名下的Hadｏｏp系...
