十亿级视频播放技术优化揭秘

QQ 空间在 2016 年日均视频播放量由年初的千万级迅速突破到十亿级，过程中也对整个视频播放技术的可靠性、性能、操作体验等方面提出严峻的考验，相关质量急需提升。经过多个迭代持续和各项优化，外网整体质量已经达标：在保证播放成功率提升到 99.92% 的基础上，首次缓冲耗时降到 0.70s，二次缓冲概率降到 0.48%，做到稳中有升。我们将从视频组件的整体架构，优化效果衡量，首次缓冲耗时优化，播放成功率优化，二次缓冲优化，总结六个方面介绍视频点播在整个优化过程中的心路历程。

Instagram 服务器性能优化实战与经验

Instagram 目前拥有超过 6 亿月活用户，是用户规模增长最快的社交平台之一。Instagram 的 Web 服务器使用 Python 编写，拥有目前世界上最大的基于 Django的Web Service 集群。随着用户数量和和业务规模的极速增长，提高 Web 服务器的性能和可靠性对于 Instagram 是一个巨大的挑战。本次演讲将介绍 Instagram 如何通过工具定位系统性能瓶颈、自动化检测性能 regression，并通过几个具体实例向大家介绍 Instagram 在性能优化方面的一些经验。

阿里电商故障治理和故障演练实践

为了支持海量用户和多元化的业务，基础设施和系统会趋于复杂。业务的高速发展的同时，对于稳定性也有非常高的要求。从 2011 年到 2015 年，电商域遇到了很多有代表性的故障，积累了非常多的高可用保障经验和解决方案。然而任何基础设施、系统、人、流程都可能出问题，且问题一直在发生。2016 年，我们研发了故障演练系统，把故障以场景化的方式沉淀到系统中，在线上主动回放故障，验证监控报警、限流降级、故障迁移、容灾策略、故障处理的有效性。在双 11 备战中，设计了数百个演练场景设计，通过几十次的演习，发现并解决了大量的问题。

本次分享会探讨经典的故障类型，剖析故障成因，提出解决方案，介绍故障演练系统的设计和演进，提出故障演练的原则和经验。

听众收益

• 整体了解阿里技术架构和稳定性治理情况，获取构建高可用系统和故障演练的一些经验。
• 阿里技术架构、稳定性治理的背景介绍：
  • 依赖治理：依赖故障分析、模式总结，电商依赖治理经验及强弱依赖系统演进；
  • 灰度发布：如何通过流量控制、灰度发布、自动化测试提前发现故障；
  • 故障演练：向故障要红利，故障演练的系统设计和演练最佳实践。

全链路压测在滴滴的实践

滴滴业务规模飞速增长，服务可用性面临的挑战，日趋严峻；面对服务瓶颈是见招拆招，还是疏通经脉，已到不得不选择的地步。滴滴选择以全链路压测来推动服务链路的梳理、核心架构的 review，排除服务链路中的稳定性毒瘤，保障服务高可用性。本次分享可了解到，滴滴的全链路压测：

1. 如何完成压测场景，数据的虚拟构造；
2. 如何解决数据链路中的压测数据的可标记性；
3. 如何解决压测数据的隔离及清理；
4. 如何有效模拟海量司机及乘客；
5. 模拟端的关键技术设计；
6. 全链路压测的后期规划。

听众受益

1. lbs 场景下的交易引擎如何完成全链路压测；
2. 复杂系统内的数据链路标记；
3. 了解模拟海量端的设计思路及技巧。

对 2000 多亿条数据做一次 group by 需要多久？

SPA 自研 PivotEngine 可以在 2 秒内完成。

数据是很多业务的核心驱动力之一。对于“SPA”这样的广告业务，更是如此。几十亿用户，每天几百亿次曝光，都产生大量的数据。对这些数据进行透视分析，发现其中蕴含的一些高层宏观信息，对于广告主以及我们自己的产品、运营、策略开发等人员的决策都能提供指导和帮助。

比如广告主投放一条广告，他想了解浏览了其广告的这批用户的年龄是个什么样的分布，更进一步地，其想对比一下曝光用户和有点击行为的用户，比如曝光中 25 岁的用户占比是 10%，但是点击中 25 岁的用户占比却高达 15%。

对于运营来说，他们可能想了解一段时间整个系统中获得不同曝光次数的用户的占比、点击率、产生的收入等。比如最近 10 天内产生 1 次曝光的用户的数量、平均点击率、收入，2 次曝光用户的数量、平均点击率、收入等。

对于广告主的这种简单需求，通过 SQL 可以这样得到结果：select age, count(*) from log where advertiser_id=xxx group by age。

对于后面那种按曝光量聚合统计的需求来说，假设每条曝光日志作为一条基本的数据，那么 sql 大概是如下这种形式的两层 GROUP BY 嵌套查询：

SELECT

    exposure_num,

    COUNT(*) as user_num,

    SUM(sum_click) / SUM(exposure_num) as click_rate,

    SUM(sum_cost) AS total_cost

FROM

    (SELECT

         qq,

         COUNT(*) AS exposure_num,

         SUM(click_count) AS sum_click,

         SUM(cost) AS sum_cost

     FROM

         log_table

     GROUP BY qq) temp_table

GROUP BY exposure_num;

如果只有几十万或几百万条数据，也许 mysql 就可以很好的解决这个问题。但是当数据规模达到几十亿、几百亿甚至上千亿时，mysql 就无法处理了。此外 mysql 一行数据在一列上只能取一个值，但是对于一个用户来说，其某个属性可能是多值，比如用户的商业兴趣，会有多个值。这时按照“商业兴趣”这一列进行 group by，mysql 也无法或者不方便处理。

为了高效低成本地支持这种简单的“过滤-聚合”模式，也即“where-group by-(count|sum|avg) ”这种模式的查询分析请求，当然易用也是非常重要的，我们自研了一套在线查询分析引擎“PivotEngine”。

OpenStack Swift 海量小文件性能优化之路

OpenStack Swift 是 OpenStack 项目的子项目，提供了弹性可伸缩、高可用的分布式对象存储服务，可用于解决海量照片、视频、日志等业务存储需求。随着互联网的高速发展，业界对海量小文件的需求越来越大，Swift 虽然能够存储海量数据，但是由于其设计并没有针对海量小文件进行特别优化，导致随着海量小文件增多，性能下降明显的问题。为了保持性能，一个简单的方案是增加机器，扩大集群规模，这种方案的最大问题是造成大量磁盘空间的浪费。为此我们进行大量的探索，结合业界一些已有存储系统的优点，在 Swift 上做了一系列的优化工作，让 Swift 在海量小文件情景下不需要通过增加机器来保持性能不下降。

听众受益

• 已有 Swift 在磁盘利用率在 5% 左右时，性能就退化了 30% 左右，听众可以了解性能退化问题的原因
• 优化过程中所采用具体的手段：
  • 用 PyPy 运行时代替 CPython，延迟降低了 25% 以上
  • Go 实现的 Swift，相比于 Python Swift，延迟降低了 30% 以上
  • Swift 上实现合并存储，相比于 Python Swift，延迟降低了60%以上，而且没有随对象数量的增加而出现明显退化的问题
• Swift 合并存储关键技术方案的实现：
  • 合并存储磁盘组织方式
  • 去中心化的多副本定位方法
  • 多副本同步方法