即席查询的问题
2015-08-17 15:58:30 12 举报AI智能生成
即席查询是一种在数据库中进行实时数据检索的方法，它允许用户根据需要动态地构建和执行查询语句。这种查询方式具有灵活性高、响应速度快的优点，特别适用于需要快速获取数据的场景。然而，由于即席查询涉及到大量的数据处理和计算，可能会对数据库性能产生一定影响。因此，在使用即席查询时，需要充分考虑查询的复杂性和数据库的性能瓶颈，以确保查询结果的准确性和系统的稳定性。
作者其他创作
大纲/内容
产品规划
基于可能的业务预测
要架设另一组
另一组里的国内业务比想象的要复杂
重构国内的媒体
基于可以衡量价值，价值被B类用户满意
推广告
盯盘
控盘
媒体上零碎的功能
实时报表
ad_group ad_set层级
用户感知
更多大块功能
接近更靠终极的理想，靠近产出价值
盯盘
推广告
控盘
监控
行动
国内投放细化到ad层
素材那一锅
扩展更多的媒体
已有细节功能做详细
报表分账号
海外子户管理
账号管理功能
自然量报表
729列
已有功能有明显进步
实时报表
adset报表
国内增加预约数据
接更多媒体
必须处理的内容
预约报表重构切换
基于更长远建设
薪酬情况
DSP对接志宽
目前进展
仍在核对主要待解决问题的解决方案
CPS打包和传包的机制问题会整体有调整，母包和分ID包都在志宽侧管理，双方的对接内容会调整
创建广告只有API一种形式，所有点击都由志宽的服务接收，所以DSP都返回志宽的APIurl 作为点击监测链接
媒体和token的使用，志宽可能考虑token存在他们那侧，DSP更改对接方式[双方都需要调整]
落地页制作部分，会准实时拿到志宽返回的CPS下载正确地址加入，并提示已经可以投放。改掉原先部分流程
需要有网站服务器的通信机制，方便上传落地页、落地页素材等
实时和离线数据细节对接
需要确定DSP网络部署的要求
归因逻辑，看咱们是否有更细节的要求，志宽可以调整
账号体系、权限机制
核对大致研发计划
志宽本周二、三给出
DSP这边本周内给出
下一步
明确细节接口和研发计划
准备部署细节
准备服务器资源
测试网络通信效果
研发、调试、上线、试运行
头条和广点通的开发者账号申请
产品研发
主线事项阶段1
技术
celery增加队列排队功能[为了降低日常运维压力、提高稳定性]
Google基础数据1.0拉取
Fb基础数据1.0拉取
谦谦数据入库存储结构调整[为了应对支持数据量的持续上升]
FB花费切换采用FB基础数据1.0的数据进行计算
GG花费切换采用GG基础数据1.0的数据进行计算
增量报表2.0[为了消灭全量计算报表，使得补数据的时候，可以快速用队列排队一天一天计算]
业务
广告盯盘页面1.0 + FB数据
报表支持呈现自然量数据
报表支持海外数据细化到ad_group和ad_set两层
tiktok 广告系统层报表
订阅报警功能
Twitter全面对接
盯盘页面 增加 开关控制
国内投放数据联合PDBI调整结构，使得可以和海外一样呈现广告组、广告创意层数据
DSP API 支持
主线事项阶段2
业务
FB推送广告
支线事项
技术
报表结果表持续超过729天的计算
单独的更新指定日期指定游戏报表上的花费
提升FB的调用频次限制
提升tiktok的调用频次限制
预约报表到OB日期可以自动更新为OB报表进行计算
业务
权限模块重构--支持同一用户在同一模块具体查询、操作等多种不同权限
报表增加账号维度
盯盘页面增加对GG的支持
NAS事项
调试领地下行网速
确定目录文件夹
开通onedrive 商业版账号
双向同步历史数据
配置达美的群晖细节、账号密码、目前权限、网络、共享登录等
转移并删除部分69的文件到达美群晖上
备份方案部署
招聘事项
计划
产品2+2TBD
1高级
1初级
python研发 7+1TBD
1高级
1初级
1初级
测试0+1TBD
1初中级
前端 3
预算情况
宪一：22870
建师：20500
李彬：26800
邹豪：26100
赵虎：44100
前端：35000
李帅：20500
赵薇：35000
0 条评论
下一页
