目录
4.10 数据仓库每天跑多少张表，大概什么时候运行，运行多久？
2.4 框架版本选型
1）Apache：运维麻烦，组件间兼容性需要自己调研。（一般大厂使用，技术实力雄厚，有专业的运维人员）
2）CDH6.3.2：国内使用最多的版本，但 CM不开源，但其实对中、小公司使用来说没有影响（建议使用）10000美金一个节点 CDP7.0
3）HDP2.7：开源，可以进行二次开发，但是没有CDH稳定，国内使用较少
Apache框架版本
| 产品 | 旧版本 | 新版本 | 版本新增 |
| Hadoop | 2.7.2 | 3.1.3 | HDFS的web端口号由50070变为9870， 客户端访问端口号9820/8020/9000 |
| Zookeeper | 3.4.10 | 3.5.7 |
|
| Mysql | 5.6.24 | 5.7.16 | ①原生json支持：不需要遍历所有字符串、通过虚拟列的功能对json的数据进行索引 ②多源复制：多主一从 ③InnoDB优化：为innoDB_buffer_pool_size、 innoDB_log_file_size、innoDB_flush_method提供了更加合适的默认值 |
| Hive | 1.2.1 | 3.1.2 | （没有查到，查到的都是说不再支持mr引擎） |
| Flume | 1.7.0 | 1.9.0 |
|
| Kafka | 0.11-0.2 | _2.11-2.4.1 | ①kafka 0.9版本之前，offset保存在Zookeeper中；从0.9版本开始，consumer自己维护了一个offset ②允许使用者从最近的副本中获取 |
| Kafka Eagle | 1.3.7 | 1.4.5 |
|
| Azkaban | 2.5.0 | 3.84.4 | 集成了给用户打电话的功能 |
| Spark | 2.1.1 | 3.0.0 | 不支持scala 2.11.x，升级为2.12.x |
| Hbase | 1.3.1 | 2.0.5 |
|
| Phoenix | 4.14.1 | 5.0.0 | 支持Apache HBase 2.0 |
| Redis | 3.2.5 | 3.2.5 |
|
| Canal | 1.1.2 | 1.1.2 |
|
| ElasticSearch+Kibana | 6.3.1 | 6.3.1 |
|
Azkaban、hive、kylin需要重新编译
2.5 服务器选型
服务器使用物理机还是云主机？
1）机器成本考虑：
（1）物理机：以128G内存，20核物理CPU，40线程，8THDD和2TSSD硬盘，单台报价4W出头，惠普品牌。一般物理机寿命5年左右。
（2）云主机，以阿里云为例，差不多相同配置，每年5W
2）运维成本考虑：
（1）物理机：需要有专业的运维人员（1万*13个月）、电费（商业用户）、安装空调
（2）云主机：很多运维工作都由阿里云已经完成，运维相对较轻松
3）企业选择
（1）金融有钱公司和阿里没有直接冲突的公司选择阿里云（上海）
（2）中小公司、为了融资上市，选择阿里云，拉倒融资后买物理机。
（3）有长期打算，资金比较足，选择物理机。
2.6 集群规模
20核物理CPU 40线程 * 7 = 280线程
内存128g * 7台 = 896g （计算任务内存700g，其他安装框架需要内存）
128m =》1g内存
=》
87g数据 、700g内存
根据数据规模大家集群
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| nn | nn | dn | dn | dn | dn | dn | dn | dn | dn |
|
|
| rm | rm | nm | nm | nm | nm | nm | nm |
|
|
| nm | nm |
|
|
|
|
|
|
|
|
|
|
|
|
|
| zk | zk | zk |
|
|
|
|
|
|
|
| kafka | kafka | kafka |
|
|
|
|
|
|
|
| Flume | Flume | flume |
|
|
| Hbase | Hbase | Hbase |
|
|
|
|
|
| hive | hive |
|
|
|
|
|
|
|
|
| mysql | mysql |
|
|
|
|
|
|
|
|
| spark | spark |
|
|
|
|
|
|
|
|
|
|
|
|
|
| ES | ES |
|
|
|
1）消耗内存的分开；
2）kafka 、zk 、flume 传输数据比较紧密的放在一起；
3）客户端尽量放在一到两台服务器上，方便外部访问；
第4章 生产经验—业务
4.1 电商常识
4.1.1 SKU和SPU
SKU：一台银色、128G内存的、支持联通网络的iPhoneX
SPU：iPhoneX
Tm_id：品牌Id苹果，包括IPHONE，耳机，mac等
4.1.2 订单表跟订单详情表区别？
订单表的订单状态会变化，订单详情表不会，因为没有订单状态。
订单表记录user_id，订单id订单编号，订单的总金额order_status，支付方式，订单状态等。
订单详情表记录user_id，商品sku_id ,具体的商品信息（商品名称sku_name，价格order_price，数量sku_num）
4.2 埋点行为数据基本格式(基本字段)
我们要收集和分析的数据主要包括页面数据、事件数据、曝光数据、启动数据和错误数据。
4.2.1 页面
页面数据主要记录一个页 面的用户访问情况，包括访问时间、停留时间、页面路径等信息。
所有页面id如下
home("首页"),
category("分类页"),
discovery("发现页"),
top_n("热门排行"),
favor("收藏页"),
search("搜索页"),
good_list("商品列表页"),
good_detail("商品详情"),
good_spec("商品规格"),
comment("评价"),
comment_done("评价完成"),
comment_list("评价列表"),
cart("购物车"),
trade("下单结算"),
payment("支付页面"),
payment_done("支付完成"),
orders_all("全部订单"),
orders_unpaid("订单待支付"),
orders_undelivered("订单待发货"),
orders_unreceipted("订单待收货"),
orders_wait_comment("订单待评价"),
mine("我的"),
activity("活动"),
login("登录"),
register("注册");
所有页面对象类型如下：
sku_id("商品skuId"),
keyword("搜索关键词"),
sku_ids("多个商品skuId"),
activity_id("活动id"),
coupon_id("购物券id");
所有来源类型如下：
promotion("商品推广"),
recommend("算法推荐商品"),
query("查询结果商品"),
activity("促销活动");
4.2.2 事件
事件数据主要记录应用内一个具体操作行为，包括操作类型、操作对象、操作对象描述等信息。
所有动作类型如下：
favor_add("添加收藏"),
favor_canel("取消收藏"),
cart_add("添加购物车"),
cart_remove("删除购物车"),
cart_add_num("增加购物车商品数量"),
cart_minus_num("减少购物车商品数量"),
trade_add_address("增加收货地址"),
get_coupon("领取优惠券");
注：对于下单、支付等业务数据，可从业务数据库获取。
所有动作目标类型如下：
sku_id("商品"),
coupon_id("购物券");
4.2.3 曝光
曝光数据主要记录页面所曝光的内容，包括曝光对象，曝光类型等信息。
所有曝光类型如下：
promotion("商品推广"),
recommend("算法推荐商品"),
query("查询结果商品"),
activity("促销活动");
所有曝光对象类型如下：
sku_id("商品skuId"),
activity_id("活动id");
4.2.4 启动
启动数据记录应用的启动信息。
所有启动入口类型如下：
icon("图标"),
notification("通知"),
install("安装后启动");
4.2.5 错误
错误数据记录应用使用过程中的错误信息，包括错误编号及错误信息。
4.2.6 埋点数据日志格式
我们的日志结构大致可分为两类，一是普通页面埋点日志，二是启动日志。
普通页面日志结构如下，每条日志包含了，当前页面的页面信息，所有事件（动作）、所有曝光信息以及错误信息。除此之外，还包含了一系列公共信息，包括设备信息，地理位置，应用信息等，即下边的common字段。
{
"common": { -- 公共信息
"ar": "230000", -- 地区编码
"ba": "iPhone", -- 手机品牌
"ch": "Appstore", -- 渠道
"md": "iPhone 8", -- 手机型号
"mid": "YXfhjAYH6As2z9Iq", -- 设备id
"os": "iOS 13.2.9", -- 操作系统
"uid": "485", -- 会员id
"vc": "v2.1.134" -- app版本号
},
"actions": [ --动作(事件)
{
"action_id": "favor_add", --动作id
"item": "3", --目标id
"item_type": "sku_id", --目标类型
"ts": 1585744376605 --动作时间戳
}
]，
"displays": [
{
"displayType": "query", -- 曝光类型
"item": "3", -- 曝光对象id
"item_type": "sku_id", -- 曝光对象类型
"order": 1 --出现顺序
},
{
"displayType": "promotion",
"item": "6",
"item_type": "sku_id",
"order": 2
},
{
"displayType": "promotion",
"item": "9",
"item_type": "sku_id",
"order": 3
},
{
"displayType": "recommend",
"item": "6",
"item_type": "sku_id",
"order": 4
},
{
"displayType": "query ",
"item": "6",
"item_type": "sku_id",
"order": 5
}
],
"page": { --页面信息
"during_time": 7648, -- 持续时间毫秒
"item": "3", -- 目标id
"item_type": "sku_id", -- 目标类型
"last_page_id": "login", -- 上页类型
"page_id": "good_detail", -- 页面ID
"sourceType": "promotion" -- 来源类型
},
"err":{ --错误
"error_code": "1234", --错误码
"msg": "***********" --错误信息
},
"ts": 1585744374423 --跳入时间戳
}
启动日志结构相对简单，主要包含公共信息，启动信息和错误信息。
{
"common": {
"ar": "370000",
"ba": "Honor",
"ch": "wandoujia",
"md": "Honor 20s",
"mid": "eQF5boERMJFOujcp",
"os": "Android 11.0",
"uid": "76",
"vc": "v2.1.134"
},
"start": {
"entry": "icon", --icon手机图标 notice 通知 install 安装后启动
"loading_time": 18803, --启动加载时间
"open_ad_id": 7, --广告页ID
"open_ad_ms": 3449, -- 广告总共播放时间
"open_ad_skip_ms": 1989 -- 用户跳过广告时点
},
"err":{ --错误
"error_code": "1234", --错误码
"msg": "***********" --错误信息
},
"ts": 1585744304000
}
4.3 电商业务流程
1）记住表与表之间的关系
2）每个表记住2-3个字段
4.4 维度表和事实表（重点）
4.4.1 维度表
维度表：一般是对事实的描述信息。每一张维表对应现实世界中的一个对象或者概念。 例如：用户、商品、日期、地区等。
4.4.2 事实表
事实表中的每行数据代表一个业务事件（下单、支付、退款、评价等）。“事实”这个术语表示的是业务事件的度量值（可统计次数、个数、件数、金额等），例如，订单事件中的下单金额。
每一个事实表的行包括：具有可加性的数值型的度量值、与维表相连接的外键、通常具有两个和两个以上的外键、外键之间表示维表之间多对多的关系。
1）事务型事实表
以每个事务或事件为单位，例如一个销售订单记录，一笔支付记录等，作为事实表里的一行数据。一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量更新。
2）周期型快照事实表
周期型快照事实表中不会保留所有数据，只保留固定时间间隔的数据，例如每天或者每月的销售额，或每月的账户余额等。
3）累积型快照事实表
累计快照事实表用于跟踪业务事实的变化。例如，数据仓库中可能需要累积或者存储订单从下订单开始，到订单商品被打包、运输、和签收的各个业务阶段的时间点数据来跟踪订单声明周期的进展情况。当这个业务过程进行时，事实表的记录也要不断更新。
| 订单id | 用户id | 下单时间 | 打包时间 | 发货时间 | 签收时间 | 订单金额 |
|
|
| 3-8 | 3-8 | 3-9 | 3-10 |
|
4.5 同步策略（重点）
实体表，维度表统称维度表，每日全量或者每月（更长时间）全量
事务型事实表：每日增量
周期性事实表：拉链表
4.6 关系型数据库范式理论
1NF：属性不可再分割（例如不能存在5台电脑的属性，坏处：表都没法用）
2NF：不能存在部分函数依赖（例如主键（学号+课名）-->成绩，姓名，但学号--》姓名，所以姓名部分依赖于主键（学号+课名），所以要去除，坏处：数据冗余）
3NF：不能存在传递函数依赖（学号--》宿舍种类--》价钱，坏处：数据冗余和增删异常）
MySQL关系模型：关系模型主要应用与OLTP系统中，为了保证数据的一致性以及避免冗余，所以大部分业务系统的表都是遵循第三范式的。
Hive 维度模型：维度模型主要应用于OLAP系统中，因为关系模型虽然冗余少，
但是在大规模数据，跨表分析统计查询过程中，会造成多表关联，这会大大降低执行效率。
所以HIVE把相关各种表整理成两种：事实表和维度表两种。所有维度表围绕着事实表进行解释。
4.7 数据模型
雪花模型、星型模型和星座模型
（在维度建模的基础上又分为三种模型：星型模型、雪花模型、星座模型。）
星型模型（一级维度表），雪花（多级维度），星座模型（星型模型+多个事实表）
4.8 拉链表（重点）
拉链表处理的业务场景：主要处理缓慢变化维的业务场景。（用户表、订单表）
4.9 即席查询数据仓库
Kylin: T+1
Impala: CDH
Presto: Apache版本框架
4.10 数据仓库每天跑多少张表，大概什么时候运行，运行多久？
基本一个项目建一个库，表格个数为初始的原始数据表格加上统计结果表格的总数。（一般70-100张表格）
用户行为5张；业务数据23张表 =》ods 24 =》dwd=>20张=》dws 6张宽表=>dwt6张宽表=>ads=》30张 =》86张
每天0：30开始运行。=》sqoop 40-50分钟：1点20：=》 5-6个小时运行完指标
所有离线数据报表控制在8小时之内
大数据实时处理部分控制在5分钟之内。（分钟级别、秒级别）
如果是实时推荐系统，需要秒级响应
4.11 活动的话，数据量会增加多少？怎么解决？
日活增加50%，GMV增加多少。（留转G复活）情人节，促销手纸。
集群资源都留有预量。11.11，6.18，数据量过大，提前动态增加服务器。
4.12 并发峰值多少？大概哪个时间点？
高峰期晚上7-12点。Kafka里面20m/s 2万/s 并发峰值在1-2万人
4.13 数仓中使用的哪种文件存储格式
常用的包括：textFile，rcFile，ORC，Parquet，一般企业里使用ORC或者Parquet，因为是列式存储，且压缩比非常高，所以相比于textFile，查询速度快，占用硬盘空间少
4.14 哪张表最费时间，有没有优化
用户行为宽表，数据量过大。数据倾斜的相关优化手段。（hadoop、hive、spark）
4.15 用什么工具做权限管理
Ranger或Sentry （用户认证kerberos（张三、李四、王五）=>表级别权限（张三、李四）、字段级别权限（李四））
4.16 数仓当中数据多久删除一次
1）部分公司永久不删
2）有一年、两年“删除”一次的，这里面说的删除是，先将超时数据压缩下载到单独安装的磁盘上。然后删除集群上数据。 很少有公司不备份数据，直接删除的。
1073
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
