数据中台-数据采集传输
近来数据中台概念大火，大家对它的定义也,五花八门，不一而足。但无论怎么定义，一个完善的数据技术架构必不可少。了解这些架构里每个部分的位置，功能和含义，不仅能让我们更好了解数据产品的范围和边界，知道技术能帮我们实现什么，能怎么实现得更好，另一方面，很多技术的设计理念对我们认知世界了解复杂系统也会有所裨益。因此这篇文章旨在梳理市面上常见的开源技术方案，背后原理及应用场景，帮助产品经理对大数据技术体系有个大致全面的了解。
一般来说，我们将数据整个链条区分为四个环节，从数据采集传输，到数据存储，再到数据计算&查询，到后续的数据可视化及分析。
这个一般对应于公司的日志平台，任务是将数据采集后缓存在某个地方，供后续的计算流程进行消费使用。针对不同的数据来源有各自的采集方式，从APP/服务器日志，到业务表，还有各种API接口及数据文件等等。其中因为日志数据有数据量多，数据结构多样，产生环境复杂等特点，属于「重点关照」的对象。目前市面针对日志采集的有F1ume，Logstash，Filebeat，Fluentd，rsyslog几种常见的框架，我们挑应用较广泛的前两者介绍下:
1.1F1ume和LogstashF1ume是一款由C1oudera开发的实时采集日志引擎，主打高并发，高速度，分布式海量日志采集。它是一种提供高可用、高可靠、分布式海量日志采集、聚合和传输的系统。F1ume支持在日志系统中定制各类数据进行发送，用于采集数据﹔同时，它支持对数据进行简单处理，并写到各种数据接收方。目前有两个版本，OG和NG，特点主要是:
布式海量日志采集。它是一种提供高可用、高可靠、分布式海量日志采集、聚合和传输的系统。F1ume支
1.侧重数据传输，有内部机制确保不会丢数据，用于重要日志场景
2.由java开发，没有丰富的插件，主要靠二次开发
a.配置繁琐，对外暴露监控端口有数据Logstash是Elastic.co旗下的一个开源数据收集引擎，可动态的统一不同的数据源的数据至目的地，搭配ElasticSearch进行分析，Kibana进行页面展示，是著名的ELK技术栈中的「L」部分。特点主要是:
2.内部没有一个persistqueue，异常情况可能会丢失部分数据
3.由ruby编写，需要ruby环境，插件很多
4.配置简单，偏重数据前期处理，分析方便
从两者的设计思想来看，F1ume最初并不是为了采集日志而设计，而是定位在把数据传入HDFS中，这和Logstash有根本的区别。所以它理所应当侧重于数据的传输和安全，且需要更多的二次开发和配置工作。而Logstash明显侧重先对日志数据进行预处理，为后续的解析做铺垫。它搭配ELK技术栈使用起来比较简单，更像是为你准备好的便当，开盒即食。
1.2日志采集如何工作
我们以F1ume为例子讲些日志采集Agent是怎么工作的。Flume由三个部分组成:Source，Channe1和Sirk，对应于采集，缓存和保存三个环节。
数据，有memorychannel，JDBCcharne1和kafkachannel三种。最后再通过Sink组件进行保存，分别支持HDFS，HBase，Hive和Kafka四种存储方式。
下面结合一个大数据实时处理系统阐述下F1ume在实际应用中所扮演的重要角色。该实时处理系统整体架构如下:通过将Agent部署在Web服务器，一旦发生新增的日志数据，就会被F1ume程序监听到，并且最终会传输到Kafka的Topic中，再进行后续的一系列操作。
