系统分为数据源和数据提取、数据仓库、计算接口和报表生成、数据查询服务五大处理流程。
（1）数据源和数据提取
数据是数据平台的基础，平台的数据包括内部数据和补充数据，内部数据由各业务系统产生的所有业务数据和文件构成。外部数据由市场调研、业务补充信息、互联网数据、关系表、码表等，可以是结构化的，也可以是非结构化的，需要借助信息集成技术整合后才能用于业务的整体全面分析。所有的数据需要经过数据评价、数据筛选以及数据抽取、转换和装载，也就是ETL后才可存储在数据平台的数据仓库中，为数据使用分析奠定基础。
源系统分为主机平台系统和开放平台系统两类，通常主要采用记录定长方式或者固定分隔符、制表符等变长格式生成下传数据文件。运行在开放平台的源系统将生成后的下传数据文件通过FTP方式直接传送到数据下传平台。运行在主机平台的源系统下传数据文件的方式也会分为两类，一类是做文件传输时会进行转码，但码制改变后通常也会导致字符集变化，导致文件记录长度变化；另一类是传输时不需要转码，这些会直接传送到数据下传平台。
数据下传平台文件处理的标准流程包括文件接收、解包、解压、转码、统一格式、文件级校验、归档和发布。每日处理文件前，需要通过手工方式在系统前端提前维护好假日表、文件处理过程等参数。
对于文件处理进程、文件处理情况等状态查询可随时进行。
详细处理流程如图4-54所示。
（2）数据仓库
接收文件中转服务器下传所有业务系统数据，包括元数据和经过ETL的业务数据。元数据是描述数据仓库内数据的结构和建立方法的数据，包括了数据源信息、数据转换的描述、数据仓库内对象和数据结构字典、数据清理和数据更新时的规则、源数据到UDM数据的映射、用户访问数据权限、相关历史记录等。在数据ETL完成后按预定义模型加工数据，为全行提供统一的数据模型UDM，UDM结果数据作为报表层的输入数据，为关系类型数据库数据。
在数据仓库内，ETL是负责完成是数据源数据向数据仓库数据的转化的过程，是实施数据仓库中最重要的步骤。如果说在数据仓库系统设计中最重要的部分是用户需求分析和模型设计，那么其中工作量最大的就是ETL规则的设计和实施，它要占到整个数据仓库设计工作量的60%～70%，甚至更多。在ETL过程中，主要进行以下几部分的处理。
1）ODS（Operational Data Store）区数据采集，该环节最主要作用是为了尽量减少对业务系统的影响，同时，这部分表结构可以不必和后续DW一致。且根据具体业务系统差异、业务需求和数据量情况，将数据源的数据放入ODS有各种不同的方法，比如Oracle的数据库链路、表复制、SQL∗LOADER、Teradata的Fastload、Sysbase的BCP等。这里需要解决的问题包括：
图4-54 数据下传流程
①数据的时间差异性问题，如在抽取源系统下传数据时，要将不同时期的数据定义统一，如果较早的数据不够完整或不符合新系统的数据规范，一般可以根据规则，在存入中转区的过程中予以更新或补充。
②业务数据的平台多样性问题，在抽取下传业务数据时，大部分数据都可采用表复制方式直接导入数据中转区集中，再做处理，但有部分数据可能需要转换成文本文件或使用第三方工具如Informatica等装载入数据中转区。这部分数据主要是与数据中转区数据库平台不一致的数据库数据，或非存储于数据库内的文本、Excel等数据。
③数据的不稳定性问题。对于重要信息的完整历史变更记录，在抽取时可以根据各时期的历史信息，在抽取需要信息等基本属性的旧有数据时，要与相应时段的信息关联得到真实的历史属性。
④数据的依赖性问题。旧有业务系统的数据关联一般已有约束保证，代码表和参照表等数据也比较准确，但仍有少量数据不完整，对这部分数据，需根据具体的需求采取清洗策略，保证数据仓库各事实表和维表之间的关联完整有效。
⑤最后，数据仓库各事实表和维表的初始装载顺序有先后关系，要有一个集中的数据装载任务顺序方案，确保初始数据装载得准确。这可以通过操作系统或第三方工具的任务调度机制来保证。
2）数据转换、清洗。将ODS中的数据，按照数据仓库中数据存储结构进行合理的转换，转换步骤一般还要包含数据清洗的过程。数据清洗主要是针对源数据库中出现二义性、重复、不完整、违反业务或逻辑规则等问题的数据进行统一的处理，一般包括如NULL（空）值处理、日期格式转换、数据类型转换等。在清洗之前需要进行数据质量分析，以找出存在问题的数据，否则数据清洗将无从谈起。数据装载是通过装载工具或自行编写的SQL程序将抽取、转换后的结果数据加载到目标数据库中。
数据质量问题具体表现在以下几个方面：
①正确性（Accuracy）。数据是否正确地反映了所代表的业务含义。(www.xing528.com)
②完整性（Integrity）。数据之间的关联完整性是否存在或一致。
③一致性（Consistency）。数据是否被一致地定义或理解。
④完备性（Completeness）。是否所有需要的数据都存在。
⑤有效性（Validity）。数据是否在业务定义的可接受的范围之内。
⑥时效性（Timeliness）。数据在需要的时点是否有效。
⑦可获取性（Accessibility）。数据是否易于获取、易于理解和易于使用。
3）数据加载。将转换和清洗完的数据按照数据仓库的结构进行数据加载。需要考虑初始数据装载、数据刷新、加载顺序等问题。
4）汇总层、CUBE加载。ODS加载进入数据仓库的数据只是底层详细层数据，还需按照预定义的规则计算集合模型，并按定义的汇总规则进行汇总，生成数据集市用的汇总表或CUBE。ETL流程是指完成每个维表数据及事实表数据导入的顺序，其包括两个部分，初始导入数据时的ETL流程及增量导入时的ETL流程。
5）任务调度策略。主要有：
①前导JOB驱动。只有满足另外一个JOB成功后，自己才运行。
②文件驱动。当下传的文件到达，并经过检验准确后JOB才运行。
③时间驱动。当到达某个时点时，JOB便开始运行。
④事件驱动：如人工参与，导致JOB执行。
（3）计算接口
为外部系统提供使用平台计算能力的调用接口，采用API接口调用的方式，将数据开放平台的计算服务开放给行内其他系统。为保障数据开放平台的安全和稳定性，对接口划分不同的等级集合，只有经过严格认证和授权的应用才能使用高级接口。接口开放支持SQL、JAVA、C、PYTHON、PERL、RUBY等多种高级语言调用。外部系统可向平台提交计算任务。计算任务是数据分析处理、数据挖掘等计算工具统称。平台根据任务队列及优先级，进行灵活调度，在空闲时间执行大计算量任务，优先处理实时计算任务。每次计算服务的提交，都作为一次计算任务来进行管理，为其定义优先级进行排队，有效协调外部系统的高频调用。经过数据计算任务处理，数据按不同维度重组、聚合，为最终报表的产生完成数据准备。计算接口的存在，除了平台本身的云计算共享，更重要的是实现数据分析开发者的成果共享，更加方便组件复用，借鉴开源的思想，促进在全行内建立大数据分析的生态圈。
（4）报表生成
利用数据库中的数据加工生成报表，报表平台同样语句各分行、各部门数据分隔的处理模式，将不同业务报表按照预先定义的权限提供给各分行、各部门的用户查看。同时可以按照预先定义的日、周、月、季、半年、年周期自动产生所需的监管报表，业务人员登录报表展示服务平台查询到相关报表后，也可以将报表下载到本地，还可以实时输入查询条件，检索特定数据范围内的报表查看。
（5）数据查询服务
数据查询服务实时同步数据仓库基础业务数据、加工的中间数据和统计的结果数据，为个外围系统和分支机构提供数据自助查询，数据自助下载、自行加工数据等功能，以及支持外围系统和分支机构灵活自行定制报表模块并生成报表实例。数据查询服务内部有A、B两个数据库实例，通过数据库日志抽取和重做机制，实现A实例与数据仓库数据库的实时同步，B实例通过DBLink方式实现与A实例连接访问。对于用户来说，在不影响生产环境情况下，只需要访问B实例就可以查询到生产环境的实时数据，同时在B实例中还可以对数据进行加工和存储，真正意义上实现Active—Active双活数据中心。数据查询服务通过使用成熟的数据库日志抽取和重做机制实现数据库同步，既保证了生产环境数据性能，又实现数据秒级同步。通过设置A、B两个数据库实例，既保证了与生产数据库同步，同时又为数据查询服务平台提供了数据加工和额外的数据存储功能。为了保证A实例数据的稳定性及一致性，将A实例设置为只读的方式，B实例为读写方式，使用DBLink的方式连接A实例。A、B实例通过使用不同的监听端口，从网络层面将A、B实例的访问进行隔离，并且在B实例细化权限的设置。在B实例建立A实例的同义词，用户在B实例使用A实例的数据时就像是在本地实例使用数据一样，而A实例同步的是数据仓库生产的数据，保证了在B实例进行数据操作，与直接对数据仓库生产的数据进行操作是一致的。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
