🥇服务器分析系统

这是有关分析系统的系列文章的第二部分（链接到第 1 部分).

如今，毫无疑问，仔细的数据处理和结果解释几乎可以帮助任何类型的业务。在这方面，分析系统加载的参数越来越多，应用程序中触发器和用户事件的数量也在不断增长。
正因为如此，公司正在向分析师提供越来越多的原始信息来分析并转化为明智的决策。分析系统对于公司的重要性不容低估，系统本身必须可靠、稳定。

客户分析师

客户分析是公司通过官方 SDK 连接到其网站或应用程序、集成到自己的代码库并选择事件触发器的服务。这种方法有一个明显的缺点：由于您选择的任何服务的限制，收集到的所有数据可能无法完全按照您想要的方式进行处理。例如，在一个系统上运行 MapReduce 任务并不容易，而在另一系统上您将无法运行模型。另一个缺点是定期的（令人印象深刻的）服务账单。
市场上有许多客户分析解决方案，但分析师迟早会面临这样一个事实：没有一种通用服务适合每项任务（而所有这些服务的价格一直在上涨）。在这种情况下，公司通常决定创建自己的分析系统，并具有所有必要的自定义设置和功能。

服务器分析师

服务器端分析是一种可以在公司内部部署在自己的服务器上并且（通常）通过自己的努力部署的服务。在该模型中，所有用户事件都存储在内部服务器上，允许开发人员尝试不同的存储数据库并选择最方便的架构。即使您仍然想使用第三方客户端分析来完成某些任务，这仍然是可能的。
服务器端分析可以通过两种方式部署。首先：选择一些开源实用程序，将它们部署在您的计算机上并开发业务逻辑。

优点
缺点

你可以定制任何你想要的东西
这通常非常困难并且需要单独的开发人员

第二：采用 SaaS 服务（Amazon、Google、Azure），而不是自己部署。我们将在第三部分更详细地讨论 SaaS。

优点
缺点

中等产量时可能会更便宜，但随着大幅增长，它仍然会变得太贵
无法控制所有参数

管理工作完全转移到服务提供商的肩上
并不总是知道服务内部有什么（可能不需要）

如何收集服务器分析

如果我们想放弃使用客户分析并构建自己的客户分析，首先我们需要仔细考虑新系统的架构。下面我会一步步告诉你需要考虑什么、为什么需要每个步骤以及可以使用哪些工具。

1. 接收数据

就像客户分析一样，首先，公司分析师选择他们将来想要研究的事件类型，并将它们收集到一个列表中。通常，这些事件以特定顺序发生，称为“事件模式”。
接下来，假设一个移动应用程序（网站）拥有常规用户（设备）和许多服务器。为了安全地将事件从设备传输到服务器，需要中间层。根据架构的不同，可能有多个不同的事件队列。
阿帕奇卡夫卡 - 发布/订阅队列，用作收集事件的队列。

根据在 Quora 上发帖 2014 年，Apache Kafka 的创建者决定以 Franz Kafka 的名字命名该软件，因为“这是一个针对写作而优化的系统”，并且因为他喜欢 Kafka 的作品。 — 维基百科

在我们的示例中，有许多数据生产者和数据消费者（设备和服务器），Kafka 帮助将它们相互连接。消费者将在下面的步骤中更详细地描述，其中他们将是主要对象。现在我们将只考虑数据生产者（事件）。
Kafka 封装了队列和分区的概念；最好在其他地方阅读更具体的内容（例如，在文件资料）。无需赘述，让我们假设为两个不同的操作系统启动了一个移动应用程序。然后每个版本都会创建自己单独的事件流。生产者将事件发送到 Kafka，它们被记录在合适的队列中。

（图片故)

同时，Kafka 允许您分块读取并以小批量处理事件流。 Kafka 是一个非常方便的工具，可以根据不断增长的需求（例如，通过事件的地理位置）进行很好的扩展。
通常一个分片就足够了，但扩展时事情会变得更加复杂（就像往常一样）。可能没有人愿意在生产中只使用一个物理分片，因为架构必须具有容错能力。除了Kafka之外，还有另一个著名的解决方案——RabbitMQ。我们没有在生产中将其用作事件分析队列（如果您有此类经验，请在评论中告诉我们！）。但是，我们使用了 AWS Kinesis。

在继续下一步之前，我们需要提到系统的另一个附加层 - 原始日志存储。这不是必需的层，但如果出现问题并且 Kafka 中的事件队列被重置，它将很有用。存储原始日志不需要复杂且昂贵的解决方案；您可以简单地将它们以正确的顺序写入某处（甚至在硬盘驱动器上）。

2. 处理事件流

在我们准备好所有事件并将它们放入适当的队列中之后，我们继续进行处理步骤。在这里我将向您介绍两种最常见的处理选项。
第一个选项是在 Apache 系统中启用 Spark Streaming。所有 Apache 产品都基于 HDFS，这是一个具有文件副本的安全文件系统。 Spark Streaming 是一个易于使用的工具，可以处理流数据并具有良好的扩展性。然而，它可能很难维护。
另一种选择是构建您自己的事件处理程序。为此，您需要编写一个 Python 应用程序，在 Docker 中构建它并订阅 Kafka 队列。当触发器到达 docker 处理程序时，处理就会开始。使用这种方法，您需要保持应用程序始终运行。
假设我们已经选择了上述选项之一并继续进行处理本身。处理器应首先检查数据的有效性、过滤垃圾和“损坏”事件。为了验证我们通常使用地狱犬。之后，您可以进行数据映射：对来自不同来源的数据进行规范化和标准化，以便将其添加到通用表中。

3. 数据库

第三步是保持事件常态化。当使用现成的分析系统时，我们必须经常访问它们，因此选择一个方便的数据库非常重要。
如果数据非常适合固定方案，您可以选择点击屋或其他一些列式数据库。这样聚合就会非常快地进行。缺点是该方案是严格固定的，因此不可能在不修改的情况下添加任意对象（例如，当发生非标准事件时）。但你可以很快地数数。
对于非结构化数据，可以采用NoSQL，例如： Apache Cassandra。它在 HDFS 上运行，复制良好，可以启动许多实例，并且具有容错能力。
您还可以提出一些更简单的问题，例如， MongoDB的。它的速度相当慢并且适用于小体积。但优点是它非常简单，因此适合入门。

4. 聚合

仔细保存所有事件后，我们希望从到达的批次中收集所有重要信息并更新数据库。在全球范围内，我们希望获得相关的仪表板和指标。例如，从事件中收集用户配置文件并以某种方式测量行为。事件被聚合、收集并再次保存（在用户表中）。同时，您可以构建一个系统，以便还可以将过滤器连接到聚合器协调器：仅从某种类型的事件收集用户。
之后，如果团队中有人只需要高级分析，则可以连接外部分析系统。您可以再次使用 Mixpanel。但由于它相当昂贵，因此并非所有用户事件都发送到那里，而是仅发送需要的事件。为此，我们需要创建一个协调器，将一些原始事件或我们自己之前聚合的内容传输到外部系统、API 或广告平台。

5. 前端

您需要将前端连接到创建的系统。服务就是一个很好的例子红达什，是一个帮助构建仪表板的数据库 GUI。交互如何进行：

用户进行 SQL 查询。
作为回应，他收到了一个信号。
它为其创建了一个“新的可视化”，并获得了一个漂亮的图表，您可以自己保存。

服务中的可视化效果会自动更新，您可以自定义和跟踪您的监控。如果是自托管，Redash 是免费的，但作为 SaaS，每月费用为 50 美元。

结论

完成上述所有步骤后，您将创建服务器分析。请注意，这并不只是连接客户分析那么简单，因为一切都需要您自己配置。因此，在创建自己的系统之前，值得将严肃的分析系统的需求与您愿意分配给它的资源进行比较。
如果您计算过并发现成本太高，那么在下一部分中我将讨论如何制作更便宜的服务器端分析版本。

谢谢阅读！我很乐意在评论中提出问题。

来源： habr.com

服务器分析系统