事件分析策略

概述

所以你想做事件分析 —— 太棒了！本文档提供了一些你应该知道的基本知识。以下是一些需要阅读的章节：

• 实现事件分析的一般策略。描述了三个需要考虑的高级选项。

• 事件分析管道的结构以及它是如何工作的。这将帮助你在整个过程中做出更好的决策。

• 实用建议。如何避免麻烦并从那些在你之前尝试过这些事情的人的错误中受益。

事件分析策略

团队选择的方案将很大程度上取决于他们的需求，但大多数人通常会随着产品和业务的扩展逐步尝试这些方案。

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

  • 优点

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

    • 最快的选项来快速部署

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

  • 缺点

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

    • 数据是隔离的，无法与其他应用程序数据结合

    • 在高容量下通常相当昂贵

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

  • 示例解决方案

    • Google Analytics

    • 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。重要的是要记住，数据通常只收集一次，但打算多次使用，因此在这里设计为pub/sub模型是有意义的，以允许对相同数据的多订阅者。

• 处理 - 数据收集后，通常需要通过一个或多个转换来准备其消费。这一步骤通常非常定制，并且很大程度上取决于数据生成和收集的方式，以及数据仓库可用性。这是你的ETL，并且它是管道中的粘合剂。

• 仓库 - 指的是数据如何存储和用于分析。这可能只是一个CSV文件，也可能是一个拥有2000多个节点的Hadoop集群。选择仓库的主要因素是数据量和分析需求。

• 分析 - 这是一套工具和流程，从仓库中提取数据并将其格式化以供活动消费，通常由人类使用。这是你的BI工具和定制仪表板通常会关注的地方。如果你有机器学习学科，那么你在这里也会有建模软件。

实用建议

一般想法

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

• 不要低估运行自己的数据管道所涉及的工作。数据管道不是一个你设置好后就无需关注就能自动运行的系统；它需要定期进行维护和滋养。

• 您管道各部分的一般难度/时间成本通常为：

  • 生成 = 简单

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

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

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

  • 分析 = 中等

当选择端到端SAAS服务时

• 通常，你需要编写一些代码来实现第三方SDK，并将数据生成代码集成到您的应用程序中。根据您想要跟踪的内容，这可以是很容易的，比如网站上的GA，或者可能涉及更多。

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

• 您将通过提供商创建的专有工具集访问您的数据，这可能是一把双刃剑。在大多数情况下，您会遇到一些障碍，比如您能做什么，您只能忍受它们，因为您无法改变任何东西。

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

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

• 虽然您可能会觉得需要数据工程师来执行此分析策略，但如果您保持事情简单，则不需要。没有理由急于雇佣数据工程师。

• 首先关注创建一个稳定且健壮的数据收集模式，因为“实际上”所有内容都从这里开始。一旦为数据收集建立了坚实的基础，您就可以在此基础上构建很多东西。这里的最佳选择是AWS Kinesis和Kafka。

• 您选择数据仓库将主要取决于数据量。对于小型数据量，请坚持使用最简单的工具，如开源SQL数据库。当您超出这个范围时，您将需要查看许多分析DWH，其中有很多选择：AWS Redshift、Vertica、ParAccel和Teradata是一些知名品牌。还有像Spark、Presto、Impala和Druid这样的新工具。

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

灵感来源

• 完全托管的分析管道