大数据采集服务-Lancer系统设计与实践1.docx

PAGE 1 大数据采集服务 - Lancer系统设计与实践 B站的日志采集肩负了B站的所有业务的日志收集并传输，提供离线数据和实时数据以满足离线或实时计算以及业务方订阅的需求。B站日志收集系统是基于Flume设计和搭建而成的。 数据采集是大数据的基石，近几年随着业务的高速增长，产生的数据量越来越大，并且会持续快速增长。因而对采集系统的实时性，稳定性以及可靠性也提出了更高的要求。 本文主要介绍了日志采集系统Lancer的整体架构包括各组件设计及优化。 B站原有的大数据采集服务存在的问题包括： 1) 系统支撑能力不足 原生Flume坑多，性能较差 异构系统较多，支持比较困难，缺乏统一的协议层标准 早期资源不足的情况下，应用的部署也不是很合理，没有做到应用的物理隔离 2) 埋点接入混乱 埋点错埋、漏埋、随意埋 数据无保障，易丢失、出现问题难以排查和恢复 缺乏自动化接入流程，业务方接入过程耗时耗力 缺乏一套完整的数据监控体系对数据流链路进行监控 3) 数据覆盖不完全 终端覆盖率不足 业务场景覆盖不够全面 架构 基于这些问题的存在，我们确立了新数据采集系统的整体设计目标，首先，性能上要做到高吞吐和低延时；其次，质量上要保证数据的安全性和时效性；最后，要做到系统高可用，提供数据灾备，保证数据零丢失。在这样的系统设计目标之下，我们按照如下结构设计了系统： 图一 Lancer系统整体架构 从系统架构中可以看出，该系统主要有两种数据流向，分别是实时流和离线流，前者对应流式埋点数据的上报，数据产生并实时上报至网关层；后者对应批量数据的同步，例如从数据库批量的对数据进行同步操作。 以实时流数据为例，数据源包括服务端以及客户端，服务端日志可以通过统一上报模块SDK以Tcp/Udp/LogStream(基于Tcp实现的私有协议，可以获得更高的传输效率)进行数据的收集并上报，而客户端通过客户端数据采集SDK以Http(s)根据不同的网络环境按一定策略将压缩后的数据进行上报。之后由统一的网关层Lancer-Gateway接收上报的数据，并写入到数据缓冲层（Kafka），最后由数据分发层将数据从数据缓冲层中拉取，将数据写入到数据存储层（包括HDFS、HIVE、ES、HBASE等），提供给后续的数据仓库、实时计算或者其他业务部门自订阅和消费。 离线流基于Sqoop，实现了数据库数据的批量同步功能，并支持分发到不同终端的功能，关于离线流的讨论本文不做展开。 基于Flume的数据网关层和分发层的实现方案 Flume是由Cloudera软件公司产出的可分布式日志收集系统，后于2009年被捐赠了apache软件基金会，现已成为apache top项目之一。它是一个分布式、可靠、和高可用的海量日志采集、聚合和传输的系统。支持在日志系统中定制各类数据发送方，用于收集数据；同时，Flume提供对数据进行简单处理，并写到各种数据接受方(比如文本、HDFS、Hbase，kafka等)的能力 。 Flume以agent为最小的独立运行单位，单agent由Source，Channel和Sink三大组件组成，而Event作为数据在Flume中传递的单位。 图二 原生Flume数据流 Flume的数据流由事件(Event)贯穿始终。Event是Flume的基本数据单位，它携带日志数据(字节数组形式)并且携带有header头信息，这些Event由Agent外部的Source生成，当Source捕获事件后会进行特定的格式化，然后Source会把事件推入(单个或多个)Channel中。可以把Channel看作是一个缓冲区，它将保存事件直到Sink处理完该事件。Sink负责持久化日志或者把事件推向另一个Source。 1） 网关层 — Lancer-Gateway 系统架构? 图三 网关层Lancer-Gateway系统设计 网关层Lancer-Gateway提供了LogStreamSource、SysLogUdpSource、SysLogTcpSource、NetSource等，可以接收不同协议层的数据上报。 Socket模型利用了Reactor主从NIO线程模型： 1. 从主线程池中随机选择一个Reactor线程作为Acceptor线程，用于绑定监听端口，接收客户端连接； 2. Acceptor线程接收客户端连接请求之后创建新的SocketChannel，将其注册到主线程池的其它Reactor线程上，由其负责接入认证，握手等操作； 3. 步骤2完成之后，业务层的链路正式建立，将SocketChannel从主线程池的Reactor线程的多路复用器上摘除，重新注册到Sub线程池的线程上，用于处理I/O的读写操作； 4. 在每个Sub线程上配置私有线程池，并发地执行数据的编解码操作并