浅谈数据治理

NNXXFF

已于 2024-09-05 20:39:24 修改

阅读量1.1k

点赞数 24

文章标签：大数据 python spark

于 2024-09-05 20:38:29 首次发布

本文链接：https://blog.csdn.net/weixin_42868744/article/details/141940157

版权

数据质量管理

对数据进行质量检查、清洗和修复，保证数据的准确性、一致性和完整性。

代码侧校验

(1)数据量检查：看看自己跑的数据和之前的数据是否是一个数据量级，这样可以保证完整性了。不是的话，就很有可能脚本逻辑错误，或者数据压根没有进入到目标表，需要复盘脚本逻辑。下面代码的意思是如果返回就脚本就报错退出，一定要抛出返回值，不然调度系统捕获不到报错。

check_01 = "SELECT 1 FROM {schema}.table WHERE data_dt={data_dt}".format(data_dt=data_dt,schema_dst=schema_dst)
count_01 = sr.sparkSql(check_01).count()
logger.info('count : ' + str(count_01))
if count_01 == 0: sys.exit(40)

(2)重复值校验：因为Spark和Hive没有主键约束这一说，只有逻辑主键，没有物理主键。所以就得需要从代码侧将其校验出来，如果大于0，证明主键重复，直接退出报错，脚本逻辑有问题。

check_02 = "SELECT STATIS_DT,CUST_NO FROM {schema_dst}.table WHERE data_dt={data_dt} GROUP BY 1,2 HAVING count(1)>1".format(data_dt=data_dt,schema_dst=schema_dst)
count_02 = sr.sparkSql(check_02).count()
logger.info('CHONG FU : ' + str(count_02))
if count_02 > 0: sys.exit(44)

(3)删除分区数据：防止即将插入数据的目标表分区有多余的数据，需要先对其进行清空分区数据。

sql_01_drop = "DROP TABLE IF EXISTS {schema_tmp}.R_CMK_CUST_INCOM_PRE_MODEL_FCST_RES_tmp01".format(schema_tmp=schema_tmp)

上线后数据验证

我们跑完脚本后，往往需要验证脚本的一致性，由于存在上下游系统完全隔离，有些操作是代码侧不好标准化，比如要验证一大段逻辑。这里面建议从上游数据查好了，对应逻辑段和数据量结果在上线前就准备好，以便上线结束后，随时校验。

以下是确保数据一致性的经验之谈：

依赖作业先跑,且跑批数据一定要日期一致,防止重复跑批

确认DDL执行完成无误/回插数据完成无误

确认无主键重复/数据量不为0

确认明细符合字段要求/单位转换/小数位数/日期格式/无大量nu11/是否字段的

变更表除变更字段,其余所有字段是否与备份表MNIUS比对无差异

变更表数据量与备份表数据量是否一致的

新增表数据量与底层主表数据量、业务测试数据量是否一致, 每个字段/标签/绩效指标符合测试阶段与业务测试通过结果标准:包括但不限金额总值

抽取底层各表中明细数据,核验符合加工规则数据与目标表结果是否一致

元数据管理

做好数据字典的梳理

把自己项目组的表结构，字段值，数据类型，以及数据来源都整理到一个数据字典里，越详细越好。不能有误差。换句话说就是把模型的Mapping放到一个Excel里面，需要查表结构细节或则字段的取值逻辑的时候，直接能够Ctrl+F能够找得到才行。

集群内小文件检察

集群内小文件过多会严重影响效率

拿Hive举例

1.针对集群目录执行hdfs dfs –count –v –h /xxxx/xxx/xx/x，根据回显确认当前目录下文件数和大小，确定小文件情况。（此命令统计的大小为单副本文件大小）

例如：当前目录总大小5G，文件数上百万，此时即可认为此目录下小文件较多，然后和业务架构师或者项目经理去确认，这个有无必要留存。

2.其他格式表合并小文件

insert overwrite table tb_name [partition(p=xx)] select * from tb_name [where p=xx];
#注意，你需要给 hive 会话添加下面的配置来控制小文件合并的条件：
set hive.merge.mapfiles=true;
set hive.merge.mapredfiles=true;
set hive.merge.size.per.task=256000000;
set mapreduce.input.fileinputformat.split.maxsize=256000000;
set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;
set mapreduce.input.fileinputformat.split.minsize=1;
set hive.merge.smallfiles.avgsize=128000000;
set mapreduce.input.fileinputformat.split.minsize.per.node=128000000;
set mapreduce.input.fileinputformat.split.minsize.per.rack=128000000;
set hive.execution.engine=mr;
#如使用动态分区进行小文件合并，还需加如下俩参数
set hive.exec.dynamic.partition=true;
set hive.exec.dynamic.partition.mode=nonstrict;

数据安全管理

对数据进行安全保护，包括数据的访问控制、加密、备份和恢复等措施，以保证数据的安全性和可靠性。

例如大型企业的常见数据保护策略如下：

1.内网外网隔离：

个人电脑只有连接专用的VPN方可进入公司内网，其他情况无法进入内网，进入内网还需登录专有的云桌面账号才可进行作业。

2.权限管理：

不同属性的员工，对平台或者集群操作粒度不一样。比如网络侧员工能登录BMC管理页面，业务开发侧则登不了，防止开发同学误操作把网络搞崩。

3.硬件管理：

办公电脑插入U盘，应该遵循只进不出，防止数据丢失。

4.透明加密：

保证假如数据本体被盗取，也无法直接查看数据本身，只有在特定客户端才能查到数据真貌。拿Hive来说，比如数据存储方式不用textfile，因为可以直接看到数据本身。这种功能应该向厂商提需求，因为尽管用 Orc或者Parquet无法直接查看，但可以通过技术手段复原数据本身。

5.数据脱敏

个别数据及其敏感，应在开发环境内，将敏感字段（身份ID，金额等）应该在开发环境进行脱敏处理，再进行开发，如果敏感数据在验证过程中需要验正准确性，就需要去生产环境去验。

6.生产环境和开发环境隔离：

财大气粗的公司为了数据安全一般会搞四种环境

(1)测试环境用来开发脚本测试脚本连通性的，一般测试环境没有数据，随便折腾，搞坏了再修即可。

(2)验证环境里面有生产经过脱敏的数据进行跑数，已经接近准生产了。因为有真数据了，可以进行脚本调优处理了。

(3)生产环境开发脚本正式上线的环境，最高安全级别，里面都是真数据，所有操作必须100%确定好。

(4)容灾环境生产的备份，目的是防止生产环境遭受不可逆的物理损坏，如机房失火等。一般生产环境的脚本也得同时上传灾备环境一份，理想情况应该是生产环境和灾备环境完全一致才行。

数据集成管理

一个非常成熟的数据仓库应该包含下面几种组件/系统：

1.分布式存储框架：HDFS,Kafka 大数据的基石

2.分布式计算框架：Hive，Spark，Flink 计算框架，离线求稳定就Hive，对Hive效率不满意就Spark，实时Flink

3.资源调度框架：Yarn 十分重要，没有不行，因为能够全局看到我运行的脚本跑了多长时间，占用多少内存，以及这个任务该不该杀掉。调度策略因资源而定，财大气粗就公平调度，想省资源就容量调度，根据项目组划分好队列，以及资源倾斜(就是说哪个项目组体量大，就多给一些资源百分比)。

4.调度系统：DolphinScheduler，Azkaban，或者自研调度系统。用过Azkaban，界面用着难受，尤其树状图，是垂直的，很不友好。

5.源业务系统: 各种TP数据库Oracle，Mysql 存储源业务数据的地方，一般都是行存的TP业务。

6.抽取工具: DataX，Flume 从源业务系统抽取到ODS层。

7.列存搜索引擎: Elasticsearch，ClickHouse这种，因为个别业务需要检索长字符串内的短字符串，而且这种业务对实时性很高，常规数据库，或者计算框架根本做不到。

数据标准化管理

1.原则上不允许出现同名不同库的情况

2.使用 string 类型代替 date、varchar 等类型

3.使用 decimal 代替 double，以避免丢失精度

4.分区字段data_dt是8位日期格式“yyyyMMdd”，优先选择bigint类型而不是string类型

5.创建分区字段时，分区字段必须小写

6.任务名、库名、sql关键字大写，其余代码内容全部小写（不做严格要求）

7.表的存储格式看需求，如果经常切片查询就Parquet，Orc，听说Orc和Hive兼容性更好，压缩率略微高一些，但如果是Spark的话，就选Parquet，毕竟是Spark的默认，加上官方严选(因为是数仓，99%的业务都适合列存)。如果个别业务有TP场景，那么一定要行存textfile，不然一定会出现数据膨胀（本来10G的表，膨胀成100G甚至更多）的情况。

8.任务名、库名、sql关键字、函数名大写，其余代码内容全部小写（不做严格要求）

9.遇到 select、from、join、where、group by、having、order by、limit 等语义时，另起一行编写。千万不能小看脚本规范化，不然到二次开发的时候，会非常难受。

10.编写sql代码应具有缩进，按4个空格缩进（不做严格要求）

11.字段和表名应添加注释说明，同一代码文件中已做过注释的字段和表，可以不重复注释

12.多表 join 时，应该显式指明每个字段来自哪个表,也就是字段前面别名必须有，方便维护不说，不然容易报ambigous