没有合适的资源?快使用搜索试试~ 我知道了~
离线数仓串讲文字版.doc
需积分: 13 1 下载量 183 浏览量
2022-05-08
00:29:41
上传
评论
收藏 42KB DOC 举报
温馨提示
试读
21页
离线数仓串讲文字版.doc
资源详情
资源评论
资源推荐
那么去面试,首先,第一步上来应该是自我介绍。自我介绍控
制在 分钟简单过一遍。其次,就介绍一下你的工作经历,比如
说你之前在哪家公司,是什么岗位,做过哪些项目,你就可以这么
讲。这三年来从最早的,从 从采集平台的搭建,大概用了几个
月时间,在后面开始做离线数仓。再到差不多一年前开始做实时的
啊,这是大概的一个项目经历,大概的时间点跟内容简单过一遍,
那么接下来面试官就该问你了。可能他会这么问,第一个介绍一下
你最熟悉的项目。或者说介绍一下你最近做的项目啊,他是选择性
的,那如果没有你就自己主动讲,下面你介绍一下项目细节。都可
以。那接下来就正式开始了,你说一开始,你当时也是没什么经验,
然后跟着你们的组长一步步做了,从买服务器开始,从 。那首
先,服务器选择的是云服务器,更方便更简单一点。那其他的这些,
像什么框架版本这些,先不提,他有问到再说。那我们的数据来源
主要有两个,第一个就是前端埋点数据,用户行为数据,另一块,
就是后端这边产生的业务数据,那一开始你们就考虑将这两部分的
数据同步到 。那首先,你们对于前端埋点的数据,是通过一个
做了一个负载均衡,将数据发送到日志服务器上面,那上面
的 程序就会将数据落盘形成日志文件。
之后我们考虑的就是如何将数据采集到 。经过我们的调研,
也发现比较流行的就是 ,因为,它特别擅长采集文件,而且
效率和可靠性方面。都比较不错,那在 ?经过你了解它组成
主要有一部分叫 。还有一个叫 ,还有一个叫
那一开始我们选型的时候首先考虑的是 ,后来发现
从 开始就支持了一个叫 。它支持断点序传和多目
录,非常适合我们的场景。那我们就是选择使用的 。
但是我们也研究过,他有这么一个问题,他之所以支持断点续传,
是因为他在磁盘上持久化了一个文件,保存 信息,如果发生
故障,他再重启起来,会先从 文件去读取位置,然后,从指
定的位置,接着去读取文件里的内容。但是这个时候,由于他读取
数据跟保存 不是一个原子性的操作。那么在极端情况可能出
现数据采集到了还没来得及持久化 ,这个时候出现宕机再重
启的话可能会出现少量的重复。当时我们也考虑过要不要处理,也
给了几个方案,第一种,就是处理的话我们可能就需要给他绑定成
为一个原子性操作。也就是添加一个事务,简单修改一下源码,那
第二种我们考虑是,其实这也没必要处理,只要不丢那就不错了。
其次,他发生重复也是极端情况,首先必须是宕机概率比较小。第
二个即使宕机也必须刚好卡在这两个步骤之间,即使有重复也是少
量,所以最终我们开会讨论决定啊,就不在这里进行处理了。那这
个 。 选 择 就 比 较 多 了 啊 , 像 支 持
还 有 ! 还 有 ! 。
是基于内存的,它的优点是传输效率高,但是可靠性差,
毕竟在内存里可能丢失。宕机的话,那它的容量是 个 ",
那 ! 是基于磁盘的。它的传输效率相比于内存的会低一
点,因为还要落盘,但是它的可靠性,会高一点,数据在磁盘,即
使宕机再启动数据还在。它的容量是 万个 "。那还有一个
是使用在有 的场景,! 它的效率,我们是经过
测试的。比如说,我们只使用一个 ! 的效率是高于
! 加 ! 的效率。因为,我们在使用当中
可以省略一个 阶段或者 阶段,它的数据是直接保存在
的磁盘里面。所以,它的特点是传输效率高,可靠性也高,
但是适用于有 的场景。同时,我们当时也发现了这么一个问
题,在 # 的时候 ! 是有 的,他不管我们怎么
设置都一定会携带一个 信息。那在 的时候解决 ,
这个 可以选择性的要或者不要。那由于我们使用的版本是
$ 啊,所以没有这个问题我们就放心使用。这个是 我们的
一个考虑。那同时 它本身也提供了事务的保证,从
到 有一个 事务,从 到 有一个 事
务。还是比较靠谱的,那它里面的同样有几个东西?第一个?就是
拦截器。它可以定义拦截器,那我们在使用过程中也使用到拦截器,
那在这里,我们定义拦截器的目的是做一个轻度的清洗,将 % 格
式不完整的脏数据提前就过滤掉了。没必要让这种脏数据贯穿整个
采集流程,另外,我们这边做的只是当初只是对 % 格式做校验,
没有做复杂的处理转换,分析这些操作,所以,对效率而言影响不
大,可以接受啊,这是我们当时使用的方案。那定义拦截器?就是
你可以介绍步骤,也可以不讲啊,那就是继承一个 & 接
口。然后重写他的几个方法,分别是初始化,单 " 的处理,多
" 的处理,还有关闭,编辑完代码之后,我们会打成 % 包。
然后,上传到服务器上面 的 目录下,然后在 的配
置文件中指定拦截器。要写全类名,然后还有一个多了内部类的名
称 ',这是我们的一个做法。那第二个? 内部有一个
选择器,它主要有两种,默认的是 。他会将一
个 " 发往所有的 ,那这是默认的,我们项目用的也是
这个,因为我们没有做什么分流处理。那第二种 选择器?
是 ,他会将一个 " 发往指定的 。
那一般应用场景?就是做一个分流的时候需要用的,那我们这
边是没有用到这个。那第三个是对 的监控,我们使用的是
,主要的就是监控 的一个事务情况。包括尝试提交
的次数,还有成功提交的次数,那如果我们发现它两者差值较大。
说明发生了大量重试,可能有问题,需要优化啊。那曾经。我们在
首次搭建完,然后第一次遇到活动的时候就出现过这个问题,后来
发现日志一看好像是内存不太够,甚至再久一点出现的 。所以
我 们 对 做 了 一 些 调 整 , 首 先 我 们 将 它 的 内 存 从 默 认 的
()提升到 #*。其次,如果遇到活动,我们会提前动态扩容
服务器。也有可能采集不过来,那这时候我们会提前购买一台云服
器,部署上 的程序。之后,将新服务器与后续
和 ,将其端口和网络打通。之后,修改 的配置,加入
新的链路,打通整个链路。那活动过后,我们也会将这台富余的服
务器给释放掉,那操作流程相反,先断 ,那等数据采集完,
再将服务器退掉。那什么时候采集完?一个是监控网络的 情况,
第二个是看他的事务提交情况,来判断是否采集完了。
那刚才提到我们后面又用了一个 ,其实最早啊,我们的考
虑是没有 的,我们通过 将文件直接采集到 。但
是正是由于那次的问题,那我们意识到如果流量激增,像双十一
#+ 这种大活动。那可能会导致 写入过快,那可能就挂了。所
以,我们考虑中间加一个缓冲。那我们选择的就是经典的消息队列
。一来, 可以起到削峰的作用。因为它的生产端跟消费
端是可以实现一个解耦啊,那如果这边数据洪峰过来,它可以先积
压在 里。那消费者慢慢去消费)不会导致 顶不住。第二
个考虑,是未来我们也规划了,会做一个实时分析系统,那在实时
的架构里面, 也是特别常用的一个数据源。所以,综上考虑,
我们会在这里添加一个 。关于 。第一个,我们考虑是
部署的一个规模,也就是台数,那当时是我们主管提出一个经验公
式,!,! 啊,这个 就是生产峰值速率乘以副本数除以 向
上取整,当时我们生产的峰值差不多也就接近 ( 左右每秒。副
本数,我们设定的是两个,他默认是一个。一个的话,可靠性没法
保证。那我们为了兼顾传输效率和可靠性,我将副本数设成了两个,
那除以 把向他取整得到一,那么这么一计算,三台差不多能够
满足我们的需求,这是我们规模的确定。第二个,就是保存时间 ,
默认保存时间是七天,那我们是将它修改成了三天。因为我
们离线的话需要做到 , 可能涉及到两天的数据,那我们还会再预
剩余20页未读,继续阅读
m0_61824581
- 粉丝: 0
- 资源: 1
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功
评论0