似乎在线广告领域应尽可能地技术化和自动化。 确实，Yandex，Mail.Ru，Google和Facebook等领域的巨头和专家在那里工作。 但是，事实证明，完美无极限，总有一些东西可以自动化。
来源传播集团
Dentsu Aegis Network Russia是数字广告市场上最大的参与者，并积极投资技术，以优化和自动化其业务流程。 在线广告市场尚未解决的问题之一是从不同的在线站点收集有关广告活动的统计数据的任务。 解决此问题的方法最终导致了
D1.Digital产品（称为DiVan）的创建，我们想谈一谈开发。
怎么了
1.在项目开始时，市场上没有一种成品可以解决自动收集广告活动统计信息的任务。
这意味着，只有我们自己可以满足我们的需求。Improvado，Roistat，Supermetrics，SegmentStream等服务提供与站点，社交网络和Google Analitycs的集成，还提供了构建分析仪表盘的功能，以方便对广告活动进行分析和控制。 在开始开发产品之前，我们尝试在工作中使用其中一些系统来从站点收集数据，但是不幸的是，它们无法解决我们的问题。
主要问题是被测产品是从数据源中剔除的，显示了按站点分类的展示位置的统计信息，并且不允许汇总广告活动的统计信息。 这种方法不允许在一处查看来自不同站点的统计信息，也无法分析整个运动的状态。
另一个因素是，在最初阶段，产品面向西方市场，不支持与俄罗斯站点的集成。 对于那些实施了集成的站点，并非总是上传具有足够详细信息的所有必要指标，并且集成也不总是那么方便和透明，尤其是在有必要获取系统界面中没有的内容时。
总的来说，我们决定不适应第三方产品，但开始开发自己的...
2.在线广告市场逐年增长，在广告预算方面，在线广告市场传统上在2018年超过了最大的电视广告市场。
所以有一个规模 。
3.与电视广告市场不同，在电视广告市场中，商业广告的销售被垄断，大量具有广告办公室的各种规模的广告设备的个人所有者在互联网上工作。 由于广告活动通常一次在多个站点上运行，因此为了了解广告活动的状态，有必要从所有站点收集报告并将它们汇总到一个可以显示整个图片的大型报告中。
因此，存在优化的潜力。4.在我们看来，互联网上广告库存的所有者已经拥有一个用于收集统计数据并将其显示在广告办公室中的基础结构，并且他们可以为该数据提供API。
因此，存在技术可行性。 我们将立即说这不是那么简单。
总的来说，实施该项目的所有先决条件对我们来说都是显而易见的，因此我们竭力实施该项目...
宏伟计划
首先，我们形成了理想系统的愿景：
- 它应自动从1C公司系统加载广告系列及其名称，期间，预算和在各种平台上的展示位置。
- 对于广告系列中的每个展示位置，应该自动下载正在进行该展示位置的网站的所有可能统计信息，例如展示次数，点击次数，观看次数等。
- 某些广告活动由所谓的广告系统通过第三方监控进行监控，例如Adriver，Weborama，DCM等。 俄罗斯还有一个工业互联网仪表-Mediascope。 根据我们的想法，独立监控和行业监控的数据也应自动上传到相应的广告系列中。
- 互联网上的大多数广告系列都针对某些针对性的操作（购买，呼叫，录制试驾等），这些操作已使用Google Analytics（分析）进行了跟踪，并且有关其的统计信息对于了解广告系列的状态也很重要，因此应上传到我们的工具中。
第一块煎饼块状
考虑到我们对软件开发的灵活原则（敏捷，所有事物）的承诺，我们决定首先开发MVP，然后迭代地实现预期的目标。
我们决定在我们的产品
DANBo（Dentsu Aegis网络委员会）的基础上构建MVP，该产品是一个网络应用程序，其中包含有关客户广告活动的一般信息。
对于MVP，该项目在实施方面得到了最大程度的简化。 我们选择了一些要集成的站点。 这些是主要平台，例如Yandex.Direct，Yandex.Display，RB.Mail，MyTarget，Adwords，DBM，VK，FB，以及主要广告系统Adriver和Weborama。
要通过API访问网站上的统计信息，我们使用了一个帐户。 想要使用广告活动的自动统计信息的客户组经理必须首先将对站点上必要的广告活动的访问权委派给平台帐户。
此外，
DANBo系统的用户必须将某种格式的文件上传到Excel系统，其中写入了有关展示位置的所有信息（广告活动，网站，格式，布置时间，计划指标，预算等）以及网站上相应广告活动的标识符和广告系统中的计数器。
坦率地说，它看起来很恐怖：
下载的数据存储在数据库中，然后各个服务从站点收集它们中的活动标识符并下载其统计信息。
为每个网站编写了单独的Windows服务，该服务每天一次进入该网站的API中的一个服务帐户，并下载有关指定广告系列标识符的统计信息。 广告系统也发生了同样的事情。
下载的数据以小型自写仪表板的形式显示在界面上：
出乎我们意料的是，MVP赢得并开始在Internet上下载有关广告活动的最新统计信息。 我们在多个客户上实施了该系统，但是当我们尝试扩展规模时，我们遇到了严重的问题：
- 主要问题是准备要加载到系统中的数据的费力。 另外，必须在下载前将展示位置数据缩小为严格固定的格式。 在要加载的文件中，必须注册来自不同站点的实体的标识符。 我们面临这样一个事实，即未经技术培训的用户很难解释在站点上哪里找到这些标识符以及将它们放在文件中的位置。 考虑到各部门在现场开展活动的员工人数和营业额，这导致了我们方面的大量支持，这绝对不适合我们。
- 另一个问题是，并非所有广告平台都具有将广告活动的访问权委派给其他帐户的机制。 但是，即使可以使用委派机制，也不是所有广告客户都愿意为他们的广告系列提供第三方帐户访问权限。
- 一个重要的因素是引起用户的愤慨，因为他们已经对我们的1C会计系统做出了贡献的所有计划指标和布置细节都应重新输入到DANBo中 。
这使我们想到，有关位置的信息的主要来源应是我们的1C系统，在该系统中，所有数据均按时准确输入（关键是基于1C数据形成了帐户，因此，正确地在1C中输入数据适用于所有KPI）。 因此出现了一个新的系统概念...
概念图
我们决定要做的第一件事是将收集互联网广告活动统计信息的系统分成一个单独的产品
D1.Digital 。
在新概念中，我们决定将广告活动和其中的展示位置的信息从1C
加载到
D1.Digital中 ，然后从网站和AdServing系统中将统计信息提取到这些展示位置。 这样做可以大大简化用户的生活（并照常向开发人员添加工作）并减少支持量。
我们遇到的第一个问题是组织性质的，与以下事实有关：我们找不到可以比较来自不同系统的实体和来自1C的广告系列和展示位置的键或属性。 事实是，我们公司的流程安排是这样的：广告活动由不同的人（媒体播放器，购买者等）输入到不同的系统中。
为了解决此问题，我们必须发明一个唯一的哈希键DANBoID，它将不同系统中的实体连接在一起，并且可以很容易且明确地在加载的数据集中进行标识。 此标识符是在内部1C系统中为每个单独的展示位置生成的，并将其投入到所有平台和所有AdServing系统中的广告系列，展示位置和计数器中。 将DANBoID附加到所有展示位置的做法需要一些时间，但我们做到了：)
然后，我们发现并非所有站点都具有用于自动统计信息收集的API，即使那些具有API的站点也不会返回所有必要的数据。
在此阶段，我们决定大幅减少要整合的网站列表，并专注于绝大多数广告系列中涉及的主要网站。 该列表包括广告市场中所有最大的参与者（Google，Yandex，Mail.ru），社交网络（VK，Facebook，Twitter），主要的AdServing和分析系统（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个广告系列的信息，在超过80,000个展示位置中，我们从用户那里收集了有关该产品的大量反馈，并根据此反馈设法多次更改了该产品的主要流程。
解决方案架构2.0
自
D1.Digital开发以来已有两年时间。 系统负载的不断增加和新数据源的出现逐渐揭示了现有解决方案体系结构中的问题。
第一个问题与从站点下载的数据量有关。 我们面临这样一个事实，即从最大的站点收集和更新所有必要的数据开始需要花费太多时间。 例如，在AdRiver广告服务系统上收集数据大约需要12个小时，我们可以使用该系统跟踪大多数展示位置的统计信息。
为了解决此问题，我们开始使用各种报告从站点下载数据，我们正尝试与站点一起开发其API，以便其速度能够满足我们的需求并尽可能并行化数据加载。
另一个问题是下载数据的处理。 现在，随着有关展示位置的新统计信息的到来，启动了一个重新计算指标的多阶段过程，其中包括加载原始数据，为每个站点计算汇总指标，将来自不同来源的数据相互比较以及为广告系列计算摘要指标。 这会给Web应用程序带来很大的负担，该Web应用程序将执行所有计算。 在重新计数的过程中，应用程序几次吞噬了服务器上的所有内存（约10-15 GB），这对用户使用系统产生最大的影响。
发现的问题和进一步开发产品的宏伟计划使我们不得不修改应用程序体系结构。
我们从连接器开始。
我们注意到所有连接器都根据同一模型工作，因此我们构建了管道输送器，在其中创建连接器时，您仅需编写步骤逻辑即可，其余的都是通用的。 如果需要改进任何连接器，那么我们将在完成连接器的同时立即将其转移到新框架中。
同时，我们开始在docker和Kubernetes中放置连接器。
我们计划迁移到Kubernetes很长时间，尝试使用CI / CD设置，但是只有在一个连接器由于错误而开始占用服务器上超过20 GB的内存时才开始移动，几乎杀死了其余过程。 在调查过程中，即使错误已修复，连接器也已重新定位到Kubernetes集群，并最终保留在该集群中。
我们很快就意识到Kubernetes很方便，在六个月内，我们将7个连接器和连接器代理移到了消耗最多资源的生产集群中。
在连接器之后，我们决定更改应用程序其余部分的体系结构。
主要问题是数据从连接器到大捆的代理，然后在DANBoID上运行，并传输到中央Web应用程序进行处理。 由于大量的指标重新计数，因此在应用程序上会产生很大的负载。
, , web , , , - .
2.0.
, Web API RabbitMQ MassTransit . Connectors Proxy, Connectors Hub. , , .
web , . .
Kubernetes, .
Proof-of-concept 2.0
D1.Digital . — 20 , , , , .
, API, .
, , adserving .
, web , Kubernetes. , , .
, MongoDB. SQL-, , , , .
, , :)
R&D Dentsu Aegis Network Russia: ( shmiigaa ), ( hitexx )