日志

基于 CCO 的协同过滤推荐

基于 CCO(Correlated Cross-Occurrence) 的协同过滤本质上是一种 Item-Based CF 算法

基于 CCO 的协同过滤推荐

基于 CCO 的协同过滤推荐通过物品之间的共现情况来计算物品之间的关联度,它跟一般的协同过滤算法不同的地方在于一般的协同过滤只能针对单一行为,而CCO算法可以计算交叉行为下的协同关联。

例如:它不仅可以通过用户的浏览行为来告诉你 “浏览了内容A的人可能会浏览内容B” ,它还能结合用户的浏览行为和用户的广告点击行为来告诉你 “点击了广告A的人可能会浏览内容F”

基于单一行为

假设有以下用户浏览行为日志:
用户行为log

整理后得到以下关系:
u1=> [ t1, t2, t3, t5 ]
u2=> [ t1, t3, t4, t5 ]
u3=> [ t2, t4 ]

构建 “用户关于浏览帖子” 的矩阵 V 以及对应的转置矩阵 V^T:
mtV

将 矩阵V^T 乘以 矩阵 V 即可得到浏览帖子的共现矩阵:
mtVV

对数似然比(Log Likelihood Ratio)即LLR。我们根据两个事件的共现关系计算LLR值,用于衡量两个事件的关联度:
LLR
阅读全文

日志

常用推荐算法比较

在推荐系统中常用的推荐算法一般可以分为两类,即 基于内容推荐 以及 协同过滤。另外,还有一类算法专门处理冷启动问题,例如:基于全局最优推荐

基于内容推荐

基于内容推荐(Content-based Recommendations)非常好理解,简单来说就是根据用户偏好的内容给他推荐其他相似的内容。

cb

图:基于内容推荐

例如:从用户画像我们发现某个用户比较喜欢活跃在“音乐”、“体育”、“动漫”、“影视” 这些栏目,那么我们就会更倾向推荐这些栏目的内容给他,我们还发现他平时偏好的是关于 “NBA”、“美剧”、“邓紫棋” 等方面的内容,那么跟这些相关的内容就会有更高的推荐权重。

评价

基于内容推荐的结果一般具有很强的解释性,因为它推荐的就是强相关的内容,但这种强相关的特点也会导致一个很明显的缺陷,它缺乏惊喜度,因此它很难挖掘用户潜在的兴趣。要解决惊喜度的问题,可以采用另一类算法–协同过滤

协同过滤

协同过滤(Collaborative Filtering)推荐本质上也是一个找相似的过程,但它认为的相似不是指物品在属性上的相似,而是指在用户行为的层面上这些物品是否有关联,协同过滤一般可以分为 基于用户的协同过滤(User-CF)基于物品的协同过滤(Item-CF)

用户物品偏好

图:用户物品偏好

基于用户的协同过滤

解释:因为 用户1用户2 都喜欢物品A、B、C、D、E,所以认为 用户1用户2 是兴趣相似的用户,现在发现 用户2 还喜欢 物品F 所以我们认为 用户1 很可能也对 物品F 感兴趣,所以向 用户1 推荐 物品F。

基于物品的协同过滤

解释:因为喜欢 物品A 的大多数都喜欢 物品C,所以可以认为 物品A 和 物品C 是相似的。用户4 喜欢 物品A 所以向 用户4 推荐 物品C。

评价

协同过滤集合了群体智慧,能满足推荐惊喜度,善于发掘用户潜在的兴趣。训练的用户历史行为数据越多,一般训练出来的模型效果也会越好。协同过滤推荐的解释性一般较弱,推荐结果不如基于内容推荐算法直观,当然这是算法特点导致的,不直观不等于不正确
阅读全文

日志

个性化推荐系统的基本抽象

在大多数 UGC、PGC、OGC 平台中,“推荐”随处可见,本文主要介绍个性化推荐系统的抽象组成。

关于推荐

人工 VS 个性化

  • 早期的推荐功能大多以人工筛选为主。人工筛选可以确保内容的高质量,这是主要的优点之一,但人工筛选往往需要投入大量的人力成本。另外,由于不同用户的个人偏好差异巨大,高质量的内容往往不等于最合适的内容(例如:一篇介绍奢侈品牌化妆品的“高大上”内容对于一位平时只关心美食和户外运动的用户而言可能是毫无吸引力的)。

  • 为了提升用户体验,后来出现了“个性化内容推荐”的概念,通过引入个性化推荐系统,解决这类“千人千面”的问题。

推荐系统抽象

个性化推荐系统一般有三大环节:预处理 -> 召回 -> 排序
注:也可以认为是两层(召回 -> 排序)

预处理

第一个环节是预处理,预处理指的是对各种数据源的数据进行特征提取和特征构建,例如:内容特征提取,用户行为画像构建。

召回

第二个环节是召回,召回就是把预处理产生的特征作为输入参数,训练出推荐模型,然后使用推荐模型得出候选集合的过程。常用的召回方式有:基于内容推荐、基于协同过滤推荐等。

排序

第三个环节是排序,简单来说就是将候选集合根据一定的规则,例如:点击预估、匹配关联度、人为权重等进行调整,从而影响最后的推荐顺序。

推荐系统架构

最后简单画了一个基本的推荐系统架构原型
个性化推荐系统框架

图:个性化推荐系统架构 ©️hejunhao.me
转载请注明出处:

© http://hejunhao.me

日志

Hadoop NameNode 高可用架构

NameNode是HDFS(hadoop分布式文件系统)的核心组件,在hadoop 1.x中NameNode存在SPOF(单点故障)问题,NameNode存储了HDFS的元数据信息,一旦NameNode宕机那么整个HDFS就无法访问,依赖HDFS的服务也会被波及(HBase、Hive…)同样无法访问,整个集群陷入瘫痪。NameNode的单点故障问题也使得Hadoop在1.x时代一直都只能用作离线存储和离线计算,无法满足对高可用要求很高的应用场景。Hadoop2.x针对NameNode的SPOF问题提出了高可用架构方案(HA),目前已经能在生产环境下应用。本文主要介绍该高可用架构的主备切换机制。

一、NameNode高可用架构

Hadoop NameNode高可用架构

Hadoop NameNode高可用架构

二、组件概述

Active NameNode 与 Standby NameNode

在NameNode的HA方案中有两个不同状态的NameNode,分别为活跃态(Active)和后备态(Standby),其中只有Active NameNode能对外提供服务,Standby NameNode会根据Active NameNode的状态变化,在必要时可切换成Active.

ZKFC

ZKFC即ZKFailoverController,是基于Zookeeper的故障转移控制器,它负责控制NameNode的主备切换,ZKFC会监测NameNode的健康状态,当发现Active NameNode出现异常时会通过Zookeeper进行一次新的选举,完成Active和Standby状态的切换

HealthMonitor

阅读全文

日志

Hadoop之YARN/MRv2

YARN又称为Mapreduce version 2(MRv2)是hadoop2.x的新架构,它将旧Hadoop Mapreduce框架中的JobTracker的资源管理和作业生命周期管理拆分成两个组件即ResourceManager(RM)和ApplicationMaster(AM)

一、为何需要MRv2?

mr1vsmr2

MRv1与MRv2对比

MRv1资源管理问题

  1. Hadoop1.0引入了“slot”的概念,每个slot代表了各个节点上的一份资源(CPU、内存等),MRv1把Map和Reduce的资源单独区分,即Map slot、Reduce slot,两个阶段的slot不能共享,这意味着资源的利用率大大降低
  2. 非MR应用不能分享资源,所以只能运行MR计算框架的应用
  3. 每个集群只有一个JobTracker,限制了集群的扩展,集群规模限制在4000个节点左右

MRv2资源管理方案

  1. 舍弃“slot”的概念,每个节点以“资源”(CPU、内存等)为单位分配给有需要的应用
  2. 支持运行MR应用和非MR应用
  3. JobTracker的大量功能被迁移到ApplicationMaster(AM),集群内可以存在多个AM(每个应用程序都拥有一个独立的AM),集群可以扩展到上万个节点

二、YARN架构

YARN_Architecture

YARN架构图(via Apache Hadoop)

资源管理器(ResourceManager,RM)

ResourceManager运行在主节点(Master)上,负责全局资源调度(分配/回收),处理各个应用的资源请求,ResourceManager由调度器(Scheduler)和应用管理器(ApplicationsManager, AsM)组成

  • 调度器(Scheduler)
    调度器根据资源调度策略(例如Capacity Scheduler、Fair Scheduler),将包含适当资源(CPU、内存等)的资源容器(Container)分配给相应的节点,应用程序的各个任务均在容器内执行,且只能使用容器分配到的资源.调度器只负责资源调度,不关心应用的执行状态.
    阅读全文
日志

Hadoop之HDFS(NameNode、DataNode、SecondaryNameNode)

HDFS(hadoop分布式文件系统)是Hadoop的核心组成部分,HDFS采用master/slave架构,一个HDFS集群由一个NameNode(不考虑HA/Federation)和多个DataNode组成

hdfs架构

HDFS架构图(via Apache Hadoop)

一、NameNode

  • NameNode是HDFS的中心,也称作Master
  • NameNode只保存HDFS的元数据,负责管理HDFS的命名空间(namespace)和控制文件的访问操作
  • NameNode不保存任何实际的数据或数据集,真正的数据由DataNode负责存储
  • NameNode拥有HDFS内所有文件的数据块(blocks)列表及其位置,因而NameNode能通过这些数据块信息来重构对应的文件
  • NameNode是HDFS的核心,一旦NameNode挂了,整个集群将无法访问
  • NameNode具有单点故障问题(Hadoop2之后可以通过High Available方案解决)
  • NameNode需要配置相对较多的内存(相比DataNode而言),因为NameNode会把HDFS的命名空间和文件数据块映射(Blockmap)保存在内存中,这也意味着集群的横向扩展受到NameNode的限制,因为集群增长到一定的规模后NameNode需要的内存也会更大,另外由于所有的元数据操作都需要通过NameNode进行,这意味着集群的性能受到NameNode的限制(Hadoop2之后可以通过Federation方案解决)
  • NameNode有两个核心的数据结构,FsImage和EditsLog,FsImage是HDFS命名空间、文件数据块映射、文件属性等信息的镜像,EditsLog相当于一个日志文件,它记录了对HDFS元数据进行修改的所有事务操作,当NameNode启动时会首先合并FsImage和EditsLog,得到HDFS的最新状态然后写入FsImage镜像文件中,并使用一个新的EditsLog文件进行记录

SecondaryNameNode

“SecondaryNamenode”这个名字具有误导性,它不能和DataNode交互,更不能替代NameNode,相反它是用来弥补NameNode的一些缺点,由于NameNode启动时会合并FsImage和EditsLog,但随着集群的运行时间变长,EditsLog会变得非常庞大,这意味着下一次启动需要花很长的时间来进行合并操作.

SecondaryNameNode负责解决以上的问题
阅读全文

日志

kafka集群部署

Kafka是一个分布式的,可分区的,支持冗余备份的日志服务,提供消息系统功能,它相当于一条插口式的高速数据总线,主要用于处理活跃的流式数据,能有效降低系统组网的复杂度,和编程复杂度。本文主要介绍如何部署Kafka集群。

Kafka集群依赖Zookeeper集群协调管理,所以部署Kafka集群之前我们需要先搭建好Zookeeper Cluster

集群环境

假设有以下集群节点
hadoop1(192.168.10.1)
hadoop2(192.168.10.2)
hadoop3(192.168.10.3)

Zookeeper集群搭建

1)下载Zookeeper

Zookeeper Download

2)安装

将安装包解压到集群各个节点的指定目录下($ZK_HOME)

3)配置

在$ZK_HOME/conf/创建zoo.cfg配置文件

#基本时间单位,控制心跳和超时的基准
tickTime=2000

#允许 follower (相对于 leader 而言的“客户端”)连接并同步到 leader 的初始化连接时间.
#它以 tickTime 的倍数来表示。当超过设置倍数的 tickTime 时间,则连接失败.
initLimit=10

#leader 与 follower 之间发送消息,请求和应答时间长度.
#如果 follower 在设置的时间内不能与leader 进行通信,那么此 follower 将被丢弃.
syncLimit=5

#自动清理事务日志和快照的时间间隔(小时)
autopurge.purgeInterval=24

#需要保留的快照文件数
autopurge.snapRetainCount=30

#存储数据的位置
dataDir=/hadoop/zookeeper

#监听客户端连接端口
clientPort=2181

#指定集群的机器配置,配置格式为“server.id=host:port:port”,其中id必须唯一.
#并且需要在各台机器的dataDir下创建一个myid的文件,在myid文件中输入对应机器的id值.
#另外,第一个端口( 2888 )是follower机器连接到leader机器的端口,第二个端口(3888)是用来进行leader选举的端口.
server.1=hadoop1:2888:3888
server.2=hadoop2:2888:3888
server.3=hadoop3:2888:3888

4)运行

在各个节点上启动zookeeper

$ZK_HOME/bin/zkServer.sh start

观察zookeeper运行状态

$ZK_HOME/bin/zkServer.sh status

Kafka集群搭建

阅读全文

日志

Elasticsearch数据备份和恢复

无论从容灾还是容错角度来看,数据的安全性都十分重要,Elasticsearch(以下简称ES)提供了Snapshot和Restore模块,用于对单个索引甚至整个集群进行备份和恢复。

环境

Elasticsearch 2.1.1

基本流程

ES的Snapshot/Restore流程可以概括为以下几个步骤

1)创建用于备份的远程仓库

2)往仓库创建快照

3)检查快照状态

4)恢复已备份快照

具体操作

阅读全文

日志

Spark集群资源动态分配

Spark默认采取预分配方式给各个application分配资源,每个application会独占所有分配到的资源直到整个生命周期的结束.对于长周期任务,在workload低峰阶段空闲的资源将一直被抢占而得不到有效利用,无疑是相当浪费.Spark1.2开始引入动态资源分配(Dynamic Resource Allocation)机制,支持资源弹性分配.

动态资源分配

Spark的资源动态分配机制主要基于application的当前任务(task)负载,以executor为粒度(以Spark1.2为例)动态向集群申请或释放资源,这意味着空闲的资源将得到有效的回收,供其他application利用.

Spark1.2仅支持Yarn模式,从Spark1.6开始,支持standalone、Yarn、Mesos.

安装与配置

1. Spark配置

阅读全文

日志

通过Sqoop向Hive导入ORC表

Sqoop在很长一段时间都只支持导入为textfile、avrofile、sequencefile等格式,如果需要将数据导入为ORC、parquet等格式的Hive Table往往需要分两个步骤完成(先导出临时表,再通过Hive转换)。而从Sqoop 1.4.4开始,Sqoop集成了HCatalog,我们可以轻易地实现多格式支持。

HCatalog配置

Sqoop需要依赖HCatalog的lib,所以需要配置环境变量$HCAT_HOME,一般从hive目录下即可找到hcatalog的相关路径


导入命令

sqoop import 
--connect jdbc:mysql://127.0.0.1:3306/test 
--username your_user_name --password your_passwd 
--table table_name --driver com.mysql.jdbc.Driver 
--create-hcatalog-table 
--hcatalog-table table_name 
--hcatalog-partition-keys month,day 
--hcatalog-partition-values 12,09 
--hcatalog-storage-stanza 'stored as orc tblproperties ("orc.compress"="SNAPPY")'

参数说明

阅读全文

第 1 页,共 2 页12