数据仓库

1. 为企业决策提供数据支撑、存储、计算、分析。
2. 分类：业务数据、用户行为数据、爬虫数据。

数据输入：用户行为数据、业务数据、爬虫数据等--------->>>数据分析：对数据进行备份、聚合、统计------------->>>数据输出：报表系统、用户画像（打标签：统计类标签、规则类标签、机器学习标签）、推荐系统（需要构建推荐模型）、机器学习。

1. 用户行为数据采集平台
2. 业务数据采集平台
3. 数据仓库维度建模（核心）
4. 分析需求主题，统计报表指标
5. 采用即席查询工具，随时进行指标分析
6. 对集群性能进行监控，发生异常要报警（电话，短信，邮件，钉钉等）
7. 元数据管理（将所有数据的执行过程和依赖关系在图形化界面上展示出来）
8. 数据质量监控（监控数据的异常变化，对于计算错误或异常的数据要监控）
9. 权限管理
项目技术选型、框架版本、服务器选型（物理机或者云主机）、确认集群规模。

1. 用户行为数据，通过flume采集数据存储在hive中。日志文件
为什么用flume不用logstash或者Java程序直接采集？
答：开源免费，大厂使用广泛，有成熟的案例和踩坑经验，传输效率非常高。
2. 业务数据，通过sqoop采集到hive。业务数据存储在mysql中，通过sqoop采集到hive中。
通过jdbc组件也可以直接连mysql采集数据，也可以通过hadoop的inputformat自定义组件，连接mysql数据库，采集业务数据。
其实sqoop底层就是hadoop，4个map采集。
3. 分层：ods备份-dwd清洗-dws聚合-dwt聚合-ads统计。一般分为四层，还有一层dim维度层。ods存放原始数据，dwd对数据进行清洗，dws和dwt对数据进行join形成大的宽表，这样每次统计不用join太多表，dws可以按照天来join，dwt是个累计的宽表，可以保存很多年的，ads层就是报表，最终统计结果。
4. 代码运行：hive on spark 
5. 数据采集：DS调度、flume、kafka（削峰）、sqoop、logstash（ELK数据分析）、dataX。（dataX和sqoop都可以采集）
6. 数据存储：mysql、hdfs、HBASE、Redis、MongoDB。
7. 数据计算：hive、tez、spark、flink
8. 数据查询：presto、kylin、impala、druid、clickhouse、Doris
9. 数据可视化：echarts、superset、quickBI、dataV
10. 任务调度：azkaban、oozie、DS、airflow（Python脚本）
11. 集群监控：zabbix（离线）grafana、prometheus（实时）
12. 元数据管理：Atlas
13. 权限管理：ranger、sentry

sqoop只能用来采集mysql，离线采集，不如dataX。
flume实时采集，用来采集日志。

1. 为什么要分层？
把复杂问题简单化
减少重复开发
隔离原始数据
2. 数据仓库与数据集市区别？
数据集市是一种微型的数据仓库，是部门级别的。数据仓库是企业级的，为整个企业的运行提供决策支持手段。
3. 命名规范
表命名：ods_,dim_,dwd_,dws_,dwt_,ads,tmp_;
脚本命名:数据源_to_目标_db/log.sh
4. 范式概念

函数依赖：完全函数依赖（a完全依赖于b和c），部分函数依赖（a部分依赖于b和c和d），传递函数依赖（a依赖于b和c，b和c依赖于d，a传递依赖于d）。
第一范式：1nf，属性不可切割。1nf是所有关系型数据库的最基本要求，如果数据表的设计不符合这个要求，那么操作一定是不成功过的。
第二范式：2nf，不能存在非主键字段部分依赖于主键字段。
第三范式：3nf，不能存在传递函数依赖。
5. 建模概念：
关系建模和维度建模是两种数据仓库的建模技术。现在普遍采用维度建模。关系建模主要应用在业务系统的业务数据库中。
数据建模必须遵循一定的规则，在关系建模中，这种规则就是范式。采用范式，可以降低数据的冗余性。
关系建模：将复杂的数据抽象为两个概念--关系和实体，并使用规范化的方式（三范式）表示出来，模型较为松散、零碎，物理表数量较多。严格遵循三范式，数据冗余低，一致性好，大数据查询效率低。
维度建模：以数据分析作为出发点，不遵循三范式，故数据存在一定的冗余。维度模型面向业务，将业务用维度表和事实表呈现出来。表结构简单，查询效率高。
维度表：一般是对事实的描述信息，每一张维表对应现实世界中的一个对象或者概念。例如：用户、商品、地区、日期等。
维度表特征：
  维度表的范围很宽（具有多个属性、列比较多），字段较多。
  跟事实表相比，行数相对较少，通常小于10万条。
  内容相对固定：编码表。维度表内容变化不会太频繁。
事实表：每行数据通常代表一个业务事件（下单、支付、退款、评价等）。事实这个术语表示的是业务事件的度量值（可统计次数、金额、个数等）。
事实表特征：
  非常大
  内容相对窄，列数很少。（主要是外检ID和度量值）
  经常发生变化，每天会新增加很多。
事务型事实表：以每个事务或者事件为单位，作为事实表中的一行数据。如一笔订单记录等。一旦事务被提交，事务表数据被插入，数据就不再进行更改，其更新方式为增量更新。
周期型快照事实表：不会保留所有数据，只保留固定时间间隔的数据，例如购物车操作，有加减商品随时都可能变化，但是我们更关心每天结束时里面有多少商品，方便我们统计。
累积型快照事实表：通常用于跟踪业务事实的变化。如快递的下单时间，揽货时间，签收时间，收货时间等，每个时间点需要跟踪，时间节点也不断增加。
总结：
一个事实表关联多个维度表。事实表主要包含两类字段，一类是维度表外键，一类是度量值。

在维度建模的基础上又分为三种模型：星型模型、雪花模型、星座模型。
DIM层和DWD层需要构建维度模型，一般采用星型模型，呈现的状态一般为星座模型。
维度建模一般按照四个步骤：选择业务过程-->声明粒度-->确认维度-->确认事实。
选择业务过程：
  根据业务需求挑选业务线，一条业务线对应一张事实表。
声明粒度：
  数据粒度指数据仓库的数据中保存数据的细化程度或者综合程度的级别。精确定义事实表中的一行数据表示什么，尽可能选最小粒度，以此应对各种各样的需求。
事实表和维度表的关联比较灵活，但是为了应对更复杂的业务需求，可以将能关联上的表尽量都关联上。