构建个性化推荐
构建个性化推荐
最近在疯狂学习推荐相关知识,才发现之前对于推荐的认识有多么的简陋o(╥﹏╥)o (也同时说明了我现在进步很大,哈哈) 目前为止,感觉对推荐的了解总算是入了门,所以再写一篇文章总结一下推荐的基本流程及概念和部分简单的算法模型
1 目前主流推荐流程概述
开局一张图,剩下全靠编~
这个流程基本上就是现在的主流流程了,接下来我来讲述一下分成4层的目的
召回:召回层的出现是为了解决目前排序层的模型无法处理超大数据的问题,如果有一天排序层能够快速排序整个资源池的数据,那召回层也就没有存在的必要了。
所以召回层的目的,就是先筛选出资源池的部分数据(几千或者几百),让接下来的排序层模型能够实时处理数据。目前大部分系统使用的依然以多路召回为主,当然实力强劲的企业也会使用模型去进行召回。
粗排:可以忽略,跟召回的目的差不多,也是为了进一步减小排序的工作量,比方说可以在粗排阶段,过滤掉用户最近看到过的作品,来减少输出量。(我也不知道为啥叫粗排不叫再召回。。。)
精排:可谓是推荐系统的重中之重,关于推荐排序的论文数不胜数,可见其重要性。排序的目的,就是根据当前用户 ...
Elastic Search 存储方式
Elastic Search 存储方式
个人习惯,一般学习数据库,主要学习其数据存储方式和索引结构。理解了这些,碰到很多优化方面的问题会事半功倍。
1 es写入数据过程先从数据如何被写入开始讲起,es是分布式的数据库,所以其写入流程也会相对复杂一点。
在es中,节点主要可分为master节点和数据节点(还有其他的节点类型,但只有这两类节点集群就能运行),其中数据节点承担了数据写入的工作。
请求路由:当写入请求被任一数据节点接收后(数据节点默认一般也担任着协调节点的功能),然后通过其要写入的文档id计算要写入到那个主分区中(分区策略算法为 shard = hash(id) % number_of_primary_shards)
再通过查询分区元信息,确认该主分区Shared1位于数据节点Node1
随后将请求转发到该数据节点Node1
具体写入:Node1收到转发的请求后,首先对写入请求进行校验和预处理(像动态mapping就是这一步操作的),然后将文档数据写入到主分片Shared1。但由于es对读性能做出了巨大优化,导致写性能相对变的很差,所以在具体的写入文档时,es也做了很多 ...
构建个性化推荐--工程方向
构建个性化推荐–工程方向
本篇文章主要面向推荐系统工程方向的介绍,而非算法相关的知识。
1 个性化推荐的演进我算是有着做个性化推荐一路从0到1的经历的,简单分享一下我所经历的演进过程。
定义排序和筛选条件的推荐
算是个性化推荐最初始的雏形,那时候在做APP首页改版的时候,接到了这项需求。
首先让用户自主选择喜好的方向,解决一部分冷启动的问题。
然后根据PD定义的排序规则(什么时间啊,级别啊之类的)和筛选条件(主要来自于用户选择的标签)直接查库就好了,因为每个用户的标签或多或少有些不一样,算是有了一点个性化的影子了。
优点:做的快,说白了就是条SQL,实现很简单。
缺点:效果当然就不会那么好了,比如说,有很多人,他是不选标签的,那个性化就不存在了。
加入用户标签的推荐
为了解决不选标签的这些人,那就要想办法从用户的行为中推测出用户的标签。
因此我们要记录用户的行为事件,正好上一次APP改版的时候,相关事件的埋点已经记录下来了。
但是由于技术能力还不够,由行为推测标签还是靠分析师和PD设计具体的分类规则,进行计算用户标签的。并且,计算标签也是T+1,跑离线 ...
日志平台构建--日志抓取
日志平台构建
对于初具规模的公司来讲,日志系统都是属于不可或缺的一部分,本文通过应用日志作为示例,讲解日志采集、日志加工、日志展示相关流程。
1.日志采集目前比较成熟且使用广泛的日志采集工具有以下两种
Flume
目前来讲使用最广泛的日志采集框架,作为apache项目之一,维护和更新不必担心。且其功能支持相比于filebeat来讲会更多,但是使用起来也会相对复杂一点。
Filebeat
Filebeat属于elastic旗下beats的一种,很轻量级的日志采集框架,只能用于抓取文件使用,相比于flume来讲扩展性更低,但是更易部署。
我们目前两种方式都有用到,但是考虑到之前的应用日志抓取使用的就是ELK技术栈,所以为了使改动最小,本次对于日志采集使用的为filebeat。以下是filebeat日志采集的配置文件,供大家参考,https://www.elastic.co/cn/downloads/past-releases/这个地址可以下载elasic的任意版本全家桶。
123456789101112131415161718192021222324252627 ...
canal部署以及使用
canal
canal是阿里开源出的mysql binlog监听框架,说实话,坑挺多,而且github上维护的很不频繁,感觉又是无人维护的状态了,所以使用要慎重
canal搭建前期准备1.首先要开启mysql的binlog日志(阿里云上默认开启),可以使用以下命令查看binlog开启状态
12show variables like 'log_bin';show variables like 'binlog_format'
如果为mac环境,则需要在/etc新建my.conf(mac安装就自带了mysql),并在配置文件中写入如下
1234567[mysqld]# log_bin# 开启binloglog-bin = mysql-bin # 选择row模式binlog-format = ROW server_id = 1
非mac环境,在mysql对应安装目录下conf文件增加上述配置即可。要注意选择row模式,否者会拿不到变更sql的很多信息
2.获取canal部署包,可以在git上直接下载对应版本的canal.depl ...
Spring--AOP实现分析
Spring-aop
AOP是指面向切面的程序设计,该设计理念可以让程序同时关注相似类型的所有业务逻辑(在AOP中也称为切面),而不必每个都要处理,从而让程序可以对切面进行统一处理,降低了代码冗余,也降低了耦合度。
1 Spring中的AOP在Spring中声明AOP只需在类型加上@Aspect注解(AOP的jar包要先引进来),再使用@Component注解,将AOP放入到容器中被Spring管理。
接着可以在声明的AOP中,定义Pointcut和Advice。
定义Pointcut时可以使用切点表达式来定义,切点的含义就是指AOP要在哪些地方生效。
Advice在Spring中有五种,分别为Before、Around、After、AfterReturning、AfterThrowing。
以下是声明AOP的简单例子。
1234567891011121314@Aspect@Componentpublic class ExampleAop { @Pointcut("@annotation(com.chuyu.live.common.annotation.L ...
Spring--bean的生命周期一览
Spring–bean的生命周期
Spring作为web开发中使用最广泛的框架之一,其本质是一个对象容器,用于帮助开发者管理对象。本文基于Spring5.0.x版本代码,重点讲解Spring中bean的整个生命周期,来方便大家了解Spring的部分设计理念。
1.对象创建Spring的本质既然是一个对象的容器,那么必然要经过以下步骤创建出对象添加到容器中,这样才能进行管理。
获取到有哪些对象应该让我去创建
怎么样去创建
由于本文重点讲解的为对象的生命周期,所以对于扫描对象只是一个最基本的介绍。
1.1 获取到有哪些对象应该让我去创建使用过Spring的小伙伴应该都知道,对于spring-boot应用会自动扫描其根路径下的所有对象,或者使用@ComponentScan注解和xml配置<context:component-scan/>方式新增扫描basePackages路径,用于让Spring能够感知到我应该去创建哪些对象。
当然Spring提供了远不止这些的途径用于让对象纳入被管理的范围,比如说很多框架常用的ImportBeanDefinitionRegistrar机 ...
带你手撸令牌桶限流算法
带你手撸令牌桶限流算法1.漏桶算法和令牌桶算法限流为流量控制策略中的一种,流量控制策略一共可大致分流、限流、降级熔断三种。
漏桶算法和令牌桶算法都属于限流的基本算法,但是各自有各自的特点
漏桶算法
上图是从网上拷的一张算法示意图,其中,桶的体积表示能够处理请求的最大值,水龙头的水表示外部请求,漏下去的水表示处理的请求。
也就是说,不管水龙头的水怎么往下流,开最大也好,关掉也好,都不会影响到桶往下滴水的速度,这也是漏桶算法最核心的一点,能够保证流量的平滑性(请求处理的速度基本一致),如果外部请求超过了桶的容积,那么水就流到桶外去了(这些请求也就都抛弃掉了)。因此,漏桶算法并不能满足对于突发流量高峰的场景,所以漏桶算法的具体实现不再阐述。
令牌桶算法
同样的,从网上拷的一张令牌桶的示意图。
令牌桶相对于漏桶算法来说,首先多了一个缓存区,使其能够处理突发的流量高峰(就是削峰填谷的作用),并且令牌的生成是每时每刻都在生成的,而不像漏桶算法,如果一段时间一直没有请求,那么桶就一直是空的,这样就能够保证,在一段时间内,请求的处理的平均速度等于令牌生成的速度。
2.开始手撸令牌桶关于令牌 ...
Mysql全方位解析
mysql全方位解析
写这篇文章缘起于对mysql相关的知识一直反复的看、反复的忘,不总结下来写篇文章真不行。
1 当前主流数据库的储存方式数据的存储方式是数据库的核心,以下四种数据库加起来可以至少占一多半的使用场景(本篇文章重点讲解Mysql,列出其他数据库是为了进行对比)。
Mysql
Mysql为开源的关系型数据库。我们一般常用的都是innodb存储引擎。
在innodb存储引擎中,表数据储存方式为B+树(聚簇索引),每张表都必须有一个聚簇索引(非聚簇索引是我们平时在表中添加的普通索引,也称二级索引),在创建表时,如果表有主键则选择主键,如果没有主键则选择一个唯一索引,如果都没有,使用行号当做聚簇索引。
Hive
Hive的数据是存放于HDFS上的(就是普通文件),对于分区的概念则是用目录进行区分。
其基本的数据存放格式类似于CSV之类的,可以在创建表的时候指定列、行分隔符进行区分。
同时也提供了几种复杂存储方式如TextFile,RCFile,SequenceFile,AVRO,ORC和Parquet格式
Hive本身不提供索引(可以使用Impala的 ...
zookeeper的核心-watch机制
zookeeper的核心-watcher
上篇文章讲过zookeeper的灵魂是ZAB协议,是其能够实现分布式的基石,但只有数据一致性协议还是无法应用于生产场景中的,本篇文章重点介绍一下zookeeper提供的watcher,基本上,所有依赖于zookeeper的框架、相关使用场景都严重依赖于watcher。
1 zk的相关使用场景在生产环境中,使用ZK主要是应用于以下几种场景
分布式下的主节点选举。
多数的分布式场景下,都是具有主节点(也称Master节点)的,由主节点负责统一调度、管理所有应用,在这种情况下,主节点就具有单点问题,为了解决单点问题,基于zookeeper来保证当主节点宕机后,能由其他节点自动选举为主节点。
分布式队列
因为ZK保证了分布式条件下的数据一致性,所以能够提供分布式下的队列支持,并能够保证进队、出队的顺序性。
集群监控
因为在ZK中有临时节点和watcher的存在,可以感知到整个分布式集群任意一台机器的离线,从而实现对集群机器存活状态的监控
类似于MQ的订阅通知
zk有watcher机制,可以让客户端感知节点、节点数据的变化来 ...