新闻中心

02-01
2018
div css布局中CSS图片大小自动按比例等比例缩小图片不变形解决技巧
div css布局中对于图片列表或图片排版时,图片不是固定宽度高度大小,但图片占位是固定宽度高度,这个时候如果使用CSS固定死图片大小(宽度 高度),这个时候如果图片相对于这个位置不是等比例大小,那么这张图片就会变形,让图片变的不清晰,这个时候想让图片不变形又按比例缩放,如何解决?CSS图片缩小不变形,图片自动缩小,图片按比例等比例缩小不变形解决。解决方法有两种:第一种,让图片和布局宽度高度成等比例,这样CSS设置死宽度和高度,图片也是等比例缩小,图片也不会变形。比如淘宝,要求店铺主上传产品封面图片是正方形的,为什么,因为图片宝贝展示列表都是正方形的排版布局,这样要求上传合适正方形宝贝封面图片,也是让图片不变形。所以有条件的情况下,大家将首页、图片列表页的布局宽度高度保持一致,上传图片时候将图片先进行处理为布局宽度高度时等比例放大尺寸的。第二种,使用CSS max-width和max-height实现图片自动等比例缩小很简单我们要使用到max-width和max-height,这样即可设置对象图片最大宽度和最大高度,这样图片就会等比例缩放图片,然图片相对不变形清晰。以下通过实例对比方法让大家掌握CSS控制图片缩小不变形技巧。一、原始描述 这里有个div,CSS宽度和CSS高度方便为300px和100px同时设置1px黑色边框,里面放了一张图片(图片原始宽度650px为高度为406px)。并通过CSS固定死图片宽度高度。1、HTML源代码:<!DOCTYPE html>  <html>  <head>  <meta charset="utf-8" />  <title>图片缩小不变形实例 www.divcss.com</title>  <style>  .divcss{ border:1px solid #000; width:300px; height:100px}  .divcss img{width:300px; height:100px}  </style>  </head>    <body>  <div class="divcss">  <img src="img.jpg" />  </div>  </body>  </html>2、CSS固定死图片宽度高度实例截图原始图片展示:原始图片截图css固定宽度高度后变形的图片截图3、小结,通过CSS固定对象内图片高度宽度,这样图片如果不是等比例缩小,那么图片就变形了。二、CSS解决图片缩小不变形实例使用max-width:300px或max-height:100px,即可解决图片比例缩小。但这样存在一个问题,如果按照宽度缩放,但图片过高会超出溢出盒子,这个时候需要对父级使用overflow:hidden隐藏超出图片内容。但是使用max-width或max-height,IE6不支持,我们需要设置个width:expression(this.width > 300 ? "300px" : this.width);或者height:e­xpression(this.height>100?"100px":this.height);。解决IE6支持max-heightdiv css解决IE6支持max-width一般情况下只需要设置好宽度限制,比如这里只设置最大宽度为300px(max-width:300px),然后对父级使用overflow:hidden隐藏溢出图片,同时为了兼容IE6我们设置个width:expression(this.width > 300 ? "300px" : this.width);解决即可。1、具体解决DIV+CSS实例代码如下:<!DOCTYPE html>  <html>  <head>  <meta charset="utf-8" />  <title>图片缩小不变形实例 www.divcss.com</title>  <style>  .divcss{ border:1px solid #000; width:300px; height:100px;overflow:hidden}  .divcss img{max-width:300px;_width:expression(this.width > 300 ? "300px" : this.width);}  </style>  </head>    <body>  <div class="divcss">  <img src="img.jpg" />  </div>  </body>  </html>2、浏览器测试效果截图css图片缩小等比例缩小后不变形截图3、缺点介绍,如果使用此方法,兼容各大浏览器不变形,但图片不是完整显示的。
01-31
2018
webrtc中rtcp反馈与码率控制模块分析
0. 参考文档1 google congestion control1. 简介webrtc的带宽估计分为两部分,一部分为发送端根据rtcp反馈信息进行反馈,另一部分为接收端根据收到的rtp数据进行相应的码率估计[1]。 本文先分析发送端根据rtcp反馈信息进行码率调整的部分代码。具体计算公式: 2. 代码结构2.1 类关系rtp_stream_receiver中有一个继承自抽象类RtpRtcp的ModuleRtpRtcpImpl,ModuleRtpRtcpImpl中有一个rtcp_receiver。当有RTCP包到来时,逐层处理至rtcp_receiver,当包是rtcp receiver report包,则会将包解析,然后在ModuleRtpRtcpImpl中再次调用rtcp_receiver中的TriggerCallbacksFromRTCPPacket函数,触发对应rtcp的一些事件,反馈触发的主要是_cbRtcpBandwidthObserver的观察者(RtcpBandwidthObserverImpl),这个观察者收到对应的report block之后会计算成带宽估计所需要的参数,并调用属主bitratecontrolImpl类对带宽进行估计,这里会调用SendSideBandwidthEstimation中的UpdateReceiverBlock进行实际的带宽评估。2.2 调用关系图3. 代码分析3.1 HandleReportBlock这个函数中最主要的部分就是RTT的计算,webrtc中对于RTT平滑的因子是一个线性增长的因子。/* 这个函数根据对应的report block生成了一个新的RTCPReportBlockInformation结构体,  * 并计算出对应的RTT,多report block在调用点处执行循环。  */ void RTCPReceiver::HandleReportBlock(     const RTCPUtility::RTCPPacket& rtcpPacket,     RTCPPacketInformation& rtcpPacketInformation,     uint32_t remoteSSRC)     EXCLUSIVE_LOCKS_REQUIRED(_criticalSectionRTCPReceiver) {   // This will be called once per report block in the RTCP packet.   // We filter out all report blocks that are not for us.   // Each packet has max 31 RR blocks.   //   // We can calc RTT if we send a send report and get a report block back.   // |rtcpPacket.ReportBlockItem.SSRC| is the SSRC identifier of the source to   // which the information in this reception report block pertains.   // Filter out all report blocks that are not for us.   if (registered_ssrcs_.find(rtcpPacket.ReportBlockItem.SSRC) ==       registered_ssrcs_.end()) {     // This block is not for us ignore it.     return;   }   RTCPReportBlockInformation* reportBlock =       CreateOrGetReportBlockInformation(remoteSSRC,                                         rtcpPacket.ReportBlockItem.SSRC);   if (reportBlock == NULL) {     LOG(LS_WARNING) << "Failed to CreateReportBlockInformation("                     << remoteSSRC << ")";     return;   }   // 用于RTCP超时的计算。   _lastReceivedRrMs = _clock->TimeInMilliseconds();   // 其他字段的拷贝。   const RTCPPacketReportBlockItem& rb = rtcpPacket.ReportBlockItem;   reportBlock->remoteReceiveBlock.remoteSSRC = remoteSSRC;   reportBlock->remoteReceiveBlock.sourceSSRC = rb.SSRC;   reportBlock->remoteReceiveBlock.fractionLost = rb.FractionLost;   reportBlock->remoteReceiveBlock.cumulativeLost =       rb.CumulativeNumOfPacketsLost;   if (rb.ExtendedHighestSequenceNumber >       reportBlock->remoteReceiveBlock.extendedHighSeqNum) {     // We have successfully delivered new RTP packets to the remote side after     // the last RR was sent from the remote side.     _lastIncreasedSequenceNumberMs = _lastReceivedRrMs;   }   reportBlock->remoteReceiveBlock.extendedHighSeqNum =       rb.ExtendedHighestSequenceNumber;   reportBlock->remoteReceiveBlock.jitter = rb.Jitter;   reportBlock->remoteReceiveBlock.delaySinceLastSR = rb.DelayLastSR;   reportBlock->remoteReceiveBlock.lastSR = rb.LastSR;   if (rtcpPacket.ReportBlockItem.Jitter > reportBlock->remoteMaxJitter) {     reportBlock->remoteMaxJitter = rtcpPacket.ReportBlockItem.Jitter;   }   int64_t rtt = 0;   uint32_t send_time = rtcpPacket.ReportBlockItem.LastSR;   // RFC3550, section 6.4.1, LSR field discription states:   // If no SR has been received yet, the field is set to zero.   // Receiver rtp_rtcp module is not expected to calculate rtt using   // Sender Reports even if it accidentally can.   if (!receiver_only_ && send_time != 0) {     // 当RR在SR之前发送,send_time为0.     // delay计算:     // Send SR                                                       Receive RR     //  |                          delay in RR                           |     //  |                        ||                         |     //  ||             ||     //     // RTT = total_time - delay_in_RR     //     = receiver_rr_time - send_sr_time - delay_in_RR     // 即使中间几个SR丢包,但是如果RTT本身是平滑的,那么RTT不会受到这几个丢包的影响     // 因为SR->RR之间的delay可以精确计算。     uint32_t delay = rtcpPacket.ReportBlockItem.DelayLastSR;     // Local NTP time.     uint32_t receive_time = CompactNtp(NtpTime(*_clock));     // RTT in 1/(2^16) seconds.     uint32_t rtt_ntp = receive_time - delay - send_time;     // Convert to 1/1000 seconds (milliseconds).     rtt = CompactNtpRttToMs(rtt_ntp);     if (rtt > reportBlock->maxRTT) {       // Store max RTT.       reportBlock->maxRTT = rtt;     }     if (reportBlock->minRTT == 0) {       // First RTT.       reportBlock->minRTT = rtt;     } else if (rtt < reportBlock->minRTT) {       // Store min RTT.       reportBlock->minRTT = rtt;     }     // Store last RTT.     reportBlock->RTT = rtt;     // store average RTT     // RTT的平滑计算。     // 如果这个块是在CreateOrGetReportBlockInformation新生成的,     // 则权重会从0开始随着受到的report逐渐递增。     // srtt(i) = i/(i+1)*srtt(i-1) + 1/(i+1)*rtt + 0.5     if (reportBlock->numAverageCalcs != 0) {       float ac = static_cast(reportBlock->numAverageCalcs);       float newAverage =           ((ac / (ac + 1)) * reportBlock->avgRTT) + ((1 / (ac + 1)) * rtt);       reportBlock->avgRTT = static_cast(newAverage + 0.5f);     } else {       // First RTT.       reportBlock->avgRTT = rtt;     }     reportBlock->numAverageCalcs++;   }   TRACE_COUNTER_ID1(TRACE_DISABLED_BY_DEFAULT("webrtc_rtp"), "RR_RTT", rb.SSRC,                     rtt);   // 添加回rtcpPacketInformation,在ModuleRtpRtcpImpl中会使用这个进行事件回调。   rtcpPacketInformation.AddReportInfo(*reportBlock); }3.2 UpdateMinHistory这个函数主要用于更新变量min_bitrate_history_,这个变量将会作用于上升区间,用来作为基数,这里简单描述下。// Updates history of min bitrates. // After this method returns min_bitrate_history_.front().second contains the // min bitrate used during last kBweIncreaseIntervalMs. // 主要结合这个函数解释下变量min_bitrate_history_ // 这个变量的两个维度,front记录的是离当前最远的时间, // 每个速率都是按照时间先后顺序逐渐push到尾部。 // 因此更新的时候,需要先将超时的元素从列表头剔除。 // 后一个维度是最小速率值, // 在相同的时间区间内,保留最小的速率值。 // |-------Interval 1---------|----------Interval 2------| // |                          |                          | // |--t1 < t2 < t3 < t4 < t5--|--t1 < t2 < t3 < t4 < t5--| // 这样的操作较为简单,不用在每次插入元素时去判断对应的时间区域,再找到对应时间区间的最小值,用部分冗余的内存换取操作的快捷。 void SendSideBandwidthEstimation::UpdateMinHistory(int64_t now_ms) {   // Remove old data points from history.   // Since history precision is in ms, add one so it is able to increase   // bitrate if it is off by as little as 0.5ms.   while (!min_bitrate_history_.empty() &&          now_ms - min_bitrate_history_.front().first + 1 >              kBweIncreaseIntervalMs) {     min_bitrate_history_.pop_front();   }   // Typical minimum sliding-window algorithm: Pop values higher than current   // bitrate before pushing it.   while (!min_bitrate_history_.empty() &&          bitrate_ <= min_bitrate_history_.back().second) {     min_bitrate_history_.pop_back();   }   min_bitrate_history_.push_back(std::make_pair(now_ms, bitrate_)); }3.3 UpdateEstimate函数UpdateReceiverBlock会根据当前的report block对当前带宽估计的一些变量进行相应的赋值,此外,只有当传输包的数量达到一定数量才会再次触发带宽估计的调整。函数UpdateEstimate是主要用于带宽估计的函数。void SendSideBandwidthEstimation::UpdateEstimate(int64_t now_ms) {   // We trust the REMB and/or delay-based estimate during the first 2 seconds if   // we haven't had any packet loss reported, to allow startup bitrate probing.   if (last_fraction_loss_ == 0 && IsInStartPhase(now_ms)) {     uint32_t prev_bitrate = bitrate_;     // bwe_incoming_是remb更新的值,如果当前无丢包且在启动阶段,直接使用remb的值。     if (bwe_incoming_ > bitrate_)       bitrate_ = CapBitrateToThresholds(now_ms, bwe_incoming_);       ...     }   }   UpdateMinHistory(now_ms);   // Only start updating bitrate when receiving receiver blocks.   // TODO(pbos): Handle the case when no receiver report is received for a very   // long time.   if (time_last_receiver_block_ms_ != -1) {     if (last_fraction_loss_ <= 5) {       // Loss < 2%: Increase rate by 8% of the min bitrate in the last       // kBweIncreaseIntervalMs.       // Note that by remembering the bitrate over the last second one can       // rampup up one second faster than if only allowed to start ramping       // at 8% per second rate now. E.g.:       //   If sending a constant 100kbps it can rampup immediatly to 108kbps       //   whenever a receiver report is received with lower packet loss.       //   If instead one would do: bitrate_ *= 1.08^(delta time), it would       //   take over one second since the lower packet loss to achieve 108kbps.         //TODO:tjl       // 这里与公式有一定不同:       // 1. 系数不同,且附带一定的修正值(向上取整加1kbps)       // 2. 取的是上一个时间间隔之内最小值,比较平滑。       bitrate_ = static_cast(           min_bitrate_history_.front().second * 1.08 + 0.5);       // Add 1 kbps extra, just to make sure that we do not get stuck       // (gives a little extra increase at low rates, negligible at higher       // rates).       bitrate_ += 1000;       event_log_->LogBwePacketLossEvent(           bitrate_, last_fraction_loss_,           expected_packets_since_last_loss_update_);     } else if (last_fraction_loss_  10%: Limit the rate decreases to once a kBweDecreaseIntervalMs +       // rtt.       if (!has_decreased_since_last_fraction_loss_ &&           (now_ms - time_last_decrease_ms_) >=               (kBweDecreaseIntervalMs + last_round_trip_time_ms_)) {         time_last_decrease_ms_ = now_ms;         // Reduce rate:         //   newRate = rate * (1 - 0.5*lossRate);         //   where packetLoss = 256*lossRate;           //TODO:tjl         // 当从未开始降低窗口值,且距离上一次衰减的时间差大于衰减周期加上rtt。         // 其实当前貌似只有这个case下会对这两个变量赋值。         // 这里的last_fraction_loss_是一次统计间隔(一定包数)之间的总丢包率。         // 丢包率的单位是1/256,因此这里是(1 - 丢包率/2) * 当前速率         // 与公式相同。         bitrate_ = static_cast(             (bitrate_ * static_cast(512 - last_fraction_loss_)) /             512.0);         has_decreased_since_last_fraction_loss_ = true;       }       event_log_->LogBwePacketLossEvent(           bitrate_, last_fraction_loss_,           expected_packets_since_last_loss_update_);     }   }   // 在有效范围内修正。   bitrate_ = CapBitrateToThresholds(now_ms, bitrate_); }
01-31
2018
成为Java顶尖程序员 ,看这11本书就够了
以下是我推荐给Java开发者们的一些值得一看的好书。但是这些书里面并没有Java基础、Java教程之类的书,不是我不推荐,而是离我自己学习 Java基础技术也过去好几年了,我学习的时候看的什么也忘了,所以我不能不负责任地推荐一些我自己都没有看过的书给大家。“学习的最好途径就是看书“,这是我自己学习并且小有了一定的积累之后的第一体会。个人认为看书有两点好处:1.能出版出来的书一定是经过反复的思考、雕琢和审核的,因此从专业性的角度来说,一本好书的价值远超其他资料2.对着书上的代码自己敲的时候方便“看完书之后再次提升自我的最好途径是看一些相关的好博文“,我个人认为这是学习的第二步,因为一本书往往有好几百页,好的博文是自己看书学习之后的一些总结和提炼,对于梳理学习的内容很有好处,当然这里不是说自己的学习方法,就不再扯下去了。很多程序员们往往有看书的冲动,但不知道看哪些书,下面我就给各位Java程序猿们推荐一些好书(每本书的作者会加粗标红),其中绝大多数都是我自己平时在看的书,也算是我对于平时读的书做一个小总结和读后感吧。首先推荐的不是一本书,而是一个博客,也是我们博客园另外一位博友java_my_life。目前市面上讲解设计模式的书很多,虽然我前面讲了看书是最好的,但是对设计模式感兴趣的朋友们,我推荐的是这个博客。这位博友的设计模式讲得非常非常好,我认为90%的内容都是没有问题且很值得学习的,其讲解设计模式的大体路线是:1、随便开篇点明该设计模式的定义2、图文并茂讲解该设计模式中的结构3、以详细的代码形式写一下该种设计模式的实现4、补充内容5、讲解该设计模式的优缺点对于一个设计模式我们关注、学习的知识点,不就是上面这些吗?不 过我要重点提醒一下网友们,同一种设计模式的写法有多种,并不是说只有按某种写法来写才是这种设计模式。比方说适配器模式,我们关注适配器模式一定要关注 的是什么是适配器模式不是怎么写适配器模式,不要认为某段代码不是按照适配器模式的写法写下来的它就不是适配器模式了,记住这一点,你在学习设计模式的时 候一定会对代码中用到的设计模式有更深入的理解。《深入理解Java虚拟机:JVM高级特性与最佳实践》如果你不满足于做一个只会写if…else…的Java程序员,而是希望更进一步,我随便举几个例子吧:1、了解Java代码的底层运行机制2、定位性能问题3、对整个系统进行性能调优4、解决各种奇奇怪怪的线上线下问题5、更加高级别的,为自己的项目量身定做一款适合自己项目的虚拟机那 么Java虚拟机是你必学的一门技术。《深入理解Java虚拟机:JVM高级特性与最佳实践》作者是周志明,这本书可以说是国内写得最好的有关Java虚 拟机的书籍,近半年,前前后后这本书我起码看了有5遍。国内写虚拟机的书除了这本,其实还有一些其他的,我也买过,不过粗略看下来,很多内容也是《深入理 解Java虚拟机:JVM高级特性与最佳实践》此书里面的。另外值得一提的是,《深入理解Java虚拟机:JVM高级特性与最佳实践》这本 书,有电子版的,网上搜一下就能下载到了。不过建议有兴趣的朋友还是去买书看,电子版本下载到的一般是比较老的版本,相比最新修订版的《深入理解Java 虚拟机:JVM高级特性与最佳实践》,有很多作者新补充的知识点是没有的。《HotSpot实战》所有的Java虚拟机都是遵循着Java虚拟机规范来的,市面上的Java虚拟机几十款,《深入理解Java虚拟机:JVM高级特性与最佳实践》一书里面讲的虚拟机并不针对某种特定的虚拟机,而是从Java虚拟机规范的角度来讲解Java虚拟机。我们平时使用的乃至商用的大多数Java虚拟机都是Sun公司的HotSpot,大家cmd进入命令行,使用”java -version”命令就可以看到了。如果希望在Java虚拟机规范的基础上更加深入地去理解虚拟机的一些细节是怎么实现的,就可以看一下《HotSpot实战》一书,作者是陈涛。不过由于HotSpot的源码都是C/C++写的,所以要求读者有非常好的C/C++基础,如果对这两门语言不是很熟悉的朋友,看这本书可能对你帮助不是很大。最后提一句,如果有兴趣的朋友,不妨先去网上下载一个openJDK,HotSpot的源码就在里面。《Java并发编程实战》这本书常常被列入Java程序员必读十大书籍排行榜前几位,不过个人不是很推荐这本书。《Java并发编程实战》作者是Brian Goetz,怎么说呢,这本书前前后后我也看了两遍左右,个人感受是:1、文字多代码少2、讲解多实践少我 觉得这可能就是老外写书的特点吧,因为Java是北美国家(加拿大、美国)开发和维护的,所以老外对Java方方面面的理论知识体系都掌握得是非常清楚和 透彻的。翻开这本书看,多线程什么用、什么是死锁、什么是竞争、什么是线程安全等等,方方面面的知识点都用大量的文字篇幅讲解,不免让人感觉十分枯燥,也 难让读者有实质性的进步。我这本书看了两遍也属于一目十行意思,有兴趣的地方就重点看一下。无论如何,作为一本常常位于Jva程序员必读十大书籍排行榜前几名的书,还是一定要推荐给大家的。《java多线程编程核心技术》《Java多线程编程核心技术》作者高洪岩。想要学习多线程的朋友,这本书是我大力推荐的,我的个人博客里面二十多篇的多线程博文都是基于此书,并且在这本书的基础上进行提炼和总结而写出来的。此书和《Java并发编程实战》 相反,这本书的特点是大篇幅的代码+小篇幅的精讲解,可能这和中国人写的书比较偏向实用主义的风格有关。本书关于线程安全、synchronized、 Reentrant、Timer等等都用详细的代码进行了讲解,而且每个大知识点下的多个小知识点都会详细讲解到,非常有实践价值。有兴趣的朋友们,我相信只要你们跟着这本书里面的代码敲、运行、思考,三步走,对于多线程的使用与理解一定会进几大步。不 过这本书的缺点就是对于Java并发包下的一些类像CountDownLatch、Semphore、CyclicBarrier、Future、 Callable等都没有讲到,重点的CAS和AQS也没有触及,重点类的实现原理也没有提。当然,这很深入了,在学习了这本书之后如果能再去对这些知识 进行一些学习、研究的话,你一定会慢慢成长为一个很厉害的多线程高手。《Effective Java中文版》这是唯一一本我没有买的书。初识这本书,是在我的博文Java代码优化(长期更新)里面,底下评论的时候有朋友提到了这本书,当时我说要去买,不过这两个月一直都没时间去逛书店,甚是遗憾,之后肯定会找时间去买这本书的。《Effective  Java中文版》的作者是Joshua   Bloch,这个人就很厉害了,他是谷歌的首席架构师,属于超级技术大牛级别了吧,呵呵。由于没有看过这本书,所以我不好发表评论,但是从这本书的知名度 以及其作者的来头来看(多提一句,这本书也是Java之父James Gosling博士推崇的一本书),我相信这一定是一本值得一看的好书。好 的代码是每个Java程序员都应该去追求的,不是说我今天写一段好代码相比写一段烂代码对性能会有多大的提升,更多的应该是提升了代码的可读性以及可以规 避许多潜在的、未知的问题,避免代码上线之后出问题而花时间去维护—-无论从时间成本、人力成本还是风险成本来说,这都是非常高的。《深入分析Java Web技术内幕》《深入分析Java Web技术内幕》,作者许令波,淘宝工程师。这本书我用一个字概括就是:全。真的非常全,HTTP、DNS、CDN、静态化、Jetty、Tomcat、Servlet、Spring、MyBatis等等,什么都有,涉及知识面非常广,但又不像专门精讲某个知识点的书籍一样讲得非常深入,感觉这本书就是尽量去用短的篇幅讲清楚一些Java Web使用到的技术的内幕,让读者对这些知识点的技术内幕有一个理性的认识。不过,尽管每个知识点的篇幅都不多,但是重点都基本讲到了,是一本让人真正有收获的书。如果想进一步了解这些技术的技术内幕,就要自己去买相关书籍或者自己上网查资料了,有种抛砖引玉,或者说师傅领进门、修行在个人的感觉。《大型网站技术架构 核心原理与案例分析》一个字评价这本书,屌;两个字评价这本书,很屌;三个字评价这本书,非常屌。呵呵,好了,再说下去可能别人以为我是水军了。《大型网站技术架构 核心原理与案例分析》的作者是李智慧,原阿里巴巴技术专家。Java 的大多数应用都是用在Web上的,现在只要稍微大型一点的Web应用,都一定是一个分布式系统,那么一个分布式系统用到了哪些技术?一个大型网站是如何从 一个小型网站成长起来的?如何保证你的网站安全?分布式系统使用到了缓存,有哪些缓存?缓存的使用有哪些值得注意的事项?关 于分布式的知识点,都在这本书里面有体现,只有你想不到,没有他写不到,而且写得非常易懂,基本属于看一两遍,再记一些笔记就知道是怎么一回事儿了。多看 几遍,对分布式的理解一定会加深不少。而且里面不仅仅是分布式的知识,还非常接地气地写了如何做一个好的架构师,其实我认为这不仅仅是写给想做架构师的读 者看的,就是给读者一些建议,如何更好地提出意见、如何更让别人关注你的声音、如何看到他人的优点,入木三分,让人获益匪浅。《大型网站系统与Java中间件实践》《大型网站系统与Java中间件实践》作者曾宪杰,是淘宝的技术总监,算起来应该在阿里有至少P8的级别了吧。这本书的部分内容和上面一本李智慧的《大型网站技术架构 核心原理与案例分析》有所重合,像分布式系统的演化、CDN、CAP理论和BASE理论等等,这也更说明这些都是分布式系统或者说是一个大型网站重点关注的内容,当作一次再学习也不错。本书要突出的重点是中间件三个字,中间件是分布式系统中一个非常重要的东西,其最重要的作用应该就是解耦,降低模块与模块之间的强依赖,不同的模块之间的依赖度降低,便可以各自独立地开发自己的功能,这也可以说是软件工程发展的目标和驱动力。因此,本书有一部分的内容就是基于中间件,详细讲解了中间件与JMS的各种知识,适合对分布式系统比较熟悉并且想要往中间件方面有一定研究的读者。《从Paxos到ZooKeeper 分布式一致性原理与实践》《从Paxos到ZooKeeper 分布式一致性原理与实践》,作者倪超,阿里巴巴工程师。这本书是我最近在研读的一本书,和上面的《大型网站系统与Java中间件实践》一样,属于分布式组件的范畴,属于有些深入的内容,当然也是我自己的个人兴趣。当然,如果有志向做一个出色的大型网站架构师、公司的技术总监之类,这些知识当然是必须掌握的。本书从分布式系统基本理论开始讲起,讲到Paxos算法,最后慢慢引入到Zookeeper,循序渐进。当然,更多的我目前还不方便发表什么看法,因为这本书的第二张Paxos算法我都还没有弄懂(Paxos算法确实有些难以理解和不太易懂),接下来的章节还没有看下去。如果网友们所在的公司在使用Zookeeper,并且你又对Zookeeper感兴趣想要研究一下它的原理的,这本书将是不二之选。《MySQL5.6从零开始学》《MySQL5.6从零开始学》,作者刘增杰和李坤。作为一名Java程序员,我认为我们千万不要觉得数据库是DBA的事情,数据库对一个Java程序员来说也是必须掌握的一门知识,丰富的数据库性能优化经验是一个顶尖程序员必备技能。目前主流的数据库有Oracle和MySQL,当然推荐大家的是MySQL,主要原因我认为有两点:1、MySQL相比Oracle更轻量级、更小、安装和卸载更方便,SQL其实都是差不多的,如果想学数据库,学MySQL就可以了,在家里面可以自己方便地研究,如果你的公司使用Oracle,只要再用对比学习法,关注一下Oracle和MySQL的差别即可2、随着2009年阿里巴巴去IOE的运动的进行,目前国内的很多互联网公司都会选择MySQL作为它们使用的数据库,因为MySQL免费,所以既省钱又不需要出了问题就依赖甲骨文公司MySQL学习我推荐的是这本我自己学习看的《MySQL5.6从零开始学》,我是觉得挺好的这本书,书里面的知识点很细致、很全面,读者选择书籍的标准大多不就是这两点吗?《Spring源码深度解析》《Spring源码深度解析》,作者郝佳。Spring 这个框架做得太好了,功能太强大了,以至于很多开发者都只知Spring,不知什么是工厂、什么是单例、什么是代理(我面试别人的真实体会)。这种功能强 大的框架内部一定是很复杂的实现,这就导致一旦你的程序使用Spring,出了问题,可能是Error、可能是Exception、可能是程序运行结果不 是你的预期的,出现诸如此类问题的时候,将会让你感到困惑,除了上网查资料或者问别人似乎没有更好的解决办法。研读Spring的源代码不失为一种很好的学习方法,我个人认为这有很多好处:1、理解框架内部的实现之后,可以主动去解决问题,而不需要依赖别人2、Spring框架内部实现用到了很多设计模式,很好的代码设计思路,这将会对你写代码、对你理解设计模式有很大的提高3、研究Spring框架将会大大增强你读代码的能力,我相信只要你能研究清楚Spring内部是如何实现的,其他任何一个框架的源代码都难不倒你总而言之,我认为读代码的能力是一个普通的程序员和一个好的程序员之间最大的差别之一,前者只会把别人写好的东西拿来用,后者不仅能用好,还清楚知道别人写好的东西底层是如何实现的,在出现问题的时候可以轻松解决。Spring源代码,个人推荐《Spring源码深度解析》一书,真要研究透并且写清楚Spring源代码,恐怕三四本书都不够,作者在近400页的篇幅中尽量去讲解Spring源代码是如何实现的,殊为不易,尽管无法讲得完全,但是相信作者的讲解配合上读者自己的研究,一定可以对Spring的实现有更深度的理解。后记以 上就是我推荐给Java开发者们的一些值得一看的好书。但是这些书里面并没有Java基础、Java教程之类的书,不是我不推荐,而是离我自己学习 Java基础技术也过去好几年了,我学习的时候看的什么也忘了,所以我不能不负责任地推荐一些我自己都没有看过的书给大家。对于Java基础知识的学习, 我提两点建议吧:1、多写多敲代码,好的代码与扎实的基础知识一定是实践出来的2、可以去尚学堂下载一下马士兵的视频来学习一下Java基础,还挺不错的,如果尚学堂官网上下载不了可以底下回复,我的电脑里有最后,每一位读到这里的网友,感谢你们能耐心地看完。希望在成为一名更优秀的Java程序员的道路上,我们可以一起学习、一起进步。
01-31
2018
盘点那些曾经让程序员目瞪口呆的Bug都有什么?
盘点那些曾经让程序员目瞪口呆的Bug都有什么?程序员一生与bug奋战,可谓是杀敌无数,见怪不怪了!在某知识社交平台中,一个“有哪些让程序员目瞪口呆的bug”的话题引来了6700多万的阅读,可见程序员们对这个话题的敏感度有多高。本文,笔者特意精选了部分优质答案供广大程序员参考!作者:佚名来源:IT168程序员一生与bug奋战,可谓是杀敌无数,见怪不怪了!在某知识社交平台中,一个“有哪些让程序员目瞪口呆的bug”的话题引来了6700多万的阅读,可见程序员们对这个话题的敏感度有多高。本文,笔者特意精选了部分优质答案供广大程序员参考!1、麻省理工“只能发500英里的邮件”该bug发生于麻省理工,当时其系统管理员接到统计系主任的求助电话,主任在电话中说:“咱们的邮件系统无法发送距离500英里以外的地方,准确地说好像是520英里。”此时的系统管理员内心是“毫无波澜”的,嗯!然后,他开始了漫长且苦逼的测试,最后发现邮件服务器操作系统(SunOS)被人更新了,因为操作系统发行版往往配备旧软件,因此邮件软件实际上是被降级了(Sendmail 8 -> Sendmail 5) ,最后的结果是:Sendmail 5试图解析Sendmail 8的配置文件。所以,为什么一定是500英里呢?且看大神讲解:2、int mian()这其实是一个书写上的错误,之所以会放在本文中,是因为很多程序员的职业生涯中都有过写!错!的经历!main和mian傻傻看不出来!3、医院急诊科的程序bug一位程序员为医院急诊科设计了一套应用程序,毕竟是为急诊病人服务,所以程序员在实验室内认真地测试无数遍,直至确定没有问题,才让医院部署使用。但是,医院方面却总是出现问题,一拿到实验室就没问题。该名程序员于是深入医院调查,最后发现是医院的X光射线导致电脑内存丢失了几个bit信息,进而让程序出现问题!4、谷歌的 Google Arts & Culture APP谷歌推出的Google Arts&Culture APP是一个可以将普通人的照片与艺术照进行对比,匹配出与用户上传的照片最相像的一张艺术画,运行效果是这样的:图片上也会给出匹配度,但偏偏有些人的照片上传后,给出来的艺术画让人哭笑不得,比如:5、硬件开光的必要性某数据中心的火灾报警器因损坏,而在没有发生火灾的情况下响起。诡异的是,数据中心内确实出现了大面积的磁盘损坏和读写性能下降!经排查,因为报警器声音太大影响了磁头的运动!网友吐槽:看来给硬盘开光很有必要啊!6、某外资通信设备商的逆天bug(实在太长,给各位上图)7、足以让数据库瞬间崩溃的bug愿望:在百万量级的数据库里实现快速自我交叉匹配查询。手段:建立临时表提速。Bug:条件里忘记添加”a.id=b.prio”结果:临时表从预计的几千条达到了上亿条,数据库崩溃!!!!8、足以让系统瘫痪的bug9、程序员都能看懂的bug(反正笔者没看懂,看懂的麻烦解释一下)if (object == null) {object.doSomething();} else {object.doSomethingElse();}10、据传,iPhone手机日历上的bug11、购买微软Office套件visio不可使用outlook邮箱注册网友爆料,自己在购买正版Office套件visio时,当他在注册页面输入微软的outlook邮箱,系统居然提示系统中没有outlook.com!12、集群宿主机已售内存为负值?13、比较弱智的bug某网友:让我目瞪口呆的BUG是update不加where...14、人类历史上第一个程序BUG
01-29
2018
爬虫需谨慎,你不知道的爬虫与反爬虫套路!
面试的时候,因为双方爬虫理念或者反爬虫理念不同,也很可能互不认可,影响自己的求职之路。本来程序员就有“文人相轻”的倾向,何况理念真的大不同。爬虫与反爬虫,是一个很不阳光的行业。这里说的不阳光,有两个含义。第一是,这个行业是隐藏在地下的,一般很少被曝光出来。很多公司对外都不会宣称自己有爬虫团队,甚至隐瞒自己有反爬虫团队的事实。这可能是出于公司战略角度来看的,与技术无关。第二是,这个行业并不是一个很积极向上的行业。很多人在这个行业摸爬滚打了多年,积攒了大量的经验,但是悲哀的发现,这些经验很难兑换成闪光的简历。面试的时候,因为双方爬虫理念或者反爬虫理念不同,也很可能互不认可,影响自己的求职之路。本来程序员就有“文人相轻”的倾向,何况理念真的大不同。然而这就是程序员的宿命。不管这个行业有多么的不阳光,依然无法阻挡大量的人进入这个行业,因为有公司的需求。那么,公司到底有什么样的需求,导致了我们真的需要爬虫/反爬虫呢?反爬虫很好理解,有了爬虫我们自然要反爬虫。对于程序员来说,哪怕仅仅是出于“我就是要证明我技术比你好”的目的,也会去做。对于公司来说,意义更加重大,最少,也能降低服务器负载,光凭这一点,反爬虫就有充足的生存价值。那么爬虫呢?最早的爬虫起源于搜索引擎。搜索引擎是善意的爬虫,可以检索你的一切信息,并提供给其他用户访问。为此他们还专门定义了 robots.txt 文件,作为君子协定,这是一个双赢的局面。然而事情很快被一些人破坏了,爬虫很快就变的不再“君子”了。后来有了“大数据”,无数的媒体鼓吹大数据是未来的趋势,吸引了一批又一批的炮灰去创办大数据公司。这些人手头根本没有大数据,他们的数据只要用一个 U 盘就可以装的下,怎么好意思叫大数据呢?这么点数据根本忽悠不了投资者,于是他们开始写爬虫,拼命地爬取各个公司的数据。很快他们的数据,就无法用一个 U 盘装下了。这个时候终于可以休息休息,然后出去吹嘘融资啦。然而可悲的是,大容量 U 盘不断地在发布,他们总是在拼命地追赶存储增加的速度。以上是爬虫与反爬虫的历史,下面通过四个方面深入谈下爬虫与反爬虫:爬虫反爬虫运行现状爬虫反爬虫技术现状爬虫反爬虫套路现状爬虫反爬虫的未来爬虫反爬虫运行现状电子商务行业的爬虫与反爬虫更有趣一些,最初的爬虫需求来源于比价。这是某些电商网站的核心业务,大家买商品的时候,是一个价格敏感型用户的话,很可能用过网上的比价功能(真心很好用啊)。毫无悬念,他们会使用爬虫技术来爬取所有相关电商的价格。他们的爬虫还是比较温柔的,对大家的服务器不会造成太大的压力。然而,这并不意味着大家喜欢被他爬取,毕竟这对其他电商是不利的,于是需要通过技术手段来做反爬虫。按照技术人员的想法,对方用技术怼过来,我们就要用技术怼回去,不能怂啊。这个想法是很好的,但是实际应用起来根本不是这么回事。诚然,技术是很重要的,但是实际操作上,更重要的是套路。谁的套路更深,谁就能玩弄对方于鼓掌之中。谁的套路不行,有再好的技术,也只能被耍的团团转。这个虽然有点伤技术人员的自尊,然而,我们也不是第一天被伤自尊了。大家应该早就习惯了吧。真实世界的爬虫比例大家应该听过一句话吧,大概意思是说,整个互联网上大概有 50% 以上的流量其实是爬虫。第一次听这句话的时候,我还不是很相信,我觉得这个说法实在是太夸张了。怎么可能爬虫比人还多呢? 爬虫毕竟只是个辅助而已。现在做了这么久的反爬虫,我依然觉得这句话太夸张了。50%?你在逗我?就这么少的量?举个例子,某公司,某个页面的接口,每分钟访问量是 1.2 万左右,这里面有多少是正常用户呢?50%?60%?还是?正确答案是:500 以下。也就是说,一个单独的页面,12000 的访问量里,有 500 是正常用户,其余是爬虫。注意,统计爬虫的时候,考虑到你不可能识别出所有的爬虫,因此,这 500 个用户里面,其实还隐藏着一些爬虫。那么爬虫率大概是:(12000-500)/12000=95.8%。这个数字你猜到了吗?这么大的爬虫量,这么少的用户量,大家到底是在干什么?是什么原因导致了明明是百人级别的生意,却需要万级别的爬虫来做辅助? 95% 以上,19 保 1?答案可能会相当令人喷饭,这些爬虫大部分是由于决策失误导致的。哭笑不得的决策思路举个例子,这个世界存在 3 家公司,售卖相同的电商产品,三家公司的名字分别是 A,B,C。这个时候,客户去 A 公司查询了下某商品的价格,看了下发现价格不好,于是他不打算买了,他对整个行业的订单贡献为 0。然而 A 公司的后台会检测到,我们有个客户流失了,原因是他来查询了一个商品,这个商品我们的价格不好,没关系,我去爬爬别人试试。于是他分别爬取了 B 公司和 C 公司,B 公司的后台检测到有人来查询价格,但是呢,最终没有下单。他会认为,嗯,我们流失了一个客户。怎么办呢?我可以爬爬看,别人什么价格。于是他爬取了 A 和 C,C 公司的后台检测到有人来查询价格。。。。。过了一段时间,三家公司的服务器分别报警,访问量过高。三家公司的 CTO 也很纳闷,没有生成任何订单啊,怎么访问量这么高?一定是其他两家禽兽写的爬虫没有限制好频率。妈的,老子要报仇!于是分别做反爬虫,不让对方抓自己的数据。然后进一步强化自己的爬虫团队抓别人的数据。一定要做到:宁叫我抓天下人,休叫天下人抓我。然后,做反爬虫的就要加班天天研究如何拦截爬虫,做爬虫的被拦截了,就要天天研究如何破解反爬虫策略。大家就这么把资源全都浪费在没用的地方了,直到大家合并了,才会心平气和的坐下来谈谈,都少抓点。最近国内的公司有大量的合并,我猜这种“心平气和”应该不少吧?爬虫反爬虫技术现状下面我们谈谈,爬虫和反爬虫分别都是怎么做的。为 Python 平反首先是爬虫,爬虫教程你到处都可以搜的到,大部分是 Python 写的。我曾经在一篇文章提到过:用 Python 写的爬虫是最薄弱的,因为天生并不适合破解反爬虫逻辑,因为反爬虫都是用 JavaScript 来处理。然而慢慢的,我发现这个理解有点问题(当然我如果说我当时是出于工作需要而有意黑 Python,你们信吗。。。)。Python 的确不适合写反爬虫逻辑,但是 Python 是一门胶水语言,他适合捆绑任何一种框架。而反爬虫策略经常会变化的翻天覆地,需要对代码进行大刀阔斧的重构,甚至重写。这种情况下,Python 不失为一种合适的解决方案。 举个例子,你之前是用 selenium 爬取对方的站点,后来你发现自己被封了,而且封锁方式十分隐蔽,完全搞不清到底是如何封的,你会怎么办?你会跟踪 selenium 的源码来找到出错的地方吗?你不会,你只会换个框架,用另一种方式来爬取,然后你就把两个框架都浅尝辄止地用了下,一个都没有深入研究过。因为没等你研究好,也许人家又换方式了,你不得不再找个框架来爬取。毕竟,老板等着明天早上开会要数据呢。老板一般都是早上八九点开会,所以你七点之前必须搞定。等你厌倦了,打算换个工作的时候,简历上又只能写“了解 n 个框架的使用”,仅此而已。 这就是爬虫工程师的宿命,爬虫工程师比外包还可怜。外包虽然不容易积累技术,但是好歹有正常上下班时间,爬虫工程师连这个权利都没有。 然而反爬虫工程师就不可怜了吗?也不是的,反爬虫有个天生的死穴,就是:误伤率。 无法绕开的误伤率我们首先谈谈,面对对方的爬虫,你的第一反应是什么?如果限定时间的话,大部分人给我的答案都是:封杀对方的 IP。然而,问题就出在,IP 不是每人一个的,大的公司有出口 IP,ISP 有的时候会劫持流量让你们走代理,有的人天生喜欢挂代理,有的人为了翻墙 24 小时挂 VPN。最坑的是,现在是移动互联网时代,你如果封了一个 IP?不好意思,这是中国联通的 4G 网络,5 分钟之前还是别人,5 分钟之后就换人了哦!因此,封 IP 的误伤指数最高,并且,效果又是最差的,因为现在即使是最菜的新手,也知道用代理池了。你们可以去淘宝看下,几十万的代理价值多少钱?我们就不谈到处都有的免费代理了。也有人说:我可以扫描对方端口,如果开放了代理端口,那就意味着是个代理,我就可以封杀了呀。 事实是残酷的,我曾经封杀过一个 IP,因为他开放了一个代理端口,而且是个很小众的代理端口。不出一天就有人来报事件,说我们一个分公司被拦截了,我一查 IP,还真是我封的 IP。我就很郁闷地问他们 IT,开这个端口干什么?他说做邮件服务器啊。我说为啥要用这么奇怪的端口?他说,这不是怕别人猜出来么?我就随便取了个。扫描端口的进阶版,还有一种方式,就是去订单库查找这个 IP 是否下过订单,如果没有,那么就是安全的;如果有,那就不安全,有很多网站会使用这个方法。然而这只是一种自欺欺人的办法而已,只需要下一单,就可以永久洗白自己的 IP,天下还有比这更便宜的生意吗?因此,封 IP,以及封 IP 的进阶版:扫描端口再封 IP,都是没用的。根本不要考虑从 IP 下手,因为对手会用大量的时间考虑如何躲避 IP 封锁,你干嘛和人家硬碰呢?这没有任何意义。那么,下一步你会考虑到什么?很多站点的工程师会考虑:既然没办法阻止对方,那我就让它变的不可读吧。我会用图片来渲染关键信息,比如价格。这样,人眼可见,机器识别不出来。 这个想法曾经是正确的,然而,坑爹的技术发展,带给我们一个坑爹的技术,叫机器学习。顺便带动了一个行业的迅猛发展,叫 OCR。很快,识别图像就不再是任何难题了,甚至连人眼都很难识别的验证码,有的 OCR 都能搞定,比我肉眼识别率都高。更何况,现在有了打码平台,用资本都可以搞定,都不需要技术。那么,下一步你会考虑什么?这个时候,后端工程师已经没有太多的办法可以搞了。 不过后端搞不定的事情,一般都推给前端啊,前端从来都是后端搞不定问题时的背锅侠。多少年来我们都是这么过来的,前端工程师这个时候就要勇敢地站出来了:“都不要得瑟了,来比比谁的前端知识牛逼,你牛逼我就让你爬。”我不知道这篇文章的读者里有多少前端工程师,我只是想顺便提一下:你们以后将会是更加抢手的人才。前端工程师的逆袭我们知道,一个数据要显示到前端,不仅仅是后端输出就完事了,前端要做大量的事情,比如取到 json 之后,至少要用 template 转成 html 吧?这已经是步骤最少最简单的了,然后你总要用 css 渲染下吧? 这也不是什么难事。等等,你还记得自己第一次做这个事情的时候的经历吗?真的,不是什么难事吗?有没有经历过,一个 html 标签拼错,或者没有闭合,导致页面错乱?一个 css 没弄好,导致整个页面都不知道飘到哪去了?这些事情,你是不是很想让别人再经历一次?这件事情充分说明了:让一个资深的前端工程师来把事情搞复杂一点,对方如果配备了资深前端工程师来破解,也需要耗费 3 倍以上的时间。毕竟是读别人的代码,别人写代码用了一分钟,你总是要读两分钟,然后骂一分钟吧?这已经算很少的了。如果对方没有配备前端工程师。。。那么经过一段时间,他们会成长为前端工程师。之后,由于前端工程师的待遇比爬虫工程师稍好一些,他们很快会离职做前端,既缓解了前端人才缺口,又可以让对方缺人,重招。而他们一般是招后端做爬虫,这些人需要再接受一次折磨,再次成长为前端工程师,这不是很好的事情吗?所以,如果你手下的爬虫工程师离职率很高,请仔细思考下,是不是自己的招聘方向有问题。那么前端最坑爹的技术是什么呢?前端最坑爹的,也是最强大的,就是我们的:JavaScript。JavaScript 有大量的花样可以玩,毫不夸张的说,一周换一个 feature(Bug)给对方学习,一年不带重样的。这个时候你就相当于一个面试官,对方要通过你的面试才行。举个例子,在 Array.prototyp e里,有没有 map 啊?什么时候有啊?你说你是 xx 浏览器,那你这个应该是有还是应该没有啊?你说这个可以有啊?可是这个真没有啊。那[]能不能在 string 里面获取字符啊?哪个浏览器可以哪个不行啊?咦!你为什么支持 WebKit 前缀啊?等等,刚刚你还支持怎么现在不支持了啊?你声明的不对啊。这些对于前端都是简单的知识,已经习以为常了,但是对于后端来说简直就是噩梦。然而,前端人员自己作死,研究出了一个东西,叫:Nodejs。基于 V8,秒杀所有的 js 运行。不过 Nodejs 实现了大量的 feature,都是浏览器不存在的,你随随便便访问一些东西(比如你为什么会支持 process.exit),都会把 node 坑的好惨好惨。而且浏览器里的 js,你拉到后台用 Nodejs 跑,你是不是想到了什么安全漏洞?这个是不是叫,代码与数据混合?如果他在 js 里跑点恶心的代码,浏览器不支持但是 node 支持怎么办?还好,爬虫工程师还有 phantomjs。但是,你怎么没有定位啊? 哈哈,你终于模拟出了定位。但是不对啊,根据我当前设置的安全策略你现在不应该能定位啊?你是怎么定出来的?连 phantomjs 的作者自己都维护不下去了,你真的愿意继续用吗?当然了,最终,所有的反爬虫策略都逃不脱被破解的命运。但是这需要时间,反爬虫需要做的就是频繁发布,拖垮对方。如果对方两天可以破解你的系统,你就一天一发布,那么你就是安全的。这个系统甚至可以改名叫做“每天一道反爬题,轻轻松松学前端”。误伤,还是误伤这又回到了我们开始提到的“误伤率”的问题了。我们知道,发布越频繁,出问题的概率越高。那么,如何在频繁发布的情况下,还能做到少出问题呢?此外还有一个问题,我们写了大量的“不可读代码”给对方,的确能给对方造成大量的压力,但是,这些代码我们自己也要维护啊。如果有一天忽然说,没人爬我们了,你们把代码下线掉吧。这个时候写代码的人已经不在了,你们怎么知道如何下线这些代码呢?这两个问题我暂时不能公布我们的做法,但是大家都是聪明人,应该都是有自己的方案的,软件行业之所以忙的不得了,无非就是在折腾两件事,一个是如何将代码拆分开,一个是如何将代码合并起来。关于误伤率,我只提一个小的 tip:你可以只开启反爬虫,但是不拦截,先放着,发统计信息给自己,相当于模拟演练。等统计的差不多了,发现真的开启了也不会有什么问题,那就开启拦截或者开启造假。这里就引发了一个问题,往往一个公司的各个频道,爬取难度是不一样的。原因就是,误伤检测这种东西与业务相关,公司的基础部门很难做出通用的,只能各个部门自己做,甚至有的部门做了有的没做。因此引发了爬虫界一个奇葩的通用做法:如果 PC 页面爬不到,就去 H5 试试,如果 H5 很麻烦,就去 PC 碰碰运气。爬虫反爬虫套路现状那么一旦有发现对方数据造假怎么办?早期的时候,大家都是要抽查数据,通过数据来检测对方是否有造假,这个需要人工核对,成本非常高。可是那已经是洪荒时代的事情了。如果你们公司还在通过这种方式来检测,说明你们的技术还比较落伍。之前我们的竞争对手是这么干的:他们会抓取我们两次,一次是他们解密出来 key 之后,用正经方式来抓取,这次的结果定为 A。一次是不带 key,直接来抓,这次的结果定为 B。根据前文描述,我们可以知道,B 一定是错误的。那么如果 A 与 B 相等,说明自己中招了,这个时候会停掉爬虫,重新破解。不要回应所以之前有一篇关于爬虫的文章,说如何破解我们的。一直有人要我回复下,我一直觉得没什么可以回复的。第一,反爬虫被破解了是正常的。这个世界上有个万能的爬虫手段,叫“人肉爬虫”。假设我们就是有钱,在印度开个分公司,每天雇便宜的劳动力用鼠标直接来点,你能拿我怎么办?第二,我们真正关心的是后续的这些套路。而我读了那篇文章,发现只是调用了selenium并且拿到了结果,就认为自己成功了。我相信你读到这里,应该已经明白为什么我不愿意回复了。我们最重要的是工作,而不是谁打谁的脸。大家如果经常混技术社区就会发现,每天热衷于打别人脸的,一般技术都不是很好。当然这并不代表我们技术天下第一什么的,我们每天面对大量的爬虫,还是遇到过很多高手的。就如同武侠小说里一样,高手一般都比较低调,他们默默地拿走数据,很难被发现,而且频率极低,不会影响我们的考评。你们应该明白,这是智商与情商兼具的高手了。我们还碰到拉走我们 js,砍掉无用的部分直接解出 key,相当高效不拖泥带水的爬虫,一点废请求都没有(相比某些爬虫教程,总是教你多访问,写没用的 url 免得被发现,真的不知道高到哪里去了。这样做除了会导致机器报警,导致对方加班封锁以外,对你自己没有任何好处)。而我们能发现这一点仅仅是是因为他低调地写了一篇博客,通篇只介绍技术,没有提任何没用的东西。这里我只是顺便发了点小牢骚,就是希望后续不要总是有人让我回应一些关于爬虫的文章。线下我认识很多爬虫工程师,水平真的很好,也真的很低调(不然你以为我是怎么知道如何对付爬虫的。。。),大家都是一起混的,不会产生“一定要互相打脸”的情绪。进化早期我们和竞争对手打的时候,双方的技术都比较初级。后来慢慢的,爬虫在升级,反爬虫也在升级,这个我们称为“进化”。我们曾经给对方放过水,来试图拖慢他们的进化速度,然而,效果不是特别理想。爬虫是否进化,取决于爬虫工程师自己的 KPI,而不是反爬虫的进化速度。后期打到白热化的时候,用的技术越来越匪夷所思。举个例子,很多人会提,做反爬虫会用到 canvas 指纹,并认为是最高境界。其实这个对于反爬虫来说也只是个辅助,canvas 指纹的含义是,因为不同硬件对 canvas 支持不同,因此你只要画一个很复杂的 canvas,那么得出的 image,总是存在像素级别的误差。考虑到爬虫代码都是统一的,就算起 selenium,也是 Ghost 的,因此指纹一般都是一致的,因此绕过几率非常低。但是!这个东西天生有两个缺陷。第一是,无法验证合法性。当然了,你可以用非对称加密来保证合法,但是这个并不靠谱。其次,canvas 的冲突概率非常高,远远不是作者宣称的那样,冲突率极低。也许在国外冲突是比较低,因为国外的语言比较多。但是国内公司通常是 IT 统一装机,无论是软件还是硬件都惊人的一致。我们测试 canvas 指纹的时候,在携程内部随便找了 20 多台机器,得出的指纹都完全一样,一丁点差别都没有。因此,有些“高级技巧”一点都不实用。法律途径此外就是大家可能都考虑过的:爬虫违法吗?能起诉对方让对方不爬吗?法务给的答案到是很干脆,可以,前提是证据。遗憾的是,这个世界上大部分的爬虫爬取数据是不会公布到自己网站的,只是用于自己的数据分析。因此,即使有一些关于爬虫的官司做为先例,并且已经打完了,依然对我们没有任何帮助。反爬虫,在对方足够低调的情况下,注定还是个技术活。搞事情,立 Flag到了后来,我们已经不再局限于打打技术了,反爬虫的代码里我们经常埋点小彩蛋给对方,比如写点注释给对方。双方通过互相交战,频繁发布,居然聊的挺 high 的。比如问问对方,北京房价是不是很高啊?对方回应,欧巴,我可是凭本事吃饭哦。继续问,摇到号了吗?诸如此类等等。这样的事情你来我往的,很容易动摇对方的军心,还是很有作用的。试想一下,如果你的爬虫工程师在大年三十还苦逼加班的时候,看到对方留言说自己拿到了 n 个月的年终奖,你觉得你的工程师,离辞职还远吗?最后,我们终于搞出了大动作,觉得一定可以坑对方很久了。我们还特意去一家小火锅店吃了一顿,庆祝一下,准备明天上线。大家都知道,一般立 Flag 的下场都比较惨的,两个小时的自助火锅,我们刚吃五分钟,就得到了我们投资竞争对手的消息。后面的一个多小时,团队气氛都很尴尬,谁也说不出什么话。我们组有个实习生,后来鼓足勇气问了我一个问题:“我还能留下来吗?”毕竟,大部分情况下,技术还是要屈服于资本的力量。爬虫反爬虫的未来与竞争对手和解之后,我们去拜访对方,大家坐在了一起。之前网上自称妹子的,一个个都是五大三粗的汉子,这让我们相当绝望。在场唯一的一个妹子还是我们自己带过去的(就是上面提到的实习生),感觉套路了这么久,最终还是被对方套路了。好在,吃的喝的都很好,大家玩的还是比较 high 的。后续就是和平年代啦,大家不打仗了,反爬虫的逻辑扔在那做个防御,然后就开放白名单允许对方爬取了。群里经常叫的就是:xxx 你怎么频率这么高,xxx 你为什么这个接口没给我开放,为什么我爬的东西不对我靠你是不是把我封了啊,诸如此类的。和平年代的反爬虫比战争年代还难做,因为战争年代,误伤率只要不是太高,公司就可以接受。和平年代大家不能搞事情,误伤率稍稍多一点,就会有人叫:好好的不赚钱,瞎搞什么搞。此外,战争年代只要不拦截用户,就不算误伤。和平年代还要考虑白名单,拦截了合作伙伴也是误伤,因此各方面会更保守一些。不过,总体来说还是和平年代比较 happy,毕竟,谁会喜欢没事加班玩呢。然而和平持续的不是很久,很快就有了新的竞争对手选择爬虫来与我们打,毕竟,这是一个利益驱使的世界。只要有大量的利润,资本家就会杀人放火,这不是我们这些技术人员可以决定的,我们希望天下无虫,但是我们又有什么权利呢。好在,这样可以催生更多的职位,顺便提高大家的身价,也算是个好事情吧。
01-26
2018
Facebook如何运用机器学习进行亿级用户数据处理
2017年末,Facebook应用机器学习组发布最新论文,对整个Facebook的机器学习软硬件架构进行了介绍。纵览全文,我们也可以从中对Facebook各产品的机器学习策略一窥究竟。论文中涉及到机器学习在全球规模(上亿级数据处理)上的全新挑战,并给出了Facebook的应对策略和解决思路,对相关行业和研究极其有意义。摘要机器学习在Facebook的众多产品和服务中都有着举足轻重的地位。 本文将详细介绍Facebook在机器学习方面的软硬件基础架构,如何来满足其全球规模的运算需求。Facebook的机器学习需求极其繁杂:需要运行大量不同的机器学习模型。这种复杂性已经深深刻在Facebook系统堆栈的所有层面上。此外,Facebook存储的所有数据,有相当大一部分会流经机器学习管道,这样的数据载荷为Facebook的分布式高性能训练流带来巨大的压力。计算需求也非常紧张,在保持用于训练的GPU/CPU平台的同时平衡出大量CPU容量用于实时推理,也带来了异常紧张的。这些问题及其他难题的解决,仍有待我们在跨越机器学习算法、软件和硬件设计上持久而不懈的努力。引言Facebook的使命是“为人类构建社交关系赋能,让世界联系更加紧密”。截至2017年12月,Facebook已经连接了全球超过20亿的人口。同时,过去几年来,机器学习同样在这样一种全球尺度的实际问题上进行着一场革命,包括在机器学习算法创新方面的良性循环,用于模型训练的海量数据以及高性能计算机体系结构的进步。在Facebook上,机器学习几乎在提升用户体验的所有层面都发挥着关键作用,包括诸如新闻推送语音和文本翻译以及照片和实时视频分类的排名等服务。Facebook在这些服务中用到了各种各样的机器学习算法,包括支持向量机,梯度boosted决策树和许多类型的神经网络。本文将介绍Facebook的数据中心架构支持机器学习需求的几个重要层面。其架构包括了内部的“ML-as-a-Service”流,开源机器学习框架,和分布式训练算法。从硬件角度来看,Facebook利用了大量的CPU和GPU平台来训练模型,以便在所需的服务延迟时间内支持模型的训练频率。对于机器学习推理过程,Facebook主要依靠CPU来处理所有主要的服务,而其中神经网络排名服务(比如新闻推送)占据着所有计算负载的大头。Facebook所存储的海量数据中,有一大部分要流经机器学习管道,并且为了提高模型质量,这一部分的数据量还在随着时间推移不断增加。提供机器学习服务所需的大量数据成为了Facebook的数据中心将要在全球规模上面临的挑战。目前已有的可被用来向模型高效地提供数据的技术有,数据反馈和训练的解耦操作,数据/计算协同定位和网络优化。与此同时,Facebook公司这样大的计算和数据规模自身还带来了一个独特的机会。在每天的负载周期内,非高峰期都会空闲出大量可以用来进行分布式训练算法的CPU。Facebook的计算集群(fleet)涉及到数十个数据中心,这样大的规模还提供了一种容灾能力。及时交付新的机器学习模型对于Facebook业务的运营是非常重要的,为了保证这一点,容灾规划也至关重要。展望未来,Facebook希望看到其现有的和新的服务中的机器学习使用频率快速增长。当然,这种增长也将为负责这些服务架构的团队在全球规模的拓展性上带来更加严峻的挑战。尽管在现有平台上优化基础架构对公司是一个重大的机遇,但我们仍然在积极评估和摸索新的硬件解决方案,同时保持对于算法创新的关注。本文(Facebook对机器学习的看法)的主要内容包括:机器学习正在被广泛应用在Facebook几乎所有的服务,而计算机视觉只占资源需求的一小部分。Facebook所需的大量机器学习算法极其繁杂,包括但不限于神经网络我们的机器学习管道正在处理海量的数据,而这会带来计算节点之外的工程和效率方面的挑战。Facebook目前的推理过程主要依靠CPU,训练过程则是同时依靠CPU和GPU。但是从性能功耗比的角度来看,应当不断对新的硬件解决方案进行摸索和评估。全球用户用来使用Facebook的设备每天都可达数亿台,而这会就会提供大量可以用于机器学习任务的机器,例如用来进行大规模的分布式训练。Facebook的机器学习机器学习(ML)是指利用一系列输入来建立一个可调模型,并利用该模型创建一种表示,预测或其他形式的有用信号的应用实例。图1. Facebook的机器学习流程和架构示例图1所示的流程由以下步骤组成,交替执行:建立模型的训练阶段。这个阶段通常离线运行。在应用中运行训练模型的推理阶段,并进行(一组)实时预测。这个阶段是在线执行的。模型进行训练的频率要比推理少得多——推理的时间规模虽然在不断变化,但一般在几天左右。训练也需要相当长的时间来完成,通常是几个小时或几天。同时,根据产品实际需求不同,在线推理阶段每天可能运行达数十万次,而且一般需要实时进行。在某些情况下,特别是对于推荐系统,还需要以这样连续的方式在线进行额外的训练。在Facebook,机器学习的一个显著特征就是有可用于模型训练的海量数据。这个数据的规模会带来很多涉及到整个机器学习架构的影响。使用机器学习的主要服务消息推送消息推送排名算法能够使用户在每次访问Facebook时,最先看到对他们来讲最重要的事情。一般模型会通过训练来确定影响内容排序的各种用户和环境因素。之后,当用户访问Facebook时,该模型会从数千个候选中生成一个最佳推送,它是一个图像和其他内容的个性化集合,以及所选内容的最佳排序。广告广告系统利用机器学习来确定向特定用户显示什么样的广告。通过对广告模型进行训练,我们可以了解用户特征,用户上下文,以前的互动和广告属性,进而学习预测用户在网站上最可能点击的广告。之后,当用户访问Facebook时,我们将输入传递进训练好的模型运行,就能立马确定要显示哪些广告。搜索搜索会针对各种垂直类型(例如,视频,照片,人物,活动等)启动一系列特定的子搜索进程。分类器层在各类垂直类型的搜索之前运行,以预测要搜索的是垂直类型中的哪一个,否则这样的垂直类型搜索将是无效的。分类器本身和各种垂直搜索都包含一个训练的离线阶段,和一个运行模型并执行分类和搜索功能的在线阶段。SigmaSigma是一个分类和异常检测通用框架,用于监测各种内部应用,包括站点的完整性,垃圾邮件检测,支付,注册,未经授权的员工访问以及事件推荐。Sigma包含了在生产中每天都要运行的数百个不同的模型,并且每个模型都会被训练来检测异常或更一般地分类内容。LumosLumos能够从图像及其内容中提取出高级属性和映射关系,使算法能够自动理解它们。这些数据可以用作其他产品和服务的输入,比如通过文本的形式。FacerFacer是Facebook的人脸检测和识别框架。给定一张图像,它首先会寻找该图像中所有的人脸。然后通过运行针对特定用户的人脸识别算法,来确定图中的人脸是否是该用户的好友。Facebook通过该服务为用户推荐想要在照片中标记的好友。语言翻译语言翻译是涉及Facebook内容的国际化交流的服务。Facebook支持超过45种语言之间的源语言或目标语言翻译,这意味着Facebook支持2000多个翻译方向,比如英语到西班牙语,阿拉伯语到英语。通过这2000多个翻译通道,Facebook每天提供4.5B字的翻译服务,通过翻译用户的消息推送,Facebook每天可为全球6亿人减轻语言障碍。目前,每种语言对方向都有其自己的模型,但是我们也正在考虑多语言模型[6]。语音识别语音识别是将音频流转换成文本的服务。它可以为视频自动填补字幕。目前,大部分流媒体都是英文的,但在未来其他语言的识别也将得到支持。另外,非语言的音频文件也可以用类似的系统(更简单的模型)来检测。除了上面提到的主要产品之外,还有更多的长尾服务也利用了各种形式的机器学习。 Facebook产品和服务的长尾数量达数百个。机器学习模型所有基于机器学习的服务都使用“特征”(或输入)来产生量化的输出。Facebook使用的机器学习算法包括Logistic回归(LR),支持向量机(SVM),梯度提升决策树(GBDT)和深度神经网络(DNN)。LR和SVM在训练和预测方面非常有效。GBDT可以通过增加计算资源来提高准确性。DNN是最具表达力的,能够提供最高的准确性,但利用的资源也是最多的(在计算量上,至少比LR和SVM等线性模型高出一个数量级)。这三种模型的自由参数都在变得越来越多,必须通过使用带标签的输入示例来优化预测的准确性。在深度神经网络中,有三类经常使用的网络:多层感知器(MLP),卷积神经网络(CNN)和递归神经网络(RNN / LSTM)。MLP网络通常运行在结构化输入特征(通常是排名)上,RNN / LSTM网络一般用来处理时域的数据,即用作序列处理器(通常是语言处理),相对的CNNs则是一种处理用来空间数据的工具(通常是图像处理)。表I显示了这些机器学习模型类型和产品/服务之间的映射关系。表1 利用机器学习算法的产品或服务Facebook中的ML-as-a-Service为了简化在产品中应用机器学习的任务,我们构建了一些内部平台和工具包,包括FBLearner,Caffe2和PyTorch。FBLearner是三种工具(FBLearner Feature Store,FBLearner Flow,FBLearner Predictor)的套装,其中每种工具分别负责机器学习管道上不同的部分。正如前面图1显示的那样,它利用了一种内部作业调度程序在GPU和CPU的共享资源池上分配资源和调度作业。Facebook大多数机器学习模型的训练过程都是在FBLearner平台上进行的。这些工具和平台被设计来帮助机器学习工程师提高效率,从而能够专注于算法创新。FBLearner Feature Store。任何机器学习建模任务的起点是收集和生成特征。 FBLearner Feature Store本质上是一系列特征生成器的目录,其特征生成器可以用于训练和实时预测,当然它也可以作为多个团队可以用来共享和寻找特征的公共空间(market place)。这样以个特征列表对于刚开始使用机器学习的团队来说是一个很好的平台,同时也有助于在现有模型中应用新特征。FBLearner Flow是Facebook用于训练模型的机器学习平台。Flow是一个管道管理系统,它会执行一个可以描述模型训练和/或评估所需步骤及其所需资源的工作流程(workflow)。这个工作流程由离散单元或操作符(operators)构成,每个单元都有输入和输出。操作符之间的连接会通过跟踪一个操作符到下一个操作符的数据流自动推理,Flow则通过处理调度和资源管理来执行工作流程。Flow还拥有一个可以用于实验管理的工具和一个简单的用户界面,这个界面可以跟踪每个workflow或实验生成的所有构件和指标,从而方便对比和管理这些实验。FBLearner Predictor是Facebook内部的推理引擎,它可以使用在Flow中训练的模型来提供实时的预测。Predictor可以用作多租户服务,也可以用作集成在特定产品的后端服务中的库。Facebook的很多产品团队都在使用Predictor,而其中许多团队都需要低延迟解决方案。Flow和Predictor之间的直接集成还有助于运行在线的实验以及在生产中管理多个版本的模型。深度学习框架我们在Facebook上利用了两种截然不同的协同框架来进行深度学习:针对研究优化的PyTorch和针对生产优化的Caffe2。Caffe2是Facebook的内部生产框架,它用于训练和部署大规模的机器学习模型。Caffe2专注于产品所需的几个关键特性:性能,跨平台支持和基本的机器学习算法,如卷积神经网络(CNN),递归神经网络(RNN)和多层感知器(MLP)。这些网络都具有稀疏或密集的连接以及高达数百亿的参数。该框架的设计采用模块化方法,在所有后端实现(CPU,GPU和加速器)之间共享统一的图表示。为了在不同平台上实现最佳的运行时间,Caffe2还抽象了包括cuDNN,MKL和Meta在内的第三方库。PyTorch是Facebook在AI研究领域的首选框架。它的前端注重灵活性、调试以及动态神经网络,能够快速进行实验。由于依赖于Python来执行,它并没有针对生产和移动端部署进行优化。当研究项目产生了有价值的结果时,模型就需要转移到生产上。过去,在生产环境中,我们通过使用其他框架重写产品环境的训练管道来完成模型转移。最近Facebook开始构建ONNX工具链来简化这个转移过程。比如,动态神经网络虽然被用于尖端的人工智能研究,但这些模型需要更长的时间才能被应用于产品中。通过解耦框架,我们避免了的为满足性能而设计更复杂的执行引擎(比如Caffe2)的需求。此外,相比模型速度,研究人员在进行研究时更看重其灵活性。举个栗子,在模型探索阶段,性能下降30%是可以容忍的,尤其是在它具有易测验和模型可视化的优点时。但是相同的方法并不适合于生产。这种取舍原则在PyTorch和Caffe2的框架设计中也可以看到,PyTorch提供了良好的默认参数和合理的性能,而Caffe2可以选择使用异步图执行,量化权重和多个专用后端等特性来达到最佳性能。虽然FBLearner平台本身不限制使用什么框架,无论是Caffe2,TensorFlow,PyTorch还是其他的框架都可以,但我们的AI软件平台(AI Software Platform)团队为了让FBLearner能够很好地与Caffe2集成还是进行了特定优化。总的来说,分离研究和生产框架(分别是PyTorch和Caffe2)使我们能够在两边灵活运作,减少约束数量的同时还能增加新特性。ONNX. 深度学习工具生态系统在整个行业还处于初级阶段。 对于不同的问题子集,不同的工具有着不同的优势,并且在灵活性,性能和支持平台方面有着不同的折衷,这就跟我们之前对PyTorch和Caffe2所描述的权衡一样。 因此,在不同的框架或平台之间交换训练模型的需求很大。 为了弥补这个缺陷,2017年末,Facebook与几个合作伙伴共同推出了开放式神经网络交换(Open Neural Network Exchange , ONNX)。ONNX是一种以标准方式表示深度学习模型的格式,以便在不同的框架和供应商优化库之间实现互操作。同时,它能满足在不同的框架或平台之间交换训练好的模型的需求。ONNX被设计为一种开放的规范,允许框架作者和硬件供应商为其做出贡献,并拥有框架和库之间的各种转换器。Facebook正在努力使ONNX成为所有这些工具之间的协作伙伴,而不是一种具有排他性的官方标准。在Facebook内部,ONNX是我们将研究模型从PyTorch环境转移到Caffe2中的高性能生产环境的主要手段,它可以实现对模型的自动捕捉和固定部分的转换。在Facebook内部,ONNX是我们将研究模型从PyTorch环境转移到Caffe2中的高性能生产环境的主要手段。 ONNX提供了自动捕捉和转换模型的静态部分的能力。 我们有一个额外的工具链,通过将它们映射到Caffe2中的控制流原函数或者以C ++作为自定义操作符重新实现它们,会有助于将模型从Python转移到动态图。机器学习的资源需求鉴于机器学习在训练和推理(inference)的阶段的资源要求、频率和持续时长不同,我们将分别讨论这两个阶段的细节和资源应用。Facebook硬件资源概况Facebook的基础架构部门(Facebook Infrastructure)很早之前就开始为主要软件服务构建的高效平台,包括针对每种主要工作负载的资源要求定制的服务器、存储以及网络支持。图2 基于CPU的计算服务器。单插槽服务器底座上有4个Monolake服务器卡,双插槽服务器底座还一个双插槽服务器,因此在2U机箱中共有三个双插槽服务器。所以在2U形式的组合中共有12个服务器。当前Facebook提供约八种主要的计算和存储架构,对应八种主要服务。这些主要架构类型足以满足Facebook主要服务的资源要求。例如,图2中展示了一个可以容纳三个计算Sleds模块的2U机架,这些模块可支持两种服务器类型。其中一种Sled模块是单插槽CPU服务器(1xCPU),多用于Web层——一种主要看重吞吐量的无状态服务,因此可以使用能效更高的CPU(Broadwell-D处理器);它的DRAM(32GB)以及主板硬盘或闪存较少。另一种Sled模块是较大的双插槽CPU服务器(2x高功率Broadwell-EP或Skylake SP CPU),它配有大量的DRAM ,常用于涉及大量计算和存储的服务。图3. 搭载8个GPU的Big Basin GPU服务器(3U机架)由于我们训练的神经网络越来越大,并且越来越深,我们开发出了Big Basin GPU服务器(如图3所示),这是我们2017年最新的GPU服务器。最初的Big Basin GPU服务器配置了八个互相连接的NVIDIA Tesla P100 GPU加速器,它使用NVIDIA NVLink形成了一个八CPU混合立方网格,后来,这种设计经过改进之后又应用到了V100 GPU上。Big Basin是早前的Big Sur GPU的继承者,后者是Facebook数据中心首个广泛应用的高性能AI计算平台,用于支持于2015年开发并通过开放计算项目(Open Compute Project)发布的NVIDIA M40 GPU。与Big Sur相比,V100 Big Basin每瓦电可实现的性能更高,这得益于单精度浮点运算单元——每个GPU的运算速度从7 teraflops(每秒万亿次浮点运算)增加到了15.7 teraflops,以及可提供900GB/s的带宽的高带宽显存(HBM2)。这种新的架构还使得半精度运算的速度快了一倍,进一步提高了运算吞吐量。由于Big Basin的运算吞吐量更大,而且显存也从12 GB增加到了16 GB,因此它可以用来训练比先前模型大30%的模型。高带宽NVLink互连GPU通信还强化了分布式训练。在使用ResNet-50图像分类模型进行的测试中,Big Basin的运算吞吐量比Big Sur要高出300%,借助它我们可以以更快的速度训练比以往更复杂的模型。Facebook通过开放计算项目(Open Compute Project)公布了所有这些计算服务器的设计以及几种存储平台。离线训练的资源需求当前,不同的产品会使用不同的计算资源来完成各自的离线训练步骤。有些产品(例如Lumos)在GPU上完成所有的训练。其他产品(例如Sigama)则在双插槽 CPU计算服务器完成所有的训练。诸如Facer这样的产品采用双阶段训练流程,先在GPU上以很小的频率(几个月一次)队通用的面部检测和识别模型进行训练,然后在数千个1xCPU服务器上以很高的频率对每个用户的模型进行特定训练。在本部分,我们将围绕机器学习训练平台、训练频率和持续时长,具体介绍多种服务的细节,并在表II中进行了总结。另外,我们还讨论了数据集的趋势以及这些趋势对计算、内存、存储和网络架构的意义。计算类型和相对数据来源的位置。离线训练既可以在CPU上完成,也可以在GPU上完成,这取决于服务本身。虽然在多数情况下,在GPU上训练出的模型在性能上要比在CPU上训练的模型好,但是CPU强大的现成运算能力使得它成为了一个非常有用的平台。这一点在每天的非高峰期中尤为明显,因为在这期间CPU资源本来就无法得到利用,后面的图4会对此进行说明。下面我们给出了服务和计算资源训练模型的对应关系:在GPU上训练模型的服务: Lumos、语音识别、语言翻译在CPU上训练模型的服务:News Feed、Sigma在GPU和CPU上训练模型的服务:Facer (在GPU上每几年训练一次的通用模型,此类模型较为稳定;在1xCPU上训练的用户特定的模型,此类模型可以用于处理新图像数据)、搜索(利用多个独立的垂直搜索引擎,使用可以进行预测的分类器启动最合适的垂直搜索引擎)。目前,GPU主要被用于离线训练,而不是向用户提供实时数据。因为大多数GPU架构都针对运算吞吐量进行了优化,以克服延迟劣势。同时由于训练过程严重依赖从大型数据生成库中获取的数据,考虑到性能和带宽方面的原因,GPU必须靠近数据来源。由于训练模型所使用的数据量增长的相当快,GPU是否靠近数据来源变得越来越重要。内存、存储和网络:从内存储器容量的角度看,CPU和GPU平台都能为训练提供充足的存储容量。即使对于Facer这样的应用,也可以在1xCPU上用32GB RAM训练用户特定的SVM模型。如果可以尽可能地利用高效平台以及多余的存储容量,则平台的总体训练效率会非常优秀。表II 不同服务的离线训练的频率、持续时长和资源机器学习系统依赖于使用实例数据的训练。Facebook 使用了机器学习数据管道中的大量数据。这使得计算资源趋向于靠近数据库。随着时间的推移,大多数服务会显示出利用累积的用户数据的趋势,这将导致这些服务更加依赖Facebook的其他服务,并且需要更大的网络带宽来获取数据。因此,只有在数据源所在地或附近部署巨大的存储,以便从偏远的区域大规模转移数据,从而避免为了等待获取更多样本数据而关停训练管道。在部署训练机器的位置时,我们也可以使用这种方法来避免训练机群给附近的存储资源造成过大的压力。不同的服务在离线训练期间使用的数据量有很大的差别。几乎所有服务的训练数据集都呈现出持续增长甚至大幅增长的趋势。例如,有些服务在ROI降低之前会使用数百万行数据,其他服务则使用数百亿行数据(100多TB),并且只受到资源的限制。 扩展(Scaling)考虑和分布式训练:训练神经网络的过程包含使用随机梯度下降法(SGD)对参数权重进行优化。这种方法用于拟合神经网络,通过评价标记实例的小子集(即“batch” 或“mini-batch”)来迭代更新权重。在数据并行中,网络会生成多个模型副本(并行实例),以并行的处理多批数据。当使用一台机器训练模型时,模型越大或更深都会带来更好的训练效果,准确度也会更高,但是训练此类模型往往需要处理更多的样本。当使用一台机器进行训练时,我们可以通过增加模型副本的数量并在多个GPU上执行数据并行,来最大化训练效果。当训练所需的数据量随时间增加,硬件限制会导致总体训练延迟和收敛时间增加。不过,我们可以使用分布式训练来克服这些硬件限制,减少延迟。这个研究领域在Facebook和整个AI研究界相当热门。一种普遍的假设是,在不同机器上实现数据并行需要使用一种专门的互连机制。但是,在我们对分布式训练的研究中,我们发现基于以太网(Ethernet)的网络就可以提供近似线性的扩展能力。能否实现近似线性的扩展,与模型的大小和网络带宽有密切的关系。如果网络带宽太小,执行参数同步所花的时间比执行梯度计算所花的时间还多,在不同机器上进行数据并行所带来的优势也会大打折扣。使用50G的以太网NIC,我们可以用Big Basin服务器扩展视觉模型的训练,而且机器间的同步完全不会造成问题。在所有情况下,更新都需要使用同步(每个副本都看到相同状态),一致性(每个副本生成正确更新)和性能(子线性缩放)的技术来与其他副本共享,这可能会影响训练质量。 例如,翻译服务目前就不能在不降低模型质量的情况下进行大批量的小批量(mini-batches)训练。相反,如果使用特定的超参数设置,我们就可以在非常大的mini-batch数据集上训练图像分类模型,并且可以扩展到256个以上的GPU上。实验证明,在Facebook的某个大型服务中,在5倍的机器上执行数据并行可以实现4倍的训练效率(例如:训练一组训练时间超过4天的模型,以前总共可以训练100个不同模型的机器集群现在每天只能训练同样的20个模型,训练效率降低了20%,但是潜在的工程进度等待时间从4天减少到了1天)。如果模型变得超级大,这时候就可以使用并行训练,对模型的层进行分组和分布,以优化训练效率,各机器间可以传递激活单元。优化可能与网络带宽、延迟或平衡内部机器限制有关。这会增加模型的端对端延迟,因此,每一时步(time step)内原始性能的增强通常与步长(step)质量的下降有关。这可能会进一步降低模型在每个步长的准确度。各步长准确度的下降最终会累积起来,这样我们就可以得出并行处理的最佳步长数量。DNN模型本身的设计使得它只能在一台机器上运行,在推理阶段,在机器间分割模型图通常会导致机器与机器进行大量的沟通。但是Facebook的主要服务会不断地权衡扩展模型的利与弊。这些考虑可以决定网络容量需求的变化。表 III 在线推理服务的资源要求在线推理的资源需求在完成离线训练之后的线推理步骤中,我们需要将模型载入到机器中,使用实时输入运行模型来生成网站流量的实时结果。接下来我们将讨论,一种实际应用中的在线推理模型——广告排名模型。这种模型可以筛选成千上万条广告,在消息推送中显示排在1至5名的广告。这个过程是通过对依次减小的广告子集进行逐步复杂的排名运算循环(passes)来实现的。每一轮运算都会用到类似于多层感知模型(MLP)的模型,这种模型包含稀疏嵌入层,每一轮运算都会缩小广告的数量。稀疏嵌入层需要大量的内存,因此当进行到靠后的运算时,模型的超参数数量更多,它将在独立于MLP运算轮的一个服务器上运行。从计算的角度上看,绝大多数在线推理都是在大量1xCPU(单插槽)或2xCPU(双插槽)上运行的。由于1xCPU对Facebook的服务而言性能更高,而且性价比更高,因此Facebook提倡尽可能使用1xCPU服务器训练模型。随着高性能移动硬件的诞生,Facebook甚至可以在用户的移动设备上直接运行某些模型,来改进延迟和降低通信成本。但是,某些需要大量计算和内存资源的服务仍然需要使用2xCPU才能实现最佳性能。不同的产品在得出在线推理的结果时拥有不同的延迟要求。在某些情况下,得出的数据可能“十分优秀” ,也可能会在向用户返回初步快速评估后被重新输入到模型中。例如,在某些情况中将某个内容分类为合格是可以接受的,但是当运行更加复杂的模型时这个初步的分类结果就会被推翻。广告排名和消息推送之类的模型配置有稳定的SLA,可以向用户推送合适的内容。这些SLA决定着模型的复杂性和依赖性,因此如果拥有更加强大的计算能力,我们就可以训练出更加先进的模型。机器学习数据计算除了资源需求外,在数据中心部署机器学习时还需要考虑一些重要的因素,包括对重要数据的需求以及面对自然灾害的可靠性。从获取数据到模型Facebook公司的许多机器学习模型,成功的主要因素就是广泛而高质量的可用数据。快速处理并将这些数据提供给机器学习模型的能力能够确保我们部署快速有效的离线训练。对于复杂的机器学习应用程序,如广告和排名,每个训练任务所需的数据量都超过数百TB大小。此外,复杂的预处理逻辑的使用能确保数据被清理并归一化,以便高效地迁移和更轻松地学习。这些操作对资源的要求非常高,特别对存储量,网络和CPU的需求。作为一个通用的解决方案,我们尝试对训练工作量中的数据进行解耦。这两个工作量都有非常显著的特点。一方面,它非常复杂,具有临时的,依赖业务性的,且变化快等特点。另一方面,训练工作量通常是固定的(例如GEMM),稳定的(核心业务相对较少),高度优化,且更偏爱于“干净”的环境下工作(例如,独占高速缓存使用和最小线程争夺)。为了优化这两者,我们在物理上对不同的机器的不同工作负载进行隔离。数据处理机器,又名“readers”,从存储器中读取数据,处理和压缩它们,然后将结果反馈给一个叫做“trainers”的训练机器。另一方面,trainers只专注于快速有效地执行任务。readers和trainers可以分布以便提供更灵活性和可扩展性的应用。此外,我们还优化了不同工作负荷的机器配置。另一个重要的优化指标是网络使用。训练过程产生的数据流量非常重要的,并且有时候会突然产生。如果没有智能化处理的话,这很容易就会导致网络设备的饱和,甚至干扰到其他服务。为了解决这些问题,我们采用压缩优化,调度算法,数据/计算布局等等操作。利用规模作为一家为用户提供服务的全球性公司,Facebook必须保持大量服务器的设计能够满足在任何时间段内的峰值工作负载。如图所示,由于用户活动的变化取决于日常负荷以及特殊事件(例如地区节假日)期间的峰值,因此大量的服务器在特定的时间段内通常是闲置的。这就释放了非高峰时段内大量可用的计算资源。利用这些可能的异构资源,以弹性方式合理分配给各种任务。这是Facebook目前正努力探索的一大机会。对于机器学习应用程序,这提供了将可扩展的分布式训练机制的优势应用到大量的异构资源(例如具有不同RAM分配的CPU和GPU平台)的机会。但是,这也会带来一些挑战。在这些低利用率的时期,大量可用的计算资源将从根本上导致分布式训练方法的不同。调度程序首先必须正确地平衡跨越异构硬件的负载,这样主机就不必为了同步性而等待其他进程的执行。当训练跨越多个主机时,调度程序还必须要考虑网络拓扑结构和同步所需的成本。如果处理不当,机架内或机架间同步所产生的流量可能会很大,这将极大地降低训练的速度和质量。
01-23
2018
科技行业开始关注老年人需求 易用性最重要
现在科技已经深入到人们生活中的每一个角落,目标受众不仅仅是接受新事物相对更快的年轻人,为老年人定制的科技产品也不少,比如通过GPS功能定位和调整音量的助听器、能够背着老人四处走动的丰田机器人以及带有追踪报警功能的无线感应器等等。但是老年人毕竟年岁已高,学习能力和接受新事物的能力不比年轻人,很多老年人还没有或很难掌握年轻人认为简单至极的基本科技知识或技能,在这种情况下,老年人还愿意去使用这些高科技产品吗?剑桥大学工程设计中心专为老年人设计产品的专家伊恩·霍斯金(Ian Hosking)相信,我们首先应该普及最基本的科技知识。他说:“老年人中固然也有能够深入了解并娴熟使用科技的人,但是面对全新的科技产品时感到头大如斗的人显然更多。他们感觉这些新科技令人费解。”我母亲可能就属于后者。她现在已经80多岁了,为了学习使用各种最新的科技产品比如二手电脑、Kindle和在线购物,她付出了大量的努力。现在她想买一台平板电脑,但是她担心自己不会用。像她这样的人不在少数,据美国皮尤互联网研究中心调查显示,77%的老年人需要他人的帮助才能完成新设备的设置过程。Breezie专为老年人设计了一款标准三星Galaxy平板电脑的简化界面。这个界面是可以定制的,用户可以在界面上定制自己想要的功能设置和应用,去掉了老年人可能永远也会用到的预装应用。另外还简化了很多功能,比如有人想利用Skype联系好友,现在只要在地址簿中点击好友头像就行了。公司创始人杰·卡兹米(Jeh Kazimi)称,Breezie的开发灵感来自于他自己的母亲。他说:“我曾经看到她努力上网的情形,她感觉上网有些吓人,也很复杂。我没办法找到能够让互联网适合她使用的任何产品,因此我就自己来开发一款这样的产品。”他继续说:“我们的目标是设计出一些能够让在线环境更容易被不懂科技的人所接受、并且不会对他们有所限制的软件。”用户们可以通过Breezie的支持服务允许亲朋好友远程签到、设置帐户和添加新联系人。去年,Breezie与Age UK合作发布了一款售价299英镑、预装了Breezie平台的平板电脑。你可能认为老年人也能像年轻人一样去使用你认为“简单易用”的设备,但是实际上这并不容易。我自己经常使用iPad,但我认为我母亲可能就无法学会使用这款设备。苹果屏幕上的图标反应时间是0.7秒,但是绝大多数年龄超过65岁的老年人的平均反应时间大约是1秒。使用触摸屏对于小孩子来说可能没什么问题,但是对于老年人来说可能就大不一样了。随着年龄的增长,手指中神经的敏感性大幅下降,这就意味着老年人“触摸”时的力度会比较重。测试表明,如果一位老年人有轻微震颤,那么他在使用触摸屏时的一次“触摸”操作就会被设备解读为“滑动”。专为老年人设计智能手机的Emporia Telecom公司的发言人克里斯·比格内尔(Chris Bignell)说:“正是这些细微的问题击溃了老年人的信心,给他们带来了极大的困扰。”Emporia Telecom推出的手机预装了一款应用,这款应用能够指导用户练习使用触摸屏。它还推出了一款可定制的外接键盘,以满足某些仍然想使用按键的用户的需求。包括很多中国厂商在内的、越来越多的科技公司在开发硬件时开始考虑老年人和残疾人的需求,比如更大的按键、音量更高的扬声器、助听兼容性和更长的电池续航时间等等。有些公司推出了精简版移动产品,就像Age UK推出的OwnFone那样只能接电话和打电话的手机,而另一些公司则从解决具体需求入手。Doro PhoneEasy的按键和按键上印刷的字体都很大,Binatone Speakeasy则配备了内置应急按钮。但是对很多老年人来说,这些手机似乎都有些过时了,用这样的手机会让他们感觉有些丢人。霍斯金教授说:“他们在解决老龄化问题时缺乏通盘考虑,因为通常年纪比较大的人同时会有多项不便之处。”随着人口老龄化问题的日益严重,科技行业决不能对此视若罔闻。据估计,到2030年的时候,19%的美国人将是年龄超过65岁的老年人,这跟目前美国人口中拥有iPhone的人口比例差不多。而到2050年的时候,退休人口将占到总人口数的三分之一。苹果也在想办法解决这个问题,但是不会是从新硬件的角度来解决。它在上个月宣布,它将专门针对老年人设计一些“非常易用的”iPad应用。美国推出了一项名为Speaking Exchange的服务,它可以让已经退休、居住在养老院的老年人通过Skype与巴西正在学习英语的人连网,相互沟通各取所需。老年人显然期待与人交谈,巴西的青少年则可以借此提高自己的英语水平。英国也有一款类似的服务:Cloud Grannies,主要是让已经退休的老年人与印度的儿童连网交流。
01-22
2018
王健林:我犯了个错误,就是给了万达网科太多的钱
“我曾经犯的一个错误,就是给了曲德君太多的钱,我跟一些企业家讨论,他们说当初网科少给点钱,定个投资上限就好了。看来钱不能给得太多。”大连万达集团董事长王健林在集团2017年会上说道。“我曾经犯的一个错误,就是给了曲德君太多的钱”王健林表示,万达集团2018年计划收入2479亿元,增幅9%。值得一提的是,在王健林对万达集团2018年的工作计划中,并没有提到此前传出要进行业务整体转型、暂停现有业务及出售和IBM合作万达云项目的万达网络科技集团。王健林称,网科集团暂不安排收入计划,上半年内因与世界级网络巨头战略合作,待落地再安排。同时,要成立新的网科公司。王健林强调,要在战略合作确定之后,再来确定网科集团的业务目标。关于网科集团,王健林承认当初的方向有偏差,而且烧了太多的钱。王健林说:“我曾经犯的一个错误,就是给了曲德君太多的钱,我跟一些企业家讨论,他们说当初网科少给点钱,定个投资上限就好了。看来钱不能给得太多。不是说网科没有做出成绩,这一次跟别人合作谈判,使我和团队对网科有了全新认识,他们开发了一些有用的东西,只是这些东西有培育期,还不能马上被资本市场接受。原来方向也有偏差,老想大规模来做,如果就为万达广场、旅游度假区研发,可能早就整出名堂了。”文旅项目每年增加1000亿负债,十几年才能收回投资在过去的一年中,王健林以438.44亿元的价格将旗下13个文旅城项目卖给了融创中国(01918.HK),199.06亿元将77家酒店出售给了广东地产商富力地产(02777.HK)。由于万达商业转让文旅项目、酒店资产,使万达集团的资产、收入两项指标有所减少。万达集团2017年的收入为2273亿元,其中商业地产收入为1125.4亿元。而万达在海外的项目也多次被传出要找买家接手。此外,关于万达资金链紧张,多家银行停止对万达贷款的市场传言让万达经历了股债双杀,外界关于万达现如今的状况也一直猜测不断。“万达过去几年在海外投了一批项目,现在我们决定清偿海外债务,卖一半资产就能把全部债务清偿,说明我们买和卖之间赚钱了。”王健林在年会上表示:“万达卖酒店,我们搞酒店建设、管理的很多同志都说,卖了是不是太可惜?万达酒店是建得不错,成本也很低,但是酒店整体年平均回报率低于4%,全部酒店每年吃掉十几个万达广场的净利润,所以,我们决定把重资产的文旅项目和酒店卖掉,做轻资产这种只赚不赔的买卖,绝对是上策。不管社会上理不理解,也可能有些内部同志不理解,但是请大家三年以后再回头来看我们的决定是否正确。”对于出售13个文旅项目的原因,王健林称,“每个大型文化旅游项目需要七年、八年有息负债才能往下走,十几年才能收回投资。万达十几个文旅项目叠加在一起,虽然通过销售物业能回收大部分现金,但至少五到六年内,每年净增1000亿负债,压力相当大。现在全球和中国都在去杠杆、降负债,这样加杠杆、逆势而为是不科学的。”采用一切资本手段降低负债,在全球绝不会出现任何信用违约王健林说,2017年是万达集团历史上难忘的一年,万达经历了风波,承受了磨难。“转让资产减债四百多亿,回收现金近700亿,加上我们手头持有的现金,万达经营的安全性增加很多,就能承受风波的冲击。而且如果我们不转让这些资产,就不能把有限的资金投入到我们最需要发展的万达广场上去,就不能保证每年50个以上万达广场开业的计划。为了企业安全,为了保证核心产业发展,我们必须这样做。”王健林说道。关于负债的问题,王健林表示:“万达集团将采用一切资本手段降低企业负债,包括出售非核心资产、保持控制权前提下的股权交易、合作管理别人的资产等等。万达要逐步清偿全部海外有息负债,万达商业A股退市资金也有了可靠方案。同时计划用两到三年时间,将企业负债降到绝对安全的水平。今天我可以在这里负责任地说,万达集团在全球绝不会出现任何信用违约!万达30年没有出现一起信用违约,我们把信用看得比资产、利润更重要。”以下为总结全文:万达集团2017年工作总结董事长 王健林2018年1月20日各位同仁,首先我代表集团董事会对大家前来参加万达集团2017年年会表示热烈欢迎!欢迎你们回家!2017年对万达来说是非常难忘的一年,经历了风波,也承受了一些磨难。在各级政府、各个方面的大力支持下,特别是万达全体员工团结奋斗,在比较困难的经营条件下,我们较好地完成了2017年各项工作任务,下面我对2017年工作进行总结。一、去年工作主要成绩(一)全面完成工作目标2017年,万达商业转让文旅项目和酒店资产,受其影响,万达集团的资产、收入两项指标有所减少。万达集团以成本计资产7000亿元,同比减少11.5%;其中国内资产占比93%,国外资产占比7%。为什么专门提这个数据?去年有人说万达把大量资产转移到海外去了,数据证明完全不符合事实。2017年万达集团收入2273.7亿元,完成计划的113%,同比减少10.8%。减少是因为转让的文旅项目收入没有计算在内,加上2016年底我们把万达旅业资产注入一个投资企业,接近200亿的旅游收入没有计入今年报表。如果考虑旅游收入变化的影响,尽管2017年万达集团转让了大量资产,收入同比只下降1.1%。净利润完成年目标的114%,同比基本持平,说明收入含金量不错。其中:商业地产收入1125.4亿元,完成年计划的104.1%,同比减少21%;租金收入255.2亿元,完成年计划的101.4%,同比增长30.3%;新开店数占总开业店数的21%,其中还有24个轻资产项目万达只分成部分租金,而总租金增长30.3%,说明老的开业店内生租金增长比例至少两位数,也就是说万达即使不开新店,租金也较高增长。租金收缴率101%,连续12年创造租金收缴率99.5%以上的世界行业纪录。新开业广场49个,万达茂1个,万达旅游小镇1个。其中开业轻资产广场24个,这是一个很不错的成绩;开业重资产广场26个,新增持有物业面积329.6万平方米,扣除转让文旅项目、酒店减少的几百万平方米持有物业面积,万达累计持有物业面积3151.1万平方米。万达仍然是世界规模最大的不动产企业。万达广场总客流31.9亿人次,同比增长28.1%。新开业店数增长21%,其中许多店下半年才开业,而客流增长28.1%,这是一个有力的证据,说明万达广场老店客流同比也在增长。房地产收入831.7亿元,完成年计划的104%,同比减少23.7%,主要因为转让文旅项目减少房地产收入。文化集团收入637.8亿元,完成年计划的100.1%,同比增长32.6%。这是扣减万达旅业收入后同比计算。影视集团收入532亿元,完成年计划98.5%,同比增长35.9%。2016年影视集团计划收入目标为540亿元。影视集团有点遗憾,去年能完成净利润目标的114%,但收入比目标差1.5%,如果再稍微努力一点就好了,我说的是整个影视集团含海外公司收入差一点,不过国内公司还是完成了年度目标。体育集团收入71.8亿元,完成年计划的104.3%,同比增长12.3%;文旅集团收入19.5亿元,完成年计划的139.5%。宝贝王集团收入14.4亿元,完成年计划的97%,同比增长176%。金融集团收入321.2亿元,完成年计划的125.5%,这里我要特别提一句,金融集团净利润完成年计划的1961%,创万达完成计划指标的历史纪录。网络科技集团收入58.6亿元,完成年计划的90.1%。集团其它公司收入130.7亿元,平均完成年计划的106%。万达集团2017年如果把转让文旅项目的收入和注入其它公司的旅游收入算上,同比增长可以达到两位数。(二)转型发展成效显著一百年来,全球大型房企无一例转型成功,万达已经改写商业历史,成功转型为服务型为主的企业。1、服务业收入占绝大多数。万达集团2017年收入中,服务业收入占比63.4%,同比提高8.4%。近几年,万达服务业收入每年都会大幅提高,今后还会继续提高。服务业收入中,租金收入占比约18%,增速远高于万达其它产业,已经连续多年平均实现超过30%的增长。租金是最长期、稳定的现金流之一,而且利润比例高,收入占比提高说明收入含金量增加。2、文化收入占比提高。2017年,万达文化产业收入占万达集团收入比重升至28.1%,接近30%,已成为万达另一个支柱产业。希望今年文化集团努努力,看能不能超过30%。3、轻资产战略超出预期。万达转型关键是万达商业转型,万达商业转型关键是从单一重资产企业转为轻资产为主、轻重并存发展的企业。说万达转型就不再持有物业,这完全错了,只是万达不像以前百分之百自己持有。去年年会,万达商业正式提出万达商业轻资产战略。万达轻资产分为两类,一种叫做投资类,一种叫做合作类。投资类就是别人出钱,万达帮别人找地、设计、建设、招商、竣工运营后移交给别人,其中还有一个资本化程序。合作类就是万达既不出钱,也不出地,觉得项目合适,跟别人签合同,帮别人建设,建成后租金三七分成,这是我们力推的模式。轻资产战略提出一年之内,轻资产万达广场开业24个,新发展轻资产万达广场47个,其中合作类轻资产万达广场签约37个,远超年初发展25个轻资产,其中投资类10个、合作类15个的目标,发展中心值得表扬。当然也不完全是发展中心功劳,相当多项目是商管和项目系统帮助促成的。这47个广场,万达不出一分钱,收益相当于投资持有16个广场,16个广场如果自己投资最少需要200亿元。更重要的是,2017年北京、杭州、广州、成都、天津、重庆等一线城市都有万达轻资产项目开业或签约,如果不是轻资产,这些城市自己投资持有很难获得项目,这说明万达广场品牌价值和投资者信任度。4、大幅降低企业负债。去年7月,万达和融创、富力签署了文旅项目、酒店资产转让协议,仅此一项协议就减债440亿元,回收现金670亿元,相当于减债1100亿元。对于这次转让,众说纷纭,很多解读,万达卖资产,是不是不行了,其实这是根本不理解商业的基本逻辑。第一、什么叫做生意?做生意用老百姓俗话说,叫做买卖。生意就是买和卖构成的,世上没有只买的生意,也没有只卖的生意。买就说这个公司好,卖就说这个公司不好,这是根本不懂商业思维。其实不管买也好、卖也好,关键看买卖之间能否赚钱。所以对万达的买买买和卖卖卖,关键看我们买的是什么价格,卖的是什么价格,万达过去几年在海外投了一批项目,现在我们决定清偿海外债务,卖一半资产就能把全部债务清偿,说明我们买和卖之间赚钱了。第二、万达广场本身是非常重的资产,过去万达广场全部自己持有,到2017年底开业236个广场,210个是重资产,按成本价计算都是几千亿规模。如果再持有文化旅游项目和酒店,重资产规模太大。文化旅游项目肯定可以收回投资的,经过数学模型分析,每个大型文化旅游项目需要七年、八年有息负债才能往下走,十几年才能收回投资。万达十几个文旅项目叠加在一起,虽然通过销售物业能回收大部分现金,但至少五到六年内,每年净增1000亿负债,压力相当大。现在全球和中国都在去杠杆、降负债,这样加杠杆、逆势而为是不科学的。第三、万达已持有大量较高收益的万达广场物业,没有必要再去持有文旅项目物业。万达卖酒店,我们搞酒店建设、管理的很多同志都说,卖了是不是太可惜?万达酒店是建得不错,成本也很低,但是酒店整体年平均回报率低于4%,全部酒店每年吃掉十几个万达广场的净利润,所以,我们决定把重资产的文旅项目和酒店卖掉,做轻资产这种只赚不赔的买卖,绝对是上策。不管社会上理不理解,也可能有些内部同志不理解,但是请大家三年以后再回头来看我们的决定是否正确。第四、企业经营安全第一。转让资产减债四百多亿,回收现金近700亿,加上我们手头持有的现金,万达经营的安全性增加很多,就能承受风波的冲击。而且如果我们不转让这些资产,就不能把有限的资金投入到我们最需要发展的万达广场上去,就不能保证每年50个以上万达广场开业的计划。为了企业安全,为了保证核心产业发展,我们必须这样做。(三)文化产业高速增长1、影视产业。影视集团去年收入增长35%,新增影城199家,新增屏幕1585块;累计开业影城1551家,屏幕数15932块,全球市场占有率和影响力进一步扩大。特别是在英语片市场,万达具有相当话语权。万达影城在中国并不都是开在万达广场,有一半左右开在非万达物业里,但万达影城单屏收入是国内平均水平1.9倍,线上收入超9成,会员收入近9成,表明万达电影收入非常稳定的增长。万达电影活跃会员突破1亿,这是重大成绩,也为长期稳定增长打下基础。万达电影花了9年时间使会员人数突破1亿。希望你们再用三年时间,看到2020年能不能把会员人数突破2亿。2、体育产业。万达体育收入两位数增长,净利润增长更为可观。在中国落地格力“中国杯”国际足球锦标赛,这是中国唯一获国际足联批准、每年定期举办的国际足球A级赛事。还落地格力“环广西”公路自行车世界巡回赛,这是中国唯一的男子公路自行车世界巡回赛,首届就有16支世界顶级车队参赛。男子公路自行车俱乐部分多个级别,有国家级、州级,世巡赛是最高级别。世巡赛级别的自行车队只有18支,世巡赛有多站比赛,只有环法是十八支车队都参加,其它如环意、环西都是十几支车队参加,“环广西”第一年就有16支车队参加,今年预计18支全部参赛。万达体育还落地铁人三项、摇滚马拉松、小轮车世界锦标赛等多项赛事。3、文旅产业。文旅产业去年表现良好,收入完成139%,净利润倍数递增。更重要的是,文旅产业实现了轻资产品牌经营的目标,由一个负债很重的企业转变为一个轻资产公司。酒店管理公司2017年首次实现公司整体盈利,新签约委托管理高星级酒店10家。自从酒店管理公司班子调整以后,业绩非常喜人,去年下半年酒店业绩大幅增长,几乎全部酒店都实现盈利,绝大多数酒店利润实现比较快的增长,再次证明管理就是生产力。4、儿童产业。十年前万达广场就想引进一个儿童娱乐综合公司,到美国、欧洲、日本、韩国去找,找了五、六年都没找到。全世界这种类型公司基本没有,有那么一两家,也不愿意到中国来。我们讨论要不要自己干,但这意味着要进入全新产业,也犹豫来犹豫去。但万达广场要实现全客层经营,光是年轻人喜欢不行,孩子也得喜欢。儿童意味着未来,所以下决心自己做,也是边探索边干。一开始公司定位搞儿童娱乐,名字就叫儿童娱乐连锁公司,去年才改名叫宝贝王集团,定位为以自有IP传播、衍生品销售为主,集儿童教育、游乐、美食于一体的综合性儿童产业公司。宝贝王集团2017年开业宝贝王乐园60家,早教中心50家;整体实现盈利,比指标提前一年。宝贝王不仅经营好,很多先行指标表现也非常好。如自有IP传播上半年全网收视率48亿人次,下半年飙升到150亿人次,估计2018年数字会更加喜人。这意味着宝贝王定位方向是绝对准确的。如果我们把宝贝王定位为一个游乐型公司,那就错了。(四)科技创新成果丰硕大家也许奇怪,万达谈什么科技创新,是不是附庸风雅,实际随着万达转型,文化旅游产业发展、线上线下融合,万达连续几年科技创新有所斩获。1、慧云。去年慧云升级3.0版本,被国际权威机构评为全球创新企业50强,是亚洲唯一获奖企业。慧云系统有十几个子系统,其中智慧消防子系统被公安部消防局列为中国城市智慧消防试点单位。2、筑云。2016年筑云在万达试行,去年正式实施,这是全球首款智慧工程管理软件,被国际权威机构评为全球数字化转型大奖。筑云可以对工程实施设计到竣工全过程的智能管控,改变工程建设行业控制成本凭经验、随意性大的问题。对还在快速推进城市化、建筑体量天文数字的中国来说,如果筑云得到推广,会在两方面作出贡献,一是可以给中国节约数以百亿、甚至千亿计的建设成本。二是遏制腐败,腐败现象很多发生在工程建设领域,主要因为工程建设是非标准化的,东西南北都不一样,地块也都不同,加上施工很多个体作业,工程智慧管控是一个大难题。筑云尽管还不完善,但万达在这方面迈出了重要步伐。3、创新加速器。去年信息中心利用万达海量线下场景作为开放平台,向全球高技术企业、科研机构、拥有核心技术的个人免费开放,可以到任何地方的万达广场做实验,吸引科创企业、个人为万达线上线下融合做贡献,我们对有前景的项目进行投资孵化。首届创新加速器活动从300个项目中选出15个进行孵化,涉及大数据分析、人工智能客服、楼宇节能黑科技、VR场景娱乐等。其中无人零售平台已在北京、杭州的万达广场试运行。我对创新加速器充满期待,如果每年成功孵化一个两个,一届一届干下去,将是一个非常有前途的项目。关键是选出来如何跟进,使它走上正路,这是孵化最重要的环节,这还不是信息中心能做的,需要更商业化的平台来做。4、飞凡大、小千帆软件。这是飞凡面向大中小型企业商户,一站式解决线上、线下融合的管理软件。签约商户6万家,日交易额超5000万元。还有“万益通”APP,这是中国首款数字权益交换平台,可进行积分、卡券和其它数字权益的交换,已有中石油、中石化、国家电网、海航、京东、顺丰等300多家大型企业参加。希望“万益通”数字交换平台能发展更多企业,争取中国大型企业都能参加,让他们的卡券在平台上都可以互换,这样平台的价值就会更大。5、曲面内显LED动感平台。这是全球首款新型观影科技设备,获得国内外知识产权。大家明年可以去广州万达城体验。2017年万达集团全球申报专利知识产权1278项,取得专利知识产权802件,全集团累计已获国内外专利知识产权5069件。(五)企业管理明显进步1、预算执行到位。去年所有在建、竣工、开业项目,结算与预算做到完全一致。西双版纳国际度假区、南昌万达城两个超大文旅项目,时间跨度5年,超百亿投资,由于我们的管理能力,加上与筑云软件相结合,也做到预决算一致,这是万达执行力和科技管理的成果。2、投资回报提升。万达广场轻资产推出来后,有人说凭什么万达一分钱不投分30%租金?光靠牌子响?肯定不是。只能解释,别人分70%大于他自己干100%。万达广场轻资产标准模板、工程管理软件研发成功和推行,使得万达广场投资回报平均达到2位数,是行业平均水平的两倍,这就可以解释为什么万达分30%租金还有那么多企业上门合作。3、严控管理费用。搞地产成本大,管理成本超一点还可以消化,但转型为服务管理企业,一旦成本超支,商业模式就不成立。所以在严控管理费用上,我们下了比较大的功夫,去年丁总带领有关部门专题研讨,优化管理环节,使万达总部在业务规模扩大的同时费用不升反降,节省管理费6.9亿元。4、反腐卓有成效。审计中心去年查处263起违规事件,解除劳动关系129人,司法立案三起,为企业挽回损失1.3亿元。万达审计有权威,在企业界也有耳闻。(六)带头履行社会责任1、精准扶贫。去年7月3日,万达捐建的贵州丹寨旅游小镇开业。9月29日,丹寨万达职业技术学院开学。由于商管、文旅等部门通力合作、精准定位、针对性推广,小镇开业半年游客超过300万人次。丹寨没有名山大川,没有独特景点,缺乏可以利用的优质旅游资源,完全是无中生有造了一个旅游小镇,就一跃成为贵州排名前3的景点,带动丹寨县2017年旅游收入翻了5倍。新增直接就业2000人,间接就业超万人,带动1.6万人脱贫。丹寨已逐步成为万达精准扶贫的新品牌。2、就业。2017年,万达新创造服务业就业岗位19.5万人,其中大学生8.4万人,占当年全国新增就业的1.5%,连续两年万达一家公司创造全国新增就业的1.5%,而且万达创造的都是有尊严的就业,在万达广场工作,风吹不着,雨淋不着,收入还稳定。3、捐赠。2017年,不含实物,万达现金捐赠7.7亿元。4、环保。2017年,万达获国家绿建标识126项,其中绿建设计标识77项,绿建运行标识49个,连续多年绿建标识获得数量全国排名第一,每年绿建总数占全国三分之一到四分之一。5、义工。去年组织义工活动2651次,10.76万人次参加,中国没有一家企业像万达连续二十几年持续组织义工活动,没有奖励、没有奖金,完全是发自内心。2017年企业取得很好成绩,但也存在不少问题。比如少部分企业没有完成年度目标、腐败现象依然严重,少部分高管本位主义,花钱大手大脚,线上线下融合不够。因为时间关系,只点个题目,有待大家下力气去解决。特别遗憾的是,去年因为有两三个单位指标没完成,使万达没有实现满堂红。二、2018年主要工作安排(一)今年工作主要目标2018年万达集团计划收入2479亿元。商业地产收入1245.4亿元,其中商管公司总收入366.4亿元,租金收入326.8亿元;新开业万达广场50个,万达茂2个;房地产收入879亿元;新发展重资产万达广场7个;轻资产万达广场50个,其中合作类40个,投资类10个。文化集团收入733亿元,其中影视集团收入581亿元;体育集团收入94.3亿元;文旅集团收入30.7亿元;宝贝王集团收入26.4亿元。金融集团收入408亿元。网科集团暂不安排收入计划,上半年内因与世界级网络巨头战略合作,待落地再安排。集团其它收入92.8亿元。(二)提升核心竞争优势1、加快万达广场发展速度。万达广场是万达的核心资产、核心企业、核心优势。随着中国城市化红利的减少,而且现在特大城市都划定了发展边界,想在中国再造一个万达已经没有可能。中国商业已进入线上线下融合发展新阶段,万达广场超大规模线下场景的价值巨大。一年前还不觉得,现在看万达广场超大规模、综合性消费场景的价值越来越凸显。商业中心有竞争半径,特别是在三四线城市,万达广场一旦落地,一定半径里竞争对手很难再投资。举个例子,我们在佛山某地,一个区域里规划了近10个大型城市综合体。我们拿了地,调研发现周边这么多项目,决定尽快开业。万达广场开业后,旁边几个项目到现在也没有开业。因为我们比较火,同类竞争业态就不好布点了,这就像下围棋一样,占了先手。所以我们要加快万达广场全国布局,尽快多签多建项目,更早将万达广场发展到千店规模,这就是万达的护城河计划。千店规模就意味这全国336个地级以上城市,万达广场能覆盖90%,剩下10%左右的地级市因为人口和消费不够;主要县级城市覆盖30%,因为中国一些县人口较多,也具备较强消费能力。万达广场建成全国网络是什么概念?打个比方,假设300公里地铁线每天可以运载300万人,600公里地铁线就不是运载600万人,而是1000万以上。因为一旦形成网络,容量就不是1加1等于2的关系,而是1加1大于2。1000个店我们能获得的租金收入、广告收入、线上线下融合的价值,绝不是现在的5倍。加快发展关键要加快轻资产,从2018年开始万达将每年提高万达广场开业数量。2、提升体验消费占比。增加万达广场黏性最好的办法就是增加体验业态,这是重中之重的工作。体验消费具有不可替代性,有人说美食也可以打包,但打包来的美食还有鲜味吗?娱乐、健身、唱歌、观影都要到现场体验,不是网络可以替代的。还要逐渐提升文化业态占比,社会发展到一定程度,人们对精神的追求就会大过对物质追求。不然就不能理解,为什么文化的东西能传承几百几千年,一本书、一部电影、一首歌曲、一部歌剧能广为流传。三年内要将万达广场体验业提升到65%,五年力争提升到70%。这不仅是商管的事,规划设计部门也要创新。希望从2018年开始,每年评几个创新广场,主要看体验业态、文化业态、更有新意这些方面。3、配置优秀管理人才。今后优秀人才向商管倾斜,万达学院培训也要向商管倾斜,形成风气。(三)持续不断企业转型企业转型没有终点,这是企业管理永恒主题。不要以为企业转型几年就完成了,企业转型没有完成时。1、加快轻资产步伐。万达品牌是非常管用的,要加快万达广场轻资产发展速度,每年不少于50个,合作项目数量上不封顶。有人写文章说商业中心建设,一个企业一年建设50个是极限,他可能是以万达作为分析条件。但万达要突破这个 “极限”。今年万达轻资产租金分成超过10亿元,以后可能每年以十亿级别增加,可以看出轻资产的前景很好。万达电影、宝贝王、文化旅游这些轻资产公司也要加快发展速度。2、形成新的支柱产业。万达广场是万达集团的核心产业,我们还要发展新的核心企业和新的支柱产业。一是影视产业。要继续保持高增长,补上内容短板,实现影视的企业中长期目标。二是体育产业。把精力放在自有IP赛事上,把中国区作为体育产业的增长极。三是文旅产业。要研究跨出万达城,发展管理其它业主的大型文旅项目,酒管也是从管理万达自己的酒店跨出来的。酒管尽早做到管理百家高星级酒店,今年新签约15家高星级酒店委管合同。四是宝贝王集团。宝贝王要把IP传播、衍生品收入作为发展方向,去年宝贝王一下子火起来,原因就是有了一个IP,讲故事吸引人。万达城和迪士尼、环球的差距在什么地方?就是娱乐主题不是自己的故事。如果有故事,有IP,再来传播,就完全不一样。去年宝贝王衍生品净利润近亿元,如果有一天宝贝王发展到几十亿、上百亿衍生品收入,线下千店的场景,做人气就可以了,实体店不盈利也可以。这就是发展模式。我相信,宝贝王有可能超过万达电影,成为万达集团又一个新的核心企业。一是这个产业可以做大。中国儿童数量众多,有3亿,二胎政策后还会继续扩大。中国家长舍得为孩子花钱,特别是在教育方面。二是没有竞争对手。中国没有一个企业像宝贝王这样把IP传播和衍生品收入作为核心来考虑,光有资金玩不了,这就是高门槛。再加上我们占了先机,到2020年开业800家店,谁能和我们竞争?三是企业高估值。宝贝王非传统产业,而且一开始就着手线上线下融合发展,以IP传播、衍生品销售、教育游乐为主要内容,这种企业在国内外估值都很高。四是成长性看好。看了宝贝王的5年测算,非常高兴,希望你们把测算变成现实。3、继续降低企业负债。万达集团将采用一切资本手段降低企业负债,包括出售非核心资产、保持控制权前提下的股权交易、合作管理别人的资产等等。万达要逐步清偿全部海外有息负债,万达商业A股退市资金也有了可靠方案。同时计划用两到三年时间,将企业负债降到绝对安全的水平。今天我可以在这里负责任地说,万达集团在全球绝不会出现任何信用违约!万达30年没有出现一起信用违约,我们把信用看得比资产、利润更重要。(四)线上线下融合发展实践证明,今后很难区分线上线下企业了,四五年之前我和小马哥还有一争论,现在看我俩合二为一了,线上线下要融合。形势比人强,互联网正走向物联网,这就是趋势。1、关键是思想要融合。万达所有系统领导,关键是坐在第一排这些人,要认识到融合发展是趋势,不融合就要被淘汰。所有系统都要推出自己有用的应用软件,特别是商管、影视、宝贝王这些重点企业。要整合万达商管、网科和信息中心的研究业务,成立万达新消费研究院。这是一个重要举措,研究方向不能光想着自己如何掌握消费数据,为自己服务,一定要想着如何为商家增值,让商家觉得有用。万达有这么大规模、不同类型的消费场景,理应折腾点名堂出来。2、从实际效果出发,不玩概念,不烧大钱。我曾经犯的一个错误,就是给了曲德君太多的钱,我跟一些企业家讨论,他们说当初网科少给点钱,定个投资上限就好了。看来钱不能给得太多。不是说网科没有做出成绩,这一次跟别人合作谈判,使我和团队对网科有了全新认识,他们开发了一些有用的东西,只是这些东西有培育期,还不能马上被资本市场接受。原来方向也有偏差,老想大规模来做,如果就为万达广场、旅游度假区研发,可能早就整出名堂了。3、自主研发。网上传网科裁员6000人,网科总共就3000人,怎么可能裁掉6000人!曲德君你为什么也不出来辟辟谣?要强调自主研发。不论网科今年与谁合作,不管是以资本还是战略方式合作,我们自己应用软件的研发都不能停止。为什么万达要成立自己的研究院?我不相信别人会出大钱来做对我们有用的东西,就算能做出来,什么时候也不知道。所以我们宁可每年少花点钱,找几个人,把有前景的研发项目继续下去,研究线上线下融合应用软件,要继续自己搞,这一点是非常明确的。4、开放式发展。要对所有科创企业、院校、研究机构、个人开放万达场景平台,要继续启动第二届创新加速器,希望一届一届地搞下去。很多人很短视,一年没出成就,两年没出成就,就不弄了。如果当初买了两位马哥的股票持有,到现在涨了多少钱了?科创类产品从研发到商业化有一个过程,要坚持搞下去。(五)组织架构适应转型为了适应转型,也为了资本市场需要,万达拟对公司管理架构进行调整,主要是商业地产进行架构调整,当然还需要提请董事会、股东会批准以后,才能正式行动。今天说的是我的一个建议。1、成立商管集团。就是将原来商业地产更名,成为一个纯粹的商业物业持有和运营管理商,使公司战略更清晰,商业模式更纯粹,也为了使市场估值更高。如果有房地产开发,还是归在房地产企业里,但万达商业租金利润已经大过开发利润。将来商管就是收租金,利润每年两位数增长,在此基础上,再通过线上线下融合做一些东西出来,这样公司市场估值会更高。新的商管公司将是以轻资产为主、重资产持有为辅的企业,我们做了公司模拟报表,负债率也非常低,可说是一个非常优秀的公司。新的商管集团将是万达集团核心企业。2、成立地产集团。第一要负责消化商管集团的地产业务,原来商业地产还有一些房地产开发业务,地产集团要尽快帮助消化,但利润归商管。第二要开发万达广场重资产,也不排除纯粹搞一些住宅开发。这么多年万达地产规划、设计、开发、销售一条龙,都是自有团队,在市场上口碑颇好。第三也可以输出品牌管理。地产集团不求做大,主要看利润。集团给了新成立的地产集团一个债务上限,这个上限是很低的,地产集团就是在负债上限下考虑业务发展,不要求做多大规模。现在中国房地产,基本上负债和销售额是对等的,销售越多,负债越多。如果地产集团朝这个路子走,就使集团现在的降负债没多大意义了。地产集团的主要任务就是建万达广场,另外捎带搞点业务就行。3、成立新网科公司。战略合作者确定之后,再来确定业务目标。点这一句话,是说给网科同志们听的。(六)承担企业社会责任1、精准扶贫。继续对丹寨扶贫投入,旅游小镇开业一周年时大型实景演出要确保上演。2018年丹寨旅游小镇要确保400万,力争500万游客数量。按照国家旅游局的标准,200万就算旅游大县,我们今年做到500万,县级旅游可能就名列前茅了。现在丹寨旅游小镇最大问题是过夜游客太少,许多游客去了以后最多吃顿饭,甚至有的人自己带东西吃,把矿泉水一喝,瓶子一丢走了。当然问题是一个个出来的,刚开始我们担心游客不够,说最多一年100万,这100万是养活小镇最基本的游客量。现在半年300万游客,就要研究怎样让游客过夜,这样收入才能增加,对丹寨的旅游拉动才能更大。年会后要马上下去好好研究增加过夜游客的措施,只要路子对头,我们可以再投入。2、就业。今年新增18万人,其中大学生8万人。3、捐赠。今年安排4亿元。4、环保。今年获国家绿建标识100项。今年是万达成立30周年,古人云“三十而立”。国际上有一个公认标准,10年以下是短寿企业,10年到30年是中寿企业,30年以上是长寿企业,万达正站在长寿企业的新起点上,所以今年对万达而言是极其重要的一年。万达要做百年企业,又迎来了新的起点,今年我们会在节俭前提下展开一系列有意义的庆祝活动,我也希望万达全体同仁,特别是各个系统领导,今年都能够完成目标,实现满堂红。我希望在30年庆祝的时候,没有哪个系统没有完成目标,让我们以实际行动来庆祝万达的30周年。让我们在党的十九大指引下,高举习近平新时代中国特色社会主义思想的伟大旗帜,在新的一年里努力奋斗!最后,我要在这里向给予万达支持的中国各级政府、合作企业、消费者和万达全体员工说一声感谢!正是你们的支持,万达才可能取得今天的成就。同时感谢哈尔滨万达城全体员工、万达文华酒店、万达嘉华酒店、皇冠假日酒店全体员工为年会所做出的辛苦工作。春节即将来临,我给在座各位,同时也通过你们给万达企业员工提前拜一个年,祝大家新的一年里面工作顺利!身体健康!万事如意!谢谢大家!
01-22
2018
短视频风口下,360发布一分钟快视频APP
11月14日消息,360旗下快视频APP在北京798尤伦斯艺术中心举行的“超短超有料 质在一分钟”发布会。360创始人兼CEO周鸿祎的演讲环节,从原定1小时,压缩到了一分钟。除了发布快视频应用之外,360还发布了“100亿快基金”计划,奖励视频作者。“快视频将自身定位为‘一分钟超短视频APP’,开创一个新的品类。”360集团助理总裁谢军样表示,“我们通过超短时长、内容有料、智能技术、闭环生态四个方面,打造一款超短超有料的视频APP。”快视频提出了“一分钟超短视频”的战略定位,第一条就是超短时长。“10秒、15秒的视频,代表为快手、奶糖等,以生活、自拍等为主。3-10分钟区间,可以称为短视频,例如西瓜视频。而20分钟以上的则为完整版的影视剧、综艺等,称为长视频,如爱奇艺等。而1-3分钟的区间,我们将其定义为超短视频。”谢军样表示。而且,超短视频内容还要有品质和有料;需要具备可传播和扩散的价值,能让普通大众欣赏;同时还有复用价值,流传很久之后,还能重复欣赏。谢军样还首次公布了快视频独创的新一代智能探索引擎(QVD引擎),在兴趣推荐的同时,强化了情绪感知和自由探索,克服了推荐引擎“信息茧房”的弊端。除了智能探索等技术架构,在扶持原创作者生态方面,快视频也发布了“100亿快基金”计划,奖励视频作者。此外,360浏览器总经理梁志辉还展示了视频剪辑器----快剪辑。这款产品上线半年,每日活跃用户数十万,累计生成视频数量近千万。据了解,快剪辑不仅包括PC端,还首次推出了安卓和iOS等版本。
01-22
2018
网站长尾关键词部局方法
  长尾关键词布局非常重要---因为涉及到网站后期优化效果。布局长尾词的第一点是挖掘和筛选长尾词,然后根据长尾词的竞争度以及相关性布局在网站的栏目页和内页。内页的长尾词围绕栏目页的竞争度大一点的短词来布局,不同栏目的长尾词不能互相交叉以及重叠。   挖掘长尾关键词:挖掘长尾关键词的方法是利用百度相关搜索、百度下拉框以及百度知道、搜搜问问这些工具寻找用户经常搜索的长尾关键词。也可以利用其它的一些工具,比如百度推广助手,挖掘的长尾词会更加精确;观其站长工具、站长工具等。   挖掘好的关键词放在电子表格里面,去除重复的以及明显刷的长尾词和不相关长尾词。比如攻丝机一类的词出现钢管舞相关的长尾词,那么公司级别相关的长尾词必须去除,这样的词和关键词本身毫无相关。   栏目页和内页布局:在筛选关键词时有短词和长词的区分、如果是短词并且指数和竞争度比较大就作为栏目页的关键词,而长词和指数小竞争度小的关键词作为内页长尾词排名。比如攻丝机厂家是一个长尾词,但指数和竞争度相对比较大,所以作为栏目页的长尾词布局,而卧室攻丝机厂家指数和竞争度都比较小,所以作为内页长尾词布局。   攻丝机长尾关键词案例   攻丝机企业长尾关键词布局案例,可供参考   问:SEO如何布局长尾关键词?   请问如何给网站做长尾关键词布局?关键词可以挖掘出很多,但不知道怎么把这些关键词使用上。   1、什么是长尾关键词?   2006年的时候,营销管理业界有一个新的理论,叫长尾理论。长尾理论不同于二八定律。长尾理论一出现,就首先得到了SEO业内的高度认同。直接借用了长尾这个名词来定义领域里面比较泛化而大量的关键词,统称为长尾关键词。   2、长尾理论是互联网时代的独有现象   马云之前有个理论,说我的产品规模要翻几倍,增加一些服务器就好了。沃尔玛要再建多少多少店面。因为内容和产品的数字化后,信息存储方便。搜索引擎的出现,让长尾理论得以体现出来。所以,对网站来说也是内容越多越好。内容多,就意味着总会有一些内容适合这类需求的用户。   3、长尾关键词等于做内容   没有内容页面来承载关键词,那关键词就无法部署,这是要解决关键词落地的问题。关键词是无法脱离内容来谈的。所以,做长尾关键词,本质上就是等于要做内容。如果网站没有几个做内容的策略方法,是很难把长尾关键词策略部署到站内去的。   4、布局长尾关键词常见方法   做聚合,是做长尾关键词策略的常用方法。但聚合的页面质量不好的话,也会影响长尾策略效果的发挥。长尾关键词因为关键词量大的原因,所以只能考虑那种能够产生大量内容的方法来布局长尾关键词。   5、长尾关键词的布局是SEO工作的核心   把长尾关键词布局得当,可以说是SEO工作的最重要的核心一点之一了。这个问题要解决并不简单。因为解决的好,就等于网站能够长期生产出高质量的内容。所以,这个问题如何解决的更好,是值得SEO人员好好思考的问题。      我的观点:不做长尾策略,网站的SEO效果终归有限。所以,如何部署长尾关键词策略,就是每个网站要发展起来过程中必须要解决的问题:   筛选长尾词的作用是找出有价值的长尾关键词并且避免重复,而做指数和竞争度分析是为了避免重复内容出现。   1、禁止出现完全不相干和刷出来的长尾关键词,有的SEO为了作弊会用工具刷长尾关键词   2、很多站长舍不得意思相近的长尾词,便把两个差不多的长尾词布局在站内,但是内容还差不多,大量这样的内容会导致网站降权。因为搜索引擎不会把一个内容重复的网站排名放在首页的。   3、在做栏目分类时,栏目下面内页的长尾词一定是栏目关键词的扩展词或者是相关长尾词,站内的长尾词不能交叉显示在网站的其他栏目。