基于公共云平台的DSP技术 刘书良（百川通联）

liushuliang@baicdata.com

如何更高效处理高并发及大数据？

• Instagram：7个工程师 && 十亿美金的故事

• 大量使用amazon云服务

• 保持简单、不重复制造轮子

• 采用已经被证明了的技术

• 百川通联：

• 架构在公共云服务平台基础之上

• 使用大量开源软件

• 搭建起国内第一个基于公共云服务的DSP、DMP平台

DSP的一些背景知识

DSP基本问题：

• 第三方adexchange每日可向DSP发送超过50亿流量

• Bidder：实时广告调度决策及出价算法

• Redis Proxy && Redis Cluster：redis数据库管理，支持对redis

高并发的请求

• 广告决策支撑数据运算：

• cookie mapping数据（adexchange与dsp间cookie对应关系）

• 用户cookie数据（兴趣、性别或者是自定义标签）

• 广告实时投放数据、结算数据

线上请求处理流程：

Online模块性能基本状况：

• 每天请求量超过50亿次，峰值请求达到5万QPS

• 每个请求的延时要小于100ms

• 出价服务器与adexchange服务器通常不在同一个城市，这样意

味这10-40ms的网络延时

• 对于每个请求，需要访问四次redis

• 决策算法时间复杂度较高

QPS接入过程中遇到的问题：

• 云服务器安全策略把adexchange流量当成了DDOS攻击

• 与云平台运维沟通，提高对指定ip的qps上限值限制

• 云服务器单独服务器pps上限值

• 前期想使用bidder高配置的云服务器，由于pps限制，cpu利用

率一直上不去，浪费了计算资源

• 把高配服务器换成几台低配服务器：1台4核，8G内存服务器替

换成4台1核，512M内存的云服务器

QPS接入过程中遇到的问题：

• 流量超过单个负载均衡实例上限值

• 与云平台运维沟通，提高负载均衡实例的QPS的上限值

• Redis问题：10亿key_value对，峰值每秒20万次请求

• 单台云主机pps上限问题，决定了少数云主机请求无法满足需求

• 内存占用过多的问题，禁用redis自带过期的设置，改为线下程

序自动过期数据，内存占用减少30%

QPS接入过程中遇到的问题：

• Redis问题：

• Twemproxy：一个关于内存数据库的代理服务器

• 将大表拆分成很多小表，部署到不同服务器的redis表中，保

证将数据平均分配到不同服务器

• 线上请求被平均分配到各台服务器上

• 目前已经通过Twemproxy管理上百个redis进程

云主机日志运算问题：

• 当线上流量达到一定时，单台log服务器出现瓶颈：

• 每秒产生的日志峰值在6万条左右，一天产生的日志量达到1T

• 通过单击接收rsyslog接受日志，已经达到单机pps上限值，造

成丢包现象

• 云服务器磁盘i/o受限设计原因，顺序读的速度小于20M左右，

也达到上限，写的速度更慢一些

• 由于单机上磁盘IO受限，单机上的数据无法进行远程拷贝

云主机日志运算问题：

• 在不影响业务的情况下，将日志发送到不同的服务器上，避免单台

服务器pps上限、i/o上限

• 对关键数据适当进行冗余备份，减少计算程序远程拷贝数据

• 使用rsyslog管道，减少日志硬盘读取

• 使用redis作为缓存，减少各个服务器读取硬盘的次数

• 将不同的离线任务，进行拆分，部署到不同的服务器上

使用自建Hadoop集群进行离线计算：

• 问题：

• 目前国内市场还没有开放的公共云平台，提供类似Hadoop

MapReduce服务。需要在云主机外再建立一个Hadoop机器。

• 数据远程传输浪费了带宽成本

• 期望尽快出现能提供Hadoop机器计算的商业平台出现

使用自建Hadoop集群进行离线计算：

• 对于实时性或者数据量巨大的运算，我们自建了hadoop集群

• 人群定义：

• 300个标准人群类别

• 给定人群进行扩展：look alick算法

• 点击率模型：

• Logistic regression

• 深度统计分析报表：

• 例如：用户行为与广告点击之间的关联分析

小结：云主机选购技巧

• 一定要准确评估内存、cpu、带宽、磁盘的峰值

• Bidder高cpu、redis服务器高内存

• 在某些情况下：

• 1台* 4核4G内存服务器 vs 4台* 1核1G内存服务器

• 很大概率对应1台实体服务器 vs 很大概率对应多台实体服务器

• 遇到单台物理机瓶颈（pps/cpu） >> 遇到单台物理机瓶颈

• 内存、cpu、带宽、磁盘可以按需定义，动态调整

小结：技术方面

• 对于线上高并发、实时请求，基于国内的商业云平台基本可以搞定

• DNS、CDN、负载均衡、开源nosql、虚拟服务器、云监控

• 虚拟服务器，磁盘IO是瓶颈，云平台需要考虑支持SSD硬盘

• 公共云平台对于类Hadoop的离线数据计算平台还相对较弱

小结：成本

• 以百川DSP为例：

• 公共云平台提供更多计算资源，便于将研发精力专注出价策略、

数据挖掘等算法方面

• 研发周期大大加快

• 测试服务器、svn都部署在云上，运维、IT人员为0.5人

• 硬件成本及研发成本大幅度下降

• 接下来，以最有效率的方式：

• 整合互联网、无线互联网、及其他智能终端上的数据

• 做数据挖掘和精准营销

17

Thanks!

百川通联 www.bcdata.cn