刘书良:基于大数据公共云平台的Dsp技术
Upcoming SlideShare
Loading in...5
×
 

刘书良:基于大数据公共云平台的Dsp技术

on

  • 524 views

BDTC 2013 Beijing China

BDTC 2013 Beijing China

Statistics

Views

Total Views
524
Views on SlideShare
524
Embed Views
0

Actions

Likes
0
Downloads
6
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    刘书良:基于大数据公共云平台的Dsp技术 刘书良:基于大数据公共云平台的Dsp技术 Presentation Transcript

    • 基于公共云平台的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人 • 硬件成本及研发成本大幅度下降 • 接下来,以最有效率的方式: • 整合互联网、无线互联网、及其他智能终端上的数据 • 做数据挖掘和精准营销
    • Thanks! 百川通联 www.bcdata.cn 17