Quantcast
Channel: IT社区推荐资讯 - ITIndex.net
Viewing all 15896 articles
Browse latest View live

算法在社区氛围的应用(三): 机器学习在答非所问识别上的运用

$
0
0
跳绳的好处有哪些?可以锻炼哪些肌肉?
A:心肺功能比之前有提高。
B:有助于提高身体的乳酸阈值。
C:有助于提高身体的协调性。
D:谢谢,我去买了跳绳。

请问,以上哪个答案是答非所问?

现在,瓦力可直接识别并处理该题中的答非所问内容。

我们鼓励认真、专业的分享,期待每一次讨论都能碰撞出更多有价值的信息,并希望每一个用心的回答都能够得到好的展示,为他人带来更多帮助。但是,我们也发现在社区中出现了答非所问类的内容,影响知友们获取有价值内容的效率。

为了更好地识别答非所问类内容,我们采用了多种模型,包括传统的机器学习模型和比较新的深度学习模型。通过前期对语料的分析,我们发现语言用词、作者历史行为、知友对内容的反馈信息等都具有比较明显的区分度,因而我们尝试使用特征工程和传统机器学习方法实现了瓦力识别答非所问的第一版模型,并达到了一个相对不错的效果。

Random Forest

随机森林 (Random Forest) 是树模型里两个常用模型之一(另一个是 Gradient Boosting Decision Tree)。顾名思义,就是用随机的机制建立一个森林,森林由多棵分类树构成。当新样本进入时,我们需要将样本输入到每棵树中进行分类。打个形象的比喻,知乎森林召开议会,讨论 @刘看山到底是狗还是北极狐(看山,我知道你是北极狐的,手动捂脸逃...),森林中的每棵树都独立发表了自己对这个问题的观点,做出了自己的判断。最终刘看山是狗还是北极狐,要依据投票情况来确定,获得票数最多的类别就是这片森林对其的分类结果。如同图一所示意境。

图 1 森林会议

有了树我们就可以分类,那么在答非所问这个场景下,怎么来建立这一个森林呢?

样本

通过训练语料和业务数据,进行特征工程,提取出了以下三类特征:

  • 回答和问题的文本特征:如二者的词向量、词向量相似度、关键词相似度、话题相似度等;
  • 回答的统计特征:如回答的赞同、反对、评论、举报等是用户对其的交互特征;
  • 回答作者的统计特征:正向行为,如关注、回答、提问、评论、举报等,负向行为,如回答被赞同、被反对、被感谢、被举报等。

同时,通过历史积累、用户标注、策略生成产生出了训练样本集,然后用以上特征类别表示出每条样本。

分类树

使用随机有放回抽样选取每棵树的训练样本,随机选取 m 个特征 (m < 总特征数) 进行无限分裂生长,成长为能独立决策的树。

投票决策

通过建好的多棵分类树,对新的样本进行决策投票,获得最终的分类结果。

对于 Random Forest 的实现,有很多优秀开源的实现,在实际中我们封装了 Spark 中的 Random Forest 完成了模型的迭代。最终取得了 Precision 97%,Recall 58% 左右的不错结果。

细心的知友可能注意到了,我们的特征里有一类特征是与时间和回答的暴光有关的,即回答和作者的统计特征。为此我们在现有模型的基础上分析了这类特征的时间累积效果,如图二所示。从图中可以看到,经过一天的统计特征累积,Precision 达到了 90%,但 Recall 只有 40%,可以说这一天时间对于 40% 的答非所问有了比较充分的特征积累以支撑对其的准确判断。而随时间的增加,基本上 Precision 和 Recall 都有提升。但并不是时间越长,提升越多。

最终我们结合产品应用层面和算法阈值,分别选出两个时间点,一方面牺牲 Recall 快速识别处理一部分答非所问的回答,另一方面允许一定的处理延时,保证了大量的 Recall,大大净化了回答区域的无关内容。

图 2 统计特征累积周期(天)对 Precision 和 Recall 的影响

深度学习模型

传统机器学习的一个核心内容就是特征工程,包括特征提取、特征选择等。

  • 特征提取:从原始数据出发构造出特征,通常包括业务和对语料的统计分析。
  • 特征选择:从提取出的候选特征中挑选出有用的特征。

但特征工程总是会耗费比较多的时间,而且在答非所问的识别中一些时间相关的特征,还延长了处理周期,不利于快速处理。而广为流传的深度学习,能自动对输入的低阶特征进行组合、变换,映射到高阶的特征,这也促使我们转向深度学习进行答非所问的识别。

深度学习兴起于图像识别,其过程可以引用图三[1] 大致描绘,输入特征,经隐藏层逐层抽象、组合,最后经输出层得出识别结果。

图 3 深度学习示意

Word Embedding

相较于图片天然的像素表征,可以直接输入到深度神经网络里,文本需要进行向量化后方可作为网络的输入。关于「词向量化」的精彩描述可以参考[2]。此处我们抽取了知乎社区 1000 多万真实的文本信息,包括问题、回答、文章、评论等数据,利用 Facebook 开源的 FastText 训练了 256 维的词向量和字向量。对于 FastText 的原理和用法此处不作详细阐述,感兴趣的朋友可以参考[3]。

CNN 网络 (Convolutional Neural Network)

我们模型的网络结构基本上采用了 Severyn[4] 提出的网络结构,但在一些细节上做了些改动,比如图四中的 CNN-answer/question, 我们结合了 Wide & Deep[5] 的思想,以提取更为丰富的语义信息。

图 4 模型结构

下面简要介绍每一层的含义:

Embedding Layer——该层利用预训练好的 FastText 词向量将原始词序列表达成词向量序列

Convolutional Layer——此层主要通过卷积操作,同时捕获类似于 N-Gram 特征(但同 N-Gram 还是有差异的)。我们的模型选取了 [2, 3, 4, 5, 6] 5 个卷积核宽度,为每个卷积核配置了 64 个 filter

Pooling Layer——池化层,对经过卷积操作提取的特征进行 Sampling。此处我们采用了 K-Max-Average pooling,对卷积层提取的特征,选择出激活程度 top-K 的特征值的平均值作为 pooling 的结果

Feature Join & Fully connected Layer——将前述几层获得的特征,以及额外信息进行融合,作为最终的特征输出,以便于最后的决策判断。实际上,我们在 Fully Connection 后面加了 3 层 Dense Layer,以提高网络的表达能力。

Softmax——将最后的特征转换成二分类决策概率。

最终训练好该模型,在验证集上达到了 Precision 78%, Recall 80% 的效果。Recall 虽有比较大的提升,但 Precision 并没有前文描述的 Random Forest 的方法好。

效果

目前,答非所问几个模型都上线到了知乎产品的诸多场景下,如反对、举报、专项清理等。每天清理约 5000条新产生的「答非所问」内容,以及此前现存的 115万条「答非所问」内容。

为了维护良好的讨论氛围,我们还需不断优化和升级。我们还有很长的路要走,后续我们将建立更为精确的语义模型,辅以问题意图识别,知识库等,更加准确地识别出所有内容。瓦力的升级,离不开知友们的帮助。欢迎大家在日常使用中,继续通过「反对」和「举报」向我们提供更多反馈,与我们共同维护知乎健康的讨论氛围。


本文作者:知乎内容质量安全团队 孙先

参考文献:

[1] Breaking it down: A Q&A on machine learning

[2] 词向量和语言模型

[3] FastText

[4] Learning to rank short text pairs with convolutional deep neural networks

[5] Wide & Deep Learning for Recommender Systems



来源:知乎 www.zhihu.com
作者: 知一声

【知乎日报】千万用户的选择,做朋友圈里的新鲜事分享大牛。 点击下载

GIMP 2.10.0 RC1 释出

$
0
0
开源图像编辑软件 GIMP 项目 释出了 2.10.0 稳定分支的首个预发布版本。GIMP 上一个稳定版本 2.8 还是在 2012 年发布的,两大版本之间相隔长达六年。GIMP 2.10.0 主要特性包括:新的 Dashboard dock 帮助监视软件的资源使用,收集崩溃信息的调试系统,崩溃后图像恢复,新的调整阴影和高光的过滤器,OpenJPEG,图像处理全部使用 GEGL(Generic Graphics Library,支持非破坏性编辑和高位深度图像的图形处理框架),繁体中文翻译,等等。

5-机器学习启蒙- 商品推荐系统1

$
0
0

5- 商品推荐系统

github: https://github.com/mtianyan/graphLabStartedML

推荐商品

有大量的商品和用户,想要推荐一部分商品给用户。
怎么通过机器学习结合你和别人的历史购物记录做出适合你的推荐。

亚马逊重点关注商品推荐,另一个推荐系统流行的例子是2006-2009
年主办的比赛,100万美金奖励推荐电影系统。

我们在哪里能见到推荐系统?

来看一些推荐系统起到重要作用的领域。

个性化正在改变我们关于世界的经验。

YouTube上每分钟有100小时的新视频,这时候哪些才是我们关心的视频变得重要了起来。

信息过载 -> 浏览全部已经成为历史

  • 需要新的方法来发现内容。

个性化:

  • 商品推荐:链接了用户和商品
  • 视频推荐: 链接了观众和视频

影片推荐:

把用户和他想要看的电影联系起来。

商品推荐:

推荐系统组合了全局和临时的喜好。

不仅仅局限于此次购物所要购买的商品。比如:

  • 某人正在买一本网站方面的书,此时他有可能对其他网站相关技术感兴趣。此次购物。
  • 如果我买了一双鞋给我的儿子。但是这些产品并不是我个人的兴趣。查看我的全部购物记录。

去年买了一堆新生儿产品。今年基本上不会再买这个了

推荐应该随着时间而变化。

音乐推荐:

一些可以连续播放的歌曲,曲风相似的歌曲。但是也不能一首歌无限的单曲循环。

推荐系统形成了一致和不同的序列(和而不同)

朋友推荐:

5-机器学习启蒙-  商品推荐系统1

mark

Facebook推荐一些我感兴趣的人。

用户和商品属于同一类型。我买东西推荐东西。我和人联系推荐人。

药品-靶相互作用

5-机器学习启蒙-  商品推荐系统1

mark

药物可以作用于其他的疾病上。批准已有药物的其他作用比批准新药更简单。

构建推荐系统

解决方案0: 流行度

最简单的方法: 流行度

这是在新网站上非常流行的方法。不同分类下最流行的文章,如转发次数最多的。

人们现在正在看什么?

  • 通过全局流行度排序

最大的缺陷: 没有个性化

解决方案1:分类模型

我要买这个商品的概率是多少?

5-机器学习启蒙-  商品推荐系统1

mark

将用户的特征集,他的购买历史,可能推荐给他的商品集,其他信息。

优点:

  • 个性化;考虑到用户信息和购买历史
  • 特征可以抓住具体场景
    什么时间? 我看到了什么?

很可能白天买课本,晚上买家具。

  • 甚至在用户数据记录很少的情况下; 处理有限的历史记录。

用户的年龄。购买记录不多,但是可以推荐年龄段适用的。

分类方法的限制

  • 特征可能非常多,或者不全。特征或许不可用。会有很多缺失信息。
  • 商品信息的缺失和写的很烂的产品说明书。
  • 常常效果不如协同过滤

解决方案2:协同过滤

协同过滤技术为用户做推荐的依据是其他所有人的历史购物记录和产品推荐的实例,
还有用户和商品的一般化的关联关系。

如果有人买过这件商品,并且这个群体中的大部分又买了其他商品。

那么我们非常有必要将这些过去经常被一起购买的商品一起推荐给此时购买这件商品的用户。当然可能这些物品不一定是同时买的,但只要是在历史购物记录里就可以
考虑。

同现购买的概念:

  • 买尿布的人同样买婴儿湿巾

同现矩阵记录哪些商品是被相同的用户购买的。用户不一定是同时购买的这些商品。
可能是一段时间内依次购买的。

构建一个行列都是物品的矩阵C

5-机器学习启蒙-  商品推荐系统1

mark

矩阵的所有行对应不同的物品。所有列也对应着不同的物品。

如上图我们假定矩阵第三行和第三列都对应着尿布。

矩阵C:

存储了通过购买商品i 和 j的用户数

  • (物品,物品) 矩阵。

如何描述很多人会同时买尿布和婴儿湿巾呢?

首先找到尿布对应的行,找到婴儿湿巾对应的列。这样就可以定位到
该点上的一个值: 这个值是同时购买尿布和婴儿湿巾的用户数。

  • 对称性: 同时购买物品i和j的用户个数等于同时买商品j和i用户个数。

这个矩阵是一个对称矩阵,关于对角线对称。

将所有值填充之后,就是同现矩阵了。

每当有一笔含有尿布的购买交易记录。我们就将跟他同时购买的物品,对应的列值加1.

这样将所有用户的购买记录扫一遍。最终构建出同现矩阵。

应用同现矩阵做推荐

简单粗暴

用户a买了尿布

  1. 找到矩阵中的尿布行
5-机器学习启蒙-  商品推荐系统1

mark

这个行的值表示人们买了多少次尿布。其中一项值表示有多少次买了尿布的同时还买了这一列的商品。

5-机器学习启蒙-  商品推荐系统1

mark

每一个值都代表着买了尿布的人同时购买了其他商品的次数。

  1. 把最大计数的商品作为推荐。

同现矩阵必须被正规化

如果有一种需求量非常大的商品,也就是非常流行的商品会怎么样?

  • 流行的婴儿商品: 尿布

另一种很流行的婴儿玩具: 长颈鹿咀嚼器。

  • 对于每个婴儿商品(比如: i= 长颈鹿咀嚼器)
5-机器学习启蒙-  商品推荐系统1

mark

我要对于现在在购买长颈鹿咀嚼器的人做出推荐: 拿出长颈鹿咀嚼器的所在行。

矩阵中对于 j=尿布的第i,j个元素都很大。

因此不管我买什么商品。它第一个都会推荐销量高的尿布。

结果: 淹没了其他的影响

推荐更加个性化。

克服流行商品推荐力度过强的问题。我们需要回到基于流行度做推荐的这个基本问题。

而不同的推荐系统的流行度都有不同的定义,计算,算法等。

正规化同现矩阵: 相似度矩阵

Jaccard相似度: 把流行度正规化

我们遇到的同现矩阵正规化问题非常像我们之前聚类和相似度部分讲过的问题。

我们在讲tf-idf的时候,曾讲过字频很高的词的作用力会盖过我们可能关心的其他词。

所以我们采用了tf-idf的方法来正规化表示文档的原词统计。

类似方法用来处理流行商品的作用力过强问题。

  • 同时买商品i和j的人的数量除以 买商品i或j的人数量。

它的值能在之前的同现矩阵中找到,就是i行j列交叉点。

简单的文氏图来表示

5-机器学习启蒙-  商品推荐系统1

mark

i和j共同区域作为分子,整个区域作为分母。

  • 还有很多其他的相似度度量: 余弦相似度。

局限

仅仅关心当前的行为,不关心历史的行为。

  • 对于你现在买的商品做推荐。

不考虑我整体购物历史对我的影响。

如果你买了很多商品怎么办?

  • 需要基于购买历史的推荐

购买商品的加权平均

给每次推荐的商品打的分加上一个权重系数。对于我购物历史的所有商品都加上这个系数。

用户: 购买了商品(尿布,牛奶)

  • 对于每个商品j,通过组合相似度计算针对于用户的得分。
5-机器学习启蒙-  商品推荐系统1

mark

从对这两个商品做平均来看我有多大可能买婴儿湿巾。当然也可以将1/2根据具体情况作出具体的调整。

  • 可以对于最近更近的购买赋予更大的权重。
5-机器学习启蒙-  商品推荐系统1

mark

只需要对加权分排序,并推荐分数最高的商品。

局限

没有利用到;

- 上下文 (比如时间) - 用户特征(比如年龄) - 商品特征(比如婴儿用品,或电子产品) 

冷启动问题:

- 如果来了一个新用户或上了一个新产品时会怎么样? 

我们没有这个商品的历史购买记录,不知道它跟其他商品同时购买的次数。
因为它从来没有出现过。同样我们也没有新用户的历史购买记录数据。

解决方案3: 通过矩阵分解来发现隐藏的结构

并没有从我作为一名用户的特征方面或者产品特征作为驱动生成。反而我们是对购买量和购买历史进行简单的同现计算。

能否利用某种方法关于我是谁?以及产品是什么的信息,来驱动推荐的生成。

就像我们在分类方法中所讨论的,我们有一些用户和产品特征的集合。但是在这里我们想去从数据中学习这些特征。

这就要考虑我们刚讨论的这些特征有可能不可获得的问题。我们还想考虑用户和商品间的同现作用。

电影推荐应用:

用户看电影,对他们评分。

5-机器学习启蒙-  商品推荐系统1

mark

绿色用户看了三部影片,分别给了三星,五星,两星的评价。

每个用户仅看了全部电影中的几部而已

将我们的数据表格转换成一个对用户电影评价的矩阵。

矩阵补全问题。

矩阵之所以巨大,是因为它通常包含大量的用户和大量的电影。
但是同时这个矩阵也是非常稀疏的,虽然有许多的电影但是用户不可能把每一部都看了。

每个用户其实只看过一小部分电影。

5-机器学习启蒙-  商品推荐系统1

mark

用户对电影的矩阵。

某一行用户u 对于某一列电影v。交点就是用户对于电影的评价rating值。

黑色方块的数量比较少,但是有很多空白方块。因此每一个空白块代表某一个用户并没有看过某部电影。或者至少该用户没有提供对于该电影的评价。

所有的空白方块都代表未知的评价,但是他们不代表0分评价(只是表示我们并不清楚)。

5-机器学习启蒙-  商品推荐系统1

mark

  • 对于黑色格子,Rating(u,v)已知
  • 对于白色格子,Rating(u,v)未知

目标; 补全缺失的数据

5-机器学习启蒙-  商品推荐系统1

mark

充分利用用户提供的所有的评价。以及与该用户相关的所有的黑色的方块。
通过一行中用户对黑色方块的评价,来预测对于白色方块的值。

对于所有的空白问号。我们都会填入用户的评价。

这样我们使用用户的评价记录,以及其他所有用户的历史评价记录。补全用户尚未看过电影的评价。

填写所有的白色方块。不仅利用这一行用户的值,而是会利用所有用户的评价。

矩阵补全问题: 这个矩阵补全的问题有点难,这是一个比较难解决的问题。

因为这个矩阵真的是非常的稀疏

假设对于每个用户和影片具有d个主题

如何给出一个人对于从未看过的电影会有怎样的评价。

我们拥有每部电影和每个用户的特征集合。

举个例子: 肖申克的救赎这部电影:

使用一个向量来表示它包含每种类型的信息。

5-机器学习启蒙-  商品推荐系统1

mark

5-机器学习启蒙-  商品推荐系统1

mark

可以知道这部电影是有关于哪些类型的。

  • 他对动作片,爱情片,戏剧篇等的喜爱程度是多少?
5-机器学习启蒙-  商品推荐系统1

mark

可以看出此用户很喜欢动作片,不喜欢爱情片,有点喜欢戏剧片。

向量一是电影的类型向量Rv ,用户的偏好向量是Lu.

掌握了这些信息之后如何去预测一个评价呢?

将上面提到的两个向量进行比较;

看他们的相符程度。加入他们有许多一致的地方,那么我们可以推测这个人会对这部电影做出很高的评价。假如他们有很多地方都不一致,那么我们可以猜测这个用户将不会喜欢这部电影。

5-机器学习启蒙-  商品推荐系统1

mark

帽子是指用户u对于他从未看过的电影v的评价。

使用一个我们在度量两个文档相似度从差不多的方法。

首先定义两个向量: 在以前文档的例子中。每个向量是关于文档所属的不同类型的表示。
但是在这里,则代表某一电影的不同类型。

然后我们可以得到向量的具体值:0.3 0.01 1.5,然后进行乘法运算对于这个向量元素逐个进行相乘。

5-机器学习启蒙-  商品推荐系统1

mark

但是假如这个用户向量真的和电影向量很不一致。

5-机器学习启蒙-  商品推荐系统1

mark

分数会十分的低

5-机器学习启蒙-  商品推荐系统1

mark

注意的是:

很一致时将要会比不一致时数字大很多。

这就表明: 相比于他们并不一致的情况。推测结果是一个分数更高的评价。

我们给出推荐时,可以将所有被预测过的电影进行排序,然后推荐评价最高的。

推荐时: 对于用户没有看过的电影是根据下图式子来排序的。

5-机器学习启蒙-  商品推荐系统1

mark

评价范围是在1-5或0-5之间的。假如你真的很讨厌一部电影0分,但是你再喜欢这部电影,最大值就是5了。

预测值是7.2 是明显大于5的,对于目前我们的预测来说,我们没有一个强制的约束

但是在我们目前的需求中仍然可用,因为我们只关注最大分数的电影。虽然这个分数不会和他能获得的星级相匹配。

利用矩阵形式预测

不再讨论如何将用户和电影以某种方式结合起来,而是探讨如何做出推测。
基于我们补全后的完整用户数据。

5-机器学习启蒙-  商品推荐系统1

mark

帽子Rating u,v = <lu rv>

5-机器学习启蒙-  商品推荐系统1

mark

lu是用户对于电影类型的喜欢程度

rv是电影包含的不同类型或主题的索引

矩阵乘法运算,对应项相乘得到结果。

得到一个完整的矩阵,所有的用户被以行表示,所有的电影被以列表示

对应一个点就是用户对该电影的评分。

通过矩阵分解发现隐藏结构

假设是在知道所有的lu基础上的。

同样的,我们也知道所有电影的主题因子。就是我们的R矩阵。

得到每个用户和每个影片对应评价的大矩阵。

事实上我们并不知道用户的喜好和影片的主题

矩阵分解模型: 从数据发现主题

5-机器学习启蒙-  商品推荐系统1

mark

基于观测到的评价的基础上为每个用户的每个电影,估计这些主题(特征)向量。

模型参数。对于已知模型的模型参数,如何从已知数据中有效的估计这些参数。

数据: 我们观测到的评价,图中黑色的部分

参数: 这些用户和电影的主题因子

将从观察到的评价估计每一个参数。

回归模块中讨论了残差平方和,我们在回归模型中讨论了屋子,它有一系列的特征,特征对应的有权重,那些权重就是我们的参数,这样我们就能预测一些屋子的销售价格
将预测的销售价格和实际价格进行比较,就能得到它们差的平方,将这些屋子每个对应的残差相加,就能构成我们的残差平方和。

5-机器学习启蒙-  商品推荐系统1

mark

<lu rv>按对应位置进行相乘求和,即某一个点对应的预测值。

现在评估L 和 R 就跟我们在住宅问题中的评估回归系数的权重一样

这个例子中检索了所有用户主题向量,所有电影主题向量。找到一个最适合的组合。

推理方式: 矩阵因子分解模型

把矩阵通过因式分解的形式来逼近它自身。

最初是一个包含被评估参数的集合、

有很多高效的矩阵分解算法。如何去填充白色的格子呢?

只利用观测到的值来估计主题Lu和Rv
利用估计的Lu和Rv来做推荐

矩阵分解的局限

  • 冷启动问题

模型依然不能处理新用户和新电影的问题

5-机器学习启蒙-  商品推荐系统1

mark

特征+矩阵分解

在基于特征的问题中:

我们解决十分有限的用户数据问题

矩阵分解中:

我们可以捕捉到用户和商品之间的关系,学习用户和商品的特征

结合特征发现主题

  • 特征抓住了上下文: 时间,看到的东西,用户信息,历史购买
  • 通过矩阵分解发现的主题抓住了行为相似的一组用户:
    • 女人,来自西雅图,老师,有个孩子

结合特征解决冷启动问题
– 仅仅通过特征(年龄,性别等)来估计新用户的评分
– 当发现更多的信息后,就可以用矩阵分解的方法来发现主题

结合用户有多少数据来切换或改变权重比例

混合模型

  • 通过混合模型增加精度
5-机器学习启蒙-  商品推荐系统1

mark

Netfix prize 2006-2009

是对于netfix 用户提供最准确的打分预测

  • 100M条评分
  • 17770个电影
  • 480189个用户

目的是对于300万影评做出最高准确度的预测

奖金: 150万美元

  • 获胜的队伍组合了多于100个模型

可以超越任何单一模型的性能

推荐系统的性能度量

假设我们想要向一位新家长推荐产品。婴儿用品的世界

5-机器学习启蒙-  商品推荐系统1

mark

上图是我们可能会推荐的产品系列

一位使用者喜欢其中的一些产品。

5-机器学习启蒙-  商品推荐系统1

mark

目标是从他们的购买中发现用户喜欢的产品

为什么不使用分类准确率

分类准确率 = 正确分类的物品比例

(喜欢的 vs 不喜欢的)

将我们推测的(喜欢的 vs 不喜欢的) 与 用户实际喜欢的,不喜欢的进行比较。

  • 在这里,对用户不喜欢的东西我们不感兴趣

  • 但是我们如何快速捕捉相对老说很少用户喜欢的物品

    • 特别是在非平衡数据分类问题中

有很多很多的产品,通常来说,使用者只会喜欢其中的一小部分。

我们可以通过直接说使用者不会喜欢任何一件产品,就可以得到较高的分类准确率
不推荐任何东西可以得到很好的准确率表现

假设使用者的关注时间有限,我们可以给使用者推荐将会看到的某一部分物品

如果用户不喜欢这件物品。选出一小部分给这个人。

如果我们的推荐物品中: 漏掉了使用者喜欢的物品,成本则会更高。

我们讨论一种或多种的度量标准。准确率或称之为( 召回率)

多少喜欢的物品被推荐了?(召回率)

5-机器学习启蒙-  商品推荐系统1

mark

5-机器学习启蒙-  商品推荐系统1

mark

彩色是被推荐的商品,灰色的是没有被推荐的商品

5-机器学习启蒙-  商品推荐系统1

mark

我要关心的是有多少件确实我喜欢的物品被推荐给我了。

五件我喜欢的商品中有三个被推荐了我。召回率3/5

只在红色方框的条件下(我们实际喜欢的物品)条件下进行度量

其他商品可以消失不存在。

推荐的物品中有哪些是用户喜欢的?(准确率)

我们关注所有被推荐的物品,其他物品可以消失掉

被推荐的物品用绿色来强调。

5-机器学习启蒙-  商品推荐系统1

mark

5-机器学习启蒙-  商品推荐系统1

mark

被推荐的物品中有多大部分是我喜欢的。

3/11

准确率: 与我喜欢的物品数量相比,我需要看多少无用的商品。

这是一种在关注范围有限下的测度。关注我会浪费多少精力在我并不喜欢的产品上

最优推荐

  • 最大化召回率: 推荐所有商品
5-机器学习启蒙-  商品推荐系统1

mark

推荐所有的物品。这样召回率就会变为1,因为所有我喜欢的物品都被推荐给我了

结果准确率

如果你有很多很多的产品,而我只喜欢其中很小的一部分。

5-机器学习启蒙-  商品推荐系统1

mark

这时如果你把所有东西都推荐给我,我会得到很小的准确率。

这个准确率会很小,而且非常小。

最优推荐

5-机器学习启蒙-  商品推荐系统1

mark

推荐的所有产品都是我喜欢的,并且只有我喜欢的。
这时候我不喜欢的东西都不会出现在推荐中

准确率-召回率曲线

输入: 一个特定的推荐系统
输出: 特定于算法的准确率-召回率曲线

我们会讲这些曲线代表着什么,以及在特定的推荐系统中这些曲线代表着。

为了画出曲线,需要变化推荐物品数的阈值。
– 对于每一种设置,计算准确率和召回率

在最优推荐的时候曲线长什么样呢?

5-机器学习启蒙-  商品推荐系统1

mark

最优的理想曲线是这条直线。

真实的推荐系统:

我们推荐的第一个产品可能不是我喜欢的,也可能是我喜欢的。
所以曲线要从准确率轴上的某处开始。在阈值足够大的某个点,系统能够推荐给我喜欢的产品。所以准确率和召回率都在增加。然后可能会发生增加了我不喜欢产品的情况。

我的召回率保持不变,没有覆盖到更多我感兴趣的物品,但是我的准确率降低了
因为我在关注更广的世界(比如我以前只关注婴儿分区,现在我又关注了男装)

得到锯齿状的曲线。

哪一个算法最好?

对于给定的准确率,希望召回率越高越好(反之亦然)

不同的点再做不同的事情。

5-机器学习启蒙-  商品推荐系统1

mark

我们有不同的曲线,每个曲线代表着不同的算法,如何比较这些算法并选择最好的一个

单一的度量标准: 最大的曲线下面积(AUC)

它的下方面积越大,就越贴近我们理想的水平直线

在网页上给用户展示你的商品,你知道给用户推荐商品的范围,比如20项。

这些案例中,你明确的知道你会推荐多少商品。

你关心的只是这个商品推荐数量下你的准确率是多少?

  • 另一种方法: 设置理想的召回率,然后最大化准确率(在k处的准确率)

推荐系统总结

我们讨论了协同过滤的基本概念和一系列的推荐系统

他们能够让我们通过人们的购买记录来进行产品推荐。

我们研究了在一些消费者和产品中,在产品推荐系统的背景下,如何
理解他们的直接关系。回想下我们的电影推荐系统。

机器学习的工作流程

5-机器学习启蒙-  商品推荐系统1

mark

训练数据是我们的客户,产品评分这个表格。

  • 我们所要做的事就是抽出一些特征,产品id 用户id
  • 目标是用户对于这些产品会做出的相应评分

用户id 对 产品 id 的评分就是我们的目标,也就是我们的预测评分y帽子

我们的模型是: 矩阵分解模型

矩阵分解模型有许多参数,w帽子是表达预测参数的一个符号。

具体的参数是: 每个用户的特征,每个产品的特征。

考虑到别的特征,用户年龄,用户性别,产品描述等也可能考虑对这些特征增加权重

w0帽子,也会变成这个特征集的参数。

但是预期目标是,我们会根据我们的评分看看模型是否能真的很好的拟合数据。

采用实际的数据(实际的评分),这些都是我们训练数据集中已经有的。与预测的评分做比较。

所以我们之前提到过的一种能够衡量预测评分和实际评分之间误差的方法。

就是残差平方和,就像在回归中的一样。

当然在这里还有一些别的衡量方法,但是重点是我们能找到一些能衡量预测值与真实值之间误差的手段来完成我们的机器学习算法。

具体的算法是什么呢?

不断的重复更新我们的用户和产品的特征,直到得到一个良好的预测,直到预测值和真实值没有太大的误差

我们学到了

  • 描述推荐系统的目标
  • 提供使用推荐系统的应用的例子
  • 实现基于同现矩阵的推荐系统

描述矩阵分解模型的输入(观测,主题的数量) 和 输出(主题向量,预测值)

  • 通过估计主题向量来预测
  • 描述冷启动问题,介绍解决它的办法(应用特征)
  • 通过准确率和召回率来分析各种推荐系统的性能
  • 通过AUC 和 k处准确率从很多算法中做选择

节日购物系统,音乐推荐系统。

推荐系统实践

见jupyter notebook

如何在Elasticsearch里面使用索引别名

$
0
0


在elasticsearch里面给index起一个aliases(别名)能非常优雅的解决两个索引无缝切换的问题,这个功能在某些场景下非常使用。

比如电商的核心商品索引库,除了实时增量数据外,每天都要重建一遍索引,避免index里面的数据和db里面的数据不一致,因为index分shard了,所以要一个一个的shard做全量替换,直到所有的shard替换完毕,才能宣布重建成功。整个过程其实还是风险挺大的,虽然每次只替换一个shard把风险量降到最低,但如果第3个或第4个shard重建有问题,有可能要回滚整个索引,这个问题其实用索引别名的问题就能比较优雅的解决。

旧索引称为a,新索引称为b,他们拥有共同的别名c,而dao层查询的索引名也是c,当新的全量索引b重建完成之后,只需要解除旧索引a与别名c关系,然后添加新索引b与别名c的关系,就能完成无缝切换,中间对用户是无感知的,如果b有问题,那么随时都可以重新解除b的关系并恢复a,这就完成了所谓的回滚操作,非常简单优雅。


在es里面index aliases就像是软连接一样,它可以映射一个或多个索引,提供了非常灵活的特性,使用它我们可以做到:

(1)在一个运行中的es集群中无缝的切换一个索引到另一个索引上

(2)分组多个索引,比如按月创建的索引,我们可以通过别名构造出一个最近3个月的索引

(3)查询一个索引里面的部分数据构成一个类似数据库的视图(views)



es里面操作索引别名的有两个api命令:

````
_alias 执行单个别名操作

_aliases 原子的执行多个别名操作

````


如何使用?

假设我们有两个索引分别是my_index_v1和my_index_v2现在想通过索引别名来实现无缝切换,他们对外的索引别名叫my_index。

首先我们先创建第一个old index并给你添加aliases
````
PUT /my_index_v1   //构建索引

PUT /my_index_v1/_alias/my_index   //给索引添加别名
````


创建完成之后,我们可以查询一下他们的关系:

````
GET /*/_alias/my_index  //查某个别名映射的所有index


GET /my_index_v1/_alias/* //查询某个index拥有的别名
````



返回结果如下:

````
{"my_index_v1" : {"aliases" : {"my_index" : { }
        }
    }
}
````



现在我们构建new index:
````
PUT /my_index_v2   //构建索引
````


新索引构建完毕之后,我们就可以执行切换操作命令了:

````
POST /_aliases
{"actions": [
        { "remove": { "index": "my_index_v1", "alias": "my_index" }},
        { "add":    { "index": "my_index_v2", "alias": "my_index" }}
    ]
}
````


上面的操作是顺序的执行的,先接触old index的别名,然后给new index 添加新的别名,这样以来
索引就透明的别切换了,用户不会感觉任何变化,而且也不需要停机操作。


下面看下java api里面如何操作:


(1)添加别名
````
  client.admin().indices().prepareAliases().addAlias("my_index_v1","my_index");
````


(2)移除别名
````
        client.admin().indices().prepareAliases().removeAlias("my_index_v1","my_index");
````


(3)删除一个别名后再添加一个
````
client.admin().indices().prepareAliases().removeAlias("my_index_v1","my_index")
                .addAlias("my_index_v2","my_index").execute().actionGet();
````



当别名添加完毕后,我们在删除,搜索,更新都可以直接使用:

````
 SearchRequestBuilder search=client.prepareSearch("my_index");
````


有一点需要注意使用别名后,type类型的值不需要在填写,如果你填写了es是会抛异常的,因为它认为你这别名是一个新的索引,所以我们只写index name即可,es服务端知道它的类型。


总结:

本文介绍了es里面别名的功能和作用并讲解了如何使用别名,如果我们的索引不确定未来如何使用时,给索引加一个别名是一个不错的选择。



有什么问题可以扫码关注微信公众号:我是攻城师(woshigcs),在后台留言咨询。 技术债不能欠,健康债更不能欠, 求道之路,与君同行。



已有 0人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



快讯:Google 正式推出移动优先索引( Mobile-First Indexing)

$
0
0

Mobile-First Indexing

通过一年半时间的测试,Google 今天在 Webmaster Central BlogTwitter宣布,正式推出 Mobile-First Indexing。
该策略将对 Google SEO 产生影响非常大,本人第一时间整理资料,整理了相关的几个要点。

为什么要推出 Mobile-First Indexing

众所周知,Google 的抓取、索引和排名系统都是基于 PC 端网页建立,移动端的排名和权重主要继承自 PC 端。
那在 WAP 流量远超 PC 的今天,这种机制就会出现各种各样的问题。

  • 很多网站的 PC 端页面展示所有内容,而WAP 只展示部分内容。
    • 举个极端的例子,移动端用户通过搜索达到某页面,发现并没有对应的内容(这个内容只在 PC 呈现,在 WAP 不呈现)
  • 很多网站重点优化 PC 站,而 WAP 站功能缺失体验严重落后,移动搜索用户体验极差
    • 我目前的项目就有这个问题
  • 因为移动端用户较多,部分网站重点建设 WAP 站,而忽视了 PC 站的建设,导致无法获取到该有的排名和流量
    • 这种情况比较少

根据目前流量趋势,Google 急需调整策略,保证 PC 和 WAP 端的搜索体验。

什么是 Mobile-First Indexing

Mobile-First Indexing, 就是 Google 会使用移动端页面的内容来建立索引和排名,以提升移动搜索体验。简单来说,

  • 之前,Google 是拿 PC 站的内容来建立索引,判断链接关系,决定最终排名
  • 现在,Google 开始拿 WAP 的内容

有几点要注意的:

  1. Google 只有一套索引,并不存在单独的一套 Mobile-First Index,所以,Mobile-First Indexing 只是替换掉之前的 PC 站索引。
  2. Mobile-First Indexing 的比例会逐步增加,而不是一下子全切

针对 Mobile-First Indexing 我需要做什么

Google 会在 Search Console 中分批通知站长,进行 Mobile-First Indexing 的改造。

要针对 Mobile-First Indexing 做改造

以下是目前几种网站类型以及对应的改造方式。
 Mobile-First Indexing 改造方式

单独的网址和动态提供内容的网站 具体做什么

  • WAP 页面的内容,需要跟 PC 页面保持一致。
  • 结构化数据在 PC 和 WAP 端都要添加。
  • Meta 数据在 PC 和 WAP 端都要添加。

对于单独网址的网站,还有几点建议:

  • WAP 和 PC 站都在 Search Console 进行验证
  • 确保 PC 和 WAP 页面有 hreflang 标签,并且指向对应版本
  • 确保 WAP 站服务器能承受足够的抓取压力
  • 确认 robots.txt 规则是否正确
  • 确保 PC 和 WAP 页的 rel=canonicalrel=alternate无误

我在移动端还可以做什么

虽然 Google 没有承认 Mobile-First Indexing 会提升网页排名,不过有 2 个因素 Google 已经承认是对排名有明显帮助。

  1. 移动友好性
  2. 网页加载速度

其他问题

问题1:Mobile-First Indexing 就是基于 WAP 站来决定排名?

答:
Mobile-First Indexing 主要是优先从移动页面获取内容和链接,以此建立索引。
Mobile-First Indexing 更偏向页面中的内容和链接,不过多多少少也会对排名产生影响,但不是 Mobile-First Indexing 的最重要的部分。

问题2:Mobile-First Indexing 会有排名上的优势吗?

答:
采用 Mobile-First Indexing 的页面,并没有在排名上有优势。
至少目前 Google 的文档中是这么说,具体表现还需要线上验证。

相关文档

  • Google Webmaster Central Blog 发布的《Rolling out mobile-first indexing》 https://webmasters.googleblog.com/2018/03/rolling-out-mobile-first-indexing.html
  • Google Search 官推发布的内容 https://twitter.com/searchliaison/status/978338963411750912
  • Mobile-First Indexing 的改造文档 https://developers.google.com/search/mobile-sites/mobile-first-indexing#best-practices
  • Mobile-First Indexing 2016 11月刚推出测试的官方文章 https://webmasters.googleblog.com/2016/11/mobile-first-indexing.html
  • 移动友好型检测工具https://developers.google.com/search/mobile-sites/?utm_source=search_console&utm_campaign=sc-mft-test
  • PageSpeed Insights 工具 https://developers.google.com/speed/pagespeed/insights/

linux 静默安装 oracle 11 - 简书

$
0
0

linux 静默安装 oracle 11

linux 版本

[root@oracle ~]# cat /etc/issue
CentOS release 6.5 (Final)
Kernel \r on an \m

环境检查

top - 16:05:23 up  8:34,  2 users,  load average: 0.00, 0.00, 0.00
Tasks: 152 total,   1 running, 151 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   1906556k total,  1094320k used,   812236k free,    58280k buffers
Swap:  2097144k total,        0k used,  2097144k free,   839620k cached

   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                      
  1654 oracle    -2   0 1185m  14m  13m S  0.7  0.8   1:52.05 oracle                                                                                                       
  1799 oracle    20   0 1190m  49m  44m S  0.3  2.7   0:05.11 oracle                                                                                                       
 16699 root      20   0 15036 1268  948 R  0.3  0.1   0:00.02 top                                                                                                          
     1 root      20   0 19364 1540 1228 S  0.0  0.1   0:02.77 init                                                                                                         
     2 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kthreadd                                                                                                     
     3 root      RT   0     0    0    0 S  0.0  0.0   0:00.30 migration/0                                                                                                  
     4 root      20   0     0    0    0 S  0.0  0.0   0:00.11 ksoftirqd/0                                                                                                  
     5 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/0                                                                                                  
     6 root      RT   0     0    0    0 S  0.0  0.0   0:00.05 watchdog/0                                                                                                   
     7 root      RT   0     0    0    0 S  0.0  0.0   0:00.01 migration/1                                                                                                  
     8 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/1                                                                                                  
     9 root      20   0     0    0    0 S  0.0  0.0   0:00.11 ksoftirqd/1                                                                                                  
    10 root      RT   0     0    0    0 S  0.0  0.0   0:00.05 watchdog/1                                                                                                   
    11 root      RT   0     0    0    0 S  0.0  0.0   0:00.25 migration/2
df -h

检查 swap分区、内存、磁盘大小

官方下载

官方文档


安装 jdk

下载 jdk-8u73-linux-x64.rpm

jdk 下载

安装

rpm -ivh jdk-8u91-linux-x64.rpm

配置环境变量

vi /etc/profile

export JAVA_HOME=/usr/java/jdk1.8.0_91

export CLASSPATH=.:$JAVA_HOME/jre/lib/rt.jar:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar

export PATH=$PATH:$JAVA_HOME/bin

测试

source /etc/profile
java -version

使用 root 用户配置环境变量

关闭 selinux

selinux 配置文件

[root@oracle ~]# cat /etc/sysconfig/selinux

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=disabled
# SELINUXTYPE= can take one of these two values:
#     targeted - Targeted processes are protected,
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted

临时关闭

setenforce 0

永久关闭

vim /etc/selinux/config
SELINUX=disabled

关闭防火墙

service iptables stop
systemctl stop firewalld
systemctl disable firewalld

修改主机名

hostname centos

在/etc/hosts文件中添加主机名

[root@centos ~]# vi /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.8.200   centos

ORA-00130: invalid listener address
添加与主机名与IP对应记录,不然在安装数据库时会报错

安装依赖包

yum install gcc
yum install gcc-c++
yum install libaio-devel
yum install compat-gcc-34
yum install compat-gcc-34-c++

建立用户和组

groupadd oinstall
groupadd dba
groupadd oper
useradd -g oinstall -G dba,oper oracle
echo "oracle" | passwd --stdin oracle
id oracle
[root@oracle ~]# id oracle
uid=500(oracle) gid=500(oinstall) groups=500(oinstall),501(dba),502(oper)

建立安装目录、设置文件权限

mkdir -p /u01/app/oracle /product/11.2.0/db_1
mkdir /u01/app/oracle/oradata
mkdir /u01/app/oracle/oraInventory
mkdir /u01/app/oracle/fast_recovery_area
chown -R oracle:oinstall /u01/app
chmod -R 775 /u01/app

修改参数

内核参数

vim /etc/sysctl.conf

fs.aio-max-nr = 1048576

fs.file-max = 6815744

kernel.shmall = 2097152

kernel.shmmax = 1073741824

kernel.shmmni = 4096

kernel.sem = 250 32000 100 128

net.ipv4.ip_local_port_range = 9000 65500

net.core.rmem_default = 262144

net.core.rmem_max = 4194304

net.core.wmem_default = 262144

net.core.wmem_max = 1048576

改好后,使之生效

sysctl -p

注:kernel.shmmax = 1073741824(byte)为本机物理内存的一半

修改系统资源限制

vim /etc/security/limits.conf

oracle soft nproc 2047

oracle hard nproc 16384

oracle soft nofile 1024

oracle hard nofile 65536

oracle soft stack 10240

修改用户验证选项

vim /etc/pam.d/login

session required /lib/security/pam_limits.so

session required pam_limits.so

修改用户配置文件

vim /etc/profile

if [ $USER = "oracle" ]; then

if [ $SHELL = "/bin/ksh" ]; then

ulimit -p 16384

ulimit -n 65536

else

ulimit -u 16384 -n 65536

fi

fi

修改 oracle 用户环境变量

vim ~oracle/.bash_profile

ORACLE_BASE=/u01/app/oracle

ORACLE_HOME=$ORACLE_BASE/product/11.2.0/db_1

ORACLE_SID=orcl

PATH=$ORACLE_HOME/bin:$PATH

export ORACLE_BASE ORACLE_HOME ORACLE_SID PATH


准备安装文件

上传安装包到 /tmp 目录下解压修改应答文件进行静默安装

oracle 安装文件名

linux.x64_11gR2_database_1of2.zip

linux.x64_11gR2_database_2of2.zip

修改权限

chown -R oracle:oinstall ./linux.x64_11gR2_database_1of2.zip
chown -R oracle:oinstall ./linux.x64_11gR2_database_2of2.zip

切换 oracle 用户、使修改的环境变量生效

su - oracle
source .bash_profile

解压安装包、复制应答文件到 oracle 用户的目录下

cd /tmp
unziap ./linux.x64_11gR2_database_1of2.zip
unziap ./linux.x64_11gR2_database_2of2.zip
cp -R /tmp/database/response/ /home/oracle/
cd /home/oracle/response/

应答文件

db_install.rsp:安装应答

dbca.rsp:创建数据库应答

netca.rsp:建立监听、本地服务名等网络设置的应答

Oracle 11g 静默安装-db_install.rsp详解

修改应答文件

vim ./db_install.rsp
oracle.install.option=INSTALL_DB_SWONLY
ORACLE_HOSTNAME= localhost.localdomain
UNIX_GROUP_NAME=oinstall
INVENTORY_LOCATION=/u01/app/oraInventory
SELECTED_LANGUAGES=en,zh_CN
ORACLE_HOME=/u01/app/oracle/product/11.2.0/db_1
ORACLE_BASE=/u01/app/oracle
oracle.install.db.InstallEdition=EE
oracle.install.db.DBA_GROUP=dba
oracle.install.db.OPER_GROUP=dba
DECLINE_SECURITY_UPDATES=true

部分参数含义

各参数含义如下:

-silent 表示以静默方式安装,不会有任何提示

-force 允许安装到一个非空目录

-noconfig 表示不运行配置助手netca

-responseFile 表示使用哪个响应文件,必需使用绝对路径

oracle.install.responseFileVersion 响应文件模板的版本,该参数不要更改

oracle.install.option 安装选项,本例只安装oracle软件,该参数不要更改

DECLINE_SECURITY_UPDATES 是否需要在线安全更新,设置为false,该参数不要更改

ORACLE_HOSTNAME 安装主机名

UNIX_GROUP_NAME oracle用户用于安装软件的组名

INVENTORY_LOCATION oracle产品清单目录

SELECTED_LANGUAGES oracle运行语言环境,一般包括引文和简繁体中文

ORACLE_HOME Oracle安装目录

ORACLE_BASE oracle基础目录

oracle.install.db.InstallEdition 安装版本类型,一般是企业版

oracle.install.db.isCustomInstall 是否定制安装,默认Partitioning,OLAP,RAT都选上了

oracle.install.db.customComponents 定制安装组件列表:除了以上默认的,可加上Label Security和Database Vault

oracle.install.db.DBA_GROUP oracle用户用于授予OSDBA权限的组名

oracle.install.db.OPER_GROUP oracle用户用于授予OSOPER权限的组名

静默安装

cd /tmp/database
./runInstaller -silent -responseFile /home/oracle/response/db_install.rsp -ignorePrereq

.
.
.
#Root scripts to run

/u01/app/oracle/oraInventory/orainstRoot.sh
/u01/app/oracle/product/11.2.0/db_1/root.sh
To execute the configuration scripts:
        1. Open a terminal window
        2. Log in as "root"
        3. Run the scripts
        4. Return to this window and hit "Enter" key to continue

Successfully Setup Software.

安装完毕后会提示上述的信息,按照要求使用 root 用户执行上面的两个脚本

静默配置监听程序

使用 oracle 用户

netca /silent /responsefile /home/oracle/response/netca.rsp

检验

1、在 /u01/app/oracle/product/11.2.0/db_1/network/admin/中生成 listener.orasqlnet.ora

ll /u01/app/oracle/product/11.2.0/db_1/network/admin/

2、通过netstat命令可以查看1521端口正在监听

netstat -tnul | grep 1521

静默方式建库

dbca -silent -createDatabase -templateName General_Purpose.dbc -gdbname orcl -sid orcl -responseFile NO_VALUE -characterSet ZHS16GBK -memoryPercentage 30 -emConfiguration LOCAL

.
.
.

85% complete
96% complete
100% complete
Look at the log file "/opt/app/oracle/cfgtoollogs/dbca/ora11g/ora11g.log" for further details.

数据库成功安装之后默认是启动状态

参数说明

-silent 指以静默方式执行dbca命令
-createDatabase 指使用dbca
-templateName 指定用来创建数据库的模板名称,这里指定为General_Purposedbc,即一般用途的数据库模板
-gdbname 指定创建的全局数据库名称,这里指定名称为ocp11g
-sid 指定数据库系统标识符,这里指定为ocp11g,与数据库同名
-responseFile 指定安装响应文件,NO_VALUE表示没有指定响应文件
-characterSet 指定数据库使用的字符集,这里指定为AL32UTF8
-memoryPercentage 指定用于oracle的物理内存的百分比,这里指定为30%
-emConfiguration 指定Enterprise Management的管理选项。LOCAL表示数据库由Enterprise Manager本地管理

数据库成功安装之后默认是启动状态

检验

1、进行实例进程检查

ps -ef | grep ora_ | grep -v grep

2、查看监听状态

lsnrctl status

3、登录查看实例状态

sqlplus / as sysdba

设置Linux开机自启动七、 设置Linux开机自启动

修改ORACLE_HOME_LISTNER

将下面两个文件的ORACLE_HOME_LISTNER=$1修改为ORACLE_HOME_LISTNER=$ORACLE_HOME

vim /u01/app/oracle/product/11.2.0/db_1/bin/dbstart
vim /u01/app/oracle/product/11.2.0/db_1/bin/dbshut

配置oratab

vi /etc/oratab

找到testsid:/opt/oracle/102:N,改为testsid:/opt/oracle/102:Y

配置rc.local

vi /etc/rc.d/rc.local

添加如下行

su oracle -lc "/u01/app/oracle/product/11.2.0/db_1/bin/lsnrctl start"
su oracle -lc /u01/app/oracle/product/11.2.0/db_1/bin/dbstart

增加权限

chmod +x /etc/rc.d/rc.local

开放1521端口允许网络连接

service iptables stop
vi /etc/sysconfig/iptables
# Generated by iptables-save v1.4.7 on Fri Dec 16 07:29:41 2016
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [10:892]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 1521 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT
# Completed on Fri Dec 16 07:29:41 2016

service iptables save

service iptables restart

iptables设置详细

利用iptables防火墙允许1521端口被连接

参考文档

Oracle 11g R2静默安装(推荐)

Oracle11gR2 for Linux 静默安装(推荐)

CentOS 6.5下静默安装oracle(推荐)

oracle11G静默安装过程——linux环境

Linux下Oracle11g静默安装

CentOS 6.2 X64上64位Oracle11gR2 静默安装,静默设置监听,静默建库

常用命令

lsnrctl start启动监听

lsnrctl stop关闭监听

lsnrctl status查看监听状态

sqlplus /nolog登陆 sqlplus

startup启动数据库

conn /as sysdba用 sysdba 登陆数据库

iptables -L -niptables当前规则

mkdir -p /u01/app/oracle /product/11.2.0/db_1递归创建文件夹

chown -R oracle:oinstall /u01/app修改文件或文件夹的所有者所属组

chmod -R 775 /u01/app修改文件或文件夹权限

vi /etc/sysconfig/iptables修改文本文件

ps -ef | grep ora_ | grep -v grep

netstat -tnul | grep 1521

若有不正确的地方,望大神指教!!!


8.4 静默建立新库(同时也建立一个对应的实例)

修改/etc/dbca.rsp,设置如下:

[GENERAL]

 RESPONSEFILE_VERSION = "11.2.0"      //不能更改

 OPERATION_TYPE = "createDatabase"

 GDBNAME = "orcl.test"               //全局数据库的名字=SID+主机域名

 SID= "orcl"                        //对应的实例名字

 TEMPLATENAME = "General_Purpose.dbc"    //建库用的模板文件

 SYSPASSWORD = "123456"                 //SYS管理员密码

 SYSTEMPASSWORD = "123456"              //SYSTEM管理员密码

 DATAFILEDESTINATION = /opt/oracle/oradata //数据文件存放目录

 RECOVERYAREADESTINATION=/opt/oracle/ flash_recovery_area    //恢复数据存放目录

 CHARACTERSET = "ZHS16GBK"   //字符集,重要!!! 建库后一般不能更改,所以建库前要确定清楚。(CHARACTERSET = "AL32UTF8"

NATIONALCHARACTERSET= "UTF8")

 TOTALMEMORY = "5120"    //oracle内存5120MB

 

 然后静默运行:

 $dbca -silent -responseFile etc/dbca.rsp

 复制数据库文件

 1% 已完成

 3% 已完成

 11% 已完成



Google 的无人车公司开门营业,十几美元能打超百万电动捷豹豪车

$
0
0

Google 母公司 Alphabet 旗下的无人驾驶公司 Waymo 已经在无人驾驶领域取得了类似 Google 在搜索引擎领域一样的地位:公认老大,无人能及。

这种差距有多大呢?以权威的美国加州机动车辆管理局 2018 年初公布的自动驾驶汽车“脱离”报告(autonomous vehicle disengagement Report)数据来看,即便 Waymo 由于车队驻地调整的缘故,使得其在加州 2017 全年的无人驾驶由前一年的 635868 英里锐减至 352545 英里,但即便如此,Waymo 的里程数依然是第二名通用 131676 英里的近两倍之多,且安全性还更好。

于是,当各家还在继续调整完善自己的无人驾驶方案的时候,Waymo 已经开始准备提供商业化出行服务了。

注意,这还是在 Uber 刚刚发生了无人驾驶致死事故,无人驾驶被舆论高度关注的情况下。

美国时间 3 月 26 日,Waymo 在其官方 Twitter 上发出一张活动预热图,表示其 CEO 将在纽约公布一件大事情。

今天,一切水落石出,Waymo 宣布已经确定了旗下下一款无人驾驶汽车的型号与规格:一辆自动驾驶的捷豹 I-PACE。

Waymo 在现场展示了这款车的最终定型,除了标志性的 Waymo 白色涂装之外,最引人瞩目的是遍布车身的激光雷达组件。

车顶上的主激光雷达被一个专门设计的流线型罩体所承载,位于车辆的核心位置。

前翼子板处各有一个凸起,用来探测车辆两侧周边的环境。

而车辆正前方与正后方的雷达则对于路线规划探测有着重要作用,前方雷达的位置位于车辆格栅的下部,用黑色涂装来进行隐蔽,不过车辆尾部的雷达就有点尴尬了……

像一个鸡蛋挂在尾门上似的。

按照 Waymo 自己的规划,将从今年起开始出行服务的试运行,这一过程将由其现有的克莱斯勒大捷龙 MPV 车队完成。

而在接下来的两年里,Waymo 将购买两万台捷豹 I-PACE 进行改造升级,基于 I-PACE 的自动驾驶服务将于 2020 年正式投入运营。

在发布会过程中,Waymo 向大家展示了自动驾驶对改善日常生活所能起到的巨大作用,Waymo 表示,94% 发生在美国的交通事故是由人为原因导致的,美国每人每年有 42 小时浪费在交通上(我咋感觉我每周就浪费这么多),于此同时,美国还有 300 万年龄在 40 岁之上且存在视力问题的人,他们被剥夺的享受便捷交通的权利,都可以被无人驾驶技术争取回来。

除了研究无人驾驶的基础技术外,Waymo 更为领先的是对于车内乘员的观察和交互模式,除了通过多个摄像头了解车内乘员的状态外,还可以通过车内的仪表让乘员对车辆运行状态了如指掌。

在发布会上,Waymo 播放了一段当前车辆进行载人路试的视频,无论是孩童还是老人,都能安心的在后排让车辆自动前行。

随着信任感的确立,不少人敢于低头去玩手机,甚至是轻轻地打起了瞌睡。

Waymo 表示对自己的技术非常有信心,表示没有必要为了一次交通事故的意外就对无人驾驶的前景失去信心,Waymo 将继续在乘用车和商用车两个领域加大投入,推动自动驾驶时代的到来。

几百万的电动自动驾驶豪车,让你十几美元便宜打到是不是很开心?

一边的捷豹表示,别光说 Waymo 啊,给我露个脸。

在刚刚结束的日内瓦车展上露面之后,I-PACE 一时间好评如潮,大家纷纷表示,特斯拉杀手学校终于不再像是幼儿园大班的感觉了,终于有个青年才俊能够光荣毕业了。

作为传统豪华品牌的“认真的、别闹”的电动化产品,I-PACE 在电动性能上并不逊于同价位的特斯拉产品,甚至在内饰质感和做工上还领先一筹,但被人最担心的是,很多人认为 I-PACE 只是电动车,却不是智能车。

这里的智能,自然包括软件体验,以及更重要的自动驾驶能力等。

与 Waymo 的合作,其实是整个产业的一个矛盾写照。

一方面,这个合作证明了传统车企求剑科技巨头之后,能让“杀手”们在装备等级上一跃成为整个服务器的老大,而且凭借传统车企的制造能力经验+科技巨头的技术研发积累,能够在车和智能两个维度都有所长。

另一方面,Waymo 与捷豹的合作更像是捷豹提供车辆平台基础,由 Waymo 升级后进行自己的商业服务,其中 Waymo 的技术被没有同步给捷豹,同时这种多雷达的硬件方案在现阶段也是捷豹不可能自己生产后去进行单车销售的。

所以,这是一个可行的商业模式,却不是一个目前可行的造车模式。

传统车企的智能化路径,还得慢慢求索,我们越发有趣地发现,眼前的路径出现了 Android 化 VS iOS 化的途径,既有百度 Apollo 这样的平台力求兼容适配,也有特斯拉这样全能的选手在构筑自己的软硬件城堡。

也就在几天前,特斯拉的 AutoPilot 2.0 进行了马斯克嘴中“采用了先进的神经网络技术”的重大更新,按照大量用户的反馈,在行驶平顺性上有了质的提升。

眼看着马斯克承诺的特斯拉完成从西海岸到东海岸的时间节点越来越近,很期待早早就提出要用自动驾驶进行共享用车服务的特斯拉能不能拿出可行的方案。

Your Turn, Elon.

#欢迎关注爱范儿官方微信公众号:爱范儿(微信号:ifanr),更多精彩内容第一时间为您奉上。

爱范儿 |原文链接· 查看评论· 新浪微博


关于昨晚的苹果新品发布会,这 5 件事值得你关注

$
0
0

苹果昨晚在美国芝加哥的 Lane Tech Prep High School 召开了新品发布会。本次发布会围绕教育主题,发布了支持 Apple Pencil 的新款入门级 iPad。如果你没有熬夜看发布会,少数派整理了发布会的要点,让你在 5 分钟内迅速了解昨晚苹果发布会的内容。

支持 Apple Pencil 的入门款 iPad

首先登场的是新款 9.7 英寸 iPad。跟之前传闻一样,这款新 iPad 最大的亮点是加入了对 Apple Pencil 的支持。

配置方面,新款 iPad 的主要升级是将上一代的 A9 芯片更新为 A10 Fusion 芯片。除此以外,新款 iPad 基本延续了上一代 iPad 的配置,使用同样的 9.7 英寸屏幕,重量不到 500g,支持触控 ID,拥有 800 万后置摄像头,以及高清 FaceTime 前置摄像头,续航同样为 10 小时。

遗憾的是,新款 iPad 并没有加入 iPad Pro 上的 Smart Connecter,所以无法和 Smart Keyboard 配合使用。

iPad 对比表格

新款 iPad 有银色、金色和深空灰三款配色,拥有 Wi-Fi 和 Wi-Fi + Cellular 两个版本,容量有 32GB 和 128GB 两个选择,起售价为人民币 2588 元,学校购买价为人民币 2388 元起。今天起可在 官网购买。

便宜一半的第三方触控笔

苹果宣布将和罗技合作推出新的 iPad 手写笔 Crayon,售价 49 美元,苹果并没有在发布会上公布有关这款触控笔的更多信息,也没有公布何时发售。

如果你觉得目前售价 99 美元的 Apple Pencil 有些过高,这款价格更为亲民的新触控笔或许能打动你。

支持制作电子书和批注功能的 iWork

苹果还更新了一系列服务,为在校师生提供更好的授课和学习体验。

iWork 三件套(Pages、Keynote 和 Numbers)都加入了「智能注解」功能,配合 Apple Pencil,你可以在文档或表格内轻松绘画,老师也可以利用这一功能快速批改作业,标注出需要注意的地方。

新版的 Pages 将加入图书制作功能,你可以轻松地通过 iOS 设备、Mac 或 iCloud 网页版制作有趣的电子书,软件内提供了丰富的模板供用户使用,也可以利用协作功能和朋友一起制作电子书。

用于教学的 AR 应用

发布会上展示了多款用于教学的 AR 应用,WWF(世界自然基金会)开发的  Free Rivers 通过 AR 技术把河流生态生动地呈现在你的书桌上,利用修建大坝等交互让学生可以对生态环境有很深地了解。 Froggipedia(预售中,3 月 30 日上架)则可以模拟解剖青蛙的过程,有助于学生在课堂上直观地了解生理结构。

Free Rivers Froggipedia

免费的「人人能创造」课程和「课业」应用

苹果上线了新的免费课程「人人能创造」,让教师能以轻松有趣的方式将绘画、音乐、影片制作或摄影融合至各个学科的现有课程计划之中。

课程提供一系列免费的学习资源和教学指南,帮助教师将绘画、音乐、影片制作或摄影轻松融入到各种课程和作业中。让学生以不同的方式来表达自我,帮助他们发掘和培养新的技能。

此外苹果还推出了新的「课业(HandsOut)」应用,用来帮助教师布置作业、查看学生作业进度,老师可以在应用内轻松指派特定的活动,指示学生直接前往应用内的特定位置。应用支持创建和发送网页链接、PDF 文档等多种内容类型的作业。

借助 ClassKit 框架,开发者之后可以开发更多用于教学的应用和「课业」联动,为数字化教学提供更多可能性。

此外苹果还为所有拥有管理式 Apple ID 的教师和学生提供了 200GB 的免费 iCloud 存储空间。

One More Thing…

虽然没有在发布会上提到,但苹果在发布会后悄悄在官网上线了一批新配件。

Apple Watch 推出了多款 春季配色新表带,涵盖运动、尼龙和经典扣式等多个系列。同时 Nike 和爱马仕合作款也有几款新配色。

图/Apple 官网

另外,之前在 iMac Pro 上大受好评的深空灰色键盘、鼠标和触控板也同时在官网上线,并支持单独购买。不过,这些深空灰色的配件都比原来银色款要贵 200 元左右, 妙控鼠标 2售价人民币 728 元, 带有小键盘的妙控键盘售价人民币 1198 元, 妙控板 2售价人民币 1198 元。

图/Apple 官网

(文中发布会现场图片均来自  The Verge


> 下载 少数派 iOS 客户端、关注 少数派公众号,为你带来第一手新鲜的苹果资讯


[译] HotSpot JVM 内存管理

$
0
0
HotSpot JVM 内存管理
更新时间:2018-03-28

关于 JVM 内存管理或者说垃圾收集,大家可能看过很多的文章了,笔者准备给大家总结下。这算是系列的第一篇,接下来一段时间会持续更新。

本文主要是翻译《 Memory Management in the Java HotSpot Virtual Machine》白皮书的前四章内容,这是 2006 的老文章了,当年发布这篇文章的还是 Sun Microsystems,以后应该会越来越少人记得这家曾经无比伟大的公司了。

虽然这个白皮书有点老了,不过那个时候 Sun 在 J2SE 5.0版本的 HotSpot 虚拟机上已经有了 Parallel 并行垃圾收集器和 CMS 这种并发收集器了,所以其实内容也没那么过时。

其实本文应该有挺多人都翻译过,我大体上是意译的,增、删了部分内容。

其他的知识,包括 Java5 之后的垃圾收集器,如 Java8 的 MetaSpace 取代了永久代、G1 收集器等,将在日后的文章中进行介绍。

目录

垃圾收集概念

GC 需要做 3 件事情:

  • 分配内存,为每个新建的对象分配空间
  • 确保还在使用的对象的内存一直还在,不能把有用的空间当垃圾回收了
  • 释放不再使用的对象所占用的空间

我们把还被 GC Roots引用的对象称为 活的,把不再被引用的对象认为是 死的,也就是我们说的垃圾,GC 的工作就是找到死的对象,回收它们占用的空间。

在这里,我们总结一下 GC Roots 有哪些:

  • 当前各线程执行方法中的局部变量(包括形参)引用的对象
  • 已被加载的类的 static 域引用的对象
  • 方法区中常量引用的对象
  • JNI 引用

我们把 GC 管理的内存称为 堆(heap),垃圾收集启动的时机取决于各个垃圾收集器,通常,垃圾收集发生于整个堆或堆的部分已经被使用光了,或者使用的空间达到了某个百分比阈值。

对于内存分配请求,实现的难点在于在堆中找到一块没有被使用的确定大小的内存空间。所以,对于大部分垃圾回收算法来说 避免内存碎片化是非常重要的,它将使得空间分配更加高效。

垃圾收集器的理想特征

  1. 安全和全面:活的对象一定不能被清理掉,死的对象一定不能在几个回收周期结束后还在内存中。
  2. 高效:不能将我们的应用程序挂起太长时间。我们需要在时间、空间、频次上作出权衡。比如,如果堆内存很小,每次垃圾收集就会很快,但是频次会增加。如果堆内存很大,很久才会被填满,但是每一次回收需要的时间很长。
  3. 尽量少的内存碎片:每次将垃圾对象释放以后,这些空间可能分布在各个地方,最糟糕的情况就是,内存中到处都是碎片,在给一个大对象分配空间的时候没有内存可用,实际上内存是够的。消除碎片的方式就是 压缩
  4. 可扩展性:在多核多线程应用中,内存分配和垃圾回收都不应该成为可扩展性的瓶颈。 原文提到的这一点,我的理解是:单线程垃圾回收在多核系统中会浪费 CPU 资源,如果我理解错误,请指正我。

设计上的权衡

往下看之前,我们需要先分清楚这里的两个概念:并发和并行

  • 并行:多个垃圾回收线程同时工作,而不是只有一个垃圾回收线程在工作
  • 并发:垃圾回收线程和应用程序线程同时工作,应用程序不需要挂起

在设计或选择垃圾回收算法的时候,我们需要作出以下几个权衡:

  • 串行 vs 并行

    串行收集的情况,即使是多核 CPU,也只有一个核心参与收集。使用并行收集器的话,垃圾收集的工作将分配给多个线程在不同的 CPU 上同时进行。并行可以让收集工作更快,缺点是带来的复杂性和内存碎片问题。

  • 并发 vs Stop-the-world

    当 stop-the-world 垃圾收集器工作的时候,应用将完全被挂起。与之相对的,并发收集器在大部分工作中都是并发进行的,也许会有少量的 stop-the-world。

    stop-the-world 垃圾收集器比并发收集器简单很多,因为应用挂起后 堆空间不再发生变化,它的缺点是在某些场景下挂起的时间我们是不能接受的(如 web 应用)。

    相应的,并发收集器能够降低挂起时间,但是也更加复杂,因为在收集的过程中,也会有新的垃圾产生,同时,需要有额外的空间用于在垃圾收集过程中应用程序的继续使用。

  • 压缩 vs 不压缩 vs 复制

    当垃圾收集器标记出内存中哪些是活的,哪些是垃圾对象后,收集器可以进行压缩,将所有活的对象移到一起,这样新的内存分配就可以在剩余的空间中进行了。经过压缩后,分配新对象的内存空间是非常简单快速的。

    相对的,不压缩的收集器只会就地释放空间,不会移动存活对象。优点就是快速完成垃圾收集,缺点就是潜在的碎片问题。通常,这种情况下,分配对象空间会比较慢比较复杂,比如为新的一个大对象找到合适的空间。

    还有一个选择就是复制收集器,将活的对象复制到另一块空间中,优点就是原空间被清空了,这样后续分配对象空间非常迅速,缺点就是需要进行复制操作和额外的空间。

性能指标

以下几个是评估垃圾收集器性能的一些指标:

  • 吞吐量:应用程序的执行时间占总时间的百分比,当然是越高越好
  • 垃圾收集开销:垃圾收集时间占总时间的百分比(1 - 吞吐量)
  • 停顿时间:垃圾收集过程中导致的应用程序挂起时间
  • 频次:相对于应用程序来说,垃圾收集的频次
  • 空间:垃圾收集占用的内存
  • 及时性:一个对象从成为垃圾到该对象空间再次可用的时间

在交互式程序中,通常希望是低延时的,而对于非交互式程序,总运行时间比较重要。实时应用程序既要求每次停顿时间足够短,也要求总的花费在收集的时间足够短。在小型个人计算机和嵌入式系统中,则希望占用更小的空间。

分代收集介绍

当我们使用分代垃圾收集器时,内存将被分为不同的 代(generation),最常见的就是分为 年轻代老年代

在不同的分代中,可以根据不同的特点使用不同的算法。分代垃圾收集基于 weak generational hypothesis假设(通常国人会翻译成 弱分代假设):

  • 大部分对象都是短命的,它们在年轻的时候就会死去
  • 极少老年对象对年轻对象的引用

年轻代中的收集是非常频繁的、高效的、快速的,因为年轻代空间中,通常都是小对象,同时有非常多的不再被引用的对象。

那些 经历过多次年轻代垃圾收集还存活的对象会晋升到老年代中,老年代的空间更大,而且占用空间增长比较慢。这样,老年代的垃圾收集是不频繁的,但是进行一次垃圾收集需要的时间更长。

对于新生代,需要选择速度比较快的垃圾回收算法,因为新生代的垃圾回收是频繁的。

对于老年代,需要考虑的是空间,因为老年代占用了大部分堆内存,而且针对该部分的垃圾回收算法,需要考虑到这个区域的 垃圾密度比较低

J2SE 5.0 HotSpot JVM 中的垃圾收集器

J2SE 5.0 HotSpot 虚拟机包含四种垃圾收集器,都是采用分代算法。包括 串行收集器并行收集器并行压缩收集器CMS 垃圾收集器

HotSpot 分代

在 HotSpot 虚拟机中,内存被组织成三个分代:年轻代、老年代、永久代。

大部分对象初始化的时候都是在年轻代中的。

老年代存放经过了几次年轻代垃圾收集依然还活着的对象,还有部分大对象因为比较大所以分配的时候直接在老年代分配。

-XX:PretenureSizeThreshold=1024,这样大于 1k 的对象就会直接分配在老年代,比如某对象含 byte[] arr = new byte[1024*4]这个 4k 大小的属性。

永久代,通常也叫 方法区,用于存储已加载类的元数据,以及存储运行时常量池等。

垃圾回收类型

当年轻代被填满后,会进行一次年轻代垃圾收集(也叫做 minor GC)。当老年代或永久代被填满了,会触发 full GC(也叫做 major GC),full GC 会收集所有区域,先进行年轻代的收集,将使用年轻代专用的垃圾回收算法,然后使用老年代的垃圾回收算法 回收老年代和永久代。如果算法带有压缩,每个代分别独立地进行压缩。

有时候,老年代太满了,以至于不能接受从年轻代垃圾收集算法中存活后晋升上来的对象。这种情况下,所有的收集器(除了 CMS) 采用老年代收集算法对整个堆进行收集(CMS 收集器比较特殊,因为它不能收集年轻代的垃圾)。

这段话我倒是没完全明白表达出来的意思,请知道的读者赐教!

快速分配

如果垃圾收集完成后,存在大片连续的内存可用于分配给新对象,这种情况下分配空间是非常简单快速的,只要一个简单的指针碰撞就可以了( bump-the-pointer),每次分配对象空间只要检测一下是否有足够的空间,如果有,指针往前移动 N 位就分配好空间了,然后就可以初始化这个对象了。

对于多线程应用,对象分配必须要保证线程安全性,如果使用全局锁,那么分配空间将成为瓶颈并降低程序性能。HotSpot 使用了称之为 Thread-Local Allocation Buffers (TLABs)的技术,该技术能改善多线程空间分配的吞吐量。首先,给予每个线程一部分内存作为缓存区,每个线程都在自己的缓存区中进行指针碰撞,这样就不用获取全局锁了。只有当一个线程使用完了它的 TLAB,它才需要使用同步来获取一个新的缓冲区。HotSpot 使用了多项技术来降低 TLAB 对于内存的浪费。比如,TLAB 的平均大小被限制在 Eden 区大小的 1% 之内。TLABs 和使用指针碰撞的线性分配结合,使得内存分配非常简单高效,只需要大概 10 条机器指令就可以完成。

串行收集器

使用串行收集器,年轻代和老年代都使用单线程进行收集(使用一个 CPU),收集过程中会 stop-the-world。所以当在垃圾收集的时候,应用程序是完全停止的。

在年轻代中使用串行收集器

下图展示了年轻代中使用串行收集器的流程。

3

年轻代分为 一个 Eden 区和两个 Survivor 区(From 区和 To 区)。年轻代垃圾收集时,将 Eden 中活着的对象复制到空的 Survivor-To 区,Survivor-From 区的对象分两类,一类是年轻的,也是复制到 Survivor-To 区,还有一类是老家伙,晋升到老年代中。

Survivor-From 和 Survivor-To 是我瞎取的名字。。。

如果复制的过程中,发现 Survivor-To 空间满了,将剩下还没复制到 Survivor-To 的来自于 Eden 和 Survivor-From 区的对象直接晋升到老年代。

年轻代垃圾收集完成后,Eden 区和 Survivor-From 就干净了,此时,将 Survivor-From 和 Survivor-To 交换一下角色。得到下面这个样子:

4

在老年代中使用串行收集器

如果使用串行收集器,在老年代和永久代将通过使用 标记 -> 清除 -> 压缩算法。标记阶段,收集器识别出哪些对象是活的;清除阶段将遍历一下老年代和永久代,识别出哪些是垃圾;然后执行压缩,将活的对象左移到老年代的起始端(永久代类似),这样就留下了右边一片连续可用的空间,后续就可以通过指针碰撞的方式快速分配对象空间。

5

何时应该使用串行收集器

串行收集器适用于运行在 client 模式下的大部分程序,它们不要求低延时。在现代硬件条件下,串行收集器可以高效管理 64M 堆内存,并且能将 full GC 控制在半秒内完成。

使用串行收集器

它是 J2SE 5.0 版本 HotSpot 虚拟机在非服务器级别硬件的默认选择。你也可以使用 -XX:+UseSerialGC来强制使用串行收集器。

并行收集器

现在大多数 Java 应用都运行在大内存、多核环境中, 并行收集器,也就是大家熟知的 吞吐量收集器,利用多核的优势来进行垃圾收集,而不是像串行收集器一样将程序挂起后只使用单线程来收集垃圾。

在年轻代中使用并行收集器

并行收集器在年轻代中其实就是串行收集器收集算法的并行版本。它仍然使用 stop-the-world 和复制算法,只不过使用了多核的优势并行执行,降低垃圾收集的时间,从而提高吞吐量。下图示意了在年轻代中,串行收集器和并行收集器的区别:

6

在老年代中使用并行收集器

在老年代中,并行收集器使用的是和串行收集器一样的算法: 单线程,标记 -> 清除 -> 压缩

是的,并行收集器只能在年轻代中并行

何时使用并行收集器

其适用于多核、不要求低停顿的应用,因为老年代的收集虽然不频繁,但是每次老年代的 单线程垃圾收集依然可能会需要很长时间。比如说,它可以应用在批处理、账单计算、科学计算等。

你应该不会想要这个收集器,而是要一个可以对每个代都采用并行收集的 并行压缩收集器,下一节将介绍这个。

使用并行收集器

前面我们说了,J2SE 5.0 中 client 模式自动选择使用串行收集器,如果是 server 模式,那么将自动使用并行收集器。在其他版本中,显示使用 -XX:+UseParallelGC 可以指定并行收集器。

并行压缩收集器

并行压缩收集器于 J2SE 5.0 update 6 引入,和并行收集器的区别在于它在老年代也使用并行收集算法。注意:并行压缩收集器终将会取代并行收集器。

在年轻代中使用并行压缩收集器

并行压缩收集器在年轻代中使用了和并行收集器一样的算法。即使用 并行、stop-the-world、复制算法。

在老年代中使用并行压缩收集器

在老年代和永久代中,其使用 并行、stop-the-world、滑动压缩算法。

一次收集分三个阶段,首先,将老年代或永久代逻辑上分为固定大小的区块。

  1. 标记阶段,将 GC Roots 拆分给多个垃圾收集线程,每个线程并行地去标记存活的对象,一旦标记一个存活对象,在 该对象所在的区块记录这个对象的大小和对象所在的位置。

  2. 汇总阶段,此阶段针对区块进行。由于之前的垃圾回收影响,老年代和永久代的左侧是 存活对象密集区,对这部分区域直接进行压缩的代价是不值得的,能清理出来的空间有限。所以第一件事就是,检查每个区块的密度,从左边第一个开始,直到找到一个区块满足: 对右侧的所有区块进行压缩获得的空间抵得上压缩它们的成本。这个区块左边的区域过于密集,不会有对象移动到这个区域中。然后,计算并保存右侧区域中每个区块被压缩后的新位置首字节地址。

    右侧的区域将被压缩,对于右侧的每个区块,由于每个区块中保存了该区块的存活对象信息,所以很容易计算每个区块的新位置。注意: 汇总阶段目前被实现为串行进行,这个阶段修改为并行也是可行的,不过没有在标记阶段和下面的压缩阶段并行那么重要。

  3. 压缩阶段,在汇总阶段已经完成了每个区块新位置的计算,所以压缩阶段每个回收线程 并行将每个区块复制到新位置即可。压缩结束后,就清出来了右侧一大片连续可用的空间。

何时使用并行压缩收集器

首先是多核上的并行优势,这个就不重复了。其次,前面的并行收集器对于老年代和永久代使用串行,而并行压缩收集器在这些区域使用并行,能降低停顿时间。

并行压缩收集器不适合运行在大型共享主机上(如 SunRays),因为它在收集的时候会独占几个 CPU,在这种机器上,可以考虑减少垃圾收集的线程数(通过 –XX:ParallelGCThreads=n),或者就选择其他收集器。

使用并行压缩收集器

显示指定: -XX:+UseParallelOldGC

Concurrent Mark-Sweep(CMS)收集器

重头戏 CMS 登场了,至少对于我这个 web 开发者来说,CMS 最常用。前面介绍的都是并行收集,这里要介绍并发收集了,也就是垃圾回收线程和应用程序线程同时运行。

对于许多程序来说,吞吐量不如响应时间来得重要。通常年轻代的垃圾收集不会停顿多长时间,但是,老年代垃圾回收,虽然不频繁,但是可能导致长时间的停顿,尤其当堆内存比较大的时候。为了解决这个问题,HotSpot 虚拟机提供了 CMS 收集器,也叫做 低延时收集器

在年轻代中使用 CMS 收集器

在年轻代中,CMS 和 并行收集器一样,即: 并行、stop-the-world、复制

在老年代中使用 CMS 收集器

在老年代的垃圾收集过程中,大部分收集任务是和应用程序 并发执行的。

CMS 收集过程首先是一段小停顿 stop-the-world,叫做 初始标记阶段(initial mark),用于确定 GC Roots。然后是 并发标记阶段(concurrent mark),标记 GC Roots 可达的所有存活对象,由于这个阶段应用程序同时也在运行,所以并发标记阶段结束后,并不能标记出所有的存活对象。为了解决这个问题,需要再次停顿应用程序,称为 再次标记阶段(remark),遍历在并发标记阶段应用程序修改的对象,由于这次停顿比初始标记要长得多, 所以会使用多线程并行执行来增加效率

再次标记阶段结束后,能保证所有存活对象都被标记完成,所以接下来的 并发清理阶段(concurrent sweep)将就地回收垃圾对象所占空间。下图示意了老年代中 串行、标记 -> 清理 -> 压缩收集器和 CMS 收集器的区别:

7

由于部分任务增加了收集器的工作,如遍历并发阶段应用程序修改的对象,所以增加了 CMS 收集器的负载。对于大部分试图降低停顿时间的收集器来说,这是一种权衡方案。

CMS 收集器是 唯一不进行压缩的收集器,在它释放了垃圾对象占用的空间后,它不会移动存活对象到一边去。

8

这将节省垃圾回收的时间,但是由于之后空闲空间不是连续的,所以也就不能使用简单的 指针碰撞(bump-the-pointer)进行对象空间分配了。它需要维护一个 空闲列表,将所有的空闲区域连接起来,当分配空间时,需要寻找到一个可以容纳该对象的区域。显然,它比使用简单的指针碰撞成本要高。同时它也会加大年轻代垃圾收集的负载,因为年轻代中的对象如果要晋升到老年代中,需要老年代进行空间分配。

另外一个缺点就是,CMS 收集器相比其他收集器需要使用更大的堆内存。因为在并发标记阶段,程序还需要执行,所以需要留足够的空间给应用程序。另外,虽然收集器能保证在标记阶段识别出所有的存活对象,但是由于应用程序并发运行,这个阶段还会产生垃圾,而且只能到下次老年代收集才会被清理,这部分垃圾称为 浮动垃圾

最后,由于缺少压缩环节,堆将会出现碎片化问题。为了解决这个问题,CMS 收集器需要追踪最常用的对象大小,评估将来的分配需求,可能还需要分割或合并空闲区域。

不像其他垃圾收集器,CMS 收集器不能等到老年代满了才开始收集。否则的话,CMS 收集器将退化到使用更加耗时的 stop-the-world、标记-清除-压缩算法。为了避免这个,CMS 收集器需要统计之前每次垃圾收集的时间和老年代空间被消耗的速度。另外,如果老年代空间被消耗了 预设占用率(initiating occupancy),也将会触发一次垃圾收集,这个占用率通过 –XX:CMSInitiatingOccupancyFraction=n进行设置,n 为老年代空间的占用百分比,默认值是 68

这个数字到 Java8 的时候已经变为默认 92 了,以后再具体说

总结下来,和并行收集器相比,CMS 收集器 降低了老年代收集时的停顿时间(有时是显著降低), 稍微增加了一些年轻代收集的时间降低了吞吐量以及 需要更多的堆内存

增量模式

CMS 收集器可以使用增量模式,在并发标记阶段,周期性地将自己的 CPU 时钟周期让出来给应用程序。这个功能适用于需要 CMS 的低延时,但是 CPU 核心只有 1 个或 2 个的情况。

何时使用 CMS 收集器

适用于应用程序要求低停顿,同时能接受在垃圾收集阶段和垃圾收集线程一起共享 CPU 资源的场景,典型的就是 web 应用了。

在 web 应用中,低延时非常重要,所以 CMS 几乎就是唯一选择,直到后来 G1 的出现。

使用 CMS 收集器

显示指定:-XX:+UseConcMarkSweepGC

如果需要增量模式:–XX:+CMSIncrementalModeoption

小结

虽然是翻译的文章,也小结一下吧。

串行收集器:在年轻代和老年代都采用单线程,年轻代中使用 stop-the-world、复制算法;老年代使用 stop-the-world、标记 -> 清理 -> 压缩算法。

并行收集器:在年轻代中使用 并行、stop-the-world、复制算法;老年代使用串行收集器的 串行、stop-the-world、标记 -> 清理 -> 压缩算法。

并行压缩收集器:在年轻代中使用并行收集器的 并行、stop-the-world、复制算法;老年代使用 并行、stop-the-world、标记 -> 清理 -> 压缩算法。和并行收集器的区别是老年代使用了并行。

CMS 收集器:在年轻使用并行收集器的 并行、stop-the-world、复制算法;老年代使用 并发、标记 -> 清理算法,不压缩。本文介绍的唯一一个并发收集器,也是唯一一个不对老年代进行压缩的收集器。

另外,在 HotSpot 中,永久代使用的是和老年代一样的算法。到了 J2SE 8.0 的 HotSpot JVM 中,永久代被 MetaSpace 取代了,这个以后再介绍。

(全文完)

评论区

留下你的评论呗

  • Copyright © 2017-2018JavaDoop. All Rights Reserved. 联系我: hongjie.v#gmail.com

数据库面试常问的一些基本概念

$
0
0

点击上方“Java知音”,选择“置顶公众号”

技术文章第一时间送达!


作者:小宝鸽

链接:https://blog.csdn.net/u013142781

知音专栏

 

Javaweb练手项目源码下载

常用设计模式完整系列篇

100套IT类简历模板下载

Java常见面试题汇总篇


1、超键、候选键、主键、外键


超键:在关系中能唯一标识元组的属性集称为关系模式的超键。一个属性可以为作为一个超键,多个属性组合在一起也可以作为一个超键。超键包含候选键和主键。


候选键:是最小超键,即没有冗余元素的超键。


主键:数据库表中对储存数据对象予以唯一和完整标识的数据列或属性的组合。一个数据列只能有一个主键,且主键的取值不能缺失,即不能为空值(Null)。


外键:在一个表中存在的另一个表的主键称此表的外键。


2、什么是事务?什么是锁?


事务:就是被绑定在一起作为一个逻辑工作单元的 SQL 语句分组,如果任何一个语句操作失败那么整个操作就被失败,以后操作就会回滚到操作前状态,或者是上有个节点。为了确保要么执行,要么不执行,就可以使用事务。要将有组语句作为事务考虑,就需要通过 ACID 测试,即原子性,一致性,隔离性和持久性。


锁:在所以的 DBMS 中,锁是实现事务的关键,锁可以保证事务的完整性和并发性。与现实生活中锁一样,它可以使某些数据的拥有者,在某段时间内不能使用某些数据或数据结构。当然锁还分级别的。


3、数据库事务的四个特性及含义


原子性:整个事务中的所有操作,要么全部完成,要么全部不完成,不可能停滞在中间某个环节。事务在执行过程中发生错误,会被回滚(Rollback)到事务开始前的状态,就像这个事务从来没有执行过一样。


一致性:在事务开始之前和事务结束以后,数据库的完整性约束没有被破坏。


隔离性:隔离状态执行事务,使它们好像是系统在给定时间内执行的唯一操作。如果有两个事务,运行在相同的时间内,执行 相同的功能,事务的隔离性将确保每一事务在系统中认为只有该事务在使用系统。这种属性有时称为串行化,为了防止事务操作间的混淆,必须串行化或序列化请 求,使得在同一时间仅有一个请求用于同一数据。


持久性:在事务完成以后,该事务所对数据库所作的更改便持久的保存在数据库之中,并不会被回滚。


4、什么是视图?


视图是一种虚拟的表,具有和物理表相同的功能。可以对视图进行增,改,查,操作,试图通常是有一个表或者多个表的行或列的子集。对视图的修改不影响基本表。它使得我们获取数据更容易,相比多表查询。


如下两种场景一般会使用到视图:


(1)不希望访问者获取整个表的信息,只暴露部分字段给访问者,所以就建一个虚表,就是视图。


(2)查询的数据来源于不同的表,而查询者希望以统一的方式查询,这样也可以建立一个视图,把多个表查询结果联合起来,查询者只需要直接从视图中获取数据,不必考虑数据来源于不同表所带来的差异。


注:这个视图是在数据库中创建的 而不是用代码创建的。


5、触发器的作用?


触发器是一中特殊的存储过程,主要是通过事件来触发而被执行的。它可以强化约束,来维护数据的完整性和一致性,可以跟踪数据库内的操作从而不允许未经许可的更新和变化。可以联级运算。如,某表上的触发器上包含对另一个表的数据操作,而该操作又会导致该表触发器被触发。


6、 维护数据库的完整性和一致性,你喜欢用触发器还是自写业务逻辑?为什么?


尽可能使用约束,如 check, 主键,外键,非空字段等来约束,这样做效率最高,也最方便。其次是使用触发器,这种方法可以保证,无论什么业务系统访问数据库都可以保证数据的完整新和一致性。最后考虑的是自写业务逻辑,但这样做麻烦,编程复杂,效率低下。


7、索引的作用?和它的优点缺点是什么?


数据库索引,是数据库管理系统中一个排序的数据结构,以协助快速查询、更新数据库表中数据。索引的实现通常使用B树及其变种B+树。


在数据之外,数据库系统还维护着满足特定查找算法的数据结构,这些数据结构以某种方式引用(指向)数据,这样就可以在这些数据结构上实现高级查找算法。这种数据结构,就是索引。


为表设置索引要付出代价的:一是增加了数据库的存储空间,二是在插入和修改数据时要花费较多的时间(因为索引也要随之变动)。


创建索引可以大大提高系统的性能(优点):


第一,通过创建唯一性索引,可以保证数据库表中每一行数据的唯一性。

第二,可以大大加快数据的检索速度,这也是创建索引的最主要的原因。

第三,可以加速表和表之间的连接,特别是在实现数据的参考完整性方面特别有意义。

第四,在使用分组和排序子句进行数据检索时,同样可以显著减少查询中分组和排序的时间。

第五,通过使用索引,可以在查询的过程中,使用优化隐藏器,提高系统的性能。

也许会有人要问:增加索引有如此多的优点,为什么不对表中的每一个列创建一个索引呢?


增加索引也有许多不利的方面:


第一,创建索引和维护索引要耗费时间,这种时间随着数据量的增加而增加。

第二,索引需要占物理空间,除了数据表占数据空间之外,每一个索引还要占一定的物理空间,如果要建立聚簇索引,那么需要的空间就会更大。

第三,当对表中的数据进行增加、删除和修改的时候,索引也要动态的维护,这样就降低了数据的维护速度。

索引是建立在数据库表中的某些列的上面。在创建索引的时候,应该考虑在哪些列上可以创建索引,在哪些列上不能创建索引。


一般来说,应该在这些列上创建索引:

(1)在经常需要搜索的列上,可以加快搜索的速度;

(2)在作为主键的列上,强制该列的唯一性和组织表中数据的排列结构;

(3)在经常用在连接的列上,这些列主要是一些外键,可以加快连接的速度;

(4)在经常需要根据范围进行搜索的列上创建索引,因为索引已经排序,其指定的范围是连续的;

(5)在经常需要排序的列上创建索引,因为索引已经排序,这样查询可以利用索引的排序,加快排序查询时间;

(6)在经常使用在WHERE子句中的列上面创建索引,加快条件的判断速度。


同样,对于有些列不应该创建索引:

第一,对于那些在查询中很少使用或者参考的列不应该创建索引。这是因为,既然这些列很少使用到,因此有索引或者无索引,并不能提高查询速度。相反,由于增加了索引,反而降低了系统的维护速度和增大了空间需求。

第二,对于那些只有很少数据值的列也不应该增加索引。这是因为,由于这些列的取值很少,例如人事表的性别列,在查询的结果中,结果集的数据行占了表中数据行的很大比例,即需要在表中搜索的数据行的比例很大。增加索引,并不能明显加快检索速度。

第三,对于那些定义为text, image和bit数据类型的列不应该增加索引。这是因为,这些列的数据量要么相当大,要么取值很少。

第四,当修改性能远远大于检索性能时,不应该创建索引。这是因为,修改性能和检索性能是互相矛盾的。当增加索引时,会提高检索性能,但是会降低修改性能。当减少索引时,会提高修改性能,降低检索性能。因此,当修改性能远远大于检索性能时,不应该创建索引。


8、drop,delete与truncate的区别


  • drop直接删掉表 。 

  • truncate删除表中数据,再插入时自增长id又从1开始 。 

  • delete删除表中数据,可以加where字句。


(1) DELETE语句执行删除的过程是每次从表中删除一行,并且同时将该行的删除操作作为事务记录在日志中保存以便进行进行回滚操作。TRUNCATE TABLE 则一次性地从表中删除所有的数据并不把单独的删除操作记录记入日志保存,删除行是不能恢复的。并且在删除的过程中不会激活与表有关的删除触发器。执行速度快。

(2) 表和索引所占空间。当表被TRUNCATE 后,这个表和索引所占用的空间会恢复到初始大小,而DELETE操作不会减少表或索引所占用的空间。drop语句将表所占用的空间全释放掉。

(3) 一般而言,drop > truncate > delete

(4) 应用范围。TRUNCATE 只能对TABLE;DELETE可以是table和view

(5) TRUNCATE 和DELETE只删除数据,而DROP则删除整个表(结构和数据)。

(6) truncate与不带where的delete :只删除数据,而不删除表的结构(定义)drop语句将删除表的结构被依赖的约束(constrain),触发器(trigger)索引(index);依赖于该表的存储过程/函数将被保留,但其状态会变为:invalid。

(7) delete语句为DML(data maintain Language),这个操作会被放到 rollback segment中,事务提交后才生效。如果有相应的 tigger,执行的时候将被触发。

(8) truncate、drop是DLL(data define language),操作立即生效,原数据不放到 rollback segment中,不能回滚。

(9) 在没有备份情况下,谨慎使用 drop 与 truncate。要删除部分数据行采用delete且注意结合where来约束影响范围。回滚段要足够大。要删除表用drop;若想保留表而将表中数据删除,如果于事务无关,用truncate即可实现。如果和事务有关,或老师想触发trigger,还是用delete。

(10) Truncate table 表名 速度快,而且效率高,因为: 
truncate table 在功能上与不带 WHERE 子句的 DELETE 语句相同:二者均删除表中的全部行。但 TRUNCATE TABLE 比 DELETE 速度快,且使用的系统和事务日志资源少。DELETE 语句每次删除一行,并在事务日志中为所删除的每行记录一项。TRUNCATE TABLE 通过释放存储表数据所用的数据页来删除数据,并且只在事务日志中记录页的释放。

(11) TRUNCATE TABLE 删除表中的所有行,但表结构及其列、约束、索引等保持不变。新行标识所用的计数值重置为该列的种子。如果想保留标识计数值,请改用 DELETE。如果要删除表定义及其数据,请使用 DROP TABLE 语句。

(12) 对于由 FOREIGN KEY 约束引用的表,不能使用 TRUNCATE TABLE,而应使用不带 WHERE 子句的 DELETE 语句。由于 TRUNCATE TABLE 不记录在日志中,所以它不能激活触发器。



为何青春期女生发育时大胸,会被认为是可耻的呢?

$
0
0

许多回答都谈到了性教育的问题,似乎认为这一现象仅见于中国,是性教育落后的产物。事实上,同伴群体对发育较早的女生表现出排斥, 并不是中国特有的现象,也显然不是对性无知这一点所能解释的。

众所周知,青少年在成长发育中,同伴群体(peer group)的影响特别大。在任何一本发展心理学的教材中,同伴群体几乎都会与学校、家庭并列成为青少年社会化的主要影响因素。近年来由于公众对校园欺凌的认识逐渐加深,一般人恐怕也能意识到青少年在其同学中是否“受欢迎”(popularity)对其在学校的生活以及日后的发展非常重要。

而影响青少年在同伴群体中受接纳、受欢迎的因素有很多,包括家庭教养方式、气质与性格、认知能力等等。其中非常重要的可能是身体特征,如面孔吸引力(漂不漂亮)、体格(强壮还是羸弱等)。另外一个非常重要的身体特征就是青春期的发育时间。青春期的发育对于男性女性而言呈现出截然相反的作用:

  • 对男孩而言,比同伴发育早,一般会在人际环境中更自信,更“老练”,在同伴中受欢迎,甚至会成为小团体中带有某种“领袖”色彩的人物。发育较晚常常导致被排斥。
  • 对女孩而言,比同伴发育早,则 常会被同龄人排斥,不少人因此变得内向,甚至出现抑郁、焦虑等症状。而 这似乎是一种普遍现象,比如,在芬兰、美国、瑞典等国的研究都发现了青春期较早的女生更容易被排斥,进而更容易表现出多种身心症状,如饮食障碍、尝试自杀等(如Aro, & Taipale, 1987)。

出现这一现象的原因可能是:

  1. 女性青春期提前后发生的变化使其明显与同龄女生不一样,而青春期的同伴群体的内部规范常常促使其排斥这些“异类”,认为“大胸可耻”只不过是这一排斥的反映而已;
  2. 另外,由于女性总体青春期早于男性,提前进入青春期的女生就更早,所以她们常不得不面对一群明显在心智上显得幼稚的多的男同学。常见的情况是,这些早熟的女生会渐渐更乐于与高年级的同学(尤其是高年级的男生)交往,而这常常会为那些排斥她们的人提供许多“口实”——“整天跟高年级的男生鬼混”;早熟的女生自己往往也尚不足以真正处理那些更大一些的青少年能够处理的问题,所以与高年级的人交往也确实可能会导致一些行为偏差(旷课、成绩下降等)。


总体看来,这一现象背后虽然还可以找到不少其他的原因,如文化因素和进化心理学中的“同性竞争”等机制,但其本质上应属于一个“发展性问题”,也就是随着青少年年龄增大,这样的现象就会慢慢消失。比如,随着时间推移,女生们发现青春期的女生更受男生欢迎了,反而会开始羡慕。


参考文献

  1. Aro, H., & Taipale, V. (1987). The impact of timing of puberty on psychosomatic symptoms among fourteen- to sixteen-year-old Finnish girls. Child Development, 58, 261-268.
  2. Caspi, A., Lynam, D., Moffitt, T. E., & Silva, P. A. (1993). Unraveling girls' delinquency: Biological, dispositional, and contextual contributors to adolescents misbehavior. Developmental Psychology, 29, 19-30.
  3. Kaltiala-Heino, R., Marttunen, M., Rantanen, P., & Rimpela, M. (2003). Early puberty is associated with mental health problems in middle adolescence. Social Science & Medicine, 57, 1055–1064
  4. Shaffer, D. R. (2009). Social and personality development (6 ed.). Belmont, USA: Wadsworth Publishing.


来源:知乎 www.zhihu.com
作者: 吴漾

【知乎日报】千万用户的选择,做朋友圈里的新鲜事分享大牛。 点击下载

此问题还有 512 个回答,查看全部。
延伸阅读:
女生由丑变美后是什么样的感觉?
在中国做女人是种怎样的体验?

为什么女人生完孩子后会判若两人? - 知乎

$
0
0

生完孩子请了月嫂,月嫂都觉得我为啥每天都很嗨皮。

后来请了育儿嫂,育儿嫂是有周末休息的,周末一休息,就开始吵架,育儿嫂一回来,恢复嗨皮状态。

说真的,我觉得,就是累的,睡眠不足,杂事太多,压力太大——>情绪爆炸。

顺便补充一下评论里的一些讨论点:

不是说没钱就不要生,生孩子,需要作经济准备和心理准备,都很重要,如果心态很好,能力很强,钱没准备够,也一样能带好孩子;如果自己心理不合格,那请一群保姆都不顶用,我生娃时,产后病房同住就有个很年轻的妈妈,她叫了月嫂来医院陪床带娃,娃一哭,那妈妈就一直恶狠狠骂脏话“SB,哭什么哭,再哭扔掉你!”我都惊呆了,她晚几年修炼好心态再生娃不好么;至于如果自己只是心理素质一般的普通人,那么经济准备就很重要了,生娃前多存点钱,用来改善生娃后的生活质量。

觉得女的产后情绪爆炸只是女的作的网友,看来我是场景描述得不够。育儿嫂休息的周末,通常情节是这样的,睡眼朦胧的我很着急地喊:“快快快,娃衣服脏了,快帮我拿纸来!”同样睡眼朦胧的老公很凶地吼回来:“急什么急!你自己倒是弄啊!”我:“你这什么态度啊?你吼什么吼?喊你一下你就这么凶啊?”然后我们就开吵了,互相指责对方不好,指责到感觉日子都没法过了。。。。育儿嫂回来了,把烂摊子一收拾,啊,心情好愉快,我和老公可以出去放风一下了,至于吵架呢?嗨,那不就是没睡醒整的嘛,睡醒了大家都心情愉快恢复好人面目。所以,情绪爆炸是男的事女的事?男的女的都是人类,不是火星人和金星人,压力之下,随便什么小事都有可能是压垮神经的最后一根稻草。

至于如果有人想说,“明明有笑对所有压力、如何如何强大的人,怎么人家做到的?凭啥你做不到?就是惯得娇气”那是人和人的能力有差异,有人考北大,有人再努力也上北大青鸟,能一样么?我高中就有学习压力太大自己又特别刻苦结果高三疯了的同学,你说人家不努力么,怎么没考上北大呢?再预防一下的补充,至于假如有人说古代女人生十个八个、不仅男人当甩手掌柜、女人还能下地干活的,一定是现代女人太娇气,那我只能说没啥好交流的了,期待这样的人先把手机扔了把电断了自来水断了穿越回古代劈柴烧火生个病靠熬去,活不下来就算太娇气。

逮到一个精神古人,评论了一大堆,省得他键盘打得累,我替他总结总结:你们这些年轻人啊,不像话,奢靡浪费,贪图享乐,当年我可是。。。你们统统该批斗!

大家请认真学习。

~~

再补充一点,很多人觉得,带孩子就是得自己带,不然就是不合格!我个人观点是,大多数人不是全职妈妈吧?都是要上班的吧?那怎么办?老人带孩子一定好么?我婆婆不带孩子,就是过来看看,月子就闹腾要断奶(我当年4个月断奶我光荣),喝米汤(米汤上面那层糊糊最有营养),快加盐(不吃盐没力气)无论如何也说不通,说医院都是骗钱的,娃哪不对要烧烧香什么的,育儿嫂因为这些事也是被婆婆各种横挑鼻子竖挑眼找茬,后来被指着鼻子骂哭n次,辞职了。你说我选婆婆还是育儿嫂?

现代社会,不是一家一户的农耕时代,没必要抱着“米一定要自己种,衣服一定要自己织,居然不耕地不织布,留出精力做别的事去了,就是邪路”的思想吧?如果自己能力不够,花点钱请专业的人来帮忙,完全是正常的选择。尤其是新手妈妈,刚开始确实是抓瞎的,如果一开始有一个熟手带一下,会好很多。至于老人是不是熟手,那分人了,碰上我家这种情况,你说呢?

推荐 3 个简历模板及 2 大加分技巧

$
0
0

2018 互联网人员简历如何脱颖而出中"十不要"第一条就是

[crayon-5abc4abe0881a516496249/]

今天先推荐三个简历模板,然后介绍两个提高简历质量的技巧。

 

一、推荐简历模板




第三和第一很像,具体看完本文大家会了解他对哪些朋友更适用。

 

以上模板 Word、PDF、Markdown 版均可从 https://github.com/Trinea/trinea-download/tree/master/resume 下载。

 

另外感谢 @JoshuaRogue 提供了这两个简历模板的 Markdown 版本,MD 粉可以试试。

 

二、简历技巧

2018 互联网人员简历如何脱颖而出提到简历需要

[crayon-5abc4abe08831536600617/]

这里展开介绍些相关技巧。

 

1. 最重要的首屏

(1) 简历打分≈经验(公司)+技能+学历,所以:

[crayon-5abc4abe08837224309310/]

 

(2) 尽量把亮眼的模块放前面,劣势的模块放后面
扬长避短,内容模块合理排序,保证第一眼有个最好印象

 

如:
如果本身学历较差,就不要放在简历最前面,简历末尾空间很大;
如果学校很好,而呆的公司名气和技术圈内影响都很小,就学校放前面;
如果职位对经验要求比较高,而你实际工作经验短,有一定实习经历,那就把工作经验模块放到前面,教育经历模块尽量放到后面;
如果职位对经验要求比较高,而你工作经验短,公司学校一般,那就把技能模块放到最前面;

 

下面介绍下如何写技能模块。

 

2. 如何写技能

技能模块可能给自己挖坑,同样也能给面试官埋坑,是仅次于工作经验的模块。

 

(1) 不要写一般 Android 开发都会的
比如:
"熟悉 Android 四大组件"
"熟练使用 Java"
"熟练使用 Android Studio"
"熟练掌握面向对象思想"
"熟悉常见数据结构和算法"
… 难道这不是每个 Android 开发该会的吗?
嗯,应届 Android 都该会的。

 

(2) 尽量不要写"会使用"类的技能
比如:
"能使用 Android Studio 开发、Charles 抓包、Jadx 反编译"
"能使用 Picasso、Volley 等三方开源库"

如果这已经是你的最高技能了,建议抽点时间去补充点高级技术点。

 

(3) 技能需要显示你不一样的技术水平
比如:
"深入了解 Retroft、React Native 等开源库原理,熟悉热修复原理"
"有内存优化等性能优化经验"
"熟悉 Android 应用框架设计,熟悉 Android 高性能编程及调优"
… 这里需要把握度,你的技能需要是真实的,要不反倒容易坑了自己。

 

(4) 技能一定程度可以往招聘技术要求靠齐

 

(5) 技能点五六条足以,太多说明写的不够好

 

如何让首屏显眼的技巧、重要的技能模块写法 今天先分享这些,怎么样,简历是不是还可以改改

美国贸易战可能打击的中企名单曝光

$
0
0

3月22号美国总统特朗普在白宫宣布,依照对中国的301知识产权调查结果,美国政府将在每年向600亿美元中国商品征收关税,并在某些产业上限制中资。

现在美国贸易代表办公室逐步公布关税商品的详细清单报告,从已公布报告可以发现,在征收惩罚性关税的表面之下,美国的真正用意是“重点关照”中国在各领域当中有较强国际竞争力的跨国企业,扼杀旨在引领科技潮流的“中国制造2025”,抑制中国科技力量的崛起。

白宫在一份200页的报告中提到了一些中国企业的名字,作为来自中国的“不公平”竞争如何使美国吃亏的例证。

分析人士认为,这些关税背后隐藏着白宫一个更广泛的目标,即破坏中国一项被称为 “中国制造 2025”(Made in China 2025) 的高层战略。

该战略旨在将一批中国企业打造为机器人、半导体、飞机制造、计算机应用等行业的世界领军者。

根据“中国制造 2025”战略,要点是通过与外国公司合作或者获取海外技术,帮助中国企业崛起为各自所在行业的全球主导者。

美国白宫贸易顾问纳瓦罗(Peter Navarro)周三做客彭博电视时称:“上周总统签署的针对中国商品的关税法令将集中于中国制造2025计划所强调的产业上。”

牛津经济研究所 (Oxford Economics) 亚洲经济部主任高路易 (Louis Kuijs) 在一份报告中表示:“美国计划实施的关税和投资限制措施意在打击中国,以回应美国视为不公平的技术和知识产权做法。”

“其中最重要的似乎是让技术更慢向中国转移。”标普全球 (S&P Global) 首席中国企业评级专家李国宜 (Christopher Lee) 表示。

美国贸易代表办公室已经把 “航空航天、信息和通信技术、机械” 列为将要征收关税的行业。预计 4 月初将公布更多细节,不过白宫已经在一份 200 页的报告中提到了一些中国企业的名字,作为来自中国的 “不公平” 竞争如何使美国吃亏的例证。

根据美方的报告,对美构成最大威胁的包括以下这些公司:

美的集团

家电制造商美的集团虽然不是国有企业,但在中国打造具有全球竞争力的机器人产业的计划中,美的具有重要地位。2016 年,美的斥资 42 亿美元收购了德国顶尖机器人集团之一库卡 (Kuka)。

美国政府认为美的是一个例子,它是一家中国民营企业集团,却似乎在执行北京上述发展政策的一些方面。美的从多家政策性银行获得了数亿美元计的贷款以支持其收购项目。

根据美国贸易办公室的说法,承贷机构之一中国进出口银行 (China Exim Bank) 表示,“该项目的实施,有助于优化中国机器人产业布局,推动多产业生产自动化进程,提升中国智造技术水平”。

中国化工

2016 年初,国有的中国化工宣布将斥资 440 亿美元收购全球最大的农药和种子集团之一瑞士先正达 (Syngenta),此举吸引了全世界的目光。这宗交易契合北京方面关于控制一系列技术以确保粮食安全、实现农业现代化的政策。

美国贸易办公室已经注意到,这宗部分由国有银行支持的交易已将在美国的 “4000 名员工、33 处研究基地以及 31 处生产和供应基地” 置于了一家听命于北京的企业集团的控制之下。

这宗收购还使陶氏杜邦 (DowDuPont)、孟山都(Monsanto) 等美国农药生产商陷入与中国政府的直接竞争,使中国化工将形成的遍及全球的触手成为美国关税的一个主要目标。

中国中车

中国中车及其他中国国有铁路集团是与庞巴迪 (Bombardier)、西门子(Siemens) 等全球行业领军企业建立合资公司的主要受益者。中国中车目前是全球最大的铁路车辆制造商。

除了供应中国快速扩张的高速铁路和地铁系统,中国中车近几年还进入了美国市场,拿下了为波士顿、芝加哥、洛杉矶、费城供应地铁列车的合同。

中国中车迄今一直从中国出口产品,但该公司位于马萨诸塞州斯普林菲尔德 (Springfield) 的首家美国工厂很快将开始投产。中国中车称,该工厂是美中合作 “双赢” 的一个案例。

白宫把中国铁路产品列为关税征收对象,不过美国贸易办公室的报告中倒是没有提到中国中车的名字。

中国商飞和中国航空工业集团

这两家中国国有飞机制造集团正试图打破波音 (Boeing) 和空客 (Airbus) 在客机市场上的垄断地位,并把中国变成一个航空制造业强国。

中国商飞意在与波音 737、空客 A320 竞争的 C919 客机,仍处于早期测试阶段,还需数年时间才能投入量产。但分析人士认为,C919 最终将能从这两家主导者手中夺走市场份额,尤其是在中国。

中国航空工业集团持有中国商飞的股份。两家公司通过对美国飞机和航电设备公司的一系列收购推动了自身发展。美国贸易代表办公室在对中国不公平贸易做法的调查中强调了上述收购。两家公司都考虑过部分或整体收购加拿大喷气式飞机制造商庞巴迪。

中国商飞依靠与包括通用电气 (GE)、霍尼韦尔(Honeywell)、罗克韦尔 • 柯林斯公司(Rockwell Collins) 在内的美国公司建立的合作和合资公司,为 C919 供应包括发动机、机轮和航电设备在内的关键部件。

清华紫光

在中国政府支持的投资者中,少有像清华紫光集团如此激进地在全球四处追逐半导体资产的。这个由位于北京的清华大学 (Tsinghua University) 控股的集团的成立使命就是通过收购把国外的半导体技术带到中国。

美国贸易办公室的报告指出,清华紫光已经从由中国工信部直接控制的国家集成电路产业投资基金 (National IC Fund) 获得了资金。

清华紫光曾多次尝试直接收购优质美国资产。例如,2015 年,该集团提出以 38 亿美元收购美国西部数据 (Western Digital) 15% 的股份。但在美国监管机构发起调查后,清华紫光撤销了这笔交易。

但清华紫光支持的集团还发起了一些规模较小、旨在进行类似收购交易的基金。另一家出现在美国贸易办公室报告中的实体——华创投资 (Hua Capital),利用来自清华紫光的资金收购了美国数字成像公司 OmniVision。

华大基因

作为全球最大的基因组学研发机构,华大基因吸引了一轮又一轮愿意出高价的私募股权机构的投资。红杉资本 (Sequoia Capital) 是华大基因的主要投资者之一。

2013 年,华大基因收购了总部位于美国的基因组测序公司 Complete Genomics,后者已经对逾 2 万个人类基因组进行了测序。

华盛顿担心中国政府和共产党对华大基因的兴趣。上述报告指出,华大基因已经从政策性银行中国国家开发银行 (China Development Bank) 获得了大笔贷款,并表示,虽然股权结构为私人所有,但华大基因“与政府有明显关联”。@今日话题 @烤鳄梨鳗鱼饭 



本话题在雪球有0条讨论,点击查看。
雪球是一个投资者的社交网络,聪明的投资者都在这里。
点击下载雪球手机客户端 http://xueqiu.com/xz

腾讯开源:微信和移动开发的 10 大项目

$
0
0

腾讯开源了许多非常有价值的项目,下面我们一起来看看腾讯10大开源项目有哪些?

1、Android 热修复框架 Tinker


Tinker 是微信官方的 Android 热补丁解决方案,它支持动态下发代码、So 库以及资源,让应用能够在不需要重新安装的情况下实现更新。当然,你也可以使用 Tinker 来更新你的插件。


它主要包括以下几个部分:

● gradle编译插件: tinker-patch-gradle-plugin

● 核心sdk库: tinker-android-lib

● 非gradle编译用户的命令行版本: tinker-patch-cli.jar(详情:https://github.com/Tencent/tinker)


2、微信客户端跨平台组件 Mars


Mars 是微信官方的终端基础组件,目前已接入微信 Android、iOS、Mac、Windows、WP 等客户端。主要包括以下几个部分:

● comm:可以独立使用的公共库,包括 socket,线程,消息队列,协程等;

● Xlog软件:日志组件,可靠性高,高性能

● SDT:网络诊断组件

● STN:信令分发网络模块,也是Mars最主要的部分。图。(详情:https://github.com/Tencent/mars)


3、小程序组件化开发框架 wepy


WePY 是一款让小程序支持组件化开发的框架,通过预编译的手段让开发者可以选择自己喜欢的开发风格去开发小程序。框架的细节优化,Promise,Async Functions 的引入都是为了能让开发小程序项目变得更加简单,高效。

同时 WePY 也是一款成长中的框架,大量吸收借鉴了一些优化前端工具以及框架的设计理念和思想。如果 WePY 有不足地方,或者你有更好的想法,欢迎提交 ISSUE 或者 PR。

特性:

● 类Vue开发风格

● 支持自定义组件开发

● 支持引入NPM包

● 支持Promise

● 支持ES2015+特性,如Async Functions

● 支持多种编译器,Less/Sass/Stylus、Babel/Typescript、Pug

● 支持多种插件处理,文件压缩,图片压缩,内容替换等

● 支持 Sourcemap,ESLint等

● 小程序细节优化,如请求列队,事件优化等(详情:https://github.com/Tencent/wepy)


4、轻量级高性能的 Hybrid 框架 VasSonic

使用前

 

使用后


VasSonic 是腾讯QQ会员 VAS团队研发的一个轻量级的高性能的 Hybrid框架,专注于提升页面首屏加载速度,完美支持静态直出页面和动态直出页面,兼容离线包等方案。


接入 VasSonic 后首次打开可以在初始化 APP 的时候并行请求页面资源,并且具备边加载边渲染的能力。非首次打开时,APP 可以快速加载上次打开动态缓存在本地的页面资源,然后动态刷新页面。腾讯手机QQ通过VasSonic 框架使得页面首屏耗时平均低于1S以下。(源码:https://github.com/Tencent/VasSonic 文档:https://github.com/Tencent/VasSonic/wiki)


5、微信团队前端开发工具 WeFlow


这是一个高效、强大、跨平台(macOS & Win)的前端工具,核心基于 tmt-workflow 工作流.(详情:https://github.com/weixin/WeFlow)



6、移动数据库框架 WCDB

WCDB 是一个高效、完整、易用的移动数据库框架,基于 SQLCipher,支持 iOS, macOS 和 Android。


基本特性:

● 易用,WCDB支持一句代码即可将数据取出并组合为object。

● 高效,WCDB通过框架层和sqlcipher源码优化,使其更高效的表现。

● 完整,WCDB覆盖了数据库相关各种场景的所需功能。(详情:https://github.com/Tencent/wcdb)


7、基于参数服务器理念的机器学习框架 Angel


Angel 是一个基于参数服务器(Parameter Server)理念开发的高性能分布式机器学习平台,它基于腾讯内部的海量数据进行了反复的调优,并具有广泛的适用性和稳定性,模型维度越高,优势越明显。 Angel 由腾讯和北京大学联合开发,兼顾了工业界的高可用性和学术界的创新性。

Angel 基于 Java 和 Scala 开发,能在社区的 Yarn 上直接调度运行,并基于 PS Service,支持 Spark on Angel,未来将会支持图计算和深度学习框架集成。(详情:https://github.com/Tencent/angel)


8、自动内存泄漏检测工具 MLeaksFinder


MLeaksFinder 是腾讯开源的 iOS 平台的自动内存泄漏检测工具,引进 MLeaksFinder 后,就可以在日常的开发,调试业务逻辑的过程中自动地发现并警告内存泄漏。具有如下特性:

● 自动检测内存泄漏和释放不及时的场景

● 构建泄漏对象相对于 ViewContrller 的引用链以帮助开发者定位问题

● 不侵入业务逻辑,引入即生效,无需修改任何代码或引入头文件(详情:https://github.com/Tencent/MLeaksFinder)


9、UI 库 WeUI

WeUI 是由微信官方设计团队专为微信移动 Web 应用设计的 UI 库。WeUI 是一套同微信原生视觉体验一致的基础样式库,为微信 Web 开发量身设计,可以令用户的使用感知更加统一。包含button、cell、dialog、toast、article、icon等各式元素。(详情:https://github.com/weixin/WeUI)


10、分布式后台服务引擎 MSEC


毫秒服务引擎(MSEC)由腾讯 QQ 团队开源。它是一个后端 DEV&OPS 引擎,包括RPC,名称查找,负载平衡,监控,发布和容量管理。毫秒服务引擎特性:

● 模块间访问采用 RPC 的方式,开发者不用关注网络与报文格式,像写单机程序一样开发分布式服务。

● 负载自动均衡与容错,对于单机故障、局部网络波动等状况自动应对,服务高可用性。

● 支持 C/C++/java/PHP 语言,如果选择 C/C++ 语言,支持协程,兼具开发和运行效率。

● Web 化的管理界面

● 简易部署,需要复杂部署的服务器都采用 docker 镜像的方式安装

● 相比使用其他开源组件拼凑起来的解决方案,毫秒服务引擎更加的体系化,对团队的规范更加到位




美团外卖骑手背后的AI技术

$
0
0

背景

随着数字化时代的到来,外卖市场近年来发展非常迅猛。对外卖物流系统而言,配送效率和用户体验至关重要。而实际配送过程是由配送员(骑手)最终完成的,因此,想要真正提升配送效率,不但要在智能调度系统(订单指派、路径规划、ETA)上下功夫,还要不断提升配送员的“附加”能力,让他们越送越“熟”,越送越“顺”,越送越“快”。以此为出发点,美团点评研发团队设计了骑手智能助手,全面提升骑手的各方面能力。

在 1月份的AICon全球人工智能与机器学习技术大会上,美团点评配送人工智能方向负责人何仁清分享了《美团骑手智能助手的技术与实践》。讲解如何在使用环境复杂、用户群体多元化的情况下,以智能耳机和语音交互为载体,并通过大数据挖掘、机器学习、自然语言处理等技术,让智能助手具备复杂场景精准识别、服务智能推送,智能引导、全语音操作等能力。最终在智能、安全、便捷、精准等多个维度上,全面提升骑手配送能力,从而提升整个配送效率和用户体验。以下系演讲内容整理:

AI技术对同城配送的业务价值

总体而言,物流业务是一个比较传统的行业,但是随着整个电商、移动互联网和移动支付的兴起,近些年整个物流行业实现了持续和高速的发展。

物流行业

上图系中国物流与采购联合会在 2016年发布的一个报告,调研数据表明,全国物流件数环比增长超过 50%,达到 300多亿件。

同时整个物流的费用占比也很高,从图中可以看到,物流成本已经占据 GDP的 15%。而在欧美国家以及日本,这个比例大概只有 8%~9%左右,所以中国的物流行业还有很大的优化空间。这也是很多公司大力投入去做物流行业的一个很重要的原因:行业正处于高速发展阶段,而且体验、效率和成本方面都有巨大的优化空间,大有可为。

下图主要介绍了美团外卖现在的发展情况:

02美团外卖发展情况

美团外卖从2013年启动,目前大概能够服务 2.5亿用户,已经覆盖1300多个城市,能够为 200多万商户提供服务,日峰值订单超过 1800万。美团外卖智能配送调度系统每天匹配50多万外卖小哥,基于海量数据和人工智能算法,确保平均配送时长不超过 28分钟。这也是目前世界上规模最大、复杂度最高的多人、多点实时智能配送调度系统。

我们对美团配送的定位是: 做成最大的即时配送平台

03美团配送定位

相比传统物流,即时配送包括以下几个优势:

  • 第一点,非常快。从商家发单,比如说一个外卖订单,从下单到用户收到,平均要在 30分钟内能完成,最慢的也应该在一小时左右。快,是最重要的一个特点,快,也能够使整个服务的要求和服务质量得到巨大提升。

  • 第二点,能够直接联系用户和商户。之前的物流基本是从商家接单,要经过很多环节,包括仓储、运输调度、人员配送等等,最后再送到用户,中间几经转手,甚至由不同的公司配送,或者有不同的加盟商。但是即时配送直接将用户和商户联系起来,进而直接影响目标人群,这是很大的一项价值。

  • 第三点,能够承担多种配送场景,不仅仅可以送外卖,还可以送商超、生鲜等等,基本上所有的同城快件,都可以纳入其配送服务范围。

总体来说,配送是一个非常复杂的业务,为了能够便于大家理解,我把这个业务模型进一些抽象和简化,可以用下面这张图来进行说明。

04配送ai问题

从本质上来讲,配送主要是把用户的配送需求和线下的各种运力(比如说骑手或车辆之类)进行匹配的过程。匹配分为线下匹配和线上匹配,线下主要靠运营,线上就是我们技术部门所构建一些系统。从这个层面而言,我们要解决的主要是在这个需求和运力之间,如何实现最优匹配的问题。

这其实也是一个相对比较传统的问题,像做广告或者推荐,都会面临这个问题,需求是要推荐的产品,供给是广告位置,但位置并不是无限多,如何在需求和供给之间达到最好的匹配,这本身就是效率优化问题,只不过广告和推荐使用的 CTR预估,而物流中使用的方法更加复杂一些。

配送中的复杂性,具体来说有几点:

  • 这是一个NP-Hard问题,计算复杂度随着规模呈指数级增加。比如是骑手身上 N个订单的路径规划问题,或者是 M个订单与 K个骑手的订单分配问题,这两个都是指数级复杂度,而且相互关联。

  • 这不但是一个多点取多点送问题,而且随时有新订单增加,具有非常强的实时计算要求,当一个新订单生成后,需要在几十毫秒内别完成调度运算,相比传统物流中有几十分钟以上的计算时间,即时配送系统设计的难度要大得多。

  • 配送场景非常复杂,涉及天气、路况、骑手熟练程度、商家出餐速度等多达几十个因素,极大增加了解空间的随机性和复杂度,对配送算法的稳定性和适应力挑战极大。

对美团配送来说,要完成这个任务,需要分为大概三个层次,如上图最右侧所示。

  • 第一层,物流基础结构建设。包括在城市里如何建设站点,如何配备人力,如何配备商家的供给情况。这些基础结构不但深刻影响配送的规模、成本、效率,而且是物流管理和运营的基础,比如加盟商管理、骑手运营等都需基于这个结构进行展开,因此这些基础结构的作用非常重要,而且它们较难进行即时调整,非常考验技术的长期预测和规划能力。

  • 第二层,供需匹配的动态均衡,通过定价机制进行市场调节,包括几个方面:一个是基础定价,比如一个定单来了,到底向用户收多少钱,向商家收多少钱,给骑手多少补贴,这需要考虑很多因素,保证定价的合理、公平。另一个是供需平衡,当遇到恶劣天气等突发情况,通过动态调价方式,实时调节用户需求和运力供给,保证整个系统的稳定与用户体验。

  • 第三层,订单和骑手的实时匹配,也就是派单,在订单出现后在几十毫秒内分配到一个最合适骑手,并完成多个订单的路径规划。这是一个NP-Hard问题,而且由于不断有新订单生成,需要实时计算,对并行计算引擎的要求很高。派单的优化目标是:提升整体配送的效率,并保证用户体验,是整个配送系统的核心模块之一。

以上,主要是我们对整个配送的理解,接下来讲述如何使用技术手段来进行落地和实践。

对于 AI问题来说,整个配送在AI问题中的分类应该是什么样?下图给出了一个解释。

05ai位置

我们可以从两个维度来看AI问题。一个维度,是看机器与人工的对比,速度上是不是比人工更快,是不是比人工的效果更好。

另一个维度是AI所发挥的作用。首先是不是能够感知世界,比如说现在做得图像识别、语音识别以及OCR,都是像人一样能够感知这个世界。其次是不是能做到认知,比如说了一句话,“今天天气怎么样”,不但要把语音翻译成文本,这里讲的是“天气”这个实体,还有“今天”这些限定因素。第三就是要做决策,现在比较火的人工智能应用都在“如何做决策”这个层面,而且要做比人做更好的决策。一些代表性应用,比如智能助手,特别是辅助人进决策权的(聊天机器人会差一些),可以帮你完成更好的任务;比如无人驾驶;比如在物流领域,如何分配订单,并通过无人车或别的方式交付订单;还有在游戏和医疗里面,AI辅助医生做决策,在游戏里面,当用户掉线时,游戏AI可以帮助用户打怪升级。

可以看到在配送层面,我们会涉及智能助手、智慧物流、无人驾驶等多个维度,而为了提升配送的整体智能化程度,我们构建了自己的“美团配送 AI”,具体来说分为两大部分:

07智慧物流

第一部分是信息化,也就是数据收集。举个例子,要收集到什么样的数据?我们要收集到一个商圈的数据,这个商圈可能要精细到小区和楼宇级别,一个楼在什么地方,这个小区是不是让骑手进来,同时还要收集天气数据,比如风速、温度,是否有雾霾,因为所有数据会影响到配送的效率,用户下单情况,比如今天雾霾,北京的外卖订单量估计会上涨。

第二部分是智能化,也就是构建一整套智能化模块,构成一个智能配送系统,覆盖配送的各个环节。

为了完成这个“美团配送 AI”的具有挑战的目标,并考虑整个行业的长期发展,我们在整个人工智能上的布局如下:

08技术布局

  • 首先是广度方面的建设。我们的目标是配送整体流程和环节进行 AI化,从用户下单开始的每个配送步骤都要覆盖,为此我们整体技术方向的面非常广,不但横跨三个大学科,而且从预测、挖掘、定价、规划、调度和硬件等都要进行技术研究和业务落地。

  • 其次是深度方面的建设。这不单单是指技术方面,比如基础计算框架和模型研究等,还包括技术与配送业务的深度整合,比如配送仿真平台建设,具备进行多配送场景的仿真能力,无需上线就能够对不同业务策略效果进行准确预估。同时还要结合行业情况,提供行业的智能化解决方案,比如在骑手运营方面,更有效的骑手激励和骑手留存的机制设计。

而美团外卖语音助手就属于我们在广度和深度结合比较好的案例。接下来就和大家分享一下我们在整个智能助手的实践和设计过程中,以及在整个物流业务中,如何将人工智能技术更好的落地的一些经验。

美团外卖智能语音助手定位

09外卖订单配送过程

我们为什么要智能语音助手?骑手到底在什么情况下需要智能助手服务,整个服务里面的关键是什么?先解释一下这个问题。如上图所示,这个是整个骑手在配送过程中遇到的一些环节,可以分为两大部分。

第一部分是线上的决策,而且涉及的决策各式各样。举个例子,这个骑手有定单,要送到一个用户那里,他可能要做几个决策,比如说要不要给用户打电话,因为有些地方是不用打电话的,像住宅楼里面,骑手有很大概率知道这个用户应该在家里的,不用打电话;有些必须打,比如写字楼,因为骑手上不去,所以需要提前打电话让用户下来。

但需要提前多长时间呢?是提前一分钟,两分钟,还是五分钟?这个问题很关键,如果打电话时间比较早,用户就会提前下来,会造成用户等待骑手的问题,用户体验不好,可能会有投诉。如果这个骑手非常保守,到楼下再打,但用户住在 10层,那么用户下来包括等电梯的时间可能要需要 10分钟,效率会变得非常低。

第二个部分是骑手操作过程,因为骑手会频繁和手机交互。他要查看一个定单,步骤非常复杂,把手机拿出来,解锁,打开 App,查看信息,做操作(比如说点击完成),最后放回手机,大概需要五到六个过程。如果操作快,也需要 10到 20秒钟。而且很多骑手是在骑行过程中做这些操作的,这样会非常危险。

总结一下,配送骑手遇到的困难可以总结为三个大的层面:

10骑手三大难题

  • 第一,任务复杂,需要做很多决策,不过复杂度会随着骑手的熟练度有所变化。

  • 第二,操作繁琐,大概需要五到六个步骤,至少需要 10到20秒,或者更长时间。

  • 第三,骑手在骑行过程中操作手机非常危险。对于有50万骑手的平台,我们必须考虑骑手在整个驾驶过程中的安全。

基于这些考虑,我们做了美团外卖语音助手,它的定位主要包括以下三点:

11语言助手定位

  • 第一点就是要求安全,要做一套全流程的语音交互方案,配送过程中的各个环节都能用语音操作,不需要骑手看手机,解放双手,让骑手更加安全。比如在行驶过程中,有个定单过来了,系统问骑手要不要接单,只要通过指令回答,“是”或“否”,或者“OK”这种,整个过程就完成了;不需要像以前那样的,把手机掏出来再进行操作,这个场景非常受骑手欢迎。

  • 第二个,设计极简的步骤,所有操作能在一到两个步骤里完成,第一个步骤是信息播报,第二个步骤通过语音命令完成操作,将原来的五到六个步骤,精简到现在的一到两个。

  • 第三个,提供很多智能化服务。最典型的,刚才说的骑手要去一个楼,用户可能在 5楼,可能在4楼,这个用户下来需要多长时间,做智能化推荐,根据用户的地址信息,系统智能推荐打电话时机,当然还包括像导航之类的基础功能。

上文的分析,基本上将我们怎么把智能语音助手在场景里落地的最关键的点分析出来了。我们要落地,最核心的就是要帮助骑手完成配送任务,而不是“聊天”或者“问答”。这就要求语音交互整个过程要非常便捷,同时也非常智能。

而我们遇到的第一个挑战,就是交互模式如何设计的问题。

12零唤醒

如上图所示,左侧是一般的语音助手方案,需要唤醒、应答、请求和再应答四个步骤,但是并不符合配送场景的要求。首先,骑手所在的场景,噪音很大,比如风噪、汽车噪音以及商场噪音等等,唤醒比较难实现。其次,需要四个步骤,还要考虑骑手的工作状态,这个操作过程太繁琐。

那怎么办?我们思考,是否能做到一套不需要唤醒的解决方案呢?答案很肯定,可以做!

第一点,我们的数据非常多。包括骑手、用户和商家,这些数据都是实时的,我们能够了解比骑手多得多的全局配送信息。第二点,我们能做到精准预测,利用机器学习、智能调度等技术,可以对骑手下一个操作场景进行识别。

举个例子,一个骑手身上可能有几个订单,他正在朝一个地方前进,通过场景分析,我们知道他要给具体哪个用户配送,而且我们能了解用户在这个楼里的几层,下来大概需要几分钟,所以能够推算出来,大概在哪个时间点提醒骑手打电话比较好。这样我们就可以省略唤醒和应答流程,直接给骑手发提醒,骑手只要回答是或否够可以了。这样设计才符合骑手线下的实际配送情况,能够真正给骑手解决实际问题,才能够真正称之为“智能”。

AI核心技术

具体技术分为几个主要的部分。第一个部分是基础设施,包括语音识别和语义理解,现在这方面开源的东西非常多,做通用的语音识别不是很难。

13基础设施

在我们场景中,要解决各种环境噪音的问题,可能骑手并没有说话,但旁边有些噪音,车的噪音或者别的噪音,甚至路上正在放一个歌,都会被识别为是骑手在说话,所以 VAD(静音检测)方面需要做很多工作。

另一个基本的组件是NLU,自然语言理解。举个例子,骑手要给尾号 6551打电话,首先系统要知道,骑手的意图是要打电话,后面要调起打电话的操作;其次要知道打电话的对象是谁,是用户,而不是商户,这就要找出用户信息;第三,要做检测,比如骑手已经送完某个订单,再打电话可能是错误操作,需要提醒骑手。

14精准场景识别

即时配送场景是一个典型的时间序列问题。从上面的图可以看出,场景包含前后关联,一个骑手历史的行为和决策会影响现在,同时现在的决策和行为会影响未来,这是个典型的时间序列问题。

场景识别要解决的两个主要目标,一个是事件预测,要知道下一时刻大概会发生什么事情,比如骑手是不是已到商家,商家是不是已经出餐;另一个是时机预测,未来要打电话,到底什么时候打更合适?

为了更好的说明,举个打电话的案例。

15识别案例

首先,要判断是否需要打电话,如果在不需要的场景也频繁提醒打电话,对骑手和用户都是骚扰。上图列举了不同地址类型下骑手打电话的比例,可以看到,像在企业和写字楼里面比例很高,但是住宅区就很低了,因为在住宅区,很大概率用户都是在家的。

其次,要针对每一个小区和楼宇类型,给一个合适的打电话时机,即提前多久打电话,对骑手和用户是最好的体验。打电话太早,用户在楼下等骑手,体验比较差。 打电话太晚,骑手在楼下等用户,效率太低。我们有精准的骑车轨迹数据,我们知道针对每一栋楼、每个小区,骑手在不同时刻打电话时会在楼下停留多久,所以可以画出一个曲线。合适的区间就在两条红线之间。

前两个主要是大数据分析,最后要实时决策,哪个订单,什么时刻需要打电话。这里就要根据骑手的实时数据了,包括订单状态、轨迹状态、环境情况等等,结合前面的大数据分析进行实时的预测骑手下一个配送地点和配送任务,并在合适的时机通过语音助手给出提醒。

具体到实现方面,场景识别需要三方面的技术:骑手轨迹挖掘、机器学习和数据挖掘。

16场景识别技术支撑

先介绍一下轨迹,我们每天能有几十亿次的定位数据,进而可以基于这些数据做很多事情。

17轨迹挖掘

第一,可以精准知道 A、B两点间最好的导航方式,相比第三方地图,可以挖掘到 A和 B间可能有可能有更好的骑行通过方式。

第二,光有轨迹数据还不够,我们还需要解决室内定位问题,室内 GPS定位已经不够用了,需要新的技术体系。比如 WiFi定位,同时还需要设计硬件,比如在商家部署硬件,判断骑手是否到店。

第三,传感器的使用,无论在室内还是在室内时候,我们不但要知道骑手的精准定位,还要知道运动方式,比如是停留、步行、骑行,是爬楼还是坐电梯,这些信息不但判断骑手在到底做什么。而且能够精细刻画配送难度,在定价和调度上非常有价值。

我们可以通过骑行轨迹来修正导航和定位。来看两个例子。

18修正结果

第一个例子(左侧)用户在下单时定位的分布,因为大家在室内下单,定位偏离是非常大的。但通过骑手轨迹的修正,实际上大概只有四个点,每个点可以认为是这个这栋楼的一个门口,这大幅提升了用户的定位精度,让骑手配送更容易。

第二个例子(右侧)通过骑手轨迹对 AB两个点的骑行路径进行修正,上图中轨迹分析发现了更短路径,穿过小区更节省时间;下图中,原地图导航要跨过中间过街天桥,但通过轨迹发现更多骑手是绕行通过,这才更符合真实的情况。

下面介绍一些机器学习相关技术,主要是应用在各种时间预估层面。

19精细预估

只有高精度的 ETA(预计到达时间)预估,这样才能更加准确的预测骑手行为,我们会做三个维度的精细预估,包括平面的配送时长、上下楼时长以及商家出餐时长。这样才能比较全面和精细的刻画骑手的配送过程。

为此,我们做了很多基础工作,比如实时特征平台,机器学习平台,包括深度学习在内模型等各种机器学习相关工作。同时我们还会做比较精细的配送知识图谱建设工作,比如精细化地址解析。

20精细挖掘

地址对配送来说是非常重要的信息,通过 NLP和地图搜索的方法,解析成层次结构,对分析商圈、楼宇维度的画像非常有帮助。我们把一个地址分解为四个层次,小区、楼号、单元号和楼层等。其中要解决很多实际问题,比如用户填写的信息完全不标准、存在歧义等问题。

做了这些工作之后,能实际产生的效果还是很有意思的。我们通过“上下楼时间”这个具体场景来进行分析。

21上下楼分析

第一张图,是不同楼宇的上下楼时长,左侧两个是厦门的两个楼宇的时间,右侧两个厦门平均值和全国的均值。可以看到,不同楼宇的上下楼时长还是存在很大差异,无法简单利用城市或者全国维度的均值进行替代。

第二张图,是不同楼层的上下楼时间,从 B2开始到 8楼。有个很有意思的是,上下楼时长与高度不是线性关系,大概在二楼、三楼和四楼时,相隔的时间很长,但是到了五楼、六楼、七楼,时间差就很小了。原因很简单,楼层较低时,骑手可能会选择爬楼。高层则选择乘电梯。不同楼层之间停留时间很短,越往上时间间隔越小。

第三张图,是不同城市的上下楼时长分布,最有意思的是黄色的线,也就是重庆的整体上下楼时长明显偏长。因为重庆是山城,房子经常在半山腰上,与平原比起来其上下楼的难度当然更大。

整体效果

上面整体介绍了语音助手依赖的场景识别技术,现在介绍一下语音助手的整体效果。首先语音助手提供了四个核心功能,包括定制耳机、语音交互、场景识别、智能引导等。

22四项核心

为什么要定制耳机呢?在骑手的使用环境中,需要克服很多噪音,很难通过软件和程序去做,而必须通过硬件去做。所以我们和厂商进行合作,定制去噪效果好的硬件。

23定制蓝牙耳机

第二个功能是语音交互,它可以在派单、查询、取餐、拨打电话等配送全流程中实现语音交互,骑手整个过程中不需要看手机,只要耳机提醒就可以完成智能配送。

24全流程语音

第三个是智能引导功能,包括安全驾驶提醒,信息播报,任务地图引导等,主要是让骑手行驶更加安全,提供全面的信息服务,让骑手配送更加方便和高效。

25全场景智能引导.

下图是智能语音在线下推广中的一些实际数据。

26语音助手效果

蓝色的线是使用语音助手的骑手的操作次数,绿色的线是不使用的操作次数。可以看到,操作次数明显下降。但是还没有降为 0,有两个原因:骑手在静止状态下,不需要使用语音助手;有些骑手的蓝牙耳机还没有下发到位。再来看下一张图:

27语音助手效果更安全

左图是骑手接单时间时长分布,越往右骑手接单的时间越长,用户体验越差。绿色的线就是之前骑手手动接单的一个分布,长尾情况比较严重,通过语音接单,接单时长明显向左侧靠拢,整体接单时长明显缩小,比较好的提升了用户体验。

右图是骑手在用户交付外卖所花费的时间的比例,横轴是骑手在楼下等待用户的时长,越往右,骑手在楼下等用户的时间越长。通过语音的提醒后,可以明显降低骑手长时间等待的情况,节省了大量骑手的时间。

写在最后

总结一下,语音识别和语音助手在实际落地过程中面临很多挑战,而且大多和场景有关系,场景识别非常重要,甚至比语音识别更为重要。

因为语音识别现在已经是比较通用的技术了,而且有很多专业厂商提供服务,硬件也是如此,进行定制化相对比较容易。因此目前做一个软硬件结合的语音助手,从基础技术来讲都不是问题,想做一个 DEMO并不会存在太大的技术障碍。

反而在具体的业务中,如何结合业务场景,把语音助手落地,才是我们需要真正考虑的。也就是说,如何将语音助手从“能用”做到“好用”,再做到让用户“愿意用”,这些才是未来语音助手面对的真正挑战。

语音识别和语音助手在实际落地过程中有很多挑战,而且和场景有关系,场景识别比较重要的,甚至比语音识别更为重要,因为语音识别现在已经是比较通用的技术了,如何结合业务场景,把语音助手落地、用好,可能是未来一段时间的挑战。

为了实现配送的全面智能化,美团点评在其中做了大量工作和尝试,这里不单单是要做好机器学习,还包括如何进行更好的实时运筹优化、实时空间数据挖掘以及人机交互等多个方面的技术内容。

作者简介

仁清,美团点评配送算法策略方向负责人。2016 年加入美团点评,负责美团配送业务的算法整体方向。包括智能调度系统,智能网络规划系统、机器学习平台、配送仿真平台等,全面支持美团专送、快送、跑腿等多个业务方向发展。加入美团点评前,曾任百度凤巢团队 T9 架构师,从事搜索广告 NLP、数据挖掘、检索技术方向研究。

在这个连开源标注数据集都没有的领域,AI该如何落地?

$
0
0

对于法律科技领域来说,2014 年元旦是一个重要分水岭。
 
这一天,最高人民法院《关于人民法院在互联网公布裁判文书的规定》生效实施。即日起, 全国四级法院的生效裁判文书, 除涉及国家秘密、个人隐私、未成年人违法犯罪等特殊情形外, 应当在生效后七日内统一上传至中国裁判文书网。
 
「我们承建了裁判文书网的后台。」北京法意科技有限公司常务副总经理陈浩告诉我们。据陈浩回忆,半年多时间,「大概到 2014 年下半年的时候,已经到了几百万量级。」
 
有了数据燃料,剩下的就是方法。

「14 年之后,好多新公司进来。至少,大家的共识是得有数据,没有数据,那个事情做不成。」如今比较活跃的法律 AI 创业公司,比如律品科技、无讼均成立于这一年。
 
两年后,中国裁判文书网已经成为全球最大裁判文书公开平台。数据显示,截至 2016 年 8 月 16 日,中国裁判文书网公开的裁判文书超过 2000 万篇,网站访问量突破 20 亿次。

更多公司开始试水 AI 领域。2016 年,法狗狗和深度好奇成立。一些大公司也开始尝试新技术:华宇设立了子公司华宇元典,而国双和上海百事通等也陆续开始探索人工智能在法律领域的可能性。
 
而作为中国裁判文书网承建商的法意科技,算是中国最早涉足法律数据和实证分析的科技公司之一。

「我们最早源于北京大学的一个科研课题。大家当时在研究法律法规跟案例的关系。裁判文书会引用法律,那么能不能通过案例文本找到被引用的具体法律内容?或者,通过法律条文找到对应案例?」

那还是 2001 年,陈浩正在北大读研究生。后来,由于研究需要更完整的法规数据库和案例数据库支撑,北大法意成立。2003 年,公司开始做数据库。

「那时候就是数据量少,没有公开那么多文书,我们也只能尽可能从各种正式渠道采集。我们一直坚持做数据库,当时也没有觉得最新的计算机技术对数据库的建设和应用有多大影响。」

 现在,完全是另一番景象。
 
2015 年以来,无论 Yann LeCun、Geoff Hinton 还是 Yoshua Bengio 都开始将关注点转移到自然语言。Yann LeCun 认为,NLP 是深度学习接下来要解决的重要问题,Geoffrey Hinton 则认为未来五年最令人兴奋的领域将是文本和视频理解。
 
而国内专业人士在接受我们专访时,也曾表示,「离钱比较近、数据比较丰富、知识结构梳理得比较好的领域」比较适合 NLP 的落地。
 
「比如,法律和医疗。它们是接近同构的两个领域,都有大量和用户交互的专家以及规范的领域知识。类似这类有富集的文本、领域知识、交互记录的领域,比较容易取得自然语言理解和相关任务的突破。」深度好奇 CEO 吕正东曾说。
 
然而,对于一家深耕法律数据和实证分析领域多年的传统公司来说,除了感受到这波人工智能浪潮带来的压力之外(「产品要更加精致」),同时也感受到了许多概念宣传带来的干扰,还发现了一些令人担忧的现象。陈浩多次表示「法意仍然对人工智能持相对保守的态度」,也反复强调了产品的精准度和行业生态建设等问题。
 
以下为采访实录,我们做了不变更原意的编辑。

我感觉现在行业内好多团队似乎对这个环节的重视程度不够,就是大前提和小前提的正确性。但实际上我感觉这是最关键的问题。

吴恩达说人工智能是电力,会给很多行业带来巨大变化。您怎么看近些年法律领域的 AI 热?
 
现在进入法律领域的资本比过去多很多,但没办法和医疗这样的领域比。
 
一方面,对人的价值不同。可能有人一辈子不打官司,但是一辈子进医院的次数就多了。另一方面,投资人的眼光也非常犀利。在人工智能技术落地的难度上,法律可能比医疗还难,因为它涉及价值判断。
 
医疗更多的是用感知技术解决诊断数据获取问题。在这些数据基础上,设定医学模型。但在法律领域,一拳打过去,这是故意伤害还是开玩笑?有很多价值判断在里面。即使用 NLP 分析发现两篇文档特别类似,可能就多了一两个字,但法律结论未必一样,还有可能严重不同。在计算机上实现这个,难度很大。
 
我们认为,人工智能,某种程度上来说是从几十年前传统的统计学发展下来的,只是现在统计方法有了新变化。有监督学习、无监督学习、半监督学习这些方法,几十年前就有了,只是具体算法不断演进了。
 
对应在法律领域内,学者们做研究讲的更多的是实证研究,实证研究用了很多不同的统计方法。在诸如 SPSS 之类的专业统计软件上会看到很多熟悉的机器学习算法。这些模型,有的可能早在 100 年前被研究出来了,一直沿用至今。
 
06 年讲深度学习,实际上只是在感知领域效果比较好。在认知领域,没有见到特别成熟的商业应用,至少在法律领域是这样。
 
从国外看,不管是英美还是大陆法系,类似的产品其实都很窄,解决的是法律领域里某一个更细分的问题,比如说破产。有个法国公司做了一个离婚模型,做完之后提供给公众服务,大家觉得非常好,好像产业就要变天了,但实际上这就是一个针对某个具体问题的具体模型,可能有商业化包装的成分在里面。

解决某个点的问题,还不能直接变革庞大的法律体系。当然,不是说这么做没用。像 IBM Watson,被一些专业团队用来做二次的垂直应用(比如 ROSS——微胖注),产生了一系列产品,验证后可能是成功的。这个应该值得大家去思考学习。
 
大的方向上,大家肯定是不会存在任何异议,但在具体推进和使用上,还是要有具体的问题意识。从具体问题出发的法律智能化服务路子,可能是对的,我们也在做这方面工作。

法意做了哪些相关的 AI 产品?
 
到底什么样的产品属于人工智能领域,其实不好说。
 
比如法律文书生成、合同的合规性审查、文书质量控制、法律风险分析、业务指引等,技术层次很多,不好说是不是都属于人工智能。只能说,计算机在各种模型和算法的支持下,可以输出很多法律服务成果。
 
08 年,我们研发了法律文书质量控制软件(「文书纠错系统」),对文书格式规范、表达规范比如语义逻辑、内容完整方面、上下文逻辑方面和法律依据引用等方面进行质量控制。现在,全国大概有 60% 的法院都在用这个服务。
 
比如,如果未成年人被判了 300 元罚金,这个软件就会提示错误。因为司法解释规定,未成年人犯罪被判处的罚金不得低于 500 元。这款产品也是通过算法、知识库支撑来实现的。光有知识库还不够,还要有算法库。
 
现在,我们在研究法律文书的法律核心问题的识别。
 
如果这种复杂又专业的文书来自最高人民法院,出自水平很高的法官,整个核心法律问题的识别,召回率能达到 75%-80% 之间。也就是说,100 篇法律文书,我们能发现 70 多篇文书的核心法律争议焦点。它的提准率,目前水平在 85% 以上。也就是说,发现 70 多个法律问题中,大概有 60 多个问题是精准的法律核心问题。

不过,面向全国法院的裁判文书后,针对类似的问题,现在的召回率大概只有 30% 多,提准率在 80% 多,提准率相对还是稳定的。
 
感觉法意的态度相对比较谨慎,对吧?

我们的态度一直比较保守。这么多年来,我们的基本经营理念都是坚持准确率指标。
 
这些指标要到什么水准,咱们才会认为结果可以接受,这种技术才能被商业化,否则就只是停留在实验室里的东西。我们不习惯对实验室阶段的技术做宣传。
 
目前市面上,有些团队在研发类案推送系统,甚至会提供倾向性结论。虽然给这种结论有点风险,但是作为给律师提供法律咨询服务的参考,以及法官作为参考不会不加甄别的接受软件提供的结果,所以,我们觉得这类产品还是很有应用价值的。
 
但是,如果把软件提供的法律结论直接提供给老百姓,确实会有很大的风险。

这么多年,我们也做了很多应用,我们对某些具体问题做了一些深入研究和应用,也出来一些具体结果。这些结果,得到过反复的验证。

 能举个例子吗?
 
09、10 年时,我们服务北京大学法学院白建军教授,就最高人民法院的量刑规范化做了一个实证研究的技术支持。
 
当时,最高院出了一个量刑指导意见(试行),作为法官量刑自由裁量权的细化指导。白老师想做个实证研究,看看全国一百多家法院试行指导意见之后量刑实践的实际规律是什么。
 
我们协助白老师做了分析框架模型的技术处理和数据处理。最高法院调了大概一百多家法院三年来的刑事判决书数据。就这三万多篇文书,按照白老师给的模型,对数据进行自动化处理——把所有判决书中记载人罪单位,全部结构化地提取出来。

我们结合了一些方法,目的就是实现高精度的结构化的数据输出。因为这种研究,最关键的就是精准度的问题。虽然大家说大数据追求模糊,不追求精确,但是,我觉得在法律领域内,精确性还是不可回避的一个问题,如果不准,这个结论不能作为决策依据。
 
高精度地将量刑数据提取出来后,白老师以此为基础做了一个研究报告,提交给了最高院。最高院相关负责人还是比较认可部分结论。
 
你看,量刑就是个非常具体的法律问题,要解决的问题也很具体-----整个模型数据的高精度的提取。问题要求的精确程度不同,相对的方法和算法也会有区别。
 
所以,我们坚持对类似这样的具体问题进行具体落地处理。然后,注重它的一些指标,主要是召回率和准确率。
 
不解决问题的刀不是好刀,还有可能是凶器是吧?我们还是希望能够提供特定场合下的高精度的东西给大家。
 

为了严格确保产品质量,还有什么需要特别注意的因素?
 
还有一点很重要,判断结论是 A 还是 B 的概率,是有具体的前提的,即影响或控制结论的前提(也就是三段论的大前提和小前提)的精准度。
 
这甚至是最重要的问题。但有时候可能会忽视了这个问题,都把焦点放在结论上。结论虽然很重要,但是之前支撑的环境变量和参数如果不准,结论等于没保障。所以,要有标准库或其他方法去验证这些大小前提的精准度。
 
比如,没小孩、有家暴,能不能离婚?你告诉他这种情况下,法院判离的概率是 60%。但事实上,判决离婚要考虑的因素不止这两个。还有很多其他因素,比如是不是自由恋爱?法官会考虑其他很多因素。但是,老百姓可能不会输入这个因素,因为他们不懂法律。在缺少这些因素的时候去做算法,结果就会似是而非。前提部分的精准度没有保障,后面就会出问题,甚至会得出截然相反的结论。

所以从技术实践角度来说,每个环节的精准度都要有一个有效的控制,肯定要采取经过反复验证的算法。
 
至于什么样的验证方法最好,没有统一的标准。最高法院也在组织课题研究这些问题。

在这个领域内,我们把基于规则、基于统计的方法结合在一起,它的效果就非常好。我们精度准确率的输出,基本上都是在 97% 以上。

法意有用到深度学习技术吗?
 
我们也有用到深度学习。之前给研究机构或甲方做的研究,为了控制垂直精准度,不会把太弹性的算法会往里加。弹性的算法(也就是基于统计的一些算法)精准度相对是偏低,但这种偏低的算法加入到你现在算法体系里,会提升算法的宽度。
 
比如说,临时有定制的需求,利用现有的成熟算法,两三天就可以训练出一套算法。但是,这套算法的可用性会有问题。现在我们给甲方做的东西都会严格控制精准度。比如裁判文书网。
 
但是,我们也没有太快拓展自己业务边界,还是有选择性的在做。我们的共识是,如果精准度可以达到我们预期,这个任务的风险是可控的。
 
深度学习技术主要用在哪些方面?

现在,我们对深度学习中的这些算法,会结合到知识图谱,比如知识规则的抽取,现在用的比较多。
 
另一个是文本分类。实际上,我们把它思路转化了一下,我们叫它文本的结构化。
 
比如做量刑模型,前提是需要高精度提取量刑情节。某个案件当中,张三犯盗窃、诈骗数罪,是盗窃了 5 万,还是诈骗了 5 万,需要精准提取这样一个文档描述中的数据结果。就这种文档的结构化提取而言,我们用了一些深度学习算法,也结合了一些传统的基于规则的模型做控制。通过评测,效果还不错。
 
文本结构化方面用的比较多。但是,用在作为所谓的规则提取,比如说未成年犯罪的罚金不得低于 500 元这种规则的提取,我们也在尝试着采用类似的技术来解决。
 
因为法律领域内的文档还是具有很强的领域性、行业特征和受控的特点,它的文本内容、结构和文本内容结构和语义后面蕴涵的信息体系,还是一个相对可控的,容易被结构化。和新闻稿相对开放的特点还是有很大的不同。
 
在这个领域内,我们把基于规则、基于统计的方法结合在一起,它的效果就非常好。我们精度准确率的输出,基本上都是在 97% 以上。

 达到这么一个精准率,需要多大的数据量?
 
跑取算法的基数,现在就是 3000 多万。08 年我们做的时候,从几十万开始到几百万,也是慢慢增长,慢慢添加的过程。
 
目前公司的产品研发是基于什么样的思路?
 
基本上还是根据客户的具体需求。一般是甲方提出要求,我们再结合自身技术储备和资源储备,看能不能做出这样的东西来。
 
比如,我们 08 年做的文书纠错系统,就是基于甲方的需求。当时最高法院的主管领导觉得法官在文书质量工作上投入的精力和时间太多了,希望借助技术手段减负,比如,对一些基本问题进行质量控制。
 
正好,我们在这个领域里也有不少基础性工作,有技术积累,就尝试着研发了这款产品的雏形,试用一段时间后,效果还挺好。后来我们发现,对法院裁判文书的质量管控来说,这个应用很有意义,就在满足最高法院需求的基础上,把它变成了一个现在全国范围内的大部分法院都采用的产品。
 
在我们看来,面向一个真的问题,我们做 IT 的才能发挥价值。和 2C 领域不同,在电子政务领域,这个意识特别重要。电子政务有时是基于一些政策,基于行业的一些发展需要而产生,这些需求有可能今年存在,明年可能不存在,波动性比较大。
 
这对产品的迭代不利吧?
 
确实不太利于技术迭代。应该说,这是所有涉足这个领域的法律 AI 公司都会都遇到的问题。

所以反过来,我们也会跟甲方反馈这些问题,持续稳定的研发投入,技术的成熟度才会不断接近用户的理想状态,生态会更良性一些。
 
但就目前来说,还是多参与行业内的一些信息化建设。要接触的多,你才能跟得多,也更清楚行业内建设的重点方向是什么。

 由此看来,法意的核心技术实力也是基于 B 端具体的产品需求逐步积累起来的吧?

是的。我们持续投入,都是基于目标任务。有经济产出也很重要,我们不是纯研发。

我们最早做数据库也是靠人整理。后来,就考虑能不能自动化,就文本里提取了一些东西,做算法来实现结构化抽取目标。因为当时需要整理的信息项比较少(比如法规名称、颁布机关、效力、法规文号等),就只提了一部分,这个时候,已经有算法的思想在里面了。
 
比如,当时做法规数据库还要处理法规效力变化,这是一个动态变化。每天往里面扔一百部法规,可能有一部会对历史库里的几百部法规产生影响,这里就需要有算法实时监测这些变化关联,包括法规之间、上位法和下位法之间、同位阶法条之间的关系。我们当时就用传统的算法来实现的。
 
03、04 年,我们做内部研发平台,将这些经验积累起来,也做了大量调研,想办法让客户搜索更精确。

我们一直清醒地认识到,法规数据库也好,案例数据库也好,提供的这种查询检索功能,一定要比较精准。所以,算法训练出来结果,在进行回归测试时,要有精度的控制。如果精度达不到,这个结果就不能用,否则会误导使用者。
 
从 07、08 年开始,我们遇到越来越多的实证研究统计分析需求,这些需求不再局限于过去简单的五六个字段,有的甚至达到了 4-500 个字段。只有足够丰富的角度去分析它,才能提供一些有价值的分析结论。
 
这些需求也成为我们技术升级的动力。我们发现标引规模太大了,传统的处理方式不够用,就慢慢引入了很多基于统计的算法。在传统的基于规则的方式,基础上增加了一些新的统计算法,结合在一起后,我们发现效果很好。这种方式精准度有保障,整个工作效率也有保障。
 
所以,从 03 年最初做数据库为基础,积累到 07,08 年,核心技术基本上比较成熟了。接下来就是基于应用不断去积累。

策划一款成功的法律 AI 产品的关键,主要还是在于用户需求,要解决的核心任务,将产品带入到场景中。

目前公司的数据库产品怎么收费?
 
我们的法规案例数据库,全国高校每年按服务费收取,几万元不等。全国法学院有法学院和有法律专业的,也就是 600 来家,全部加起来一年也就一千多万的市场规模。
 
考虑过设计面向其他用户群体的产品吗?
 
这么几年来,我们的基本精力主要放在政法机关,高校法学教育机构。这两个受众群体本身就从事法律业务和正在进行法律学习,对法律信息化需求比较刚性,也比较集中和稳定。
 
对于律师行业来说,还是要看要解决律所和律师的什么需求。如果是满足资源管控需求,那就是 ERP。EPR 本身是个好东西,意味着产业化、规模化和标准化。资源优化是一件好事,但恰好碰上律所这类人合组织,就很考验合伙人的管理文化了,看他们需不需要管控。
 
所以我们后来做了一段时间以后,发现这个领域的专业化标准化和规范化,确实还有很大波动,也比较难做,就暂停了这一块业务。
 
不过,律师领域还有一块业务领域,用智能化软件手段辅助律师进行业务处理。这肯定是一个可行的方向。但是,律师本身就是专业能力很强的一个群体,如果软件本身的智能化能力不是特别高,他们的需求也不会那么高。
 
老百姓这块儿市场呢?

 
至少在软件的整个能力没有达到一定高度时(不准、不是很靠谱)的时候,会有误导。再说,提供法律服务的公共渠道并不少。
 
我们现在在内部预演类似产品。尝试做了离婚,民间借贷,道路交通肇事等领域。比如,能不能解除婚姻关系,会给你一个结论。我们这个结论是基于一百多万离婚案件的裁判,不是我们通过规则设置的。不断增加判决书进行训练,结论就有可能会变,但它就是基于这个文本本身。
 
不过我们也一直坚持,如果这个产品精度不是很高,我们不会把它拿出来商用。

在您看来,策划一款成功的法律科技产品的关键是什么?
 
要更多地将智能化的产品带入到具体场景当中。
 
比如 ROSS。他们做非常垂直的领域,比如破产。用户输入情况,系统告诉你能不能去申请破产。将你输的情况,带到所有可以破产案件里,去做一个相似。最后我们会找到相似的案例,并且找到这些案例的结论。然后,我们的结论做一个验证和判断,最后我们给出最终的结论。
 
里面的算法很多,比如你要做相似性比较的算法,把相似东西找出来,只是代表了把相似的情况找出来,但是不代表这些相似情况的法律结论,是 A 还是 B 的时候,或者是有离散趋势的时候,怎么给受众一个相对明确的结论?
 
你可以告诉用户,相似情况中,有 10% 的时候不准破产,90% 的时候允许破产。但是,这个可能不是用户想要的答案。关键还是,用户需要的是一个明确的答案。
 
面向法官的产品,和面向老百姓的产品,解决的问题确实是不一样的。

老百姓没有专业的法律知识,他只管自己要输入自己想说的话,要系统给他一个终极性的结论。比如,离婚的问题。这婚能离吗?你就告诉她能还是不能,需要采用什么策略和手段。他们只是关心这个。

但法官不一样。他要考量案件的全面问题,具体到某个个案时,他可能会更关心偷录的录音证据是不是非法证据。
 
所以,主要还是在于用户需求,要解决的核心任务,将产品带入到场景中。

如果法院想让产业界的人提供好的人工智能的产品,就必须得有一套标准,有一套所谓的那种验证。

咱们法律垂直领域的 AI 研发到底有多花钱?
 
我们的算法,从 03、04 年开始做,一直到 07、08 年出了一个版本。它是一种引擎,一系列算法,一个支撑平台。这多年来,算法的积累一直没有停止。我们的这套算法都是基于应用产品的目标和任务去发展。如果今天又要研发一套新产品,产品中需要增加一些文本分析与理解的维度,我们就会去扩展这个算法。
 
06、07 年研发纠错软件时,之前那些积累就不提了,仅人工成本,前后就投入了 800 万左右。当时,我们是集中研发一款市场可以接受的版本,基于之前的技术积累,进行软件升级。当时的人工成本不比现在,800 万已经是很大一笔投入了。
 
但是,还可能出现这种情况——到最后,你的算法精度始终没办法达到商用水平。这时就会非常纠结了:前期投入那么多,再投进去有可能是无底洞,而且可能还无法评估效果,怎么办?做出来,有时候用到什么场景,也未必有把握。
 
算法,和传统做软件(写代码然后呈现功能),差别很大,本身就是一个很复杂的东西。

对于我们这种规模的公司来说,专注某个垂直领域,认真去做,也会有我们的收益。不过因为各方面原因,投入确实蛮大。
 
听说西方几个大数据库厂商在智能检索上,投入非常高。其中一个巨头会请多少年执业经历以上的律师在一座大山里封闭式做标注,安保措施级别也非常高。而且每年都得做。看来做 NLP 也很烧钱,NLP 和做图像识比起来,到底谁的成本投入更高?
 
自然语言理解比较高。自然语言理解这一块,至少得做语义做标注。比如,咱们法律要做标注,普通的高中生、大专生还不行。至少得大三的学生。人工标注都不准,没法做训练集。所以,得有大量法律职业者给你做这个标注。
 
之前采访过 LawGeex,他们和国内法律 AI 公司差不多,都靠自己的法律专业团队从事数据标记和系统训练。他们也感慨投入非常高昂。
 
单纯的工程师是肯定不够。对于对咱们法律人来说,从产品设计到最后落地,都需要有法律人全程配合。公司设立这方面的专业团队,才能实现垂直领域的高精度应用成效。生态面前,「人人平等。」现在请一些素质比较高的人进来,人工成本还是很高的。
 
我们当初做的时候,也遇到一样的难题。从零变成一百很容易,自己做也可以。数据量从一百变成一万,咱们这些人几乎就受不了这种重复性工作。从 1 万变成 10 万,靠人力已经有点不现实。从 10 万变成 20 万,30 万就更别提了。在这个过程中,我们也会涉及到请人去标注数据,然后让算法教算法,然后让算法变得更聪明。
 
从 03 年开始,我们大概用了一年多的时间把法规数据库做到接近 20 万部,把国内能收集到的法规全部收到数据库。全部都用计算机的算法拆解出来做,通过自动化的方式实现。用一年左右的时间做了个案例数据库。当时就做了这么两个数据库,都是纯粹用计算机来做的。
 
基于人工智能技术应用到法律领域的巨大投入, 需要国家有关部门组织力量, 构建一些应用指标, 如召回率、准确率等, 使得司法公开成果在公平正义的框架下辐射到各个群体。

除了刚才聊到的这些,您觉得目前产业环境中还有哪些不利于法律 AI 发展的因素?
 
缺乏 Benchmark。类似于 ImageNet(图像)、斯坦福 SQuAD(NLP)那样的数据集。不过标注这么大量的数据集太花钱,一般企业玩不起。
 
但我觉得检察院、法院还是有这个条件组织这个事情的。如果法院想让产业界的人提供好的人工智能的产品,就必须得有一套标准,有一套所谓的那种验证。验证也通过你的验证的产品,法院就放心可以用。
 
其实,这种核心技术是我们企业比较深层次的资产,所以我们不会太对外去宣传这样的东西。我们往往宣传效果,比如这个纠错软件的精准率能到 70% 到 80%。如果别的产品达不到我们这个水平,我的产品卖的贵一点,客户也舍得买。
 
如果精准率不达标,你可以去发学术文章,但不能应用于司法实践,因为司法实践可能会造成系统性的偏差。这是法律领域,不是其他什么娱乐领域。所以,我觉得大家还是要回归到问题的起点,还是几个指标的问题。

说白了,整个体系的设计是基于你的软件目标,这个软件目标怎么一层一层地倒推回来,最后下沉到基础算法。

最看好哪些竞争者?
 
有法律基因的公司,懂这个行业的。如果能坚持下来,未来应该说都发展前景都比较好。包括过去从事法律信息化建设的,也算是有法律基因。
 
主要判断标准,还是整个核心团队的核心负责人,他要有很深的法律背景的。现在从整个 IT 行业的发展的趋势来说,越来越黑箱化,就是说,开箱即用。我认为未来可能很有发展前景。
 
法意科技本来就专注于法律领域,现在外部提供了更多的工具,节省了自己的研发成本,现在直接把他们最好的算法拿过来用,并结合法意自主的核心技术结合在一起,形成符合应用指标的应用产品。
 
不过行业的竞争也在加剧,这促使我们必须加快它的这种核心竞争力,加快对外围技术能力的整合。这也是对法意最大的推动力。
 
带着深度学习技术回国的人才呢?
 
倒不是特别看好。全球几大的顶尖的会议, 每年都有好多论文在发表,每年的算法都在推陈出新,不同的研究者都宣称自己在某个点上精度做了什么突破。这些纯算法的这种发展,它是停不下来的。
 
现在这个深度学习的好多平台都越来越封装化,你接入 API 就行。至少 17 年,像腾讯,像百度都开放了 AI 平台,都是开放的,算法变成一个服务。
 
我提到好多其他做人工智能的技术公司,都在开放它的 AI 的平台。开放之后,他们还会把平台积累的一些成熟能力,封装成服务再开发。比如说对于语音识别。这个行业格局一下子又不一样。
 
好多做法律业务有场景的公司,就是利用 BAT 等行业内能够提供通用能力的平台,快速封装,战略合作,切入垂直领域,像用语音识别服务法院的公司就出来好几家。
 
既然算法都能封装成工具,大家都是一样的,那么核心竞争力变成了产品能力。
 
比如,用 LSTM 这种模型,它的参数是要调优的,参数怎么设?需要有法律背景的帮忙。这样,效果才会出得更快。有时候,沟通后发现不大可行,就得立刻终止这样一个方向。对素材更了解,才懂怎么调会更精准。
 
说白了,整个体系的设计是基于你的软件目标,这个软件目标怎么一层一层地倒推回来,最后下沉到基础算法。
 
有时候通过分析,你会发现它只需要解决一个问题,前面那些问题都是冠以整个法律业务场景框架设计的问题,这个前端问题处理好了,深度学习的压力就小。不同的设计方案,他对底层的深度学习算法的要求是不一样的。

 关键的问题还在于产品的设计。
 
这就是我比较注重法律基因的原因。我们通过产品的设计,有时候会回避一些这个有时候很难解决的问题,而不是纠缠于整个产品。
 
给一个深度学习的完整框架,然后你就扔你素材进来,系统给你一个答案,然后这中间你给我海量的文本大数据。我感觉,没有问题域的一个场景,深度学习还没有达到这样的水平。
 
另外,这里面还有一个很关键的原因。至少在法律领域,我觉得是需要我们去这个去辨别的。大数据它更注重解决相关,不注重解决因果。实际也反映了现在这种大数据技术能力,只是给你体现了数据的一个伴随性。

比如,你发现更多的男性,概率机会就要重一点,女性要轻一点。但是,这个东西可能并不是法官要考虑的这个东西。
 
不同法系,比如大陆法系和判例法系,对 AI 技术的采用会有很大影响吗?
 
国内的研究者没有明显发出这样的一个信号。但是,我看到介绍过来的国外文章认为,判例法系的国家,对于这种所谓的法律人工智能的认可度更高。大陆法系这样的成文法的国家,认可度相对低。
 
我理解的是这样的。AI,是通过特征相似性来输出结论。特征相似性,是基于大量案例描述而形成的一个集合体。判例法系,就是以案例的方式描述某个法律规则。每一个案例就像一张图片,告诉你什么是猫,什么是狗。
 
而成文法系中,法条一定要抽象,变成一个法律的规则,以此为基础进行审判,需要一个具体适用的过程。就从这个角度来说,我认为,在计算机理解上,制定法比判例法难度大。
 
你让计算机去理解一个抽象的法律规定,然后输入一个具体适用的判断,这很有难度。至少你要以文本描述实例的方式来表达一个游戏规则(这种数据对象),才能更容易被计算机理解和控制。计算机没办法理解人类的抽象思维。我们有时候理解法条都难理解,更何况电脑。

最前线 | 比亚迪首次官方回应:电池业务独立上市正在酝酿之中

$
0
0

文 | 高小倩  张嫣

关于比亚迪将拆分旗下电池业务的消息由来已久,而在公司发布了2017年全年财报后这一事情似乎有了实质的进展。3月29日,《经济观察报》报道,其记者获悉:汽车生产厂商比亚迪欲将旗下的动力电池和光伏板块进行拆分并进一步推动上市。

对此,比亚迪官方回应36氪,并确认此事:比亚迪从去年开始做零部件产业的市场化,首先在公司内部实行市场化战略,按照市场机制定价,形成利润中心,按照利润为中心激励团队做好。同时, 推动各个零部件进行分拆上市的计划,现在酝酿之中。相信未来几年,公司会根据业务的情况和政策法规环境推出零部件产业的市场化。

此外,比亚迪表示:去年包括电池等零部件市场化后,在与很多厂家在洽谈,现在在商讨中,未来会达成一系列的合作。

这意味着,目前处在电池行业老二位置的比亚迪将在更开放的体系内,与该领域的独角兽宁德时代展开竞争,以开启下一个千亿市场。

打破零部件封闭体系,寻利润新增长点

3月27日,比亚迪发布了2017年的业绩报告。虽然收入微增,但利润正在下滑。

数据显示,公司实现1059.15亿元的收入,同比增长2.36%。归属于上市公司股东的净利润为40.66亿元,同比下降19.51%。导致这一结果的原因有二:新能源补贴的下降;以及公司燃油汽车的销量同比下降24.62%。

第一季度预计新能源汽车销量与去年同期相比实现了近200%增长,但受新能源汽车补贴退坡影响,该业务尤其是电动大巴部分盈利能力正在下滑。公司将2018年第一季度的净利润预期调整为下降75.24%——91.75%。

尽管补贴下降、利润下滑是所有企业都面临的,但针对利润下滑这一问题,近年来比亚迪已经开始做出调整。在过去很长一段时间,比亚迪的零部件体系一直比较封闭。但由于电动汽车行业垂直整合红利开始下降,“每一颗螺丝钉都要自己做”的时代已经过去。

于是,比亚迪通过裁撤、合并事业部、放弃非核心零部自行生产等方式,比亚迪对零部件体系进行整合,以使供应链体系逐渐开放。比如座椅方面,去年,比亚迪通过与佛吉亚成立合资公司,实现了相关业务的剥离。

相比而言,电池业务则是比亚迪的下一个盈利增长点。

依靠电池起家的比亚迪曾多年担任全球充电电池生产商老大,镍镉电池、手机锂电池出货量全球第一2017年该业务收入同比增长19.37%,占总收入的比重为8.28%。

其实早在2017年5月10日,比亚迪董秘办就曾表示,目前这件事(拆分)还在探讨阶段,没有正式确定。但一位长期关注比亚迪、位于深圳某证券公司的分析师透露,动力电池业务拆分方案已经获得比亚迪高层通过,只等下一步公告。

不甘居第二,欲与宁德时代厮杀

在2016年时,比亚迪董事长王传福还表示:“暂不对外供电池。”但变化太快。比如,比亚迪刚刚丢掉了中国国内锂动力电池企业出货量第一的位置。在前年,宁德时代出货量还位居第二,但在2017年,这家企业就快速增长,大幅甩开了比亚迪。

虽然比亚迪的电池业务早于宁德时代,但它的封闭体系反而让后者迅速占领市场。宁德时代已为宝马、北汽新能源、吉利汽车、长安汽车、东风汽车等车企提供电池,还与上汽成立了合资公司。

另外,宁德时代不仅成为了新能源汽车领域的独角兽,而且还打算登陆资本市场。公司于3月12日更新招股书。数据显示,公司2017年实现营业收入199.97亿元,同比增长逾34%;实现净利润39.72亿元,同比增长31.4%。从营收来看,要远超比亚迪电池业务的营收,后者为87.67亿元。

科技部公布的独角兽

所以,比亚迪拆分电池业务并独立上市,有与宁德时代展开竞争的意图,同时也可视为是公司补回缺失的战略机会,而规模化也是大幅摊薄成本、分摊风险的手段。

据称,比亚迪已经就动力电池领域与长城、北汽、广汽等各大汽车主机厂进行业务对接。对此,资本市场认为比亚迪动力电池业务看点十足,一旦比亚迪成功实现对于动力电池业务的拆分和上市,比亚迪将开启一个新的千亿市场的业务,而动力电池业务所带来的对于比亚迪估值的提升也将成为又一利好。

此前,中国化学与物理电源行业协会秘书长刘彦龙表示:“比亚迪动力电池业务开放会在市场具有一定的竞争力,但是和整车厂合作还需要一定过程,从认证到产品开发至少需要两三年时间。”

据36氪了解,目前比亚迪的电池在内部已经出于供不应求的状态,其青海工厂即将扩大电池产能,达到8GWh,缓解这一情况。因此未来对外销售的电池可能在这一工厂生产。

初步诊断你的 GC

$
0
0

本文是好友阿飞写的,并且经过作者同意发的原创!
阿飞Javaer,转载请注明原创出处,谢谢!

前言

JVM的GC机制让Java程序员省去了自己垃圾回收的烦恼,大大提高了生产效率。但是正因为JVM垃圾回收机制足够优秀,导致很多Java程序员对JVM这个黑盒了解甚少,很多人没有去了解它,很多人也没机会去了解它。然而要想成为一名优秀的Java程序员,了解JVM和它的GC机制,写出JVM GC机制更喜欢的代码,是必须要掌握的一门技术;

这篇文章我主要说一下 如何初步诊断JVM的GC是否允许正常,重点讲解 诊断GC,而不是JVM基础和GC基础。所以看这篇文章,需要对JVM有一定的了解,比如常用的垃圾回收器,堆的模型以及分代等,如果你还对JVM一无所知,那么请先花点时间看一下周志明的<<深入理解Java虚拟机>>,重点关注" 第二部分 自动内存管理机制"。

GC概念纠正

对GC机制有一定了解的同学都知道,GC主要有YoungGC,OldGC,FullGC(还有G1中独有的Mixed GC,收集整个young区以及部分Old区,提及的概率相对少很多,本篇文章不打算讲解),在讲解如何判断这三种GC是否正常之前,先再次解释一下这三种GC,因为很多很多的同学对OldGC和FullGC有误解;

  • YoungGC:应该是最没有歧义的一种GC了,只是有些地方称之为 Minor GC,或者简称 YGC,都是没有问题的;

  • OldGC:截止Java发展到现在JDK9为止, 只单独回收Old区的只有CMS GC,且是CMS的 concurrent collection模式(CMS有两种模式,请参考寒泉子的文章JVM源码分析之SystemGC完全解读)。G1出来之前,CMS GC也是OLTP系统最常用的;而JDK8以前默认的垃圾回收器ParallelOldGC,在Old满后触发的是FullGC;

  • FullGC:有些地方称之为 Major GC,Major GC通常是跟FullGC是等价的,都是收集整个GC堆。但因为HotSpot VM发展了这么多年,外界对各种名词的解读已经完全混乱了,当有人说“Major GC”的时候一定要问清楚他想要指的是上面的FullGC还是OldGC(参考R大的Major GC和Full GC的区别)。对这个GC的误解最大,尤其最常用的ParNew+CMS组合,很多人误解FullGC可能是受到 jstat结果的影响。 如果配置了CMS垃圾回收器,那么jstat中的FGC并不表示就一定发生了FullGC,很有可能是发生了CMS GC而且每发生一次CMS GC,jstat中的FGC就会+2(因为CMS GC时初始化标记和重新标记都会STW,所以FGC的值会+2,可以通过让JVM按照预期GC提供的代码验证);事实上,FullGC的触发条件比较苛刻, 判断是否发生了FullGC最好通过GC日志,所以 强烈建议生产环境开启GC日志,它的价值远大于它对性能的影响;

FullGC触发条件

  • 没有配置 -XX:+DisableExplicitGC情况下System.gc()可能会触发FullGC;

  • Promotion failed;

  • concurrent mode failure;

  • Metaspace Space使用达到MaxMetaspace阈值;

  • 执行jmap -histo:live或者jmap -dump:live

说明:统计发现之前YGC的平均晋升大小比目前old gen剩余的空间大,触发CMS GC;Metaspace Space使用达到Metaspace阈值是触发CMS GC;

健康的GC

诊断GC的第一步,当然是知道你的JVM的GC是否正常。那么GC是否正常,首先就要看YoungGC,OldGC和FullGC是否正常;无论是定位YoungGC,OldGC,FullGC哪一种GC,判断其是否正常主要从两个维度: GC频率和STW时间;要得到这两个维度的值,我们需要知道JVM运行了多久,执行如下命令即可:

ps -p pid -o etime

运行结果参考,下面的运行结果表示这个JVM运行了24天16个小时37分35秒,如果JVM运行时间没有超过一天,执行结果是这样 "16:37:35"

[afei@ubuntu ~]$ ps -p11864-o etime    
   ELAPSED
24-16:37:35

那么怎样的GC频率和STW时间才算是正常呢?这里以我以前开发过的一个 读多写少的dubbo服务作为参考,该dubbo服务基本情况如下:

  • 日调用量1亿+次,接口平均响应时间6ms以内

  • 4个JVM

  • 每个JVM设置Xmx和Xms为4G,Xmn1G

  • 4核CPU&8G内存服务器

  • JDK7

  • AWS云虚拟机

GC情况如下图所示:

GC统计信息

根据这张图输出数据,可以得到如下一些信息:

  1. JVM运行总时间为6944534秒(day 243600+hour 3600+minutes60+second)

  2. YoungGC频率为4s/次(建议通过GC日志中两次YoungGC时间差计算得出)

  3. CMS GC频率为9天/次(FGC=18,即最多发生9次CMS GC,所以CMS GC频率为80/9≈9天/次)

  4. 每次YoungGC的时间为6ms(通过YGCT/YGC计算得出)

  5. FullGC几乎没有(JVM总计运行80天,FGC才18,即使是18次FullGC,FullGC频率也才4.5天/次,更何况实际上FGC=18肯定包含了若干次CMS GC)

根据上面的GC情况,给个 可参考的健康的GC状况

  1. YoungGC频率5秒/次;

  2. CMS GC频率不超过1天/次;

  3. 每次YoungGC的时间不超过30ms;

  4. FullGC频率尽可能完全杜绝;

说明:G1&CMS时,FullGC回收算法会退化成Serial+SerialOld,即单线程串行回收,且完全STW,影响很大且STW时间完全不可预估,所以FullGC频率尽可能完全杜绝。另外, 可参考的健康的GC状况这里只是参考,不是绝对,不能说这个GC状况有多好,起码横向对比业务规模,以及服务器规格,你的GC状况不能与上面的dubbo服务有明显的差距;

了解GC健康时候的样子,那么接下来把脉你的JVM GC,一一讲解YoungGC,OldGC,FullGC。看看是有疾在腠理,还是在肌肤,还是在肠胃,甚至已经在骨髓病入膏肓了;

YoungGC

YoungGC是最频繁发生的,发生的概率是OldGC和FullGC的的10倍,100倍,甚至1000倍。同时YoungGC的问题也是最难定位的。这里给出YoungGC定位三板斧(都是踩过坑):

  1. 查看服务器SWAP&IO情况,如果服务器发生SWAP,会严重拖慢GC效率,导致STW时间异常长,拉长接口响应时间,从而影响用户体验(推荐神器 sar,yum install sysstat即可,想了解该命令,请搜索" linux sar");

  2. 查看StringTable情况(请参考探索StringTable提升YGC性能)

  3. 排查每次YoungGC后幸存对象大小(JVM模型基于分配的对象朝生夕死的假设设计,如果每次YoungGC后幸存对象较大,可能存在问题)

  4. 未完待续……(可以在留言中分享你的IDEA)

排查每次YoungGC后幸存对象大小可通过GC日志中发生YoungGC的日志计算得出:
例如下面两行GC日志,黑色加粗部分,第二次YoungGC相比第一次YoungGC,整个Heap并没有增长(都是647K),说明回收效果非常理想:
2017-11-28T10:22:57.332+0800: [GC (Allocation Failure) 2017-11-28T10:22:57.332+0800: [ParNew: 7974K->0K(9216K), 0.0016636 secs]  7974K->647K(19456K), 0.0016865 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
2017-11-28T10:22:57.334+0800: [GC (Allocation Failure) 2017-11-28T10:22:57.334+0800: [ParNew: 7318K->0K(9216K), 0.0002355 secs]  7965K->647K(19456K), 0.0002742 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
再看下面两行GC日志,黑色加粗部分,第二次YoungGC相比第一次YoungGC,整个Heap从2707K增长到了4743K,说明回收效果一般:
2017-11-28T10:26:41.890+0800: [GC (Allocation Failure) 2017-11-28T10:26:41.890+0800: [ParNew: 7783K->657K(9216K), 0.0013021 secs]  7783K->2707K(19456K), 0.0013416 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
2017-11-28T10:26:41.892+0800: [GC (Allocation Failure) 2017-11-28T10:26:41.892+0800: [ParNew: 7982K->0K(9216K), 0.0018354 secs]  10032K->4743K(19456K), 0.0018536 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

可参考的健康的GC状况给出建议YoungGC频率5秒/次,经验值3秒~6秒/次都是比较合理的YoungGC频率;

  • 如果YoungGC频率远高于这个值,例如20秒/次,30秒/次,甚至60秒/次,这种情况下,JVM相当空闲,处于基本上无事可做的状态。建议缩容,减少服务器浪费;

  • 如果YoungGC频率远低于这个值,例如1秒/次,甚至1秒/好多次,这种情况下,JVM相当繁忙,建议follow如下步骤进行初步症断:

  1. 检查Young区,Young区在整个堆占比在25%~40%比较合理,如果Young区太小,建议扩大Xmn。

  2. 检查SurvivorRatio,保持默认值8即可,Eden:S0:S1=8:1:1是一个比较合理的值;

OldGC

上面已经提及:到目前为止HotSpot JVM虚拟机 只单独回收Old区的只有CMS GC。触发CMS GC条件比较简单,JVM有一个线程定时扫描Old区,时间间隔可以通过参数 -XX:CMSWaitDuration=2000设置(默认就是2s),如果发现Old区占比超过参数 -XX:CMSInitiatingOccupancyFraction=75设定值(CMS条件下默认为68%),就会触发CMS GC。建议搭配 -XX:+UseCMSInitiatingOccupancyOnly参数使用,简化CMS GC触发条件, 只有在Old区占比满足条件的情况下才触发CMS GC;

可参考的健康的GC状况给出建议CMS GC频率不超过1天/次,如果CMS GC频率1天发生数次,甚至上10次,说明你的GC情况病的不轻了,建议follow如下步骤进行初步症断:

  1. 检查Young区与Old区比值,尽量留60%以上的堆空间给Old区;

  2. 通过jstat查看每次YoungGC后晋升到Old区对象占比,如果发现每次YoungGC后Old区涨好几个百分点,甚至上10个点,说明有大对象,建议dump( jmap -dump:format=b,file=app.bin pid)后用MAT分析;

  3. 如果不停的CMS GC,Old区降不下去,建议先执行 jmap -histo pid | head -n20 查看TOP20对象分布,如果除了 [B和[C,即byte[]和char[],还有其他占比较大的实例,如下图所示中TOP1的Object数组,也可通过dump后用MAT分析问题;

  4. 如果TOP20对象中有 StandartSession对象,排查你的业务代码中有没有显示使用 HttpSession,例如 String id = request.getSession().getId();,一般的OLTP系统几乎不会使用 HttpSession,且 HttpSession的的生命周期很长,会加快Old区增长速度;

异常的大对象.png

FullGC

  • 如果配置CMS,由于CMS采用标记清理算法,会有内存碎片的问题,推荐配置一个查看内存碎片程度的JVM参数PrintFLSStatistics。

  • 如果配置ParallelOldGC,那么每次Old区满后,会触发FullGC,如果FullGC频率过高,也可以通过上面 OldGC段落提及的排查方法;

  • 如果没有配置 -XX:+DisableExplicitGC,即没有屏蔽 System.gc()触发FullGC,那么可以通过排查GC日志中有System字样判断是否System.gc()触发(日志样本: 558082.666: [Full GC (System) [PSYoungGen: 368K->0K(42112K)] [PSOldGen: 36485K->32282K(87424K)] 36853K->32282K(129536K) [PSPermGen: 34270K->34252K(196608K)], 0.2997530 secs] );或者通过 jstat -gccause pid 2s pid判定, LGCC表示最近一次GC原因,如果为"System.gc",表示由System.gc()触发, GCC表示当前GC原因,如果当前没有GC,那么就是No GC:

[afei@aliyun~]$ jstat -gccause236062s5    
 S0    S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT    LGCC                 GCC                
 0.00100.00 37.50 83.17 93.31 84.35 5597 24.116   0   0.000 24.116G1 Evacuation Pause  No GC              
 0.00100.00 37.50 83.17 93.31 84.35 5597 24.116   0   0.000 24.116G1 Evacuation Pause  No GC              
 0.00100.00 37.50 83.17 93.31 84.35 5597 24.116   0   0.000 24.116G1 Evacuation Pause  No GC              
 0.00100.00 37.50 83.17 93.31 84.35 5597 24.116   0   0.000 24.116G1 Evacuation Pause  No GC              
 0.00100.00 37.50 83.17 93.31 84.35 5597 24.116   0   0.000 24.116G1 Evacuation Pause  No GC
System.gc引起的FullGC.png



如果读完觉得有收获的话,欢迎点赞、关注、加公众号【匠心零度】,查阅更多精彩历史!!!


深度 | 区块链 到底应该怎样玩?

$
0
0

 

钟家鸣(Jimmy Zhong),IOS基金会创始人。

IOS,即Internet Of Services,旨在开发高TPS、高可拓展性和安全的区块链基础设施,为互联网服务商提供最坚实的土壤。

 

2018年3月27日,人民创投区块链频道与行业垂直媒体31区联合主办的「 链·未来,2018春季区块链技术论坛」在人民日报新媒体大楼举办,与会人士通过主题演讲和圆桌论坛等形式,对区块链行业中所存在的问题和机遇进行了深入探讨。

 

笔者有幸参与了这次活动,其中钟先生的演讲干货满满、亮点频出, 对区块链项目落地有很强的指导意义,特整理出来,以飨读者。

 

演讲正文

 

刚才 (指之前的演讲) 很多人讲了为什么区块链是一项好技术,也简单聊了区块链行业,今天稍微给大家泼一点冷水:「 好像除了比特币之外没有看到什么应用」。

 

接下来,我就简单给大家讲一下,「 区块链行业遇到的一些问题」以及「 为什么到现在还没有产生比较好的应用」。

 

主要讲四点。

 

一、现在的技术应用和实际现状

二、扩容问题带来的冲突

三、现有的解决方案和代价

四、行业未来的发展方向

 

一、现在的技术应用和实际现状

 

目前,区块链创业一共两个方向,我们用比较简单的语言描述一下。

 

一是、做底层。 用“传统世界”的语言来比喻,就像 iOS 和 Android ,可以为其他开发者提供一个平台。

 

二是、做应用。 假设区块链是一个操作系统,有人在上面开发微信,有人开发淘宝,我们把这类产品叫做基于区块链的应用。

 

这是目前比较热门的两个方向。

 

先讲两个比较适合于“区块链化”的应用场景。

 

一、虚拟货币的交易所。

 

大家可能听说过,Coincheck,5亿美金被偷了。这里体现了一个问题, 交易所有非常大的安全隐患。

 

你的以太坊、虚拟货币放到这里以后就是把钱交给了别人。这个交易所可能有冷钱包,热钱包,你把一切都交给它,就像把钱存在私人银行,他们有一天说不好意思,我们着火了,什么都没了。

 

你没有任何办法 ,中心化就是如此。

 

很多人说既然这样,以后我们搞一个去中心化的交易所,你的币在你的钱包里,我的在我的钱包里,我们想交换就自己交换。

 

想法很不错。

 

交易所,听起来是很适合「区块链化」的行业。

 

二、在线广告。

 

可能在座的诸位也有在Facebook或百度投放过广告,理论上讲,他们的广告是很容易作弊的。

 

你把广告投放给Facebook,他可能会有按照点击量收费之类的规则,看似很规矩对吧。但大家如果稍微懂点技术就知道,Facebook可以随意修改你存在他服务器上的任何数据,当然我并不是说Facebook真的这样做,只是打个比方。

 

现在,我们假设把这两个行业「区块链」化,比如我们把交易所的交易数据使用区块链存储。我们把广告的每一次观看和点击也全部放在区块链,不可篡改,童叟无欺。

 

听起来很完美是不是?

 

但是为什么这两个行业没有做起来?这就要说到区块链本身存在的瓶颈了。

 

二、扩容问题带来的冲突

 

扩容问题。

 

想支持一个交易所,即便这个行业内一般的交易所,交易量也到了2000到5000笔每秒,而大一点的交易所基本上万。

 

在线广告的数据量更大,如果是跟踪点击量每秒钟 是 十万或者百万的量级。

 

反观以太坊,目前仅支持20笔交易每秒,姑且不说手续费,仅此一项就是很大的问题。

 

我有时候会想,大家现在把区块链描述得很美好,有点像两年前或者三年前大家去描述虚拟现实的时候。

 

那时候VR、AR很热,出了一大票公司。

 

很多人讲,以后你们都不用工作上班了,在家躺着,想干什么干什么,想当谁当谁。

 

 

你以为是这样的效果,其实戴上以后没两分钟就要吐了。 很多事情听起来很好,实际上技术上遇到很大的难题,不是那么容易改造。

 

扩容真的是非常严重的问题。

 

很多时候大家觉得交易慢是因为矿机不够多,程序写得不够好, 然而事实并不是这样。

 

扩容问题真的是非常难解决的问题,每次“解决”扩容问题都会带来 行业 很大的牺牲。

 

这里我讲一个概念, 三角冲突,即 去中心化一致性扩展性的冲突。看完你就明白为什么扩容问题这么难以解决。

 

 

扩展性

 

这个非常好理解,上面最开始Planetary scale,是扩展性,高负载。

 

扩展的特性,理论上讲,是你希望节点越多,扩容性越强,而不是受到限制。另外还有延时问题,大家都知道比特币六个交易才能确认的特性,每笔交易要等60分钟。

 

一秒钟20个交易不行,我们要变成2000或20000。

一小时确认交易不行,我们要一秒钟确认。

 

一致性

 

这个需要大家稍微理解一下,一致性共有三种。

 

先讲什么叫 完全一致

 

完全一致就是现在以太坊和比特币的做法,所有的节点,所有的矿机,在同一时间点,它们存储的数据是严格一致的。

 

打个比方,假设全班有一百个人,我们做一道数学题。虽然各做各的,但是卷子收上来了,我们有一个同步答案的过程,这就是强一致性。

 

完全不一致,就是我们全班一百个人,连做的题都不一样,就是完全不一致。

 

弱一致,就是虽然短时间内不一致,一万个节点可能有五千个不一致,但是会提供一些算法,在某些情况下同步。

 

去中心化

 

中心化也有三种,分为 完全中心化半中心化以及 去中心化

 

在这个行业,对于以太坊来说也好,对其它基础设施也好,我们定义 完全的中心化就是一台服务器或者一个公司掌握所有的事情。

 

比如Facebook有自己的服务器集群,因此它可以完全控制所有的事情,还是可以到数据库把广告从一百次改成一万次。

 

半中心化,就是没有一个个体可以严格地控制所有的事情。

 

假如我是Facebook,我不再能直接去一个数据库里面改数据,而是需要跟别人商量,任何人都可以去写,去读。

 

我们讲一个比较火的例子:EOS,21个超级节点和其它小节点,它没有完全去中心化,但是只要超级节点们达成一致,这个系统依然可以运行。

 

还是举例全班一百个人,原来是老师说答案是一就是一,现在我们分成十组,各自有自己的答案,最终达成一致的就是正确答案。

 

完全的去中心化就类似于以太坊。

 

虽然它一定程度上会有矿主的垄断地位,但在理论上任何人都可以加入作为一个节点。

 

也就是说你明天想成为一个以太坊公司很简单,你可以直接在电脑上跑一个以太坊节点,你可能不会掌握很大的算力,可能很慢,但没人能阻止你这样做。

 

任何人都有能力加入这样的节点,而不是像EOS那样需要购买很多算力,否则你没有资格成为超级节点。

 

理解了这个三角的基本概念,我们接着讲一下, 为什么不能三者兼备?为什么不能又去中心化,又快?

 

很多原因。

 

我们讲一个 最简单的因素就是 网络带宽因素,这是非常现实的因素。

 

比特币每笔交易是500左右的字节,假设每秒1万笔交易,什么概念呢?500字节乘以10000,每秒钟要下载5兆的东西。

 

如果这个可以达到,那么如果每秒10万笔交易,使用能满足这个需求的理论带宽 需要400兆 ,你下载一个1GB的电影只需要20秒,这还是最理想的情况。

 

由于区块网络并不是一直平稳的状态,有时候你理论上需要400兆的网络带宽,但实际可能需要数倍于此。

 

假设以太坊支持每秒1万笔交易,你可能连网速都跟不上,更不要提别的东西了。

 

这就是为什么很难要求一个完全去中心化的区块链网络,在保证数据一致性的情况下支持高吞吐量,因为你要同步所有数据!

 

所以,你要么选择高度去中心化,像以太坊一样每个人都可以成为节点。要么高扩展性,只要网络带宽达标的超级节点。

 

你先去阿里云买一个2000万一个月的服务器,什么东西都能跑,你可以当超级节点,我们通过超级节点可以满足很多扩容需求,但是牺牲了很多去中心化的因素。

 

接下来我们聊一下现有针对扩容问题的解决方案,就是一句话, 有付出才有回报,没有什么是完美的。

 

三、现有的解决方案和代价

 

目前比较流行的解决方案,首先就要数 超级节点,这是最直观的解决方案。

 

超级节点对算力的要求不高,能正常处理链上的交易就够了。但其对网络的性能很高,每秒可能会达到百万级别的处理能力,普通的计算机根本不可能作为节点,需要一个内存达到几百G甚至更高配的机器,而且未来也只会越来越高。

 

还有一种方式叫做 划分网络。这里有两个技术,一个是 DAG(Directed acyclic graph,有向无循环图) , Shardin(分片技术) 。

 

关于分片技术,举个例子,比如说我们全班一百个人, 必须每个人都要看一遍题目,然后表态。

 

这个过程很麻烦,很可能有人缺勤、有人打牌、有人打游戏。现在把全班100个人随机分成4个组,每个组25个人,只要确保分组的过程足够随机,这个组不停地换,就能保证一定的安全性。

 

还有DAG,现在这种方案非常火,它是计算机领域一个常用的数据结构,因为独特的拓扑结构所带来的一些特性,经常被用到处理动态规划,导航中寻求最短路径、数据压缩等场景中。

 

 

Ext社区提出的DAG of blocks

 

DAG 本身跟 Shardin 的方法很不一样。还是用全班做题来打比方,原来是这一道题必须全班一百个人都看一遍,现在只需要我左右两个人验证一遍就可以了。

 

这里就有一致性的问题,因为很多节点在同一时刻是不一致的。

 

举个例子,一个智能合约可能有五个变量,有的节点觉得变量A是5,有的节点觉得 变量 A是8,还没同步完成。

 

如果你想做智能合约,那么需要再为DAG量身定制一个。

 

所以没有完美的解决方案。

 

看到这里,你或许会问, 这不是死局,无解了吗?

 

不是的。

 

还是回到最初的那两个行业: 交易所在线广告

 

去中心化的交易所最核心的需求是什么?

 

安全。 因为你在转移自己的资产,你不希望你的资产出错。

 

对于一个去中心化交易所来说,可能你每一万笔交易错一笔都是不能忍受的。有这样的安全隐患是不能忍受的。

 

而对于在线广告来说,这可能就是可以忍受的,比如说Facebook广告原来播放一万次,现在播放9999次,多付一、两分钱无关紧要。

 

但 在线广告对扩容性要求就非常 非常 之高。

 

所以答案是, 我们可以针对不同的应用场景,在拓展性、去中心化、一致性上作出必要的取舍。

 

四、行业未来的发展方向

 

接下来我们讲一下,区块链的未来发展和分布。

 

诚然,在计算机领域,解决方案是比较统一的。 比如说有Windows、macOS、Linux等等,本质上是被一些巨头垄断了。再比如手机端,除了 iOS 和 Android 其他的系统也没人用了。

 

但我不认为区块链未来会像这些一样,除了以太坊就没了。

 

各个行业有不同的取舍,可能你做一个A系统,它吞吐量极高,可去中心化较差。或者系统B,它很安全,很去中心化,但可能不适合开发应用。

 

所以未来的区块链基础设施领域,不太可能形成单一的寡头。

 

谢谢大家。

 

本文整理自钟家鸣演讲,并作了适当补充、拓展,未经本人确认。责任编辑 托尼托尼·98(fengyutanjun)。

 

- END -

MORE | 更多精彩文章

 

 

合作请加微信:bangcbd

推荐邦哥的好朋友“毒舌科技”, ID:dushekeji

更多最新信息下载创业邦app

Viewing all 15896 articles
Browse latest View live