Youtube's Success Story - Case Study II (Python-based Company)

Be a great websites product design and online marketing expert.Slide 1 of 33

.

YouTube.com

Sting Chen （陈世欣）

使用 Python 技术的成功案例之二

名媛荟网 MY1930. COM CTOTwitter ： @stingchen 博客： BOPOR.COM


假设每个公司用一个协议栈表示，可能如下

使命和目标（梦想、目标、宗旨）文化和结构（文化、制度、团队组织）业务和市场（模式、推广、销售）产品（策划、功能、细分市场）设计（界面设计、交互设计，用户体验）前端（页面模板、 JS 、 AS ）程序（架构、设计、写代码、测试）运维（安全、日志、性能、备份）


故事起源

• 2005 年 1 月陈士骏及 YouTube 另一位创始人查德 . 赫利都离开了前一个工作。在一次烤肉的聚会中，陈士骏苦于找不到地方与人分享录像带，心想如果能放在网络上，必定吸引很多同好。于是两人就在查德 . 赫利家中的车库设计网络视频分享的计划， YouTube 因此诞生。 2006 年10 月，谷歌 (Google) 以 16.5 亿美元收购美国加州初创视频网站 YouTube ，使包括华裔陈士骏在内的 YouTube 两名创始人一夜间成为巨富。

• 以 16 亿 5000 万美元除以 YouTube 五千多万用户，平均一个用户作价 32 美元

• 于 2006 年 3 月达到每天 3 千万的视频点击量于 2006 年 7 月达到每天 1 亿的视频点击量

• 2010 年 5 月占据 43.1% 市场份额的 YouTube 里他们有超过 140 亿段视频被用户观看，刷新了自己的记录，这相当于每名 YouTube 访客在 5 月里观看了超过 100 段视频（仅限美国地区）


创始人

陈士骏 (Steve Chen) – CTO, 美籍台湾人，1978 年生于中国台湾， 8 岁随父母移居美国1995 年进入伊利诺伊大学计算机系学习1999 年，在大学四年级时中途辍学，到只有 4 人的贝宝 (PayPal) 工作。谷歌公司 2006 年收购 YouTube 视频网站时，获得的总价值为 3.01 亿美元

查德 . 赫利 (Chad Harley) – CEO毕业于印第安那大学设计专业，毕业后在网络支付网站 PayPal 工作了几年，是 PayPal的第 15 位员工，也是第一位美工。 PayPal 被 eBay 收购后，赫利转而为多家 IT公司提供咨询服务，与此同时，他还在好莱坞充当制片人，推出的作品包括喜剧《多谢抽烟》。

贾韦德 ·卡里姆斯坦福大学未毕业学生，早先加入 paypal持有的 YouTube股份当时价值 6600 万美元


创意灵感

• 源自印尼海啸 31 岁的瑞典修车工人汤米在印尼的普吉岛度假，突然，“轰隆轰隆”，海上响起奇怪的低吟声，霎时， 3层楼高的海浪凌空席卷！汤米大叫快跑，随手拿起手机，拍下这一幕南亚海啸短片刚播放，就有 12 个博客转载，其中一个原本无名的博客，人气从零 5 天内吸引了 68 万人次上线观看，当时至少有超过 130 万人在网络上看到南亚海啸的内容，这个数字，比美国《商业周刊》每周 120 万本的发行量还高。

• 这则短片最早在挪威的《 Dagbladet》日报网站上播放， 12小时内，包含 CNN 在内的全球媒体都在追着汤米买影带。陈士骏 3 人惊觉，科技的进步已让全民都拥有了创作权，修车工人也能打败 CNN 记者。


创始理念

• 相信消费者至上，相信‘你 (You)’ 是最重要的。

• 希望创建一个视频内容共享社区 ,让公众上传任何格式的视频内容，同时为此提供一个视频播放器，用户可将视频内容放置于网站或博客当中，并与他人分享。

• 想法很实际，不是自顾自地在车库里研发产品，还要想到市场。

• 效率很重要，时间要有效率，用钱也是如此，像我不会聘用没有效率的员工。


开发的产品

• 一套简单的程序，可以支持各种各样的视频文件，任何电脑用任何网络浏览器都可以播放这些视频文件。

• 然后创建了一个网上视频社群，人们可以存这个网站上发布自己制作的视频，观看、搜索其他人的作品，并进行评论和评级。


低成本的起步

• 几台计算机，一张信用卡 ( 陈士骏的信用卡 ) ，就把系统建立起来了。

• 又过了三个月，伙伴们愁眉苦脸地坐在堆满杂物的车库里对望，他们想提供平台给 eBay 网络拍卖者使用，但卖方不喜欢以影片介绍产品，结果就是“没有人用”。

• 松开双手，“创造（消费者）要的产品。”他们宣布，提供“嵌入式服务”，消费者上传影片到YouTube 网站后，其他喜欢影片或是想要观赏影片的人，可以直接设立链接，贴到自己的网页上。也就是说，所有人不须要进入 YouTube 的网站，在自己的网页上就能看到那些影片。


YouTube 成功的秘诀是什么 ?

• 首先是简单 –简单其实才是互联网上最重要的法则。–从一开始就是为了用户使用方便而设计，把那些看似笨重，困难的过程变得简单。 YouTube是第一家使用 Flash Video 的，这样再不用关心你最初安装的是什么样的媒体播放器，把所有的视频都转化为了一种普通格式。

– YouTube 的页面干凈，导航也很容易。


YouTube 成功的秘诀是什么 ?

• 其次是对于细节的关注 – 用户收到一个链接，点击，打开浏览器，这里面的视

频应该是自动播放，而不是需要用户再点一下 – 分享的链接。在 YouTube 的每一个视频旁边，都有一

个让用户可以粘贴到 MSN或者网页里面的代码。其实，这个 URL 在浏览器上面的地址栏里也有，用户可以把鼠标挪上去，然后拷贝下来。但是把这个链接放在视频的右侧，就那么近，那么容易看到，容易明白，容易拷贝

– YouTube 里视频的 URL 都很短，比如 http://www.youtube.com/watch?v=Lcfx7v-z-JE，这样做的优势在于，能够确保在即时通讯工具或者邮件里面不会折行，从而影响打开。


每天超过 1 亿的视频点击量时候的技术团队配置

• 2 个系统管理员• 2 个伸缩性软件架构师 • 2 个软件开发工程师• 2 个网络工程师• 1 个 DBA


平台

• Apache Python Linux(SuSe) MySQL psyco ，一个动态的 Python 到 C 的编译器 lighttpd 代替 Apache做视频查看



Web 服务器端的一些运营情况

• NetScaler 用于负载均衡和静态内容缓存 • 使用 mod_fast_cgi运行 Apache

• 使用一个 Python应用服务器来处理请求的路由

• 应用服务器与多个数据库和其他信息源交互来获取数据和格式化 html 页面

• 一般可以通过添加更多的机器来在 Web层提高伸缩性



• Python 的 Web层代码通常不是性能瓶颈，大部分时间阻塞在 RPC

• Python允许快速而灵活的开发和部署 • 通常每个页面服务少于 100毫秒的时间 • 使用 psyco( 一个类似于 JIT编译器的动态

的 Python 到 C 的编译器 )来优化内部循环 • 对于像加密等密集型 CPU活动，使用 C扩展



• 对于一些开销昂贵的块使用预先生成并缓存的 html

• 数据库里使用行级缓存 • 缓存完整的 Python对象 • 有些数据被计算出来并发送给各个程序，所以这些值缓存在本地内存中。这是个使用不当的策略。应用服务器里最快的缓存将预先计算的值发送给所有服务器也花不了多少时间。只需弄一个代理来监听更改，预计算，然后发送。


视频服务相关的一些情况

• 花费包括带宽，硬件和能源消耗 • 每个视频由一个迷你集群来 host ，每个视

频被超过一台机器持有，这样做的好处有：–更多的硬盘来持有内容意味着更快的速度 – failover 。如果一台机器出故障了，另外的机器可以继续服务

– 在线备份


视频服务

• 用 lighttpd 作为 Web 服务器来提供视频服务： – Apache 开销太大 – 使用 epoll来等待多个 fds –从单进程配置转变为多进程配置来处理更多的连接

• 大部分流行的内容移到 CDN ： – CDN 在多个地方备份内容，这样内容离用户更近的机会就会更高

– CDN 机器经常内存不足，因为内容太流行以致很少有内容进出内存的颠簸


视频服务

• 不太流行的内容 ( 每天 1-20浏览次数 ) 在许多 colo 站点使用 YouTube 服务器 –长尾效应。一个视频可以有多个播放，但是许

多视频正在播放。随机硬盘块被访问 – 在这种情况下缓存不会很好，所以花钱在更多

的缓存上可能没太大意义。 –调节 RAID控制并注意其他低级问题 –调节每台机器上的内存，不要太多也不要太少


视频服务关键点

• 保持简单和廉价• 保持简单网络路径，在内容和用户间不要

有太多设备 • 使用常用硬件，昂贵的硬件很难找到帮助

文档 • 使用简单而常见的工具，使用构建在 Linux

里或之上的大部分工具 • 很好的处理随机查找 (SATA ， tweaks)


缩略图服务

• 做到高效及其困难 – 每个视频大概 4张缩略图，所以缩略图比视频

多很多 –缩略图仅仅 host 在几个机器上


缩略图服务

• 持有一些小东西所遇到的问题： – OS 级别的大量的硬盘查找和 inode和页面缓存问题 – 单目录文件限制，特别是 Ext3 ，后来移到多分层的结

构。内核 2.6 的最近改进可能让 Ext3允许大目录，但在一个文件系统里存储大量文件不是个好主意

– 每秒大量的请求，因为 Web 页面可能在页面上显示 60个缩略图

– 在这种高负载下 Apache表现的非常糟糕 – 在 Apache 前端使用 squid ，这种方式工作了一段时间，但是由于负载继续增加而以失败告终。它让每秒 300个请求变为 20 个

– 尝试使用 lighttpd但是由于使用单线程它陷于困境。遇到多进程的问题，因为它们各自保持自己单独的缓存

– 如此多的图片以致一台新机器只能接管 24小时 – 重启机器需要 6-10小时来缓存


缩略图服务

• 为了解决所有这些问题 YouTube 开始使用Google 的 BigTable ，一个分布式数据存储： –避免小文件问题，因为它将文件收集到一起 –快，错误容忍 –更低的延迟，因为它使用分布式多级缓存，该缓存与多个不同 collocation 站点工作


Python 的优化措施 - 问题

• 纯 python 的加密模块 HMAC (Hash-based Message Authentication Code) 要占用 40% 的 cpu– 应对策略：用 C语言重写，提高性能

• 大量评论的显示问题：过于复杂的算法去计算显示对象树– 应对策略：简化查询 , 简化算法


Python 的优化措施

• 使用 psyco – 加快 Python执行的编译器–最常用的功能都是用 psyco编译–由于存在上下文切换开销，需要测试

• 优化后大量评论的显示性能– closure +psyco = 提高性能达 400%

– closure ： A JavaScript optimizer


怎样获得可以接受的性能？

• 服务的扩展–对各种“叶子级别”的服务进行优化–动态 web请求是一种 ` 服务 `– web service 容易扩展 , 可以向外扩展

• 数据库的扩展–数据库很难扩展，需要聪明的逐步升级的技巧但，慢慢地就没有牌可以打了


MySQL 性能扩展

• 不得不做大量水平切分–需要仔细选择分库计划

• 理解数据访问模式–最常用的查询是什么？– 使用到了 Join没有–需要事务一致性吗？为什么？

• 是否可以进行“实体”的融合 ?


MySQL 性能扩展

• 必须根据实体进行分块–实体是事务一致性的–实体内部属性允许交互连接–实体容易迁移– 交叉实体过于复杂

• 减弱实体中的一些保证要求、简化实体• 通过设计减少相关活动


MySQL 性能扩展

• 数据库优化实践相关操作–连接和事务管理– 查询服务机制（ lookup service ）–建立查询工厂，并发查询（ query factory ）–抽取最小表的集合，加快查询，禁止 ORM–简化最常用的用户行为设计–程序设计对实际数据库透明


整个网站运营中循环进行的主题

• 简单的优雅• 选择可靠的开源软件，然后做定制化• `pythonic veneer`

• DIY – 发现一个问题并不够，鼓励发现者自己动手去解决这个问题。


总结的经验

• 用短期方案赢得问题解决时间– 在考虑长远解决方案时候，一些技巧性但有些风险的短期方案可以帮你渡过难关

• 任何事情都按照优先级安排– 清晰了解什么对你的服务和资源最重要的，资源和工

作总是按照优先级来安排• 外包一些重要的服务

– 自己做一些服务化时间长，成本也高。比如 CDN

• 保持简单– 这样可以重构更快，响应问题更快。也许没有人知道什么是简单的设计。如果你不害怕做改变，那就是一个信号。


总结的经验

• 切片 (Shard)– 切片的设计思路不仅仅获得更好的写性能，

还能帮助隔离和限制所有资源包括存储、 CPU ，内存和 IO ，便于横向扩展。

• 对解决瓶颈的各个环节反复迭代– 软件 : DB, caching– 操作系统 : 磁盘 I/O– 硬件 : memory, RAID

• 成功来自于一个好的团队– 好的团队有纪律，并理解整个系统和系统内部的原理。


讨论

• 成立 18 个月的公司， 67 人，卖了 16.5 亿美金，其价值何在？

• 为何这个模式树立了高门槛，以至于竞争者不能追赶，只能收购？

• 哪些领域可以复制此类成功？• 有哪些类似的例子？• 中国有什么机会？• 技术和团队方面有哪些可以借鉴的？• 产品思路方面有哪些可以借鉴的？• 运营思路和实践方面有哪些可以借鉴的？

Technology

Youtube's Success Story - Case Study II (Python-based Company)