数据研发：Scribe系列之一 特点结构简述

    近期在回顾这近两年做数据研发的收获，将写一系列数据研发相关技术的日志，也算留作自己温习的资料。其中一些内容之前早已随意写在有道云笔记。现在整理成成文日志，均发布到这个平台上。

    由于是做数据研发，因此从数据收集、数据处理、数据存储及数据展示均有涉及，固暂且列个计划依次写一系列的日志，将工作中所用到的技术手动都做一下介绍。

    首先是数据采集。各种用户数据、服务数据会产生在用户手机、服务器等设备上，而生产中做数据分析，需要把各种分散的数据最终集中到存储上来，因此需要借助数据采集系统来做数据收集。常用的技术方案有cloudera开源的flume和facebook开源的scribe。我的公司大环境采用scribe，因此对scribe了解的比较深入，本文就对scribe做一个比较慨括的描述。

    什么是scribe呢？英文直接翻译过来是抄写员的意思，这和他的实际功能非常贴近。Scribe是由著名的美国互联网公司facebook开源的日志采集系统。我们天朝因为有墙不能用facebook，但我们牛逼的程序员们可不管什么墙不墙的，系统好用就直接翻过去拿。可能有的同学要提问题了，为撒搞个日志还要用什么系统，不就是看看log吗。这就要从我们真正的互联网软件生产说起了。实际生产里面，可能有权限控制，分布式服务很多情况，需要方便的把好多机器上的日志都收集到一起来进行分析处理，一台台的机器直接去看log，累死了都找不到问题。牛逼的程序员很懒的人，能写代码快速搞定的，绝不手动去搞。Scribe的特点就是适应刚才所说的分布式，他可以部署在每个需要收集日志的机器上。同时，他又支持c/s结构能把不同机器上收集的日志，汇总到中央服务器上。这样我们从中央服务器直接看日志就能省很多事。

scribe特点

    下面，给大家介绍一下使用scribe的系统架构图

scribe的总体结构分为三部分，日志服务器、中心服务器和存储服务器。结构如下图所示

    为了收集日志，每一台用户业务服务器上都会部署一个scribe客户端，它包含两个模块：agent和local_server。其中agent的作用就是以tail读文件末尾的方式读取本地目录下的日志文件，并将数据写到本地的local_server，然后local_server通过zookeeper定位到center_server，并将数据发送给远端的center_server

    center_server其实和local_server是同一套程序，只是配置文件不一样，它们通过thrift进行通信。center_server收到数据后，根据配置将各个category的数据发向不同的方向，比如写到HDFS、发到Kafka集群等等。

    存储服务器：日志被收集到存储服务器以后，就可以进行离线/实时的统计分析了。比如，HDFS是用来永久存储日志，并给MapReduce提供离线数据的；Kafka则是给Storm集群提供实时数据流，以实时地统计分析

在Scribe中传输的每个基本数据单元都包含一个category和一个message，category作为message的标识符，用于给message分类，以避免数据在传输过程中混淆在一起。

通过上图的传输结构，我们通过可以采用scribe将各个设备上收集的日志，统一传输至文件存储系统中以进行后续的计算或者分析。

本文仅介绍了scribe的概念和结构。大概搜了下网上现有的中文scribe资料，都比较分散，概念介绍和使用流程不统一。所以我想做一个系列，从介绍到安装使用配置都做一个详细的介绍，以便大家能比较方便了解和使用。