一种广告投放系统的制作方法

文档序号:17330259发布日期:2019-04-05 22:02阅读:198来源:国知局
一种广告投放系统的制作方法

本发明涉及计算机技术领域,尤其涉及一种广告投放系统。



背景技术:

现有广告系统核心为关系数据库,广告主通过业务系统管理广告数据:账户设置,广告计划,预算,推广单元,广告创意等;通过审核后可以投放的数据进入广告投放服务器。投放服务器直接访问数据库获取需要投放的广告数据,并通过缓存来提高性能,减少对数据库的压力。在广告系统中对广告数据的管理会通过一个或多个基于web的应用来实现。

作为服务于大量媒体的广告投放系统,其系统负载往往是其所服务的各个媒体的负载总和。同时,广告投放业务的实时特性也决定了系统必须能对广告投放请求给出最快程度的响应(业界一般为100ms内),由于延时导致的广告投放滞后或者失败,将对广告投放的效果和客户体验造成较大影响。因此,高并发负载支持,作为系统设计成败的关键性因素,是系统设计的核心问题。



技术实现要素:

本发明实施例提供一种广告投放系统,能提供大流量高并发的动态系统,减少了广告系统的网络带宽,提高系统响应时间。

本发明一实施例提供一种广告投放系统,包括:

基础设施模块,用于构建所述广告投放系统的硬件和框架;

基础服务模块,用于提供认证服务、监控服务、文件服务、配置服务、mq服务和task服务;

数据库模块,用于存储通过hadoop收集且通过sqoop工具同步的数据;

大数据服务平台,为各类计算框架提供资源的管理和调度;

应用层模块,用于通过基于技术协议的接口支撑广告投放系统顶层应用。

与现有技术相比,本发明实施例公开的广告投放系统,包括基础设施模块,用于构建所述广告投放系统的硬件和框架;基础服务模块,用于提供认证服务、监控服务、文件服务、配置服务、mq服务和task服务;数据库模块,用于存储通过hadoop收集且通过sqoop工具同步的数据;大数据服务平台,为各类计算框架提供资源的管理和调度;应用层模块,用于通过基于技术协议的接口支撑广告投放系统顶层应用,能提供全栈框架,使得处理能力达到qps>60万,tps>7万,响应速率<30ms,远低于行业标准100ms的响应速率,减少了广告系统的网络带宽,提高系统响应时间,实现高流量并发的广告投放。

作为上述方案的改进,所述基础设施模块包括私有云、bgp机房、ssd和监控报警单元,其中,所述私有云基于openstack搭建;所述bgp机房网络为bgp线路,ssd为针对部分高速读写的业务提供的高性能磁盘,所述监控报警单元用于云平台健康运行状态的监控及故障响应跟踪。

作为上述方案的改进,所述认证服务包括安全控制和权限管控,所述监控服务包括云平台提供的paas级监控和基于开源zabbix以及open-falcon的监控;所述文件服务包括fast-dfs集群、用于接口数据传输的ftp服务和为web提供的文件级服务;所述配置服务包括zkui和dubboadmin配置管理工具;所述mq服务及task服务用于爬取数据和回流数据,所述数据包括idfa数据、mac数据、imel数据和androidid数据。

作为上述方案的改进,所述数据库模块包括nosql集群、mysql集群、hbase分布式集群和kafka队列;其中,所述nosql集群用于存储多维度标签数据,以及用于存储实时逻辑数据以及流量筛选逻辑处理;所述mysql集群用于存储系统平台关系型数据,所述系统平台关系型数据包括订单数据和策略管理数据;所述kafka队列用于存储和清洗非结构化数据,所述非结构化数据为nosql标签数据的原始数据。

作为上述方案的改进,所述应用层模块包括计划管理单元、策略管理单元、素材管理单元、广告主管理单元、报表管理单元、算法模型单元、流量清洗单元和广告位检测单元;所述计划管理单元、策略管理单元、素材管理单元、广告主管理单元、报表管理单元、算法模型单元、流量清洗单元和广告位检测单元之间的交互均以以rpcdubbo作为基础架构实现。

作为上述方案的改进,所述广告主管理单元,用于管理广告主客户基本信息,并根据不同媒体要求进行送审和审核。

所述订单管理单元:管理每个投放计划下的订单,包括订单状态、订单基本信息增删改查、订单素材、订单策略、订单频次及推送比控制等。

策略管理单元:管理订单筛选的流量、流量曝光那个素材、策略是否做重定向等,都是通过策略管理确定的。

素材管理单元:管理不同媒体在投放时素材所需的素材规格、广告位、监测代码,并送审给媒体,通过审核后可用于投放。

所述报表管理单元,用于统计分析每个订单的曝光目标量、曝光完成量、曝光完成率、累计曝光完成率、推送目标量、推送完成量、推送完成率、优选完成量、优选完成率、退回流量、协议退回率、流量退回率,并以图形加表格方式展现,对数据进行导出;还用于监测每个订单的点击、ctr、ta浓度、uv、cpuv和非ta流量,用于及时调整广告位的素材和策略提高ctr和ta浓度。

所述流量清洗单元:用于清洗接收流量中的无效流量、异常流量,安全事件告警,提升带宽利用的有效性。

所述算法模型单元,用于根据12+n级退量平衡算法设计的算法模型。

所述广告位监测单元,用于监测广告位的在不同计划、订单、客户端、素材的曝光量、点击量、点击率、uv和cpuv,用于广告位素材和策略的后续优化。

作为上述方案的改进,所述大数据服务平台包括spark内存批处理、hive数据仓库、sqoopetl工具、azkaban调度和es搜索引擎。

作为上述方案的改进,所述spark内存批处理用于支撑系统内各种维度数据分析和复杂算法,所述维度数据分析和复杂算法包括sql查询、文本处理、机器学习。

作为上述方案的改进,所述策略管理单元生成的策略包是通过大数据平台实现,投放产生的媒体流量日志会回流到所述大数据平台。

附图说明

图1是本发明一实施例提供的一种广告投放系统的结构示意图。

图2是本发明一实施例提供的一种广告投放系统的结构示意图。

图3是本发明一实施例提供的数据分析的架构流程图。

图4是本发明一实施例提供的策略管理单元和大数据平台的交互示意图。

具体实施方式

下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。

参见图1,是本发明一实施例提供的一种广告投放系统,包括:

基础设施模块101,用于构建所述广告投放系统的硬件和框架;

基础服务模块102,用于提供认证服务、监控服务、文件服务、配置服务、mq服务和task服务;

数据库模块103,用于存储通过hadoop收集且通过sqoop工具同步的数据;

大数据服务平台104,为各类计算框架提供资源的管理和调度;

应用层模块105,用于通过基于技术协议的接口支撑广告投放系统顶层应用。

如图2所示,在另一种优选实施例中,所述基础设施模块101包括私有云、bgp机房、ssd和监控报警单元,其中,所述私有云基于openstack搭建;所述bgp机房网络为bgp线路,ssd为针对部分高速读写的业务提供的高性能磁盘,所述监控报警单元用于云平台健康运行状态的监控及故障响应跟踪。整个基础设施即iaas层服务。

所述认证服务包括安全控制和权限管控,所述监控服务包括云平台提供的paas级监控和基于开源zabbix以及open-falcon的监控,实时对业务系统进行监控,以确保系统高效运行;所述文件服务包括fast-dfs集群、用于接口数据传输的ftp服务和为web提供的文件级服务;所述配置服务包括zkui和dubboadmin配置管理工具,主要是统一的配置管理;所述mq服务及task服务用于爬取数据和回流数据,所述数据包括idfa数据、mac数据、imel数据和androidid数据。

所述数据库模块103包括nosql集群、mysql集群、hbase分布式集群和kafka队列;其中,所述nosql集群用于存储多维度标签数据,以及用于存储实时逻辑数据以及流量筛选逻辑处理;所述mysql集群用于存储系统平台关系型数据,所述系统平台关系型数据包括订单数据和策略管理数据;所述hbase分布式集群用于存储广告用户特征和广告展示环境特征的数据,对于用户特征与广告展示特征,即用户标签数据,广告投放会有一定部分日志回流,这部分日志包含了用户id数据以及触达的广告点位数据;所述kafka队列用于存储和清洗非结构化数据,所述非结构化数据为nosql标签数据的原始数据。

数据存储在内存和磁盘两级,内存中存放热点数据,磁盘中存放全量数据。内存中的数据包括历史数据和实时数据两部分,实时数据流会更新实时数据,在查询的时候,集群负责同时查历史和实时两份数据,合并后将结果返回。在投放过程中,绝大多数媒体要求100毫秒内处理一个请求,这块对实时性能要求非常高,此时需要预先根据业务需求查询磁盘业务数据存储到内存中,当有投放流量进来的时候,业务处理不读取磁盘,读取内存数据即可。

所述应用层模块包括计划管理单元、策略管理单元、素材管理单元、广告主管理单元、报表管理单元、算法模型单元、流量清洗单元和广告位检测单元;所述计划管理单元、策略管理单元、素材管理单元、广告主管理单元、报表管理单元、算法模型单元、流量清洗单元和广告位检测单元之间的交互均以以rpcdubbo作为基础架构实现。

所述广告主管理单元,用于管理广告主客户基本信息,并根据不同媒体要求进行送审和审核。

所述订单管理单元:管理每个投放计划下的订单,包括订单状态、订单基本信息增删改查、订单素材、订单策略、订单频次及推送比控制等。

策略管理单元:管理订单筛选的流量、流量曝光那个素材、策略是否做重定向等,都是通过策略管理确定的。

素材管理单元:管理不同媒体在投放时素材所需的素材规格、广告位、监测代码,并送审给媒体,通过审核后可用于投放。

所述报表管理单元,用于统计分析每个订单的曝光目标量、曝光完成量、曝光完成率、累计曝光完成率、推送目标量、推送完成量、推送完成率、优选完成量、优选完成率、退回流量、协议退回率、流量退回率,并以图形加表格方式展现,对数据进行导出;还用于监测每个订单的点击、ctr、ta浓度、uv、cpuv和非ta流量,用于及时调整广告位的素材和策略提高ctr和ta浓度。

所述流量清洗单元:用于清洗接收流量中的无效流量、异常流量,安全事件告警,提升带宽利用的有效性。

所述算法模型单元,用于根据12+n级退量平衡算法设计的算法模型。

所述广告位监测单元,用于监测广告位的在不同计划、订单、客户端、素材的曝光量、点击量、点击率、uv和cpuv,用于广告位素材和策略的后续优化。

所述大数据服务平台104包括spark内存批处理、hive数据仓库、sqoopetl工具、azkaban调度和es搜索引擎。

资源调度层采用业界主流的azkaban资源调度平台,可为各类计算框架提供资源的管理和调度,具备处理大数据时的层级队列、容量保证、安全性高、可伸缩性强的优势。支撑和调度系统大规模的各种数据分析。与数据存储层和数据分析层交互如下:

1.client向azkaban提交job,首先找resourcemanager分配资源,

2.resourcemanager开启一个container,在container中运行一个applicationmanager

3.applicationmanager找一台nodemanager启动applicationmaster,计算任务所需的计算

4.applicationmaster向applicationmanager(azkaban)申请运行任务所需的资源

5.resourcescheduler将资源封装发给applicationmaster

6.applicationmaster将获取到的资源分配给各个nodemanager

7.各个nodemanager得到任务和资源开始执行maptask

8.maptask执行结束后,开始执行reducetask

9.maptask和reducetask将执行结果反馈给applicationmaster

10.applicationmaster将任务执行的结果反馈applicationmanager。

数据分析层分为在线分析、近线分析、离线分析,在线和近线分析中,技术上采用实时数据计算框架spark及storm框架,作为大规模数据处理而设计的快速通用的计算引擎,支撑系统内各种维度数据分析和复杂算法,包括sql查询、文本处理、机器学习。在离线分析中,使用hdfs存储数据和mapreduce做批量计算,计算完成的数据存入hive数据仓库。在线分析、近线分析及所述离线分析主要是分析用户标签数据,广告点位以及特征数据,架构流程如图3所示。

系统的策略管理生成的策略包是通过大数据平台实现,投放产生的媒体流量日志会回流到我方大数据平台,所述内容或者模块与所述数据分析层的交互与联系如图4所示。

所述广告投放系统的管理采用微服务架构,结合devops,动态增减容,构建稳健的高可用系统。强大的运维监控体系,服务自动治理,结合实时监控shiro框架,确保系统的安全性。另外,系统采用全栈框架,使得处理能力达到qps>60万,tps>7万,响应速率<30ms,远低于行业标准100ms的响应速率,减少了广告系统的网络带宽,提高系统响应时间,实现高流量并发的广告投放。

以上所述是本发明的优选实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本发明原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也视为本发明的保护范围。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1