Smart Community(1)之设计规范

通过前面大数据开发相关知识的学习,准备做一个项目进行练习---我给他起了一个响亮的名字:基于HadoopHA的智慧社区服务平台

Smart Community(1)之设计规范_第1张图片

设计规范:

做一个项目之前肯定要先规定一些开发过程中的设计规范

(一)数据埋点规范:

数据埋点:是一种在软件、应用程序或网站中插入代码的技术,用于收集和跟踪用户行为和事件的数据。通过在关键位置插入代码片段(埋点),可以记录用户在应用程序中的操作和交互,以及其他有关系统和用户行为的信息。

(1)确保灵活、高可扩展

(2)兼顾后续的处理、分析的方便性

(3)确保可跟踪、数据正确性

(4)业务数据打通

(5)考虑不同C端产品特性与用户体验

(6)确保性能、敏感数据安全性

(二)数仓层次设计规范:

 ODS层:是原始数据层,是最接近数据源的一层,将数据源中的数据经过ETL之后装入ODS层,ODS的数据结构一般与数据来源保持一致,便于减少ETL工作的复杂性。

DWD层:是明细数据层,进行维度建模,该层的表结构和粒度与原始表保持一致,不过对ODS层数据进行清洗、维度退化、脱敏等,最终得到的数据是干净的,完整的,一致的数据。一般采用星型模型,呈现的状态一般为星座模型。 维度建模一般分为四步: 选择业务过程(先选择容易实现的)、 声明粒度(以最低的原子粒度处理数据)、 确认维度(考虑其他维度是否可以被属性化)、 确认事实(确认将那些事实---(指的是度量值,一些具体数据)放入事实表中)。

DWS层:服务数据层,基于DWD层的明细数据,按天轻度汇总成某一个主题域的服务数据,一般是宽表。DWS层统计各个主题对象的当天行为,以及一些业务明细数据,服务于DM(数据集市)层的某个主题。

(三)表命名规范:

英文在不是原意的情况下采用缩写,避免数字开头

Smart Community(1)之设计规范_第2张图片能够合理的区分出表所描述的数据域、数据周期等。 命名规范设定:

层次_数据域_修饰/描述_范围/周期

订单相关数据表

dwd层: d_ord_info_d

dws层: s_ord_st_d

维度表(dimension

用户维度: dim_user_d

商品缓慢渐变维表: dim_product_l

ods层

对于ods层表,最好能够区分数据来源,包括在来自什么系统、源数据名称。

eg 从业务系统全量采集订单(loan_order)数据到ods层 业务系统编码: buss 业务系统订单表: loan_order ods层表命名: o_buss_loan_order_d

(四)脚本命名规范:

•ETL脚本名称尽可能和所产出的表同名 •数据采集、 数据推送脚本尽可能标识数据去向

•ETL脚本若产生多个表, 采用对应的数据域和语义描述命名

•Jar包命名以实际的业务处理逻辑语义描述为主,调度任务命名同样尽量以产出表名命名。

eg:

订单ETL过程 从表o_buss_loan_order_d整理数据并且装载到dwd层表d_ord_info_d中。

ETL脚本命名: d_ord_info_d.sh

ETL任务命名: d_ord_info_d 一个ETL脚本产出多个表,比如从商品表中分离出商品维度、厂家维度。

ETL脚本命名: dim_product_mfrs_d.sh

ETL任务名称: dim_product_mfrs_d 采集数据到ods层的表o_buss_loan_order_d imp_o_buss_loan_order_d.sh

数据表dm_ord_trsfm_d推送到BI系统 exp_bi_dm_ord_trsm_d.sh

(五)开发规范:

数仓中MR程序尽可能统一输入参数、输出参数,单个jar程序的功能模块清晰,避免多种处理逻辑写入一个jar包。

每个ETL脚本尽可能产出一张数仓表,方便任务排查,同时也减少数仓表的耦合性。

ETL脚本格式、备注清晰,避免大范围、格式杂乱的脚本,合理利用临时表。

字段列对齐 关键字列对齐

禁止使用Tab, 全部使用4个空格代替

你可能感兴趣的:(bigdata,programe,设计规范)