PA数据平台-第二章-系统改进设计思路

2019独角兽企业重金招聘Python工程师标准>>>

前言

能够正常生产的系统就是必然有其的适用性，本着这个理念，在对系统的可能的调整上，是考虑兼容以前的逻辑上，在局部做了微调和新增一些必要的模块，下图是调整后的系统结构。整个系统的调整原则：以元数据管理核心，构建一个从接入入口到推送出口的全流域数据管理平台，并以此驱动数据质量，驱动监控的迭代，最终达到，让用户能偶快速了解，流畅接入，快乐使用，轻松排错。

调整后系统

我们先来看下整体的系统架构图：
整体流程基本保持不变，只是对调整地方进行着重说明，

1. 在数据传输层面，从一个接入工具，拓展成一个受管理的接入系统传输集群
2. 将ETL（数据加工），从单机前置机解析，调整到hadoop集群内部，任务状态，处理过程由系统统一处理
3. 将ETL（数据加工），引入数据质量模块，分析结果数据，保留异常数据，并对异常数据进行分析处理，任务状态，处理过程由系统统一处理，提升数据质量。
4. 任务调度系统，任务调度职责过重，现将作业定义，任务启动调度，作业流程管理职责进行拆分，不再直接上传各种接入，传输，加工，合并的脚本。任务调度系统职责也只有任务启动调度这项职责。
5. 引入元数据与作业控制管理模块，元数据记录俩大部分的东西：系统的状态，执行信息以及数据流在全流域的状态，流转信息。作业控制管理，根据元数据动态生成作业，负责作业流程管理。
6. 在元数据构建基础上构建数据质量管理模块，根据系统状态，执行信息对系统进行监控，根据数据流在流域内部的流转信息对数据质量进行监控，同时可以根据既定的异常信息，或者新增的异常处理规则进行处理。

接入集群

随着业务量和接入公司的增多，目前的filesync存在一定的瓶颈，在上一章节已经说明。所以针对存在的情况，做了如下的一些设计：

设计目标

1. 不对现有系统产生冲击的情况下，将同步从一个工具提升成一个系统，增强对系统的管控，减少甚者是实现业务代码的零新增，所有的接入需求采用配置的方式。
2. 不对现有系统产生冲击的情况下，将具体的业务和物理上的存放方式进行分离解耦，保证系统的稳定性和横向扩展能力，突破吞吐量的瓶颈。
3. 结合元数据与作业控制系统，对接入进行监控，同时保证数据接入过程数据完整性

过程设计

1. 为了保证系统的稳定，不对现有的业务产生影响，还会持续保留filesync这个工具。但是为了对filesync服务器磁盘做更好的流量监控，管控磁盘负载，提升用户体验，减少使用中的问题。引入了元数据管理模块，用于记录各个filesync上任务配置信息。作业提交到集群不建议用户在手动写shell脚本提交到scheduler了，由生成同步作业的模块，统一读取元数据信息提交到集群，这在第四节元数据和作业控制会进行详细介绍。这样做的益处有主要俩点：1，能够管控filesync负载，对于即将接入的数据有更好评估，自动分配负载较低的路径给新接入的任务，避免临时接入的巨量数据导致数据同步延期;2，对用户的输入进行控制，filesync文档已经写得更详细了，但是由于没有输入校验导致用户使用起来问题频频。同时用户也不再维护shell脚本。
2. 为了应对日益增多的业务需求，引入分布式日志文件收集组件，将业务扩展和资源扩展目前紧耦合形式，进行分离，提供系统的容错能力，以及极为方便的横向扩展能力。在面临新产品数据接入，应对数据量的暴增的情况下，开发人员不需要为应对数据分盘，手动调整同步任务中的同步代码，引入新的机器即可。如果资源过剩，减少机器，也不需对数据进行手工上的挪动。传输完成后也不需要开发额外的脚本标注传输已经完成.具体架构见下图：
   在各台前置机上配置agent，agent采用file channel保证在传输过程中的数据完整性，在类似filesync服务器上配置collect，channel采用kafka channel，利用kafka高效的读写效率，和较为轻松的横向扩展能力。同时如果有多个集群不同类型(eg,hdfs,storm,rdmbs)的接入需求可以通过配置多个sink进行。为了实现运维上的方便所有配置信息不在本地存储，有zookeeper进行配置的统一管理，zookeeper定时读取元数据中的配置进行更新集群中的配置。即如果如果需要进行扩容，只需要在copy一台agent配置，然后在元数据将这台的纳入到集群中即可。

数据质量

数据质量的控制在整个生命周期内，即从数据接入入口，到数据推送出口，都属于管控范围内。其中能够直接决定数据质量高低，就是在清洗加工的ETL环节。所以在进行全流域管控的同时，对ETL阶段的数据质量做更为详细的设计。

数据ETL和ETL数据质量控制

设计目标

1. 最大化集群的特点提升解析工作效率以及应对异常的高容错，提升内化异常的能力，以及快速度恢复能力
2. 将解析工作纳入到整个流程的管理上，管控解析过程和结果，构建对异常数据的分析和再处理机制，对数据问题进行主动提早发现，对于业务已发现的问题也能够快速定位，提升数据质量。

过程设计

1. 将数据处理从单机的前置机，移到hadoop集群，充分利用集群的计算资源使用hive streaming或者map reduce，减少因单机磁盘问题，单机解析程序问题，磁盘传输慢对数据接入集群效率的影响，提升解析过程的容错能力。同时将异常数据和解析后的数据统一放在hdfs进行管理，方便后续的问题排查和异常数据的再清洗，提升ETL阶段的数据质量。
2. 数据质量的校验和提升 提升数据质量分为依据咱现有系统单源模式层，单源实例层，多源模式层这三个。在单源模式层，进行完整性校验。单源实例层，进行一致性性和完备性校验 eg：值域一致性，格式一致性，相似重复记录。多源模式进行命名冲突，结构冲突等校验。检验层次以及过程见下图
   
   作业控制程序读取作业的启动信息后，启动task，task读取数据质量校验规则，生成相应的校验代码，执行校验。如果校验不通过，抛出异常根据异常的类型，调用元数据的异常处理规则对异常进行处理，如果还是存在异常则放入异常明细日志中，将异常日志信息写入数据库中，方便开发人员的二次排查和问题归档。

全流域数据质量控制

如果要做到这点需要保证俩点，第一点：需要保证全流域的各节点的健康运行；第二点：清楚数据的转换脉络，对能起到质量控制，不可变因数进行统计比较收集和监控。eg：数据条数，关键属性一致性。需要对全流域，各节点的执行过程，执行状态，执行结果都能纳入统一的一个地方进行管理，现系统作业的执行信息被分散到各个角落，标记信息方式各异，只能通过事后结果监控，这种监控具有滞后性的，不确定性，查看难等问题。这也引入元数据与作业控制俩个模块的必要性。

元数据与作业控制

设计目标

1. 指导数据的集成接入，所有的同步任务都都必须在管理系统内注册，以便管理系统更好管控现有集成任务，对接新业务。eg，在新任务同步接入的时候，需要平衡每个磁盘流量，配置相应的磁盘路径
2. 定义的语义（schema）帮助用户理解数据仓库中的数据，需要记录每个表的定义信息，从表类型，用户，记录，记录类型。方便和帮助使用这个系统的人理解数据。
3. 保证数据质量，记录各个阶段的schema，流程，运行状态，记录掌控 各个数据来龙去脉；记录清理规则，异常处理规则，会让用户对数据处理的细节有更加直接认识，同时便捷发现数据存在的质量问题。
4. 提升对应新需求的适应能力，减少人员工作量。流程中记录的信息将不会被硬编码在代码中，也不应该被硬编码，都会以元数形式存储在数据库，作业控制系统通过读取数据库信息，控制整个工作流，数据流，能够较大提升系统应对变化需求的能力。

过程设计

作业控制组件和元数据俩个模块的产生，是为了把scheduler/oozie集成作业流程管理，作业定义以及任务调度的三个职责进行分离。原先所有的作业定义，以及运行的流程都是写零散的脚本上传到scheduler（oozie）由scheduler同一进行管理，产生的问题在第一章 弱架构性能已经完整描述了，解决问题有俩个层面，第一基本层面，规范打印日志，建立日志收集和分析机制。组件的沟通交流可以通过日志来进行，这时候算整个系统有了基本的较为明确全局沟通的机制。只是这种通过声明规范的方式，如果开发人员，漏写，或者不写关键的流程转化等信息，也会导致日志的不够全面，不能启到甚者是妨碍问题的排查，此外异构代码（java，shell业务代码），各种编码人员素质层次不齐的情况下光是靠说明规范，很难落实。所以需要第二个第二个基本层面，对于流程转换的关键节点，对于公共的逻辑转换，交给一个固定角色去管理。直接带来的改进就是，重复冗余的代码可以被抽象到这个角色中，流程控制这类非业务逻辑(eg,判断是否存在标记文件) 也可以抽象到角色中，如果是业务逻辑代码大多相似，也可以抽象到这个角色的下属子类，或者以某个形式聚合到到该角色中，eg同步任务，推送任务。如果需要深入定制细节的业务逻辑，则开放实现接口。综上这个角色是负责全流程的统一交互，统一的输入，统一的输出。这个角色就是作业管理（作业控制）模块。下图是组件交互图：

作业管理组件，将目前系统的俩类作业进行抽象，初步定义了俩个模块，同步作业生成模块，hadoop作业生成模块。基本的业务架构图见下图：

作业管理组件根据元数据库定义的输入格式，生成统一的运行逻辑，统一的日志打印逻辑，提交到集群。eg：推送，同步作业。对于需要较高灵活度，需要自定义业务细节，则只开发出mapreduce接口，hive执行接口。这样做考虑的出发点是，抽象共同的逻辑，减少重复代码，减少在业务无关人力以及时间投入，对于业务流程较为固定的可以开发成模板，减少重复开发，降低运维的成本，将更多的人力hold在需要做深度个性化开发的工作上，或者对接新业务上。下图是基本的包图设计：（更加详细设计可以再落地阶段根据更加详细的需求做改动)

最终体现的效果

整个设计的系统需要达成的效果，让开发人员从重复劳动中，繁琐的问题排查流程中解脱出来，甚者可以结合权限系统让业务实现自主接入，自主排错。让开发人员去对接新的业务。最终让用户养成一种习惯，所有操作都从GBDETL管理系统开始，所有的操作也都在GBDETL管理系统结束。 eg：用户新增任务，查看任务的启动状态，查看整个流程的运作，查看运行过中的异常，都在GBDETL系统内一站式完成。不让用户在编写零散的脚本直接上传到scheduler进行调度。
Eg1：在做推送任务的时候，只需要配置好推送的库名，表名，数据筛选添加，同步周期，整个任务就可以完成，可以观察每日的推送的数据量，推送耗时等过程或者结果信息。
EG2: 在做接入工作时，如果是业务数据量的增长，基于flume，服务器的增加，只需运维配置拷贝一台flume节点的配置到新机器，启动初始化服务就可。如果是基于filesync，sqoop，需要在gbdetl系统，按输入要求配置好输入参数，filesync缓存路径等瓶颈点会根据目前系统磁盘负载自动分配。

转载于:https://my.oschina.net/osenlin/blog/1603096