优化的解决方案:离线电商数仓-用户行为采集平台-第4章 用户行为数据采集模块

　　优化的解决方案:离线电商数仓-用户行为采集平台-第4章 用户行为数据采集模块

　　前言

　　此博客是一个学习记录，可能收录错误，仅供参考。

　　如果您发现错误，请在评论区进行更正，我会及时更正。

　　同时，我也希望大家能在评论区与我多讨论，或者给我发私信，讨论能让我们更高效地学习。

　　当前版本不是最终版本，我将随着学习继续更新。

　　第 4 章：用户行为数据采集模块 4.2 环境准备 4.2.2 Hadoop 安装

　　1） 配置集群

　　1. 核心站点配置

　　配置此 atguigu（超级用户）以允许代理访问所有主机节点、用户所属的所有组以及所有用户

　　2.纱线现场.xml配置

　　这三个参数不是直接分布的，而是根据每台机器的内存大小单独设置的。

　　2） 项目经验

　　HDFS 存储 多目录集群数据平衡 节点和磁盘之间的数据平衡 Hadoop 参数调整 HDFS 参数调整 YARN 参数调整 4.2.3 动物园管理员安装 1）动物园管理员重命名后可能出现的问题，与文档不一致，但文档中的路径也使用了，所以要注意动物园管理员的安装，重命名应与文档中相同。2）动物园管理员的选举机制

　　（3条消息）动物园管理员流亡Mechanism_Blog - CSDN博客_zookeeper选举机制

　　4.2.4 卡夫卡安装

　　首先启动动物园管理员，然后启动卡夫卡。

　　先关上卡夫卡，然后关上动物园管理员。

　　配置环境变量时，

　　需要注意的是，一般是在hadoop102上配置，然后分发，配置环境变量后，需要源/etc/profile

　　主题

　　制作人

　　消费者

　　这三者仍然需要学习#待学

　　4.2.5 水槽安装

　　当您启动 flume 时，它会根据其配置文件启动。

　　4.3 对数采集水槽

　　卡夫卡*敏*感*词*相当于生产者的实现，将数据写入卡夫卡的主题

　　卡夫卡源相当于消费者实现，从卡夫卡的主题中读取数据

　　卡夫卡频道使用三种方案

　　引用：

　　解决方案一：与水槽和水槽一起使用

　　描述: __________：

　　

　　Taildir读取文件中的数据并将其输入到卡夫卡通道中以将数据写入主题hdfs*敏*感*词*从卡夫卡通道读取数据时，卡夫卡通道将首先读取主题中的数据，然后传递到最终的hdfs*敏*感*词*将数据写入hdfs

　　选项二：与水烟酸一起使用

　　注意：只有从文件中读取的数据才会写入 kafka

　　解决方案三：与水槽一起使用

　　注意：仅从卡夫卡读取数据，写入HDFS

　　因为卡夫卡通道中有一个参数如下

　　如果参数解析为“流量”设置为 True，则数据将传输到

　　事件的形式（header+body），然后从 kafka 通道到 kafka 的主题，并将有用的数据存储在正文中，因此会存储更多的数据标头。对于离线数据仓库，可以在下游解析正文，但对于直接从Kafka主题读取数据的实时数据数据仓库来说，标头是无用的。

　　如果参数解析为“流量”设置为“假”，则数据仅传输到卡夫卡通道，没有标头，但与*敏*感*词*一起使用时需要卡夫卡通道

　　对于本项目，使用了备选方案二和三的组合

　　上游首先使用卡夫卡通道（将解析为“事件”设置为“假”）将数据写入卡夫卡

　　再往下游穿过*敏*感*词*（#待学）。

　　使用卡夫卡通道可以减少一个步骤并提高效率。

　　4.3.2 记录采集水槽配置实践

　　2） 配置文件的内容如下

　　1. 配置源

　　2. 配置通道

　　3. 最终配置文件

　　#1.定义组件

a1.sources=r1

a1.channels=c1

#2.配置sources

a1.sources.r1.type=TAILDIR

a1.sources.r1.filegroups=f1

#设置监控的文件

a1.sources.r1.filegroups.f1=/opt/module/applog/log/app.*

#设置断点续传

a1.sources.r1.positionFile=/opt/module/flume/taildir_position.json

#3.配置channels

a1.channels.c1.type = org.apache.flume.channel.kafka.KafkaChannel

<p>

a1.channels.c1.kafka.bootstrap.servers=hadoop102:9092,hadoop103:9092

a1.channels.c1.kafka.topic = topic_log

a1.channels.c1.parseAsFlumeEvent = false

#4.组装

a1.sources.r1.channels=c1

</p>

　　3）编写水槽*敏*感*词*

　　*敏*感*词*使用-flume官方网站说明

　　Flume具有在飞行中修改/丢弃事件的能力。这是在*敏*感*词*的帮助下完成的。*敏*感*词*是实现 org 的类。阿帕奇。水槽。拦截 器。*敏*感*词*接口。*敏*感*词*可以根据*敏*感*词*开发人员选择的任何条件修改甚至删除事件。水槽支持*敏*感*词*的链接。这是通过在配置中指定*敏*感*词**敏*感*词*类名列表来实现的。*敏*感*词*在源配置中被指定为空格分隔列表。

　　指定*敏*感*词*的顺序是调用它们的顺序。一个*敏*感*词*返回的事件列表被传递到链中的下一个*敏*感*词*。*敏*感*词*可以修改或删除事件。如果*敏*感*词*需要丢弃事件，它只是不会在它返回的列表中返回该事件。如果要删除所有事件，则它只是返回一个空列表。*敏*感*词*被命名为组件，下面是如何通过配置创建它们的示例：

　　a1.sources = r1

a1.sinks = k1

a1.channels = c1

a1.sources.r1.interceptors = i1 i2

a1.sources.r1.interceptors.i1.type = org.apache.flume.interceptor.HostInterceptor$Builder

a1.sources.r1.interceptors.i1.preserveExisting = false

a1.sources.r1.interceptors.i1.hostHeader = hostname

a1.sources.r1.interceptors.i2.type = org.apache.flume.interceptor.TimestampInterceptor$Builder

a1.sinks.k1.filePrefix = FlumeData.%{CollectorHost}.%Y-%m-%d

a1.sinks.k1.channel = c1

　　4）我的理解：

　　1. 就是用Java写一个*敏*感*词*的jar包，然后这个*敏*感*词*类需要继承这个类组织.apache.flume.*敏*感*词*，并重写里面的接口。

　　2.然后用maven制作一个罐子包（带有依赖项）

　　3. 将罐子包装放入 /选择/模块/水槽/库

　　4. 然后将此*敏*感*词*配置到 flume 中，并将配置文件放入 /opt/模块/flume/job 中，并按如下方式进行配置：

　　a1.sources.r1.interceptors=i1

a1.sources.r1.interceptors.i1.type=com.atguigu.gmall.flume.interceptor.ETLInterceptor$Builder

　　其中，com.atguigu.gmall.flume.*敏*感*词*.ETL感知器*敏*感*词*是*敏*感*词*jar的*敏*感*词*全类名，请注意，您必须使用“*敏*感*词*是*敏*感*词*罐的*敏*感*词*全类名”，请注意“*敏*感*词*”

　　是*敏*感*词* jar 的*敏*感*词*全类名，请注意，您必须在此处使用“”符号，而不是“.”符号。

　　5. 使用 /opt/模块/水槽/作业中的配置文件启动水槽

　　6. 然后在 hadoop103 中打开卡夫卡消费者，挂起

　　7. 然后将非法 JSON 添加到 /opt/module/applog/log 中的日志文件中，如果 Kafka 使用者无法获取此非法 JSON 数据，则表示*敏*感*词*已正常工作。

　　其他 __________

　　ArrayList 集合的索引是动态可缩放的，当您使用删除到删除时，很容易出现数据超出边界的异常。

　　成熟的解决方案:前端监控的搭建步骤，别再一头雾水了！

　　大家好，我叫杨成功。

　　上一篇介绍了为什么前端会有监控系统？前端监控系统有什么意义？有朋友看完后留言，想听听一些详细的实现。那么在本文中，我们将开始介绍前端监控是如何实现的。

　　如果还是不明白为什么，监控有什么用，推荐阅读上一篇文章文章：前端为什么不能没有监控系统？

　　在实施之前，首先要在脑海中有一个整体的背景，了解构建前端监控的具体流程步骤。因为前端监控系统其实是一个完整的全栈项目，不仅仅是前端，甚至主要的实现都围绕着数据。

　　当然，还有一点需要说明。本文的实现主要针对普通业务和中小厂自研方向。我看过大厂做的监控系统。它非常复杂和强大，动辄数以亿计的数据。最终走向了大数据的方向。我只介绍如何实现main函数，如何解决问题。

　　前端监控的构建过程分为以下几个阶段：

　　采集Stage：Data 采集API Stage：构建API应用，接收采集Data Storage Stage：将API应用连接到数据库，存储采集 查询统计阶段：对采集接收到的数据进行查询、统计、分析 可视化阶段：前端通过API查询统计数据，可视化展示告警阶段：API对接告警通知服务，如钉钉部署阶段：整体应用部署上线

　　下面我来梳理一下各个阶段的关键实现思路。

　　采集阶段：采集什么数据？

　　监控的第一步是采集数据。有数据是监控的前提。

　　采集数据的含义是记录用户在使用产品过程中的真实操作。结合我们上一篇的分析，实际操作产生的数据可以分为两类：异常数据和行为数据。

　　我们先分析异常数据。项目中的异常一般可以分为两类，一类是前端异常，一类是接口异常。

　　前端异常

　　前端异常大致可以分为：

　　最重要的，也是我们遇到最多的，就是各种js代码执行异常。比如类型错误、引用错误等。这些异常大部分是由于我们的编码不精确造成的，所以采集这些异常有助于我们提高编码质量。

　　然后是 Promise 异常。Promise 是 ES6 最重要的属性之一。考验我们的js异步编程能力，主要体现在接口请求上。因此，这两部分的异常捕获非常关键。

　　另外，静态资源加载异常一般是指引用了一些html中的图片地址、第三方js地址等，由于各种原因不能正常加载，这个也要监控。

　　console.error 异常一般用在第三方前端框架中。它自定义了一些错误，会被console.error抛出。此类异常也需要被捕获。

　　至于跨域异常，我们经常会遇到这种情况，通常可以在前后端开发联调阶段发现。但不确定是后端的配置突然在线更改，导致前端跨域。为了安全起见，您还应该对其进行监控。

　　前端异常采集大概只有这5种，基本覆盖了前端90%以上的异常。

　　接口异常

　　接口异常属于后端异常，但是接口异常会直接导致前端页面错误。因此，此类异常是我们判断线上问题根源的重要依据。接口异常可以根据响应结果分类：

　　有时由于网络问题或服务器问题，前端发起请求后没有收到响应，请求被挂起。这次是无响应/超时响应异常。对于此类异常，我们可以设置最大请求时间，超时后主动断开请求，添加接口超时记录。

　　另外，其他类型的接口异常可以根据HTTP状态码或者后端返回的error_code等指定字段来判断。

　　不管是使用状态码还是其他判断方式，只要能区分异常类型，这个不是严格要求的。

　　4xx异常类型是请求异常，一般是前端传递的参数有问题，或者接口验证参数有问题。处理此类异常的关键是保存请求参数，这样可以方便前端排查。

　　

　　5xx 错误是服务器内部处理的异常。此类异常的关键信息是报错时间和返回的异常描述。保存这些可以方便后端查找日志。

　　我认为权限不足也是一种重要的错误类型。因为有些管理系统的权限设计比较复杂，有时候界面突然莫名其妙无法调整，影响用户接下来的操作，也需要记录和跟踪。

　　行为数据

　　行为数据比较广泛，用户任何有意义的操作都可以定义为行为数据。

　　例如，当一个按钮被点击时，它在那里停留了多长时间，新功能的点击率，何时使用等等。自主研发的监控系统的优势之一是灵活性。您需要的任何有用信息都可以在此阶段进行设计。

　　这个阶段非常关键，是监控系统设计的核心，所以我写的很详细，这个阶段大家要多考虑采集哪些数据。后面的阶段都是基于这个设计的具体实现。

　　API阶段：构建上报数据的API接口

　　在上一阶段，采集数据计划已经准备好了。当 采集 数据到达时，接下来会上报数据。

　　说白了，数据上报就是通过调用API接口将数据传输出来，然后存入数据库。因此，这个阶段的任务是构建一个用于报告数据的API接口应用程序。

　　作为一名光荣的前端工程师，在开发接口时自然会选择属于 JS 家族的 Node.js。Node.js 目前有很多框架。我比较喜欢轻量简洁，什么都需要自己安装，所以选择了简洁经典的Express框架。

　　构建 API 应用程序要做的事情是：

　　还有一些细节需要处理。这个阶段对于后端基础薄弱的同学来说是一个很好的学习机会。

　　强烈建议前端的朋友掌握一些后端的基础知识，至少从简单的原理上了解是怎么回事。这个阶段主要是了解API应用是如何搭建的，每个部分为什么要做，可以解决哪些问题，这样你对后端的基础知识就会建立起来。

　　框架搭建好后，主要是设计接口URL，然后编写处理逻辑，保证这一步设计的接口可以调整，可以接收数据。

　　数据存储阶段：与数据库接口对接

　　上一步我们构建了API接口，接收到采集的数据。然后，在这一步中，我们需要连接数据库，并将 采集 中的数据存储到数据库中。

　　数据库方面，选择对前端最友好的，属于NoSQL家族的文档数据库MongoDB。

　　这个数据库最大的特点就是存储的数据格式类似于JSON，操作就像在JS中调用函数，结合JOSN数据。我们很容易理解并开始使用前端。可以在实战过程中体验。优雅也。

　　数据存储阶段主要介绍数据库的基本信息和操作，包括以下几个方面：

　　这个阶段的关键是数据验证。在设计完数据库字段后，我们希望所有写入的数据都必须符合我们想要的数据格式。如果验证后不符合，我们可以补充或修改数据字段，或者干脆拒绝写入，这样可以保证数据的可靠性，避免不必要的数据清洗。

　　数据写入完成后，需要添加一些简单的查询和修改功能。因为要在写完数据后查看执行是否成功，可以查看一个列表来查看结果。

　　还需要修改功能。前端监控中一个很常见的需求就是计算用户的页面停留时间。我的计划是在用户进入某个页面时创建一条记录，然后在用户离开时修改该记录并添加一个结束时间字段，这需要修改功能。

　　最后但并非最不重要的一点是，许多人都在谈论如何清理数据。实际上，这取决于您在将数据存储在您面前时如何验证。如果确实可以存储无效数据，可以写一个清空数据的接口，自己写清空逻辑，定时执行。

　　查询统计阶段：数据查询和统计分析

　　经过一系列的准备，我们已经完成了API接口和数据写入的功能。假设我们有 采集 足够的数据并存储在数据库中，这个阶段就是充分利用这些数据的时候了。

　　这个阶段的主要任务是对数据进行检索和统计分析，基本上是“查询”操作。

　　这里的查询不仅仅是为了检查，如何检查，关系到我们采集到的数据能否得到有效利用。我的想法是从这两个方面入手：

　　

　　当然，这只是笼统的说法。行为数据也将在一行中查询。例如，如果我想查看用户在某个时间做了什么，这就是精确搜索。还有异常数据的统计，比如异常接口的触发频率排名。

　　行为数据量会非常大，在用户使用系统的过程中会频繁生成并写入数据库。因此，在这类数据的大部分情况下，都是通过聚合查询的方式，从页数、时间等多个维度进行整体统计，最后得出一些百分比的结论。这些统计值可以大致反映产品的实际使用情况。

　　这里有个优化点，因为频繁的请求会增加接口的负担，所以一部分数据也可以在本地存储，达到一定数量后，一次性请求并存储接口。

　　异常数据对于开发者来说非常重要，对于我们定位和解决bug来说是天赐之物。与行为数据的多重统计不同，我们更关心异常数据的每一条记录的详细信息，让错误一目了然。

　　查询异常数据也比较简单。和普通的列表查询一样，只需要返回最新的异常数据即可。当然，我们排查问题后，也要把处理的异常标记为已处理，这样可以防止重复排查。

　　可以看出，这个阶段最重要的是做一个统计界面，为下一阶段图表展示的可视化做准备。

　　可视化阶段：最终数据图表展示

　　在最后阶段，我们开发了一个统计界面并找到了想要的数据结果。不幸的是，这些结果只有程序员才能理解，其他人可能无法理解。所以最后，为了更直观的反映数据，我们需要使用前端的可视化图表，让这些数据活起来。

　　在这个阶段，我们终于回到了最熟悉的前端领域。这个阶段的任务比较简单，比较顺利。基于React构建一个新的前端应用，访问上一步的统计界面，然后集成前端图表库，以图表的形式展示统计结果。

　　这个新应用是一个前端监控系统，真正需要展示给外界。供团队内部的开发人员或产品学生使用，方便他们实时查看产品产生的数据信息，解决自己的问题。

　　事实上，现阶段没有关键问题可谈。主要是选择一个好用的图表库并连接接口。还有各种类型的图表。需要考虑哪些数据适合哪些图表，根据实际情况做出判断。

　　最后，监控系统的前端页面和界面数据不是人人都能看到的，所以要有基本的登录页面和功能。做到这一点，这个阶段的任务就结束了。

　　报警阶段：发现异常立即报警通知

　　前一阶段，监控系统前端搭建完成，统计数据以图表形式展示后，整个监控系统基本可用。

　　但是还有另一种情况，就是用户在使用我们的产品时突然报错，错误信息也被写入了数据库。如果此时你不主动刷新页面，实际上你也不能一直刷新页面，那么我们根本不知道这个错误。

　　如果这是一个非常致命的bug，影响范围很广，我们甚至不知道这个bug是什么时候发生的，那会给我们带来很大的损失。

　　所以，为了保证我们能及时解决bug，告警通知的功能就显得非常重要了。它的作用是在出现异常的第一时间推送给开发者，让大家第一时间发现问题，然后以最快的速度解决，避免遗漏。

　　报警通知，现在一般的解决方案是连接钉钉或者企业微信的机器人，我们这里使用钉钉。使用哪个平台取决于您的主题所在的平台。比如我的团队主体在钉钉上，所以在发送报警通知时，可以直接用手机号@任意一个团队成员，实现更精准的提醒。

　　本部分是对 API 应用的补充。申请钉钉开发者权限后，访问API中的相关代码。

　　部署阶段：万事俱备，只等上线

　　在前面的阶段，我们已经完成了数据采集、API应用构建、数据存储、前端可视化展示、监控告警。整个前端监控系统功能齐全。最后一步是将所有的前端和后端数据库都在线部署，供大家访问。

　　部署主要是nginx解析、https配置、数据库安装、nodejs的应用部署等，这个阶段的内容会多一点运维。不过不用担心，这里我也会详细介绍关键操作。

　　系统上线后，你可以按照第一篇中的采集方法，尝试通过API将数据采集保存在你的任意一个前端项目中，然后登录监控系统来查看真实的使用数据。

　　当这部分完成后，恭喜，一个小型的前端监控系统搭建完成。未来我们可以在此基础上继续扩展功能，慢慢让这个自研的监控系统变得更强大。

　　总结

　　本文介绍了前端监控系统的搭建流程，将整个流程分为几个阶段，简要说明每个阶段要做什么，有哪些关键问题，以帮助大家理清思路​​​​​建立监控系统。