Talkingdata

DynamoDB 是 Amazon 基于《 Dynamo: Amazon’s Highly Available Key-value Store 》实现的 NoSQL 数据库服务。它可以满足数据库无缝的扩展，可以保证数据的持久性以及高可用性。开发人员不必费心关注 DynamoDB 的维护、扩展、性能等一系列问题，它由 Amazon 完全托管，开发人员可以将更多的精力放到架构和业务层面上。 本文主要介绍作者所在团队在具体业务中所遇到的挑战，基于这些挑战为何最终选型使用 Amazon DynamoDB，在实践中遇到了哪些问题以及又是如何解决的。文中不会详细讨论 Amazon DynamoDB 的技术细节，也不会涵盖 Amazon DynamoDB 的全部特性。 背景与挑战TalkingData 移动广告效果监测产品（TalkingData Ad Tracking）作为广告主与媒体之间的一个广告投放监测平台，每天需要接收大量的推广样本信息和实际效果信息，并最终将实际的效果归因到推广样本上。 举个例子，我们通过手机某新闻类 APP 浏览信息，会在信息流中看到穿插的广告，广告可能是文字形式、图片形式、视频形式的，而不管是哪种形式的广告它们都是可以和用户交互的。 如果广告推送比较精准，刚好是用户感兴趣的内容，用户可能会去点击这个广告来了解更多的信息。一旦点击了广告，监测平台会收到这一次用户触发的点击事件，我们将这个点击事件携带的所有信息称为样本信息，其中可能包含点击的广告来源、点击广告的时间等等。通常，点击了广告后会引导用户进行相关操作，比如下载广告推荐的 APP，当用户下载并打开 APP 后，移动广告监测平台会收到这个 APP 发来的效果信息。到此为止，对于广告投放来说就算做一次成功转化。 DynamoDB实践：当数据量巨大而不可预知，如何保证高可用与实时性？ 移动广告监测平台需要接收源源不断的样本信息和效果信息，并反复、不停的实时处理一次又一次转化。对于监测平台来讲，它的责任重大，不能多记录，也不能少记录，如果转化数据记多了广告主需要多付广告费给媒体，记少了媒体会有亏损。这样就为平台带来了几大挑战： 数据量大：有的媒体为了利益最大化可能会采取非正常手段制造假的样本，产生“虚假流量”，所以广告监测平台除了会收到真实用户样本外，也会收到大量造假的样本，影响正常的监测和归因。在最“疯狂”的时候，我们的平台会在一天内收到 40 亿 + 的点击样本事件请求。要知道，这些点击样本事件是要保留下来作为后续效果归因用的，而且样本有效期大不相同，从最短 12 小时到最长 90 天不等。数据量不可预知：对于广告主的大推、应用商店竞价排名等一系列的推广，会导致突发大量样本数据流入。面对这些流量不可预知的情况，我们仍要保证系统的正确、稳定、实时。实时处理：广告主依赖广告监测平台实时处理的结果来调整广告推广策略。因此广告监测平台需要支持数据实时处理，才能为广告主更快的优化推广策略提供有力支撑。与此同时，广告监测平台的处理结果也要实时回传给媒体方以及广告主。可以看到，准确性和实时性是系统必须要满足的基本条件。样本存储：我们的业务最核心的功能就是归因，我们要明确例如用户下载打开 APP 的这个转化效果是由哪一个推广活动样本带来的——也就是上图中的第 7 步，当用户安装 APP 后，监测平台要对应找到第 1 步中样本所在推广活动，这个是一个查询匹配的过程。对于庞大的归因样本数据，有效期又各不相同，我们应该怎样存储样本才能让系统快速归因，不影响实时结果，这也是一个很大的挑战。最初形态在 2017 年 6 月前我们的业务处理服务部署在机房，使用 Redis Version 2.8 存储所有样本数据。Redis 使用多节点分区，每个分区以主从方式部署。在最开始我们 Redis 部署了多个节点，分成多个分区，每个分区一主一从。刚开始这种方式还没有出现什么问题，但随着用户设置的样本有效期加长、监测样本增多，当时的节点数量逐渐已经不够支撑业务存储量级了。如果用户监测推广量一旦暴增，我们系统存储将面临崩溃，业务也会瘫痪。于是我们进行了第一次扩容。 ...