文档章节

数据生产与收集

hblt-j
 hblt-j
发布于 01/24 11:20
字数 6066
阅读 5
收藏 0

数据

对于移动端的app来说, 分析的数据大致上都可以分为俩种, 一种是在线数据,一种是离线数据。 在线数据, 即app后端服务所产生的日志数据,例如服务接口的性能数据, 服务接口的调用及其参数等, 通过服务端的日志数据, 我们不但可以统计服务接口的性能指标,还可以针对具体的业务逻辑,做相关的分析,一些常见的app分析指标如新增,活跃,累计,留存等,也都可以通过服务日志来统计出来。 对应的离线数据即是app客户端本身产生的数据, 这种情况一般是发生在客户端不调用底层服务的情况下,需要了解用户在客户端的行为,就需要用到离线数据。 离线日志一般记录用户在客户端的具体行为,如用户在客户端的拖动,上下滚动,翻页等不涉及到后端服务的操作,以及app本身的崩溃行为产生的数据, 都可以被记录, 一般的,记录的内容包括事件类型,控件编号,控件属性及相关参数,事件时间等。

 

数据收集

在线日志

在线日志,一般来讲,有俩种

  • web服务器的配置化log(如nginx, apache等web服务器的access.log)
    这一类日志不需要用户自己做实现, 只需要开启web服务器的相关日志功能,即可完成日志记录。
  • 应用服务器的log
    一般包括应用服务器的配置化log 以及 用户自定义的log。 用户自定义log包括用户通过相关日志组件自己的debug, waring ,error, info等级别的日志。 这一类日志没有固定的格式,完全有用户自行控制。
    在线日志一般会伴随业务直接产生在相关的业务服务器上(web服务器日志产生在web服务器上),但是有的时候,为了将相关服务的监控日志与业务分析日志分离,会将业务日志直接记录在一台独立的日志服务器上。

离线日志

离线日志,一般也有俩种

  • 客户端的行为日志 用户在操作app的时候,产生的行为,都可以记录下来。 行为日志一般是用来研究用户使用习惯, 分析应用的使用热度的。 同时可以结合客户端异常日志来分析异常原因。
  • 客户端的异常日志 用来监控客户端异常原因, 帮助解决相关问题。

埋点及上传

不管是在线日志,还是离线日志,我们首先都要确认在什么地方记录日志, 于是我们就引入了埋点的概念。 通俗的讲,在正常业务代码逻辑上, 添加记录日志的代码, 都叫做埋点。 但是一般的,埋点只用来描述客户端日志记录。
由于在线日志是直接产生在服务器端, 日志采集工具可以直接从含有日志的服务器上采集日志数据到相应的文件系统, 所以不存在日志上传的问题。但是对于离线日志来说, 数据是产生在客户端的, 所以上传机制必须考虑。

离线日志上传机制

业界采用的离线日志上传机制如下:

  1. 服务端提供日志记录接口, 当客户端有事件时,直接调用日志记录接口将日志记录在服务器端。
  2. 服务端提供日志上传接口, 客户端先将日志暂存客户端本地,当达到一定的大小,网络环境允许的情况下, 通过上传接口,将日志文件打包压缩后上传。

第一种上传方式,时效性方面有一定的保障, 在网络环境允许的情况下,能及时的将信息记录到服务器,但是当埋点较多时,记录日志产生的流量会很大,占据很大的带宽,给用户带来损失。 同时, 前端的某些行为,如在某个activity停留时间等也无法通过这种在线的方式捕获。 还有一个重要的问题是, 由于客户端数据没有暂存机制, 当网络暂时无法使用时, 日志记录接口无法正常调用, 所有的日志也就随之丢失。 第二种方式,在时效性上较差,因为他需要等待数据累计到一定程度,或者网络允许的情况下,如在wifi情况下,才发送,但是占用的带宽相对较小, 对客户端动作的捕获较为灵活。
启明星客户端数据上传目前采用的是第二种方式, 客户端会先暂存日志,等达到2m,在wifi的情况下, 对数据进行打包压缩后,进行上传。 上传成功后直接删除, 否则重试, 三天之内无法上传,就自动删除。 虽然日志同样有丢失的可能,但是总体来说讲,比第一种上传方式更有优势。

埋点的三种方案

埋点的三种方案

 

  1. 传统埋点 开发者直接在客户端埋点。
    • 优点: 开发者可以随意的在任何地方添加埋点
    • 缺点: 成本高,每次埋点的增删改都需要发版,很难控制。启明星现在采用的就是传统的埋点方式, 由于之前没有统一的规划, 相关页面的同一个按钮,不同的版本功能不同, 但却埋了同一个点, 造成统计比较混乱。之后我们引入了埋点下发平台,虽然一定程度上缓解了这种问题,但是由于其灵活性以及主观性, 问题依然无法避免。
  2. 可视化埋点 由于传统埋点的一系列问题, 自然而然的就产生了可视化埋点的方案, 用可视化交互的手段来代替写代码,将核心代码和配置,资源分开, 在app启动是通过网络更新配置和资源来实现埋点功能。
    可视化埋点的大体流程如下: 首先埋点服务平台与埋点客户机做关联, 包括客户机包含的埋点模块扫描当前整个客户端页面的控件,形成控件树,并将当前页面截图,发送给埋点服务端平台; 埋点服务端平台接收到截图和控件树数据后,在服务端重新绘制app界面,通过可视化交互的方式,给当前页面需要埋点的控件上添加事件,添加完毕后,形成配置文件, 并发布上线。 装有埋点模块的所有客户端,接收到配置文件并解析, 根据配置为页面中相关的控件添加监听事件, 当这些控件出发事件时记录日志。
    其中有很多细节的地方需要注意:

     

    • 可视化埋点也需要考虑不同版本之间埋点的差异
    • 可视化埋点在分发埋点配置文件的时候,会有延迟或者丢失的情况, 有的客户端有可能收不到或者很久才能收到配置文件,这样埋点的时效性会大打折扣
  3. 无埋点 所谓的无埋点,其实也就是全埋点, 它和可视化埋点很像, 可视化埋点是根据埋点配置来收集数据,而无埋点方案则是尽可能的收集所有控件的操作数据。 实现原理也很简单, 客户端添加扫描代码, 为每个扫描到的控件添加监听事件。 当事件被触发后,记录日志。
    其实我想,大家对此也不陌生,比如很早之前,对PC站点的统计, 各大分析平台,都需要在网页<head></head>之间添加一段js代码。 其实那段js代码, 就是我们现在提到的无埋点的扫描代码。

这里强调一下, 由于可视化埋点是在需要的时候才埋点, 所以他并不能回溯事件,也就是说,我们只能统计需求提出后,埋点开始的所有的数据,埋点之前的数据我们是拿不到的。 而无埋点方案, 在开始埋点的时候,所有的数据已经都被记录了, 所以他可以查看之前的数据 (这里的之前也是相对与提统计需求的时间,而不是相对于埋点的时间), 也就是说他可以做回溯。 而这种回溯是建立在大量存储要求的基础上的。

总结: 不管是哪种解决方案,我们的目的只有一条,就是尽可能多的收集需要的数据, 所以在实际操作过程中, 我们可以根据具体情况,多种方案相结合使用

第三方分析平台

目前,各大公司都有自己的统计平台,数据的收集也由自己完成, 比如我们之前的启明星平台, 对于更好的分析业务是个不错的选择。 一些创业公司, 没有这样的条件,其实可以选择第三方的统计分析平台,他们提供了各种数据收集 ,统计的服务, 更方便快捷。 目前比较流行的平台有
UmengTalkingDataGoogleAnalyticszhugeIO(诸葛IO)Mixpanelsensorsdata(神策)heapGrowingIO等。 这些平台各有各的特点, 在数据收集方面,我文中提到的基本上都有涉及到。 大家可以多多了解一下。

简介

互联网的发展,带来了业务种类的日新月异,随着业务的增长,随之而来的,就是业务日志指数的递增。一些公司每条业务线, 提供服务的线上服务器就达几百台之多, 每天的日志量超百亿。如何能够将散落在各服务器上的日志数据高效的收集汇总起来, 成了在数据分析处理之前必须解决的问题。

一个优秀的数据收集框架,需要具备三点特性,一是低延迟,二是可扩展,三是容错性。

  1. 低延迟从Log数据产生到能够对其做分析,希望尽可能快的完成数据的收集。 在批处理或者离线分析中,对数据的实时性要求并不高,但是随着大数据的发展,实时计算的能力越来越强,实时分析的场景也越来越多,所以对日志收容的实时性要求也越来越高。
  2. 可扩展性日志分布在服务器集群上,由于业务或者系统的原因, 集群的服务器会发生变化,如上线,下线,宕机等, Log收集框架需要能够相应的做出变化,易扩展,易部署。
  3. 容错性Log收集系统需要满足大的吞吐以及承受足够的压力, 这就意味着Log收集系统很可能面临宕机的风险, 在这种情况下, Log系统需要有不丢失数据的能力。

各大互联网巨头都开发了自己的日志收集工具, 比如apache的chukwa,facebook的scribe, cloudera的flume以及ELK stack(归属于Elastic.co公司)组合中的logstash,都是目前比较流行的开源的日志收集框架。 除此之外,linkedin 的kafka 和 阿里的TT(TimeTUnel), 是高效的数据传输框架,在其基础上,可以方便的搭建出高性能的数据收集框架。阿里通过TT搭建的数据收集系统,服务了一半以上的公司业务, 同时TT在hbase的支撑下,还可以作为大吞吐的消息队列来使用。

接下来,我们就来逐一的了解一下这些数据收集框架

chukwa

chukwa 是apache 开源的针对大规模分布式系统的日志收集和分析的项目, 它建立在hdfs以及mr框架的基础上,完全继承了hadoop的扩展性和稳定性。chukwa还包括了一系列组件,用于监控数据,分析数据和数据可视化等。 架构图如下

picture1

从架构图上可以看出, chukwa大致分为五个部分:

  • hadoop和hbase集群,用于chukwa处理数据
  • 一个或多个agent进程, 将监控的数据发送到hbase集群。 启动有agent进程的节点被称作监控源节点
  • Solr云集群,用于存储索引数据文件
  • 数据分析脚本, 概括hadoop集群的健康状况
  • HICC, chukwa的可视化工具

由于依赖于mr去处理数据,所以chukwa效率注定不会太高,整个数据流在数据处理间断吞吐量急剧下降。 另外,chukwa设计时就没有将它定位为单纯的日志收集工具,而是囊括数据的分析处理, 数据可视化等功能的完整的数据分析框架, 在这样的设计思路下, 数据收集和数据分析俩大任务在优化目标上并不相同,甚至有可能相悖。所以优化效果并不明显。 与其如此,还不如专一的定位在数据收集领域,数据分析和处理等交给其他成熟的框架来实现, 如Hive、Impala等。 也出于这些原因,chukwa并没有被广泛的使用。

scribe

scribe 是Facebook开源的日志收集系统,在facebook内部被广泛使用。 scribe主要用于收集汇总日志流,易扩展,并且能够保证在网络和部分节点异常情况下的正常运行。 其架构图如下:

picture2

应用系统中每一台日志服务器都会部署scribe服务, scribe服务收集节点信息,并将数据发送到scribe中央服务, scribe中央服务是多组scribe服务集群。如果scribe中央服务不可用,本地的scribe服务就会将信息写到本地磁盘,当中央服务可用时重新发送。 scribe中央服务将数据写入到最终的目的地,典型的存储包括nfs或者dfs, 当然,也可以重新写到下一个scribe服务中。

scribe将客户端日志组织为类目和信息俩个部分,以此来唯一确定一条消息。 类目用来描述信息预计的目标位置, 可以通过scribe server中配置来指定。 类目同样也支持前缀方式的配置, 默认可以在文件路径中插入类目名称。scribe在一些特定case下会丢失数据:

  • 如果客户端的scribe既不能连接到本地文件系统,也不能连接到scribe中央服务器
  • 如果客户端scribe服务崩溃, 会造成内存中的少量数据丢失,但磁盘数据不会丢失
  • 多种情况并发,如重发服务无法连接到任何的中央服务器,而且本地磁盘已满
  • 小概率的延迟导致的消息冲突

从架构图上可以看到,agent是作为thirft的客户端与scribe中央服务器通信的,这样做的好处显而易见, 我们可以采用多种编程语言来开发我们的数据收集客户端,具备较大的灵活性。但是依赖于thirft框架,其稳定性与吞吐量受到了thirft的制约, 同时引入消息队列, 整个收集框架略显承重。

flume

说起Flume 大家并不陌生,flume是目前使用的比较广的日志收容工具。 先说说flume的历史,flume早期是由cloudera 开发设计的, 目前将其早期的版本称为flume-og。 随着大数据的发展,flume的 工程代码变得越来越臃肿, 再加上核心组件设计不合理、核心配置不标准等,造成flume的越来越不稳定。 2011年10月22号,cloudera 完成了Flume-728,对 Flume 进行了大刀阔斧的改造,随后被纳入Apache阵营,更名为Apache Flume,开启了flume-ng的时代。

我们首先来看一下flume-og是怎样的一个存在。

flume-og架构图

picture3

从架构图上我们可以了解到, flume-og 有三种角色的节点,代理节点(agent)、收集节点(collector)、主节点(master),agent 从各个数据源收集日志数据,将收集到的数据集中到 collector,然后由收集节点汇总存入 hdfs。master 负责管理 agent,collector 的活动。 仔细看,我们会返现, agent、collector 都由 source、sink 组成,代表在当前节点数据是从 source 传送到 sink, 这也就意味着,节点中没有专门的缓存数据的模块,节点之间的数据阻塞极易发生, 再加上,数据流经的缓解太多,必然会对吞吐造成影响。同时, 为了提高可用性, 引入zk来管理 agent, collector, master的配置信息,大大增加了使用和维护的成本。

flume-ng架构图

picture4

flume-ng节点组成

picture5

改版后的flume-ng, 只保留了一种角色的节点,代理节点(agent), 没有了collector和master节点,这是核心组件最核心的变化,大大简化了部署和维护的成本。 同时将节点由之前的source, sink升级到现在的source, channel, sink三部分,channel专门用于传输过程中数据的暂时缓存。 flume-ng不在依赖于zk,更加灵活,轻便。自带多种类型插件,可以从多种数据源中收集数据,将数据送入到指定的目标存储中, 借助自定义source,channel和sink,不断可以扩展数据收集的source,channel,sink类型,还可以实现除日志收集之外的其他功能。 不同类型的agent直接可以相互连接,形成Pipeline, 完成更加复杂的功能。 这也是flume-ng越来越流行的重要原因。

logstash

logstash 是基于实时数据管道能力的数据收集引擎, 它可以从不同的数据源整理数据,统一写入到你选择的目标存储中。 清洗和规范你的数据,方便下游分析和可视化使用。

架构图如下:

picture6

从架构图看,logstash和flume-ng的设计思想很相似, flume-ng的agent由source,channel,sink三部分组成, 而logstash实例由input,filter和output三部分组成。 input同source一样,用于从数据源中收集数据。 filter和channel略有不同,filter是对input收集上来的数据做一定的处理后交给output。 默认的filter有 grok filter(用于结构化数据), mutate filter(用于更改数据结构,如数据字段更名,移除,替换等),drop filter(彻底删除数据),clone filter(拷贝数据), geoip filter(通过ip地址获取额外的信息)等。 output将filter处理后的数据送入的指定的存储或者下一个logstash的实例。

logstash同flume-ng一样,在实现日志收集功能的基础上,通过实现和更改logstash的input, filter, 和output插件, 可以将一些我们想要的功能,很方便的嵌入到数据收集的整个过程中, 加速我们对大量的多样话数据的感知能力。

大多数情况下, logstash作为elk套件的日志收集框架,实现实时日志分析时使用。

Kafka

picture7kafka 是 linkedin 2010开源的基于发布订阅模式分布式消息系统,之后加入apache阵营,更名为apache kafka. 其架构如下: 整个系统由三部分节点组成:

  • producer 产生指定topic的消息
  • broker 在磁盘上存储维护各种topic的消息队列
  • comsumer 订阅了某个topic的消费者从broker中拉取消息并进行处理

broker对topic的管理是基于顺序读写磁盘文件而实现的,在kafka内部,支持对topic进行数据分片(partition), 每个数据分片都是一个有序的, 不可更改的尾部追加消息队列。队列内每个消息都被分配一个在本数据分片的唯一ID,也叫offset, 消息生产者在产生消息时可以指定数据分片, 具体方法可以采用round robin 随机分配, 也可以根据一定的应用语义逻辑分配, 比如可以按照用户uid进行哈希分配,这样可以保证同一用户的数据会放入相同的队列中, 便于后续处理。 也正因为如此, kafka有着极高的吞吐量。 在kafka的基础上实现日志收容有着天然的优势:

  • 方便实现 开发收集数据的producer和写数据的consumer即可, producer从日志服务器上收集日志,送入broker, consumer从broker拉取数据,写入到目标存储
  • 高性能 天然的高吞吐,较强的可扩展性和高可用性, 消息传递低延迟

TT(Timetunel)

 

是阿里开源的实时数据传输平台,基于thrift通讯框架实现,具有高性能、实时性、顺序性、高可靠性、高可用性、可扩展性等特点。

其架构如下

picture8

整个系统大概分四部分:client,router, zookeeper,broker

  • client 用户访问timetunnel的接口,通过client用户可以向timetunnel发布消息,订阅消息。
  • router timetunnel的门户,提供安全认证、服务路由、负载均衡三个功能。router知道每个broker的工作状态,router总是向client返回正确的broker地址。
  • zookeeper timetunnel的状态同步模块,router就是通过zookeeper感知系统状态变化,例如增加/删除broker环、环节点的增删、环对应的topic增删、系统用户信息变化等。
  • broker timetunnel的核心,负责消息的存储转发。broker以环的形式组成成集群,可以通过配置告知router哪些数据应该被分配到那个集群,以便router正确路由。环里面的节点是有顺序的,每个节点的后续节点自己的备份节点,当节点故障时,可以从备份节点恢复因故障丢失的数据。

和kafka类似, tt自身也只是一个数据传输的工具,并没有日志采集的功能,但是在它的架构之上,我们很容易去构造一个高性能,大吞吐的数据收集工具。

picture9

如上图,tt实现的收容框架,大致分为三部分:

  1. clientAgent基于TTclientAPI 实现的日志收容客户端,被安装在日志服务器上,用于收集数据并将数据送入到消息通讯层;如TailFIle agent, 通过linux的notify机制,监控文件变化,将数据实时的送入消息通讯层
  2. 消息通讯层有client agent收集上来的数据,经过tt集群传输后,以一定的数据格式暂时存入底层hbase集群。 消息通讯层,还实现了发布订阅的消息机制, 通过TTclientAPI可以订阅消息通讯层的数据.
  3. DeepStorage通过订阅消息通讯层数据,通过不同的writer将数据写入到不同的存储中,用于接下来的分析处理

我相信大家现在对这几种框架有了初步的了解了,在开始自己的数据分析之旅前,请根据自己的业务需要,选择合适的收集框架。

本文转载自:https://yq.aliyun.com/articles/67250?spm=a2c4e.11153940.blogrightarea58780.17.4e452d3dzgJIFX

共有 人打赏支持
hblt-j
粉丝 22
博文 199
码字总数 71424
作品 0
海淀
架构师
私信 提问
Kafka实战-Flume到Kafka

1.概述   前面给大家介绍了整个Kafka项目的开发流程,今天给大家分享Kafka如何获取数据源,即Kafka生产数据。下面是今天要分享的目录: 数据来源 Flume到Kafka 数据源加载 预览   下面开...

smartloli
2015/07/02
0
0
基于Flume+Kafka+Spark-Streaming的实时流式处理完整流程

基于Flume+Kafka+Spark-Streaming的实时流式处理完整流程 1、环境准备,四台测试服务器 spark集群三台,spark1,spark2,spark3 kafka集群三台,spark1,spark2,spark3 zookeeper集群三台,spa...

闪电
2016/06/28
1K
3
PHP性能分析工具XHProf安装使用教程

HProf是facebook开源出来的一个php轻量级的性能分析工具,跟Xdebug类似,但性能开销更低,还可以用在生产环境中,也可以由程序开关来控制是否进行profile。基于浏览 器的性能分析用户界面能更...

开元中国2015
2015/05/18
108
0
【转】全面质量管理常用七种工具

所谓全面质量管理常用七种工具,就是在开展全面质量管理活动中,用于收集和分析质量数据,分析和确定质量问题,控制和改进质量水平的常用七种方法。这些方法不仅科学,而且实用,作为班组长应...

gehui
2015/08/10
0
0
性能数据收集工具--Allmon

Allmon 是一个通用的系统收集和对性能和可用性监测的存储数据。该项目的主要目标是创建一个通用系统的各种数据存储系统的性能,卫生,质量和有效性的监控用途的集合。该系统还提供了一组数据...

匿名
2009/12/08
1K
0

没有更多内容

加载失败,请刷新页面

加载更多

移植Modbus到STM32F103(2):移植FreeModbus到usart3并运行示例代码

FreeModbus是Modbus的一个被广泛移植的实现。其源码在github,最新版是1.6。 FreeModbus支持Modbus功能码里的0x01~0x06,0x0F~0x11和0x17,对一些功能比如异常诊断和读事件计数等功能码并没有...

Konstantine
今天
3
0
浅谈神经网络(神经网络篇)

背景 之前写过浅谈神经网络基础篇,简单介绍下机器学习这块内容,用于扫盲。本文正式将神经网络,这部分是深度学习的基础。了解完可以掌握强大的机器学习的方法,也可以更好的了解深度学习。...

Uknowzheng
今天
3
0
移动硬盘变为RAW格式后的修复

在Mac上使用自己的移动硬盘结果文件系统格式变为RAW; 在自己windows笔记本上使用chkdsk H: /F进行修复,修复日志如下: C:\Users\mengzhang6>chkdsk H: /F文件系统的类型是 NTFS。卷标是 do...

晨猫
今天
3
0
10 Git —— 标签管理

10 Git —— 标签管理 本节内容: 命令git tag <tagname>用于新建一个标签,默认为HEAD,也可以指定一个commit id;命令git tag -a <tagname> -m "blablabla..."可以指定标签信息;命令git......

lwenhao
今天
3
0
小程序设置垂直居中,水平居中

如果子容器中的view需要居中的话,那需要在父容器中设置居中 水平居中: display: flex; flex-direction: column; align-items: center; 垂直居中 display: flex;align-items: cen...

淘幻幻
今天
4
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部