事件分析策略

概览

您想进行事件分析 — 太棒了！本文档提供了一些您应该了解的基本知识。有几个部分需要阅读，如下所示：

• 实施事件分析的通用策略。描述了要考虑的三个高级选项。

• 事件分析管道的结构及其工作原理。这将帮助您在整个过程中做出更好的决策。

• 实用建议。如何避免麻烦，并从许多尝试过这些方法的人的错误中获益。

事件分析策略

团队选择哪个选项将在很大程度上取决于他们的需求，但大多数人在他们的产品和业务规模扩大时，往往会逐步完成这些选项。

• 使用端到端 SAAS 分析提供商。当您无法承担自己管理任何事件分析管道的成本，或者您根本不想这样做时，您将选择此项。

  • 优点

    • 完全无需手动操作，无需基础设施

    • 获得成果的最快选项

    • 解决方案通常针对事件分析工作负载进行了优化

  • 缺点

    • 专有解决方案，无法控制功能

    • 数据是隔离的，无法与应用程序中的任何其他数据连接

    • 在高容量下通常变得非常昂贵

    • 在大多数情况下，您不会拥有数据，如果您决定要对其进行更多操作，也无法完全取回数据

  • 示例解决方案

    • Google Analytics

    • Mixpanel

    • Keen IO

• 使用托管服务构建的自定义管道。这是中间路径。您重新获得了一些关键的控制要素，但需要付出更多努力。

  • 优点

    • 您拥有贯穿整个管道的数据，让您有机会决定以任何您想要的方式使用它

    • 您将能够将各种数据源连接在一起，从而实现原本不可能的分析

    • 数据隐私和安全性更牢固地掌握在您的控制之中

  • 缺点

    • 您正在承担收集和存储数据的责任，因此您需要准备好拥有该解决方案

    • 通常，您需要创建和维护一些代码来处理提取和转换收集的数据以供使用

  • 示例解决方案

    • AWS Mobile Events + S3 + Redshift + BI

    • AWS Kinesis + S3 + DWH + BI

    • Kafka + S3 + DWH + BI

    • Kafka + Storm + BI（实时）

    • Segment.io + S3 或 Redshift + BI

• 完全自定义的管道。这是一个完全自由、完全构建的管道，通常包含高度定制的组件。

  • 优点

    • 完全控制管道的每个步骤，确保您有能力解决您需要的任何问题

    • 您可以根据自己的特定需求进行优化，而不是依赖更通用的解决方案

    • 您的所有数据都可以根据需要移动和整合，因此可以进行任何分析

  • 缺点

    • 这是成本最高的选项，肯定需要专门的人员来执行

    • 构建完整的数据管道需要时间 — 通常需要几个月或几年

  • 示例解决方案

    • 您需要独自完成 — 这正是您想要的，不是吗？

分析管道的结构

数据管道有多种形状和大小，但在大多数情况下，以下步骤代表了讨论管道中各个部分的可靠框架。

• 生成 - 这是数据的创建地点和方式。可能来自移动应用程序、浏览器中的用户、后端服务器等。在大多数情况下，您要么自己编写此代码，要么使用 GA、Segment.io、Mixpanel 等第三方 SDK。

• 收集 - 数据生成后，通常需要将其发送到某处并存储以供下游使用。在大多数情况下，这是一个基于 HTTP 的 API。重要的是要记住，数据通常收集一次，但旨在多次使用，因此在此处设计发布/订阅模型是有意义的，以允许多个订阅者访问相同的数据。

• 处理 - 数据收集后，通常会经过一个或多个转换，以准备用于消费。此步骤通常是高度自定义的，并且在很大程度上取决于数据生成和收集的方式，以及数据仓库可用的内容。这是您的 ETL，它实际上是管道中的粘合剂。

• 仓库 - 指的是如何存储数据并使其可用于分析。它可以像 CSV 文件一样简单，也可以像拥有 2,000 多个节点的 Hadoop 集群一样复杂。选择仓库的主要因素是数据量和分析需求。

• 分析 - 从仓库提取数据并将其格式化以供主动消费（通常由人进行）的一组工具和流程。这是您的 BI 工具和自定义仪表盘倾向于关注的地方。如果您有 ML 学科，那么您也会在此处拥有建模软件。

实用建议

一般想法

• 在升级到更复杂的方法之前，尽可能充分利用每种解决方案。

• 不要低估运行自己的管道所涉及的工作。数据管道不是一个设置好就可以自动运行而无需任何关注的系统；它需要定期维护和管理。

• 管道各部分的总体难度/时间成本往往是：

  • 生成 = 简单

  • 捕获 = 中等 -> 简单（随着您越来越熟练）

  • 处理 = 困难 -> 中等（随着您越来越熟练）

  • 仓库 = 困难 -> 中等（随着您越来越熟练）

  • 分析 = 中等

当使用端到端 SAAS 服务时

• 通常，您需要编写少量代码来实施第三方 SDK，并将数据生成代码集成到您的应用程序中。根据您要跟踪的内容，这可能非常容易（例如网站上的 GA），也可能稍微复杂一些。

• 客户/客户端/用户将向第三方发送数据，因此至少需要考虑一些法律和隐私影响。在大多数情况下，这不是一个大问题，但值得思考一下。

• 您将通过提供商创建的专有工具集访问您的数据，这可能有利有弊。在大多数情况下，您最终会遇到关于您可以做什么的限制，您将不得不忍受这些限制，因为您无法更改任何内容。

当您计划启动自己的管道时

• 请记住，要执行此操作，您必须运行一些基础设施，即使它是 AWS 上的托管服务，因此请确保您具备一些基本的技术运营能力。

• 很容易认为您需要数据工程师来执行此分析策略，但如果您保持简单，则不需要。没有理由急于聘请数据工程师。

• 首先专注于创建稳定且强大的数据收集模式，因为“实际上”一切都由此而来。一旦您为数据收集建立了可靠的基础，您就可以在此基础上构建许多东西。此处的首选是 AWS Kinesis 和 Kafka。

• 您的数据仓库选择主要取决于数据量。对于小数据量，请坚持使用最简单的工具，例如开源 SQL 数据库。当您超出此范围时，您将需要查看分析 DWH，其中有很多选择：AWS Redshift、Vertica、ParAccel 和 Terradata 是其中的佼佼者。还有 Spark、Presto、Impala 和 Druid 等较新的工具。

• 每个人都希望他们的数据管道是实时的（意味着数据可以立即用于分析），但这肯定需要更多的工作来执行，因此请尽早决定这是否对您有价值。要做到这一点，通常需要专门的工具和不同的管道配置，因此请考虑到这一点。

灵感来源

• 完全托管的分析管道