weixin_40612128的博客

一、项目中遇到的问题及优化如何保证在Neo4j中维护平台全量粉丝关注数据针对粉丝关注数据我们有两份第一份是历史粉丝关注数据第二份是实时粉丝关注数据如何通过这两份数据实现维护平台全量粉丝关注数据呢？背景是这样的历史粉丝数据是由服务端每天晚上0点的时候定时同步到mysql数据库中的，因为之前平台是把粉丝的关注数据，存储到了redis中，每天晚上定时向mysql中同步一次。实时粉丝数据在准备做这个项目之前通过日志采集工具把这些数据采集到kafka里面了基于此，假设我们是在2026年2月1日那天上

一、Hadoop启动start-all.sh停止stop-all.sh查看进程jpsjps -mps -ef |grep 进程名称1、hdfs2、MapReduce3、Yarn二、Flume1、启动flume任务方式1：flume-ng agent --name a1 --conf conf --conf-file conf/example.conf -Dflume.root.logger=INFO,console2、启动命令1解释：后面指定agent，表示启动一个

1、一个1G的文件，会产生多少个map任务？Block块默认是128M，所以1G的文件会产生8个Block块默认情况下InputSplit的大小和Block块的大小一致，每一个InputSplit会产生一个map任务所以：1024/128=8个map任务2、1000个文件，每个文件100KB，会产生多少个map任务？一个文件，不管再小，都会占用一个block，所以这1000个小文件会产生1000个Block，那最终会产生1000个InputSplit，也就对应着会产生1000个map任务一个1

现象如下：原因：（1）环境变量中配置了Hbase的目录导致hbase安装包下日志jar包重复导致。cd /data/soft/hbase-2.2.7/lib/client-facing-thirdparty把这三个jar包重命名一下。或者把环境变量注释掉。（2）环境变量配置了HADOOP_CLASSPATH导致的vi /etc/profileexport HADOOP_CLASSPATH=`${HADOOP_HOME}/bin/hadoop classpath`把这个注释掉或

注：这个问题其实不影响，但强迫症不想看到报错。。1、场景在使用IntelliJ IDEA 写spark相关的代码时候遇到：Could not locate executable null\bin\winutils.exe in the Hadoop binaries.2、原因根据报错是没有定位到这个文件：winutils.exe3、解决办法首先在本地解压一个hadoop，这里我使用的是3.2.0hadoop3.2.0的下载地址：链接：https://pan.baidu.com/s/1jCm

一、Sqoop数据采集参数优化默认情况下Sqoop采集数据只会生成一个map任务，采集性能会比较低，我们可以通过splitBy指定一个数字类型的列，再去修改num-mappers的值，这样就可以提高采集性能了，一般可以将num-mappers设置为5~10个。二、集群Queue队列优化针对大数据集群的资源可以分为多个队列，可以分为一个online队列，online表示线上的意思，这里面会执行线上的任务，还有一个offline队列，这个里面执行离线任务针对我们的数仓任务可以在离线队列中执行，不影响线上

一、任务调度针对数据仓库中的任务脚本我们前面已经整理过了，任务脚本还是比较多的，针对初始化表的脚本只需要执行一次即可，其它的脚本需要每天都执行一次，这个时候就需要涉及到任务定时调度了。二、Crontab调度器的使用咱们前面在学习Linux的时候学过一个crontab调度器，通过它可以实现定时执行指定的脚本。针对我们这个数据仓库中的这些脚本使用crontab进行调度是可以的。但是需要注意一点：这些任务之间是有一些依赖关系的，从大的层面上来说，dwd层的任务需要等ods层的任务执行成功之后才能开始执行

一、数据可视化数据可视化这块不是项目的重点，不过为了让大家能有一个更加直观的感受，我们可以选择一些现成的数据可视化工具实现。咱们前面分析过，想要查询hive中的数据可以使用hue，不过hue无法自动生成图表。所以我们可以考虑使用Zeppelin针对一些复杂的图表，可以选择定制开发，使用echarts、finebi组件实现。二、Zeppelin安装部署注意：不要使用Zeppelin0.8.2版本，这个版本有bug，无法使用图形展现数据。在这我们使用zeppelin-0.9.0-preview1这

一、数据库和表梳理二、任务脚本梳理三、数据这个待补充。

一、什么是拉链表针对订单表、订单商品表，流水表，这些表中的数据是比较多的，如果使用全量的方式，会造成大量的数据冗余，浪费磁盘空间。所以这种表，一般使用增量的方式，每日采集新增的数据。在这注意一点：针对订单表，如果单纯的按照订单产生时间增量采集数据，是有问题的，因为用户可能今天下单，明天才支付，但是Hive是不支持数据更新的，这样虽然MySQL中订单的状态改变了，但是Hive中订单的状态还是之前的状态。想要解决这个问题，一般有这么几种方案：第一种：每天全量导入订单表的数据，这种方案在项目启动初期是没

一、漏斗分析先看漏斗的效果其实就是根据用户的行为一层一层分析用户的转化率。活跃–>商品详情页–>下单–>支付每一个指标对应的表：活跃：dws_user_active_history商品详情页：dwd_good_item下单：dwd_user_order支付：dwd_user_order二、思路首先统计当天活跃用户数量。接着统计当天进入了多少个商品详情页。接着统计当天下单的数量。最后统计当天支付的数量。并且计算每一层的转化率。最终把结果数据保存到表app_us

一、商品相关指标分析针对这个需求我们主要统计两个指标1、商品销售情况（商品名称、一级类目、订单总量、销售额）2、商品品类偏好Top10（商品一级类目，订单总量）二、思路1、商品销售情况这个指标主要统计商品名称，一级类目、订单总量、销售额这些字段信息。订单中的详细信息是在dwd_order_item表中，需要关联dwd_goods_info和dwd_category_code获取商品名称和商品一级类目信息。在这最后是基于这些表构建一个商品订单信息的宽表 dws_order_goods_all_

一、电商GMV分析GMV：Gross Merchandise Volume,是指一定时间内的成交总金额。GMV 多用于电商行业，这个实际指的是拍下的订单总金额，包含付款和未付款的部分。我们在统计的时候就可以将订单中的每天的所有订单金额全部都累加起来，就可以获取到当天的GMV了。二、思路对dwd_user_order表中的数据进行统计即可，通过order_money字段可以计算出来GMV,将结果保存到表app_gmv中。三、app层注意：gmv字段的类型可以使用double或者decimal(1

一、用户信息宽表分析宽表主要是便于使用，在使用的时候不至于每次都要关联很多张表。用户信息宽表包括服务端中的user表、user_extend表。如果有需求的话其实还可以把用户的一些其他维度的数据关联过来，例如：当日的下单数量、消费金额等等指标。二、思路对dwd_user表和dwd_user_extend表执行left join操作，通过user_id进行关联即可，将结果数据保存到dws_user_info_all表中。三、dws层1、（1）源表（2）建表语句（3）映射关系四、开发脚本

一、需求分析需求一：用户信息宽表需求二：电商GMV需求三：商品相关指标需求四：用户行为漏斗二、生成数据为了保证大家在练习的时候计算的数据结果和我的保持一致，所以针对后面的测试数据就不再随机生成了，而是生成固定的数据，一共1个月的数据。从2026-02-01~2026-02-28的数据。1、执行代码注意，这里的校验码：JD3B37868104C5F2A这个校验码有效期只有1个月。以及下面hdfs的地址改成你自己的地址如下，说明执行完成了：2、去hdfs上检查数据是否生成这个是直接

一、分析针对ods层表中的数据进行清洗，参考数据清洗规则，按照实际情况对数据进行清洗。由于数据库中的数据都是比较规整的，其实可以直接迁移到dwd层，不过为了以防万一，还是对ods层的数据进行过滤，主要过滤表中的id字段为null的数据，在关系型数据库中表中的id字段都是主键，肯定是不为Null的，我们在这里进行判断主要是为了避免数据在采集过程中出现问题。二、构建dwd层1、dwd_user（1）源表ods_user（2）建表语句create external table if not ex

一、ods层在ods层中需要创建以下针对商品订单数据的表表名 说明 导入方式ods_user 用户信息表 全量ods_user_extend 用户扩展表 全量ods_user_addr 用户收货地址表 全量ods_goods_info 商品信息表 全量ods_category_code 商品类目码表 全量ods_user_order 订单表 增量ods_order_item 订单商品表 增量ods_order_delivery

一、数据库和表梳理二、任务脚本梳理三、用户行为所有涉及的脚本和数据如下下载地址：链接：https://pan.baidu.com/s/1A8oU_y6SwJ8eWTkrhFUjOw?pwd=91m5 提取码：91m5 注：里面包含所有的脚本，客户端埋点的数据、服务端的数据。服务端的数据直接导入到数据库，然后再使用sqoop导入到hdfs就行了。客户端埋点的数据直接使用hdfs dfs -put /data/ods/user_action下。...

一、App崩溃相关指标分析这个需求是统计在不同平台系统不同版本下App崩溃的情况，统计这个数据可以方便排查定位问题，如果发现某一个版本的App崩溃频繁，则需要及时修复问题，推送新版本，提升用户体验。针对这个需求主要统计下面几个指标1、每日操作系统奔溃总计（安卓、IOS）2、每日安卓系统-不同APP版本奔溃量3、每日IOS系统-不同APP版本崩溃量这里面三个指标是有关联的，第一个是总的统计，第二个和第三个是不同维度的统计。二、思路针对第一个指标，使用dwd_app_close表中的数据，根据p

一、操作系统活跃用户相关指标分析这个需求是统计一下我们产品的目前主要用户群体是使用什么类型的操作系统。因为我们产品的app是有Android端和ios端的。如果我们的用户80%以上使用的都是Android,那么我们肯定要针对Android端的APP做更多的优化支持，这样可以保证大部分用户的使用体验。还有就是获取用户使用的手机型号，分辨率信息，这样可以更好的做适配。针对这个需求我们主要统计以下指标：1、操作系统活跃用户分布（安卓、IOS）2、安卓系统版本活跃用户分布3、IOS系统版本活跃用户分

一、每日启动App次数相关指标分析这个需求就是对每日打开app上报的数据进行统计。针对这个需求我们需要统计两个指标1、每日人均启动App次数2、每日APP启动次数分布（1次、2次、3次及以上）二、思路1、每日人均启动APP次数每日人均启动App次数=当日所有用户启动App总次数/当日所有人数针对这种需求，我们在计算结果的时候最好是把这个指标的分子和分母保存起来，这样这份数据后期还有可能被复用，如果直接保存最终的结果，这个数据就没办法复用了。1、基于dws_user_active_histo

一、用户7日流失push提醒分析什么是流失？假设这个用户在2026年2月2日是新增用户，如果他在后续的7天内，也就是在2月9日内没有再使用app,则认为是流失用户，具体多少天属于流失用户，这个是需要产品经理根据对应产品的特点来定的，一般业内使用比较多的是7天这个时间点。push是什么意思呢？大家平时是不是深受各种app的提醒轰炸，我针对大部分的app都禁用了消息推送，要不然每天手机上会有各种各样的推送消息，很烦，这个其实就是软件给你push的消息。二、实现思路1、基于dws_user_activ

一、每日活跃用户（主活）相关指标分析活跃用户的定义是指只要当天使用过APP就算是活跃用户，使用APP这种操作属于主动操作，所以这种活跃我们也会称为主动活跃，简称主活。针对这个需求统计的指标和新用户的指标类似1、每日主活用户量2、每日主活用户量的日环比和周同比1、每日主活用户量主活的概念和定义我们知道了，其实就是统计每天使用过app的用户，所以我们可以直接使用dws层的dws_user_active_history这个表。直接求和即可获取到当日的主活用户量，将最终的结果保存到app层的app_u

一、每日新增用户相关指标分析在统计新增用户时，用户是以设备标识（xaid字段）来判断的，每一个设备都有一个唯一设备码。因为会存在用户不登录的情况，以及多人共用一个账号的情况，所以根据用户id进行过滤统计是不准确的。新增用户是指第一次安装并且使用app的用户，后期卸载之后再使用就不算新用户了，这个新增用户其实也可以称为新增设备，一个设备对应一个用户。1、每日新增用户量2、每日新增用户量的日环比和周同比二、每日新增用户量分析1、分析在时间工作中通过这个指标可以衡量我们产品的用户增长速度，如果每日

一、需求分析前面的两层中的表和需求一般没什么关系，就是把已有的数据接入进来。然后对数据进行清洗处理。但是后面的dws层和app层是和业务有关联的，所以在构建这两层中的表的时候，我们需要根据一些典型的业务场景来进行分析，在根据具体业务建表的时候尽可能把表设计的更加通用，可以满足后期一些类似业务需求。就是说我们在基于业务构建表的时候，不要直接一个SQL搞定，可以把一些复杂的SQL基于一些维度进行拆分，拆分出来一些中间表，再基于这些中间表统计最终的结果。这样这个中间表里的数据，我们后期针对一些类似的业务

一、dwd层分析下面我们来创建dwd层：针对ods层表中的数据进行清洗，参考数据清洗规则，按照实际情况对数据进行清洗。注意：如果清洗规则使用SQL可以实现，那么就使用SQL实现数据清洗，如果清洗的规则使用SQL实现起来非常麻烦，或者使用SQL压根无法实现，此时就可以考虑需要使用MapReduce代码或者Spark代码对数据进行清洗了。由于我们这里采集的数据还是比较规整的，可以使用SQL实现，所以我们就直接使用SQL实现数据清洗了。二、创建dwd层数据库在hive中创建数据库dwd_mallc

咱们前面对项目的需求进行了分析，整体上来说是需要三个大的功能模块，那下面我们就来分析一下，想要实现这些功能模块，具体使用哪些技术框架比较合适。一、技术选型1、数据采集咱们前面学习了Flume这个数据采集工具其实还有一些类似的数据采集工具，Logstash、FileBeat，这两个也可以实现数据采集那这三个日志采集工具我们需要如何选择呢？首先从性能消耗上面来说，Flume和Logstash的性能消耗差不多，都是基于JVM执行的，都是重量级的组件，支持多种数据源和目的地。FileBeat是一个只支

接下来我们就来开发第一个模块：数据采集模块这一块内容在开发的时候，我们需要先生成测试数据，一份是服务端数据，还有一份是客户端数据一、数据生成1、【客户端数据】用户行为数据首先我们模拟生成用户行为数据，也就是客户端数据，主要包含用户打开APP、点击、浏览等行为数据用户行为数据：通过埋点上报，后端日志服务器(http)负责接收数据埋点上报数据基本格式：{"uid"：1001, //用户ID"xaid"："ab25617-c38910-m2991", //手机设备ID"platform"：

一、Sqoop的版本Sqoop目前有两大版本，Sqoop1和Sqoop2，这两个版本都是一直在维护者的，所以使用哪个版本都可以。这两个版本我都用过，还是感觉Sqoop1用起来比较方便，使用Sqoop1的时候可以将具体的命令全部都写到脚本中，这样看起来是比较清晰的，但是有一个弊端，就是在操作MySQL的时候，MySQL数据库的用户名和密码会明文暴露在这些脚本中，不过一般也没有什么问题，因为在访问生产环境下的MySQL的时候，是需要申请权限的，就算你知道了MySQL的用户名和密码，但是你压根无法访问MySQ

一、什么是数据仓库咱们前面说了要构建一个数据仓库，那严格意义上来说，到底什么是数据仓库呢？咱们前面学习过Hive，说Hive其实就是一个数据仓库，可以这样理解，就是把Hive认为是一种技术，通过Hive这种技术可以实现数据仓库的建设。咱们这个项目中的数据仓库就是使用Hive构建的。来看一下针对数据仓库的官方解释：数据仓库(Data Warehouse)是一个面向主题的、集成的、稳定的且随时间变化的数据集合，用于支持管理人员的决策。二、数据仓库的特性1、面向主题主题就是类型的意思。传统数据库

一、项目效果展示大家好，下面我们来学习一个电商行业的数据仓库项目首先看一下项目效果本身我们这个数据仓库项目其实是一个纯后台项目，不过为了让大家能够更加直观的感受项目的效果，我们可以基于数据仓库中的数据统计一些指标进行展现。我们这个项目要讲的重点不是这个大屏，这个大屏只是一个效果，为了让大家感受更加直观一些而已，我们主要讲的是这些指标对应的底层数据是如何在数据仓库中一层一层构建的。二、项目的由来接下来我们来看一下这个项目的由来，我们为什么要做这个数据仓库项目呢？或者说做这个数据仓库项目有什么意义

一、Flume高级组件1、Source InterceptorsSource可以指定一个或者多个拦截器按先后顺序依次对采集到的数据进行处理。2、Channel SelectorsSource发往多个Channel的策略设置，如果source后面接了多个channel，到底是给所有的channel都发，还是根据规则发送到不同channel，这些是由Channel Selectors来控制的3、Sink ProcessorsSink 发送数据的策略设置，一个channel后面可以接多个sink，ch

一、Hadoop在CDH和HDP中的使用咱们前面学习了官方的Apache Hadoop版本，我们前面也说了，在实际工作中其实会使用CDH或者HDP，那下面我们就看一下在CDH和HDP中如何操作Hadoop。注意了，在这里我不打算讲CDH和HDP的安装部署，意义不大，咱们是开发人员，主要侧重于代码开发，安装部署的工作是运维人员的，咱们不能抢饭碗啊，什么都让你做了，别人不就得喝西北风啊，这样太不地道了，对吧。如果确实想了解CDH是怎么安装的，看下面我整理的CDH集群以及单机部署大数据平台安装部署–CD

前面我们把Hadoop中的HDFS、MapReduce、YARN中比较常用和重要的功能基本都学习完了，但是在后续工作中可能会遇到一些特殊的场景需要用到特殊的知识点，这个时候就需要考验大家的自学能力了，以及后期你再遇到一些新的技术框架，想要从0开始学习的时候这个时候该如何下手呢？官方文档是最直接最靠谱的途径下面我们就以Hadoop官网为例来分析一下：其实咱们前面学习的很多知识点在官网中都有说明一般网站上都有这么几个链接下载：下载安装包快速开始：快速安装部署，运行起来文档：最完整、最权威的技术文

案例：YARN多资源队列配置和使用我们的需求是这样的，希望增加2个队列，一个是online队列，一个是offline队列然后向offline队列中提交一个mapreduce任务online队列里面运行实时任务offline队列里面运行离线任务，我们现在学习的mapreduce就属于离线任务实时任务我们后面会学习，等讲到了再具体分析。这两个队列其实也是我们公司中最开始分配的队列，不过随着后期集群规模的扩大和业务需求的增加，后期又增加了多个队列。在这里我们先增加这2个队列，后期再增加多个也是一样的

一、HADOOP之YARN详解前面我们学习了Hadoop中的MapReduce，我们知道MapReduce任务是需要在YARN中执行的，那下面我们就来学习一下Hadoop中的YARN二、YARN的由来从Hadoop2开始，官方把资源管理单独剥离出来，主要是为了考虑后期作为一个公共的资源管理平台，任何满足规则的计算引擎都可以在它上面执行。所以YARN可以实现HADOOP集群的资源共享，不仅仅可以跑MapRedcue，还可以跑Spark、Flink。三、YARN架构分析咱们之前部署Hadoop集群的

在实际工作中，如果我们想提高MapReduce的执行效率，最直接的方法是什么呢？我们知道MapReduce是分为Map阶段和Reduce阶段，其实提高执行效率就是提高这两个阶段的执行效率默认情况下Map阶段中Map任务的个数是和数据的InputSplit相关的，InputSplit的个数一般是和Block块是有关联的，所以可以认为Map任务的个数和数据的block块个数有关系，针对Map任务的个数我们一般是不需要干预的，除非是前面我们说的海量小文件，那个时候可以考虑把小文件合并成大文件。其他情况是不需要

一、MapReduce性能优化现在大家已经掌握了MapReduce程序的开发步骤，注意了，针对MapReduce的案例我们并没有讲太多，主要是因为在实际工作中真正需要我们去写MapReduce代码的场景已经是凤毛麟角了，因为后面我们会学习一个大数据框架Hive，Hive支持SQL，这个Hive底层会把SQL转化为MapReduce执行，不需要我们写一行代码，所以说工作中的大部分需求我们都使用SQL去实现了，谁还苦巴巴的来写代码啊，一行SQL能抵你写的几十行代码，你还想去写MapReduce代码吗，肯定不想

前面我们分析了Java中的序列化和Hadoop中的序列化，其实最主要的区别就是针对相同的数据，Java中的序列化会占用较大的存储空间，而Hadoop中的序列化可以节省很多存储空间，这样在海量数据计算的场景下，可以减少数据传输的大小，极大的提高计算效率，下面我们就来具体实战分析一下。一、Java中的序列化1、代码如下：package com.imooc.mr;import java.io.*;/** * Java中的序列化机制介绍 */public class JavaSerialize