数据平台建设

梦里梦外; 2022-12-27 09:05 152阅读 0赞

## 数据平台建设 ##

### 平台要解决的问题 ###

*  数据质量层次不齐
 *  数据交换和共享困难
 *  缺乏有效的管理机制
 *  存在数据安全隐患

### 平台架构要求的能力 ###

*  无数据模型的架构

> 很多时候数据处理都是在一个无模式或者非结构化或者半结构化的数据集上进行处理

*  近实时的数据采集

> 批量采集和实时采集

*  微批处理的能力
 *

### 基础设施的要求 ###

*  线性可扩展
 *  高吞吐量
 *  容错能力
 *  分布式数据处理

## 具体的平台化工具 ##

### 任务调度系统 ###

*  数据采集任务、数据同步任务、数据清洗任务、数据分析任务等；这些任务除了定时调度，还存在非常复杂的任务依赖关系，比如：数据分析任务必须等相应的数据采集任务完成后才能开始；数据同步任务需要等数据分析任务完成后才能开始；
 *  调度系统，更确切地说，作业调度系统（Job Scheduler）或者说工作流调度系统（workflow Scheduler）是任何一个稍微有点规模，不是简单玩玩的大数据开发平台都必不可少的重要组成部分。

> 除了Crontab，Quartz这类偏单机的定时调度程序／库。开源的分布式作业调度系统也有很多，比较知名的比如：oozie，azkaban，chronos，zeus等等，此外，还有包括阿里的TBSchedule，SchedulerX，腾讯的Lhotse，当当的elastic-job，唯品会的Saturn等等

> 可以说，几乎每家稍微有点规模的数据平台团队，都会有自己的调度系统实现方案，要不然自研，要不然在开源的基础上进行一些封装和改造（比如很多公司采取了封装oozie的方式）。

> 资源调度系统，它的工作重点是底层物理资源的分配管理，目标是最大化的利用集群机器的CPU／磁盘／网络等硬件资源，所调配和处理的往往是与业务逻辑没有直接关联的通用的程序进程这样的对象。

> 作业调度系统有时也会考虑负载均衡问题，但保证负载均衡更多的是为了系统自身的健壮性，而资源的合理利用，作为一个可以优化的点，往往依托底层的资源调度系统来实现。

> 一个成熟易用，便于管理和维护的作业调度系统，需要和大量的周边组件对接，不仅包括各种存储计算框架，还可要处理或使用到包括：血缘管理，权限控制，负载流控，监控报警，质量分析等各种服务或事务。这些事务环节，在每家公司往往都有自己的解决方案，所以作业调度系统所处的整体外部环境，千差万别，再加上各公司各种业务流程的定制化需求进一步加大了环境的差异性，所以，调度系统很难做到既能灵活通用的适配广大用户的各种需求，又不落到太过晦涩难用的地步。

#### 调度类型 ####

##### 依赖调度 #####

*  父依赖执行完开始执行

##### 时间调度 #####

*  到达特定的时间点开始执行

#### 依赖推荐 ####

*  随着数仓的建设，表越来越多，依赖推荐尤为重要，自动依赖推荐可以避免少添加依赖的数据错误(数据错误任务状态不会错误，不容易发现，只能通过数据质量监控平台或者业务方反馈)、多添加依赖的无用等待，以及循环依赖的致命错误

#### 基线控制 ####

> 大数据离线计算通常作业执行时间比较长，如果不能及时发现问题，重跑需要几个小时，显然来不及

##### 统一管理 #####

*  统一管理作业的完成时间、优先级、告警策略、保证数据加工按时完成，调度模块需要根据重要性、优先级、最短执行时间策略进行动态资源调整，让资源利用率最大化，损失最小化

##### 算法预测和调控 #####

*  算法对正常数据进行训练，当作业无法正正常产出和动态调整资源无法完成的时候，调度中心会通知运维和值班人员进行接入处理。

#### 代码校验 ####

*  设计了代码上线时候的语法检测，并且设计了试运行和线上以及测试三种运行模式，上线的时候必须有试运行成功的记录

#### 环境隔离 ####

*  通过运行模式实现了测试和试运行以及线上形成了测试环境、uat环境、线上三种环境

#### 多引擎支持 ####

*  支持自定义脚本，hive,sprk,python，等多种引擎

#### 功能 ####

*  用户可以在管控后台中，自主的对拥有权限的作业／任务进行管理，包括添加，删除，修改，重跑等。对没有权限的作业，只能检索信息。
 *  支持当日任务计划和执行流水的检索，支持周期作业信息的检索，包括作业概况，历史运行流水，**运行日志，变更记录，依赖关系树查询等**。
 *  支持作业失败自动重试，可以设置**自动重试次数，重试间隔**等
 *  支持**历史任务独立重刷或按照依赖关系重刷后续整条作业链路**
 *  允许**设置作业生命周期，可以临时禁止或启用一个周期作业**
 *  支持任务**失败报警，超时报警，到达指定时间未执行报警等异常情况的报警监控**
 *  支持动态按应用／业务／**优先级等维度调整作业执行的并发度  
    调度时间和数据时间的分离**

> 支持灰度功能，允许按特定条件筛选作业按照特定的策略灰度执;根据血缘信息，自动建立作业依赖关系;任务日志分析，自动识别错误原因和类型

### 元数据管理系统(元数据治理) ###

#### 数据安全 ####

##### 数据安全——权限 #####

*  核心数据的权限管理

##### 数据安全——脱敏 #####

*  数据脱敏

#### 血缘关系 ####

#### 数据生命周期管理 ####

#### 数仓的治理规范的落地 ####

*  建表的权限
 *  命名是否规则

### 数据质量监控平台 ###

> 随着大数据时代的带来，数据的应用也日趋繁茂，越来越多的应用和服务都基于数据而建立，数据的重要性不言而喻。而且，数据质量是数据分析和数据挖掘结论有效性和准确性的基础，也是这一切的数据驱动决策的前提！如何保障数据质量，确保数据可用性是每一位数据人都不可忽略的重要环节。

*  完整性、准确性、一致性和及时性  
    ![image-20201205191525265][]

![image-20201205191545457][]

#### 完整性 ####

*  完整性是指数据的记录和信息是否完整，是否存在缺失的情况。数据的缺失主要包括记录的缺失和记录中某个字段信息的缺失，两者都会造成统计结果不准确，所以说**完整性是数据质量最基础的保障**
 *  考虑两个方面：一是，数据条数是否少了，二是，某些字段的取值是否缺失。完整性的监控，多出现在日志级别的监控上，一般会在数据接入的时候来做数据完整性校验。

##### 数据同步工具故障 #####

##### 数据被归档 #####

#### 准确性 ####

*  准确性是指**数据中记录的信息和数据是否准确，是否存在异常或者错误的信息**。
 *  直观来讲就是看数据是否上准确的。一般准确性的监控多集中在对业务结果数据的监控，比如**每日的活跃、收入等数据是否正常**
 *  常见的度量规则，空值检测、重复值检测、相关性检测、波动性检测、阈值检测、业务逻辑规则检测(非常重要)

#### 一致性 ####

*  一致性是指同一指标在不同地方的结果是否一致
 *  数据不一致的情况，多出现在数据系统达到一定的复杂度后，同一指标会在多处进行计算，由于计算口径或者开发人员的不同，容易造成同一指标出现的不同的结果。

#### 及时性 ####

*  在确保数据的完整性、准确性和一致性后，接下来就要保障数据能够及时产出，这样才能体现数据的价值
 *  及时性很容易理解，主要就是数据计算出来的速度是否够快，这点在数据质量监控中可以体现在监控结果数据数据是否在指定时间点前计算完成。
 *  主要随着数据规模的变化，导致边界问题对数据的及时性的影响越来越大(集群故障、网络故障、流量激增)

> 其实主要是数据源的监控、数据指标的监控、数据表的监控、高级一点的会涉及到全链路的监控

#### 监控平台设计思路 ####

数据：主要是需要被数据质量监控到的数据，数据可能存放在不同的存储引擎中，比如Hive、PG、ES等。
    
    规则：是指如何设计发现异常的规则，一般而言主要是数值的异常和环比等异常监控方式。也会有一些通过算法来发掘异常数据的方法。
    
    告警：告警是指出发告警的动作，这里可以通过微信消息、电话、短信或者是微信小程序的方式来触发告警内容。
    
    反馈：这里需要特别注意，反馈是指对告警内容的反馈，比如说收到的告警的内容，那么负责人要来回应这个告警消息是否是真的异常，是否需要忽略该异常，是否已经处理了该异常。有了反馈的机制，整个数据质量监控才容易形成闭环。更能体现业务价值。

![image-20201205191417368][]

*  问题:告警信息太多了,容易被忽略,主要是思路是提高告警的准确率，避免无用的告警

> 多使用机器学习算法的方式来发现异常点，比如：异常森林。

> 加入反馈机制，如果业务负责人认为该告警是正常的，就打上正常的tag，后续告警规则根据反馈进行优化。

> 加入屏蔽功能，屏蔽不感兴趣的告警。

### 数据同步平台 ###

*  主要有增量同步、全量同步、基于binlog 的实时同步，不论哪种方式到最后都涉及到数据更新合并的问题
 *  由于数据湖的发展，可能会改变基于binlog 的同步方式(离线——(kafka/hbase),实时——hbase)
 *  这个平台也很重要，因为这是一切的数据来源，而且随着业务的发展，要对接各种各样的数据源，数据同步平台的稳定与准确是一切的基础保障

#### 数据同步方式(工具) ####

##### 数据库直连同步 #####

\-sqoop

###### 数据库文件同步 ######

*  自定义脚本

> 会遇到两个问题，一个是网络波动可能会丢包，另一个是源文件比较大需要进行压缩传输。因而通常在传输数据文件的同时，会上传一个校验文件，检测数据量、文件大小等信息，以保证数据同步的准确性

##### 数据库日志解析同步 #####

*  maxwell、cancel

> 大多数主流数据库都可以通过日志文件的方式进行系统的恢复，并且由于日志文件的信息记录非常完整，格式解析也很稳定，因而完全可以通过解析数据库日志文件来获得发生变更的数据，再更新离线系统以最大提升效率

#### 数据更新 ####

*  数据库日志解析实现了**准实时同步的能力，对业务系统的影响也很小**，因而广泛的应用在了从业务系统到数据仓库的增量数据同步应用之中。值得注意的是，由于数据仓库对于更新操作支持比较差，通常会采用先删除、再插入的方式来模拟更新操作
 *  主要实现方式有两种，一种是通过join 的方式，另外一种是row\_number()的方式

> 数据延迟、处理数据量较大及数据漂移，因而中间系统的建设也需要进行一定的编码开发，以消除数据不一致的情况

### 数据资产服务平台 ###

*  数据资产的定义是由企业拥有或者控制的，能够为企业未来带来经济利益的，以物理或者电子方式记录的数据资源，如文件资料或者数字资料
 *  对外提供数据支持，直接服务于各个业务线已经公司的数据分析师，只有业务能够读懂能够理解的数据才叫数据资产

#### 数据分析平台(adhoc) ####

*  相对于adhoc 而言提供了可视化的功能
 *  zeeplin
 *  superset
 *  adhoc(自研)

#### 接口服务(数据资产服务平台) ####

*  提供sql 的方式进行接口配置，对接口进行统一管理，安全、性能、稳定性、生命周期、监控
 *  充当数据的提供方，报表数据、计算指标、明细数据、用户画像数据

#### 报表服务(数据资产服务平台) ####

*  BI 工具，支持报表和 Dashboard
 *  需要接口服务的接口(其实也可以直接采用sql 配置的方式)

### 实时数仓 ###

*  资源层面——所有调度任务只能在业务闲时（凌晨）集中启动，集群压力大，耗时越来越长；
 *  业务层面——数据按T+1更新，延迟高，数据时效价值打折扣，无法精细化运营与及时感知异常。

> 实时数仓即离线数仓的时效性改进方案，从原本的小时/天级别做到秒/分钟级别。

> 底层设计变动的同时，需要尽力保证平滑迁移，不影响用户（分析人员）之前的使用习惯

#### 指导思想：Kappa架构 ####

#### 计算引擎 ####

*  批流一体化——能同时进行实时和离线的操作
 *  提供统一易用的SQL interface——方便开发人员和分析人员

#### 底层（事实数据）存储引擎 ####

> 可靠存储——有一定持久化能力，高可用，支持数据重放。

*  kafka

#### 实时平台 ####

[image-20201205191525265]: /images/20221120/d6509e1401ed4a7990f1a587903019d9.png
[image-20201205191545457]: /images/20221120/a94165c2f2414536901440fa05095586.png
[image-20201205191417368]: https://img-blog.csdnimg.cn/img_convert/0187d24b6ea8369b733c97205a6faa1e.png