广告-offline-warehouse-01-double_happy

1.MySQL:
	1.不同库下面的表 进行join 是 很难的  很苛刻 
为什么呢？
	1.sql语法是很简单 但是
		要保证：
			1.数据库A 数据库B
				1.字符集跟排序规则，需要保持一致
            2.字段的字符集排序规则 要一致
注意：
	所以条件很苛刻
	参考：
	https://blog.csdn.net/AS761379193/article/details/89298484

第一个阶段：	

2.那么怎么更好的解决这个问题？
	1. 把数据入到	 Hive

3.注意：
	问题：
		1.没有数仓设计的话 会导致
			1.重复开发 取数
		

所以：建立数仓 ->数仓架构设计很重要
	1.表名规范
	2.分层设计
	3.搭建各个主题域 的中间层

第二个阶段：
 问题：
 	1.当数据量上来之后：
 		1.数据抽取 十分耗时！！
 		     考虑：
 		     	1.最优数据抽取
 		     	2.存储策略
 	2.ETL任务脚本  在服务器上更新的问题 
 		就是pull 下来 更新了 忘记push 那么第二天的任务就出问题了
 		（这个问题 jekins可以+自己细心点）
 	3.调度问题：
 		1.依赖任务 我们现在是 使用 dolphinscheduler 贼好用

第三个阶段：
	问题：
		1.业务不断的发展 业务系统会变化   涉及到改造
		   可能改造的是 中间层 那么所有的表都可能都要变
		   只要跟中间层有关系的 都要变  你得一个一个搜索
				 解决：. 数据血缘 ：
				       有这个 改造就很轻松了 
		 
		 2.业务方会质疑你数据不准：
		 		1.数据口径不统一
		 		2.sql 数据取错了
		 		3.数据抽取挂了
		 		4.任务跑的慢  sql写的不规范
        	解决：
        		1.指标中心   (口径统一 、业务计算逻辑统一)
        		2.数据质量中心(DQC)
        		     1.监控数据条数    全量/增量  有一个范围
        		     2.对应指标 

       需求：
       	 1.多维分析的需求 
       	 	  这个就是 grouping sets  语法
       	 	  Hive来做多维分析 可以做 但是：
       	 	  	维度太多了 ！！！
      		解决：
      			kylin +BI系统
注意：   
      1. 数据血缘 +指标中心+数仓表信息(行数、数据量、字段) =>元数据中心
      2.数仓表信息(行数、数据量、字段)：就是数据字典
        注意：
        	1.数据血缘  就是  上下游表 改动时候用到
        	2.其他两个是非常有用的

！！！
	1.指标中心
	2.数据字典 
是为了BI业务多起来之后 新人加入团队 非常关键的一个建设！

注意：
	难道你要新人 去服务器上 desc 表 一个一个字段查？指标是通过问 ！来做吗？？


但是！！：
	大部分公司都是处于 这个阶段

第四阶段：
    问题：
    	1.集群稳定性
    	     监控集群 关键数据  做一个报表 =》图表展示
    	     eg：
    	     	离线任务平均运行时长