平台组建设思路@20101027

平台组建设思路

一、经分平台系统架构

说明：

1.1 外部数据接口

提供给经分系统原始业务数据的，以及需要从经分获取统计分析后数据的系统、平台。与这些系统、平台间需要一套规范的数据交互（接口）的格式和流程，用以确保数据的可靠性。这部分主要由平台组负责开发和制定规范和流程。

1.2 ETL进口、经分出口系统

负责按照经分与外部系统的接口规范提供数据向经分流入，或者从经分流出的处理实现。目前可以提供支持的有：各类格式的数据文件、邮件（人工处理）、库表、webservice等。这部分由系统组（平台和前端）负责系统开发、规范制定，维护组负责日常运维，并收集优化需求提供给系统组做评估。

1.3 仓库层

仓库层是经分系统的核心，主要由经分仓库（含开发、测试库）和若干数据集市组成。这部分在物理上主要包含：DB数据库+数据处理程序（SQC）+调度处理系统。所有经分和业务相关的数据处理的生产、开发任务都在这部分完成。同时也是系统平台开发面向的“服务”

对象。

1.4 分发系统

分发系统是负责将经分的多个数据库（仓库、集市等）之间的表数据进行流转的控制处理系统。它将表数据从一个库导入到另一个库，采用自动调度、异常处理等功能。

1.5 SS系统

SS系统采用了亚信开发的SS调度软件，它在系统中负责在某个仓库内，调度进行数据处理的sqc程序。而sqc程序是数据生产的最主要的驱动力，因此SS系统也是担负程序和程序之间的控制处理系统。

1.6 支撑平台

支撑平台主要由：元数据管理、维护管理、数据质量管理三个平台组成。

元数据平台：负责采集经分系统各处理环节的业务元数据，通过各类元数据分析处理工具的开发和应用，为经分建设提供技术支持。

维护管理平台：负责提供经分日常生产中工作流程的IT支撑。主要应用有：权限申请、分发申请、ETL申请、代码提交单管理等等维护支撑方面的功能。

数据质量管理平台：负责提供对经分各系统处理数据的采集分析，进行数据质量的管理和监控。

三个平台由平台组和前端组共同开发实施，并提供日常运维支持。

1.6 应用层

本层提供为经分开发和生产相关的一些实用工具。这些工具主要都是以BS架构实现，面向的服务对象是经分开发、管理人员，以及移动各业务部门。这部分主要由前端组配合其他业务条线的开发人员共同完成实用工具的应用开发，以及日常运维工作。

二、经分系统平台建设思路

经分系统平台组的日常工作主要将围绕：进出口管理、数据处理、维护支撑、开发支撑这4方面展开：

2.1 进出口管理

进出口管理主要负责经分数据与各外围系统平台间的数据交互接口的开发、运维、管理等方面的工作内容。这部分内容可以从以下3个切入点开展工作：

2.1.1 接口规范

●首先梳理当前经分系统存在的进出口接口信息，这些信会包括：类型、格式、传输方式、

周期、交互机制、外围系统平台信息、相关接口人、数据量等等所有信息。进出口的交互方式不仅限于后台的文件或表的交互，今后的管理也将包括前台的webservice的接口梳理，最终的目标就是建立经分的进出口的数据字典。

●参照梳理的结果，制定出今后新增接口时的规范（参照VGOP方式）。梳理和制定规范

的工作可以同时进行，规范内容随着接口的增多不断补充或修正。

2.1.2 接口开发

接口开发的工作是和所有的新增接口需要涉及的开发内容都有关的。对平台组来说，它目前主要由两方面组成：

●系统开发。主要为满足经分外部系统与经分进行数据交换而需要进行的系统方面的建设

和开发工作。目前针对的系统就是ETL进口和后台出口上的技术实施。当有这方面需求的时候，就需要作为一个小专项开展工作，包括需求调研、系统设计、开发、测试等等环节。

●应用程序开发。这部分工作补充了目前其他小组工作职责中与外部系统接口相关开发工

作的缺失。当前的情况是：

?绝大部分的进口由ETL系统完成，基本不含业务逻辑的开发内容，都是由各方的需求人负责调研、维护组负责配置、平台组负责技术支持；

?绝大部分的后台出口都是由各条线的专项人员负责。部分接口的开发通过平台人员落实，没有到维护组。今后需要将这部分同进口一样进行管理；

?由前台页面做成的进出口的开发，都由前台组相关人员负责开发和维护，专项人员负责管理协调；

?一经、一级客服等等出口的开发未落实具体的接口人，基本由维护组内部消化。

为了统一管理进出口，做好系统内各小组的分工界面，目前的分工思路如下：?ETL的开发纳入平台组进出口管理中“系统开发”的工作范围；

?后台出口的开发同ETL进口一样，归在进出口管理中“系统开发”中，业务逻辑部分由各专项人员负责落实，平台组负责实施和技术支持，维护组负责日

常运维；

?前台的进出口开发任务由前台负责系统实施、专项人员负责业务逻辑的实施、平台负责归档和管理（接口规范）；

?一经、一级客服等等出口的开发任务由平台组负责完成从需求调研、程序开发、系统实施整个流程，维护组负责日常生产维护，并依靠平台组的技术支持。

2.1.3 日常管理

进出口的日常管理主要是指平台组与维护组的分工界面：

●日常进出口需求的归口在平台。有新的需求首先落到平台组的归口人，然后进行需求调

研。

●需求调研主要会针对：系统、网络、技术实现等方面进行。需求调研的同时也是收集整

理进出口数据字典的过程。当调研结果是当前各方面满足新增的接口时，就可以转到相关维护人员那里，进行新增的配置工作。

●如果是当前系统、技术架构等无法满足需求时，就需要启动平台的接口开发的工作内容，

做成专项，与现有系统统一进行评估、设计和开发优化。

2.2 数据处理

数据处理主要指在仓库中，对表、程序运行管理控制的一个过程，保证了经分仓库、集市、前台中的数据流转的顺畅、及时和准确。这部分的工作可以从以下几个方面展开：

2.2.1 SS系统

SS系统是对程序的管控，负责调度仓库内的各种sqc程序、数据处理脚本等等，是数据流转的调度引擎。目前使用的是亚信的产品。日常的运维是由维护组负责，根据不同的应用场景包含有宏冠、宽文等其他厂商共同参与。对于该产品的使用，今后考虑由平台组负责收集整理优化需求，与研发部门沟通的工作，以及日常应用的技术支持。在系统建设上，需要考虑将SS与经分其他后台系统之间的衔接处理。

2.2.2 分发系统

分发系统是对表的调度，负责进行库与库之间表数据的交换处理和调度。主要目标就是在提升处理性能的基础上，强化监控，同时要让分发系统与经分其他平台系统能有效的进行处理上的衔接。

2.2.3 系统间衔接

系统间衔接本身并不是一个系统，但为了将经分平台上的各处理系统的调度进行处理上的有效衔接，必须有一套机制能实现这个衔接过程。通过在前阶段的ETL系统的开发，已经尝试了ETL->SS的衔接。接下来的工作要需要分为两块：

●各系统的优化。针对三个处理系统：ETL、分发、SS，对各自的系统进行优化，留出

与其他系统的接口。考虑的方向是：

?流程的触发方式。除了现有的时间触发，也需要考虑通过事件，或状态等标志进行触发。并且，也需要考虑自身系统内的前后依赖触发方式，例如一个ETL流程结

束后自动启动另一个ETL流程(已配合crm改造完成)。

?流程的结束标识。一个系统的流程结束，有统一的标识方式，可供其他系统或处理机制进行判断，为后续的衔接预留接口。

●系统衔接机制的实现。需要通过一套处理机制将各系统预留的前后接口有效的衔接起来

（使用socket消息方案来实现）。

?预先配置的衔接任务，表示有哪些系统的哪些任务需要和哪些系统的哪些任务进行衔接。

?对前置系统的完成标识的判断。

?对后续系统的触发接口进行触发。

?系统间级别的调度机制的实现。即数据处理从一个系统流转到另一个系统的自动调度机制。

●LIB库的优化。与衔接机制一样，lib库的实现是另一种“被动”的衔接方式，有利于

对调度异常的情况进行处理。在以上两个工作的同时，日常的开发、维护工作都需要把lib库这个sqc规范的实现作为管理内容之一。管理内容包括：

?sqc规范的制定、文档版本的管理。

?技术培训。

?数据处理开发方面的需求收集、调研。

?函数库的设计和开发。

2.3 维护支撑

维护支撑工作是围绕日常运维的需求决定的，工作的目标是经分平台系统，服务的对象主要是维护人员。通过支撑平台的建设，提供运维工作的界面化管控手段，提高维护人员操作效率、减少人为故障率、降低维护人员工作强度。

目前正在使用的维护功能有：ETL的运行监控、ETL配置和操作、代码提交单管理（上线管理）、申请单管理、表空间管理、文件系统监控和管理、血缘分析、影响分析、SS关系查询等等。

维护支撑围绕三个平台的建设进行：元数据管理平台、维护管理平台、数据质量管理平台。元数据管理平台主要是指对经分日常运行元数据和业务元数据的采集和分析，提供经分开发人员在日常开发的辅助功能。维护管理平台主要是维护工具的集合，提供一些后台运行的生产系统（如ETL、分发）的前端操作交互界面。数据质量管理平台主要是通过对生产数据的采集、分析，实现对经分数据处理流程的自动监控、告警机制。

因此，平台组维护支撑的工作可以从以下三个切入点展开：

●现有工具的优化。目前的工具存在易用性、界面友好度、功能性等方面的缺陷，因此需

要逐个梳理收集用户（主要是维护人员）方面的优化需求，然后逐一进行修正。特别是功能性上面的缺陷是首要解决的问题。

●平台建设。主要指数据质量管理平台的建设任务。当前的质量管理平台的架构，已经无

法充分满足经分生产的需求，特别是对数据采集和评估的效率无法达到及时性的需求。

因此需要将平台的处理架构进行优化修改，以期达到满足评估的需求。同时，这个也需要结合几个系统的优化和开发的工作进行。例如ETL系统的优化，如果ETL做不好与其他系统的前后衔接机制（本文2.2.2节）的处理，平台对ETL的监控和处理也无法做到及时和准确。

●新功能的开发。这方面的需求会从维护人员、局方两方面提出。同时，平台组也需要从

现有的平台各项功能出发，主动将操作、监控等日常维护的工作内容与维护平台的建设放在一起考虑。对一些新系统的设计开发时，例如分发系统的优化，也需要这样考虑。

2.4 开发支撑

开发支撑与维护支撑类似，主要面对的服务对象是其他小组的开发人员，例如属地、数据等业务条线的开发人员。支撑的手段就是通过提供多种开发辅助的工具，为开发人员在生产过程中提供IT支撑。目前这些工具会根据实际情况分布在三个支撑平台上。

当前开发支撑方面的工作可以从以下两个方向入手：

●实用工具。当前元数据上有很多同其他省一起开发的元数据方面的应用工具，这些工具

目前基本都没使用，目前需要一个易于维护和能够持续更新的元数据产品（调度、解析等其他元数据应用），当然也可以考虑平台组自己开发。

新需求收集整理。主要是对各条线业务负责人的专项、日常收集到的信息中，寻找日常生产需要支撑的功能点，然后通过设计和开发实现。