看来在线广告领域应该尽可能技术先进和自动化。 当然，因为 Yandex、Mail.Ru、Google 和 Facebook 等各自领域的巨头和专家都在那里工作。 但事实证明，完美是没有极限的，总有一些东西可以自动化。
通讯组 电通安吉斯网络俄罗斯 是数字广告市场最大的参与者，正在积极投资技术，试图优化和自动化其业务流程。 在线广告市场尚未解决的问题之一是收集不同互联网平台广告活动的统计数据。 这个问题的解决最终导致了产品的创建 D1.数码 （读作 DiVan），我们要谈谈它的发展。
Зачем？
1. 在项目启动时，市场上还没有任何现成的产品可以解决广告活动统计数据的自动化收集问题。 这意味着除了我们自己之外没有人能够满足我们的需求。
Improvado、Roistat、Supermetrics、SegmentStream 等服务提供与平台、社交网络和 Google Analitycs 的集成，并且还可以构建分析仪表板以方便分析和控制广告活动。 在我们开始开发产品之前，我们尝试使用其中一些系统从网站收集数据，但不幸的是，它们无法解决我们的问题。
主要问题是测试的产品基于数据源，按网站显示投放统计数据，并且不提供聚合广告活动统计数据的功能。 这种方法不允许我们在一个地方看到来自不同站点的统计数据并分析整个活动的状态。
另一个因素是，在最初阶段，产品针对的是西方市场，不支持与俄罗斯站点的集成。 对于那些实施集成的网站，所有必要的指标并不总是下载足够的细节，并且集成并不总是方便和透明，特别是当需要获取系统界面中没有的东西时。
总的来说，我们决定不适应第三方产品，而是开始开发我们自己的......
2、网络广告市场逐年增长，2018年，就广告预算而言，超过了传统上最大的电视广告市场。 所以有一个尺度.
3、与商业广告销售被垄断的电视广告市场不同，有很多规模不等的广告库存个人拥有者在互联网上拥有自己的广告账户进行经营。 由于广告活动通常会同时在多个站点上运行，因此为了了解广告活动的状态，有必要收集所有站点的报告并将它们组合成一个可以显示全貌的大型报告。 这意味着存在优化的潜力。
4. 在我们看来，互联网广告库存的所有者已经拥有收集统计数据并将其显示在广告帐户中的基础设施，并且他们将能够为这些数据提供 API。 这意味着它在技术上是可以实现的。 我们马上说，事实证明事情没有那么简单。
总的来说，实施该项目的所有先决条件对我们来说都是显而易见的，我们开始努力使该项目付诸实践......
宏伟计划
首先，我们形成了一个理想系统的愿景：
- 1C企业系统中的广告活动应自动加载到其中，包括其名称、周期、预算和在各个平台上的展示位置。
- 对于广告活动中的每个展示位置，应从进行展示位置的网站自动下载所有可能的统计数据，例如展示次数、点击次数、浏览次数等。
- 一些广告活动是通过所谓的广告服务系统（例如 Adriver、Weborama、DCM 等）使用第三方监控进行跟踪的。 俄罗斯还有一个工业互联网仪表——Mediascope公司。 根据我们的计划，来自独立和工业监测的数据也应该自动加载到相应的广告活动中。
- 互联网上的大多数广告活动都是针对某些目标操作（购买、致电、注册试驾等），这些活动是使用 Google Analytics 进行跟踪的，其统计数据对于了解活动的状态也很重要应该加载到我们的工具中。
第一个煎饼是块状的
鉴于我们对软件开发的灵活原则（敏捷、一切）的承诺，我们决定首先开发 MVP，然后迭代地实现预期目标。
我们决定根据我们的产品构建 MVP DANBo（电通安吉斯网络董事会），这是一个网络应用程序，包含有关我们客户的广告活动的一般信息。
对于MVP来说，项目在实现方面尽可能的简化。 我们选择了有限的集成平台列表。 这些是主要平台，例如Yandex.Direct、Yandex.Display、RB.Mail、MyTarget、Adwords、DBM、VK、FB，以及主要广告系统Adriver和Weborama。
为了通过 API 访问网站统计信息，我们使用了单个帐户。 想要使用自动收集广告活动统计数据的客户组经理必须首先将对网站上必要的广告活动的访问权限委托给平台帐户。
接下来是系统用户 丹波 需要将一定格式的文件上传到Excel系统中，其中包含投放的所有信息（广告活动、平台、格式、投放周期、计划指标、预算等）以及相应广告活动在平台上的标识符。广告系统中的站点和柜台。
坦率地说，它看起来很可怕：
下载的数据被保存到数据库中，然后单独的服务从它们收集网站上的活动标识符并下载它们的统计数据。
对于每个站点，都编写了一个单独的 Windows 服务，该服务每天一次在站点 API 中的一个服务帐户下运行，并下载指定活动 ID 的统计信息。 广告系统也发生了同样的事情。
下载的数据以小型自定义仪表板的形式显示在界面上：
出乎我们意料的是，MVP 开始工作并开始下载互联网上广告活动的最新统计数据。 我们在多个客户端上实施了该系统，但在尝试扩展时，我们遇到了严重的问题：
- 主要问题是准备数据加载到系统中的复杂性。 此外，在加载之前，放置数据必须转换为严格固定的格式。 有必要在下载文件中包含来自不同站点的实体标识符。 我们面临的事实是，未经技术培训的用户很难解释在网站上哪里可以找到这些标识符以及需要在文件中的何处输入它们。 考虑到在网站上开展活动的部门的员工数量和营业额，这导致我们这边得到了大量的支持，我们对此绝对不满意。
- 另一个问题是，并非所有广告平台都有将广告活动的访问权限委托给其他帐户的机制。 但即使有授权机制可用，也不是所有广告商都愿意将其广告活动的访问权限授予第三方帐户。
- 一个重要的因素是引起了用户的愤慨，因为他们已经输入我们1C会计系统的所有计划指标和投放细节必须重新输入 丹波.
这让我们想到，有关放置的信息的主要来源应该是我们的 1C 系统，所有数据都准确、按时地输入到该系统中（这里的要点是，发票是根据 1C 数据生成的，因此将数据正确输入到 1C 中）是每个人的首要任务 KPI）。 这就是系统的新概念的出现......
概念
我们决定做的第一件事是将收集互联网广告活动统计数据的系统分离成一个单独的产品 - D1.数码.
在新概念中，我们决定加载 D1.数码 1C 中有关广告活动及其展示位置的信息，然后从网站和广告服务系统中提取统计数据到这些展示位置。 这应该会显着简化用户的生活（并且像往常一样，为开发人员增加更多工作）并减少支持量。
我们遇到的第一个问题是组织性质的，与我们无法找到可以将不同系统中的实体与 1C 中的营销活动和展示位置进行比较的关键或标志这一事实有关。 事实上，我们公司的流程是这样设计的：广告活动由不同的人（媒体策划者、购买者等）输入不同的系统。
为了解决这个问题，我们必须发明一个唯一的散列密钥 DANBoID，它将不同系统中的实体链接在一起，并且可以在下载的数据集中相当容易且唯一地识别。 该标识符在内部 1C 系统中为每个单独的展示位置生成，并传输到所有网站和所有 AdServing 系统中的营销活动、展示位置和计数器。 实施将 DANBoID 放入所有展示位置的做法花费了一些时间，但我们成功做到了:)
然后我们发现并非所有网站都有自动收集统计数据的 API，即使有 API，它也不会返回所有必要的数据。
现阶段，我们决定大幅减少整合平台列表，重点关注参与绝大多数广告活动的主要平台。 该列表包括广告市场（Google、Yandex、Mail.ru）、社交网络（VK、Facebook、Twitter）、主要广告服务和分析系统（DCM、Adriver、Weborama、Google Analytics）和其他平台的所有最大参与者。
我们选择的大多数网站都有一个 API，可以提供我们所需的指标。 在没有 API 或不包含必要数据的情况下，我们使用每天发送到我们办公室电子邮件的报告来加载数据（在某些系统中可以配置此类报告，在其他系统中我们同意开发此类报告）为了我们）。
在分析不同站点的数据时，我们发现不同系统中实体的层次结构并不相同。 此外，需要从不同的系统下载不同细节的信息。
为了解决这个问题，开发了 SubDANBoID 概念。 SubDANBoID 的思路很简单，我们用生成的 DANBoID 来标记站点上活动的主要实体，并上传所有具有唯一站点标识符的嵌套实体，并根据 DANBoID 原则 + 第一级标识符形成 SubDANBoID嵌套实体+第二级嵌套实体的标识符+...这种方法使我们能够连接不同系统中的广告活动并下载它们的详细统计数据。
我们还必须解决在不同平台上访问活动的问题。 正如我们上面所写，将活动访问权限委托给单独的技术帐户的机制并不总是适用。 因此，我们必须开发一个基础设施，以便使用令牌和更新这些令牌的机制通过 OAuth 自动授权。
在本文后面，我们将尝试更详细地描述该解决方案的架构和实现的技术细节。
解决方案架构1.0
当开始实施新产品时，我们明白我们立即需要提供连接新站点的可能性，因此我们决定走微服务架构的道路。
在设计架构时，我们将所有外部系统（1C、广告平台和广告系统）的连接器分离为单独的服务。
主要思想是站点的所有连接器都具有相同的 API，并且是将站点 API 带到对我们来说方便的接口的适配器。
我们产品的核心是一个 Web 应用程序，它是一个整体，其设计方式可以轻松地分解为服务。 该应用程序负责处理下载的数据，整理来自不同系统的统计数据并将其呈现给系统用户。
为了在连接器和 Web 应用程序之间进行通信，我们必须创建一项附加服务，我们将其称为连接器代理。 它执行服务发现和任务计划程序的功能。 该服务每晚为每个连接器运行数据收集任务。 编写服务层比连接消息代理更容易，对我们来说，尽快获得结果非常重要。
为了简单性和开发速度，我们还决定所有服务都将是 Web API。 这使得快速组装概念验证并验证整个设计是否有效成为可能。
一项单独且相当复杂的任务是设置从不同帐户收集数据的访问权限，正如我们决定的那样，这应该由用户通过 Web 界面执行。 它由两个单独的步骤组成：首先，用户添加令牌以通过 OAuth 访问帐户，然后配置客户端从特定帐户收集的数据。 通过 OAuth 获取令牌是必要的，因为正如我们已经写过的，并不总是可以将访问权限委托给网站上所需的帐户。
为了创建从站点选择帐户的通用机制，我们必须向连接器 API 添加一个返回 JSON 架构的方法，该方法使用修改后的 JSONEditor 组件呈现为表单。 这样，用户就可以选择从中下载数据的帐户。
为了遵守网站上存在的请求限制，我们将设置请求合并到一个令牌中，但我们可以并行处理不同的令牌。
我们选择 MongoDB 作为 Web 应用程序和连接器加载数据的存储，这使我们不必在开发的初始阶段过多担心数据结构，因为应用程序的对象模型每隔一天都会发生变化。
我们很快发现并非所有数据都适合 MongoDB，例如，将日常统计数据存储在关系数据库中更方便。 因此，对于数据结构更适合关系数据库的连接器，我们开始使用PostgreSQL或MS SQL Server作为存储。
所选择的架构和技术使我们能够相对快速地构建和推出 D1.Digital 产品。 在两年多的产品开发过程中，我们开发了 23 个站点连接器，获得了与第三方 API 合作的宝贵经验，学会了避免不同站点的陷阱（每个站点都有自己的陷阱），为至少 3 个 API 的开发做出了贡献网站自动下载了近15个活动和000多个展示位置的信息，收集了大量用户对产品操作的反馈，并根据这些反馈多次更改了产品的主要流程。
解决方案架构2.0
自开始开发以来已经过去两年了 D1.数码。 系统负载的不断增加以及越来越多新数据源的出现逐渐暴露出现有解决方案架构中的问题。
第一个问题与从网站下载的数据量有关。 我们面临这样一个事实：从最大的站点收集和更新所有必要的数据开始花费太多时间。 例如，从 AdRiver 广告投放系统收集数据（我们使用该系统跟踪大多数展示位置的统计数据）大约需要 12 小时。
为了解决这个问题，我们开始使用各种报表从站点下载数据，我们正在尝试与站点一起开发他们的API，使其运行速度满足我们的需求，并尽可能并行化数据下载。
另一个问题涉及下载数据的处理。 现在，当新的展示位置统计数据到达时，会启动重新计算指标的多阶段过程，其中包括加载原始数据、计算每个网站的聚合指标、比较不同来源的数据以及计算活动的汇总指标。 这会导致执行所有计算的 Web 应用程序承受大量负载。 有几次，在重新计算过程中，应用程序消耗了服务器上的所有内存，大约10-15 GB，这对用户使用系统的工作产生了最不利的影响。
所发现的问题和进一步开发产品的雄心勃勃的计划使我们需要重新考虑应用程序架构。
我们从连接器开始。
我们注意到所有连接器都按照相同的模型工作，因此我们构建了一个管道框架，在其中创建连接器时只需编写步骤的逻辑，其余部分都是通用的。 如果某些连接器需要改进，那么我们在改进连接器的同时立即将其转移到新框架。
与此同时，我们开始将连接器部署到 Docker 和 Kubernetes。
我们计划迁移到 Kubernetes 很长一段时间，尝试了 CI/CD 设置，但只有当一个连接器由于错误而开始占用服务器上超过 20 GB 的内存，几乎杀死了其他进程时才开始迁移。 在调查过程中，连接器被移至 Kubernetes 集群，即使在错误修复后，它最终仍保留在那里。
很快我们就意识到 Kubernetes 很方便，在六个月内我们将 7 个连接器和消耗资源最多的连接器代理转移到生产集群。
在连接器之后，我们决定更改应用程序其余部分的架构。
主要问题是数据大批量地从连接器发送到代理，然后到达 DANBoID 并发送到中央 Web 应用程序进行处理。 由于大量的指标重新计算，应用程序的负载很大。
事实证明，监控各个数据收集作业的状态并将连接器中发生的错误报告给中央 Web 应用程序非常困难，以便用户可以了解正在发生的情况以及未收集数据的原因。
为了解决这些问题，我们开发了架构2.0。
新版本架构的主要区别在于，我们使用 RabbitMQ 和 MassTransit 库而不是 Web API 在服务之间交换消息。 为此，我们必须几乎完全重写 Connectors Proxy，使其成为 Connectors Hub。 名称已更改，因为该服务的主要作用不再是将请求转发到连接器并返回，而是管理来自连接器的指标集合。
从中央网络应用程序中，我们将有关展示位置和统计信息的信息从网站中分离到单独的服务中，这使得摆脱不必要的重新计算并仅存储展示位置级别上已经计算和汇总的统计数据成为可能。 我们还根据原始数据重写并优化了基础统计的计算逻辑。
同时，我们正在将所有服务和应用程序迁移到 Docker 和 Kubernetes，以使解决方案更易于扩展且更方便管理。
我们现在在哪
概念验证架构 2.0 产品 D1.数码 准备好并在具有有限连接器集的测试环境中工作。 剩下要做的就是将另外 20 个连接器重写到新平台，测试数据是否正确加载以及所有指标是否正确计算，然后将整个设计投入生产。
事实上，这个过程将逐渐发生，我们将不得不保留与旧 API 的向后兼容性，以保持一切正常运行。
我们的近期计划包括开发新的连接器、与新系统集成以及向从连接的站点和广告系统下载的数据集添加额外的指标。
我们还计划将所有应用程序（包括中央 Web 应用程序）转移到 Docker 和 Kubernetes。 与新架构相结合，这将显着简化消耗资源的部署、监控和控制。
另一个想法是尝试选择存储统计信息的数据库，目前存储在 MongoDB 中。 我们已经将几个新的连接器转移到 SQL 数据库，但差异几乎无法察觉，并且对于可以在任意时间段内请求的按天聚合统计数据，增益可能相当大。
总的来说，计划很宏大，让我们继续吧:)
电通安吉斯网络俄罗斯研发一文的作者：Georgy Ostapenko (），米哈伊尔·科齐克（)
来源： habr.com