利用Python机器学习框架scikit-learn，我们自己做一个分类模型，对中文评论信息做情感分析。其中还会介绍中文停用词的处理方法。

image

疑惑

前些日子，我在微信后台收到了一则读者的留言。

image

我一下子有些懵——这怎么还带点播了呢？

但是旋即我醒悟过来，好像是我自己之前挖了个坑。

之前我写过《 如何用Python从海量文本抽取主题？》一文，其中有这么一段：

为了演示的流畅，我们这里忽略了许多细节。很多内容使用的是预置默认参数，而且完全忽略了中文停用词设置环节，因此“这个”、“如果”、“可能”、“就是”这样的停用词才会大摇大摆地出现在结果中。不过没有关系，完成比完美重要得多。知道了问题所在，后面改进起来很容易。 有机会我会写文章介绍如何加入中文停用词的去除环节。

根据“自己挖坑自己填”的法则，我决定把这一部分写出来。

我可以使用偷懒的办法。

例如在原先的教程里，更新中文停用词处理部分，打个补丁。

但是，最近我发现，好像至今为止，我们的教程从来没有介绍过如何用机器学习做情感分析。

你可能说，不对吧？

情感分析不是讲过了吗？老师你好像讲过《 如何用Python做情感分析？》，《 如何用Python做舆情时间序列可视化？》和《 如何用Python和R对《权力的游戏》故事情节做情绪分析？》。

你记得真清楚，提出表扬。

但是请注意，之前这几篇文章中，并没有使用机器学习方法。我们只不过调用了第三方提供的文本情感分析工具而已。

但是问题来了，这些第三方工具是在别的数据集上面训练出来的，未必适合你的应用场景。

例如有些情感分析工具更适合分析新闻，有的更善于处理微博数据……你拿过来，却是要对店铺评论信息做分析。

这就如同你自己笔记本电脑里的网页浏览器，和图书馆电子阅览室的网页浏览器，可能类型、版本完全一样。但是你用起自己的浏览器，就是比公用电脑上的舒服、高效——因为你已经根据偏好，对自己浏览器上的“书签”、“密码存储”、“稍后阅读”都做了个性化设置。

咱们这篇文章，就给你讲讲如何利用Python和机器学习，自己训练模型，对中文评论数据做情感分类。

# 数据

我的一个学生，利用爬虫抓取了大众点评网站上的数万条餐厅评论数据。

这些数据在爬取时，包含了丰富的元数据类型。

我从中抽取了评论文本和评星（1-5星），用于本文的演示。

从这些数据里，我们随机筛选评星为1，2，4，5的，各500条评论数据。一共2000条。

为什么只甩下评星数量为3的没有选择？

你先思考10秒钟，然后往下看，核对答案。

答案是这样的：

因为我们只希望对情感做出（正和负）二元分类，4和5星可以看作正向情感，1和2是负向情感……3怎么算？

所以，为了避免这种边界不清晰造成的混淆，咱们只好把标为3星的内容丢弃掉了。

整理好之后的评论数据，如下图所示。

image

我已经把数据放到了演示文件夹压缩包里面。后文会给你提供下载路径。

模型

使用机器学习的时候，你会遇到模型的选择问题。

例如，许多模型都可以用来处理分类问题。逻辑回归、决策树、SVM、朴素贝叶斯……具体到咱们的评论信息情感分类问题，该用哪一种呢？

幸好，Python上的机器学习工具包 scikit-learn 不仅给我们提供了方便的接口，供我们调用，而且还非常贴心地帮我们做了小抄（cheat-sheet）。

image

这张图看似密密麻麻，非常混乱，实际上是一个非常好的迷宫指南。其中绿色的方框，是各种机器学习模型。而蓝色的圆圈，是你做判断的地方。

你看，咱们要处理类别问题，对吧？

顺着往下看，会要求你判断数据是否有标记。我们有啊。

继续往下走，数据小于100K吗？

考虑一下，我们的数据有2000条，小于这个阈值。

接下来问是不是文本数据？是啊。

于是路径到了终点。

Scikit-learn告诉我们：用朴素贝叶斯模型好了。

小抄都做得如此照顾用户需求，你对scikit-learn的品质应该有个预期了吧？如果你需要使用经典机器学习模型（你可以理解成深度学习之外的所有模型），我推荐你先尝试scikit-learn 。

向量化

《 如何用Python从海量文本抽取主题？》一文里，我们讲过自然语言处理时的向量化。

忘了？

没关系。

子曰：

学而时习之，不亦乐乎？

这里咱们复习一下。

对自然语言文本做向量化（vectorization）的主要原因，是计算机 看不懂自然语言。

计算机，顾名思义，就是用来算数的。文本对于它（至少到今天）没有真正的意义。

但是自然语言的处理，是一个重要问题，也需要自动化的支持。因此人就得想办法，让机器能尽量理解和表示人类的语言。

假如这里有两句话：

I love the game.

I hate the game.

那么我们就可以简单粗暴地抽取出以下特征（其实就是把所有的单词都罗列一遍）：

• I
• love
• hate
• the
• game

对每一句话，都分别计算特征出现个数。于是上面两句话就转换为以下表格：

image

按照句子为单位，从左到右读数字，第一句表示为[1, 1, 0, 1, 1]，第二句就成了[1, 0, 1, 1, 1]。

这就叫向量化。

这个例子里面，特征的数量叫做维度。于是向量化之后的这两句话，都有5个维度。

你一定要记住，此时机器依然不能理解两句话的具体含义。但是它已经尽量在用一种有意义的方式来表达它们。

注意这里我们使用的，叫做“一袋子词”（bag of words）模型。

下面这张图（来自 _{https://goo.gl/2jJ9Kp}），形象化表示出这个模型的含义。

image

一袋子词模型不考虑词语的出现顺序，也不考虑词语和前后词语之间的连接。每个词都被当作一个独立的特征来看待。

你可能会问：“这样不是很不精确吗？充分考虑顺序和上下文联系，不是更好吗？”

没错，你对文本的顺序、结构考虑得越周全，模型可以获得的信息就越多。

但是，凡事都有成本。只需要用基础的排列组合知识，你就能计算出独立考虑单词，和考虑连续n个词语（称作 n-gram），造成的模型维度差异了。

为了简单起见，咱们这里还是先用一袋子词吧。有空我再给你讲讲……

打住，不能再挖坑了。

中文

上一节咱们介绍的，是自然语言向量化处理的通则。

处理中文的时候，要更加麻烦一些。

因为不同于英文、法文等拉丁语系文字，中文天然 没有空格作为词语之间的分割符号。

我们要先将中文分割成空格连接的词语。

例如把：

“我喜欢这个游戏”

变成：

“我 喜欢 这个 游戏”

这样一来，就可以仿照英文句子的向量化，来做中文的向量化了。

你可能担心计算机处理起中文的词语，跟处理英文词语有所不同。

这种担心没必要。

因为咱们前面讲过，计算机其实连英文单词也看不懂。

在它眼里，不论什么自然语言的词汇，都只是某种特定组合的字符串而已。
不论处理中文还是英文，都需要处理的一种词汇，叫做停用词。

中文维基百科里，是这么定义停用词的：

在信息检索中，为节省存储空间和提高搜索效率，在处理自然语言数据（或文本）之前或之后会自动过滤掉某些字或词，这些字或词即被称为Stop Words(停用词)。

咱们做的，不是信息检索，而已文本分类。

对咱们来说，你不打算拿它做特征的单词，就可以当作停用词。

还是举刚才英文的例子，下面两句话：

I love the game.

I hate the game.

告诉我，哪些是停用词？

直觉会告诉你，定冠词 the 应该是。

没错，它是虚词，没有什么特殊意义。

它在哪儿出现，都是一个意思。

一段文字里，出现很多次定冠词都很正常。把它和那些包含信息更丰富的词汇（例如love, hate）放在一起统计，就容易干扰我们把握文本的特征。

所以，咱们把它当作停用词，从特征里面剔除出去。

举一反三，你会发现分词后的中文语句：

“我 喜欢 这个 游戏”

其中的“这个”应该也是停用词吧？

答对了！

要处理停用词，怎么办呢？当然你可以一个个手工来寻找，但是那显然效率太低。

有的机构或者团队处理过许多停用词。他们会发现，某种语言里，停用词是有规律的。

他们把常见的停用词总结出来，汇集成表格。以后只需要查表格，做处理，就可以利用先前的经验和知识，提升效率，节约时间。

在scikit-learn中，英语停用词是自带的。只需要指定语言为英文，机器会帮助你自动处理它们。

但是中文……

scikit-learn开发团队里，大概缺少足够多的中文使用者吧。

好消息是，你可以使用第三方共享的停用词表。

这种停用词表到哪里下载呢？

我已经帮你找到了 一个 github 项目，里面包含了4种停用词表，来自哈工大、四川大学和百度等自然语言处理方面的权威单位。

image

这几个停用词表文件长度不同，内容也差异很大。为了演示的方便与一致性，咱们统一先用哈工大这个停用词表吧。

image

我已经将其一并存储到了演示目录压缩包中，供你下载。
# 环境

请你先到 这个网址下载本教程配套的压缩包。

下载后解压，你会在生成的目录里面看到以下4个文件。

image

下文中，我们会把这个目录称为“演示目录”。

请一定注意记好它的位置哦。

要装Python，最简便办法是安装Anaconda套装。

请到 这个网址下载Anaconda的最新版本。

image

请选择左侧的 Python 3.6版本下载安装。

如果你需要具体的步骤指导，或者想知道Windows平台如何安装并运行Anaconda命令，请参考我为你准备的 视频教程。

打开终端，用cd命令进入 演示目录。如果你不了解具体使用方法，也可以参考 视频教程。
我们需要使用许多软件包。如果每一个都手动安装，会非常麻烦。

我帮你做了个虚拟环境的配置文件，叫做environment.yaml ，也放在演示目录中。

请你首先执行以下命令：

conda env create -f environment.yaml

这样，所需的软件包就一次性安装完毕了。

之后执行，

source activate datapy3

进入这个虚拟环境。

注意一定要执行下面这句：

python -m ipykernel install –user –name=datapy3

只有这样，当前的Python环境才会作为核心（kernel）在系统中注册。
确认你的电脑上已经安装了 Google Chrome 浏览器。如果没有安装请到这里 下载安装。

之后，在演示目录中，我们执行：

jupyter notebook

Google Chrome会开启，并启动 Jupyter 笔记本界面：

image

你可以直接点击文件列表中的demo.ipynb文件，可以看到本教程的全部示例代码。

image

你可以一边看教程的讲解，一边依次执行这些代码。

但是，我 建议的方法，是回到主界面下，新建一个新的空白 Python 3 （显示名称为datapy3的那个）笔记本。

image

请跟着教程，一个个字符输入相应的内容。这可以帮助你更为深刻地理解代码的含义，更高效地把技能内化。

image

准备工作结束，下面我们开始正式输入代码。

代码

我们读入数据框处理工具pandas。

import pandas as pd 

利用pandas的csv读取功能，把数据读入。

注意为了与Excel和系统环境设置的兼容性，该csv数据文件采用的编码为GB18030。这里需要显式指定，否则会报错。

df = pd.read_csv('data.csv', encoding='gb18030') 

我们看看读入是否正确。

df.head() 

前5行内容如下：

image

看看数据框整体的形状是怎么样的：

df.shape 

(2000, 2) 

我们的数据一共2000行，2列。完整读入。

我们并不准备把情感分析的结果分成4个类别。我们只打算分成正向和负向。

这里我们用一个无名函数来把评星数量>3的，当成正向情感，取值为1；反之视作负向情感，取值为0。

def make_label(df):     df["sentiment"] = df["star"].apply(lambda x: 1 if x>3 else 0) 

编制好函数之后，我们实际运行在数据框上面。

make_label(df) 

看看结果：

df.head() 

image

从前5行看来，情感取值就是根据我们设定的规则，从评星数量转化而来。

下面我们把特征和标签拆开。

X = df[['comment']] y = df.sentiment 

X 是我们的全部特征。因为我们只用文本判断情感，所以X实际上只有1列。

X.shape 

(2000, 1) 

而y是对应的标记数据。它也是只有1列。

y.shape 

(2000,) 

我们来看看 X 的前几行数据。

X.head() 

image

注意这里评论数据还是原始信息。词语没有进行拆分。

为了做特征向量化，下面我们利用结巴分词工具来拆分句子为词语。

import jieba 

我们建立一个辅助函数，把结巴分词的结果用空格连接。

这样分词后的结果就如同一个英文句子一样，单次之间依靠空格分割。

def chinese_word_cut(mytext):     return " ".join(jieba.cut(mytext)) 

有了这个函数，我们就可以使用 apply 命令，把每一行的评论数据都进行分词。

X['cutted_comment'] = X.comment.apply(chinese_word_cut) 

我们看看分词后的效果：

X.cutted_comment[:5] 

image

单词和标点之间都用空格分割，符合我们的要求。

下面就是机器学习的常规步骤了：我们需要把数据分成训练集和测试集。

为什么要拆分数据集合？

在《 贷还是不贷：如何用Python和机器学习帮你决策？》一文中，我已解释过，这里复习一下：

如果期末考试之前，老师给你一套试题和答案，你把它背了下来。然后考试的时候，只是从那套试题里面抽取一部分考。你凭借超人的记忆力获得了100分。请问你学会了这门课的知识了吗？不知道如果给你新的题目，你会不会做呢？答案还是不知道。所以考试题目需要和复习题目有区别。

同样的道理，假设咱们的模型只在某个数据集上训练，准确度非常高，但是从来没有见过其他新数据，那么它面对新数据表现如何呢？

你心里也没底吧？

所以我们需要把数据集拆开，只在训练集上训练。保留测试集先不用，作为考试题，看模型经过训练后的分类效果。

from sklearn.model_selection import train_test_split X_train, X_test, y_train, y_test = train_test_split(X, y, random_state=1) 

这里，我们设定了 random_state取值，这是为了在不同环境中，保证随机数取值一致，以便验证咱们模型的实际效果。

我们看看此时的 X_train数据集形状。

X_train.shape 

(1500, 2) 

可见，在默认模式下， train_test_split函数对训练集和测试集的划分比例为 3:1。

我们检验一下其他3个集合看看：

y_train.shape 

(1500,) 

X_test.shape 

(500, 2) 

y_test.shape 

(500,) 

同样都正确无误。

下面我们就要处理中文停用词了。

我们编写一个函数，从中文停用词表里面，把停用词作为列表格式保存并返回：

def get_custom_stopwords(stop_words_file):     with open(stop_words_file) as f:         stopwords = f.read()     stopwords_list = stopwords.split('/n')     custom_stopwords_list = [i for i in stopwords_list]     return custom_stopwords_list 

我们指定使用的停用词表，为我们已经下载保存好的哈工大停用词表文件。

stop_words_file = "stopwordsHIT.txt" stopwords = get_custom_stopwords(stop_words_file) 

看看我们的停用词列表的后10项：

stopwords[-10:] 

image

这些大部分都是语气助词，作为停用词去除掉，不会影响到语句的实质含义。

下面我们就要尝试对分词后的中文语句做向量化了。

我们读入 CountVectorizer向量化工具，它依据词语出现频率转化向量。

from sklearn.feature_extraction.text import CountVectorizer 

我们建立一个 CountVectorizer()的实例，起名叫做vect。

注意这里为了说明停用词的作用。我们先使用默认参数建立vect。

vect = CountVectorizer() 

然后我们用向量化工具转换已经分词的训练集语句，并且将其转化为一个数据框，起名为 term_matrix。

term_matrix = pd.DataFrame(vect.fit_transform(X_train.cutted_comment).toarray(), columns=vect.get_feature_names()) 

我们看看 term_matrix的前5行：

term_matrix.head() 

image

我们注意到，特征词语五花八门，特别是很多数字都被当作特征放在了这里。

term_matrix的形状如下：

term_matrix.shape 

(1500, 7305) 

行数没错，列数就是特征个数，有7305个。

下面我们测试一下，加上停用词去除功能，特征向量的转化结果会有什么变化。

vect = CountVectorizer(stop_words=frozenset(stopwords)) 

下面的语句跟刚才一样：

term_matrix = pd.DataFrame(vect.fit_transform(X_train.cutted_comment).toarray(), columns=vect.get_feature_names()) 

term_matrix.head() 

image

可以看到，此时特征个数从刚才的7305个，降低为7144个。我们没有调整任何其他的参数，因此减少的161个特征，就是出现在停用词表中的单词。

但是，这种停用词表的写法，依然会漏掉不少漏网之鱼。

首先就是前面那一堆显眼的数字。它们在此处作为特征毫无道理。如果没有单位，没有上下文，数字都是没有意义的。

因此我们需要设定，数字不能作为特征。

在Python里面，我们可以设定 token_pattern来完成这个目标。

这一部分需要用到正则表达式的知识，我们这里无法详细展开了。

但如果你只是需要去掉数字作为特征的话，按照我这样写，就可以了。

另一个问题在于，我们看到这个矩阵，实际上是个非常稀疏的矩阵，其中大部分的取值都是0.

这没有关系，也很正常。

毕竟大部分评论语句当中只有几个到几十个词语而已。7000多的特征，单个语句显然是覆盖不过来的。

然而，有些词汇作为特征，就值得注意了。

首先是那些过于普遍的词汇。尽管我们用了停用词表，但是难免有些词汇几乎出现在每一句评论里。什么叫做特征？特征就是可以把一个事物与其他事物区别开的属性。

假设让你描述今天见到的印象最深刻的人。你怎么描述？

我看见他穿着小丑的衣服，在繁华的商业街踩高跷，一边走还一边抛球，和路人打招呼。

还是……

我看见他有两只眼睛，一只鼻子。

后者绝对不算是好的特征描述，因为难以把你要描述的个体区分出来。

物极必反，那些过于特殊的词汇，其实也不应该保留。因为你了解了这个特征之后，对你的模型处理新的语句情感判断，几乎都用不上。

这就如同你跟着神仙学了屠龙之术，然而之后一辈子也没有见过龙……

所以，如下面两个代码段所示，我们一共多设置了3层特征词汇过滤。

max_df = 0.8 # 在超过这一比例的文档中出现的关键词（过于平凡），去除掉。 min_df = 3 # 在低于这一数量的文档中出现的关键词（过于独特），去除掉。 

vect = CountVectorizer(max_df = max_df,                        min_df = min_df,                        token_pattern=u'(?u)//b[^//d//W]//w+//b',                        stop_words=frozenset(stopwords)) 

这时候，再运行我们之前的语句，看看效果。

term_matrix = pd.DataFrame(vect.fit_transform(X_train.cutted_comment).toarray(), columns=vect.get_feature_names()) 

term_matrix.head() 

image

可以看到，那些数字全都不见了。特征数量从单一词表法去除停用词之后的7144个，变成了1864个。

你可能会觉得，太可惜了吧？好容易分出来的词，就这么扔了？

要知道，特征多，绝不一定是好事儿。

尤其是噪声大量混入时，会显著影响你模型的效能。

好了，评论数据训练集已经特征向量化了。下面我们要利用生成的特征矩阵来训练模型了。

我们的分类模型，采用朴素贝叶斯（Multinomial naive bayes）。

from sklearn.naive_bayes import MultinomialNB nb = MultinomialNB() 

注意我们的数据处理流程是这样的：

1. 特征向量化；
2. 朴素贝叶斯分类。

如果每次修改一个参数，或者换用测试集，我们都需要重新运行这么多的函数，肯定是一件效率不高，且令人头疼的事儿。而且只要一复杂，出现错误的几率就会增加。

幸好，Scikit-learn给我们提供了一个功能，叫做管道(pipeline)，可以方便解决这个问题。

它可以帮助我们，把这些顺序工作连接起来，隐藏其中的功能顺序关联，从外部一次调用，就能完成顺序定义的全部工作。

使用很简单，我们就把 vect 和 nb 串联起来，叫做pipe。

from sklearn.pipeline import make_pipeline pipe = make_pipeline(vect, nb) 

看看它都包含什么步骤：

pipe.steps 

image

看，我们刚才做的工作，都在管道里面了。我们可以把管道当成一个整体模型来调用。

下面一行语句，就可以把未经特征向量化的训练集内容输入，做交叉验证，算出模型分类准确率的均值。

from sklearn.cross_validation import cross_val_score cross_val_score(pipe, X_train.cutted_comment, y_train, cv=5, scoring='accuracy').mean() 

咱们的模型在训练中的准确率如何呢？

0.820687244673089 

这个结果，还是不错的。

回忆一下，总体的正向和负向情感，各占了数据集的一半。

如果我们建立一个“笨模型”（dummy model），即所有的评论，都当成正向（或者负向）情感，准确率多少？

对，50%。

目前的模型准确率，远远超出这个数值。超出的这30%多，其实就是评论信息为模型带来的确定性。

但是，不要忘了，我们不能光拿训练集来说事儿，对吧？下面咱们给模型来个考试。

我们用训练集，把模型拟合出来。

pipe.fit(X_train.cutted_comment, y_train) 

然后，我们在测试集上，对情感分类标记进行预测。

pipe.predict(X_test.cutted_comment) 

image

这一大串0和1，你看得是否眼花缭乱？

没关系，scikit-learn给我们提供了非常多的模型性能测度工具。

我们先把预测结果保存到 y_pred。

y_pred = pipe.predict(X_test.cutted_comment) 

读入 scikit-learn 的测量工具集。

from sklearn import metrics 

我们先来看看测试准确率：

metrics.accuracy_score(y_test, y_pred) 

0.86 

这个结果是不是让你很吃惊？没错，模型面对没有见到的数据，居然有如此高的情感分类准确性。

对于分类问题，光看准确率有些不全面，咱们来看看混淆矩阵。

metrics.confusion_matrix(y_test, y_pred) 

array([[194,  43],        [ 27, 236]]) 

混淆矩阵中的4个数字，分别代表：

• TP: 本来是正向，预测也是正向的；
• FP: 本来是负向，预测却是正向的；
• FN: 本来是正向，预测却是负向的；
• TN: 本来是负向，预测也是负向的。

下面这张图（来自 https://goo.gl/5cYGZd）应该能让你更为清晰理解混淆矩阵的含义：

image

写到这儿，你大概能明白咱们模型的性能了。

但是总不能只把咱们训练出的模型和无脑“笨模型”去对比吧？这也太不公平了！

下面，我们把老朋友 SnowNLP 呼唤出来，做个对比。

如果你把它给忘了，请复习《 如何用Python做情感分析？》

from snownlp import SnowNLP def get_sentiment(text):     return SnowNLP(text).sentiments 

我们利用测试集评论原始数据，让 SnowNLP 跑一遍，获得结果。

y_pred_snownlp = X_test.comment.apply(get_sentiment) 

注意这里有个小问题。 SnowNLP 生成的结果，不是0和1，而是0到1之间的小数。所以我们需要做一步转换，把0.5以上的结果当作正向，其余当作负向。

y_pred_snownlp_normalized = y_pred_snownlp.apply(lambda x: 1 if x>0.5 else 0) 

看看转换后的前5条 SnowNLP 预测结果：

y_pred_snownlp_normalized[:5] 

image

好了，符合我们的要求。

下面我们先看模型分类准确率：

metrics.accuracy_score(y_test, y_pred_snownlp_normalized) 

0.77 

与之对比，咱们的测试集分类准确率，可是0.86哦。

我们再来看看混淆矩阵。

metrics.confusion_matrix(y_test, y_pred_snownlp_normalized) 

array([[189,  48],        [ 67, 196]]) 

对比的结果，是 TP 和 TN 两项上，咱们的模型判断正确数量，都要超出 SnowNLP。

小结

回顾一下，本文介绍了以下知识点：

1. 如何用一袋子词（bag of words）模型将自然语言语句向量化，形成特征矩阵；
2. 如何利用停用词表、词频阈值和标记模式(token pattern)移除不想干的伪特征词汇，降低模型复杂度。
3. 如何选用合适的机器学习分类模型，对词语特征矩阵做出分类；
4. 如何用管道模式，归并和简化机器学习步骤流程；
5. 如何选择合适的性能测度工具，对模型的效能进行评估和对比。

希望这些内容能够帮助你更高效地处理中文文本情感分类工作。

讨论

你之前用机器学习做过中文情感分类项目吗？你是如何去除停用词的？你使用的分类模型是哪个？获得的准确率怎么样？欢迎留言，把你的经验和思考分享给大家，我们一起交流讨论。

如果你对我的文章感兴趣，欢迎点赞，并且微信关注和置顶我的公众号“玉树芝兰”(nkwangshuyi)。

如果本文可能对你身边的亲友有帮助，也欢迎你把本文通过微博或朋友圈分享给他们。让他们一起参与到我们的讨论中来。

延伸阅读

如何用《玉树芝兰》入门数据科学？

数据科学相关文章合集（玉树芝兰）

      过去的一年里，我们准备在Ali-HBase上突破这个被普遍认知的痛点，为此进行了深度分析及全面创新的工作，获得了一些比较好的效果。以蚂蚁风控场景为例，HBase的线上young GC时间从120ms减少到15ms，结合阿里巴巴JDK团队提供的利器——AliGC，进一步在实验室压测环境做到了5ms。本文主要介绍我们过去在这方面的一些工作和技术思想。

   背景

      JVM的GC机制对开发者屏蔽了内存管理的细节，提高了开发效率。说起GC，很多人的第一反应可能是JVM长时间停顿或者FGC导致进程卡死不可服务的情况。但就HBase这样的大数据存储服务而言，JVM带来的GC挑战相当复杂和艰难。原因有三:

    1、内存规模巨大。线上HBase进程多数为96G大堆，今年新机型已经上线部分160G以上的堆配置

    2、对象状态复杂。HBase服务器内部会维护大量的读写cache，达到数十GB的规模。HBase以表格的形式提供有序的服务数据，数据以一定的结构组织起来，这些数据结构产生了过亿级别的对象和引用

    3、young GC频率高。访问压力越大，young区的内存消耗越快，部分繁忙的集群可以达到每秒1~2次youngGC， 大的young区可以减少GC频率，但是会带来更大的young GC停顿，损害业务的实时性需求。

  思路

      1. HBase作为一个存储系统，使用了大量的内存作为写buffer和读cache，比如96G的大堆（4G young + 92G old）下，写buffer+读cache会占用70%以上的内存(约70G），本身堆内的内存水位会控制在85%，而剩余的占用内存就只有在10G以内了。所以，如果我们能在应用层面 自管理好这70G+的 内存，那么对于JVM而言，百G大堆的GC压力就会等价于10G小堆的GC压力，并且未来面对更大的堆也不会恶化膨胀。 在这个解决思路下，我们线上的young GC时间获得了从120ms到15ms的优化效果。
      2. 在一个高吞吐的数据密集型服务系统中，大量的临时对象被频繁创建与回收，如何能够针对性管理这些临时对象的分配与回收，AliJDK团队研发了一种新的基于租户的GC算法—AliGC。集团HBase基于这个新的AliGC算法进行改造，我们在实验室中压测的young GC时间从15ms减少到5ms，这是一个未曾期望的极致效果。

     下面将逐一介绍Ali-HBase版本GC优化所使用的关键技术。

      消灭一亿个对象：更快更省的CCSMap

     目前HBase使用的存储模型是LSMTree模型，写入的数据会在内存中暂存到一定规模后再dump到磁盘上形成文件。

      下面我们将其简称为写缓存。写缓存是可查询的，这就要求数据在内存中有序。为了提高并发读写效率，并达成数据有序且支持seek&scan的基本要求，SkipList是使用得比较广泛的数据结构。

我们以JDK自带的ConcurrentSkipListMap为例子进行分析，它有下面三个问题:

     1. 内部对象繁多。每存储一个元素，平均需要4个对象(index+node+key+value，平均层高为1)

     2. 新插入的对象在young区，老对象在old区。当不断插入元素时，内部的引用关系会频繁发生变化，无论是ParNew算法的CardTable标记，还是G1算法的RSet标记，都有可能触发old区扫描。

      3. 业务写入的KeyValue元素并不是规整长度的，当它晋升到old区时，可能产生大量的内存碎片。

问题1使得young区GC的对象扫描成本很高，young GC时晋升对象更多。问题2使得young GC时需要扫描的old区域会扩大。问题3使得内存碎片化导致的FGC概率升高。当写入的元素较小时，问题会变得更加严重。我们曾对线上的RegionServer进程进行统计，活跃Objects有1亿2千万之多！

      分析完当前young GC的最大敌人后，一个大胆的想法就产生了，既然写缓存的分配，访问，销毁，回收都是由我们来管理的，如果让JVM“看不到”写缓存，我们自己来管理写缓存的生命周期，GC问题自然也就迎刃而解了。

      说起让JVM“看不到”，可能很多人想到的是off-heap的解决方案，但是这对写缓存来说没那么简单，因为即使把KeyValue放到offheap，也无法避免问题1和问题2。而1和2也是young GC的最大困扰。

      问题现在被转化成了： 如何不使用JVM对象来构建一个有序的支持并发访问的Map。
      当然我们也不能接受性能损失，因为写入Map的速度和HBase的写吞吐息息相关。
需求再次强化： 如何不使用对象来构建一个有序的支持并发访问的Map，且不能有性能损失。

为了达成这个目标，我们设计了这样一个数据结构：

• 它使用连续的内存(堆内or堆外)，我们通过代码控制内部结构而不是依赖于JVM的对象机制
• 在逻辑上也是一个SkipList，支持无锁的并发写入和查询
• 控制指针和数据都存放在连续内存中

       上图所展示的即是CCSMap(CompactedConcurrentSkipListMap)的内存结构。 我们以大块的内存段(Chunk)的方式申请写缓存内存。每个Chunk包含多个Node，每个Node对应一个元素。新插入的元素永远放在已使用内存的末尾。Node内部复杂的结构，存放了Index/Next/Key/Value等维护信息和数据。新插入的元素需要拷贝到Node结构中。当HBase发生写缓存dump时，整个CCSMap的所有Chunk都会被回收。当元素被删除时，我们只是逻辑上把元素从链表里"踢走"，不会把元素实际从内存中收回(当然做实际回收也是有方法，就HBase而言没有那个必要)。

       插入KeyValue数据时虽然多了一遍拷贝，但是就绝大多数情况而言，拷贝反而会更快。因为从CCSMap的结构来看，一个Map中的元素的控制节点和KeyValue在内存上是邻近的，利用CPU缓存的效率更高，seek会更快。对于SkipList来说，写速度其实是bound在seek速度上的，实际拷贝产生的overhead远不如seek的开销。根据我们的测试，CCSMap和JDK自带的ConcurrentSkipListMap相比，50Byte长度KV的测试中，读写吞吐提升了20~30%。

       由于没有了JVM对象，每个JVM对象至少占用16Byte空间也可以被节省掉(8byte为标记预留，8byte为类型指针)。还是以50Byte长度KeyValue为例，CCSMap和JDK自带的ConcurrentSkipListMap相比，内存占用减少了40%。

         CCSMap在生产中上线后，实际优化效果： young GC从120ms+减少到了30ms

 优化前

 优化后

       使用了CCSMap后，原来的1亿2千万个存活对象被缩减到了千万级别以内，大大减轻了GC压力。由于紧致的内存排布， 写入吞吐能力也得到了30%的提升。

       永不晋升的Cache：BucketCache

       HBase以Block的方式组织磁盘上的数据。一个典型的HBase Block大小在16K~64K之间。HBase内部会维护BlockCache来减少磁盘的I/O。BlockCache和写缓存一样，不符合GC算法理论里的分代假说，天生就是对GC算法不友好的 —— 既不稍纵即逝，也不永久存活。

一段Block数据从磁盘被load到JVM内存中，生命周期从分钟到月不等，绝大部分Block都会进入old区，只有Major GC时才会让它被JVM回收。它的麻烦主要体现在:

       1. HBase Block的大小不是固定的，且相对较大，内存容易碎片化

       2. 在ParNew算法上，晋升麻烦。 麻烦不是体现在拷贝代价上，而是因为尺寸较大，寻找合适的空间存放HBase Block的代价较高。

       读缓存优化的思路则是，向JVM申请一块永不归还的内存作为BlockCache，我们自己对内存进行固定大小的分段，当Block加载到内存中时，我们将Block拷贝到分好段的区间内，并标记为已使用。当这个Block不被需要时，我们会标记该区间为可用，可以重新存放新的Block，这就是BucketCache。关于BucketCache中的内存空间分配与回收(这一块的设计与研发在多年前已完成)，详细可以参考 : http://zjushch.iteye.com/blog/1751387

       很多基于堆外内存的RPC框架，也会自己管理堆外内存的分配和回收，一般通过显式释放的方式进行内存回收。但是对HBase来说，却有一些困难。我们将Block对象视为需要自管理的内存片段。Block可能被多个任务引用，要解决Block的回收问题，最简单的方式是将Block对每个任务copy到栈上(copy的block一般不会晋升到old区)，转交给JVM管理就可以。

       实际上，我们之前一直使用的是这种方法，实现简单，JVM背书，安全可靠。但这是有损耗的内存管理方式，为了解决GC问题，引入了每次请求的拷贝代价。由于拷贝到栈上需要支付额外的cpu拷贝成本和young区内存分配成本，在cpu和总线越来越珍贵的今天，这个代价显得高昂。

于是我们转而考虑使用引用计数的方式管理内存，HBase上遇到的主要难点是:

1. HBase内部会有多个任务引用同一个Block
2.  同一个任务内可能有多个变量引用同一个Block。引用者可能是栈上临时变量，也可能是堆上对象域。
3. Block上的处理逻辑相对复杂，Block会在多个函数和对象之间以参数、返回值、域赋值的方式传递。
4. Block可能是受我们管理的，也可能是不受我们管理的(某些Block需要手动释放，某些不需要)。
5. Block可能被转换为Block的子类型。

       这几点综合起来，对如何写出正确的代码是一个挑战。但在C++ 上，使用智能指针来管理对象生命周期是很自然的事情，为什么到了Java里会有困难呢？

      Java中变量的赋值，在用户代码的层面上，只会产生引用赋值的行为，而C++ 中的变量赋值可以利用对象的构造器和析构器来干很多事情，智能指针即基于此实现(当然C++的构造器和析构器使用不当也会引发很多问题，各有优劣，这里不讨论)

      于是我们参考了C++的智能指针，设计了一个Block引用管理和回收的框架ShrableHolder来抹平coding中各种if else的困难。它有以下的范式:

1. ShrableHolder可以管理有引用计数的对象，也可以管理非引用计数的对象
2. ShrableHolder在被重新赋值时，释放之前的对象。如果是受管理的对象，引用计数减1，如果不是，则无变化。
3. ShrableHolder在任务结束或者代码段结束时，必须被调用reset
4. ShrableHolder不可直接赋值。必须调用ShrableHolder提供的方法进行内容的传递
5. 因为ShrableHolder不可直接赋值，需要传递包含生命周期语义的Block到函数中时，ShrableHolder不能作为函数的参数。

      根据这个范式写出来的代码，原来的代码逻辑改动很少，不会引入if else。虽然看上去仍然有一些复杂度，所幸的是，受此影响的区间还是局限于非常局部的下层，对HBase而言还是可以接受的。为了保险起见，避免内存泄漏，我们在这套框架里加入了探测机制，探测长时间不活动的引用，发现之后会强制标记为删除。

将BucketCache应用之后，减少了BlockCache的晋升开销，减少了young GC时间：

 

 
 (CCSMap+BucketCache优化后的效果)

     追求极致：AliGC

       经过以上两个大的优化之后，蚂蚁风控生产环境的young GC时间已经缩减到15ms。由于ParNew+CMS算法在这个尺度上再做优化已经很困难了，我们转而投向AliGC的怀抱。AliGC在G1算法的基础上做了深度改进，内存自管理的大堆HBase和AliGC产生了很好的化学反应。

AliGC是阿里巴巴JVM团队基于G1算法， 面向大堆 (LargeHeap) 应用场景，优化的GC算法的统称。这里主要介绍下多租户GC。

      多租户GC包含的三层核心逻辑： 1）在JavaHeap上，对象的分配按照租户隔离，不同的租户使用不同的Heap区域； 2）允许GC以更小的代价发生在租户粒度，而不仅仅是应用的全局； 3）允许上层应用根据业务需求对租户灵活映射。

      AliGC将内存Region划分为了多个租户，每个租户内独立触发GC。在个基础上，我们将内存分为普通租户和中等生命周期租户。中等生命周期对象指的是，既不稍纵即逝，也不永久存在的对象。由于经过以上两个大幅优化，现在堆中等生命周期对象数量和内存占用已经很少了。但是中等生命周期对象在生成时会被old区对象引用，每次young GC都需要扫描RSet，现在仍然是young GC的耗时大头。

借助于AJDK团队的ObjectTrace功能，我们找出中等生命周期对象中最"大头"的部分，将这些对象在生成时直接分配到中等生命周期租户的old区，避免RSet标记。而普通租户则以正常的方式进行内存分配。

普通租户GC频率很高，但是由于晋升的对象少，跨代引用少，Young区的GC时间得到了很好的控制。在实验室场景仿真环境中，我们将young GC优化到了5ms。

(AliGC优化后的效果，单位问题，此处为us)

 

  云端使用

      阿里HBase目前已经在阿里云提供商业化服务，任何有需求的用户都可以在阿里云端使用深入改进的、一站式的HBase服务。云HBase版本与自建HBase相比在运维、可靠性、性能、稳定性、安全、成本等方面均有很多的改进，更多内容欢迎大家关注HBase技术社区微信公众号。

1.敏捷开发模型：

敏捷思想，有效沟通、小步快跑、拥抱变化、不断改进。

敏捷项目角色：

产品负责人（Product Owner）：主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。

流程管理员（Scrum Master）：主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。

开发团队（Scrum Team）：主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标。

2.敏捷开发过程：

1.首先我们需要确认一个 PB ( Product Backlog , 即按优先顺序排列的一个产品需求列表) ，这是由 PO（Product Owner） 负责的

2.ST（Scrum Team） 会根据 PB 列表，进行工作量的预估和安排

3.有了 PB 列表，我们需要通过 Sprint Planning Meeting( Sprint 计划会议)来从中挑选出一个 Story 作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog

4.Sprint Backlog 是由 ST 去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）

5.在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃尽图）

6.做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本；很多人可能还没有用过自动化的每日集成，其实TFS就有这个功能，它可以支持每次有成员进行签入操作的时候，在服务器上自动获取最新版本，然后在服务器中编译，如果通过则马上再执行单元测试代码，如果也全部通过，则将该版本发布，这时一次正式的签入操作才保存到TFS中，中间有任何失败，都会用邮件通知项目管理人员

7.当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）

8.最后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中。

3.敏捷过程总结：

1. Sprint 第一天，需要将目标定义清楚，并让团队所有人都知道「确保建立一致的目标并使之明确」；
2. 若出现需求变更，则优先排到下次迭代，特殊情况需特殊处理「确保本次迭代可以按时完工」；
3. Scrum Master 将迭代中的需求分解为任务，每个任务只能有一个任务负责人，且不超过一个人天「确保每日任务可评估」；
4. 让 Product Owner 直接与相关开发人员确定需求，Scrum Master 需一同参与「确保需求与实现不会发生偏差」；
5. 每日定时站会，时长不超过 15 分钟，规模不要太大「确保任务完成情况与计划保持一致」；
6. 每日进行一次代码评审，由 Scrum Master 负责，并在次日将评审结果通知给相关开发人员「确保代码质量不要下降」；
7. 各个团队的 Scrum Master 保持每日沟通一次，时间不要超过 15 分钟「确保项目管理不会出现风险」；
8. 每次迭代结束，让大家稍微放松一下，可提供一些团队活动，比如聚餐「确保团队能够更加凝聚」；
9. Scrum Master 需要给团队一些承诺，比如项目奖金或特殊福利等「确保团队更加有激情」；
10. 对于情绪异常的员工，Scrum Master 需及时与其沟通「确保不要让一个人的情绪影响整个团队」；

此外，作为项目管理者，需要不断在团队中加强以下 5 点文化：

1. 方向一致
2. 当面沟通
3. 全情投入
4. 充分信任
5. 说到做到

2017年10月，中国移动对外开始招标，将重新复活飞信，更名为“和飞信”，其中和飞信业务运营支撑服务项目招标金额达4764.6万，由此看出中国移动要利用飞信杀入移动社交工具的意图十分明显。

市场遭受挤压，移动盘活飞信进军社交领域

飞信是中国移动在2007年5月推出的通信服务产品，其功能主要包含语音、GPS定位、短信等多种通信功能。在互联网技术尚未成熟，互联网时代还未进入快车道之时，昂贵的上网费用让众多试图通过互联网来实现交流的用户望而却步。

在还未开化的互联网时代，电话语音通话和收发短信成为人们主要的线上社交方式。但在通信技术还未完全开化的时代，通话时间过长所产生的高额话费也令诸多手机用户苦不堪言，因此，相对于通话，费用便宜的短信则成为众多手机用户眼里的香饽饽。

而飞信出现，众多移动用户通过飞信就可以免费给好友发送短信的功能，更是掀起了手机用户通过短信交流的大浪潮。2012年第3季度，在国内移动IM市场活跃账户榜单中，手机飞信就以24.11%的市场份额领先于微信当年的17.58%。其用户规模在峰值时更是达到了5亿用户之多，被称为QQ最有竞争力的对手。

但随着腾讯将微信与QQ之间的转换通道逐渐成熟化打通之后，QQ用户通过QQ账号就可以登录微信的渠道得以实现，微信用户量也在QQ引流之后逐渐壮大；并且微信在实时语音交互、视频交互、分享生活点滴等社交功能上的优势较飞信更为明显，人们的社交方式发生改变，以短信为主的飞信在用户使用频次上也逐渐下降。

加之在移动通信领域，联通和电信在近几年的抢流大战中，纷纷迎合4G用户推出了流量优惠活动，帮助社交用户在社交软件上使用的数据流量提供保障之后，中国移动在通信领域的市场份额开始遭受挤压。

数据显示，2017年中国联通的4G用户数量达到1.7亿户，仅由联通大王卡产生的用户增量就超过了5000万户；而同期中国电信4G用户净增6017万户，累计用户数超过1.8亿户。其中，电信不限量套餐新增用户同样达到了惊人的5000万户。

在社交功能上，飞信不具备像微信那样的便捷多元的社交属性，而随着3G、4G时代的到来，用户在数据流量上的需求无法在中国移动上得以满足，联通和电信的不限流量模式则成为众多用户出逃的有力导向。在由社交功能和数据流量引发的用户流失问题不断加剧之后，中国移动在通信市场上的份额不断被挤压，其想要通过飞信收复失地实是必然之举。

物是人非，和飞信社交路上的荆棘

而在中国移动复盘飞信的消息公布之后，中国移动也公布了未来飞信的发展方向和新增功能。在发展方向上，新版飞信将会从原先的个人用户向企业客户进行转型；而在新增功能上，“定时消息”等新功能将会为和飞信用户带来全新的社交体验。并且会在原有的集团网业务上加以优化，为集团网用户提供独立数据流量收费标准。

虽然新版的和飞信在方向和功能上均做出了相应调整，中国移动对和飞信在社交市场上复盘抱有很大的希望，但是经过十年的发展，移动社交领域上的企业已如雨后春笋般林立而起，社交市场的格局也早已经从以腾讯的QQ、微信，旧版飞信为主的社交应用市场，逐渐转变为“一超多强”的多元化市场。因此在未来移动社交市场上，和飞信除了要面对QQ和微信这样传统的老对手之外，还将面对钉钉、新浪微博、网易易信等社交平台组合成的新市场格局。

一来，“老友”腾讯在熟人社交领域中跨年龄段的高渗透。在家庭、朋友等熟人社交领域上，微信和QQ两大社交平台的受众已经涵盖到大部分年龄段，拥有超高市场渗透率的腾讯社交平台，微信日活跃用户量已经超过9.5亿，而以95后、00后为主力军的QQ用户也有5亿之多。微信、QQ为用户带来的熟人社交便利让腾讯在移动社交时代占据了绝对优势。因此，中国移动要想通过盘活飞信来收复自己曾经在社交领域上的失地，在社交体系已经十分完善的微信和QQ面前并非轻而易举。

二来，心怀执念，阿里钉钉对企业社交来势汹汹。继来往在熟人社交领域败北之后，阿里在2014年又推出了主打企业社交的钉钉社交平台，钉钉的出现让诸多企业的员工将工作和生活分隔开来，逐渐形成了熟人社交之外的另一种社交模式。2017年12月底，阿里宣布钉钉用户量过亿，未来将面向全球企业社交市场。从来往到钉钉，阿里在社交产品上的投入力度不断加大，其想要在社交领域分得一杯羹已是司马昭之心。在未来社交领域中，与其说微信是未来飞信最大的竞争对手，不如说不断壮大的钉钉才是和飞信在企业社交上不容小觑的劲敌。

三来，微博和易信截断泛娱乐社交通道。在以陌生人为主的泛娱乐社交领域上，新浪微博和网易易信具有特色的社交功能更能满足用户的社交需求，两者均是介于熟人和陌生人之间的移动社交社区。用户在这两个平台上既可以与熟人分享生活趣事，又能与志同道合的用户建立新的社交关系，并且具有的短视频分享娱乐功能，能够满足用户泛娱乐社交需求。2017年，新浪微博宣布月活用户已达3亿，周边、热点等特色领域成为微博在社交抢流大战中功不可没；而网易与电信联手打造的易信在上线一年后也宣布用户过亿，通讯+娱乐社交模式也为易信在社交领域中积累更多粘性用户。

虽然中国移动在盘活和飞信之后一直将微信作为其未来社交领域中的第一劲敌，但是在企业社交上，钉钉在阿里的推动下已经逐渐步入正轨，同时能满足用户多元化社交需求的泛娱乐社交平台也将对和飞信造成不小的冲击。在这样多方割据的市场竞争格局下，和飞信从C端市场转像B端真的是可行之举吗？

创新方能让和飞信存活

从目前的通讯市场上看，虽然在经历了2017年联通大王卡和电信不限流量营销模式的强烈攻击之后，中国移动在移动通讯市场上的市场危机不断升级，但是中国移动凭借入局通讯领域较早的优势，仍有着联通、电信两家企业不可逾越的市场规模。中国通信网数据显示，截止2017年6月底，移动用户量约为8.67亿，其用户量和市场渗透率均是电信+联通用户总量的两倍。

未来，社交领域上的大战已经无法避免，而中国移动如何利用早期在市场积累的超高用户量和强大的市场渗透率，才能盘活飞信，打破当前以腾讯为首的“一超多强”的社交格局？

从历史来看，旧版飞信之所以取得成功，是基于用户在即时语音、短信的高消费场景下，用户对优惠甚至是免费的移动社交应用的需求。而在如今的社交领域中，能满足这样需求的社交应用琳琅满目，因此，创新成为和飞信重新杀入社交市场的唯一选择。

一方面，建立C端用户端口向和飞信引流。2018年，国内通讯领域的5G时代即将到来，各企业抢流大战也一触即发。对于通讯数据流量供应商的中国移动而言，这无疑是复盘和飞信的最佳时机，在满足用户对流量需求的前提条件下，利用5G技术加持和飞信，为消费用户提供全新的社交体验。同时加强5G技术对和飞信建设的优先性，实现用户、手机号、和飞信与5G技术的紧密相连。

另一方面，完善和飞信企业服务功能，明确未来走向。2017年极光大数据监测结果显示，2017年上半年，企业微信和钉钉均拥有较高的7天留存率，分别为81.7%和81.1%，而同期和飞信的7天留存率均值仅有不足70%。在相同的企业IM市场中，和飞信增加的文件传输留存期限和留存率不具有强有力优势，从IM市场上吸引更多企业入驻也就变得更加艰难。

同时，企业IM市场的社交应用均独具特色：有按管理者思路，自上而下打造的钉钉；也有因用户抱怨生活和工作混杂，自然延伸的企业微信；而企业易信则是倾向政府、企业用户……和飞信要想在企业IM领域中实现翻身，在完善其服务功能的同时，还要明确自身的运营和管理模式。

总体而言，随着消费者主导市场的能力日趋明显，传统以商家为主导的消费市场格局正在发生改变，用户流量已经成为判断某一企业是否拥有竞争力的重要风向标。而在这个流量为王的消费时代，企业只有始终维护消费者利益，为消费者提供优质体验的服务产品，才能在竞争日益激烈的市场中得以长存。

文/刘旷

Introduction

The Open Session in View is an Anti-Pattern, and this post is going to demonstrate why it is so. First of all, let’s start with the Wikipedia definition of an Anti-Pattern:

An anti-pattern (or antipattern) is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive.

A LazyInitializationException band aid

When using JPA and Hibernate, the Fetching policy can have one of the biggest impacts on application performance, and, as explained in my High-Performance JDBC presentation, you should always fetch just as much data you need to fulfil the requirements of a given business logic use case. Fetching too many columns than necessary has an impact, and that’s why entities are not good candidates for read-only views. In turn, DTO projectionsare better suited for read-only data sets.

Entities are very useful for read-write transactions because you can benefit from the automatic dirty checking mechanismwhile preventing lost updates phenomenain multi-request logical transactions.

Unfortunately, many enterprise applications don’t make this distinction, and they rely solely on entities for both read-only and read-write transactions. Not only that an entity has more columns than a custom DTO projection, but the entity might have associations as well. Entity associations are convenient because it allows the application developer to access joined relationships without even needing to write a query.

Hibernate comes with Proxies that allow the application developer to defer fetching until the association is needed. This is very useful, especially from a performance perspective. The worst thing to do is to use EAGER associationsbecause, once a relationship is set to be eagerly fetched, it cannot be changed to being fetched lazily on a per query basis. For this reason, many associations are configured with the FetchType.LAZYattribute.

However, a LAZY association needs the Sessionto be opened in order to initialize the Proxy. If the Persistence Context is closed, when trying to access a non-initialized LAZY association, the infamous LazyInitializationExceptionis thrown.

For read-only views, when using DTO projections, we have to manually choose the child associations properties too, therefore, the LazyInitializationExceptioncannot occur. For read-write transactions, entities might be fetched with the intention of being modified and saved at the end of the currently running workflow. These entities are prone to LazyInitializationException(s), so there are good ways and bad ways of dealing with this issue.

It is only the business layer responsibility to fetch all the data that’s necessary for a particular business use case. For many-to-one and one-to-one associations, as well as to at most one one-to-manyrelationship, JOIN FETCHdirective is the best way of initializing the associations that are going to be needed in the view layer. For multiple one-to-manyassociations, to avoid a Cartesian Product, it’s necessary to use secondary queries. These secondary queries can be fired when the association is accessed for the first time, which can be done with the Hibernate.initialize(proxy)utility.

Open Session In View takes a different approach. Instead of letting the business layer decide how it’s best to fetch all the associations that are needed by the View layer, it forces the Persistence Context to stay open so that the View layer can trigger the Proxy initialization.

• The OpenSessionInViewFiltercalls the openSessionmethod of the underlying SessionFactoryand obtains a new Session.
• The Sessionis bound to the TransactionSynchronizationManager.
• The OpenSessionInViewFiltercalls the doFilterof the javax.servlet.FilterChainobject reference and the request is further processed
• The DispatcherServletis called, and it routes the HTTP request to the underlying PostController.
• The PostControllercalls the PostServiceto get a list of Postentities.
• The PostServiceopens a new transaction, and the HibernateTransactionManagerreuses the same Sessionthat was opened by the OpenSessionInViewFilter.
• The PostDAOfetches the list of Postentities without initializing any lazy association.
• The PostServicecommits the underlying transaction, but the Sessionis not closed because it was opened externally.
• The DispatcherServletstarts rendering the UI, which, in turn, navigates the lazy associations and triggers their initialization.
• The OpenSessionInViewFiltercan close the Session, and the underlying database connection is released as well.

At a first glance, this might not look like a terrible thing to do, but, once you view it from a database perspective, a series of flaws start to become more obvious.

The service layer opens and closes a database transaction, but afterward, there is no explicit transaction going on. For this reason, every additional statement issued from the UI rendering phase is executed in auto-commit mode. Auto-commit puts pressure on the database server because each statement must flush the transaction log to disk, therefore causing a lot of I/O traffic on the database side. One optimization would be to mark the Connectionas read-only which would allow the database server to avoid writing to the transaction log.

There is no separation of concerns anymore because statements are generated both by the service layer and by the UI rendering process. Writing integration tests that assert the number of statements being generatedrequires going through all layers (web, service, DAO) while having the application deployed on a web container. Even when using an in-memory database (e.g. HSQLDB) and a lightweight web server (e.g. Jetty), these integration tests are going to be slower to execute than if layers were separated and the back-end integration tests used the database, while the front-end integration tests were mocking the service layer altogether.

The UI layer is limited to navigating associations which can, in turn, trigger N+1 query problems. Although Hibernate offers @BatchSizefor fetching associations in batches, and FetchMode.SUBSELECTto cope with this scenario, the annotations are affecting the default fetch plan, so they get applied to every business use case. For this reason, a data access layer query is much more suitable because it can be tailored to the current use case data fetch requirements.

Last but not least, the database connection is held throughout the UI rendering phase which increases connection lease time and limits the overall transaction throughput due to congestion on the database connection pool. The more the connection is held, the more other concurrent requests are going to wait to get a connection from the pool.

Read-life stories

• Spring Boot: Open Session In View caused cache problems
• Paper scalability, Bcrypt, and Zonky’s performance debugging (Czech)

After a long debate, it’s good that Spring Boot issues a warning id the Open Session In View mode is active.

If you enjoyed this article, I bet you are going to love my Bookand Video Coursesas well.

Conclusion

The Open Session in View is a solution to a problem that should not exist in the first place, and the most likely root cause is relying exclusively on entity fetching. If the UI layer only needs a view of the underlying data, then the data access layer is going to perform much better with a DTO projection.

A DTO projectionforces the application developer to fetch just the required data set and is not susceptible to LazyInitializationException(s). This way, the separation of concerns is no longer compromised, and performance optimizations can be applied at the data access layer level since all statements are confined to the boundaries of the currently executing transaction.

Introduction

The LazyInitializationExceptionis undoubtedly one of the most common exceptions you can get when using Hibernate. This article is going to summarize the best and the worst ways of handling lazy associations.

Fetching 101

With JPA, not only you can fetch entities from the database, but you can also fetch entity associations as well. For this reason, JPA defines two FetchTypestrategies:

• EAGER
• LAZY

The problem with EAGER fetching

EAGERfetching means that associations are always retrieved along with their parent entity. In reality, EAGER fetching is very bad from a performance perspectivebecause it’s very difficult to come up with a global fetch policy that applies to every business use case you might have in your enterprise application.

Once you have an EAGERassociation, there is no way you can make it LAZY. This way, the association will always be fetched even if the user does not necessarily need it for a particular use case. Even worse, if you forget to specify that an EAGER association needs to be JOIN FETCH-ed by a JPQL query, Hibernate is going to issue a secondary select for every uninitialized association, leading to N+1 query problems.

Unfortunately, JPA 1.0 decided that @ManyToOneand @OneToOneshould default to FetchType.EAGER, so now you have to explicitly mark these two associations as FetchType.LAZY:

@ManyToOne(fetch = FetchType.LAZY)
private Post post;

LAZY fetching

For this reason, it’s better to use LAZYassociations. A LAZYassociation is exposed via a Proxy, which allows the data access layer to load the association on demand. Unfortunately, LAZYassociations can lead to LazyInitializationException.

For our next example, we are going to use the following entities:

When executing the following logic:

List<PostComment> comments = null;

EntityManager entityManager = null;
EntityTransaction transaction = null;
try {
    entityManager = entityManagerFactory()
        .createEntityManager();
    transaction = entityManager.getTransaction();
    transaction.begin();

    comments = entityManager.createQuery(
        "select pc " +"from PostComment pc " +"where pc.review = :review", PostComment.class)
    .setParameter("review", review)
    .getResultList();

    transaction.commit();
} catch (Throwable e) {
    if (transaction != null && 
        transaction.isActive())
        transaction.rollback();
    throw e;
} finally {
    if (entityManager != null) {
        entityManager.close();
    }
}

try {
    for(PostComment comment : comments) {
        LOGGER.info(
            "The post title is '{}'", 
            comment.getPost().getTitle()
        );
    }
} catch (LazyInitializationException expected) {
    assertEquals("could not initialize proxy - no Session", 
        expected.getMessage()
    );
}

Hibernate is going to throw a LazyInitializationExceptionbecause the PostCommententity did not fetch the Postassociation while the EntityManagerwas still opened, and the Postrelationship was marked with FetchType.LAZY:

@ManyToOne(fetch = FetchType.LAZY)
private Post post;

How NOT to handle LazyInitializationException

Unfortunately, there are also bad ways of handling the LazyInitializationExceptionlike:

• Open Session in View
• hibernate.enable_lazy_load_no_trans

These two Anti-Patterns are very inefficient from a database perspective, so you should never use them in your enterprise application.

JOIN FETCH to the rescue

Entities are only needed when the current running application-level transactionneeds to modify the entities that are being fetched. Because of the automatic dirty checking mechanism, Hibernate makes it very easy to translate entity state transitionsinto SQL statements.

Considering that we need to modify the PostCommententities, and we also need the Postentities as well, we just need to use the JOIN FETCHdirective like in the following query:

comments = entityManager.createQuery("select pc " +"from PostComment pc " +"join fetch pc.post " +"where pc.review = :review", PostComment.class)
.setParameter("review", review)
.getResultList();

The JOIN FETCHdirective instructs Hibernate to issue an INNER JOIN so that Postentities are fetched along with the PostCommentrecords:

SELECT pc.id AS id1_1_0_ ,
       p.id AS id1_0_1_ ,
       pc.post_id AS post_id3_1_0_ ,
       pc.review AS review2_1_0_ ,
       p.title AS title2_0_1_
FROM   post_comment pc
INNER JOIN post p ON pc.post_id = p.id
WHERE  pc.review = 'Excellent!'

That’s it! It’s as simple as that!

DTO projection to the rescue

Now, we are not done yet. What if you don’t even want entities in the first place. If you don’t need to modify the data that’s being read, why would you want to fetch an entity in the first place? A DTO projectionallows you to fetch fewer columns and you won’t risk any LazyInitializationException.

For instance, we can have the following DTO class:

public class PostCommentDTO {

    private final Long id;

    private final String review;

    private final String title;

    public PostCommentDTO(
        Long id, String review, String title) {
        this.id = id;
        this.review = review;
        this.title = title;
    }

    public Long getId() {
        return id;
    }

    public String getReview() {
        return review;
    }

    public String getTitle() {
        return title;
    }
}

If the business logic only needs a projection, DTOs are much more suitable than entities. The previous query can be rewritten as follows:

List<PostCommentDTO> comments = doInJPA(entityManager -> {
    return entityManager.createQuery("select new " +"   com.vladmihalcea.book.hpjp.hibernate.fetching.PostCommentDTO(" +"       pc.id, pc.review, p.title" +"   ) " +"from PostComment pc " +"join pc.post p " +"where pc.review = :review", PostCommentDTO.class)
    .setParameter("review", review)
    .getResultList();
});

for(PostCommentDTO comment : comments) {
    LOGGER.info("The post title is '{}'", comment.getTitle());
}

And Hibernate can execute a SQL query which only needs to select threecolumns instead of five:

SELECT pc.id AS col_0_0_ ,
       pc.review AS col_1_0_ ,
       p.title AS col_2_0_
FROM   post_comment pc
INNER JOIN post p ON pc.post_id = p.id
WHERE  pc.review = 'Excellent!'

Not only that we got rid of the LazyInitializationException, but the SQL query is even more efficient. Cool, right?

If you enjoyed this article, I bet you are going to love my Bookand Video Coursesas well.

Conclusion

LazyInitializationExceptionis a code smell because it might hide the fact that entities are used instead of DTO projections. Sometimes, fetching entities is the right choice, in which case, a JOIN FETCHdirective is the simplest and the best way to initialize the LAZYHibernate proxies.

最近在一个项目里使用了fasttext[1]， 这是facebook今年开源的一个词向量与文本分类工具，在学术上没有什么创新点，但是好处就是模型简单，训练速度又非常快。我在最近的一个项目里尝试了一下，发现用起来真的很顺手，做出来的结果也可以达到上线使用的标准。

其实fasttext使用的模型与word2vec的模型在结构上是一样的，拿cbow来说，不同的只是在于word2vec cbow的目标是通过当前词的前后N个词来预测当前词，在使用层次softmax的时候，huffman树叶子节点处是训练语料里所有词的向量。

而fasttext在进行文本分类时，huffmax树叶子节点处是每一个类别标签的词向量，在训练的过程中，训练语料的每一个词也会得到对应的词向量，输入为一个window内的词对应的词向量，hidden layer为这几个词的线性相加，相加的结果作为该文档的向量，再通过层次softmax得到预测标签，结合文档的真实标签计算loss，梯度与迭代更新词向量。

fasttext有别于word2vec的另一点是加了ngram切分这个trick，将长词再通过ngram切分为几个短词，这样对于未登录词也可以通过切出来的ngram词向量合并为一个词。由于中文的词大多比较短，这对英文语料的用处会比中文语料更大。

此外，fasttext相比deep learning模型的优点是训练速度极快。我们目前使用fasttext来进行客户填写的订单地址到镇这一级别的分类。每一个省份建立一个模型，每个模型要分的类别都有1000多类，200万左右的训练数据，12个线程1分钟不到就可以训练完成，最终的分类准确率与模型鲁棒性都比较高(区县级别分类正确准确率高于99.5%， 镇级别高于98%)，尤其是对缩写地名，或者漏写了市级行政区、区县级行政区的情况也都可以正确处理。

参数方面

1. loss function选用hs（hierarchical softmax）要比ns(negative sampling) 训练速度要快很多倍，并且准确率也更高。

2. wordNgrams 默认为1，设置为2以上可以明显提高准确率。

3. 如果词数不是很多，可以把bucket设置的小一点，否则预留会预留太多bucket使模型太大。

因为facebook提供的只是C++版本的代码，原本还以为要自己封装一个python接口，结果上github一搜已经有封装的python接口了[2]。用起来特别方便，觉得还不能满足自己的使用要求，修改源码也非常方便。

对于同样的文本分类问题，后来还用单向LSTM做了一遍，输入pre-trained的embedding词向量，并且在训练的时候fine-tune，与fasttext对比，即使使用了GTX 980的GPU，训练速度还是要慢很多，并且，准确准确率和fasttext是差不多的。

所以对于文本分类，先用fasttext做一个简单的baseline是很适合的。

[1] https://github.com/facebookresearch/fastText
[2] https://github.com/salestock/fastText.py

FastText是Facebook开发的一款快速文本分类器，提供简单而高效的文本分类和表征学习的方法，不过这个项目其实是有两部分组成的，一部分是这篇文章介绍的
fastText 文本分类（paper： A. Joulin, E. Grave, P. Bojanowski, T. Mikolov,
Bag of Tricks for Efficient Text
Classification（高效文本分类技巧）），
另一部分是词嵌入学习（paper: P.
Bojanowski*, E. Grave*, A. Joulin, T. Mikolov, Enriching Word Vectors
with Subword
Information（使用子字信息丰富词汇向量））。
按论文来说只有文本分类部分才是 fastText，但也有人把这两部分合在一起称为
fastText。笔者，在这即认为词嵌入学习属于FastText项目。
github链接： https://github.com/facebookresearch/fastText

.

高级词向量三部曲：

1、 NLP︱高级词向量表达（一）——GloVe（理论、相关测评结果、R&python实现、相关应用）
2、 NLP︱高级词向量表达（二）——FastText（简述、学习笔记）
3、 NLP︱高级词向量表达（三）——WordRank（简述）
4、其他NLP词表示方法paper: 从符号到分布式表示NLP中词各种表示方法综述

一、FastText架构

本节内容参考自：
1、开源中国社区 [ http://www.oschina.net]《Facebook 开源的快速文本分类器 FastTexT》
2、雷锋网文章：《 比深度学习快几个数量级，详解Facebook最新开源工具——fastText》

.

1、fastText 架构原理

fastText 方法包含三部分：模型架构、层次 Softmax 和 N-gram 特征。

fastText 模型输入一个词的序列（一段文本或者一句话)，输出这个词序列属于不同类别的概率。
序列中的词和词组组成特征向量，特征向量通过线性变换映射到中间层，中间层再映射到标签。
fastText 在预测标签时使用了非线性激活函数，但在中间层不使用非线性激活函数。
fastText 模型架构和 Word2Vec 中的 CBOW 模型很类似。不同之处在于，fastText 预测标签，而 CBOW 模型预测中间词。

.
.

2、改善运算效率——softmax层级

对于有大量类别的数据集，fastText使用了一个分层分类器（而非扁平式架构）。不同的类别被整合进树形结构中（想象下二叉树而非 list）。在某些文本分类任务中类别很多，计算线性分类器的复杂度高。为了改善运行时间，fastText 模型使用了层次 Softmax 技巧。层次 Softmax 技巧建立在哈弗曼编码的基础上，对标签进行编码，能够极大地缩小模型预测目标的数量。（参考 博客）

考虑到线性以及多种类别的对数模型，这大大减少了训练复杂性和测试文本分类器的时间。fastText 也利用了类别（class）不均衡这个事实（一些类别出现次数比其他的更多），通过使用 Huffman 算法建立用于表征类别的树形结构。因此，频繁出现类别的树形结构的深度要比不频繁出现类别的树形结构的深度要小，这也使得进一步的计算效率更高。

.
.
.

二、FastText的词向量表征

1、FastText的N-gram特征

常用的特征是词袋模型。但词袋模型不能考虑词之间的顺序，因此 fastText 还加入了 N-gram 特征。
“我 爱 她” 这句话中的词袋模型特征是 “我”，“爱”, “她”。这些特征和句子 “她 爱 我” 的特征是一样的。
如果加入 2-Ngram，第一句话的特征还有 “我-爱” 和 “爱-她”，这两句话 “我 爱 她” 和 “她 爱 我” 就能区别开来了。当然，为了提高效率，我们需要过滤掉低频的 N-gram。

在 fastText 中一个低维度向量与每个单词都相关。隐藏表征在不同类别所有分类器中进行共享，使得文本信息在不同类别中能够共同使用。这类表征被称为词袋（bag of words）（此处忽视词序）。在 fastText中也使用向量表征单词 n-gram来将局部词序考虑在内，这对很多文本分类问题来说十分重要。

举例来说：fastText能够学会“男孩”、“女孩”、“男人”、“女人”指代的是特定的性别，并且能够将这些数值存在相关文档中。然后，当某个程序在提出一个用户请求（假设是“我女友现在在儿？”），它能够马上在fastText生成的文档中进行查找并且理解用户想要问的是有关女性的问题。
.
.

2、FastText词向量优势

（1）适合大型数据+高效的训练速度：能够训练模型“在使用标准多核CPU的情况下10分钟内处理超过10亿个词汇”，特别是与深度模型对比，fastText能将训练时间由数天缩短到几秒钟。使用一个标准多核 CPU，得到了在10分钟内训练完超过10亿词汇量模型的结果。此外， fastText还能在五分钟内将50万个句子分成超过30万个类别。
（2）支持多语言表达：利用其语言形态结构，fastText能够被设计用来支持包括英语、德语、西班牙语、法语以及捷克语等多种语言。它还使用了一种简单高效的纳入子字信息的方式，在用于像捷克语这样词态丰富的语言时，这种方式表现得非常好，这也证明了精心设计的字符 n-gram 特征是丰富词汇表征的重要来源。FastText的性能要比时下流行的word2vec工具明显好上不少，也比其他目前最先进的词态词汇表征要好。

（3）fastText专注于文本分类，在许多标准问题上实现当下最好的表现（例如文本倾向性分析或标签预测）。FastText与基于深度学习方法的Char-CNN以及VDCNN对比：

（4）比word2vec更考虑了相似性，比如 fastText 的词嵌入学习能够考虑 english-born 和 british-born 之间有相同的后缀，但 word2vec 却不能（具体参考 paper）。
.
.

3、FastText词向量与word2vec对比

本节来源于博客： fasttext
FastText= word2vec中 cbow + h-softmax的灵活使用

灵活体现在两个方面：
1. 模型的输出层：word2vec的输出层，对应的是每一个term，计算某term的概率最大；而fasttext的输出层对应的是 分类的label。不过不管输出层对应的是什么内容，起对应的vector都不会被保留和使用；
2. 模型的输入层：word2vec的输出层，是 context window 内的term；而fasttext 对应的整个sentence的内容，包括term，也包括 n-gram的内容；

两者本质的不同，体现在 h-softmax的使用。
Wordvec的目的是得到词向量，该词向量 最终是在输入层得到，输出层对应的 h-softmax 也会生成一系列的向量，但最终都被抛弃，不会使用。
fasttext则充分利用了h-softmax的分类功能，遍历分类树的所有叶节点，找到概率最大的label（一个或者N个）

相关文章： Jupyter notebooks：Comparison of FastText and Word2Vec
.
.
.

三、FastText实现

github链接： https://github.com/facebookresearch/fastText
fastText基于Mac OS或者Linux系统构筑，使用 C++11 的特性。需要python 2.6 或者更高版本支持，以及numpy & scipy等软件支持。
FastText默认参数：

  $ ./fasttext supervised

Mikolov 在 fastTetxt 的论文中报告了两个实验，其中一个实验和 Tagspace 模型进行对比。实验是在 YFCC100M 数据集上进行的, YFCC100M 数据集包含将近 1 亿张图片以及摘要、标题和标签。实验使用摘要和标题去预测标签。Tagspace 模型是建立在 Wsabie 模型的基础上的。Wsabie 模型除了利用 CNN 抽取特征之外，还提出了一个带权近似配对排序 (Weighted Approximate-Rank Pairwise, WARP) 损失函数用于处理预测目标数量巨大的问题。

上面就是实验结果，从实验结果来看 fastText 能够取得比 Tagspace 好的效果，并拥有无以伦比的训练测试速度。但严格来说，这个实验对 Tagspace 有些不公平。YFCC100M 数据集是关于多标记分类的，即需要模型能从多个类别里预测出多个类。Tagspace 确实是做多标记分类的；但 fastText 只能做多类别分类，从多个类别里预测出一个类。而评价指标 prec@1 只评价一个预测结果，刚好能够评价多类别分类。

YFCC100M 数据： https://research.facebook.com/research/fasttext/

.

延伸一：重磅：facebook公开了90种语言的Pre-trained word vectors

https://github.com/facebookresearch/fastText/blob/master/pretrained-vectors.md
可怕的facebook，用fasttext进行训练，使用默认参数，300维度

曾经有一位著名的经济学家，曾经预言到 2028 年，我们每个人都将不再需要为赚钱烦恼，到那时我们每个人每天只需要工作 3 小时。这位经济学家，就是被称为“资本主义救星”的英国经济学家凯恩斯。

这样的 2028 年，你觉得会到来吗？

凯恩斯认为，在不惜一切进行原始积累的阶段过去了之后，人们终将从疯狂的工作劳动中解放出来，获得大把的空闲时间。（as cited in, Kolbert, 2014）。

不知道 2028 年世界会不会发生一个剧变，至少目前，我们比起几十年前已经是更加忙碌了。

一项美国的调查显示，尤其在投行、咨询、IT、律师等高薪领域中， 94%的人每周工作 50 小时以上，超过半数的人每周工作 65 小时以上，而且，这还不包括他们在办公室以外的地方，用手机处理公务的时间（Perlow & Poter, 2009）。

有趣的是，当大家都以为不停加班都只是因为工作压力、被逼无奈时，《纽约客》的专栏作家 Surowiecki（2014）却指出， 大部分人的持续忙碌，其实都是自己主动选择的。

而在这种自主选择的忙碌背后，可能是一种深深的焦虑感，一旦停止忙碌，人们就会身陷其中。

对于许多超时工作、不停加班的人而言，“不忙就焦虑”是他们普遍的困扰，但其背后的原因却是不尽相同的。正如我们曾提到过的，焦虑，是一枚情绪的通用货币，每个人的焦虑背后，都可能包含了千差万别的认知想法与情绪需求。

A 款焦虑：对被需要的渴望

无论你是否承认，每个人都或多或少需要“被需要”。 这种感觉，会让我们获得价值感与力量感——“我有能力帮助他人实现愿望”、“我受他人重视和感激”， 还会让我们直观感受到自己与世界上其他个体的联结。

对于 A 款“不忙碌焦虑”的人群来说， 你也许没有意识到，其实你需要的不是工作，而是在工作中被人需要的人际满足感。

他们在家庭和感情生活中，很难感受到“被需要”。只有在工作的忙碌中，才能体会人际互动、以及他人对自己的依赖和肯定。因此，一旦停止忙碌，他们就会不自觉地陷入一种莫名的焦虑。其实，他们是用焦虑掩盖了内心最深处的恐惧——潜意识中， 他们怀疑自己在工作以外的世界里，不会被需要、也不会被爱。在工作以外的世界里，他们感到自己失去价值，被他人和世界所遗忘。

他们以为自己享受的是忙碌，其实是人间烟火和温情脉脉。

B 款焦虑：误把成功与忙碌划等号

移动互联网的普及，催生了“永远在线”（always on）的职场文化，我们的工作和生活也早已不存在绝对的区隔，在周末或度假的时候收发邮件、随时随地处理工作是常态。不妨试着回想一下，你上一次可以“完全不处理任何工作”的时间是什么时候？

这种职场文化带来的是人们对于“忙碌”与“休息”看法的改变。越来越多的雇主与员工都开始认为 “不停忙碌才意味着尽职尽责”、“休息就是消极怠惰”、“越是忙碌的人，对公司价值越高”等等。在这种职场文化中， 忙碌，逐渐被与“尽职”、“成功”画上了等号。

永远在线的职场文化，让每个人都感染上了一种竞争压力。 如果不这么忙，自己会不会就变成一个失败者？没出息的人？就算自己并不想忙碌，一旦悠闲下来，也可能真的被老板和他人评价为 “懒惰”、“不尽责”、“不够优秀”。

这个社会对于人忙碌程度的要求已经不再合理了。

C 款焦虑：一种深刻的存在主义绝望（existential despair）

人们无时无刻忙碌的另一个原因，可能来自一种存在主义绝望。生活的意义，工作的目标，他人的期待等等，这些使得我们保持忙碌的事物，无论多么世俗，都令我们的“存在感”/ 生命意义感得以存续（Tsilimparis, 2018）。

Tsilimparis（2018）认为 当不再有这些可以让自己去努力和付出的事情时，人们很容易陷入对于自我有限性的过度思考之中。我们可能会强烈地感受到生而为人的平凡与渺小，怀疑生命存在的意义与价值，继而陷入一种巨大的、难以承受的绝望。

芝加哥大学的 Hsee 等人（2010）的实验也从某种程度上证明了这一点。

他们邀请了一群参与者完成 2 个任务。这两个任务之间有 15 分钟的休息时间，参与者需要在这段时间里将任务一中填写的调查表交还到指定地点。此时，这些参与者可以在两个制定地点中任选其一：

• “远”：12 分钟在路上，3 分钟等待下一个任务
• “近”：就在门口交表，15 分钟等待下一个任务

结果，大多数人选择离自己较远的地点交表格，力求减少一个人无所事事独自等待的时间。 人在纯粹无事可做的独处中，是很容易感到不舒服的。实验结果也证明，走了更远路的被试，在情绪反馈表上，比那些走得短但一直在等待的人，心情更加愉悦。

和对人际温暖的需求相似又略有区别。C 款不工作就焦虑的同学们，是用忙碌逃避一种停下来就是笼罩在身上的无意义感。人会因为过度思考“我为什么活着”这一类存在主义的问题而产生负面感受。人很容易在这样直面自身的过程中，陷入到虚无感中。“瞎忙”是很多人躲避陷入虚无感的自我保护手段，忙工作忙朋友聚餐忙四处旅行。

除此之外， 还有一些人比其他人更容易在停止忙碌之后倍感焦虑。

重点人群 1 型：讨好者

他们总是忍不住想取悦他人。他们会在讨好别人的过程中表现出过度的责任心，试图让所有人都满意，也试图为所有人的工作负责。这就不可避免地会让他们陷入过度的忙碌之中，且一旦停止忙碌，他们就开始担心他人会对自己不满。

重点人群 2 型: 情绪无能者（爱无能的人）

Damaske 等人（2014）的研究发现， 越来越多的人正把办公室当做情感寄托，他们不寻找生活伴侣，或者不投入太多精力在家庭中。办公室对他们来说是更舒服的场景。 对于情绪无能的人来说，更是如此。

我们曾介绍过，“情绪无能”的人对于深刻的爱、或深层的情感交流不感兴趣也无所适从。他们不明白自己的情绪是什么，也不擅长共情他人的感受，也不知道如何沟通情绪和感受。于是，他们情愿把时间和精力花费在无需情感投入的工作上，这样自己就拥有了“我没时间处理感情”的正当理由。

第 1 款恶果：

情感瘫痪（Emotional Basket Cases）

身处被焦虑感支配的忙碌之中，人们在精神上和身体上都很难真正放松。有研究发现，那些工作时间更长的人，需要更长的时间才能从紧张的状态中真正放松下来，让身心得到修复（Virtanen, 2009）。

Gorden（2014）指出，在身体与心理长时间超负荷的工作下，人们很容易陷入 情感瘫痪，即在人际间解读情绪的能力急剧下降，不能觉察到自己和他人的情绪需求，甚至也很容易误读他人的情绪，与他人产生误会与摩擦。

比如，陷入情感瘫痪的人，常常不能意识到自己已经处在一种暴躁易怒的情绪当中，并且不自觉地说出了许多伤人的话，他们也无法从对方的表现里“读出”自己的话已经造成的伤害。

而这往往给人们的社交关系带来很大的影响，导致伴侣、同事及家人朋友之间的失和，甚至关系的彻底破裂。

第 2 款恶果：

你会变胖、变笨

正如我们在“情绪性进食”的文章中所提到的那样，当我们焦虑的时候，我们会试图吃点什么来给自己安慰。又因为我们正被这种焦虑感支配的忙不迭，我们往往只能选择一些方便易得的外卖或快餐来满足口欲。于是，肥胖，就成为了忙碌的另一个代价。

不仅如此，还有研究发现， 连续 5 年处于忙碌状态（每周工作超过 55 小时）的人，他们的大脑认知功能可能会下降，即他们在词汇、推理、记忆与运算速度上都比 5 年前有明显的下降；对照组中不那么忙碌的被试，在 5 年前后的区别远没有这么明显（Virtanen, 2009）。也就是说，过度忙碌还会让人变笨。

第 3 款恶果：

切换任务时反复消耗的认知成本

另外，为了让自己忙起来，我们还可能陷入一种不必要的“多线程工作”（multi-tasking）。比如，一个人明明可以先完成 A 项任务，再进行 B 任务。但 Ta 为了逃避焦虑感，就可能会在完成 A 任务的过程中，给自己穿插着安排 B 任务一起做，让自己处于不必要的多线程工作中。

这种不必要的多线程工作，会让我们产生一种“虚假的效能感”——自我感觉良好，感到自己很努力——但往往实际效率不高，工作质量也受到影响。

这是因为 每当人们从 A 任务转换到 B 任务中时，他们的注意力都仍有一部分被“残留”（attention residue）在了 A 任务之中（Leroy, 2009）。 每一次转换任务，都是有成本的（shifting cost），是对一个人认知资源与注意力的消耗。这就是为什么人们很容易“忙中出错”的原因（Dahl, 2015）。

首先，你需要意识到自己是上述哪一款焦虑宝宝。你用工作在逃避什么？是逃避人际中的孤独感？是担心影响别人对你的评价？是逃避一种停下来之后的空虚感？你的忙于工作，是不是因为感到自己不被人真心所爱、不被人保护、不被人需要。所以忙碌成为了一种替代性的可以让生活有充实感、幸福感的途径。

其次，你需要明白， 忙碌只不过是暂时缓解了焦虑感，但它可能带来更多长期的后果，比如，上文中提到的过度忙碌可能使人情感瘫痪，最终导致的人际关系的失和，甚至彻底破裂等等。

另外，你也要学会享受任务间歇的休息时间，不要总想一刻不停。有研究发现， 在工作期间进行 15~30 分钟的小睡，有助于提升记忆力，并且能让人在睡觉的期间及时“清空”大脑，减少注意力残留，为之后接触新的信息作准备（Soong, 2010）。

最后，对于那些长期与存在主义绝望对抗的人而言，人和人之间真正的情感联结才是你获得生命意义感的来源。这种情感的联结，是需要你付出尝试——至少要有机会不断接触到新的人，同时双方共同尝试走近对方、信任对方，才最终慢慢达成的。这个过程对于很多优秀工作者来说，可比做好工作难太多了。

人们都喜欢做自己擅长的人，而倾向于躲避自己的表现成绩不够好的任务。这些优秀的工作者，更不喜欢面对“我不足够优秀”的批评和自我批评。所以他们不断选择工作，放弃人与人之间的经营。最后前者越做越拿手，后者越来越落后同龄其他人群。最终形成恶性循环。

最终，我们都得面对自己真实的、全面的需要。只有当你的自我价值感和幸福感，来自于各种不同的来源时——工作、家庭、朋友、爱好等等——你的幸福才不是高空走高丝般如履薄冰，也不是有一方面出问题就能让你粉碎。

如果你是一个一停止忙碌就焦虑的人，是时候让自己停一段时间了。想一想，你缺的到底是什么，你工作最终渴望的生活目标是什么？不要畏难，选择自己最薄弱的方面做做练习、成长提升。

忙的正面意义只存在于当它真的能把你引向更好的生活时。而什么是好生活，对每个人来说的定义都是很个人的。没有人能帮你回答这个问题，包括所有会因为你看起来不够忙批判你的人。你要自己回答好这个问题，然后才能找到真正适合你的工作与生活的节奏。

以上。

条条大路通罗马，但有的人就住罗马。来源: scientific american

这世界上绝大多数的成功读物都会孜孜不倦地教导你：只要努力，就能成功。但无论是科学研究还是社会经验都告诉我们，这并不是一个靠谱的结论。最近一组意大利的研究人员发现，那些平凡却幸运的个体，要比有天赋而不幸的个体更加成功。换言之， 很多取得巨大成就的人，他们也许并非具有过人的才能，而只是运气特别好罢了。这一结论可以帮助我们建立更加公平高效的社会机制。

作者 | Scott Barry Kaufman

翻译 | 施怿

编辑 | 王妍琳

想获得成功要具备什么条件？成功人士都有那些秘诀？从《成功》、《福布斯》、《企业家》等杂志的流行程度来看，人们对成功这一话题从不乏热情。一种深层次的假设认为： 成功是可以习得的。这一假设基于成功人士身上具备的、促使他们走到今天的那些个性特征，例如天赋、才能、意志力、勤奋、韧性、乐观、成长型思维以及情商。这一假设不仅是这些成功学杂志得以流行的基础，也影响了我们的社会进行资源分配的方式。从工作机会到荣誉，再到政府补助，再到公共政策决策， 我们都习惯于假设最成功的人也是最能干的，并将资源分配给那些有成功过往的人，而倾向于忽略那些不成功的人。

但这一假设正确吗？在整个职业生涯中，我一直致力于研究能预测成就和创造力的心理特征。虽然我已经发现，有一些心理特征（例如：激情、毅力、想象力、求知欲和开放性）确实能很好地解释成功之间的差异，但我更感兴趣的是，有多少差异是这些特征无法解释的。

近几年里，有不少研究和书籍都认为， 在包括金融交易、商业、体育、艺术、音乐、文学和科学在内的多个领域中，运气和机会可能比我们以为的更重要。他们的观点是：虽然天赋也很重要，但数据表明，在试图找出成功的决定因素时，如果我们只专注于个人特征，那么就会错过成功图景中真正重要的一片拼图。

以下是一些新发现：

全世界人民的收入差异有一半可以由他们所在的居住国和该国的收入分配差异来解释；

科研成果的影响力是随机分布的，在科研生涯中，仅高生产力这一个因素对高影响力的研究成果产生的影响是有限的；

能否成为CEO会受到你叫什么名字或出生在几月的影响，在六月或七月出生的CEO比其他月份要少得多；

姓氏首字母在字母表中更靠前的人更有可能获得最高部门的职位，有中间名缩写的人更容易在智力和成就方面获得更多的正面评价；

名字更易拼写的人比名字难拼写的人更容易获得肯定；

女性姓名听起来更阳刚，则更易在法律职业生涯中获得成功。

运气这一隐藏维度的重要性引出了一个有趣的问题：我们社会中那些成功人士取得了成就，仅仅是因为他们比较幸运吗？这一假设哪怕只是部分正确，都将对我们如何分配有限的资源产生重大影响，也将帮助富人和成功人士更有效地回报社会。

为了试图阐明这一重大问题，意大利物理学家Allesandro Pluchino、Andrea Raspisarda和意大利经济学家Alessio Biondo组成研究小组，第一次尝试量化运气和天赋对成功的影响。在他们开创性的工作中，他们提醒那些“天真的精英”， 人们低估了随机因素的作用，而实际上并没有把荣誉和奖励赋予最有能力的人。为了进一步解释这一现象，他们提出了“玩具数学模型”，模拟了一群人在40年的工作生涯中（从20岁到60岁）职业的发展变化。

模拟初始化设定图（N=1000）

图片来源：Pluchino,Biondo, & Rapisarda 2018

意大利研究者们设定了大量“天赋”水平不同的假设个体（“代号1”至“代号1000”），将这些个体置于一个正方形的世界中，让他们在其中经历他们的整个工作生涯。他们将“天赋”定义为 让一个人能够抓住机遇的任何一组个性特征。天赋可以包括智力、技能、动机、决心、创造性思维、情商等等。这里的关键在于， 更有天赋的人会更倾向于从各种机会中找出最适合他们的那一个。

在模拟开始时，所有的个体拥有相同的成功值（10“成功单位”）。每六个月，这些个体会遇到特定数量的 幸运事件（绿色）和特定数量的 不幸事件（红色）。当个体遇到不幸事件时，其成功值减半；当个体遇到幸运事件时，其成功值根据其天赋水平按比例增加（以反映真实世界中天赋与机会之间的关系）。

他们的发现是什么？首先，他们重现了著名的“ 帕雷托原理”。这一原理认为，少数人最终将获得大多数人的成功（Richard Koch又将其引用为“80/20原理”）。在40年模拟的最终结果中，虽然初始设定的天赋呈正态分布，成功却不是。 20名最成功的个体合计占有了44%的成功值，而将近半数人的成功值维持在10单位以下（与初始设定值相同）。这一结果和来自真实世界的数据相同，甚至有迹象表明，财富成功在真实世界中的分布要更加不平衡：最富有的8个人拥有的财富等于世界上最贫穷的一半人的财富总和。

天赋的正态分布

图片来源：Pluchino,Biondo, & Rapisarda 2018

高度不平衡的成功值分布

图片来源：Pluchino,Biondo, & Rapisarda 2018

尽管如此不平衡的分布看起来很不公平，如果那些最成功的人也是最有天赋最有能力的人，那么这一结果也可以合理化。那模拟结果是否是这样的呢？一方面，天赋并不是与成功毫不相干。通常情况下，天赋更高的人更有可能抓住运气提供的机遇。并且，模拟中最成功的个体天赋水平大多至少在平均值以上。所以 天赋确实重要。

然而， 只有天赋是绝对不够的，因为那些最有天赋的个体只有极少数也是最成功的。通常情况下， 平凡却幸运的个体要比有天赋而不幸的个体更加成功。那些最成功的个体往往只有稍高于平均值的天赋水平，却在生活中充满了运气。

以下是他们模拟实验中最成功个体和最不成功个体的成功值演变图：

最成功和最不成功个体的成功值演变图

图片来源：Pluchino,Biondo, & Rapisarda 2018

正如你所见，绿色线条表示的最成功的个体在其生命中遇到了一系列非常幸运的事件，而红色线条表示的最不成功的个体（他们甚至比那些最成功的个体天赋更高）在生命中经历的不幸事件难以想象地多。正如论文作者所说，“在不幸的怒火面前，即使拥有极高的天赋也无济于事。”

怀才不遇无论对个体还是社会而言都是不幸的。因此，我们可以做些什么来让那些最有能力利用机会的人得到他们最需要的发展机会呢？

更有效的资助策略

许多“精英主义”用以分配荣誉、资金或奖励的策略，通常基于某个人过去的成功经历。以这样的方式进行选拔无疑会导致富人更富、穷人更穷，这也被称作“ 马太效应”。但这是激发潜力的最有效策略吗？如果你是决策人，哪一种投资策略会更为有效呢？向几位以前有成功经历的申请人提供大笔资助，还是将资金分成很多份分给许多不那么成功的普通人？

Jean-Michel Fortin和 David Currie 曾研究过更大规模的资助是否会带来更大的成果。他们发现在研究资金和科研成果影响力之间的确存在一定的正相关， 但这种关联非常微弱。更重要的是，那些获得第二笔资助的人并不比那些只获得一笔资助的人更多产，而且对于这些人而言成果通常是资助的递减函数。

论文作者们认为， 比起那些以“优秀”作为遴选标准的项目，更关注目标多样性的资助策略可能会对社会产生更大的影响。在一项更新的研究中，研究人员研究了魁北克在15年期间内对12720名研究人员提供的资金。他们得出的结论是，“在论文数量和科学影响方面，研究资金集中在所谓的‘精英’研究人员手中，通常会产生边际收益递减”。

基于这项工作，模拟了运气对成功的影响的意大利研究组进行了进一步模拟。他们从上帝视角探讨了许多不同资助策略的有效性。在模拟个体的40年工作生涯中，他们每隔5年就换用一次不同的资助策略。我们已经发现，在没有任何资助的情况下，最成功的个体是那些拥有平均天赋水平却非常幸运的人。当研究组向模拟中引入多种资助策略后，会有什么结果呢？

不同资助策略的效率

图片来源：Pluchino,Biondo, & Rapisarda 2018

这一表格按效率递减的排序列出了40年间最有效的资助策略（例如，需要的资金最少而获得的投资回报最大）。从下至上阅读列表，可以发现 那些把一定比例的资金给已经非常成功的人的资助策略是最无效的。将一定比例的资金给那些已经非常成功的个体而将余下的资金平均分配的“混合”策略相比之下要更有效一点， 但这些都还不如随机分配资金的策略高效。最后这一项发现非常有趣，因为它与其他一些研究结果一致，这些结果都表明，在复杂的社会和经济环境中，机会很可能发挥了一定的作用，在这一前提下， 结合了随机性的策略比基于“精英主义”的策略表现更好。

这表示，最佳资助策略应当是给每个人都分配同等数量的资金。当以每5个月1单位的速度分配资金时，60%的最有天赋个体获得了超过平均水平的成功值，以每6个月5单位的速度分配资金的结果是，100%的最有天赋个体都产生了影响力！这表明，如果一个资助机构或政府有更多的资金可供分配，那么将这些额外的资金均分给每个人，与只给一部分人相比是更明智的选择。

正如研究者总结道：“如果投资目标是奖励最有天赋的人，以使他们最终获得更高的成就，那么向所有人定期等额提供资金，会比将大额资金提供给被选中的小部分人更有效。”

什么样的社会更容易造就成功？

这个不可思议的意大利研究组并没有就此止步！既然拥有了上帝视角，为什么不钻研到底呢。他们还做了一些改变了个体所处环境的模拟实验。使用之前搭建的框架，他们模拟了一个非常激励人的环境，对每个人而言都充满了机遇（比如像美国那样富裕而高度工业化的国家），也模拟了一个相比之下不那么激励人的环境，只有非常少的机会（比如第二次世界大战中的国家）。以下是他们的发现：

最成功个体在充满机遇的环境（上）和机遇不多的环境（下）中的成功值

图片来源：Pluchino,Biondo, & Rapisarda 2018

观察比较充满机遇的环境（上）与机遇不多的环境（下）中结果分布的差异。在上半幅图模拟的环境中，一部分天赋水平中上的个体能够获得非常高的成功值，天赋较高的人获得较高成功值的可能性也比较高。相反，在第二幅图模拟的环境中，整个社会的总成功值水平很低，并且只有18个个体获得了比初始值更高的成功。

以上模拟实验的结果与越来越多的基于真实世界数据的研究结果相吻合，所有的结果都强烈表明， 运气和机会在决定个人的最终成功水平方面扮演着重要角色。正如研究者指出的，奖励和资源通常都被给予那些已经被高度赞扬的人们，而这往往会导致最有天赋的那些人（比如，最有潜力因这些资源真正受益的人）反而得不到机会。在进行这样的资源分配时我们忽视了运气扮演的重要角色，实际上，运气的影响在整个创造性的过程中难以避免。研究者们认为，为了给人们更多成功的机会，以下因素都很关键： 一个充满机遇的环境、良好的教育、密集的培训和行之有效的资金与资源分配策略。他们认为，任何能够影响这些因素的政策都将有助于公民的个人实现，也会在宏观层面为全社会带来更大的集体进步和更多创新。

原文链接：https://blogs.scientificamerican.com/beautiful-minds/the-role-of-luck-in-life-success-is-far-greater-than-we-realize/

《环球科学》3月刊现已上市

欢迎点击 阅读原文购买