进入主页，点击右上角“设为星标”python
比别人更快接收好文章mysql
前言
技术是为业务服务的，业务是为公司创造价值的，离开业务的技术是无心义的web
业务介绍
公司属于金融科技ToC企业，针对不一样需求的用户开发不一样的产品，因此公司内部有不少条业务线，可是对于数据部门来讲，全部业务线的数据都是数据源。对数据的划分不仅是根据业务进行，而是结合数据的属性。sql
早期规划
以前开发是不一样业务线对应不一样的数据团队，每一个数据团队互不干扰，这种模式比较简单，只针对本身的业务线进行数仓建设及报表开发便可。shell
可是随着业务的发展，频繁迭代及跨部门的垂直业务单元愈来愈多，业务之间的出现耦合状况，这时再采用这种烟囱式开发就出现了问题：数据库
例如权限问题，公司对数据管理比较严格，不一样的数据开发组没有权限共享数据，须要其余业务线的数据权限须要上报审批，比较耽误时间；微信
还有重复开发问题，不一样业务线会出现相同的报表需求，若是每一个业务方都开发各自的报表，太浪费资源。架构
因此对于数据开发而言，须要对各个业务线的数据进行统一管理，因此就有了数据中台的出现。app
数据中台
我认为数据中台是根据每一个公司具体的业务需求而搭建的，不一样的业务，对中台的理解有所不一样。框架
公司内部开发的敏捷数据中台，主要从数据技术和计算能力的复用，到数据资产和数据服务的复用，数据中台以更大价值带宽，快准精让数据直接赋能业务。提供一个统一化的管理，打破数据孤岛，追溯数据血缘，实现自助化及高复用度。
以下所示：
以上解释比较抽象，咱们以实际项目开发来看下数据中台的便利性。
好比咱们以前作报表开发流程，首先是要数据采集，不一样的数据源经过sqoop等工具采集到大数据平台，而后进行数仓搭建，最后产出报表数据，放到可视化系统展现，最终把整个流程写成脚本放到调度平台进行自动化执行。
而有了数据中台以后就不须要那么繁琐，直接进行数仓搭建，产生报表便可，无需将精力过多放在数据源、可视化展现及调度。而且能够直观的查看数据血缘关系，计算表之间血缘。像下面图中，表之间的依赖关系很明确：
另外一点，数据中台的异构数据系统能够很是简单的进行关联查询，好比hive的表关联mysql的表。
可透明屏蔽异构数据系统异构交互方式，轻松实现跨异构数据系统透明混算。
跨异构数据系统原理是数据中台提供虚拟表到物理表之间的映射,终端用户无需关心数据的物理存放位置和底层数据源的特性，可直接操做数据，体验相似操做一个虚拟数据库。
数据中台还额外集成可视化展现，提供一站式数据可视化解决方案，支持JDBC数据源和CSV文件上传，支持基于数据模型拖拽智能生成可视化组件，大屏展现自适应不一样大小屏幕。
调度系统是公司内部自写集成到数据中台的，在编写完sql语句以后能够直接进行调度。
数仓建设
到这才真正到数仓建设，为何前面要占那么大篇幅去介绍公司业务及所使用的数据中台系统，由于下面的数仓建设是根据公司的业务发展及现有的数据中台进行，数仓的建设离不开公司的业务。
数仓建设核心思想：从设计、开发、部署和使用层面，避免重复建设和指标冗余建设，从而保障数据口径的规范和统一，最终实现数据资产全链路关联、提供标准数据输出以及创建统一的数据公共层。
有了核心思想，那怎么开始数仓建设，有句话说数仓建设者便是技术专家，也是大半个业务专家，因此采用的方式就是需求推进数据建设，而且由于数据中台，因此各业务知识体系比较集中，各业务数据再也不分散，加快了数仓建设速度。
数仓建设主要从两个方面进行，模型和规范，全部业务进行统一化
模型
全部业务采用统一的模型体系，从而下降研发成本，加强指标复用，而且能保证数据口径的统一
模型分层
结合公司业务，后期新增需求较多，因此分层不宜过多，而且须要清晰明确各层职责，要保证数据层的稳定又要屏蔽对下游影响，因此采用以下分层结构：
数据流向
遵循模型开发时分层结构，数据从 ods -> dw -> dm ->app 这样正向流动，能够防止因数据引用不规范而形成数据链路混乱及SLA时效难保障等问题，同时保证血缘关系简洁化，可以轻易追踪数据流向。
在开发时应避免如下状况出现：
数据引用链路不正确，如 ods -> dm ->app ，出现这种状况说明明细层没有彻底覆盖数据；如 ods -> dw -> app ，说明轻度汇总层主题划分未覆盖全 。减小跨层引用，才能提升中间表的复用度。理想的数仓模型设计应当具有：数据模型可复⽤，完善且规范。
尽可能避免一层的表生成当前层的表，如dw层表生成dw层表，这样会影响ETL效率。
禁止出现反向依赖，如dw表依赖于dm表。
规范
表命名规范
对于ods、dm、app层表名：类型_主题_表含义，如：dm_xxsh_user
对于dw层表名：类型_主题_维度_表含义，如：dw_xxsh_fact_users（事实表）、dw_xxsh_dim_city（维度表）
字段命名规范
构建词根，词根是维度和指标管理的基础，划分为普通词根与专有词根普通词根：描述事物的最小单元体，如：sex-性别。
专有词根：具有行业专属或公司内部规定的描述体，如：xxsh-公司内部对某个产品的称呼。
脚本命名规范
脚本名称：脚本类型.脚本功用.[库名].脚本名称，如 hive.hive.dm.dm_xxsh_users
脚本类型主要分为如下三类：常规Hive sql：hive
自定义shell脚本：sh
自定义Python脚本：python
脚本内容规范
#变量的定义要符合python的语法要求
#指定任务负责人
owner = "zhangsan@xxx.com"
#脚本存放目录/opt/xxx
#脚本名称 hive.hive.dm.dm_xxsh_users
#source用来标识上游依赖表，一个任务若是有多个上游表，都须要写进去
#(xxx_name 是须要改动的，其他不须要改)
source = {
"table_name": {
"db": "db_name",
"table": "table_name"
}
}
#如source，可是每一个任务target只有一张表
target = {
"db_table": {
"host": "hive",
"db": "db_name",
"table": "table_name"
}
}
#变量列表
#$now
#$now.date 经常使用，格式示例：2020-12-11
task = '''
写sql代码
'''
数据层具体实现
使用四张图说明每层的具体实现
数据源层ODS
数据源层主要将各个业务数据导入到大数据平台，做为业务数据的快照存储。
数据明细层DW
事实表中的每行对应一个度量，每行中的数据是一个特定级别的细节数据，称为粒度。维度建模的核心原则之一是同一事实表中的全部度量必须具备相同的粒度。这样能确保不会出现重复计算度量的问题。
维度表通常都是单一主键，少数是联合主键，注意维度表不要出现重复数据，不然和事实表关联会出现数据发散问题。
有时候每每不能肯定该列数据是事实属性仍是维度属性。记住最实用的事实就是数值类型和可加类事实。因此能够经过分析该列是不是一种包含多个值并做为计算的参与者的度量，这种状况下该列每每是事实；若是该列是对具体值的描述，是一个文本或常量，某一约束和行标识的参与者，此时该属性每每是维度属性。可是仍是要结合业务进行最终判断是维度仍是事实。
数据轻度汇总层DM
此层命名为轻汇总层，就表明这一层已经开始对数据进行汇总，可是不是彻底汇总，只是对相同粒度的数据进行关联汇总，不一样粒度可是有关系的数据也可进行汇总，此时须要将粒度经过聚合等操做进行统一。
数据应用层APP
数据应用层的表就是提供给用户使用的，数仓建设到此就接近尾声了，接下来就根据不一样的需求进行不一样的取数，如直接进行报表展现，或提供给数据分析的同事所需的数据，或其余的业务支撑。
总结
一张图总结下数据仓库的构建总体流程：
实际生产中注意事项
生产环境中操做不能像咱们本身测试时那样随意，一不当心均可能形成生产事故。因此每步操做都要十分当心，需全神贯注，管好大脑管住右手。
仅列出如下但不限于如下的注意事项：
请勿操做本身管理及受权表以外的其它库表；
未经受权，请勿操做生产环境中其余人的脚本及文件；
在修改生产环境脚本前，请务必自行备份到本地；
请确认本身的修改操做能迅速回滚；
生产环境中表名及字段等全部命名请遵循命名规则。
欢迎小伙伴们 点赞，在看，转发，收藏
本文分享自微信公众号 - 五分钟学大数据（gh_d4a7af3ecd50）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。