保险ODS系统架构及设计

        • 业务系统方：目前主要的业务系统方包括：销售管理系统、个险核心系统、团险核心系统等。后期随着各类业务系统的逐步建立，ODS系统也会持续的扩张接入更多的业务系统数据。

        • 数据采集方式：针对目前各个业务系统无法提供约定规格的接口数据文件，ODS系统ETL处理平台采用主动数据采集的方式，从各个业务系统采集获取存量数据和每日增量数据，加载到ODS数据采集层，进入到下一处理环节。目前业务方系统较少，数据量级较小，在ODS系统建设初期，暂未使用专业ETL工具（datastage、informatic）。初期，在ETL服务器部署shell脚本，连接远端业务系统数据库进行数据采集和数据加载。采集数据文件落地在ETL服务器指定路径，格式为.txt平面文件。

        • 外部数据应用分析：在保险领域，目前ODS系统的数据需求方主要有：EDW、ECIF、CRM、BAS等数据应用分析系统。

        数据采集层

        数据采集是指把业务数据从各个业务系统（如个/团核心业务系统、财务系统、销售管理系统等）进行抽取并装载到ODS的过程。数据采集层不仅仅是将业务系统中的数据复制到ODS系统中的过程，要求更多的是捕捉到数据变化的能力。数据采集层，也被称为“同构层”或者“贴源层”。因为其数据存储结构基本和业务系统保持一致，只是补充了数据采集、加载的一些基本信息。比如，来源系统标识、数据卸载时间戳、数据加载时间戳、批次号（增量日期）。存储与业务系统源表基本同构的数据，目的是为后续数据汇总、加工提供基础的可查询的数据。同构的数据存储方式，一方面能够存储最细粒度的数据，可以获取到清单级别的数据；另一方面还可以减轻业务系统对数据查询和报表提取的压力。

        ODS数据采集层是业务数据流动过程中的第一个存储区，需要对不同业务系统具体的数据表做评估，选用合适的数据采集方式。对于数据量比较大的源数据可以采用增量的方式进行抽取，对于经常变化更新的数据一般采用全量的方式进行抽取。传统的数据采集方式都很容易实现数据复制，但是对于数据变更的捕捉能力不足。ODS系统的数据采集通常可以使用以下方式。①离线文件方式：将业务系统变化捕捉后形成文件形式，传输到ODS系统，加载到ODS系统的数据库。②ETL数据抽取方式：通过专业ETL工具（datastage、informatic），从各个业务系统抽取数据，导入ODS系统数据库。

        离线文件的方式，是通过编程的方式（常用的是shell程序）将业务系统数据卸载落地成一定规格的文件，采集的数据文件一般都落地在ETL文件服务器。然后在ETL服务器，根据ODS数据库的类型来做数据的加载。如果ODS是Oracle存储平台可以使用SQL*Loader工具、ETL工具（datastage、informatic）方式将数据加载到ODS数据库。这种方式需要通过专门的程序来对文件传输和数据入库过程进行监控，确保数据卸载和加载的正确性；如果ODS是DB2存储平台，则可以使用DB2所提供的一些专门为数据移动所服务的命令（export、import、load、DB2MOVE）来实现数据的卸载和加载；如果ODS存储平台为greenplum，则可以用相应的gpload工具、外部表、copy命令来实现数据的卸载和加载。

        在ODS采集层，首先需要界定数据的采集范围，就是要明确需要从哪些业务系统中采集哪些数据表。这是因为ODS需要建立统一的数据模型，而数据模型建立的第一步是定义数据的整合范围。整合范围，描述了数据模型中包含什么和不包含什么。整合范围十分重要，没有它ODS的数据模型就会无休止地建立下去。数据的整合范围定义了，也就间接地定义了数据的采集范围，但ODS数据整合范围的定义，并不是一件一蹴而就的任务。在面对各类相对孤立的业务系统时，要区分和取舍哪些是真正和分析应用主题相关的数据，而哪些是无需进入ODS不相关的数据时，其实并不容易。

        数据采集范围的界定，实际上是对ODS进行主题划分的过程，这种划分是基于对业务系统调研的基础上而进行的，并不十分关心整个ODS系统前端应用需求，但是需要把前端应用需求与ODS数据范围进行验证，以确保所有应用所需的数据都已经从业务系统中采集过来，并且得到了很好的组织。一般来讲，主题的划分是以业务系统的信息模型为依据的，设计者需要综合业务系统的信息模型，并进行宏观的归并，整合得到企业范围内的高层数据视图，并加以抽象，划定几个逻辑的数据主题范围。在这个阶段，以ER模型表示数据主题关系最为恰当。

        在ODS数据采集层，为了防止数据卸载和加载过程中，可能存在的数据丢失情况，需要设置基本的数据级校验功能。在采集数据前和加载数据后均需要获取数据表的记录信息，数据表每采集一次，均会记录其采集点时间、数据量等信息。另外，为了保证数据采集前后的一致性，在数据采集层同样需要做业务级的数据校验。如机构、代理人、产品间的关联关系，补全数据表之间的外键关系等操作。

        数据整合层

        险企有不同的机构和部门，且都保存维护着自己相对独立的业务系统的数据，而决策制订人员需要关心的是全局的、一致的、完整的信息。这种全局数据就需要从各个下属机构保存的数据中进行提取、清洗、转换，最后装载到一个统一标准的结构当中，这一过程称为数据的整合。在ODS数据整合层，有选择地集成、整合业务系统的源数据，对数据进行清洗、转换操作，以数据主题域为数据集成的基础，对数据进行分类和组织，使用户能够通过统一信息视图区获得跟某个主题域相关的实时性数据。各业务系统和ODS用户可以互相访问，可以生成具有实时性的操作性报表和查询某一主题的近期全部信息。

        ODS整合层的数据结构，是在现有业务系统的基础上，针对管理信息的特征，从整个企业全局信息战略出发，对数据的名称、类型、描述及关联等进行的重新组织和定义，主要包括：统一数据类型、调整数据长度和增加转换时间属性。在界定了数据的范围之后，需要给出一个ETL数据的源到目标的映射。业务规则是管理ODS数据从采集层到数据整合层流动的必要组件之一，所以ETL的规则和业务规则息息相关。因此，最终ETL过程必须像裁判一样来决定：对于来自不同业务系统的各个数据单元而言，那些系统的业务规则是凌驾于其他规则之上的。

        数据整合层的两大任务是，数据存储和ETL数据处理。由于ODS集中了企业业务系统的全局数据，数据库平台的选型比较重要，考虑到未来ODS系统会接入更多的业务系统数据，数据库平台最好选用MPP架构的，比如：Teradata或者greenplum数据库平台，充分利用其并行数据处理的能力。ODS的数据存储是经过数据清洗、转换、整合后的全局运营数据的存储。数据原则上是统一编码格式的数据，并且可作为企业数据标准指导外围系统逐步统一数据格式。存储数据模型遵循EDM模型，按数据主题域体系组织，落实具有物理特征的EDM逻辑模型。

首页 上一页 1 2 3 4 下一页 尾页

扫码即可手机
阅读转发此文