前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >你的每一次点击行为,是如何变成数据的?| 聊一聊互联网公司的内部数据采集

你的每一次点击行为,是如何变成数据的?| 聊一聊互联网公司的内部数据采集

作者头像
数说君
发布2018-04-08 16:42:50
1.7K0
发布2018-04-08 16:42:50
举报
文章被收录于专栏:数说工作室

数据是怎么来的?

在很多行业,数据都是人工收集来的,比如医学疾病数据、环境数据、经济数据等。数据的更新周期也比较长,比如年度、月度。

但互联网行业不一样,这个天然的流量行业,数据量巨大,更新周期按天就算长了,通常有小时级、分钟级、实时秒级,甚至来不及落入表中,直接对实时流数据就进行计算。

最后说的这种「流式计算」,之前介绍过:什么是流式计算 | 另一个世界系列,对数据流实时进行计算,不需要存储到表里,主要为了满足一些实时级的需求,比如实时监控、实时个性化推荐等。

不管是「流式计算」还是存储到表里再计算,总要对数据源进行采集,那么数据源在哪里?我们每天打开APP、浏览网页、点击、下单、支付等等这些行为,是如何落入表中、变成数据的?

这一切都来源于一个叫「日志」的东西,它记录了何时、发生了什么,也即最原始的事件。这些日志信息是数据的源头,互联网公司通过搭建采集框架,把日志变成数据存储在表里,或变成数据流进行流式计算。

日志的采集工作非常重要,收集好数据,公司才能更好的把精力投入在业务价值的挖掘上。(当然我说的是内部的数据采集,外部的数据爬取、购买的第三方数据,不在本文讨论范围之内)

各大互联网巨头都开发了自己的日志采集系统,如 Apache 的 chukwa,Facebook 的 Scribe,Cloudera 的 flume,Linkedin 的 Kafka, 这几个是目前比较流行的开源日志收集框架,国内公司360使用的是基于 Scribe 的日志收集系统,阿里使用的是自己的 TT(TimeTunel)。

这里主要介绍一下 chukwa 和 Scribe,尽量用简单的语言来让大家明白其架构思想:

1、chukwa

chukwa 是 Apache 的开源项目,作为 Hadoop 系列产品之一,使用了很多 Hadoop 的组件(用HDFS存储,用MapReducec处理数据),完全继承了Hadoop的扩展性和稳定性。

chukwa包括了一系列组件,用于监控数据,分析数据和数据可视化等。 架构图如下:

(图片源于http://dongxicheng.org/search-engine/log-systems/)

(1)HDFS

  • HDFS 是 Hadoop 分布式文件系统,chukwa采用了 HDFS 作为存储系统。
  • HDFS 支持大文件存储、小并发高速写的应用场景。

然而问题是,日志系统的场景正好相反,需要高并发、低速写大量的小文件。系统中的 Agent 和 Collector 也是为了满足这样的支持。

(2)什么是 Agent

  • Agent 是驻守在各个节点上的负责收集数据的程序。
  • Agent 又由若干 adapter 组成,adapter 运行在 Agent 进程以内,执行实际收集数据的工作,而 Agent 则负责 adapter 的管理,包括启动和关闭 adaptor。
  • Agent 将数据通过 HTTP 传递给 Collector

(3)什么是 Collector

  • Collector 收集各个 Agent 传来的数据,合并后,将这些数据写入 HDFS。
  • 然后由 Map-Reduce job 进行数据的预处理。

实际上,chukwa 的效率并不高,因为它并不是单纯的日志收集工具,而是包含了数据的分析处理、可视化等功能的完整数据框架。但是,数据收集和数据分析俩大任务在优化目标上并不相同甚至一定程度上是相悖的。这样会影响到对数据的收集效率。

很多人认为,这样还不如只专一的做数据收集,把数据分析等交给其他成熟的框架来实现,也因此chukwa并没有被广泛的使用。

2、scribe

Scribe 是 Facebook 的开源日志收集系统。它主要思想是「分布式收集,统一处理」,从各种日志源上收集数据,存储到一个中央存储系统中。框架如下:

(Scribe 架构图1 来源于http://dongxicheng.org/search-engine/log-systems/)

(Scribe 架构图2 来源于网络,侵删)

具体而言,在分布式系统中,每一个节点都会部署 scribe 服务(local scribe server),收集此节点的日志信息,并将其发送给scribe中央服务(central scribe server)。

Scribe 的一个重要优点是容错性。节点信息发送给 scribe中央服务之后,如果中央服务系统挂!了!(crash),怎么办?

此时本地的 scribe服务就会将信息写到本地磁盘,当中央服务可用时重新发送。 scribe中央服务将数据写入到最终的目的地。是不是很机智!当然,在一些特点情况下,Scribe 也会丢失数据,比如:

  • 如果客户端scribe服务崩溃, 会造成内存中的少量数据丢失,但磁盘数据不会丢失。
  • 客户端的scribe既不能连接到本地文件系统,也不能连接到scribe中央服务器,这种情况除非神仙来了!
  • 多种情况并发,如重发服务无法连接到任何的中央服务器,而且本地磁盘已满,这种情况神仙来了也没办法了!
本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2018-03-12,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 数说工作室 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
大数据
全栈大数据产品,面向海量数据场景,帮助您 “智理无数,心中有数”!
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档