事件分析策略

概述

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

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

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

• 实用建议。如何避免麻烦，并从许多在您之前尝试过此方法的人的错误中受益。

事件分析策略

团队选择哪个选项很大程度上取决于他们的需求，但大多数人倾向于随着产品和业务的扩展逐步尝试这些选项。

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

  • 优点

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

    • 最快的实现方案

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

  • 缺点

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

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

    • 在高容量情况下通常会变得相当昂贵

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

  • 解决方案示例

    • 谷歌分析

    • Mixpanel

    • Keen IO

• 由托管服务组成的自定义管道。这是中间路线。您将通过付出更多努力来重新获得一些关键的控制元素。

  • 优点

    • 您在整个管道中拥有数据，这使您有机会决定如何使用它

    • 您将能够将各种数据源连接在一起，从而实现其他方式无法进行的分析

    • 数据隐私和安全更牢固地掌握在您手中

  • 缺点

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

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

  • 解决方案示例

    • AWS 移动事件 + S3 + Redshift + BI

    • AWS Kinesis + S3 + DWH + BI

    • Kafka + S3 + DWH + BI

    • Kafka + Storm + BI（实时）

    • Segment.io + S3 或 Redshift + BI

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

  • 优点

    • 对管道中每个步骤的完全控制确保您能够解决所需的任何问题

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

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

  • 缺点

    • 这是最昂贵的选项，肯定需要专门的人力来执行

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

  • 解决方案示例

    • 您只能靠自己了——这正是您想要的，对吧？

分析管道的结构

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

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

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

• 处理 - 数据收集后，通常会经过一次或多次转换以准备供消费。此步骤通常高度定制，并且很大程度上取决于数据生成和收集的方式，以及可用于数据仓库的内容。这是您的 ETL，它有效地连接着您的管道。

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

• 分析 - 一套从仓库中提取数据并将其格式化以供主动（通常是人类）消费的工具和流程。这是您的 BI 工具和自定义仪表板倾向于关注的领域。如果您有机器学习学科，那么您也将在此时使用建模软件。

实用建议

一般想法

• 在转向更复杂的方法之前，尽可能地利用每个解决方案。

• 不要低估运行自己的管道所涉及的工作。数据管道不是一个您设置好就能自动运行的系统；它需要定期维护和投入精力。

• 管道各部分的总体难度/时间成本倾向于：

  • 生成 = 简单

  • 捕获 = 中等 -> 简单（随着您的熟练度提高）

  • 处理 = 困难 -> 中等（随着您的熟练度提高）

  • 仓储 = 困难 -> 中等（随着您的熟练度提高）

  • 分析 = 中等

选择端到端 SaaS 服务时

• 通常，您需要编写一些代码来实现第三方 SDK 并将数据生成代码集成到您的应用程序中。根据您想要跟踪的内容，这可能非常简单，例如在网站上使用 GA，也可能涉及更多。

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

• 您将通过提供商创建的专有工具集访问数据，这可能是一把双刃剑。在大多数情况下，您会遇到关于您能做什么的限制，并且您只能接受它们，因为您无法更改任何内容。

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

• 请记住，要执行此操作，您需要运行一些基础设施，即使它是像 AWS 上的托管服务，所以请确保您具备一些基本的运维能力。

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

• 首先关注创建稳定可靠的数据收集模式，因为“一切”都源于此。一旦您建立了可靠的数据收集系统，您就可以在此基础上构建许多东西。这里的首选是 AWS Kinesis 和 Kafka。

• 您的数据仓库选择主要取决于数据量。对于小数据量，请使用最简单的工具，例如开源 SQL 数据库。当您超出该范围时，您将考虑分析型数据仓库，其中有许多选择：AWS Redshift、Vertica、ParAccel 和 Terradata 是其中的知名品牌。还有 Spark、Presto、Impala 和 Druid 等新工具。

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

灵感来源

• 完全托管的分析管道