OLAP的特点
电商这样的OLTP场景大家更熟悉。相比之下，OLAP的特点：
- 读相对多，1000row以上大批写入，不改已有数据
- 查询时输出很多行、很少列，结果被过滤或聚合后能够在一台服务器的内存中
- 单台服务器qps数百，但吞吐量每秒数十亿行
- 宽表，列总数多
- 事务不必须，数据一致性要求低
大数据的工作范畴、业务地位
大数据的研究对象，主要是通用分布式计算框架。任务调度（定时执行、相互依赖）和集群管理（选举、通信等）也算。
数据库应该做存储相关的事情。现在的互联网的大流量冲击下，如果把业务处理及计算放在数据库上，数据库的负载压力会特别大。现在大数据一般外置，由专门的集群负责业务处理及计算。从写sql存储过程，到写spark sql（sql + scala/python）和flink代码（java/scala）。
程序化广告
在CCTV黄金时段打洗脑广告的时代已经过去了。现在出现了很多小微流量主，私域不容小觑。
广告主想打广告，流量主想接广告。称为需求方和供给方。需要有一个“中介”，否则洽谈将无休无止。
广告主对不同的用户群体有不同的预算。“中介”需要考虑广告主的出价，用户的特征，广告位的上下文，来决定“你打开手机看见的是哪个广告”。能感觉到这是一个优化问题。
下面是singular公司对程序化广告的解释：
广告库存的实时拍卖发生在访问者登陆网页或应用程序加载屏幕的那一刻。使用数据和机器学习算法向用户提供最相关的广告。将用户个人资料或广告将放置的上下文中的任何已知数据与广告商对相关兴趣或受众人口统计数据的出价进行匹配，确保广告商能够为其营销工作带来回报。
移动营销的一种部门分工
工程
前后端的数据交互。用户加载、点击一个广告，观看、安装、充值/购买、更新app，都会产生日志，日志会发送到日志服务器。日志是最原始、最丰富的数据。比如事件信息（如日期时刻，点击位置）、用户信息（安装的其它app列表，设备信息）、广告信息（素材编号、图片/视频/可交互）、包信息（app类型，评分）。
数据中台
从上述日志中提取字段。设计表的字段（有点特征工程的意思）。也负责反作弊。
数分/运营
熟悉各类指标，比如日活、次留。他们工作一般面对BI软件，生产报表。
大数据平台
按不同粒度（比如日期，地区，事件类型）聚合数据，存储供查询。开发/维护存储和查询时需要用到的工具/集群，监控硬件指标以外的服务指标。解答用户使用时的问题。成本核算。自动化数据质量检测。
算法工程
开发/维护ABtest实验平台。目标是方便、快速比较哪个算法好，记录实验结果。
算法
生成算法提供广告素材，推荐算法给广告素材排序。目标是提高广告点击率。
未来趋势
感觉目前的云厂商有统一天下的野心。我这里仅举出我在这家公司亲眼看见的例子，想必只是冰山一角。之所以现在还没有一统，是因为目前在成本上：养人、开源二次开发、自己运维 < 云厂商服务。部门kafka评估出的全托管成本百万/月，目前用人还是更划算一些。
AWS Athena
AWS Athena是一种交互式查询服务，用户可以使用标准SQL直接在S3上轻松分析数据。也就是说，企业不需要养数据库（存储研究人员、DBA），也不再需要spark集群运维，bi运维。细分市场的BI服务提供商，比如帆软、tableau这种，也会受到冲击。
阿里云PAI
从上图可以看出，企业用户只需要提供数据集和配置，就能一键微调定制自己的大语言模型。可能只需要招1个人就够了。
AWS也提供类似的服务。amazon bedrock，model as a service，企业用户可以直接选择某一种模型（比如meta llama，amazon titan，anthropic等），打造自己公司的问答机器人，用的是公司自己提供的数据，以解决隐私合规等问题。他们提供了几种评估方式，帮助企业用户来做选择，playground手测，公开benchmark自动测，使用自己的数据集测，委托aws团队测。
