Tag Archives: 数据挖掘

Cookie、RTB、大数据、逻辑回归和文艺复兴技术公司

  3.15晚会,DSP几乎全军覆没,Cookie这个词热起来,话题也涉及到RTB和大数据产业。好多人问,啥叫RTB?啥叫DSP?

  最近我们算法平台正在应用于在线广告业务,因此写篇BLOG介绍点RTB领域的业务常识和八卦。后面的所有内容,都源于网上已公开的信息。

  对于Cookie技术,网上已有很多解释,就不再详述了。总之,如果网站设计规范,即使第三方在投放广告位里放置代码,也只能操作它自己的Cookie,不可能读写宿主站的Cookie并获得登录密码和个人信息。

  Cookie的一个常见用途就是收集用户历史行为,用于个性化推荐。比如豆瓣网很受欢迎,因为它的算法能根据每个人的历史数据,向我们推荐可能感兴趣的书、电影、音乐。

  更热门的应用就是精准投放广告,例如这两年很受关注的RTB。典型的RTB流程如下:

  1、张三点击网页“尿布大全”(往往正是通过Cookie识别出访问者是张三);
  2、该网页某广告位向广告平台请求:张三来了,需要合适的广告;
  3、广告平台向DMP发出请求:张三啥情况?
  4、DMP回复广告平台:张三是个美食家,他有个1岁的宝宝;
  5、广告平台向所有DSP公告:这里有个“吃货”&“孩他爸”、在浏览“尿布大全”、谁投放广告?
  6、DSP根据信息(如广告位置、“尿布大全”、 “吃货”&“孩他爸”等)决定是否出价,出价多少;
  7、广告平台决定出价高的DSP投放广告。

  所有交互计算要在Web页面返回给用户前的100毫秒内完成,对参与各方的技术要求很高。这个流程中DMP扮演着重要角色,它负责提供访问者的消费特点,这里就需要预先进行数据挖掘。注意,规范情况下,广告平台不应该向DSP透露张三的身份。

  在线广告行业,预测用户点击率(CRT)是一个核心问题。问题的输入往往需要上百万维特征。Google、Facebook早期都试图引入高维建模算法,但最后殊途同归都用的是逻辑回归算法。这是和逻辑回归算法本身的很多特点有关的,例如:

  1、变量范围是[-∞ ,+∞];同时和其他“广义线性回归”相比,值域是[0,1],因此形式上类似一个概率函数,适合分类问题;
  2、基本上可看作一个单层的人工神经网络,所有训练人工神经网络的训练方法都适用;
  3、可扩展性好,适合海量的特征当特征数目超过百万时,利用训练最大熵模型的IIS方法可直接用于训练逻辑回归;
  4、online learning,能够进行增量学习;
  5、线性模型,在金融信用领域,往往利用可解释的特点给出评分卡信息。Google内部也要求“所有效果变化可解释”。

  最大熵的建模计算量很大。面对上百万列特征、上百亿行记录的海量数据,如何通过分布式集群快速训练模型,就成了关键性问题。在这个领域最早取得技术突破的是Della Pietra兄弟。这两个人后来退出学术界,加入了传说中的华尔街赚钱机器:文艺复兴技术公司 (Renaissance Technologies)。

  文艺复兴科技公司的创始人是James Simons。他早年是顶尖数学家,提出了著名的Chern-Simons定理,1976年获得数学界的皇冠——维布伦奖(Veblen)。 1982年,Simons投身金融领域,雇佣大量毫无金融背景的数学家和物理学家,开发算法模型,对股票和期货进行自动交易。文艺复兴科技公司管理的大奖章基金从1989到2007年间的平均年收益率高达35%,超过了巴菲特。

  关于James Simons和文艺复兴技术公司的事,我在知乎上回答过一个相关的问题。

推荐系统业务调研

  来还前两天的债了。后面是推荐系统的业务调研。

  粘帖之前先说点八卦话题。最早知道数据挖掘和“尿布与啤酒”,是大一在贺仲雄老师那门妙趣横生的选秀课上,至今历历在目。包括后来两个月为了写那篇软件工程的论文,每天跑去图书馆查的资料,每一份内容都记得好清楚。再往后的三年,课堂上再也找不到那种感觉了,枯燥乏味死记硬背。最好玩的是,为了应付几门不同的选修课考试,连续三个学期,三次把“关联规则分析”和“梯度下降法”等算法的步骤背得贼熟,考完又很快忘掉。

  工作之后,进入生物信息领域,视角逐渐小众。认识xVector还是因为去贝塔沙龙听技术讲座,粗心记错时间了,幸运地碰到了Resys线下聚会。此后就成了xVector的粉丝,只要他的公开讲座,就尽量去听。最近一次就是今年在上海的第二届中国推荐系统大会。后面这份调研笔记的内容,大部分都是从他的书《推荐系统实践》里抄来的。

推荐系统实践

  今年连续参加了很多次数据处理的讲座,讨论。这份文档也算结果之一吧。

==============我是分割线,以上为无用的八卦内容===============

推荐系统业务调研

一、修改历史

  略……

二、简介

  随着ODPS系统被深入应用,在数仓团队以外,各个公司的BI团队也逐渐成为我们的用户。ODPS面临的需求也就逐渐拓展到数据挖掘领域。而推荐系统和个性化算法正是目前BI团队最典型的业务。

  本文对推荐系统的领域现状、典型算法、业务流程进行梳理。这份调研不是学术性的论文、算法、专利的全面列举,而是站在产品和业务的立场进行分析,对经典的工业界常用算法进行介绍,如果涉及Big Data场景会重点关注和讨论。

  涉及信息主要源于公开的网络、杂志、书籍和技术讲座。其中涉及淘宝推荐系统的涉密内容已删除,剩下的内容都可以在公网搜索到。

  转载,请保留原作者http://wangleheng.net链接。

三、背景和应用案例

  产品太多的情况下,用户面临信息过载,解决这个问题的方案包括分类目录、搜索引擎和推荐系统。前两种方案中用户知道自己想要什么,而推荐系统则更加主动。

  推荐系统通过挖掘用户的各种数据,找到其个性化的需求,将长尾商品推荐给需要它的用户,帮助用户发现那些感兴趣但很难发现的商品。目前已经投入工业实用的知名推荐系统包括:

业务领域

著名产品名称

网址

国内类似产品

电子商务

亚马逊图书推荐

www.amazon.com

豆瓣读书

电影视频

Netflix视频推荐

www.netflix.com

暴风影音、(hulu)

个性化音乐

Pandora和Last.fm

www.pandora.com

www.Last.fm

豆瓣电台

社交网络偏好推荐

Facebook Instant Personalization

facebook.com/instantpersonalization

新浪微博

个性化阅读

Google Reader

Digg 新闻排序

www.google.com/reader

www.digg.com

百度新闻猜您喜欢

LBS

Foursquare客户端

foursquare.com/apps

大众点评客户端

个性化邮件

Gmail优先收件

gmail.com

 

定向广告投放

Facebook 目标投放

facebook.com->
creat a Ad

 

  推荐系统的评价依赖于各种指标:用户满意度、预测准确度、覆盖率、多样性、新颖性、惊喜度。要测量这些指标,有些可以采用离线计算方式,有些则必须采用A/B对照组在线实验。真正的工业化实践中,往往是在诸多指标中寻求平衡,并记录业务效果,所以最终的衡量标准往往还得看点击率和转化率。

四、针对各种业务数据类型的经典算法方案

4.1. 利用用户浏览、购买、评价的记录数据

  基于用户行为的应用,最典型的就是各种排行榜,例如淘宝指数。

  早期数据挖掘领域最经典方法是基于销售数据的关联规则发现,一个被反复提起的行业故事是“尿布和啤酒”的故事。这个阶段,数据挖掘算法的主要业务客户来自于金融、电信、零售,这些行业才有条件和动力收集自己的业务数据。

  而进入互联网时代,协同过滤等算法成为主流算法。这种方法的基础是网站记录下来的用户行为数据。和前面提到“尿布啤酒”案例中的数据相比,互联网应用除了记录下产品的销售数据以外,还拥有每个用户(账号或客户端)的独立行为数据,这样就可以进一步针对每个用户进行个性化推荐。

  目前工业界最常用的协同过滤算法有两种:基于用户的(user based collaborative filtering)和基于物品的(item based collaborative filtering)协同过滤算法。另外隐语义模型(latent factor model)算法也比较受关注。

4.1.1基于用户的协同过滤算法

  基于用户的协同过滤算法是整个推荐系统领域最早最经典的算法。这个算法在1992年的提出标志着推荐系统的诞生。目前最著名的使用者是Digg新闻推荐系统。

  基于用户的协同过滤算法主要包括两个步骤:
  1> 找到与目标用户兴趣相似的用户集合;
  2> 找到这个集合中用户喜欢的、且目标用户尚未点击/购买/观看的物品给目标用户。

  对于步骤1>,要计算两个用户的兴趣相似度。从日志数据里,可以得到两个用户曾经有过正面反馈的物品集合,然后把这两个集合通过Jaccard公式(交集数除以并集数)或通过余弦夹角计算出其距离。

  有了距离公式,求对于某个用户最相似的Top N用户,就成了一个典型的KNN算法。如果用双层循环,硬算用户两两之间的距离,其时间复杂度是平方级的。

  但现实情况下,实际上很多用户之间是没有任何交集的,我们可以首先计算交集,只有不为零的用户对才除以分母的并集部分。这就节省了很大一部分计算量。具体算法里可以空间换时间,先创建“物品到用户”的倒排索引,再建立一个稀疏矩阵C用于存储两个用户之间的交集总数。只要扫描所有物品的倒排索引,将其中包含的所有用户之间的交集数加1(利用C),最终就可以得到所有用户之间不为零的交集(也就是C的内容)。

  得到用户之间的兴趣相似度之后,就开始步骤2>,这就相对比较简单了,只要用一个双重循环,就可以把与目标用户最接近的Top N个用户涉及到的所有物品进行排列,然后再挑选出其中目标用户没有涉及过的前K个产品。

  对于这个算法,还可以通过各种手段进行预处理,进一步提高效果。一个最常见的问题是“哈里波特现象”,也就是大热的畅销商品导致所有用户之间都有虚假的联系,既增加了运算量,也干扰了预测结果,降低了惊喜度。因此可以对畅销热门商品施加一个权重惩罚值。

4.1.2基于物品的协同过滤算法

  基于用户的协同过滤算法,其时间复杂度是与用户数目相关的。在大多数电子商务网站上,物品数都是大大小于用户数的。因此亚马逊最早应用了基于物品的协同过滤算法。这个算法目前成了业界应用最多的算法。反过来,Digg、新浪微博等新闻类网站仍然坚持使用基于用户的协同过滤算法,是由于这些网站上的物品(新闻帖子)的数目都是大于用户数的,而且这些物品会的很快过时(几天甚至几个小时)。

  基于物品的协同过滤算法主要分为两步:
  1> 计算物品之间的相似度;
  2> 根据物品的相似度和用户的数据给用户生成推荐结果。

  与基于用户的协同过滤算法类似,基于物品的协同过滤算法的计算也可以首先建立“用户到物品”的倒排索引,然后对每个用户,将他物品列表中物品两两在矩阵C中加 1。然后将矩阵归一化就可以得到物品之间的余弦夹角。

  除了前面提到的“哈里波特现象”,基于物品的协同过滤算法也会被“超级买家现象”干扰。如果有用户大量购买各种商品(例如职业出版人和评论家)则会导致算法性能下降,因此需要对过于活跃的用户进行权重惩罚。

  另外,为了增加推荐的覆盖率和多样性,应该对前面的相似度矩阵C按最大值归一化。这样就能保证被推荐的商品不仅仅来自一个类型中心附近。

4.2. 利用用户对产品的个性化标签(UGC tags)

  UGC标签系统是很多Web 2.0网站的重要组成部分。使用标签数据进行推荐的网站包括Delicious、Last.fm和豆瓣。

  基本的利用用户标签个性化推荐算法包括以下几步:
  1> 统计每个用户最常用的标签;
  2> 对于每个标签,统计被打过这个标签最多的物品;
  3> 对于目标用户通过他的常用标签,查找这些标签对应的热门物品,删重并推荐。

  上面方法倾向于推荐热门标签和热门物品,降低了新颖性。可以借鉴搜索引擎TF/IDF的思路,对热门标签和热门物品进行适当惩罚。

  进一步,可以适当对标签集合做聚类,计算标签之间的相似度,对标签进行拓展,从而对标签历史比较少的新用户或新物品提供更多推荐。对于相似度的度量,可以认为当两个标签同时出现在很多物品的标记中时,它们相似度较高。因此我们可以利用常规的余弦夹角来计算标签的相似度。

  再进一步,可以通过清理一些区分性不好的标签,以便提高算法精度,例如词频很高的停止词。也可以让编辑和运营人员进行整理。

4.3. 利用上下文和社交网络数据

  上下文信息和社交网络数据,均可以为主力推荐算法提供补充,作为参数输入到前面提到的经典算法当中去。

  例如,利用时间上下文,可以给物品设定一个半衰期,让较新的物品排在前面,这种做法对新闻类的Web 2.0网站很常见。

  再如,利用位置信息上下文,对很多LBS类应用很关键。具体计算时,可以先对目标用户进行个性化推荐,再利用他所在位置得到一个用户集合,利用这个集合的信息再给出另一个推荐结果,最后把两个推荐结果进行综合。

  还有,如果能得到一个用户的社交网络信息,就可以获得他的熟人圈子和关注对象列表。基于友好用户的兴趣来推荐或解释推荐结果,对目标用户的感受而言会更加可信。尤其是对于信息流的推荐,更加适合使用社交网络的信息。

  此外,社交网络的一个标准模块是好友推荐。最常规的方法是推荐“好友的好友”。

五、淘宝的推荐系统的特点

淘宝推荐系统

5.1. 业务场景

  淘宝的推荐系统主要涉及以下这些业务场景:
  1>Detail 浏览了还浏览
  2>收藏夹弹出层推荐
  3>购物车弹出层推荐
  4>已买到宝贝你可能感兴趣
  5>淘宝无线应用
  6>EDM(重复购买提醒)
  7>各个垂直频道
  8>个性化list排序

5.2. 算法应用

  淘宝推荐系统主要用到了聚类算法,预测算法,分类算法等基础算法产生基础知识库;利用协同过滤算法、基于标签的推荐算法和关联规则发现算法进行推荐。应用方式说明如下:

  预测算法,例如logistic 回归,通过以点击率为目标,以商品,卖家等因素作为指标,建立预测模型构建淘宝优质宝贝库。

  分类算法,例如朴素朴素贝叶斯算法,用于对商品和用户进行性别判断(男性、女性、中性)。

  聚类算法,例如k-means算法,用于对人群进行细分,例如客户流失分析;也用于Big Data条件下的降维。

  关联规则发现算法,用于发现类目、商品和用户的相关性。

  协同过滤算法,提供长尾新奇商品的个性化推荐,遇到的问题主要是冷启动。

  基于标签的推荐算法,优势是实现简单,且与搜索引擎容易配合,缺点是难以区分商品品质,无法照顾惊喜度。

5.3. 特点和需求

  淘宝推荐系统的特点是用户、商品、类目和商铺的数量都很惊人(数百万店铺信息、4.4亿激活用户、8亿在线商品、数十亿收藏标签、每分钟销售商品4.8万件)。因此前文提到的多数单机内存算法,都面临大数据下的分布式化改写的问题。除此之外,淘宝TCIF团队还希望融入更多信息,例如支付信息,用户访问的第三方网站PV等等。

  淘宝推荐系统的评价指标包括CTR、GMV和转化率。

  略……

六、参考文献

  《推荐系统实践》,2012年6月,项亮,人民邮电出版社
  《推荐系统@淘宝》,2012 年 7月,空望,百度文库
  《淘宝网TCIF案例分析:基于海量数据下的消费者研究》,2012年4月,必达,2012数据库技术大会
  《淘宝海量数据技术》,2011年 11月,空无,百度文库

数据挖掘和哈姆雷特

  关于推荐系统和数据挖掘想到点好玩的:电子书里的小说情节可以个性化。例如根据读者特点和所处位置修改男主角失恋后去的酒吧。再例如故事结局到底是黑色幽默或者苍凉离去呢,要根据读者是宅男还是文艺女青年来定制。真正实现一千个人眼里有一千个哈姆雷特。

  好吧我承认,上面这个段子本来是另外一篇更长的文字里的点缀。最近因为工作需要,我在写一份与推荐系统有关的文档,技术和业务都会蜻蜓点水说说皮毛。其中的非涉密内容打算整理成独立一篇BLOG。忍不住先把这个小段子发布出来,也算给自己挖个坑,防止偷懒赖帐。

KDD 2012第一天

  我现在在KDD 2012大会现场。由于今年的主题是Mining the Big Data,有趣的报告太多了。我主要在穿插着听以下三个Track:

  1.关于海量数据处理,基于MapReduce、Stream的数据挖掘算法实现的BigMine

  2.关于生物信息数据挖掘的BIOKDD,以及与健康信息有关的HI-KDD

  3.Yahoo专家的特邀报告Data mining in streams

  见到很多朋友,如果你也在现场请联系我或者微博上@我,大家多交流。

KDD2012将在北京举行

  第18届知识发现与数据挖掘ACM学术会议,也就是KDD 2012,8月12日将在北京举办。这次大会的主题是Mining the Big Data。由于阿里云是赞助商之一,所以我弄到了参会名额。

  这次的KDD cup 2012,题目使用了腾讯微博和搜索引擎的数据。负责主持的是Kaggle,数据挖掘领域著名的竞技平台,里面举行的比赛奖金颇丰。

  2004的KDD cup,题目是生物信息领域的,pFind团队的yfu大牛取得全球并列第一。

  而让KDD cup名声大震的,当数2006年的Netflix Prize,悬赏100万美元。现在国内推荐系统领域领军人物xVector,就是凭借这次大赛成为大众偶像。这是戏剧性的一次大赛,纽约时报全程报导,xVector的团队在最后20分钟痛失第一。

  我们会上见。

近几年内,国内公有云会怎么发展?

  我在知乎上回答了一个问题:近几年内,云计算会有怎么的发展?

     只说说公有云。对私有云不了解。

     1.最近云计算领域的关键词是“落地”。国内共有云基础设施将逐步成熟,领先的公司有望收支平衡。随着价格战的展开,泡沫落潮,没穿内裤的游泳者会逐步出局。

     2.地方政府推动的所谓云计算项目,会找公有云商业公司合作。前者擅长出钱、征地、修机房、买机器,并拉上来一些当地客户。而拥有技术和运营能力的商业公司,负责提供品牌、开发软件、部署系统、运维。

     3.越来越多的天使投资人和风险投资人会要求互联网创业团队在创业初期租用公有云。这比一开始就买很多硬件和带宽放在那里日日夜夜产生折旧成本,风险更小。支出成本与业务量之间线性相关,一旦业务转型包袱比较轻,这更符合财务投资的原则。

     4.Saas类的产品会再次迎来机会。此前的一些RCM、ERP、SCM软件的Saas化尝试不算特别成功,原因是业务模式只改了一半:客户这边变成了按需租用,但支出成本这边却仍然不变, 需要自己建机房买机器,这导致现金流循环的周期太长。有了底层Iaas和Paas供应商,Saas从业者可以按需租用,节省运维费用,成本就降下来了。

     5.移动智能手机的进展会促进云计算的发展。

     6.电子商务从业者方面,用数据仓库、数据挖掘技术支撑运营,会逐渐变成默认标配。中小电商不会投资独立设施,会租用云计算。

     7.弹性计算、云存储、大数据处理,这三大主题陆续都会变成红海。业者需要寻找新的技术和业务模式的创新。

     8 传统意义上的高性能计算的非互联网客户,例如物理、天文、地质、材料,生化等计算的市场,会逐渐往云计算平台上转,但这是一个漫长的过程。曙光6000和天河1号这样的超算中心将来还是会活的很滋润。两边各自擅长于不同的市场(IO密集型和计算密集型)。

从卫生巾说到生物云计算

  写一些技术感想,意识流,没中心,想到哪里写到哪里。

  12月12日,淘宝又一次大促销。一天时间不到,卖出去了三亿片苏菲。这是一个很恐怖的数字。随着淘宝占全中国零售额的比例一路超过5%,电子商务已经开始影响传统主体经济。

  体量足够大,就有数据可供挖掘了。

  例子一,去年到上海参加软件开发SD2.0大会,淘宝的数据可视化讲座,给出了女性内衣的尺码数据统计,平均值从前几年的A罩,迅速增大,目前居然达到了C罩杯。因此得到两个结论:<1>中国人的营养水平和肥胖率不断上升,<2>上淘宝买东西的女性年龄在增大,已经越过了婚育年龄均值点。

  例子二,2010年温总理去淘宝视察,马云的报告里说,由于阿里巴巴有真实的外贸订单数据,淘宝有真实的国内零售数据,所以可以据此预测未来半年的全国经济走势。那时候马云PPT里的预测,现在印证起来,相当准确。

  屁股决定上层建筑,有了数据金矿挖掘的利益驱动,相关的技术投资就会被重视,然后就构建出新的技术平台和商业模式来。Amazon的营业收入中,越来越大的比例源于计算和存储能力的对外租用,也就是云计算。它已经不知不觉变成了云计算市场的领袖,甚至威胁到了伟大的Google。

  回来再说我们pFind的事情。最近半年多lyz美女一直在开发pFind@hadoop。此前也讨论过生物信息云计算。

  首先用MapReduce创建离子索引还挺顺利,然后就开始写查询这一块。方案是利用HBase进行存储,利用Thrift进行结构化和远程调用传输。但性能一直是问题,hchi用C++写的单进程处理程序(把数据索引分块,逐个载入查询),居然和Hadoop版的64核集群的速度差不多。进行了大量的优化,并请教了在搜索引擎公司的Hadoop牛人,依然达不到期望。

  在很小的质谱数据集上,pFind就要发起接近百万次的离子查询,这种规模的并发,已经远远超出了HBase常见的应用方式。于是反思方案本身。HBase的特点是支持随机写入,引入了并发事务性管理机制。因此,它更合适需要增删改的online实时处理,其替代对象是传统的SQL关系型数据库。

  而对于全文搜索类的应用场景而言,其预计算索引一般只需要顺序批量写入,不必支持随机改和删除。所以可以直接把索引存入HDFS,自己实现查询。由于不用支持随机写入和删除。也就是几千行代码而已。最新2011.12期的《程序员》刊登了推特Nathan Marz的文章《如何打败CAP定理》,他们的方案是采用Elephant和Voldemort read-only这一类可以直接从Hadoop MapReduce中导出key/value的数据库。这些数据库都不支持随机写入,简洁使其鲁棒性特别好。这种方式不能更新数据,每次都需要全局重做。但生物数据库对实时更新并没有太高要求。

  (补:Guancheng大虾提示说,把Hadoop实现的版本跑在512甚至1024核上会不会比C++单线程版本快?把input size增加几倍的话Hadoop版本的Scalability会不会更好?)

  再记录一件事。大红大紫的redis的维护者刚刚拒绝了微软提交的补丁。补丁的目的是让redis可以在Windows系统下运行。拒绝的原因是Linux completely won as a platform to deploy software(作为工作软件的部署平台,Linux已经完胜win32)。维护者认为应该把精力集中在真正重要的问题上。

  这一期《程序员》杂志的企业软件专题里面,主编表达了与此相关的一些观点。最近五年以来,Java和C#这些语言逐渐不那么招人喜欢(看这个链接这个链接)。企业级开发、Windows开发的形象变得过时。像我这种有点年纪的程序员,难免总会有点三十年水流东三十年水流西的感慨。

  云计算是现在最热的buzzwords,小心,IT领域的大词,总会很快过时。

推荐10月份的《程序员》

  刚刚收到10月份的《程序员》,有几篇文章不错,推荐一下。

  这期组织了一个产品开发、营销和运营的专题。第一篇就是周鸿祎的《用互联网的思想经营产品》,很赞同其中的很多观点。之前谢文有一篇文字,对开发、营销和运营三阶段有很类似的论述。分析Windows Vista这款失败产品那一段,和Joel on software的看法基本一致。

  最近数据挖掘和推荐的话题很火爆,大牛们纷纷加入Resys Group。《程序员》保持了嗅觉灵敏、迅速跟进的特点,这一期里有《商品推荐背后的数学》和《Tag和Tagging》两篇与此有关。

  感兴趣的一篇小文章是《编程习惯》,强调了版本控制、构建系统、自动化测试、代码评阅、重构、代码风格等六大基础设施。刚好和俺前两天写的不谋而合。

  HR的内容越来越多了,例如《建立完整的外包人才体系》、《绩效考核的五种死因》、《绩效实施经验六法》等。今天和朋友吃饭,聊天说起这个来,很多HR部门都有故弄玄虚的坏毛病,交流困难,演进缓慢。在这种不良气氛下,个人的职业成长很多时候更需要依赖悟性和韧劲。