写在最前

前文提到过查询的优化问题，这里我们了解下怎么更精准地去找到到底是哪里出了问题。

结构

这里我们在hive shell里面执行任务时的日志信息，里面可以获取很多信息，这里我们先看一下Application，Task ，Job和Stage这几个概念，这里借鉴一下Spark的…

1
2
3
4

Application：User program built on Spark. Consists of a driver program and executors on the cluster.
Task：A unit of work that will be sent to one executor
Job：A parallel computation consisting of multiple tasks that gets spawned in response to a Spark action (e.g. save, collect); you'll see this term used in the driver's logs.
Stage：Each job gets divided into smaller sets of tasks called stages that depend on each other (similar to the map and reduce stages in MapReduce); you'll see this term used in the driver's logs.

更直观地感受就是去看一下shell里输出的日志信息，里面都是有用的。这里画了一下图，助于理解

执行

• 如果发现查询过程中效率很低，这个时候先观察日志，到底是哪一步慢了，至少细化到Stage粒度
• explain yourfile.hql，查看hive的执行计划

这里就不贴实际的代码和输出的信息了，在公司环境上搞的，还是稳健一点比较好。
虽然对Spark了解不多，但感觉对其优化应该也是这么一个思路吧，后面该开始了解一下Spark了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

import this

'''
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
'''

翻译一下:

Python之禅

优美胜于丑陋（Python 以编写优美的代码为目标）
明了胜于晦涩（优美的代码应当是明了的，命名规范，风格相似）
简洁胜于复杂（优美的代码应当是简洁的，不要有复杂的内部实现）
复杂胜于凌乱（如果复杂不可避免，那代码间也不能有难懂的关系，要保持接口简洁）
扁平胜于嵌套（优美的代码应当是扁平的，不能有太多的嵌套）
间隔胜于紧凑（优美的代码有适当的间隔，不要奢望一行代码解决问题）
可读性很重要（优美的代码是可读的）
即便假借特例的实用性之名，也不可违背这些规则（这些规则至高无上）
不要包容所有错误，除非你确定需要这样做（精准地捕获异常，不写 except:pass 风格的代码）
当存在多种可能，不要尝试去猜测
而是尽量找一种，最好是唯一一种明显的解决方案（如果不确定，就用穷举法）
虽然这并不容易，因为你不是 Python 之父（这里的 Dutch 是指 Guido ）
做也许好过不做，但不假思索就动手还不如不做（动手之前要细思量）
如果你无法向人描述你的方案，那肯定不是一个好方案；反之亦然（方案测评标准）
命名空间是一种绝妙的理念，我们应当多加利用（倡导与号召）

2018，我大学毕业的第一年
2018，我小学毕业的第十年

写在最前

早有写下2018年终总结的计划，但是一直拖着没有写。今天是2018年12月29号，回想这一年来的种种，还是有一点感慨，里面随便挑一两个都对我的生活产生了巨大的影响，这里就一并写下来。

关于生活

生活上最大的改变就是从宿舍搬到自己租的房间了，很幸运地和ruibin一起在公司附近租了一个两室一厅，每天都可以走路上下班了（租房那段时间辛苦ruibin老哥了…）从此离开了大学宿舍开始了自己一个人独立生活，少了些热闹，但多了些自由。不过有一点不好的就是每天还是一点多睡，早上九点多才醒。

自打工作之后，吃得多了好了，体重也在缓慢增长，虽然已经趋于稳定…五月我在前辈们面前吹嘘我长不胖，现在想来当时前辈们看我的眼神大概是有了一种关爱智障的味道。

和家里保持一周至少一通电话，不过妈妈说最近越来越想我了。

运动也少了很多，正式入职之后经常晚上八点多九点才下班，回到家还是很疲倦的，周末也常和kk宅在家里，明年得改。

五月份去了一趟泰山烟台；六月份毕业旅行去了伊犁；九月去了大连；国庆去了冰山梁，没有赶上十一月的泰国行。明年还是得多走走，读书和旅行都是好东西。

今年看了蛮多电影和纪录片的，电影院上的、豆瓣Top榜单上的、B站上的纪录片等等，很开心。音乐方面Top3则是《Merry Christmas Mr. Lawrence》《きっとまたいつか 》《沧海一声笑》，工作或是读书都喜欢听~

关于爱情

很幸运今年认识了kk，从烟台之行后不久正式在一起，到现在感情越来越好。煽情的话就不在这里说啦，希望以后的日子可以一起走下去！

关于工作

春招进入了猿辅导，很开心。

三月到六月是实习期，这段时间主要熟悉贵司的业务与上手自己的工作，期间很多认识了很多优秀的同学，教会了我很多东西，这里要特别感谢金勇，在刚进公司的初期给了我很多指导，直到现在依然很受用。

七月开始正式入职，开始全面对接辅导运营推广及部分小学产品的数据工作，中间具体细节不谈。年终回顾一下，领导给予了肯定，对接的同学没有直接问，不过应该也还是可以的。

关于学习

学校

我也忘了是什么时候查的考研分数，鉴于数学涂错答题卡这种操作，跪了。不过当时应该就是知道自己上不了自己想去的实验室了，于是决定春招。还是ruibin老哥抬了一手，内推了一下猿辅导，假期在家里没有玩很多，都是在准备面试，效率不是很高就是了。。。

开学之后过几天就是面试，比较幸运地拿到了offer，其他同学也都是在准备复试之类的，最后全部都如愿上了研究生（感觉自己有点垃圾…），其后就开始了一边实习一边准备毕设的生活。

毕业季呀。

自我学习

自我学习主要还是来自工作上问题的解决和看书。

工作上的坑基本都总结到了印象笔记里，主要说一说看了什么书吧:

技术类

• 《Hadoop基础教程》
• 《数学之美》
• 《贝叶斯思维》
• 《利用Python进行数据分析》—重读
• 《Hadoop权威指南》—在读

人文社科类

• 《菊与刀》
• 《王阳明传》
• 《乌合之众》
• 《黄金时代》
• 《活法》
• 《自在独行》
• 《墨菲定律》

看得还不够。。。

小眺2019

2018这么看来，其实总体还是偏好的。但也有还有很多没做好的事，都当做明年的flag吧。

• 主观地展开一些工作
• 学习一些统计和Java相关的知识，争取一月一本技术书籍，人文社科类的随性。
• 坚持维护博客
• 渐渐开始睡早点，醒早点，稳定于12点睡觉，七点半醒。
• 带kk出去走一次长线
• 学会吹口琴
• 健身，这个随缘…

写在最前

关于TF-IDF算法本是我九月组内分享会的内容，前段时间看《数学之美》的时候又重新看到。虽然在实战中使用的机会很少，但是不妨碍我们去感受去理解这些简洁却有力量的思想。

什么是TF和IDF

• TF:词频(term frequency),即一个词语出现在一篇文章的频率，计算方式很简单：词频=某个词在文章中的出现次数/文章的总词数
• IDF:逆文本频率(inverse document frequency)，是一个词语的普遍重要性的度量，逆文本频率=log(语料库的文档总数/包含该词的文档数+1)

TF-IDF = TF * IDF

某一特定文件内的高词语频率，以及该词语在整个文件集合中的低文件频率，可以产生出高权重的TF-IDF。因此，TF-IDF倾向于过滤掉常见的词语，保留重要的词语。

具体公式可以参见维基百科

简单应用

TF-IDF 思想及其简单，但是应用起来威力就很大，下面我们来看一个判断句子相关性的例子：

• str0:’今天中午的螃蟹真好吃’
• str1:’今天中午的大闸蟹真难吃’

分词

首先我们需要对句子进行分词处理，网上有很多优秀的资源，比如结巴中文分词，这里我们从简~

str0:[‘今天’,’中午’,’的’,’螃蟹’,’真’,’好吃’]
str1:[‘今天’,’中午’,’的’,’大闸蟹’,’真’,’难吃’]

构建词向量

对我们分词的结果取set(),那么我们可以得到[‘今天’,’中午’,’的’,’螃蟹’,’大闸蟹’,’真’,’好吃’,’难吃’]这个词组。我们分别对str0和str1构建词向量，结果为

• str0=[1,1,1,1,0,1,1,0]
• str1=[1,1,1,0,1,1,0,1]

计算相关性

数学上我们学过向量空间的余弦相似度，在这里就派上了大用场。最简单的例子，若两条直线的余弦为0，表示不相关；若为-1，则表示完全相反。即余弦相似度越大，其内容的相似度越高，其推广到多维空间也是成立的。

公式和计算过程就省略一下,计算结果是0.677,相关系数还蛮高的

更多内容参考这里

更多应用

• 论文检索
• 新闻的分类
• 用户画像

不提爱情，我觉得自己在某些方面还是蛮孤独的，有时享受，有时难受。书中提到：好多人在说自己孤独，说自己孤独的人其实并不孤独。孤独不是受到冷落和遗弃，而是无知己，不被理解。真正的孤独者不言孤独，偶尔做些长啸，如我们看到的兽。一句话写出了所有的毛病。

前面两章读起来很有味道，第三章之后便是草草翻阅，大概阅历是可以看的，但是风土人情是应当自己的去感受体会的，看书里面写再多，也不如去到靖边之类的地方住上几日，吃上一碗地地道道的羊肉泡馍。

洒脱的人生态度很好，但是诸多见解还是无法认同。

写在最前

主要说一下我们平时查询中会遇到的一些性能问题。

Map join

基于join的性质，我们可以知道把小表放在join的左边，可以有效地减少数据量（基本习惯）。同时我们开启map join，小表数据会被广播到各个节点，消除shuffle运算。

1
2

set hive.auto.convert.join = true ; -- 开启自动转化成mapjoin
set hive.mapjoin.smalltable.filesize = 2500000 ; -- 设置广播小表size

distinct

多列或者一列去重

hive是通过group by实现distinct的,如下代码hive的执行计划其实是完全一致的

1
2

select  distinct a,b,func(c) as tt  from xxx ;
select  a,b,func(c) as tt  from xxx  group by a,b,func(c)

如果我们可以确定这个func()是一个单映射的话，那么其实是可以直接等效写为:

1

select a,b,func(c) as tt from xxx group by a,b,c

聚合函数中进行计算

1
2
3

select dt,count(distinct userid) as uv 
from xxx
group by dt

这样会把所有的数据放在一个reducer里面，执行时间较长，可以这么优化，即把

1
2
3
4
5
6

select dt,count(1)
from(
    select  distinct dt,userid
    from xxx 
    ) final
group by dt

这样把第一个阶段分担到多个reducer上，但实际业务过程中，大多数的数据都是在多维度下多指标计算（计算量大），经常会导致数据倾斜之类的问题。

不同条件的count(distinct)

1
2
3
4
5

select dt 
, count(distinct userid) as tt 
, count(distinct if(a rlike 'xxx',userid,null)) as u1
, count(distinct if(b > xxx ,userid, null)) as u2
, count(distinct if(c = xxx , userid , null)) as u3

可以通过标记的方式来解决

1
2
3
4
5
6
7
8
9
10
11
12

select dt
, count(userid) as tt
, count(if(tag0=1,userid,null)) as u1
, count(if(tag1=1,userid,null)) as u2
, count(if(tag2=2,userid,null)) as u3
from(
    select dt
        , max(if(a rlike 'xxx',1,0)) as tag0
        , max(if(b > xxx ,1,0)) as tag1
        , max(if(c = xxx ,1,0))
    group by dt 
)

多维度聚合（group by xx,xx with cube)

手动维护grouping sets的组合

1
2
3
4
5

group by semesterid , grade_type , gradeid , courseid  , seasonid , seasonname, teamid
grouping sets( (semesterid , grade_type , gradeid , courseid  , seasonid , seasonname, teamid )
  , (semesterid , grade_type , gradeid , courseid  , seasonid , seasonname)

  )

不同列聚合

1
2

count(distinct userid)
count(distinct deviceid)

可以进行分拆成两个查询分别计算(load两遍数据),最后join到一起

题目描述

有 12 个球，外形相同，其中一个小球的质量与其他 11 个不同，给一个天平，最少需要几次把这个小球找出来并且知道这个小球是比其他的轻还是重?

思考轨迹

首先想到的当然是分组称重这样的解法：

• 均分为三组，每组四个
• 取任意两组称重…GG

后经大佬提示，涨了姿势:

信息熵计算公式：

$$H(x) = - \sum_{i=1}^{n} P(x_{i}) \cdot log_2{P(x_{i})}$$

• 有12个小球，分别有重和不重两种状态，即有24种可能，那么信息熵为$H(x)=24 \cdot {1 \over 24} \cdot \log_2{24} = log_2{24} $
• 我们每一次称重存在三种状态，即轻、重、平衡，那么每一次称重的熵为$H(x)=3 \cdot {1 \over 3} \cdot \log_2{3} = log_2{3} $
• 所以理论上称重次数为$ {log_2{24} \over log_2{3}} = 3 $,即三次即可找出小球

100个，1000个也是同理，从信息论的角度来看只是熵大小的差别。

同理，给定称重次数N，也可以反推回去最多可以称多少个小球。（$n = \frac {3^N-3}{2}$）

具体实现

概括一下就是：

• 分为三组
• 平衡Pass，若不平衡，则引入三个正常球替换三个球
• …

final

在金勇的博客上看到这个问题，于此写下回答。

在解决很多常规想法看起来不好确定的问题的时候，从熵的角度去看会很有用。

写在最前

每天其实都有蛮多事情，亦或者说很多想法吧，不定期更新一下~

关于今天刷屏的成都七中直播课

今天被冰点周刊的关于“全国两百多所学校通过成都七中的网络直播课展开教育的新闻，文中数据显示7.2w人通过直播课学习，88人考上清北”刷屏了。关于这个新闻，心里面是有一些想法的：

• 这是一个好事，绝对绝对的好事！以一个相对公平的方式去分享好的教育资源，给想要学习却又囿于资源的同学提供了一个很好的方式！
• 数据有失真。据我了解，这些学校都是成立了试点班级，选取的基本都是自己学校顶尖的学生来组成直播班，文中举的例子也基本着力于这些学生中的头部学生，应该是为了宣传效果吧。
• 这样的班级会配备老师在课堂上做一些辅导工作，比如针对直播的老师讲的一些点做补充之类的，首先这样对老师公平吗？其次是对于学生，这样讲课与班级管理分开，个人感觉师生之间缺少了点什么（纽带？）
• 这个也是收费的，学校需要支付给一个网校机构一大笔钱。打着公益的名头干收钱的事儿不对，有益的事情是应该有利的，单收钱就不要提公益（听说要收钱，没有去查证）
• 明年在线教育行业应该会发生挺多事的，感觉国家意志开始介入了。

一直记得高中班主任说的那句：到学校应该先学做人，再学知识。

关于Hive优化

在调整了几个之后感觉这个最重要的知识还是在于理解MapReduce，比如今天遇到一个问题是有一个Map任务耗时特别久，检查之后发现时case when判断的时候string类型的grade的条件值的是int类型的，这里就多个一个对每行数据取公共类型的处理，导致Map任务耗时增加。再有就是数据倾斜了，这个之前有写过，感觉会是一生之敌，不过改天还是总结一下实际业务中常见情景及解决方法吧。

使用了一下快手

抖音实在是太火了，虽然我没有用过。。。我主观地以为这个就像是粉饰了的太平，喧嚣但是没有啥营养，高频的刺激让用户觉得很上瘾吧。很早之前因为下载过快手，但是很快就卸载了，觉得真的太low了,里面的视频都是弱智么…不过前几天因为虎嗅的一篇文章重新下载了并且保留了几天都没有卸，应该是因为真实吧。

昨天看到张小龙的年会摘录，里面有一条是：

• 大部分产品都在欺骗用户，你做各种滤镜，你说[记录美好生活]，但生活其实是不美好的。

Be real。

读《乌合之众》杂想

今晚看完了勒庞的《乌合之众》，有些许印象与点点想法，记录一下：

• 你信不信这译本的前20%都是译者的序。。。
• 群体是不相信原则的，如果想要引领群体，就要去寻找他们所关心的点
• 种族是对一个群体最大的影响（种族->文化->传统->制度->教育）
• 遗传赋予每个种族中的每一个人某些共同特征，这些特征加在一起，便构成了这个种族的气质
• 人们从来不是按照纯粹理性的教导来指导行动的
• 作出简洁有力的断言，不理睬任何推理和证据，是让某种观念进入群众头脑最可靠的办法之一。再搭配重复、传染的方式，会变得很有力有效

最近开始了解贝叶斯相关的东西，《贝叶斯思维》这本书开篇提到的“Monty Hall Problem”就很有趣（第一次我也错了。。。）这里就记录一下这个问题。

问题是什么

书里面描述有点多，直接简化来说现在有三道扇门，其中一扇后面有10w软妹币，另外两扇后面则是1软妹币,现在我们按如下的规则玩游戏：

• 猜那个后面有大奖，猜中则拿到大奖
• 让你先挑选一扇门，我们称之为A，另外两扇分别为B，C
• 为了增加悬念，这个时候主持人会打开B，C中的任意一个，假设B吧（B，C中肯定可以开一个)
• 然后主持人给你一个选择：是坚持最初的选择还是换到剩下未打开的门上

我的第一反应是这俩没啥区别，既然开了一扇小的，那么剩下两扇门后面中大奖的概率应该是五五开的。但是一个贝叶斯主义者应该不这么看，此时的概率已经悄然改变。

分析

贝叶斯公式

估计这个不需要介绍太多

通俗一点解释就是：

后文例子中：

• $p(H)$：先验概率
• $p(D \vert H)$：似然度，即在该假设下得到某数据的概率
• $p(D)$：标准化常量，即在任何假设下得到某数据的概率
• $p(H \vert D)$：后验概率，即看到新数据后，我们要计算的概率

定义事件

我们可以把事件归纳为以下两件，其中重点是理解事件D

• H : 钱在门后面

• D : 打开门B且钱不在后面

算算概率

先验概率一眼而知，但是似然度就需要一些思考了，现在我们分开来看：

• 对于假设A，即钱在A门后面，那么在这种情况下，BC两门任选，即$p(D \vert H)={1 \over 2}$
• 对于假设B，主持人必须打开门C，此时$p(D \vert H)=0$
• 对于假设C，主持人必须打开门B，此时$p(D \vert H)=1$

算一算$p(D) = {1 \over 2}$,后面的后验概率也是呼之欲出了

个人思考

就跟考试的时候选择题第十题，假设这个时候你已经知道一个答案的错的情况下，再去选择的话，只要不傻，正确的概率就由0.25变成0.33了赛。
个人感觉重点是理解似然度的计算，理解已经发生的事情对未知的事情（打开了门B且没有钱）对未知的事情（钱在哪一个门后面）产生的影响。

MapReduce的核心思想是分而治之和并行处理。

举个栗子

假设我跟一个身高一米八体重一百八的大胖哥打架，我估计我有点危险，这个时候怎么办呢？打个电话叫兄弟赛，单挑是一个打一群，群殴是一群揍一个，MapReduce大概干的也是这个事儿~

键值对

键值对的具体含义

键值数据作为MapReduce操作的基础，让MapReduce变得十分强大。因为很多数据要么本身即是键值对的形式，要么可以以键值对的形式表示，其简洁而有力，所以我们有必要清晰一下键值对的特征：

• 键必须是唯一的
• 每个值必须与键相关联，但键可能没有值
• 对键有明确的定义，比如是否区分大小写

MapReduce作为一系列键值变换

有人这么描述MapReduce:

{K1,V1} -> {K2,List<V2>} -> {K3,V3}

现在我们试图来理解一下：

• MapReduce作业中map方法的输入是一系列的键值对，我们称之为K1、V1
• map方法的输出是一系列键和与之对应的值的列表（其作为接下来reduce方法的输入），我们称之为K2、V2。注意一点是map方法输出的其实是一系列单个的键值对，需要shuffle方法组合成键与值列表
• reduce方法接受输入，输出K3、V3

MapReduce执行流程

直接看图写作文吧（图来自互联网）

1.输入和拆分（Input&Split）

对数据内容进行分片处理，例如WordCount例子中便对每行内容拆分为单词。

2.迭代（iteration）

遍历输入数据，并将之解析成key/value对，即{K1,V1}。

3.映射（map）

将输入key/value对映射成另外一些key/value对。MapReduce开始在机器上执行map方法，map()由我们定义。

4.洗牌过程（shuffle）

依据 key 对中间数据进行分组(grouping)，输出{K2,List}。其中会有排序、合并、分区等操作，是一个很神奇的地方，需要专门学习一下。

5.归约（reduce)

以组为单位对数据进行归约(reduce)，输出{K3,V3}。

6.迭代

输出文件到HDFS。

说点屁话

讲道理到现在直接写MR程序还真没干过，都是直接用Hive搞了，节约了大量的时间，但是理解工欲善其事必先利其器，学习一下MapReduce的各种知识，感觉还是蛮有必要的。