本文探讨了数据管理平台（DMP）在广告定向和个性化推荐中的应用，强调了DMP系统对低响应时间、高可用性、高并发和低成本的需求。分析了MongoDB在DMP、数据管道和数据仓库场景中的局限性，并提出更合适的解决方案，如Aerospike用于KV数据库，Kafka用于数据管道，以及Hive或使用SSD的列族数据库如Cassandra用于数据仓库。Cassandra通过顺序写和BloomFilter优化随机读写性能，适应SSD硬盘，以提高高并发随机读写的效率。
目录
一、DMP：数据管理平台
DMP 系统的全称叫作数据管理平台（Data Management Platform），目前广泛应用在互联网的广告定向（Ad Targeting）、个性化推荐（Recommendation）这些领域。
DMP 系统会通过处理海量的互联网访问数据以及机器学习算法，给一个用户标注上各种各样的标签。然后，在做个性化推荐和广告投放的时候，再利用这些标签，去做实际的广告排序、推荐等工作。无论是 Google 的搜索广告、淘宝里千人千面的商品信息，还是抖音里面的信息流推荐，背后都会有一个 DMP 系统。
对于外部使用 DMP 的系统或者用户来说，可以简单地把 DMP 看成是一个键 - 值对（Key-Value）数据库。广告系统或者推荐系统，可以通过一个客户端输入用户的唯一标识（ID），然后拿到这个用户的各种信息。
这些信息中，有些是用户的人口属性信息（Demographic），比如性别、年龄；有些是非常具体的行为（Behavior），比如用户最近看过的商品是什么，用户的手机型号是什么；有一些是通过算法系统计算出来的兴趣（Interests），比如用户喜欢健身、听音乐；还有一些则是完全通过机器学习算法得出的用户向量，给后面的推荐算法或者广告算法作为数据输入。
基于此，对于这个 KV 数据库，我们的期望也很清楚，那就是：低响应时间（Low Response Time）、高可用性（High Availability）、高并发（High Concurrency）、海量数据（Big Data），付得起对应的成本（Affordable Cost）。如果用数字来衡量这些指标，那么我们的期望就会具体化成下面这样。
- 低响应时间：一般的广告系统留给整个广告投放决策的时间也就是 10ms 左右，所以对于访问 DMP 获取用户数据，预期的响应时间都在 1ms 之内。
- 高可用性：DMP 常常用在广告系统里面。DMP 系统出问题，往往就意味着整个的广告收入在不可用的时间就没了，所以对于可用性的追求可谓是没有上限的。Google 2018 年的广告收入是 1160 亿美元，折合到每一分钟的收入是 22 万美元。即使我们做到 99.99% 的可用性，也意味着每个月我们都会损失 100 万美元。
- 高并发：还是以广告系统为例，如果每天我们需要响应 100 亿次的广告请求，那么我们每秒的并发请求数就在 100 亿 / (86400) ~= 12K 次左右，所以DMP 需要支持高并发。
- 数据量：如果产品针对中国市场，那么需要有 10 亿个 Key，对应的假设每个用户有 500 个标签，标签有对应的分数。标签和分数都用一个 4 字节（Bytes）的整数来表示，那么一共需要 10 亿 x 500 x (4 + 4) Bytes = 4 TB 的数据。
- 低成本：从广告系统的角度来考虑，广告系统的收入通常用 CPM（Cost Per Mille），也就是千次曝光来统计。如果千次曝光的利润是 0.10 美元，那么每天 100 亿次的曝光就是 100 万美元的利润。这个利润听起来非常高了。但是反过来算一下，DMP 每 1000 次的请求的成本不能超过 0.10 美元。最好只有 0.01 美元，甚至更低，才能尽可能多赚到一点广告利润。
为了能够生成这个 KV 数据库，我们需要有一个在客户端或者 Web 端的数据采集模块，不断采集用户的行为，向后端的服务器发送数据。服务器端接收到数据，就要把这份数据放到一个数据管道（Data Pipeline）里面。数据管道的下游，需要实际将数据落地到数据仓库（Data W
最低0.47元/天 解锁文章
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
