事件分析策略

概述

您想做事件分析——很棒！本指南提供了一些您应该了解的基础知识。下面有几个部分供您阅读：

• 实施事件分析的通用策略。描述了三种可供考虑的高层选项。

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

• 实践建议。如何避免麻烦，并从许多在此之前尝试过这些事物的人的错误中受益。

事件分析策略

团队选择哪种方案将很大程度上取决于他们的需求，但大多数人倾向于随着产品和业务的扩展，逐步采用这些方案。

• 使用端到端 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

• 完全自定义管道。这是一种随心所欲、完全构建的管道，通常包含高度定制的组件。

  • 优点

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

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

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

  • 缺点

    • 这是成本最高的一种选择，肯定需要专职人员来执行

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

  • 示例解决方案

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

分析管道的结构

数据管道有多种形状和大小，但在大多数情况下，以下步骤代表了讨论管道组件的坚实框架。

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

• 收集 - 一旦数据生成，通常需要将其发送到某个地方并存储以供下游使用。在大多数情况下，这是一个基于 HTTP 的 API。需要牢记的是，数据通常只收集一次，但打算多次使用，因此设计成发布/订阅模型在这里是合理的，以允许同一数据的多个订阅者。

• 处理 - 数据收集后，通常会经过一个或多个转换，以准备好进行使用。这一步通常是高度定制的，并且很大程度上取决于数据生成和收集的方式，以及数据仓库的可用性。这是您的 ETL，它有效地成为您管道的粘合剂。

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

• 分析 - 用于从数据仓库中提取数据并将其格式化以便主动使用的工具和流程集，通常由人类使用。这就是您的 BI 工具和自定义仪表板倾向于关注的地方。如果您有机器学习学科，那么这里也会有建模软件。

实践建议

总体思路

• 在迁移到更复杂的方法之前，尽可能地利用每种解决方案。

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

• 您管道各部分的一般难度/时间成本倾向于

  • 生成 = 容易

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

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

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

  • 分析 = 中等

选择端到端 SAAS 服务时

• 通常，您需要编写一些代码来实现第三方 SDK，并将数据生成代码集成到您的应用程序中。根据您想跟踪的内容，这可能非常简单，就像网站上的 GA，或者可能稍微复杂一些。

• 客户/用户将向第三方发送数据，因此至少有一些法律和隐私方面的考虑。在大多数情况下，这都不是大问题，但值得考虑。

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

当您计划开始自己的管道时

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

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

• 首先专注于创建稳定可靠的数据收集模式，因为“字面意义上”一切都将以此为基础。一旦您有了坚实的数据收集基础，您就可以在其之上构建许多东西。这里的首选是 AWS Kinesis 和 Kafka。

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

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

灵感来源

• 完全托管的分析管道