‧
8 分钟阅读
事件分析策略
Allen Gilliland
‧ 8 分钟阅读
分享此文章
概述
因此，您想要进行事件分析——太棒了！本文提供了一些您应该了解的基本知识。以下是您需要阅读的几个部分：
-
实施事件分析的通用策略。描述了三个需要考虑的高级选项。
-
事件分析管道的结构及其工作原理。这将帮助您在整个过程中做出更好的决策。
-
实用建议。如何避免麻烦并从许多先行者的错误中受益。
事件分析策略
团队选择哪个选项很大程度上取决于他们的需求，但大多数人倾向于随着产品和业务的扩展逐步尝试这些选项。
-
使用端到端 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 文件一样简单，也可以像拥有 2,000 多个节点的 Hadoop 集群一样复杂。选择仓库的主要因素是数据量和分析需求。
-
分析——从数据仓库中提取数据并将其格式化以供主动消费（通常由人类消费）的工具和流程集合。这是您的 BI 工具和定制仪表板倾向于关注的领域。如果您有机器学习学科，那么这里也会有建模软件。
实用建议
一般思考
-
在转向更复杂的方法之前，尽可能地利用每种解决方案。
-
不要低估运行自己的数据管道所需的工作量。数据管道不是一个设置好就能自动运行的系统；它需要定期维护和关注。
-
您的数据管道各部分的总体难度/时间成本往往是：
-
生成 = 容易
-
捕获 = 中等 -> 容易（随着熟练度提高）
-
处理 = 困难 -> 中等（随着熟练度提高）
-
仓储 = 困难 -> 中等（随着熟练度提高）
-
分析 = 中等
-
选择端到端 SaaS 服务时
-
通常，您需要编写少量代码来实现第三方 SDK，并将数据生成代码集成到您的应用程序中。根据您想要跟踪的内容，这可能非常简单，例如在网站上使用 GA，也可能更复杂。
-
客户/用户会将数据发送给第三方，因此至少需要考虑一些法律和隐私问题。在大多数情况下，这不是大问题，但值得思考。
-
您将通过您的提供商创建的专有工具集访问数据，这可能喜忧参半。在大多数情况下，您会遇到功能限制，并且由于无法更改任何内容，您只能接受这些限制。
当您计划启动自己的管道时
-
请记住，要执行此操作，您必须运行一些基础设施，即使是 AWS 等托管服务，因此请确保您具备一些基本的技术运营能力。
-
您可能会认为需要数据工程师来执行此分析策略，但如果保持简单，则不需要。没有理由急于招聘数据工程师。
-
首先关注创建稳定且可靠的数据收集模式，因为“字面上”所有后续操作都依赖于此。一旦您建立了稳固的数据收集基础，就可以在此基础上构建许多东西。这里最好的选择是 AWS Kinesis 和 Kafka。
-
您的数据仓库选择主要取决于数据量。对于小数据量，请坚持使用最简单的工具，如开源 SQL 数据库。当您超越此范围时，您将需要分析型数据仓库 (DWH)，其中有许多选择：AWS Redshift、Vertica、ParAccel 和 Terradata 是其中的知名产品。还有一些较新的工具，如 Spark、Presto、Impala 和 Druid。
-
每个人都希望他们的数据管道是实时的（意味着数据可以立即用于分析），但这肯定需要更多的工作量，所以请及早决定这是否值得您投入。通常，这需要专门的工具和不同的管道配置，因此请将其考虑在内。
