Smart Community(1)之设计规范

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

设计规范：

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

（一）数据埋点规范：

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

（1）确保灵活、高可扩展

（2）兼顾后续的处理、分析的方便性

（3）确保可跟踪、数据正确性

（4）业务数据打通

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

（6）确保性能、敏感数据安全性

（二）数仓层次设计规范：

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

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

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

（三）表命名规范：

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

能够合理的区分出表所描述的数据域、数据周期等。 命名规范设定：

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

订单相关数据表

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个空格代替