数仓建模

大数据项目之电商数仓(用户行为数据采集)数据仓库简介

1.什么是数据库
数据库(Database)是按照数据结构来组织、存储和管理数据的建立在计算机存储设备上的仓库。
数据库是长期存储在计算机内、有组织的、可共享的数据集合。数据库中二点数据指的是以一定的数据模型组织、描述和储存在一起、具有尽可能小的冗余度、较高的数据独立性和易扩展性的特点并可在一定范围内为多个用户共享。

常用的数据库有:Mysql、ORACLE、SQL Server等。作用不一样,数据库是用来支撑业务的,需要响应速度特别快,没有延时,查询起来都是一条条查询,把相关的数据全部得到,适合用这种关系型数据库。数据仓库用来主要用来支撑分析的。此时设计到一个问题。什么是业务?



业务就是:系统会和自己用户打交道的系统,为业务系统。例如滴滴打车,乘客(叫车,上车,确认上车,确认到达,好评),司机,自己公司的员工,公司就会开发出配套的it系统。公司的一个员工:考勤系统、财务系统,都需要有对应的数据库做支持    

2.什么是数据仓库?

数据仓库是决策支持系统(dss)和联机分析应用数据源的结构化数据环境。数据仓库研究和解决从数据库中获取信息的问题。
数据仓库的特征在于面向主题、集成性、稳定性和时变性,用于支持管理决策。数据仓库存在的意义在于对企业的所有数据进行汇总,为企业各个部分提供统一的、规范的数据出口。
面向主题:数据仓库中的数据是按照一定的主题域进行组织的,每一个主题对应一个宏观的分析领域。数据仓库排除对于决策无用的数据,提供特定主题的简明视图。
面向主题(一种看待问题的角度):用户分析,财务分析,销售分析,订单分析....。主题不一样,需要的分析指标不一样,不同的指标的数据(表和字段)和分析的指标就不一样。

OLAP和OLTP的区别:
OLAP(On-line Analytical Processing)联系分析处理,也称为面向交易的处理过程,其基本特征是前台接收的用户数据可以立即传送到计算中心进行处理,并在很短的时间内给出处理结果,是对用户操作快速响应的方式之一。应用在数据仓库,使用对象是决策者。OLAP系统强调的数据分析,响应速度要求没那么高。OLTP(On-line Transaction Processing)联机事务处理,它使分析人员能够迅速、一致、交互地从各个方面观察信息,以达到深入理解数据的目的。它具有FASMI(Fast Analysis of Shared Multidimensional Information),即共享多维信息的快速分析的特征。主要应用是传统关系型数据库。OLTP系统强调的是内存效率,实时性比较高。
数仓建模_第1张图片

数据的一致性怎么理解?

在数据仓库里面有各种数据的来源,最终我们创建数据仓库需要把这些不同的数据整合,而很有可能这些数据不一致,例如:业务系统数据库在建模的时候,会采用关系建模,遵循三范式,减少冗余,尽量保证数据的一致性。现实情况中假设有500张表,10张表都有性别这个字段,但是因为开发java后台的时候,有可能是多个团队,多个阶段,多个项目组来实现...数据仓库需要把这些数据全部导入,需要做一致性的处理。

数仓的特点?

集成的:企业内不同业务部门数据的完整集成。对于企业内所有数据的集成要注意一致性(假设财务系统中对于性别F/M,而OA系统对性别使用A/B,这就是数据不一致,如果想搭建企业级的数据仓库,需要数据具有一致性)。
稳定的:数仓里不存在数据的更新和删除操作。
变化的:数仓里会完整的记录某个对象在一段时期内的变化情况。

数据仓库的目标是实现集成、稳定、反映历史变化有组织有结构的存储数据的集合。

第一章 数据仓库概念数据仓库概念:

数仓建模_第2张图片

数据仓库(Data Warehouse),是为企业所有决策制定过程,提供所有系统数据支持的战略集合。
通过对数据仓库中数据的分析,可以帮助企业,改进业务流程,控制成本、提高产品质量等。
数据仓库,并不是数据的最终目的地,而是为了数据最终的目的地做好准备。这些准备包括对数据的:清洗,转义,分类,重组,合并,拆分,统计等等。
日志数据:通过sdk(soft development kit)做数据采集(js采集,java代码),所谓sdk就是我们开发的一些工具,采集用户和前端交互的数据(点赞、浏览、点击、广告、错误日志),采集方式是通过监控事件的方式,采集之后对数据进行加密,压缩,转码,采用实时发送,定时发送,还可能根据网络情况发送,需要发送给后端日志服务器。
业务数据:记录在数据库中的数据,这些数据基于事务机制记录每个业务过程的数据。
去企业,大部分情况是做报表(分析各种指标),画像,推荐,机器学习都需要掌握算法,风控:风险控制,金融行业-->银行,最重要的是看你有没有还款能力。
大数据里面做的各种菜,当成我们大数据的各种产品,数仓的作用就是相当于这个牛逼的惨痛的后厨,采购各种原材料,分类和加工,买回来的菜清洗一下,小虫,农药清理干净

穿插两个面试题:

1.数据来源? 
日志采集系统,写日志,写入到文件里面去,xxx.long,js前端埋点,前端工程师写一些js代码,js代码会捕捉各种事件(各种行为),把这些事件按照对应的数据格式以一条条日志的方式,发送给后台。sdk,java对面,主要用在收集app上..
业务系统的数据:写入到mysql的数据
2.数据仓库为什么业务支撑?
几乎所有做大数据的公司都会做报表。用户画像,精准化下营销,推荐系统的基础,最重要的工作就是给用户打标签,京东刻画用户标签有5000多个

标签分为

人口属性标签,年龄,学历,家庭信息.... 统计类,某个人每天上网时长。时间分布等等
挖掘类标签:-->算法,有没有钱(有钱人,普通人,屌丝,薅羊毛) 
风控:判断出你这个人有没有信用,会不会违约,会不会按时还钱

第二章 项目需求及架构设计

2.1项目需求分析

项目需求
用户行为数据采集平台搭建
业务数据采集平台搭建
数据仓库维度建模
分析,用户、流量、会员、商品、销售、地区、活动等电商核心主题,统计的报表指标近100 个。完全对比中型公司
采用即席查询工具,随机进行指标分析
对集群性能进行监控,发生异常需要报警。
元数据管理
质量监控
二、思考题
项目技术如何选型?
我们在进行技术选项的时候,尽量选择成熟的技术,没有必须追求最新的技术。主要考虑的因素有:数据量的大小、业务需求、行业内经验、技术成熟度、开发维护成本、总成本预算。

系统数据流程设计

我们这里可以使用kafka也可以使用多个flume。那我们为什么要使用kafka呢?
1.我们的业务有实时的业务,spark可以和flume做整合的
2.削峰平谷,处理一些高并发的场景
3.解耦,适合这种多场景对数据的多次使用。
埋点的数据是如何被采集的?
采集的都是用户的行为,写一些代码(js,sdk),往后台发送,实时发送,每隔一段时间发送一个数据包(加密、压缩、转码,一次性发送多条)
框架版本如何选型?
版本分为 apache、cdh、hdp

2020年2月,CDH不再免费,Cloudera把cdh和hdp整合为cdp,针对节点收费,收费的标准是一万美元一个节点,这个就会使后续越来越多的公司使用apache的版本。hdp用的非常少,稳定性差,并不建议使用
具体版本型号

hive的版本是2.3,后续我们需要数据的质量监控。不建议使用最新版本问题。因为最新版本有一些未知的坑。兼容性。一般来说,选比较新的常用版本。
服务器使用物理机还是云主机?
一般来说,用云主机的好处是,运维方便,不需要请运维,使用起来可以根据自己的需求来定,公司起步阶段,对服务器这一块的数据量,访问都比较少,需求有限,选一个低配置的。数据不会丢失,安全性会好一点。
但是,一般大厂都睡考虑自己搞物理服务器。中小型公司,会更喜欢云主机。但是一些不差钱的金融公司,为了方便,会选择云主机,大规模的买。

物理机又分为哪几种呢?
物理机:分为刀片服务器、塔式服务器,其实本质就是电脑主机,一直得通电,一直得运行,稳定性要求特别好,扩展性也特别好,方便我们加配置(多个cpu,多块硬盘,多个内存条),配置和我们得平常用的有点不一样,i3,i5,i7,i9
例:华为2288H V5服务器主机 25盘 2U机架式,2颗金牌5120 28核 2.2|900W2 128G内存|181.2T 10K|SR430,需要把这些服务器放在机房,需要人管理这些服务器,这样的人叫运维。
中国的互联网企业,有两个流派,分为阿里流和腾讯流
京东–腾讯系、拼多多–腾讯系、美团–腾讯系
优酷–阿里系、微博–阿里系
如何确认集群规模?
根据日志文件的大小(一般每条日志的大小在0.5k-2k)。假设,每台服务器8T磁盘,128G内存。现在我们这个app每天日活跃用户100万,每人一天平均100条:100万100条=1亿条。然后假设每条日志1k左右,每天1一条的话:100000000 /1024/1024=约100G,半年内不扩容服务器来算:100G180天=约18T 。然后假设保存3副本:18T*3=54T。预留20%~30%Buf=54T/0.7=77T。这时候就需要10个服务器
如果考虑数仓分层?数据采用压缩?需要重新再计算
数仓分层是数据仓库设计中十分重要的一个环节,优秀的分层设计能够让整个数据体系更容 易理解和使用
对于日志文件而言,每条日志大小在0.5k-2k之间,大小和数据的字段多少有关,取平均1k比较合理。数据仓库建模,数据分层,备份,数据量会增加2-3倍,如果这些数据还考虑一些压缩的格式,就会把数据存储的空间变小,变成之前的1/5-1/20。性能和成本之间找一个平衡。业务数据占日志的占比一般来说2-10%

第二章 项目需求及架构设计

2.1项目需求分析

项目需求

用户行为数据采集平台搭建
业务数据采集平台搭建
数据仓库维度建模分析,用户、流量、会员、商品、销售、地区、活动等电商核心主题,统计的报表指标近100个。完全对比中型公司采用即席查询工具,随机进行指标分析对集群性能进行监控,发生异常需要报警。

二、思考题
项目技术如何选型?
我们在进行技术选项的时候,尽量选择成熟的技术,没有必须追求最新的技术。主要考虑的因素有:数据量的大小、业务需求、行业内经验、技术成熟度、开发维护成本、总成本预算。

系统数据流程设计

我们这里可以使用kafka也可以使用多个flume。那我们为什么要使用kafka呢?
1.我们的业务有实时的业务,spark可以和flume做整合的
2.削峰平谷,处理一些高并发的场景
3.解耦,适合这种多场景对数据的多次使用。
埋点的数据是如何被采集的?
采集的都是用户的行为,写一些代码(js,sdk),往后台发送,实时发送,每隔一段时间发送一个数据包(加密、压缩、转码,一次性发送多条)
框架版本如何选型?
版本分为 apache、cdh、hdp

2020年2月,CDH不再免费,Cloudera把cdh和hdp整合为cdp,针对节点收费,收费的标准是一万美元一个节点,这个就会使后续越来越多的公司使用apache的版本。hdp用的非常少,稳定性差,并不建议使用
具体版本型号

hive的版本是2.3,后续我们需要数据的质量监控。不建议使用最新版本问题。因为最新版本有一些未知的坑。兼容性。一般来说,选比较新的常用版本。
服务器使用物理机还是云主机?
一般来说,用云主机的好处是,运维方便,不需要请运维,使用起来可以根据自己的需求来定,公司起步阶段,对服务器这一块的数据量,访问都比较少,需求有限,选一个低配置的。数据不会丢失,安全性会好一点。
但是,一般大厂都睡考虑自己搞物理服务器。中小型公司,会更喜欢云主机。但是一些不差钱的金融公司,为了方便,会选择云主机,大规模的买。

物理机又分为哪几种呢?
物理机:分为刀片服务器、塔式服务器,其实本质就是电脑主机,一直得通电,一直得运行,稳定性要求特别好,扩展性也特别好,方便我们加配置(多个cpu,多块硬盘,多个内存条),配置和我们得平常用的有点不一样,i3,i5,i7,i9
例:华为2288H V5服务器主机 25盘 2U机架式,2颗金牌5120 28核2.2|900W2128G内存|181.2T 10K|SR430,需要把这些服务器放在机房,需要人管理这些服务器,这样的人叫运维。
中国的互联网企业,有两个流派,分为阿里流和腾讯流
京东–腾讯系、拼多多–腾讯系、美团–腾讯系
优酷–阿里系、微博–阿里系

2.2集群资源规划设计

如何确认集群规模?
根据日志文件的大小(一般每条日志的大小在0.5k-2k)。假设,每台服务器8T磁盘,128G内存。现在我们这个app每天日活跃用户100万,每人一天平均100条:100万100条=1亿条。然后假设每条日志1k左右,每天1一条的话:100000000/1024/1024=约100G,半年内不扩容服务器来算:100G180天=约18T 。然后假设保存3副本:18T*3=54T。预留20%~30%Buf=54T/0.7=77T。这时候就需要10个服务器。

如果考虑数仓分层?数据采用压缩?需要重新再计算
数仓分层是数据仓库设计中十分重要的一个环节,优秀的分层设计能够让整个数据体系更容易理解和使用。对于日志文件而言,每条日志大小在0.5k-2k之间,大小和数据的字段多少有关,取平均1k比较合理。数据仓库建模,数据分层,备份,数据量会增加2-3倍,如果这些数据还考虑一些压缩的格式,就会把数据存储的空间变小,变成之前的1/5-1/20。性能和成本之间找一个平衡。业务数据占日志的占比一般来说2-10%

2.2.1测试集群服务器规划

注意事项:
1.资源不能太集中,尽量平均
2.有些框架配置HA,要注意有些进程需要分开配置。
3.内存和cpu给进程多的节点
4.相互通信多的框架,尽量部署在相同的节点
测试服务器的规格要么就说和生产服务器的规格一样,要么就减半。
测试
服务名称 子服务 服务器bigdata02 服务器bigdata03 服务器bigdata04
HDFS NameNode √
DataNode √ √ √
SecondaryNameNode √
Yarn NodeManager √ √ √
Resourcemanager √
Zookeeper Zookeeper Server √ √ √
Flume(采集日志) Flume √ √
Kafka Kafka √ √ √
Flume(消费Kafka) Flume √
Hive Hive √
MySQL MySQL √
Sqoop Sqoop √
Presto Coordinator √
Worker √ √
Azkaban AzkabanWebServer √
AzkabanExecutorServer √
Druid Druid √ √ √
Kylin √
Hbase HMaster √
HRegionServer √ √ √
Superset √
Atlas √
Solr Jar √
Griffin √
服务数总计 19 9 9
生产
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 spark spark spark spark spark
ES ES

  • 服务尽量的平均,内存,cpu消耗大的不要太聚集
  • 高可用的配置的分开
  • 互相有频繁通信的得分开
    人员配置参考(面试问题:旁敲侧击的问你到底做过没有 。你们的大概规模,数据量)
    1.整体架构
    属于研发部/技术部/数据部/基础平台部。我们属于大数据组,其他还有后端项目组,前端组,移动开发、测试组、ui组等等。其他的还有产品部、运营部、人事部、财务部、行政部、市场部、销售部等。
    2.人员配置参考
    小型公司(3人左右):组长1人,剩余组员没有明确分工,并且可能兼顾javaEE和前端
    中小型公司(3到6人左右):组长1人,离线2人左右,实时1人左右(离线一般多于实时),组长兼顾和javaee、前端。
    中型公司(5-10人左右):组长1人,离线(3-5人左右,离线处理、数仓),实时2人左右,组长和技术大牛兼顾javaee、前端。
    中大型公司(10-20人左右):组长1人,离线5-10人(离线处理、数仓),实时5人左右,javaee1人左右(负责对接javaee业务),前端1人(有或者没有人单独负责前端)。发展比较好的公司可能把大数据部门已经细化拆分,分为多个大数据组,分别负责不同的业务)
    写项目的时候,首先选公司,查一下这个公司的所有信息,包括这个公司做什么行业的,具体业务是什么,靠什么赚钱,目前的发展状况,公司的地址(精确到哪个城市,哪个区,哪条街哪栋楼,哪一层,几号),你住在哪里,坐几路公交车

第三章 数据生成模块

数据是通过埋点得方式获取得,一般来说,都是用一些sdk(数据采集用户的行为程序,js埋点,Java埋点)加密压缩转码发给nginx服务器,服务器后端回做解码,解压,解密。

3.1日志发送的时机

有启动的时候,退出的时候,定时发送,还有可能根据网络情况发送
接下来需要根据自己的情况来模拟数据。
示例日志
示例日志(服务器时间戳 | 日志):
时间戳——> 数据从客户端发到服务器,服务器接受数据的时间,如果这个时间落后发送的时间太多,说明网络有问题.
1540934156385|{
“ap”: “gmall”,
“cm”: {
“uid”: “1234”,
“vc”: “2”,
“vn”: “1.0”,
“la”: “EN”,
“sr”: “”,
“os”: “7.1.1”,
“ar”: “CN”,
“md”: “BBB100-1”,
“ba”: “blackberry”,
“sv”: “V2.2.1”,
“g”: “[email protected]”,
“hw”: “1620x1080”,
“t”: “1506047606608”,
“nw”: “WIFI”,
“ln”: 0
},
“et”: [
{
“ett”: “1506047605364”, //客户端事件产生时间
“en”: “display”, //事件名称
“kv”: { //事件结果,以key-value形式自行定义
“goodsid”: “236”,
“action”: “1”,
“extend1”: “1”,
“place”: “2”,
“category”: “75”
}
},{
“ett”: “1552352626835”,
“en”: “active_background”,
“kv”: {
“active_source”: “1”
}
}
]
}
}

你可能感兴趣的:(大数据,数据仓库)