我的主要工作是:数仓建模和具体的业务指标分析 Flume日志采集到kafka->hdfs->load date ->hive Sqoop迁移到hive 我们的数仓分五层:ods->dwd->dws->dwt->ads 首先ods层是有个原始层，起到一个备份原始数据的作用。采用lzo压缩的方式对原始数据压缩，降低磁盘的存储空间，比如100g的数据可以压缩到10g.还可以采用分区的方式，避免后期的一个全表扫描。 然后到dwd层，对ods层数据进行清洗，一个是数仓建模。我们采用维度建模，星型模型，我们的核心业务过程有下单 支付 退款 评论 收藏 加购等。 一条业务线对应一张事实表。 根据核心业务过程，我们设计的总线矩阵，事实表有： 事务事实表:支付事实表,订单明细事实表,退款事实表,评论事实表。他的表结构和ods层中的表基本保持一致。主要看总线矩阵，看缺少哪些维度，找相关的表关联，补足。他的数据更新方式就是增量更新。比如说，支付事实表，我们要从时间、用户、地区维度统计分析。那么，原始的表中，缺少地区维度。我们需要关联订单表补足维度。 周期性快照事实表有收藏表和加入购物车表，数据会变化，但我们只统计他周期结束时的值。他的表结构和ods层中的表基本保持一致。主要看总线矩阵，看缺少哪些维度，找相关的表关联，补足。 最后是累积型事实表 是用于跟踪业务事实，有优惠券领用事实表和订单事实表。数据的特点是既有新增又有变化。这个变化有业务意义，需要记录。比如说订单事实表，订单状态的变化构成订单生命周期（创建时间=>支付时间=>取消时间=>完成时间=>退款时间=>退款完成时间），我们设计表的时候，需要为这六个环节设计对应的六个字段。因为这个生命周期可能是跨好几天才完成的,需要设计成动态分区表。数据更新，是累积更新，也就是当天的状态数据是new表，之前的数据是old表，然后old、new全外连接，利用new表里边的状态更新old表里的状态（sql） 维表设计，我们要符合星型模型。比如，商品维表，原始表有六张：一级、二级、三级类目表等等，那么我们就需要join成一张表。 用户维度表我们设计的是拉链表，因为用户表中的数据每天都有可能新增也有可能会修改。属于缓慢变化的维度 但是他修改的频率不是很高用全量去记录太过于浪费资源。 拉链表的制作有三个步骤：1、初始化拉链表，新增两个字段，开始时间、结束时间。 2、制作当日用户变化表，包含新增及变化的数据； 3、历史拉链表和用户变化表合并。 合并的逻辑是这样的。首先，历史拉链表 left join 用户变化表，求交集，交集部分是变化的数据，找到历史版本，如果结束时间是9999，修改成前一天；然后，union all 用户变化表。 dwd层日志数据，我们是这样处理的。利用 get_josn_object 函数，提取json对象然后转换成曝光日志，页面日志，对于复杂的数据，我们需要自定义udtf函数，进行处理。 dws 和dwt都是汇总层，这层表的设计，就是围绕某个主题，将相关业务事件汇总到一块儿，统计相关指标。目前，我们的主题，主要有用户主题、设备主题、商品主题、地区主题、营销主题。比如说，我们围绕用户主题，将登录、下单、支付、评论等汇总到一块儿，统计登录次数、下单次数等相关指标。dws层的主要是以天汇总的，统计每天的登录次数、下单次数、支付次数等；然后这个dwt层就是一个累计汇总，统计的是，首次下单、末次下单，累积下单次数这样的指标。汇总层细分成dws、dwt的好处是：减少了重复计算，还有每次计算的数据量。比如说，我们统计30天、60天、90天的订单量，如果没有按天汇总的话，我们就要拉取30天、60天的数量。数据量大，并且有重复计算。有按天汇总的话，我们就是在天的基础上，30个数字、60个数字的加总。 最后到ads层就是对电商系统各大主题指标分别进行分析 有日活周活月活，每日新增用户数 会员数，沉默，回流用户数，七天连续三天登录，咱这个会员主题用的就是漏斗分析，有这个浏览首页 浏览商品详情页 加入购物车 下单 支付的这个转化率 商店个数信息等这些指标。 用户行为漏斗分析:当日首页浏览人数-->商品详情页浏览人数-->加购人数-->下单人数-->支付成功人数 七天内连续登录三次:ROW_NUMBER()根据mid_id分组,dt(时间)排序 rn,用date_sub求出七天内的,最后dt-rn >=3天 本周回流