Harper的大数据漫谈(2): 数据采集

前言

这是漫谈系列的第二篇文章了, 这几天看了一些网上其他人写的关于大数据的文章, 感觉要不就是在分析大数据的产业和应用, 要不就是在具体的讲某种技术或者分析某个问题, 动辄就是大数据4v和Hadoop. 这些文章可能写的很好, 讲了很多概念, 我在当初入门的时候也看过一些, 但我个人认为对我的帮助比较有限. 因为这些文章要不就过于理论, 要不就过于具体. 因此我希望自己写的这个专栏可以把具体例子和理论结合起来, 对和我有类似经历的人有更多的帮助和引导.

Harper的大数据漫谈历史文章

Harper的大数据漫谈(1): 什么是大数据

数据采集

在第一篇文章里, 我们举了个开电商的例子讲了什么是大数据, 并且粗略的画了个示意图. 接下来我们继续这个电商的话题, 看看如何把我们的大数据系统最终设计出来.

本系列中考虑的全都是大数据场景, 一般网站后台服务器也是分布式部署的. 只靠一两台服务器就能满足需求的, 一般产生的数据量也称不上大数据. 所以文章中提出的很多问题都由一个隐藏的运维成本.

我们先从数据源和采集开始聊. 大数据中的数据来源可以有很多, 比较常见的就是自己的应用记录的日志, 爬虫爬到的数据, 第三方直接提供的数据等等. 这里咱们开的是个电商网站, 暂且先不考虑去爬对手的竞品以及和第三方合作了, 先从自己收集的用户行为数据搞起吧. 下面是一个在这个场景下的数据采集示意图:

这里蓝色框发生在前端, 也就是网站页面或者手机的APP客户端一类的. 绿色框发生在后端, 主要是业务处理流程. , 红色框主要是数据采集流程, 也属于后端服务.
这里出现了一个名词: OLTP. 如果不了解OLTP和OLAP的话, 后面有个简单的介绍

埋点

埋点就是在程序中嵌入一些代码, 记录用户行为. 埋点按位置可以分成前端埋点和后端埋点. 一个行为的采集具体要在哪里埋点, 主要考虑的是是否可以实现, 实现复杂度, 是否容易扩展, 采集需求有变化的时候是否容易修改等等.

有些用户行为会触发和后端的交互, 这时候通过后端埋点是可以获取的. 比如在前一篇文章里, 我们收集的信息, 主要是用户的浏览记录和下单记录. 其中下单记录可以通过定期访问OLTP数据库获取, 搜索和浏览记录则通常不需要存储在OLTP数据库里面, 事件发生的时候写成本地文件, 等着采集程序采集就可以了.

实际上我们可以采集的用户信息非常多, 其中有一些用户行为并不会触发和后端的交互, 这时候就需要前端埋点了. 比如你在某个页面停留的时长, 具体是通过哪个按钮进入的商品页面, 或者浏览离线缓存中的内容的时候等等. 更有甚者,比如你在安装有一些APP的时候, 它会莫名其妙的请求非必要的麦克风权限或者定位权限, 有可能就是在通过客户端采集你的语音信息和位置信息.

数据采集与业务处理

数据采集与业务处理通常都是两个不同的服务, 因为他们的场景区别很大.

首先, 两者要处理的数据量级差别就很大, 用户的行为数据量远远大于实际的业务数据量. 最直观的:用户想要买一件衣服的话, 可能在网站上浏览了半天看了各种评价, 最后才下一个订单. 所以才会有各种什么用户转化率, 用户留存率一类的分析.

其次,业务处理通常对可靠性要求很高, 不但要求准确无误, 而且要求响应时间不能很长: 如果在你网站上搜个商品搜不出来, 下个订单总是报错, 扣了钱以后订单不见了, 那么客户早就投诉跑路了. 因此业务处理中通常都是用OLTP数据库保证事务性, 想办法满足高并发场景, 在举办双十一等各种活动的时候也要保证响应的快速且准确. 而数据采集虽然也很重要, 但是对可靠性要求并不那么高. 尤其是很多支持商业决策的数据处理, 主要是针对的超大数据量的统计信息进行的分析, 丢失几条数据根本不会有任何影响.

最后, 数据延迟也不一样, 尤其是前端埋点, 由于采集的行为并不一定需要和后端交互, 所以通常都是有个单独的数据上报接口, 整个采集的过程是异步的, 可能几个小时或者几天后才会把你的行为上报上去. 举个例子, 比如我们的电商手机APP为了优化用户体验, 可以把用户的所有行为, 包括屏幕的左滑右滑等等都上报上来. 这些行为很细碎, 不太可能每一次发生都直接上报, 那样性能太差. 比较常见的是本地积攒一批行为, 每过一段时间或者积攒了一定量的行为后统一上报. 如果到了上报的时候恰巧网络不通, 那么就过段时间再上报也不耽误事儿.

基于以上的考虑, 即便是我们的小网站在最开始的时候可能要处理的场景比较简单, 数量并不大, 但在设计上也还是要考虑把他们设计成两个不同的服务, 在保证业务不受影响的前提下, 尽可能的采集数据. 这样会让以后的扩展不那么痛苦.

数据采集系统的设计

接下来我们细化一下那个红色的数据采集系统. 一个经典的设计大概长这个样子:

数据来源有两个: 一是数据上报API服务,用于接收前端的埋点数据上报. 二是业务后端服务埋点, 会以日志的形式记录在后端服务器磁盘里, 通过文件采集程序(比如Flume, Logstash, Filebeat等)收集起来.
这里采集到的数据尚未经过ETL, 很大概率是非结构化的, 也就是纯文本那种, 而且还可能存在乱码, 比如:

2021-02-14 01:00:00 INFO com.harper.bigdata.business(123): 张三搜索了香皂
2021-02-14 01:00:00 INFO com.harper.bigdata.business(123): 张三锟斤拷了脸盆
2021-02-14 01:00:00 INFO com.harper.bigdata.business(123): 张三烫烫烫烫烫
2021-02-14 01:00:00 WARN com.harper.bigdata.business(123): 张三&*&^&^)&*@

这样的数据需要先经过ETL以及数据清洗才能入库. 而

现在也有些公司在服务后端生成数据文件的时候, 就直接写成 Protobuf, Avro等结构化的二进制文件. 好处是文件结构更紧凑, 字段规定的更严谨, 更不容易出现脏数据, 但也有一些缺点, 比如如果文件中间出了问题影响可能会较大, 不容易让人直接看懂等等. 其中的优劣在选型的时候可以自己斟酌.

接下来我们来思考一个问题: 像上面这种采集起来的数据要存储到哪里去呢?

目前最常用的解决方案, 就是放到一个数据管道或者说消息队列里面,比如Kafka或者Pulsar. 这里暂时不做展开, 之后有时间再写, 有兴趣可以先自行了解. Kafka的官方文档写的非常好, 很值得一看. 这样做有很多好处.

首先,这个数据管道解耦了处理逻辑和采集逻辑. 数据采集程序通常应该尽量的简单(Logstash虽然可以支持在采集数据时进行一些过滤和转换, 但都是相对比较简单的), 其中通常不该带有复杂的解析逻辑, 否则和业务耦合过紧会让这个组件并不通用, 升级的时候得和业务模块一起升级才行, 而且以后如果有新的采集需求的话也会很难搞. 有了数据管道, 采集程序就可以不做任何处理, 或者只是做简单的过滤就将数据丢到管道中去. 而数据处理程序则直接消费管道中的内容, 两者以数据管道为接口, 无论是运维还是扩展都会很方便.

其次, 这个数据管道承担了很好的缓冲作用. 数据的生成速度取决于用户的行为, 并非是平稳的,一般人们白天没事儿的时候数据量是顶峰, 晚上人们睡觉的时候数据量是低谷. 而且周末和平时, 活动和非活动期间流量也会差好几倍. 如果我们一直为流量尖峰去配置计算资源, 浪费是非常严重的. 有了这个数据管道, 暂时无法处理的数据就可以被缓存起来, 给我们赢得一些时间去扩展处理资源, 或者干脆不管它, 等流量没那么大了积累的数据自然就会被慢慢消费掉,

最后, 这个数据管道扩展了应用场景. 一般我们对数据的处理分成实时处理和批处理, 二者的处理逻辑未必是相同的. 实时处理一般是分析一些即时状态, 以及提供高度汇总的实时报表, 倾向于低延时. 而批处理则面向比较长时间的历史数据,倾向于高吞吐, 自由度更高, 另外由于可以使用比较复杂的清洗逻辑, 数据可信度也要比实时数据高一些. 有了数据管道的存在, 实时处理和批处理的可以基于各自的处理需求和处理逻辑去消费同一份数据.

附录

OLTP与OLAP

如果对OLTP于OLAP没什么概念的话, 可以看一下这里的简单介绍.
OLTP数据库就是Oracle和MySQL一类的, 擅长事务处理, 强调数据一致性,高并发,对数据的增删改查. 里面存储的通常是系统的当前状态, 比如还未完成的用户订单一类的, 这些数据会经常需要修改状态.
OLAP则强调少写多读, 很少有Update操作, 擅长大规模的数据分析. 里面存储的通常都是历史数据. 比如已经完成的历史订单, 这些历史事实基本上不会再发生改变, 也就不需要 update操作
数据量不是特别大的情况下, OLTP和OLAP之间的界限并不明显, 你也可以用MySQL来做OLAP. 但是在大数据场景下, 往往就需要术业有专攻了.