ADT(Advertising Tracking)广告追踪，也称它为移动广告效果监测，后面我们统称ADT。ADT的愿景是「希望帮助用户量化移动广告推广的效果，更聪明的使用每一分钱」针对这句话的字面意思能看到两个基本诉求：广告推广指标的量化和指标计算和呈现的实时性。这篇文章先介绍ADT到底是什么、它的价值何在、它又是如何工作的；再围绕ADT的愿景从技术层面展开讨论，也算是对我在TalkingData ADT团队工作的一个总结。

DynamoDB是Amazon基于《Dynamo: Amazon’s Highly Available Key-value Store》实现的NoSQL数据库服务。它可以满足数据库无缝的扩展，可以保证数据的持久性以及高可用性。开发人员不必关注DynamoDB的维护、扩展、性能等一系列问题，它由Amazon完全托管，开发人员可以将更多的精力放到架构和业务层面上。

本文主要介绍作者的工作团队所遇到的挑战，基于这些挑战最终为何选型使用Amazon DynamoDB，在实践中遇到了哪些问题以及又是如何解决的。因此文中不会重点讨论介绍Amazon DynamoDB的技术细节，文中也不会涵盖Amazon DynamoDB的全部特性。

Flink Kafa Connector是Flink内置的Kafka连接器，它包含了从Kafka Topic读入数据的Flink Kafka Consumer以及向Kafka Topic写出数据的Flink Kafka Producer，除此之外Flink Kafa Connector基于Flink Checkpoint机制提供了完善的容错能力。本文从Flink Kafka Connector的基本使用到Kafka在Flink中端到端的容错原理展开讨论。

ZooKeeper是一个开源分布式协调服务、分布式数据一致性解决方案。可基于ZooKeeper实现命名服务、集群管理、Master选举、分布式锁等功能。

高可用

为了保证ZooKeeper的可用性，在生产环境中我们使用ZooKeeper集群模式对外提供服务，并且集群规模至少由3个ZooKeeper节点组成。

集群至少由3个节点组成

ZooKeeper其实2个节点也可以组成集群并对外提供服务，但我们使用集群主要目的是为了高可用。如果2个节点组成集群，其中1个节点挂了，另外ZooKeeper节点不能正常对外提供服务。因此也失去了集群的意义。
如果3个节点组成集群，其中1个节点挂掉后，根据ZooKeeper的Leader选举机制是可以从另外2个节点选出一个作为Leader的，集群可以继续对外提供服务。

ZooKeeper是一个开源的分布式协调服务，它允许分布式进程通过共享层级相互协调。分布式应用可以基于ZooKeeper实现数据发布订阅、负载、命名服务、Master选举、分布式锁等功能。

ZooKeeper 数据模型

ZooKeeper的视图结构和Linux文件系统类似，ZooKeeper引入了数据节点(ZNode)的概念，每一个数据节点都被称为一个ZNode，ZNode在ZooKeeper中是数据的最小单元。
每个节点都以路径表示，我们可以向节点写入数据，也可以在节点下面创建子节点。

与典型的文件系统不同的是ZooKeeper的数据保存在内存中，这样可以实现更高吞吐和低延时。

Window意为窗口。在流处理系统中数据源源不断流入到系统，我们可以逐条处理流入的数据，也可以按一定规则一次处理流中的多条数据。当处理数据时程序需要知道什么时候开始处理、处理哪些数据。窗口提供了这样一种依据，决定了数据何时开始处理。

Flink内置Window

Flink有3个内置Window

• 以事件数量驱动的Count Window
• 以会话间隔驱动的Session Window
• 以时间驱动的Time Window

本文围绕这3个内置窗口展开讨论，我们首先了解这3个窗口在运行时产生的现象，最后再讨论它们的实现原理。

slf4j中MDC是什么鬼

slf4j除了trace、debug、info、warn、error这几个日志接口外，还可以配合MDC将数据写入日志。换句话说MDC也是用来记录日志的，但它的使用方式与使用日志接口不同。