日志

NLP 关键词提取算法之 TF-IDF

TF-IDF 是处理 NLP 问题时经常使用的经典算法,常用于对文本进行关键词的提取。

TF-IDF 介绍

计算公式

TF-IDF 的计算非常简单


TF-IDF = TF(\text{文章词频}) * IDF(\text{逆文档频率})

概念解释

TF: 指某个词在一段文本中出现的词频


TF = \dfrac{\text{某个词在文章中出现的次数}}{\text{文章总词数}}

IDF: 指某个词在所有文本(对应语境所在的训练语料,例如:科学领域、体育领域)中的区分度,它认为越少出现的词区分度越高,相应的 IDF 值也越高。


IDF = \log\dfrac{(\text{训练语料的总文档数+1})}{(\text{出现该词的文档数+1})}

分母 “+1” 是为了防止分母为零,同时相应地分子 “+1” 以防止 IDF 为负数。

算法总结

经验

从计算公式可知,TF-IDF 的准确性非常依赖 IDF 模型的质量。同一个词在不同领域对应的区分度(IDF)也不同甚至差别巨大,例如 “冠军” 在体育领域的语料中出现的次数远远大于在政治领域的语料中所出现的次数,这意味着在后者的语境下,“冠军” 这个词的区分度更高,IDF 值更大。要提升 TF-IDF 的算法效果一般需要根据业务场合单独训练特定领域的 IDF 模型。

评价

  • TF-IDF 计算复杂度低,适合对效率优先的场景。
  • 由于它只依赖关键词的统计特征进行排序,有时候效果并不理想,比如有时候文本的关键要素不一定是频繁出现的元素。
  • 另外它也缺乏对文本结构的考虑。
转载请注明出处:

© http://hejunhao.me

日志

TensorFlow GPU 环境部署(CUDA + cuDNN)

TensorFlow 是目前主流的深度学习框架之一(虽然它有很多反人类的设计),它支持基于 GPU 的模型训练和预测,本文主要介绍 GPU 环境的快速部署。

本文最后更新于 2018年04月01日 以最新的 cuDNN7.0 + CUDA 9.0 + tensorflow_gpu==1.7 为例

环境

Ubuntu 16.04
NVIDIA Driver
CUDA 8.0 CUDA 9.0
cuDNN 5.1 cuDNN 7.0

总览

GPU 环境部署主要涉及三个步骤:

  1. 显卡驱动安装(本文不作介绍)
  2. CUDA 安装

  3. cuDNN 安装
    阅读全文

日志

K-Means聚类算法(实践篇)– 基于Spark Mlib的图像压缩案例

Spark Mlib 机器学习库集成了许多常用的机器学习算法,本文以K-Means算法为例结合图像压缩案例,简单介绍K-Means的应用。关于K-Means算法理论可以参考 → K-Means聚类算法(理论篇)

案例介绍

图像压缩

1)一张图由一系列像素组成,每个像素的颜色都由R、G、B值构成(不考虑Alpha),即R、G、B构成了颜色的三个基本特征,例如一个白色的像素点可以表示为(255,255,255)。

2)一张800×600的图片有480000个颜色数据,通过K-Means算法将这些颜色数据归类到K种颜色中,通过训练模型计算原始颜色对应的颜色分类,替换后生成新的图片。

Spark Mlib K-Means应用(Java + Python)

阅读全文

日志

K-Means聚类算法(理论篇)

K-means算法是机器学习/数据挖掘领域广泛使用的聚类算法,它是一个无监督学习算法,即无需对样本进行事先标记。K-means算法通俗来说主要完成一件事:给定一个包含n个点的数据集,把该数据集划分到k个聚类中,使得各个聚类所包含的每个点到各自聚类中心的距离均小于与其他聚类中心的距离。

K-Means算法

(一)算法过程

1)确定要划分的聚类个数(K),从数据集D中任意选出K个点作为聚类中心
2)计算所有点到各个聚类中心的距离,把各个点归类到距离最近的那个聚类集中
3)计算第二步所产生的K个聚类集的中心,将该中心作为数据集D新的K个聚类中心
4)重复2)、3)直到中心点不再变化或迭代次数达到设定的最大迭代值或中心点的变化收敛于某个预定值

(二)算法分析

阅读全文

日志

方差、标准差、均方误差、协方差的区别

简单介绍 方差、标准差、均方误差、协方差的基本概念以及计算公式,以区分它们的作用。

方差(Variance)

用来度量随机变量和其数学期望(即均值)之间的偏离程度


σ^2 = \dfrac{(x_1 - \bar{X})^2 + (x_2 - \bar{X})^2 ... + (x_n - \bar{X})^2}{(n-1)} = \dfrac{\sum_{i=1}^n{(x_i - \bar{X})^2}}{(n-1)}


备注:n-1 原因是无偏估计

标准差(Standard Deviation)

又叫均方差 , 反映一个数据集的离散程度(波动大小).

标准差 = 方差的算术平方根


σ = \sqrt{\dfrac{(x_1 - \bar{X})^2 + (x_2 - \bar{X})^2 ... + (x_n - \bar{X})^2}{(n-1)}} =\sqrt{\dfrac{\sum_{i=1}^n{(x_i - \bar{X})^2}}{(n-1)}}

问:有了方差为何需要标准差?

答:标准差的量纲(单位)与数据集一致,更直观描述波动范围。

均方误差(Mean Squared Error)

用来度量预测值与真实值的偏离程度

y:预测值 , Y:真实值


MSE = \dfrac{(y_1 - Y_1)^2 + (y_2 - Y_2)^2 ... + (y_n - Y_n)^2}{n} = \dfrac{\sum_{i=1}^n{(y_i - Y_i)^2}}{n}

协方差 (Covariance)

两个变量有多大的“可能”朝一个方向改变?协方差用于度量这个“可能”的程度。如果两个变量的变化方向一致,那么协方差为正,反之为负。其中,变化指变量与它的数学期望的差值。


Cov(x,y) = \dfrac{(x_1 - \bar{X})(y_1 - \bar{Y}) + (x_2 - \bar{X})(y_2 - \bar{Y}) ... + (x_n - \bar{X})(y_n - \bar{Y})}{(n-1)}
         = \dfrac{\sum_{i=1}^n{(x_i - \bar{X})(y_i - \bar{Y})}}{(n-1)}


当 cov(x,y)>0 ,则 X 与 Y 正相关;
当 cov(x,y)<0 , 则 X 与 Y 负相关;
当 cov(x,y)=0 ,则 X 与 Y 不相关。

转载请注明出处:

© 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)恢复已备份快照

具体操作

阅读全文

第 2 页,共 5 页12345