- 每天插入约 1000 亿条记录，每秒超过 100 万条记录
- 能够每天聚合超过 10 亿个唯一用户
- 从 MSSQL 迁移到 Azure 表存储，再迁移到 ClickHouse
- ClickHouse 部署在 15 台服务器上，总内存为 2 TB
Admixer 是一家广告科技公司，为品牌、广告代理商、媒体机构、发布商、广告网络以及其他寻求有效广告管理的买方和卖方行业参与者提供构建广告产品基础设施的所有组件。Admixer 的一个显著特点是其技术，它允许
- 代理商投放具有指定执行条件（条款、预算、创意展示设置）的广告活动
- 设置在数千家发布商之间分配广告活动预算的规则
- 为发布商提供账户，他们不仅可以查看收入统计信息或提取资金，还可以创建自己的广告活动，以及除了网络广告活动之外连接其他盈利来源。
Admixer 的产品包括
- SSP – 供给方平台，发布商/网站在其中提供广告位
- DSP – 需求方平台，广告主在其中购买广告位
- ADX – 广告交易平台（连接 SSP 和 DSP – 广告和广告位的买方和卖方）
- DMP – 数据管理平台（广告主使用它来配置他们想要定位的目标受众）
Admixer 不仅提供对这些产品的访问，还允许客户构建整个生态系统。
为了实现前一点，Admixer 开始开发广告交易平台。最初，广告交易平台基于外部 DSP 销售本地库存。然后它开始聚合外部 SSP 的流量，在其上投放本地广告，然后将此流量重定向到外部 DSP。因此，创建了 ADX。
在 2015-2016 年，外部库存的份额为 3%（1 亿次请求），然后在 2016 年底，超过 90%（30 亿次请求）。随着请求数量的急剧增加，其处理负载也随之增加，最重要的是，存储和提供在线分析的负载也增加了。关系型数据库无法处理如此大量的统计记录插入。在迁移到 Azure 之前，我们使用 MSSQL 服务器存储对象结构和统计信息。
2011 年，在迁移到 Azure 时，我们使用 Azure 表存储来存储和发布统计信息。但是，随着交易数量和数据量的增加，使用此解决方案并非最佳选择，因为 Azure 表存储会根据交易数量和数据量收费。
因此，我们需要
- 在用户界面中实时显示广告交易的统计信息；
- 接受大量（每秒 100 万条记录）数据插入；
- 为不同部分聚合接收到的数据（40 个操作和相同数量的指标）；
- 能够随着请求数量的增长扩展数据仓库；
- 完全控制我们的成本。
此图像显示了配置文件报告。Admixer 中的任何广告活动都按广告系列细分（配置文件）。可以概述每个配置文件的详细报告，包括日期时间统计信息、地理位置、域名、SSP。此报告也会实时更新。
ClickHouse 有助于应对上述挑战，并提供以下益处
- 不绑定到平台（我们决定从云端迁移）；
- 我们构建的集群允许我们每秒接收多达一百万次插入（并且我们知道如何在需要时扩展）；
- 具有用于在表之间聚合和分发数据的内置机制（物化视图）；
- 出色的数据压缩；
- 读取速度使得可以在用户界面中直接实时显示统计信息；
- 具有 SQL 方言，可以构建任何报告；
- 具有多个高级功能（并允许您编写自己的功能）来处理统计信息；
- 内置 HyperLogLog 用于存储粗略数据；
- 数据采样；
- 开源/社区/良好的文档；
- 不断添加新功能、修复错误并改进当前功能；
- 便捷的操作。
我们的架构从 2016 年到 2020 年发生了变化。下面有两个图表：我们开始时的状态和我们到达的状态。
2016 年架构
2020 年架构
请求处理程序是一个组件，它接受广告请求并确定要显示哪个横幅。选择横幅后，它会将其记录在统计信息中。自 2020 年以来，这些组件每秒接收超过 100 万个请求。统计信息通过名为全局事件队列的中间元素记录。事件从 GlobalEventsQueue 中检索，由 EventsProcessor 组件读取，并进行额外验证/丰富，然后写入 ClickHouse 集群。
最初，我们从 EventsProcessor 并行写入 ClickHouse 的多个表中，但随后切换到 Buffer->Null 表->MatViews。接下来，我们将调查 21.11 版中的新异步插入功能是否可以替代使用缓冲表。
我们还审查了事件队列的实现。最初，我们使用 Redis（但 Redis 是内存存储），因此
- 服务器重新启动时，存在丢失事件的风险；
- RAM 的数量相对较小，如果我们计划停止 Events Processor 或 ClickHouse，则存在事件队列溢出的风险，因此需要对事件处理器问题做出非常高的响应速度。
我们尝试替换 Redis 并改用 Kafka，但当时 ClickHouse 的 Kafka 驱动程序存在数组问题（此问题现已解决）。
因此，我们实现了我们自己的事件队列，该队列存储在每个 EventHandler 组件的磁盘上，并且本地 EventsProcessor 位于同一服务器上。EventsProcessor 组件的数量增加了，这意味着 ClickHouse 中的插入请求数量也增加了，但这并不是问题。
由于财务优化也是我们重要的因素，因此该方案在这方面也证明非常出色。为了接收来自 ADX 的数据处理和存储，我们组建了一个包含 15 台服务器的集群（40 个线程、128GB RAM、SSD 存储），并且我们也以一定的裕度考虑了这一点。对于唯一用户的存储集群，我们使用了包含 6 台相同服务器的集群。
另一个重点是与从集群接收数据相关的操作。如果随意向集群发送请求，可能会给它带来相当大的负载，导致其他进程速度变慢。但 ClickHouse 具有限制资源和为特定用户分配配额的设置，这使我们能够快速解决此问题。所有配置文件都可以完美地放置在配置管理系统中，并从那里进行管理。
除了按维度汇总指标的统计数据聚合之外，Admixer 还提供有关有多少唯一用户观看广告一定时间的信息。唯一用户数量无法直接相加。在我们的系统中，用户 ID 是 UUID。当我们想要获取某个任意时间段内的多个唯一 UUID 时，每次都需要重新计算该时间段内的唯一 UUID。我们无法预先分解所有可能的组合，因为交集将过大。
在使用 ClickHouse 之前，我们只能计算预定义时间段内的唯一用户数量：日、周、月和所有时间。此外，切片数量也受到限制。此外，对 Aerospike 的持续批量请求也减慢了事件处理器的速度。
AggregatingMergeTree 允许我们以最小的成本在一个报表中按大量键计算唯一用户数量。最初，使用由三台服务器组成的集群，我们可以在大约 12 个切片中轻松计算每天 10 亿个唯一用户。也有一些细微差别；大型切片无法输出到界面，因为同时扫描大型表会占用大量 CPU 时间。解决此问题的方案是报表生成服务，它拥有自己的内部队列，并将已生成的 CSV 文件发送到界面。另一方面，我们可以输出日期范围有限的小型切片到界面。
ClickHouse 非常适合作为我们机器学习模型的大数据存储。
细节决定成败！
ClickHouse 技术技巧
- 如果不需要高数据精度，请使用 HyperLogLog 和采样；
- 运行负载测试以确定您的集群在给定数据结构的情况下可以承受多少操作，然后再组装集群；
- 缓冲区是插入数据的好方法，但要注意内存；
- 使用 Native 格式进行插入；
- 避免在连续流插入中使用大量的小分区。过多的表会在后台生成大量的合并操作，例如“Too many parts (300)”错误；
- 需要在开始时确定复制方案。一种选择是使用 ZooKeeper，并让表使用 ReplicatedMergeTree 和其他复制表引擎自行复制。因为我们有很多表，并且希望选择数据的哪些部分复制到哪些服务器，所以我们选择不使用 ZooKeeper，而是让我们的客户端分散写入——每次写入都发送到两台服务器。
在过去的五年里，Admixer 的核心团队一直在处理高负载和大数据的聚合。任何工作都有其微妙之处，不要重蹈覆辙。使用我们的经验。
我们为客户提供专业的审计、咨询或使用 ClickHouse 创建现成的解决方案来解决高负载任务。这些专业服务现已通过我们的新计划 LoadFighters 提供。
Admixer 是一家独立的广告科技公司，开发了一个全栈程序化解决方案生态系统。Admixer 拥有自己的广告科技产品线，面向品牌、广告代理商、媒体公司、发布商、广告网络以及其他寻求有效广告管理的买卖双方行业参与者。我们可定制的技术、深入的专业知识和个性化方法帮助企业将程序化广告转化为可扩展的收入渠道。
自 2008 年成立以来，我们的使命一直是构建一个生态系统，在数字广告行业的所有参与者之间建立有效且透明的关系。
如今，该公司拥有 100 多家供应和需求合作伙伴、3000 多名客户和 200 多名全球员工。他们在乌克兰、白俄罗斯、哈萨克斯坦、摩尔多瓦、格鲁吉亚设有办事处，并在英国和德国设有法人实体。
更多信息请访问
