BDTC 2013 Beijing China

1. 基于公共云平台的DSP技术
刘书良（百川通联）
liushuliang@baicdata.com

2. 如何更高效处理高并发及大数据？
• Instagram：7个工程师 && 十亿美金的故事
• 大量使用amazon云服务
• 保持简单、不重复制造轮子
• 采用已经被证明了的技术
• 百川通联：
• 架构在公共云服务平台基础之上
• 使用大量开源软件
• 搭建起国内第一个基于公共云服务的DSP、DMP平台

3. DSP的一些背景知识

4. DSP基本问题：
• 第三方adexchange每日可向DSP发送超过50亿流量
• Bidder：实时广告调度决策及出价算法
• Redis Proxy && Redis Cluster：redis数据库管理，支持对redis
高并发的请求
• 广告决策支撑数据运算：
• cookie mapping数据（adexchange与dsp间cookie对应关系）
• 用户cookie数据（兴趣、性别或者是自定义标签）
• 广告实时投放数据、结算数据

5. 线上请求处理流程：

6. Online模块性能基本状况：
• 每天请求量超过50亿次，峰值请求达到5万QPS
• 每个请求的延时要小于100ms
• 出价服务器与adexchange服务器通常不在同一个城市，这样意
味这10-40ms的网络延时
• 对于每个请求，需要访问四次redis
• 决策算法时间复杂度较高

7. QPS接入过程中遇到的问题：
• 云服务器安全策略把adexchange流量当成了DDOS攻击
• 与云平台运维沟通，提高对指定ip的qps上限值限制
• 云服务器单独服务器pps上限值
• 前期想使用bidder高配置的云服务器，由于pps限制，cpu利用
率一直上不去，浪费了计算资源
• 把高配服务器换成几台低配服务器：1台4核，8G内存服务器替
换成4台1核，512M内存的云服务器

8. QPS接入过程中遇到的问题：
• 流量超过单个负载均衡实例上限值
• 与云平台运维沟通，提高负载均衡实例的QPS的上限值
• Redis问题：10亿key_value对，峰值每秒20万次请求
• 单台云主机pps上限问题，决定了少数云主机请求无法满足需求
• 内存占用过多的问题，禁用redis自带过期的设置，改为线下程
序自动过期数据，内存占用减少30%

9. QPS接入过程中遇到的问题：
• Redis问题：
• Twemproxy：一个关于内存数据库的代理服务器
• 将大表拆分成很多小表，部署到不同服务器的redis表中，保
证将数据平均分配到不同服务器
• 线上请求被平均分配到各台服务器上
• 目前已经通过Twemproxy管理上百个redis进程

10. 云主机日志运算问题：
• 当线上流量达到一定时，单台log服务器出现瓶颈：
• 每秒产生的日志峰值在6万条左右，一天产生的日志量达到1T
• 通过单击接收rsyslog接受日志，已经达到单机pps上限值，造
成丢包现象
• 云服务器磁盘i/o受限设计原因，顺序读的速度小于20M左右，
也达到上限，写的速度更慢一些
• 由于单机上磁盘IO受限，单机上的数据无法进行远程拷贝

11. 云主机日志运算问题：
• 在不影响业务的情况下，将日志发送到不同的服务器上，避免单台
服务器pps上限、i/o上限
• 对关键数据适当进行冗余备份，减少计算程序远程拷贝数据
• 使用rsyslog管道，减少日志硬盘读取
• 使用redis作为缓存，减少各个服务器读取硬盘的次数
• 将不同的离线任务，进行拆分，部署到不同的服务器上

12. 使用自建Hadoop集群进行离线计算：
• 问题：
• 目前国内市场还没有开放的公共云平台，提供类似Hadoop
MapReduce服务。需要在云主机外再建立一个Hadoop机器。
• 数据远程传输浪费了带宽成本
• 期望尽快出现能提供Hadoop机器计算的商业平台出现

13. 使用自建Hadoop集群进行离线计算：
• 对于实时性或者数据量巨大的运算，我们自建了hadoop集群
• 人群定义：
• 300个标准人群类别
• 给定人群进行扩展：look alick算法
• 点击率模型：
• Logistic regression
• 深度统计分析报表：
• 例如：用户行为与广告点击之间的关联分析

14. 小结：云主机选购技巧
• 一定要准确评估内存、cpu、带宽、磁盘的峰值
• Bidder高cpu、redis服务器高内存
• 在某些情况下：
• 1台* 4核4G内存服务器
vs 4台* 1核1G内存服务器
• 很大概率对应1台实体服务器 vs 很大概率对应多台实体服务器
• 遇到单台物理机瓶颈（pps/cpu） >> 遇到单台物理机瓶颈
• 内存、cpu、带宽、磁盘可以按需定义，动态调整

15. 小结：技术方面
• 对于线上高并发、实时请求，基于国内的商业云平台基本可以搞定
• DNS、CDN、负载均衡、开源nosql、虚拟服务器、云监控
• 虚拟服务器，磁盘IO是瓶颈，云平台需要考虑支持SSD硬盘
• 公共云平台对于类Hadoop的离线数据计算平台还相对较弱

16. 小结：成本
• 以百川DSP为例：
• 公共云平台提供更多计算资源，便于将研发精力专注出价策略、
数据挖掘等算法方面
• 研发周期大大加快
• 测试服务器、svn都部署在云上，运维、IT人员为0.5人
• 硬件成本及研发成本大幅度下降
• 接下来，以最有效率的方式：
• 整合互联网、无线互联网、及其他智能终端上的数据
• 做数据挖掘和精准营销

17. Thanks!
百川通联
www.bcdata.cn
17