大数据中台平台化建设需求

数据标准体系建设需求分析

按照大数据中台据标准体系框架构建基本原则，将数据中台标准体系框架分为数据汇聚类、数据管理类、数据分析类、数据开放类标准。

大数据中台建设的核心之一是数据标准规范的制定。在加工数据之前，需要将多源的数据进行标准化处理，即将来源复杂、形态各异的数据转换为可用的标准化数据。具体标准化定义范围包括：

数据汇聚类标准：定义进入大数据中台的数据范围和规格，具体包括核心数据范围、共享数据范围、采集数据范围。包括数据实体、实体属性、关联属性、属性取值范围、属性编码方式等。大数据中台共享数据的方法和数据内容，具体包括数据采集接口技术形式，采集协议，采集周期或触发机制等。采集数据内容包括数据范围，采集数据模型，数据载体形式和编码方式等。
数据管理类标准：定义大数据中台的数据生命周期管理标准，定义管理角色、管理流程和表单内容等.定义数据安全、隐私保护方面的约定。定义主数据范围、数据模型、管理原则等。
数据分析类标准：定义大数据中台提供的数据分析方式，包括数据模型分析、预测、分析、展现原则等。
数据开发类标准：定义大数据中台提供的数据共享技术方式、交互过程，数据服务原语、数据服务参数、返回结果结构和编码方式。如果是文件方式，需要定义文件内容结构、编码方式、文件命名格式、数据就绪时间等约定。

数据加工体系建设需求分析

大数据中台旨在通过大数据技术，推进数据驱动的业务决策，需要构建全域大数据体系，汇聚内部及外部的大数据，进行标准化管理和存储。需要打通下属各级单位以及跨部门、跨系统的数据壁垒，因此存在组织机构规模大、数据多样化、数据采集场景多的特点。

结合对项目的需求现状进行分析，项目主要数据来源包括现有业务系统，存在关系型数据、音频文件、视频文件、文本数据等形态，同时针对不同的数据类型其需要满足的时效性，以及通信协议也不尽相同，因此通过构建统一的数据采集与感知平台，实现对多样化数据采集需求的统一接入，屏蔽底层的数据采集的差异性，从而更有效的支撑农业农村大数据体系建设，转化有价值的数据服务应用。

数据加工开发体系建设提供了实时数据感知、批量数据采集、应用系统数据采集、业务日志数据采集、网页数据采集以及人工填报数据采集的能力，从而满足当前项目的多样化数据采集需求。

数据加工开发体系建设的另一个重点就是构建数据的离线开发和实时开发的能力。汇聚联通到中台的数据，基本是按照数据的原始状态堆砌在一起的，是对过往所有IT信息化建设积累的成果的融合。数据开发是数据资产内容建设的主战场，是数据价值生产过程中的核心环节，可以支撑大批量数据的离线处理、实时处理和数据挖掘等。业务沉淀的数据就像原始的矿石或商品的原材料，数据开发这个环节就像是"商品"生产的流水线，通过这条流水线将数据转换成数据资产，让数据能根据业务的需求转换成新的形态，将原本看起来没有价值的数据变成对业务有价值的资产，为前端业务源源不断提供所需要的"商品"。

数据存储体系建设需求分析

大数据中台是数据汇聚地，一切数据都汇聚到大数据中台，业务所需的数据总能在大数据中台找到。但大数据中台中的数据并不是简单地堆积，各种系统产生的原始数据堆积在一起导致使用成本非常高，这类数据只能在某些数据技术基础非常好的部门使用，而且会经常出现命名不一、口径不一的问题，从而导致整个企业数据无法真正用起来。大数据中台数据体系是在全域原始数据的基础上，进行标准定义及分层建模，数据体系建设最终呈现的结果是一套完整、规范、准确的数据体系，可以方便支撑数据应用。

中台数据体系应具备以下特征：

覆盖全域数据：数据集中建设，覆盖所有业务过程数据，业务在中台数据体系中总能找到需要的数据。
结构层次清晰：纵向的数据分层，横向主题域、业务过程划分，让整个层次结构清晰易理解。
数据准确一致：定义一致性指标，统一命名、统一业务含义、统一计算口径，并有专业团队负责建模，保证数据的准确一致。
性能提升：统一的规划设计，选用合理的数据模型，清晰地定义并统一规范，并且考虑使用场景，使整体性能更好。
降低成本：数据体系的建设使得数据能被业务共享，这避免了大量烟囱式的重复建设，节约了计算、存储和人力成本。
方便易用：易用的总体原则是越往后越能方便地直接使用数据，把一些复杂的处理尽可能前置，必要时做适当的冗余处理。比如在数据的使用中，可以通过维度冗余和事实冗余来提前进行相关处理，以避免使用时才计算，通过公共计算下沉、明细与汇总共存等为业务提供灵活性。统一数据体系的建设让整个企业的业务都有机会使用数据。

为了使数据体系在建设时具备以上特征，需要一个体系化的数据层次架构，这个层次架构定义了数据分层及每一层的模型建设规范。数据体系架构是一套指导规范，实施过程中应严格按照架构执行，如下图所示。

数据体系架构图

原始数据域：

对各业务系统数据进行采集、汇聚，尽可能保留原始业务流程数据，与业务系统基本保持一致，仅做简单整合、非结构化数据结构化处理或者增加标识数据日期描述信息，不做深度清洗加工。

标准数据域：

又细分为明细数据层DWD（Data Warehouse Detail）和汇总数据层DWS （Data Warehouse Summary），与传统数据仓库功能基本一致，对全历史业务过程数据进行建模存储。对来源于业务系统的数据进行重新组织。业务系统是按照业务流程方便操作的方式来组织数据的，而统一数仓层从业务易理解的视角来重新组织，定义一致的指标、维度，各业务板块、业务域按照统一规范独立建设，从而形成统一规范的标准业务数据体系。

应用数据域：按照业务的需要从统一数仓层、标签数据层抽取数据，并面向业务的特殊需要加工业务特定数据，以满足业务及性能需求，向特定应用组装应用数据。。

数据服务体系建设需求分析

将数据资产封装成数据服务，以接口方式提供给上层应用，才能极大释放、提升数据资产的价值。数据服务体系就是把数据变为一种服务能力，通过数据服务让数据参与到业务之中，激活整个大数据中台，这也是大数据中台的价值所在。

数据资产只有形成数据服务被业务所使用，才能体现其价值。以往传统做法是根据某个应用产品的需要，独立构建非常多的数据接口与应用产品对接，这会形成数据接口的"孤岛"，造成大量接口的重复建设，且修改、运维、监控的成本都很大，需要抽象成可管理、可复用、可监控的统一标准下的数据服务体系。而通过数据服务便捷地对接业务系统或应用系统，才能将数据资产灵活使用起来，最终给企业带来各种适配业务场景的数据解决方案，从而提升效率。数据服务作为大数据中台实现资产服务化的核心能力，是连接前台业务和数据的桥梁，通过服务接口的方式对数据进行封装和开放，快速、灵活地满足上层应用的需求。大数据中台能够以提供数据服务的方式直接驱动业务，不需要人的介入，让业务更快地产生价值。

数据服务是对数据进行计算逻辑的封装（过滤查询、多维分析和算法推理等计算逻辑），生成API服务，上层数据应用可以对接数据服务API，让数据快速应用到业务场景中。数据服务是大数据中台能力的出口，是支持数据应用的重要支撑。在大数据中台落地支撑业务时，数据分析师或算法工程师可以通过数据服务配置中台数据资产的访问API，这样数据应用产品可以方便地使用中台的数据能力，支撑业务决策和智能创新。

数据服务作为补全数据应用的最后一公里，它的核心价值有以下4点。

确保数据在业务层的全域流通

数据服务可以对大数据中台的全量数据进行封装透出，让中台的数据支撑数据业务，加速数据业务化的流程；数据业务产生的反馈数据可以回流到大数据中台中，不断优化现有的数据服务，让数据在业务中持续流动起来。

降低数据接口的重复建设

前端不同的数据应用对数据的需求有些是类似的，例如客户画像和客户精准营销都对客户的特征标签有需求，通过统一的数据服务创建的包含客户特征数据的接口，可以通过授权分别提供给画像和营销两个应用。与以前的烟囱式开发相比，这样做的好处是可以避免数据接口的重复建设。通过一次创建、多次授权的方式交付给前端。

保障数据获取的及时性和稳定高效

通过统一的数据服务，对于不同业务部门给大数据中台提的数据需求，中台管理方可以进行统一规划和分配，从整体上保证资源和需求的协调。同时，通过数据服务中的数据，中台可以及时得到业务上的完整反馈信息，并基于真实数据及时调整：若需要及时的数据，则给予实时性的保障；若需要稳定的数据，则给予可用性的保障。

使能数据能力扩展

通过统一大数据中台，不断扩展数据源、优化数据资产建设、扩展数据服务封装方式，将数据能力进行持续扩展，不断给数据业务和数据应用提供更多数据价值。

数据资产管理体系建设需求分析

数据是一种无形的宝贵资产，谷歌、Facebook、阿里巴巴、腾讯等企业的市值能够高达数千亿美元，除了其独特的商业模式和市场地位，市场还格外看重其拥有的海量用户数据里所蕴含的巨大价值。对于数据的拥有者和管理者来说，通过对数据的合理管理和有效应用，能盘活并充分释放数据的巨大价值。但如果他们不能对数据进行有效管理，数据就用不起来，或者即便用起来也用不好，在这种情况下，堆积如山的无序数据给企业带来的是高昂的成本，数据就成为一项棘手的"负债"。《数据资产管理实践白皮书4.0》中对"数据资产管理"的定义为："规划、控制和提供数据及信息资产的一组业务职能，包括开发、执行和监督有关数据的计划、政策、方案、项目、流程、方法和程序，从而控制、保护、交付和提高数据资产的价值。"

数据资产管理是大数据中台面向业务提供数据能力的一个窗口，数据资产中心将数据资产统一管理起来，实现数据资产的可见、可懂、可用和可运营。

可见：

通过对数据资产的全面盘点，形成数据资产地图。针对数据生产者、管理者、使用者等不同的角色，用数据资产目录的方式共享数据资产，用户可以快速、精确地查找到自己关心的数据资产。

可懂：

通过元数据管理，完善对数据资产的描述。同时在数据资产的建设过程中，注重数据资产业务含义的提炼，将数据加工和组织成人人可懂的、无歧义的数据资产。

可用：

通过统一数据标准、提升数据质量和数据安全性等措施，增强数据的可信度，让数据科学家和数据分析人员没有后顾之忧，放心使用数据资产，降低因为数据不可用、不可信而带来的沟通成本和管理成本。

可运营：

数据资产运营的最终目的是让数据价值越滚越大，因此数据资产运营要始终围绕资产价值来开展。通过建立一套符合数据驱动的组织管理制度流程和价值评估体系，改进数据资产建设过程，提升数据资产管理的水平，提升数据资产的价值。

总体设计方案

总体设计原则

大数据中台的涉及内容众多，技术复杂，使用对象覆盖面广。因此，在建设时，项目规划设计应遵循以下基本原则：

业务驱动原则

大数据中台是业务驱动型项目，要求业务部门深度参与项目的规划和建设，数据模型设计和数据展现需求必须来源于实际的业务需求，数据应用和数据价值体现必须通过实际的业务能力提升来检验。

先进性原则

大数据中台采用先进技术，针对不同的业务场景，采用不同的计算和存储技术来对应等。平台采用先进的架构，各个部分之间采用松耦合，一个子系统出现问题不会影响其他系统。

易用性原则

大数据中台的各个子系统注重易用性的设计，界面和操作直观、美观、方便，易理解性，使用户抓住重点，一目了然；易操作性，提供便捷、一致的操作方式，减少用户输入和点击次数；易管理性，缩减安装、配置、实施、备份的时间和难度。

安全性原则

针对数据安全性，采用立体化的安全防范手段，一方面加强对现有安全设备的利用，另一方面应采用安全加密和脱敏系统加强对数据的防护，并结合已有的安全管理制度，共同形成高安全性防护。

扩展性原则

为保证系统的可扩展性设计，在系统架构上，采用系统分层设计实现。保证在设计开发上具有适应业务变化的能力，当系统新增业务功能或现有业务功能改变时（界面的改变、业务实体变化、业务流程变化、规则的改变、代码改变等），应尽可能的保证业务变化造成的影响局部化。

整体性原则

由于大数据中台类项目涉及的子平台和子系统众多，为体现系统的整体性，应提供统一门户，完成各子平台和子系统的身份统一和集成，完成各系统的界面、应用和数据集成，确保各部分形成一个整体统一对外提供服务。

信息共享原则

建立数据信息共享的服务平台，完善相关管理机制，在保证数据安全性的前提下，推动数据跨部门、跨学段、跨领域的数据共享和信息公开。实现数据在各单位之间、向政府其他部门的数据共享，从而充分发挥数据价值；实现数据和信息社会公众的公开，，从而提高政府工作的透明度，促进依法行政，并充分发挥政府信息对人民群众生产、生活和经济社会活动的服务作用。

总体架构设计

逻辑架构设计

大数据中台的建设宗旨是能够让数据持续的用起来，发挥数据中蕴含的价值。为实现大数据中台的建设宗旨，依托数据资产服务快速实现业务赋能和创新的目的，本项目将秉承"数据资产化、资产服务化"的建设理念构建大数据中台的总体架构。

图 2-1大数据中台逻辑架构图

大数据中台的建设包括标准规范体系、大数据中台加工开发体系、大数据中台数据存储体系、大数据中台资产管理体系以及大数据中台服务体系的建设。其中标准规范体系建设为大数据中台的建设提供参考依据，实现"书同文、车同轨"，避免产生数据歧义，便于构建整个大数据中台体系；大数据中台加工开发体系的建设为大数据中台提供数据采集、数据整合、数据加工、数据开发的能力，帮助用户快速进行数据资产体系建设；数据存储体系建设为了构建一套统一的数据存储方法，便于支撑上层的数据应用；数据资产管理体系建设为了构建统一的数据资产中心，数据汇总上来之后，对外提供干净、可用的数据，提升数据的价值；数据服务体系的建设为大数据中台提供对外赋能的能力，大数据中台积累的数据资产、知识能力，需要以服务的形态面向前台进行赋能，以支持前台进行快速创新使用。

应用架构设计

大数据中台共划分为数据存储、数据接入、数据资产加工、数据治理、数据能力开发以及数据资源目录几部分。

图 2-2大数据中台应用架构图

数据存储

数据存储提供各种类型、各种形态数据的存储能力，同时将数据存储划分为原始数据区、标准数据区以及应用数据区。其中原始数据区用于存放原始形态数据，标准数据区存放经过加工融合的数据，应用数据区存放的是面向业务侧需求直接使用过的数据。

数据接入

数据接入提供包括数据流接入、数据库采集、日志采集、接口采集、应用数据采集等全域数据接入能力。配合各种形态数据的接入，需要提供实时数据传输、批量数据传输以及文件传输的能力，以满足不同时效、不同形态数据应用的需求。通过数据接入模块，能够实现将源端多种存储形态、多种存储位置、多种结构的数据接入到大数据中台，以为数据的横向打通奠定基础。

数据资产加工

数据资产加工提供包括清洗转换、数据关联、数据分类、比对融合等能力，以支持将多源异构的数据整合成面向不同主题的基础数据。数据资产加工是对接数据接入模块，然后对这些数据进行转化，经过复杂的清晰转换，将数据转换成标准形态，也就是通常所说的ETL过程。

在对数据资产进行加工处理时，提供批量处理和实施处理两种形态。将数据汇聚到中台后需要对其进行进一步加工处理，一般来说，有60%～80%的场景需要用到离线批处理的能力，这个过程就像一条数据的生产流水线，将采集和汇聚起来的原始数据，通过离线加工的各个环节和相应的数据处理模型，形成有价值的数据资产。

随着数据的应用场景越来越丰富，对于数据价值反馈到业务中的时效性要求也越来越高，也就是数据的价值在于数据的在线化。数据的业务价值随着时间的流逝会迅速降低，因此在数据产生后必须尽快对其进行计算和处理。通常而言，实时计算具备以下三大特点：

❏实时且无界（unbounded）的数据流：实时计算面对的计算是实时的、流式的，流数据是按照时间发生的顺序被实时计算订阅和消费的。并且，由于数据产生的持续性，数据流将长久且持续地集成到实时计算系统中。

❏持续且高效的计算：实时计算是一种"事件触发"的计算模式，触发源就是上述的无界流式数据。一旦有新的流数据进入实时计算，实时计算立刻发起并进行一次计算任务，因此整个实时计算是持续进行的高效计算。

❏流式且实时的数据集成：流数据触发一次实时计算的计算结果，可以被直接写入目的存储中，例如，将计算后的报表数据直接写入My SQL进行报表展示。因此，流数据的计算结果可以类似流式数据一样持续写入目的存储中。

技术架构设计

图 2-3大数据中台技术架构图

如图所示大数据中台建设所涉及的技术可以归类为基础设施、数据接入、服务支撑以及能力开放。

基础设施层

基础设施层通过虚拟化技术或者容器技术将底层的硬件资源进行服务化，包括计算资源、存储资源以及网络资源。通过将硬件资源服务化，能够屏蔽底层的硬件差异性，同时提升硬件设施的利用率。

数据接入层

数据接入层为了满足各种形态数据的接入，网页数据抓取能够实现网页页面中的数据的采集；应用数据抓取能够实现外部业务系统或者内部遗留业务系统的数据采集，无需暴露底层的数据存储；数据库存量数据抽取能够实现存储在数据库中的数据的采集；事务日志采集能够实现基于数据库事务日志的增量数据采集；内容数据采集能够实现记录在文本中的数据采集；用户行为数据采集能够实现人工填报类型的数据采集；流数据采集能够实现流式数据的实时接入。将这些数据接入后，可以通过ETL工具对数据进行清洗转换表转化。

服务支撑层

服务支撑层能够实现对各种形态数据的存储和处理，针对关系型数据可以将数据存储到关系数据库中；非关系型数据可以存储在NoSQL数据库中或者分布式文件系统中。通过这种混合型数据存储架构能够满足不同形态数据的按需存取。同时为了提高数据的存取能力，可以引入缓存技术。

针对高价值密度的结构化数据，应用数据仓库技术进行数据的建模和存储，在构建数据仓库时，可以通过OLAP提供多维分析的能力。针对非结构化数据可以借助大数据技术实现这些数据的存储和处理。

为了提供标准化、高可用的数据，通过元数据管理、数据标准管理、数据质量管理等进行数据治理，实现数据的可查、可信、可用。

能力开放层

能力开放以数据资源目录为出口，对外提供数据、服务以及文档类型的服务。

数据架构设计

图 2-4大数据中台数据架构图

大数据中台会汇集各种异构数据源的数据，从数据类型上可以分为结构化数据、半结构化数据和非结构化数据。这些数据采集到平台中首先会保存到数据湖中，一方面作为全量数据的备份，另一方面可以根据不同的数据使用情况分别为更上层的数据仓库和分析数据区提供原始数据支持。数据湖中的结构化数据经过汇总和标准化会进入数据仓库中存储，数据仓库提供结构化数据的查询与多维分析功能，同时在数据仓库的基础上按照主题构建数据集市，为上层应用提供面向主题的数据分析服务。数据湖中的另一部分用于预测性分析的结构化数据会导入到分析数据区中临时暂存，用于机器学习建模使用，构建好的模型以及预测分析结果也会保存到分析数据区中。数据湖中的用于文本挖掘和全文检索的半/非结构化数据也会导入到数据分析区中暂存，文本挖掘的分析结果和构建的全文检索结果数据同样会保存到分析数据区中。当分析过程结束，临时暂存数据将会删除以减少存储资源消耗，如果日后还有用到这些数据的分析则从数据湖中再次根据需要导入相应的数据即可。管理相关的元数据、主数据、目录数据、监控数据、权限数据、日志审计数据都单独存储于独立的数据库中。

数据湖：数据湖是平台所有数据的基础，存储了进入平台的全量结构化、半结构与非结构化数据，为后续进一步加工处理和数据分析做好数据储备；其中结构化原始数据根据其时效性，实时采集的数据会保存到HBase中，批量采集的数据会保存到HDFS中存储。而半/非结构化数据会保存到HDFS中存储。

数据仓库：数据仓库基于数据湖中的结构化数据经过ETL及高度汇总，对处理后的高价值密度数据进行存储，除了数据存储外，还可以为上层提供数据的查询及多维度分析支持；数据仓库由于数据范围和特点的不同，往往可以选取不同的技术路线或者混合使用。对于数据量不大（一般几十TB以下）、稳定性要求高的场景，会采用传统的MPP数据库构建数据仓库，对于大数据量（几十TB到PB级）的场景，往往采用Hive数据仓库工具构建数据仓库。

数据集市：在数据仓库的基础上，根据各个业务主题的不同需求，构建主题数据模型，进而构建面向主题的数据集市，支持对主题数据进行高效的查询、多维分析及统计报表。数据集市同样根据场景不同可能会采用传统的MPP构建或者Hive数据仓库工具构建。

分析数据区：分析数据区中存储了从数据湖中导入的要用于机器学习建模分析及文本挖掘或全文检索所需的结构化、半结构化及非结构化数据。这部分数据作为临时暂存数据仅用于分析的过程中，当分析结束根据其生命周期设置可以进行删除以便存储空间的优化利用。同时分析数据区还存储了预测性分析的结果及模型，以及文本挖掘的分析结果与模型，全文检索的索引及相关数据等等。其中暂存数据会存储于HDFS中，模型及分析结果也会保存在HDFS中，全文检索的相关数据会保存到ES中。

管理相关数据：元数据由于数据量不会太大，会存储于关系型数据库中；主数据会和业务相关数据一同存储于数据仓库中，根据场景不同可能是MPP或者Hive；资源目录数据根据资源的类型不同，结构化的存储于关系型数据库中，半/非结构化的存储于ES中；平台的监控数据存储于关系型数据库中；平台的权限管理数据也存储于关系型数据库中；平台的日志审计数据由于数据量较大会存储于HBase中。。

数据流总体设计

图 2-5大数据中台数据流图

数据源包含政府数据、互联网数据以及第三方数据，通过平台的数据采集系统将数据采集并存储到数据湖，在数据湖中进行数据分区处理，通过数据抽取、清洗、对比、质量管理等处理后的数据，形成基础库、分析库以及用于支撑上层应用系统的业务支撑库，最终通过平台开放的数据文件接口、数据库接口以及API接口等多种方式为上层应用提供数据支撑。。

大数据中台建设方案

数据标准体系建设

行业术语管理

统一行业术语管理提供了业务术语管理功能，业务术语能够提供对行业术语的业务背景描述和说明等信息，是从商业和业务的角度描述业务领域相关概念、关系和规则的数据，可以辅助对技术类元数据进行补充描述，以建立业务与技术人员的沟通桥梁。行业术语能够让业务人员在不了解技术元数据细节的情况下，清晰的掌握某个技术元数据的业务属性等信息，能够消除技术人员和业务人员之间的沟通壁垒和理解障碍。

支持行业术语分组管理

行业术语管理支持行业属于分组能力,可以按照农业农村的不同细分领域对行业术语进行分组、分类管理，更加清晰明了。通过创建词汇表和类别等多个维度将行业术语进行分组管理。

支持行业术语同义词管理

行业术语管理功能提供了同义词管理能力。用户可以将不同领域或分组下的具有相同或者类似含义的行业术语，通过同义词管理功能将其关联起来，用于展示说明这几个行业术语的相同性。

支持行业术语关联分析

支持将行业术语关联到任意的元数据上，作为该元数据的业务属性描述，便于非技术人员快速掌握该元数据的业务领域属性和含义。同时，用户可以在业务术语管理当中，以TopN的形式查看到某个业务术语关联的所有资源。

值域代码管理

值域代码管理提供了对值域代码管理的能力，通过将值域代码进行信息化管理有助于实现行业的值域代码的标准规范化，从而更加有利于打通各个业务系统间的数据壁垒。

支持值域代码定义

对值域代码进行定义描述，能够定义具体的值域编码、值域名称信息。能够对值域中包含的代码信息进行管理，能够新增、修改及删除具体的代码信息，包括代码的值信息以及具体的值含义信息。对已定义的值域代码，支持将其禁用，禁用后的值域将不再作为标准推广。

支持值域代码检索

为了便于值域代码的浏览查看，值域代码管理提供了按照值域编码、值域名称以及具体包含的值域代码值条件对值域进行检索的能力。

支持值域代码属性扩展

对于有些值域代码而言，除了定义了编码、名称和值意外，还需要描述该值域代码的附加属性，因此值域代码管理支持对值域代码扩展属性进行管理，能够定义代码项扩展属性，在定义扩展属性时能定义扩展属性名称、类型、扩展属性含义信息。针对定义了扩展属性的值域代码，在定义代码时，能够基于扩展属性定义填写具体属性值。

支持值域代码对照

在实际情况中，具有相同业务含义的值域代码可能有多套，因此值域代码管理支持设定一组值域代码作为标准值域代码，同时支持配置非标准值域的代码与标准值域代码的映射关系。并且支持在查看值域详情时，能够查看具体的值域对照关系。

支持值域代码批量导入

支持通过Excel批量导入值域代码，并能够下载对应的Excel模板文件，帮助用户快速实现值域代码的统一管理和标准化。对于批量导入能力，需要支持标准值域代码批量导入、扩展属性值域代码批量导入以及值域代码对照的批量导入能力。

值域规则管理

值域规则管理应具备值域规则分组管理和值域规则的管理维护能力，值域规则管理维护可以通过可视化页面定义类似身份证编码规则，将作为对应数据字段的取值范围约束规范。

支持值域规则定义

对值域规则进行定义描述，能够定义具体的值域规则编码、值域规则名称信息。能够对值域规则中包含的具体分段规则进行管理，能够新增、修改及删除具体的分段规则信息，包括分段规则具体遵循的相关标准。对已定义的值域规则，支持将其禁用，禁用后的值域规则将不再作为标准推广。

支持值域规则检索

为了便于值域规则的浏览查看，值域规则管理提供了按照值域规则编码、值域规则名称进行检索的能力。

支持值域规则批量导入

支持通过Excel批量导入值域代码，并能够下载对应的Excel模板文件，帮助用户快速实现值域规则的统一管理和标准化。

数据标准管理

数据标准管理提供了定义进入大数据中台的数据范围和规格，具体包括数据实体、实体属性、关联属性、属性取值范围、属性编码方式等。数据标准管理为实现农业农村大数据的"书同文、车同轨"的数据标准化提供了基础，通过数据标准管理能够规范各个主题域下的数据存储规范标准，提高了数据的可用性。

支持数据标准定义

数据标准对标准数据结构进行声明，能够将具体的数据标准文件进行数字化，支持基于数据标准文件结构进行数据标准定义描述，具体包括能够定义描述性内容，比如术语说明、概念说明等内容；能够定义描述具体的数据结构约束。

在定义数据结构约束时，支持选择已有的数据结构，或者通过组合已有的数据元形成新的数据结构约束。同时，能够基于物理数据表反向生成数据结构约束。

支持查看数据标准详情

为了便于查看以及执行相应的数据标准，数据标准管理支持查看已定义的数据标准详情，详情页能够对已定义的描述性标准项以及数据结构约束标准项进行有序展示。

支持数据标准检索

为了便于浏览查看数据标准，支持按照标准编码、名称条件对数据标准进行检索。

支持数据标准批量导入

为了便于数据标准的快速创建和维护，支持通过Excel批量导入数据标准信息，并能够下载对应的Excel模板文件。

数据加工体系建设

实时数据感知系统设计

实时数据感知主要是通过解析数据库的日志信息，实时感知原始数据的变化内容并将变化内容同步至目标数据库中，从而实现变更数据的实时采集和同步的能力。

实时数据感知以松散耦合的方式与现有业务系统集成，一方面可以避免对原有业务系统的影响，另一方面也可以充分兼容未来新业务系统的接入需求。

系统的架构采用业界先进的设计理念和成熟的技术路线，遵循自主可控、安全、高效、开放、稳定的原则，确保整个产品平台的安全性、高效性、易用性、可扩充性和可维护性。整体的系统架构如下所示：

实施数据感知系统架构图

系统架构可以分为以下几个部分：

执行引擎：依照用户设定的业务流程，完成对变更数据的捕获。通过重做日志采集和对数据库日志的解析，识别出变更数据内容；再通过事务的过滤、合成和加载等流程，实现事务的统一控制，确保事务的一致性和准确性。
控制台：控制台负责为用户提供多种管理和监控功能，包括数据采集的性能监控，异常情况的管理，采集任务的调度管理以及元数据的管理等。
第三方接口：系统提供了种类丰富的第三方服务接口，包括管理监控类的接口，以及服务集成类的接口等。通过上述服务接口，用户可以在第三方系统中进行产品的集成和二次开发，以满足用户不同业务场景的功能需求。

变更数据实时抽取

每次数据采集不能进行全量采集，需要识别出最后一次数据采集后的增量数据，数据采集操作仅针对增量数据部分。系统支持秒级的变更数据捕捉和同步，支持指定表及字段复制。

管理监控

管理监控模块用于维护和配置数据捕获与分发流程，提供用户选择相应任务执行，提供基于指定的时间点、时间段配置执行数据同步任务，并提供任务运行日志方便用户查看任务运行情况，允许用户全方位了解任务运行状况。

断点恢复

当系统与源端数据库网络连接失败时，系统能够自动记录断点，并挂起同步状态。当断网得到修复后，系统可以自动恢复同步任务，并从断点处继续捕获变更数据。

当由于网络等因素导致系统与数据库连接失败时，系统能够自动记录数据同步的断点，同时挂起同步状态。在网络环境等因素修复后，系统能够自动恢复同步任务，并从断点处继续捕获变更数据。

断网恢复

在网络发生故障时，系统可以将当前同步任务及时挂起，并且记录当前已经传输完成的字节数作为传输断点。在网络恢复时，系统能够自动在断点处继续同步数据。

断电恢复

实时数据采集系统可以被注册为操作系统的服务，支持服务托管与自动恢复能力。在注册为系统服务后，当系统在因意外断电重启后，可以自动启动任务，且在断点处自动恢复采集传输任务，无需人工干预即可自动启动系统后台服务。

告警功能

针对特定事件或异常情况，可以产生相关告警信息，并对告警信息进行统一管理，主要包括告警日志查看、告警任务管理、告警邮件设置、事件联系人管理和异常信息模板管理。

批量数据采集系统设计

批量数据采集系统主要是提供面向复杂网络环境和多样化数据环境的数据交换和传输服务，能够保证数据迁移和交换的持续性、时效性以及可靠性，为在复杂的数据环境下构建数据集成提供全面的技术支撑。

批量数据采集系统能够将不同来源、格式和特点的数据在逻辑上或物理上有机地集中，从而为业务单元提供全面的数据共享和支撑。

批量数据采集系统应采用业界先进的设计理念和成熟的技术路线。产品架构设计遵循自主可控、安全、高效、开放、稳定的原则，确保整个产品平台的安全性、高效性、易用性、可扩充性和可维护性。其系统功能架构如下所示：

批量数据采集系统架构图

产品的系统架构可以分为以下几个部分：

执行引擎：在执行引擎中，系统具备完善的读取和加载适配模块，可以适配国内外主流的数据库、文件数据源以及大数据平台数据源等。用户可以依托产品提供的各功能模块完成对交换任务的设定，包括数据的抽取策略、加载策略、数据清洗策略等核心交换流程。同时，客户可以通过交换流程编排模块对多个交换任务的执行顺序进行自定义编排，满足复杂的交换业务场景。对于保密性要求较高的情况，系统提供传输加密功能，以确保数据的安全性。
控制台：控制台负责为用户提供多种管理和监控功能，包括数据采集的性能监控，异常情况的管理，采集任务的调度管理以及元数据的管理等。
第三方接口：系统提供了种类丰富的第三方服务接口，包括管理监控类的接口，以及服务集成类的接口等。通过上述服务接口，用户可以在第三方系统中进行产品的集成和二次开发，以满足用户不同业务场景的功能需求。

支持数据源管理

系统的整体设计主要是通过适配器来兼容各种数据源、传送组件及相关技术组件，系统支持多种类型数据源主要通过DataBaseAdaptor、XMLAdaptor、ExcelAdaptor、HBaseAdaptor、TxtAdaptor、RecordAdaptor来兼容数据源，其中DataBaseAdaptor用来兼容数据库类型数据源，XMLAdaptor用来兼容XML数据源，ExcelAdaptor用来兼容Excel数据源，HBaseAdaptor用来兼容HBase数据源，TxtAdaptor用来兼容TXT数据源，RecordAdaptor用来兼容自定义扩展数据源，如PDF、word、dbf等。

目前经过安全、可靠性测试数据源有：

支持Oracle、MySQL、PostgreSQL、SQLServer、DB2、Sybase、神通、达梦、人大金仓、南大通用、虚谷、浪潮等国内外主流关系型数据库；
支持XML，Excel、文本数据；
支持Greenplum、Netezza、HBase、MongDB、Hive、Impala等数据源；
支持WebService接口数据源和HDFS文件系统；
支持创建Shell/Batch脚本任务，可以监控脚本执行的过程和结果；
自定义存储过程、自定义SQL、自定义JAVA程序等；
支持灵活的扩展支持新的数据源，如LDAP等。

数据源定义图

支持节点管理

在分布式部署时，能够将所有的分布式节点进行统一的拓扑图形化管理，可以实时监控所有分布式交换节点的在线或离线状态。交换中心的管理员可以远程登录到下级分布式节点进行数据的管理和维护

节点管理图

此外，分布式节点应提供分组管理功能，可以通过拖拽的形式将某个节点划分到某一个分组中。

支持批量数据抽取

通过数据交换服务，数据抽取模块依据映射模型配置的抽取规则，访问数据源，将数据抽取至内存、文件（XML、文本文件）或数据流的形式，抽取的内容可以做后续的数据质量稽核、加工、传输或加载操作。主要数据抽取模式包括：

全量抽取。抽取元数据所包含的表在指定数据源中的全部数据。
时间戳增量抽取。该功能需要利用数据中的递增字段进行数据抽取，主要通过在SQL语句上拼接增量字段的区间范围进行数据抽取。
快照增量数据捕获。在数据表没有任何增量标识的情况下，通过对比上次数据缓存快照分析出数据的增、删、改操作。
外部接口抽取。在任务管理中，新建任务时需要自动生成对应的WebService服务，该功能主要通过通用Web服务接口将任务直接生成对外服务接口。
文件抽取。文件做为数据同步的一种适配器，主要能够满足对数据文件的读、写、解析操作，文件抽取主要通过这个文件适配器来实现，如ExcelAdaptorImpl、XMLAdaptorImpl、TXTAdaptorImpl等。
文件压缩。若需要抽取的数据文件为压缩的数据，需要系统进行解压或直接以zip流方式抽取数据文件，然后将数据解析推向后续处理。
自定义SQL查询。查询数据源除了直接针对表、视图之外，也可以直接使用用户自定义的sql语句，将sql语句产生的结果集读取到ETL引擎中，供后续转化、清洗、加载使用。

支持数据传输

接收数据抽取的数据、其他应用系统或人工提供的数据，实现数据的双向传输操作，通过指定的端口实现不同部门两端数据交换系统对接，实现与网闸设备进行对接，实现数据基于内存或落地文件的传输。本系统数据传输方案采用通用的数据传输接口，即传输接口统一，针对于不同的实现，采用不同的传输协议。

主要功能包括：

协议支持。在数据传输层，提供一个通用传输适配接口，由此扩展出各种传输适配器，如HTTP、FTP、SFTP等传输适配器。
加密传输。数据传输过程中，为防止数据被截获或恶意破坏，需要通过安全算法对数据进行处理。
压缩与解压缩。为节省网络消耗，可选择的对数据进行压缩、解压缩处理，在数据解压缩时要根据压缩算法自动适配进行解压。
异常处理。在传输过程发生异常时，系统记忆发生错误时传输数据的位置，再次执行时优先从上次断开位置开始执行。
并行。在整个数据传输过程中，传输性能可以通过增加传输线程数提示传输效率。

支持批量数据加载

数据加载动作依据映射模型配置的加载规则，访问实际的数据源接口，实现将内存数据、文件数据或来源于其它系统的数据，加载至数据库、文件存储、Hbase、GlusterFS等或以数据流的形式发布到webservice接口或其他应用系统。

主要功能如下：

数据加载策略。数据抽取组件抽取出的增量数据中含有增量标识，默认为I-表示insert，U-表示update，D-表示delete，数据加载组件需要读取数据数据中增量标识，按标识类型进行数据处理，若insert过程失败，则尝试进行update。
数据唯一性。在数据写入目标数据源时，可选择配置去重操作，若同一个数据联系出现两次，则可被自动忽略掉，如相同标识数据间隔距离较大则用最后一次数据覆盖之前写入的数据。
数据完备性。在识别数据完整性方面，可以配置字段完整性校验策略，在数据加载过程中，若数据配置了字段完整性，则优先校验字段数据是否存在，若存在则忽略，若不存在则填补字段值。
对外服务。任意新建任务都可以生成对应的WebService服务，该功能主要通过通用Web服务接口将任务直接生成对外服务接口。
并行。在整个数据同步过程中，系统的加载性能也可以由系统某些参数进行调整，主要包括加载线程数，其中线程数对加载性能提升应该最为明显。
异常处理。在数据加载过程发生异常时，系统记忆发生错误时加载数据的位置，再次执行时优先从上次错误的位置开始加载。

支持资源关系

提供系统内部资源关系的数据流向展示，可按照数据流入、流出进行数据过滤。同时可以提供数据源、数据表级别的数据流向展示，可查看、编辑某一个数据源/数据表关联的元数据、映射、任务和调度等信息。

支持多种任务触发方式

系统提供三种任务触发方式，以满足不同场景下的业务需求，这三种方式分别是人工手动触发、调度定时触发、事件接口触发。

手动触发

手动触发，常应用调试期，业务尚未稳定时，常用手动触发调试问题，在系统监控页面便可手动触发。

调度触发

调度触发是最常用的触发方式。系统在正式上线后，经常会通过调度功能将相关的业务进行编排，并使得相关业务自动化周期运行，避免人工干预。

调度配置策略支持妙计分钟级、小时级、每天、每周、每月等，同时支持用户自定义配置任意的执行周期。

调度支持与一到多个交换任务关联，同时交换任务支持同时被一到多个调度触发执行。

此外，调度管理可以按名称等条件进行快速检索查询，支持用户预览某个调度的未来执行计划。

事件接口触发

事件接口触发，主要通过主动触发任务进行数据交换，常见于对实时性要求极高的业务，数据延迟为毫秒级。

支持系统审计

系统支持审计日志功能，包括记录用户登入登出操作信息，以及登录系统后的所有增、删、改等操作信息，并可根据用户名称和时间轴进行过滤。

用户操作审计

系统对关键操作均进行留痕处理，将一些操作的关键信息进行持久化保存，以方便后续的用户操作审计。

系统支持针对如下操作进行留痕处理：

1.用户登录、登出情况

2.数据交换任务管理、配置情况

3.数据交换任务运行情况

4.所有异常情况

系统以列表的方式提供了系统审计的详细信息，信息主要包括：用户、行为、行为描述和发生时间。其中，针对行为和行为描述，系统提供了运行期的可视化的配置方式。

系统提供三种查询维度，详细描述如下：

用户

系统提供对指定用户的操作记录的过滤查看。

行为

系统提供对指定行为（系统登入、系统登出等）的操作记录的过滤查看。

时间

系统缺省提供对当天的系统审计详细信息的展现。用户也可以调整统计时间区间，主要包括：今天、昨天、全部以及指定时间段。

系统数据审计

系统提供交换任务模板的列表，该列表中主要包含最后一次任务执行的状态、任务模板标识、任务模板名称和触发方式等，可以方便对系统任务的执行结果进行审计。

点击某个任务模板的状态，系统提供与交换任务规则配置一致的图形化监控页面，在该页面中可以查看每个步骤的执行细节。

在监控页面中，可以查看任务的开始时间、结束时间、持续时间、任务步骤的状态。点击某个步骤，可以查看步骤的持续时间及步骤相关的日志信息，如数据输入记录数，输出记录数等。默认展现任务步骤的概要信息，针对ETL类型的步骤，可以点击页面中的"明细"按钮查看任务的详细运行信息。针对ETL步骤，可以查看源端输入的类型，如果是数据库类型，展现源端数据源、查询SQL语句、抽取方式、输入记录数等信息；同时目标端也会列出目标数据源、插入SQL语句、成功记录数以及成功明细等信息。

审计日志查看

系统支持对审计日志的查询，并支持根据时间、用户、类型等进行过滤与定位。

支持系统监控

允许用户查看系统信息，包括CPU使用率、内存使用率和磁盘使用率，以及系统环境参数，如操作系统、IP地址、CPU核数、和物理内存等等。

支持系统日志

能够记录系统的所有日志信息，包括常规信息、错误信息和忽略信息等，支持日志查看、检索、导出和清空等功能。

系统日志图

支持告警功能

系统针对特定事件或异常情况，可以产生相关告警信息，并对告警信息进行统一管理，主要包括告警日志查看、告警任务管理、告警邮件设置、事件联系人管理和异常信息模板管理。

系统通过列表方式，详细地展现了产生告警的相关属性信息，主要包括：告警标题、触发事件、告警类型、告警状态、告警时间和告警详情（形如"任务Oid[xxxx]产生告警"）。

告警日志查看

告警日志查看页面，缺省提供当天的告警信息展现，用户也可以调整统计时间区间，主要包括：今天、昨天、全部以及指定时间段。同时如果告警信息较多时，系统提供快速搜索过滤功能。

告警日志查看图

告警任务管理

告警任务管理提供了告警任务的新建、编辑、删除、启用/禁用和关联数据交换任务等功能。

新建告警任务，需要用户填写告警名称、告警描述，以及选择触发事件、告警类型和告警级别。其中触发事件包括任务启动、任务停止和任务异常，告警类型包括写入日志、发送邮件等。触发事件和告警类型均可多选。最后，需要关联相关联系人，即告警信息的接收人，可关联多人。

系统通过列表方式展现所有创建的告警任务信息，用户可以选定某个告警任务进行启用或禁用，也可以进行任务关联。任务关联是指告警任务对哪些数据交换任务生效，同一告警任务可关联多个数据交换任务。

告警任务配置完毕后，系统自动在数据交换任务的全生命周期管理过程中，依据既定告警规则，实时产生相应的告警信息。

告警任务管理图

告警邮件设置

若需发送通知电子邮件，需要设置相关邮件服务器的信息。

告警邮件设置图

事件联系人

联系人即是告警信息的接收人，系统提供了联系人的新建、编辑和删除。新建联系人，用户需要填写人员名称、邮箱和手机号码。

事件联系人图

异常信息模版

异常信息模版是系统发送异常时，参考模版生成相应的提示信息，并通过邮件方式将此信息发送给联系人。异常信息模版管理页面如下：

、

异常信息模板管理图

支持异常处理

异常处理是系统异常处理的核心控制模块，为其他功能模块提供异常处理接口和错误处理方法。在其他模块有异常发生时，可以抛出指定范围的异常码和错误信息，也可以进行异常处理，为系统任务恢复执行、断点续传、错误数据处理提供接口。

主要功能如下：

自动恢复。在数据交换服务宕机或数据同步发生错误时，要通过异常处理接口记忆错误信息，并进行持久化记忆，当系统重启或任务自动恢复时，利用记忆的错误信息恢复执行。
断点续抽。在数据抽取过程发生异常时，系统记忆发生错误时抽取数据的位置，再次执行时优先从上次错误的位置开始执行。
断点加载。在数据加载过程发生异常时，系统记忆发生错误时加载数据的位置，再次执行时优先从上次错误的位置开始加载。
断点传输。在数据传输过程发生异常时，系统记忆发生错误时传输数据的位置，再次执行时优先从上次错误的位置开始传输。
忽略处理。在数据处理过程发生异常时，若配置异常可忽略，则忽略错误数据，并计入日志；若不可忽略，则直接停止执行，并抛出异常，等待人为干预。

支持网络隔离

网络隔离交换主要实现通过网闸或在物理隔离的情况下，实现离线交换功能。网络隔离交换，需要在网络两端分别部署数据交换系统，网络隔离的传输可以使用网闸设备。

如果使用网闸，则通过网闸摆渡数据文件，如果网闸设备提供触发的接口，数据发送操作直接调用网闸设备的接口发送数据。如果物理隔离，则通过手工摆渡数据文件。

支持调度管理

调度规则管理主要用于定时执行数据交换任务。定制好某个数据交换任务模板后，通过调度管理对任务进行调度（定时执行任务），提供关联数据交换任务、查看关联数据交换任务、取消关联数据交换任务功能。调度可以与一到多个交换任务关联，同时交换任务也可以同时被一到多个调度触发执行。

具体的调度周期可以提供分钟级、小时级、天级、周级和月级的自动执行策略，同时允许用户按照特定的业务需求，自定义配置出任意的执行周期。周期性执行的交换任务要求同时支持手动和实时接口触发的执行方式。

该模块主要应用在重复频率较高的数据交换场景，能够自动完成已经定制好的数据交换流程而无需人工参与。

应用系统数据采集系统设计

应用数据数据采集系统可以基于系统的展现层内容，实现与系统应用层的数据连接、开采和融合，能够智能地识别与连接不同业务系统之间的应用逻辑。

在无法获悉业务系统的数据库连接信息和系统接口时，可以通过应用数据连接重构业务系统的数据读、写的API接口，实现业务数据的获取以及业务数据的系统回写功能，进而达到对已有业务系统的数据开放、对接、交互和重构等建设目标，构建跨平台、跨领域的采集、开放、共享、融合的大数据支撑环境。

产品架构设计遵循自主可控、安全、高效、开放、稳定的原则，确保整个产品平台的安全性、高效性、易用性、可扩充性和可维护性。其系统功能架构如下所示：

应用系统数据采集系统架构图

产品的系统架构可以分为以下2个部分：

配置管理功能：该功能主要面向业务实施部门的施工人员。通过配置管理功能，实施人员依据客户业务需求进行接口构建，包括业务数据的获取、返回数据的整合、转换与清洗等，最终形成交付给客户的接口。
运维管理功能：该功能主要面向业务人员。业务人员通过运维管理功能可以维护和管理接口，包括监控接口的调用情况，接口的申请和审批管理，以及接口的授权控制等。

支持业务数据的智能识别

系统能够将业务系统的功能构建成数据API读取和写入接口，以便使用者调用，实现业务数据获取或回写等功能。全程无需获取业务系统的源码或开放业务系统的数据库，也无需业务系统开发API接口进行系统集成，对源系统完全无侵入。

支持单点登录访问策略

系统针对需要登录验证的网站，提供单点登录访问策略。用户只需要在产品中登录一次网站后，即可多次调用封装后的API接口，无需在每次调用接口前进行重复登录操作，减少后台服务器访问、验证负担，提升接口响应效率。

支持数据安全管理

系统提供完全的数据安全管理能力，具体包括：

接口使用时，使用者需要提交申请，管理员审批后可正常使用。

设定数据资源项是否隐藏：针对数据资源中的某一项，管理员可以设定为对外公开或者对外隐藏。

当管理员设定某一个数据资源项为隐藏时，数据调用者获取的数据资源中，将对该项信息不可见。反之，数据调用者则可以正常获取并可见。

设定隐藏项图

支持IP地址访问控制功能

系统可以在系统配置功能中，以白名单的形式控制IP地址访问权限，不在IP地址白名单内的IP地址无法调用API接口。访问地址控制功能提供两级设置，包括全局设置和用户列表的白名单设置。

全局设置：在用户启用白名单功能后，可以在全局设置中添加允许访问的IP地址。在白名单内的IP地址可以顺利访问客户应用端进行接口调用、维护等操作。

用户列表的白名单设置：在用户列表中选中某一个用户后，系统管理员可以在右侧添加允许该用户访问的白名单。在后续的使用中，当该用户尝试登录系统时，其IP地址必须在用户列表的白名单范围内才可以成功登陆，否则登陆失败。

访问地址控制图

支持数据服务调试功能

内嵌数据服务调试功能，可基于自定义的条件格式和数据内容调试服务接口，便于用户实时掌握接口的健康状态。

支持仪表盘统计功能

通过仪表盘提供数据服务系统概览，包括"数据源数量"、"接口数量"、"用户数量"等数据。此外，仪表盘还应提供"接口访问趋势图"、"用户访问TOP"、"接口访问TOP"等分析数据，并允许用户自定义时间段进行联动数据的统计分析，方便用户全面掌握系统的数据服务使用情况。

此外，仪表盘还提供"接口访问趋势图"、"用户访问TOP"、"接口访问TOP"等分析数据，并允许用户自定义时间段进行联动数据的统计分析。

接口访问趋势图可以帮助用户查看特性时间段内，系统接口的被访问次数。同时，用户也可以查看在特定时间段内，访问最多的用户TOP5和被调用最多的接口TOP5，以方便用户快捷的掌握管理信息。

仪表盘之统计功能图

支持告警功能

统针对特定事件或异常情况，可以产生相关告警信息，并对告警信息进行统一管理，主要包括告警日志查看、告警任务管理、告警邮件设置、事件联系人管理和异常信息模板管理。

告警日志查看

告警日志查看图

告警任务管理

告警任务管理提供了告警任务的新建、编辑、删除、启用/禁用和关联数据交换任务等功能。

新建告警任务，需要用户填写告警名称、告警描述，以及选择触发事件、告警类型。其中触发事件包括任务启动、任务暂停、任务停止和任务异常，告警类型包括写入日志、发送邮件等。触发事件和告警类型均可多选。最后，需要关联相关联系人，即告警信息的接收人，可关联多人。

告警任务配置完毕后，系统自动在数据交换任务的全生命周期管理过程中，依据既定告警规则，实时产生相应的告警信息。

告警任务管理图

告警邮件设置

若需发送通知电子邮件，需要设置相关邮件服务器的信息。

告警邮件设置图

联系人

联系人即是告警信息的接收人，系统提供了联系人的新建、编辑和删除。新建联系人，用户需要填写人员名称、邮箱和手机号码。

事件联系人图

异常信息模版

异常信息模版是系统发送异常时，参考模版生成相应的提示信息，并通过邮件方式将此信息发送给联系人。异常信息模版管理页面如下：

异常信息模板管理图

支持审计日志

产品将用户对数据服务的调用时间、调用行为、调用结果、客户端IP和登出系统时间等信息都可以持久化到数据库中，形成审计日志以便后续查询审计。

审计日志实时及历史查询图

业务日志数据采集系统设计

业务日志数据采集系统部署在应用系统上或者被采集系统主动发送数据到日志平台，平台提供web界面供日志查询。平台分为采集端、消息中间件、日志存储、日志分析及展示层。采集端负责日志数据的收集、消息中间件负责数据缓存、日志存储负责数据索引及统一存储、日志分析及展示层负责提供日志数据查询及可视化等功能。

在平台架构方面，主要分为以下主要层次，"日志采集与预处理服务"层最主要的特征是采取了插件化可配置的预处理逻辑，它以管道过滤器模式来实现数据采集与预处理过程，数据接入-中间处理-结果输出至存储的过程是由一组粒度较小、具有可复用性的过滤器组件顺序联合完成。该过滤器链将以配置的方式来进行组合启动。另外，除了使用预置插件外，还可以自定义开发插件。如此将可以较灵活地应对多种内容、多种格式以及规则发生变化的情况。

在"日志存储服务"层，将通过水平扩展性来应对海量数据存储问题，基于NoSQL存储技术来实现高效的数据读写，使用全文索引功能来确保数据检索的查询效率。其自身对外提供全功能的RestAPI，为上层的分析展现应用面向业务进行定制扩展开发提供技术支持基础。

在"业务层"，都是基于平台工具进行参数化配置后生成，后台参数管理需要定制化开发，供运维人员配置使用。其中自定义报表工具提供报表可视化配置工具，日志分析提供DSL查询语言，可以实现关联性分析、快速定位、统计查询、安全事件回顾与调查等功能。

在"用户层"，首先该层次主要提供丰富的强大的数据可视化组件，用以展现数据检索与统计分析结果。另外，在该层次中可以按照业务来划分查询分析子模块，并提供了大屏显示等展现形式供客户选择。

日志平台整体架构图

数据来源分析

日志平台可以及时捕捉采集各类软件、数据的运行状态及结果，为数据集成的日常运行提供信息采集。平台支持根据业务类型采集日志，以可视化方式展示数据湖中总的数据构成、数据比重及数据校核问题数量等，同时各业务作为一个数据来源也需要展示每个数据源的数据构成、数据比重及数据校核问题数量等。日志平台能够采集常见的数据源指标项包括系所有进程信息、按进程的CPU资源占用信息、按进程的内存资源占用信息、数据构成、数据比重及数据校核问题数量信息等。

数据质量分析

日志平台支持数据质量分析，可以从数据实时性、数据准确性及数据完备性三个维度进行分析，按照一定规则和权重进行合理评分。不同数据源对数据的实时性、准确性和完备性有不同的校验规则，需要结合已有数据质量校验产品输出的日志数据进行分析，以可视化方式进行展示。

数据共享服务及功能使用分析

日志平台可以通过数据监控发现的问题纷繁复杂，需要按照任务形式进行管理，问题追溯功能不仅能够提供问题追溯任务管理功能，而且提供问题追溯的分析工具，调取监控日志，帮助用户进行问题的排查纠错，然后调用问题排查报告功能对问题追溯任务进行记录归档。具体功能包括问题追溯任务管理、问题追溯分析、问题排查报告。数据分析部门会把采集汇总的数据进行包装，以API接口服务和功能菜单（页面）的方式提供给各数据消费部门进行使用。根据API的调用日志及页面的访问日志，进行可视化分析，合理评估功能的使用情况，促进数据的共享使用，最大化地挖掘数据的价值。

实时监控大屏

以上3部分内容，需要集成在一个或多个可视化大屏的页面中进行可视化展示，辅助以一定的动态交互效果，并支持数据的下钻分析。日志平台所采集监控信息量大且纷繁复杂，平台提供可视化的数据查看分析工具，以便于用户直观的了解数据所反映的系统、数据状况。监控可视化展现功能将每个数据项作为一个图形元素表示，将数据的各个属性值以多维数据的形式表示，可以从不同的维度观察数字信息，利用图表和仪表盘等形式实现数据的可视化，帮助用户对海量的监控信息能快速、精确、科学的理解数据含义，提高数据分析能力，从而对数据进行更深入的观察和分析。

人工填报数据采集系统设计

分析本项目的需求现状，存在组织机构规模大、数据采集场景多的特点。对于要采集的数据内容具有涉及广泛、构成多变、个性化定制较强等要求。通过人工填报数据采集可构建众多填报、上报业务，实现数据的快速采集，提高业务敏捷能力。实现采集高效、结果全面、过程可控的目标。

人工填报采集业务系统，以数据收集、数据管理为中心。通过快捷的表单定义工具、流程定义工具、报表统计工具，敏捷实现对数据采集、数据处理的快速实现。并通过社交化方式（多种手段），实现多人间的协作，并自动实现收集数据及结果分析。

格式化表单定义

为方便用户使用，提供基于WEB的表单设计工具，即通过浏览器界面即可完整设计所见即所得的表单。设计完成后，无需重新测试、部署系统，即时生效。

支持面向业务人员的简单绘制表单

通过拖拽或者点击控件，即可在鼠标位置添加相应控件。通过与元数据关联屏蔽技术细节，无需编写任何 SQL 代码。

支持多种布局方式

提供多行多列式的自适应布局样式，以满足简单表单在不同设备上的展现；同时还支持 Table 样式，以满足对表单样式有严格要求的复杂表单绘制。

支持零编码实现业务表单自动映射业务数据表的功能

表单数据可以直接和数据中心的数据进行关联。同时，如果是新增临时数据，表单绘制保存时能够自动生成业务数据库表，并自动完成表单输入域和数据库表相应字段的关系绑定。

表单源码支持自定义添加事件，自定义添加样式等

通过表单的源码视图，可以添加自定义事件、添加自定义样式文件等，满足个性化需求。

提供丰富的表单控件

包含标签、文本框、按钮、日期、下拉列表、单选按钮组、多选按钮组、图片、数据表格、附件上传等。同时控件提供丰富的属性配置，包括 ID 、名称、数据绑定、样式等。另外控件支持必要的合法性校验，例如：必填、邮箱、电话号码等。

问卷定义

智能填报平台除了支持定义数据采集以及流程审批业务外，还支持对调查问卷的快速定义与分发，具体功能包括：

基于WEB的问卷设计工具

调查问卷设计工具支持常见的表单控件类型，且提供一种简便的方式快速定义调查问卷。

调查问卷支持内部分发以及外部分发

发起调查时支持内部调查以及外部分发，内部调查时需指定组织内人员，人员需要登录后才可以访问调查问卷；对于外部调查不需要指定参与人，支持生成二维码或者访问链接，访问不做权限控制。

调查问卷支持截止时间

发起调查时支持设置截止时间，超过截止时间后，调查问卷自动失效，不再允许访问。

调查问卷支持反馈查看

调查问卷发起者可随时查看反馈信息，同时可以以多种维度自动生成统计信息。

多渠道分发

在数据采集过程中，为方便填写人获得填报任务，可以将填报任务以多种形式进行推送。填报发起人可以设置监控，以实时了解各填写人填写情况。支持订阅填写人提交操作的动态信息。（可选）支持与用户APP的对接。

推送到统一待办任务中心

对于内部分发，可以推送到统一待办任务中心，填写人员登录后，通过打开任务可以进行填写。

生成二维码（可直接扫描填写）

可以直接扫描填写，或者将链接分享到朋友圈。

填报任务分发图

填报任务办理

通过填报服务系统发布的填报服务支持 PC 和移动端访问。表单工具开发出的表单能够自动适应多种终端，包括PC、智能手机等，并且自动以适合移动设备操作习惯的最佳显示效果适配不同屏幕大小、不同分辨率的移动设备。

运行期填表图

典型处理动作包括如下：

暂存：任务未办理完成，暂时保存当前的任务办理状态

同意：同意在此之前完成的办理意见，完成当前任务办理，流程向下流转

送达：按照既定的流程动态改变临近的下一节点的办理人，将任务指派给该办理人

回退：当前办理人不同意之前完成的办理意见，驳回当前任务到指定节点

终止：当前办理人终止当前的任务办理

传阅：将任务抄送给指定人员审阅，无需此人办理

沟通：任务原定办理人收到工作任务后，把该工作任务分配给他人办理。任务办理完成后，将办理结果反馈回原办理人

重新填报：重新启动填表服务

导出：导出当前表单单据

由于每个移动设备显示特定网页的方式不同，因此表单的实际外观将随访问它的设备而变。在表单设计器设计表单模板时，支持在定义期预览各种设备上的显示效果。

支持移动端填表图

数据自动归集、统计、导出

每个表单样式各有不同，填报系统能够根据表单内容属性（如数据输入域的类型）自动生成各种汇总数据分析报表，并通过统一界面集中展现各报表。

基于数字、日期的等类型的可计算属性进行数字运算统计。典型的数据统计方式包括合计，以及基于下拉/单选/复选项的分组、小计计算等。

当表单中增加相应的属性域后，统计报表自动更新。

针对结果数据，支持数据导出功能，导出格式包括：Excel 、PDF等，导出内容包括数据明细及相应统计报表。

结果数据统计分析图

业务集成管理

填报权限管理

对于同一张表单经常是由不同的人填写不同的域，表单权限设置的目的是使不同的用户对同一表单具有不同的操作。

表单的授权和表单的定义是分离的，在定义表单时无需关心它的权限。且可以随需应变，减少了维护的工作量和工作难度。同时支持权限快速设置以及权限复制。

表单的权限设置包括表单控件的读写可见权限、表单的提交和打印权限。权限的设置是可选的。如果不使用任何权限，所有人对表单都有相同的权限。如果应用了权限，将有两个因素决定一个表单的权限，分别是流程和用户。同一个表单可能会在不同的流程使用，但在两个流程中的权限不同。同一个流程内不同的用户也有可能具有不同的权限。

与业务数据的对接与集成

对于各公司，可能存在众多的业务系统，数据也多分布在多个系统中（或数据中心）。填报服务系统支持与业务数据的对接，包括读取及写入。

表单支持数据源的管理。基于数据服务模块提供的统一数据接口，支持在应用下建立和维护多种类型的数据源，包括关系数据库、非关系数据库作为数据源、Web 服务作为数据源。支持多数据源并存。

表单构件支持元数据自动抽取管理和自动数据集的自动生成。支持自动从获取数据源抽取可用元数据并结构化展示；支持基于自动抽取的元数据自动生成操作数据集。支持数据回写到目标数据源。

与业务应用系统的集成

业务部门的应用系统可与填报服务进行集成。以组织内的门户系统为例，可以将填报服务，以URL形式添加到门户中，通过统一认证和权限控制，方便业务人员无需登录档案相关系统，即可上报相关数据、文件。通过填报系统，可实时查看获得的数据。

数据转换与清洗系统设计

数据转换与清洗是创建ETL流程模板的图形化定义工具。其设计旨在使数据集成配置人员能够快捷地定义ETL流程中数据抽取（Extract）、转换（Transform）和加载（Load）等过程。

通过单一方式访问、转换、清洗和加载数据，适用于数据仓库、数据迁移等应用场景。内置大量数据转换模型，遵从国际化标准以及国家众多行业标准，几十种通用的转换规则如类型转换、字段拆分、字段合并、字符串处理、日期转换、算术运算、码表转换等，同时提供自定义转换接口实现特殊的数据转换处理。

系统可以通过单一方式访问、转换、清洗和加载数据，能够将原始业务数据按照规范的标准进行转换清洗，从而实现数据的标准化。

系统应采用业界先进的设计理念和成熟的技术路线。架构设计遵循自主可控、安全、高效、开放、稳定的原则，确保整个产品平台的安全性、高效性、易用性、可扩充性和可维护性。其系统功能架构如下所示：

数据转换与清洗系统架构图

产品的系统架构可以分为以下几个部分：

执行引擎：在执行引擎中，系统具备完善的读取和加载适配模块，可以适配国内外主流的数据库、文件数据源以及大数据平台数据源等。在抽取和加载时，可以实现单表的多线程并行操作。同时，用户可以根据业务需求场景将数据进行多种转换与清洗，最终将标准的数据加载入库。
控制台：控制台负责为用户提供多种管理和监控功能，包括数据采集的性能监控，采集任务的调度管理以及元数据的管理等。
第三方接口：系统提供了种类丰富的第三方服务接口，包括管理监控类的接口，以及服务集成类的接口等。通过上述服务接口，用户可以在第三方系统中进行产品的集成和二次开发，以满足用户不同业务场景的功能需求。

支持异构数据源整合

系统能够实现主流的关系型和非关系型数据库、XML文档、文本数据、Excel、WebService接口以及主流的大数据引擎之间的异构数据整合等，同时可以灵活的扩展新的数据源，以满足未来业务系统的扩展接入需求。

支持图形化映射工具

提供完全基于Web的数据转换流程的图形化配置工具，使数据集成配置人员能够快捷地定义数据转换流程中数据抽取（Extract）、转换（Transform）、加载（Load）过程。

映射是数据转换与清洗的核心功能之一，提供业务源与业务目标的映射关系管理，包括字段映射、抽取规则、数据加载规则等。映射工具产品是基于Web技术实现的图形化ETL转换与映射。提供多种数据抽取策略、数据加载策略以及数据清洗等功能。

基于Web的ETL功能图

支持数据抽取

系统支持多种捕获变化数据的抽取策略，主要包括全量抽取、时间戳增量抽取、标志位增量抽取、快照比对增量抽取等。

数据加载策略图

全量抽取

在全量抽取模式下，系统会将源端数据源的所有数据同步到目标端数据源。该模式主要用于数据同步初始化的场景中。

时间戳增量抽取

利用业务表中时间戳字段来实现增量数据的捕获。时间戳、标志位抽取方式结合使用可以实现指定时间间隔内增量数据的按操作类型的抽取（如1表示修改，2表示插入，3表示删除），实现源端、目的端数据源的数据同步。

标志位增量抽取

利用业务表中标志位字段来实现增量数据的捕获，用不同的状态表示不同的数据库操作，如1表示修改，2表示插入，3表示删除，0表示无变化，抽取时只抽取被改变的数据，已抽取的记录将状态置为0。

快照比对增量抽取

快照方式在不改变原有数据库结构，不侵入原始数据库结构，不影响业务数据库性能的同时完成增量数据抽取。这种方式通用性强，可维护性好，适用于没有时间戳、标志位字段，又不能创建触发器的的业务，且性能较好。

支持数据转换

系统应提供多种内置的数据转换组件，如字段拆分、合并、常量、替换、码表、字符串截取、数据路由、类型转换、频率统计、计算表达式、大小写转换、字符串重组、字符串反转、去除字段收尾空格、获取增量标识和序列等多种数据转换。

用户还可以通过JavaScript或Java等方式添加自定义转换节点，以实现自定义扩展新的转换规则，满足不同业务场景的转换需求。

数据存储体系建设

存储方案设计

分布式数据存储平台提供了多样性的数据存储机制，服务于不同的数据结构与存取需求，其中NoSQL存储主要作为海量分析数据的存储设施、关系数据库则主要作为平台支撑数据的存储设施、文件系统主要作为离线数据的存储设施、而搜索引擎则提供了数据检索的功能基础，各存储机制之间通过统一的DSL智能引擎向上提供数据资源，为上层应用数据基础。

针对数据存储，平台提出了"数据湖"概念，内部包含多种存储介质，包括Hadoop HDFS分布式文件系统、Elasticsearch存储、Hadoop Hbase存储、关系型数据存储等，全面满足各类数据的存储需求。

在数据存储的同时，还集成了分布式数据缓存、分布式计算框架，实时数据检索的功能，让数据存储和数据查询紧密结合起来。

数据存储组件图

分布式存储设计

分布式存储平台提供了多样性的数据存储机制，服务于不同的数据结构与存取需求，其中NoSQL存储主要作为海量分析数据的存储设施、关系数据库则主要作为平台支撑数据的存储设施、文件系统主要作为离线数据的存储设施、而搜索引擎则提供了数据检索的功能基础。

分布式存储平台模块中除了包括以上对应不同需求的存储机制外，更重要地是提供了统一的存储访问层。该访问层本质是一个API框架，其作用在于：

1、简化对各类型持久化存储的访问、操作方式；

2、对外提供一种通用的开发模式。

首先，该层的存在就使得屏蔽底层存储细节成为了可能，进而可允许存储服务模块的底层升级、改造与优化工作平滑进行。事实上，作为大数据平台的核心组成部分，以软件演化的观点来看，该子平台存在长期优化、调整的现实需求。那么统一的屏蔽底层基础实现的访问层就成为了必要性设计。

另外，该层次不仅简化而且统一了持久化存储的访问操作模式，这为上层应用的扩展开发提供了便利，使得开发过程与软件质量的可控性大大增强。

关于"统一持久化访问层"的组成示意如图所示。其中"数据源映射"的作用为抽象各种异构数据源对象，"对象映射"的作用为将数据库中的数据结构映射为程序对象，"操作模板"的作用为将一些像"分页"、"按id查找"等常用的编程操作固化为模板方法。

统一持久化访问层示意图

存储容量的线性扩展

在分布式存储平台模块中，多种不同机制的存储设施机制不同、各有所长，其应用分工也各有差异。关系型存储多数工作与平台运行支撑的目的，比如用户与组织信息的维护、权限信息的维护以及其他内容的关系型数据等；而服务于分析性数据源的存储设施主要是NoSQL数据库与分布式文件系统。关系型存储无论其基础模型还是应用需求大都对应了有限的相对少量数据的存储需求；但是NoSQL与分布式文件系统的设计主要是为了应对海量数据规模的增长问题，其最重要的特点即在于以水平扩容的手段来匹配数据量的增长。该种方法的优势在于成本可控，可按需伸缩，且相对于纵向扩容手段将存储处理极限大大提高。通常理论上而言，线性增长将会带来容量的无上限扩充。不过在具体应用中，由于网络、计算资源和可管理性等方面的限制，节点数量与容量的关系会在一定的区间范围内存在一个近线性的关系。不过就算实际物理计算环境等客观条件会有所限制，但较之于纵向单机扩容的方法而言，该种方法可以较容易地将存储容量极限提升至TB~PB级别。

参考逻辑架构

在分布式数据存储服务提供的细分服务中，被分析的大规模的数据通常进入NoSQL数据库存储进而提供在线的即时数据服务；搜索引擎则提供高效的数据检索服务；分布式文件系统主要用于归档管理或者旧数据的挖掘分析等离线性质的工作；关系数据库提供支撑数据存储服务。整体上的逻辑结构如图所示。

分布式数据存储服务逻辑架构参考图

其中相对比较简单的是"关系数据库存储"，它相对数据量较小，但支撑数据同样具备一定的重要性，所以做双节点HA集群配置即可。

"分布式文件系统"部分将文件系统扩展到一个多机网络环境下，并且屏蔽了数据在网络中的分布细节，提供统一的文件读写上下文。

"NoSQL数据库存储服务"是一种面向与Document的数据存储设施，它将会承担绝大部分的在线海量数据的存储工作。首先为了提升数据读写效率对集群内部可做读写分离配置，数据将以分片（shard）为单位在节点间进行迁移和同步。并且数据分片将会被委派"主分片"和"从分片"两种角色，主分片承担数据更新与副本分发控制工作，此处通过数据冗余的手段来保证数据的高可用。

"搜索引擎"服务将提供数据检索服务，其原始数据源主要是NoSQL存储中的在线数据。为了提升数据检索效率，将以多索引集群加前端路由服务的方式来对外提供检索服务。进一步须说明的是每个索引集群都是通过索引数据冗余来保证高可用的并提高并发查询执行效率。

这些存储子部分每个都是一个独立的服务，相互之间并无耦合，所以可以分开来看待。各种类型存储适用于不同的存储场景。具体特点与对应关系如下图所示：

存储服务中的数据存储机制与用例示意图

分布式存储服务模块中提供了多种类型的存储机制，从技术上而言，其中包含三种持久化层次：

1、文件系统

2、NoSQL存储

3、关系数据存储

这三种存储结构从I/O读写效率和数据最大管理容量支持角度而言，从高到低的顺序为：文件系统>NoSQL存储>关系数据存储。而从复杂查询功能建模支持度而言，从高到低的顺序为：关系存储>NoSQL存储>文件存储。在以上分析基础上，总结以下数据存储参考原则：

1、文件系统用于存储高速写入的大批量完全无结构的数据，并且可预期这些数据不会被即时查询分析所涉及。

2、NoSQL存储作为能力相对均衡的存储设施，可以用来存储规模较大，而且需要能够支持较多查询分析方式的半结构化的数据。并且可以结合搜索引擎技术来增强关于其查询检索方面的能力。

3、关系数据存储由于其强大的关系模型能力，一方面可以较好的支持管理配置功能模块的运行，另一方面也可以针对少量规模的计算结果数据进行存储。

分布式文件系统

基础平台存储服务模块中的分布式文件系统将提供文件数据存储服务，如文本文档、PDF、图像、视频等文件数据。该服务模块将基于HDFS技术进行构建。HDFS是一个高度容错性的系统，适合部署在廉价的机器上。HDFS能提供高吞吐量的数据访问，非常适合大规模数据集上的应用。其技术结构如下图所示：

分布式文件存储的技术结构图

上图所示HDFS由一个NameNode和多个DataNode形成的集群构成，NameNode是Maste节点，作为管理员角色，管理数据块映射、处理客户端的读写请求、配置副本策略；管理HDFS的名子空间。SecondNameNode是NameNode的从属角色，作为NameNode的冷备份，一方面保证NameNode工作的高可用性，另一方面分担NameNode的工作量，合并fsimage和fsedits然后再发给NameNode。DataNode是作为Slave角色负责存储client发来的数据块block，执行数据块的读写操作。客户端在进行写操作的时候, 文件会被分割成多个block进行存储，block大小默认为64MB。每一个block会在多个DataNode上存储多份副本，默认是3份,这样保证了某个节点失效的话,仍然有别的副本可用,实现了高可用性, 由于HDFS是个面向分布式的文件系统,只需通过增加DataNode节点便可以实现线性扩容。

平台分布式文件存储模块并不会将HDFS实现直接对外暴露，而是提供基于JAVA的文件API，供外部编程开发使用。

并且为了文件数据的存储管理方便，平台将提供基于Web的文件资源管理控制台，以GUI方式实现对文件系统的浏览、增加文件、删除文件、读取文件等操作。并且该控制台将可以被定制性地切入权限控制系统以增强文件数据安全控制方面的功能。

关系数据存储

关系型数据库的缺点在于读写较慢，水平扩展能力一般，所以需要控制以关系数据库作为持久化解决方案的数据量，通常应限制在TB以下级别。而其优点在于稳定，功能丰富，通常用于存储重要的结构化的数据。在基础平台方案中提供的关系型存储服务，主要在于两重目的：

1、用于存储支撑平台运行的数据，比如配置数据、用户数据、权限数据等；

2、用于存储规模不大的分析计算结果数据。

平台提供的关系型数据存储模块基于MySQL技术构建，其技术结构如下图所示：

关系数据存储技术结构图

该存储子模块提供服务JDBC规范的数据存取API来屏蔽底层的集群实现。读写分离通过SQL路由代理来实现，所有的写操作将发送给Master实例，所有的读操作发送给Slave实例。通常对于关系型数据库的使用，读操作次数远大于写操作，多Slave可以分担Master的写入压力。单Master有可能不足以应对写入的压力，形成双Master同时写的结构，写入的数据通过复制来保证数据一致性。任意Master宕机,，都有对应的处于相同地位的Master来保证写入操作，使得写入操作持续持久化。同一Master下的Slave宕机，将由同一Master下的Slave继续支持读操作，使得读操作持续服务。以上技术结构将保证关系存储的高可用性。

分布式搜索引擎

基础平台的存储服务中提供分布式搜索引擎服务，进而用来支撑数据检索分析尤其是数据即席分析方面的基础能力。该服务子模块基于Elasticsearch进行构建。Elasticsearch是一个分布式搜索引擎，天然支持分布式集群，并没有实质的中心节点概念，各个数据节点都可向外提供服务，对于线性扩容，可以通过简单增加节点来实现。不过由于数据量增大，简单增加节点的扩容方式将开始逐渐影响到搜索的性能，导致集群失效，通常采取多集群架构方式。该模块的其技术结构如下图所示：

搜索引擎服务技术结构图

上图中ES集群结构示意，索引被分配到3个主分片中：P0、P1、P2。复制分片为R0、R1、R2。Cluster中有3个node节点,，任意节点接受请求时，相应的搜索定位到具体节点,然后分发到具体分片，提供搜索服务。如果复制分片节点失效，集群自动从相应主分片创建分本到复制分片；如果主分片节点失效，复制分片提升为主分本并创建复制分片，这样保证了集群的高可用性。

各个Cluster可以具有不同的节点规模，各个集群通过简单加节点方式实现水平扩容。该模块内通过多集群方式来保证集群效率，那么关于集群的划分遵循以下两种策略：

1、按时间、容量等客观指标划分。这个模式不关注外部业务，可以简单看成ClusterA达到给定规模，开始创建ClusterB，以此类推。优势在于可以作为通用扩容手段，对外部隐藏细节。该种策略的主要效果在于解决随时间增长数据的累积规模问题。但是缺点在于并不会在检索命中效果方面起到优化效果。这种策略是对于系统而言是一种主动性策略，只需要用户配置是否执行，然后系统将自动切分集群，并且这种切分对于外部是透明的。

2、按业务划分。针对外部业务来划分，这是针对优化搜索命中效果目标的最常用的模式。比如A只负责销售记录搜索，B只负责资金流水搜索，等等。不同的方向搜索引导到不同的集群,，而在集群内部，根据小的类目做索引。比如ClusterB负责作为用户集群, 有政府用户，企业用户，普通用户，分别做索引, 而对普通用户，根据归属地做routing，比如北京，上海等，提高分片命中率。该种策略对于系统而言是一种被动性策略，系统不能自动识别业务类型，只能由管理员进行规划。

而以上两种策略可以结合使用，策略2用于优化搜索性能，而策略1应用在策略2之下用于解决数据量累积增长瓶颈问题。

NoSQL数据存储

NoSQL数据存储是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，例如HBase，利用NoSQL数据存储技术可在廉价PC Server上搭建起大规模结构化存储集群。NoSQL数据存储主要包括两种文件类型：

1. HFile， NoSQL数据存储中KeyValue数据的存储格式，HFile是二进制格式文件，实际上StoreFile就是对HFile做了轻量级包装，即StoreFile底层就是HFile

2. HLog File，NoSQL数据存储中WAL（Write Ahead Log）的存储格式，物理上是Sequence File

HFile

首先HFile文件是不定长的，长度固定的只有其中的两块：Trailer和FileInfo。Trailer中有指针指向其他数据块的起始点。File Info中记录了文件的一些Meta信息，例如：AVG_KEY_LEN, AVG_VALUE_LEN, LAST_KEY, COMPARATOR, MAX_SEQ_ID_KEY等。Data Index和Meta Index块记录了每个Data块和Meta块的起始点。

Data Block

Data Block是HBase I/O的基本单元，为了提高效率，HRegionServer中有基于LRU的Block Cache机制。每个Data块的大小可以在创建一个Table的时候通过参数指定，大号的Block有利于顺序Scan，小号Block利于随机查询。每个Data块除了开头的Magic以外就是一个个KeyValue对拼接而成, Magic内容就是一些随机数字，目的是防止数据损坏。后面会详细介绍每个KeyValue对的内部构造。

HLogFile

HLog文件就是一个普通的Hadoop Sequence File，Sequence File 的Key是HLogKey对象，HLogKey中记录了写入数据的归属信息，除了table和region名字外，同时还包括 sequence number和timestamp，timestamp是"写入时间"，sequence number的起始值为0，或者是最近一次存入文件系统中sequence number。

参考部署架构与技术选型

关于分布式数据存储服务的参考部署架构与技术选型如下图所示：

参考部署架构图

具体的部署涉及到四种持久化基础设施软件服务。分别是HBase集群、HDFS集群、Elasticsearch集群和MySQL集群。另外，由于Hadoop生态中的HBase和HDFS需要Zookeeper集群做协同管理，所以还需要附加部署Zookeeper集群。

CarbonData是一个基于Hadoop，Spark生态，存储在HDFS上的列存储格式。

Parquet是面向分析型业务的一种存储格式，它是语言、平台无关的，并且不需要和任何一种数据处理框架绑定。

CarbonData有着更丰富的索引支持。在数据加载方面CarbonData会比Parquet慢，但是查询会快。CarbonData的文件也会比Parquet大，以空间换取时间。CarbonData与Parquet都兼容hadoop生态，平台可以通过hadoop里的部件来扩展底层的存储和计算设施去对应CarbonData的处理。但是平台不做封装、加工、改造。

原始数据域方案设计

原始数据域也称操作数据域，是数据体系架构中最接近数据源的一层，是全业务数据的集中存储处，除了对非结构化数据进行结构化处理以及对相同数据进行整合外，并不对业务数据做过多的清洗加工，尽可能保留数据的原始状态。原始数据域建设的目标就是把全域原始数据都汇聚到大数据中台，从而能在大数据中台查询到所有的数据，为后面的标准数据域和应用数据域建设做准备。

大数据中台的原始数据域的数据获取方式与传统数仓的ETL （Extract-Transform-Load）过程类似，但也有不同。传统数仓的ETL过程是在抽取（Extract）和装载（Load）的过程中进行清洗转换（Transform）操作，装载到数仓的是被清洗转换后的数据。这样的方式如果转换规则复杂，就会导致在ETL过程中消耗大量的计算资源，另外如果转换有错误，由于没有保留原始数据，则会导致在数仓层面无法追溯问题。进入大数据时代，由于存储成本降低和数据量增大，导致ETL过程中的复杂处理非常耗时，因此建议采用ELT（Extract-Load-Transform）方式，即将所有原始数据都抽取到大数据中台的原始数据域，在大数据中台内部再利用大数据底层平台的计算能力进行转换操作。这样既可让数据的抽取过程尽可能简单，又保留了所有的原始数据，以便于问题的追溯，还能充分利用大数据的计算能力。

按照数据结构类型的不同，原始数据域中的数据可以分为三类：

结构化数据：主要是关系型数据库中的数据，直接从业务系统DB抽取到原始数据域。
半结构化数据：一般是纯文本数据，以各种日志数据为主，半结构化数据保留原始数据的同时也做结构化处理，为后续使用做准备。
非结构化数据：主要是图片、音频、视频，一般保留在文件系统中，由于这类数据量一般比较庞大，而且没有太多挖掘分析价值，所以原始数据与不保留原始文件，只保留对原始数据文件的描述，比如地址、名称、类型、分辨率等。

原始数据域表设计

原始数据域中的数据表与对应的业务系统数据表原则上保持一致，数据结构上几乎不做修改，所以参考业务系统数据表结构来设计原始数据域表结构即可，结构设计上没有太多的规范要求。考虑到业务系统数据的多样性，原始数据域数据表的设计要遵循一定的规范，规范如下：

原始数据域表的命名采用前缀+业务系统表名的方式。比如，ODS_系统简称_业务系统表名，这样既可以最大限度保持与业务系统命名一致，又可以有清晰的层次，还可以区分来源。
原始数据域表的字段名与业务系统字段名保持一致，在ODS层不做字段命名归一。字段类型也尽可能保持一致，如果大数据中台没有与业务系统对应的数据类型则用一个可以兼容的数据类型。比如，业务系统的数据类型是float，大数据中台的存储系统没有float类型，则可以用double代替。
对于一些数据量较大的业务数据表，如果采用增量同步的方式，则要同时建立增量表和全量表，增量表利用后缀标识。比如，ODS_系统简称_业务系统表名_delta，汇聚到增量表的数据通过数据加工任务合并生成全量表数据。
对于日志、文件等半结构化数据，不仅要存储原始数据，为了方便后续的使用还要对数据做结构化处理，并存储结构化之后的数据。原始数据可以按行存储在文本类型的大字段中，然后再通过解析任务把数据解析到结构化数据表中。

通过以上建设规范，可保障企业所有业务数据按照一致的存储方式存储到大数据中台。

原始数据域表实现

原始数据域采用数据采集与汇聚体系构建的数据同步工具实现数据的同步落地。具体的实现步骤如下：

确定业务系统源表与原始数据域目标表；
配置数据字段映射关系，目标表可能会增加采集日期、分区、原系统标识等必要信息，业务相关内容不做转换；
如果是增量同步或者有条件地同步部分数据，则配置数据同步条件；
清理目标表对应数据；
启动同步任务，往原始数据域目标表导入数据；
验证任务是否可以正确运行，并且采集到准确数据；
发布采集任务，加入生产调度，并配置相关限速、容错、质量监控、告警机制。

标准数据域方案设计

原始数据域只对企业各个来源的数据做汇聚、整合，并没有做过多的加工处理，数据基本还是原始结构。且业务系统更多是按照流程组织数据，为保证流程的完整、方便，没有按照业务的本质来组织数据，原始数据域并不方便业务理解，更不适合做分析、挖掘。标准数据域站在业务的视角，不考虑业务系统流程，从业务完整性的角度重新组织数据。

建设标准数据域的目标是建设一套覆盖全域、全历史的企业数据体系，利用这套数据体系可以还原组织任意时刻的业务运转状态。要达到这个目标，需要利用维度建模方法用事实表、维度表来组织数据。之所以使用这种方法，是因为这种技术已经有近30年的历史，经过大量案例考验，证明这套简单的模型技术满足建模需求。维度建模具备以下特点：

模型简单易理解：仅有维度、事实两种类型数据，站在业务的角度组织数据。

性能好：维度建模使用的是可预测的标准框架，允许数据库系统和最终用户通过查询工具在数据方面生成强大的假设条件，这些数据主要在表现和性能方面起作用。

可扩展性好：具有非常好的可扩展性，以便容纳不可预知的新数据源和新的设计决策。可以在不改变模型粒度的情况下，很方便地增加新的分析维度和事实，不需要重载数据，也不需要为了适应新的改变而重新编码。良好的可扩展性意味着以前的所有应用都可以继续运行，并不会产生不同的结果。

数据冗余：由于在构建事实表星型模式之前需要进行大量的数据预处理，因此会导致大量的数据处理工作。而且，当业务发生变化，需要重新进行维度的定义时，往往需要重新进行维度数据的预处理。而在这些预处理过程中，往往会导致大量的数据冗余。

大数据时代，数据是资产，数据应该在业务中发挥更大作用，而易理解、易用、性能好、扩展性好的模型技术能让数据更方便参与业务。随着技术的发展，存储、计算成本的降低，经常会以存储换取性能和易用性。综上考虑，笔者推荐使用维度建模。

建模过程设计

标准数据域建设过程以维度建模为理论基础，构建总线矩阵，划分业务板块，定义数据主题、业务过程、维度、原子指标、修饰类型、修饰词、时间周期、派生指标，进而确定维度表、事实表的模型设计。

建模过程图

业务板块：根据业务的属性划分出的相对独立的业务板块，业务板块是一种大的划分，各业务板块中的业务重叠度极低，数据独立建设。
数据主题：数据主题是标准数据域的顶层划分，是一个较高层次的数据归类标准，是对业务过程进行抽象、提炼、组合的集合，面向业务分析，一个数据主题对应一个宏观分析领域。数据主题是抽象、提炼出来的，并且不轻易变动，既能涵盖当前所有业务需求，又能在新业务进入时无影响地将其分配到已有的数据域中，只有当所有分类都不合适时才会扩展新的数据主题。数据主题是有效归纳、组织业务过程的方式，同时方便定位指标/度量。
业务过程：业务过程是一种业务活动事件，且是业务运行过程中不可拆分的行为事件。业务过程产生度量，并且会被转换为最终的事实表中的事实。业务过程一般与事实表一一对应，也有一对多或者多对一的特殊情况。
修饰词：修饰词指除统计维度以外的对指标进行限定抽象的业务场景词语，修饰词隶属于一个修饰类型。修饰类型的出现是为了方便管理、使用修饰词。
原子指标：原子指标是针对某一业务事件行为的度量，是一种不可拆分的指标，具有明确业务含义。原子指标有确定的字段名称、数据类型、算法说明、所属数据主题和业务过程。原子指标名称一般采用"动作+度量"方式命名，比如支付金额、注册用户数。
派生指标：派生指标可以理解为对原子指标业务统计范围的圈定。派生指标=1个原子指标+多个修饰词+时间修饰词。
计算方法：指标的数学计算方式，比如汇总、平均、最大、最小等。
维度表：维度是观察事物的角度，提供某一业务过程事件所涉及的用于过滤及分类事实的描述性属性，用于描述与"谁、什么、哪里、何时、为什么、如何"（5W1H）有关的事件。维度表需要统一设计，在整个标准数据域中共享，所有数据主题、业务过程都需要用到维度，都可以在公共维度表中获取相关维度属性。
事实表：事实是观察事物得到的事实数据，事实涉及来自业务过程事件的度量，基本都是以数量值表示。在确定数据主题与业务过程后，就可以根据业务过程涉及的维度、度量及粒度，设计相关的事实表。事实表不跨数据域，根据需要，一个事实表可能对应同一个数据主题下一个或者多个业务过程。事实表又分为明细事实表和汇总事实表。明细事实表记录事务层面的事实，保存的是原子数据，数据的粒度通常是每个事务一条记录，明细事实表数据被插入，数据就不再进行更改，其更新方式为增量更新。汇总事实表是把明细事实聚合形成的事实表，包括以具有规律性的、可预见的时间间隔来记录事实的周期快照事实表和以不确定的周期来记录事实的累计快照事实表。

数据主题划分过程设计

数据主题是指面向业务或数据进行本质分析，归纳总结出来的数据集合。为保障整个体系的生命力，数据主题需要抽象提炼，并且长期维护和更新，但不轻易变动。在划分数据主题时，既能涵盖当前所有的业务需求，又能在新业务进入时无影响地将其插进已有的数据主题中或者扩展新的数据主题。具体数据主题划分过程如下：

第一阶段：数据调研。
业务调研：确定项目要涵盖的业务领域和业务线，以及各个业务线可以细分成哪几个业务模块，各业务模块具体的业务流程是怎样的，通过跟业务专家访谈或进行资料文档收集，梳理主要业务流程、业务边界、专业术语等。
数据调研：调研全部数据目录信息，梳理数据流与业务过程关联关系。
第二阶段：业务分类。
业务过程提取：根据调研结果抽取出全部业务过程。
业务过程拆分：将组合型的业务过程拆分成一个个不可分割的行为事件。
业务过程分类：按照业务分类规则，将相似特征的业务过程分为一类，且每一个业务过程只能唯一归属于一类。
第三阶段：数据主题定义。
业务分类确认：对业务分类结果再次确认，避免分类范围中出现业务特征明显与其他业务过程无关的情况。
数据主题定义：根据业务分类的规律总结出划分业务范围的标准定义。
数据主题命名：为每个数据主题起一个专属名称，并附上英文全称和简称。
第四阶段：总线矩阵构建。
关系梳理：明确每个数据主题下有哪些业务过程，并梳理出业务过程与哪些维度相关。
矩阵构建：定义一张二维矩阵，将数据主题下的业务过程与维度信息如实记录下来。

指标设计

指标就是在业务运转过程中产生的度量事实，一致性指标设计是为了在组织内外部使指标的命名、计算方法、业务理解达到一致，避免不同部门同一个指标的数据对不上或者对同一个指标的数据理解不一致。一致性指标的定义为，描述原子指标、修饰词、时间周期和派生指标的含义、类型、命名、算法，被用于模型设计，是建模的基础。

一致性指标设计是事实表模型设计的来源，有了一致性的指标定义，在设计事实表模型时引用定义好的一致性指标，可达到指标的一致性与标志性。

维度表设计

维度是维度建模的基础和灵魂，维度表设计得好坏直接决定了维度建模的好坏。维度表包含了事实表所记录的业务过程度量的上下文和环境，它们除了记录5W等信息外，通常还包含了很多描述属性字段。每个维度表都包含单一的主键列。维度设计的核心是确定维度属性，维度属性是查询约束条件（SQL where条件）、分组（SQL group语句）与报表标签生成的基本来源。维度表通常有多列或者说多个属性。维度表通常比较宽，是扁平型非规范表，包含大量细粒度的文本属性。实际应用中，包含几十甚至上百个属性的维度并不少见。维度表应该尽可能包括一些有意义的文字性描述，以方便下游用户使用。维度属性尽可能丰富。维度属性设计中会有一些反规范化设计，把相关维度的属性也合并到主维度属性中，达到易用、少关联的效果。

维度表设计主要包括选择维度、确定主维表、梳理关联维表、定义维度属性等过程。

选择维度：维度作为维度建模的核心，在标准数据域中必须保证维度的唯一性。维度一般用于查询约束条件、分组、排序的关键属性，维度既可以从报表需求中分析获取，也可以从与业务人员的交谈中发现。
确定主维表：主维表一般直接从业务系统同步而来，是分析事实时所需环境描述的最基础、最频繁的维度属性集合。比如用户维表从业务系统的用户基本信息表中产出。
梳理关联维表：标准数据域是业务源系统的数据整合，不同业务系统或者同一业务系统中的表间存在关联性。根据对业务的梳理，确定哪些表和主维表存在关联关系，并选择其中的某些表用于生成维度属性。
定义维度属性：从主维表或关联维表中选择维度属性或生成新的维度属性，过程中尽量生成更丰富、更通用的维度属性，并维护和描述维度属性的层次及关联关系。

事实表设计

事实表是标准数据域建设的主要产出物，标准数据域绝大部分表都是事实表。一般来说事实表由两部分组成：一部分是由主键和外键组成的键值部分，另一部分是用来描述业务过程的事实度量。事实表的键值部分确定了事实表的粒度，事实表通过粒度和事实度量来描述业务过程。事实表的外键总是对应某个维度表的主键，实际建设和试用过程中，为了提升事实表的易用性和性能，不仅会存储维度主键，还会把关键的维度属性存储在实施表中。这样事实表就包含表达粒度的键值部分、事实度量及退化的维度属性。一切数据应用和分析都是围绕事实表来展开的，稳定的数据模型能大幅提高数据复用性。

在Kimball的维度建模理论中主要定义了事务事实表、周期快照事实表、累积快照事实表三种类型的事实表。

事务事实表：事务事实表描述业务过程事务层面的事实，每条记录代表一个事务事件，保留事务事件活动的原始内容。事务事实表中的数据在事务事件发生后记录，一般记录后数据就不再进行更改，其更新方式为增量更新。事务事实表相对其他事实表保存的数据粒度更细，可以通过事务事实表对事务行为进行详细分析。
周期快照事实表：周期快照事实表以具有规律性、可预见的时间间隔产生快照来记录事实，每行代表某个时间周期的一条记录，记录的事实是时间周期内的聚集事实值或状态度量。周期快照事实表的内容一般在所表达的时间周期结束后才会产生，一般记录后数据就不再更改，其更新方式为增量更新。周期快照事实表一般是建立在事务事实表之上的聚集，维度比事务事实表少，粒度比事务事实表粗，但是由于对事实进行了多种形式的加工从而产生了新的事实，故一般事实会比事务事实表多。
累计快照事实表：累积快照事实表覆盖一个事务从开始到结束之间所有的关键事件，覆盖事务的整个生命周期，通常具有多个日期字段来记录关键事件时间点。周期快速事实表涉及的多个事件中任意一个的产生都要做记录，由于周期快照事实表涉及的多个事件的首次加载和后续更新时间是不确定的，因此在首次加载后允许对记录进行更新，一般采用全量刷新的方式更新。

事实表设计遵循以下步骤：

第一步：确定业务过程。

业务是由一个个业务过程组成的，事实表就是为了记录这些业务过程产生的事实，以便还原任意时刻的业务运转状态。所以设计事实表，第一步就是确定实施所要表达的是哪一个或者几个业务过程。业务过程和事实表会存在多对多的关系。

第二步：定义粒度。

不管事实表对应一个还是多个业务过程，每个事实表都有且只能有唯一的粒度，粒度是事实表的每一行所表示的业务含义，是事实的细节级别。粒度与主键等价，粒度更偏向业务，而主键是站在技术角度说的。

第三步：确定维度。

定义粒度之后，事实表每一行的业务含义就确定了。那么业务人员会站在哪些角度来描述事实度量？这就要确定维度了，常见的维度有时间、区域、产品、员工等。维度依附于粒度，是粒度的环境描述。

第四步：确定事实。

事实就是事实表度量的内容，也就是业务过程产生的事实度量的计算结果。事实表的所有事实度量都与事实表所表达的业务过程相关，所有事实必须满足第二步所定义的粒度。

第五步：冗余维度属性。

事实表的设计要综合考虑数据来源和使用需求，在满足业务事实记录的同时也要满足使用的便利性和性能要求。大数据时代，事实表记录数动辄亿级，甚至数十亿、数百亿，维表也有可能达到亿级甚至更多。利用标准维度模型会经常出现维表与事实表关联的情况，这种对亿级表的关联计算，在性能上是灾难性的。为了满足业务需求，降低资源消耗，可以适当冗余维度属性数据到事实表，直接利用事实表就可以完成绝大部分业务的使用需求，这样下游使用时可减少大表关联，提升效率。所以大数据时代，适当进行维度冗余是可取的。

但是需要注意，维度属性冗余与模型的稳定性是有矛盾的，因为维度的属性是有可能改变的，如果属性已经冗余到事实表中，那么维度属性就与事实一起被记录到事实表中。如果后续维度属性值改变，由于事实表已经生成，事实表的内容基本不会再做改变，这样就会出现已记录的维度属性与真实的维度属性不一致，导致数据错误的情况。

模型落地设计

经过以上数据主题的划分、指标的定义、维表设计、事实表设计，就完成了整个标准数据域的设计工作。接下来要在大数据中台建设过程中建设的数据开发工具，进行标准数据域的物理层面的建设。模型结构与内容已经确定，仅仅需要任务配置和运维层面的实施。落地实施的具体步骤如下：

按照命名规范创建表，包括维表和事实表；
开发生成维表和事实表的数据的逻辑；
进行逻辑测试，验证数据加工逻辑的正确性；
配置发布，加入生产调度，并配置相应的质量监控和报警机制；
持续任务运维监控。

应用数据域方案设计

标准数据域的数据相对稳定，然而最终用户的需求和使用方式是千变万化的，标准数据域无法灵活适应各类用户的使用需求。另外最终用户使用数据也需要灵活性和高性能，而这与规范是矛盾的，因为按规范进行建设就会把数据按照各种主题、业务过程、维度、粒度等拆分，使用的时候需要各种连接，这样就无法满足对灵活、高性能的要求。为了解决规范稳定与灵活、高性能之间的矛盾，要增加应用数据域。

应用数据域是按照业务使用的需要，组织已经加工好的数据以及一些面向业务的特定个性化指标加工，以满足最终业务应用的场景。应用数据域一般也是采用维度建模的方法，但是为了满足业务的个性需求以及性能的要求，会有一些反规范化的操作，所以应用数据域并没有非常规范的建设标准。应用数据域类似于传统的数据集市，但是比数据集市更轻量化、更灵活，用于解决特定的业务问题。应用数据域整体而言是构建在标准数据域之上的简单数据组装层，不像数据集市那样要为某个特定的业务独立构建，应用数据域的构建和完善是从组织内部多个类似业务场景来考虑的，同时它又具备数据集市灵活响应业务需求的特点。

应用数据表设计

应用数据域是在标准数据域已经建设好的基础上，面向特定业务需求而准备的个性数据组装层，除了特殊的业务个性标签需要单独加工外，其他尽可能复用标准数据域的建设成果。

应用数据域的建设是强业务驱动的，业务部门需要参与到应用数据域的建设中来。推荐的工作方式是，业务部门的业务专家把业务需求告知数据部门的数据工程师，然后在建模过程中深入沟通，这样最终形成的应用数据域的表设计才能既满足业务需求又符合整体的规范。因此应用数据域的特点就是考虑使用场景，其有以下几种结构：

应用场景是多维的即席分析，一般为了减少连接、提升性能，会采用大宽表的形式组织。
如果是特定指标的查询，可以采用K-V表形式组织，涉及此类表的时候需要深入了解具体的查询场景，例如是否有模糊查询，以便于选择最适合的数据结构。
有些场景下一次要查询多种信息，也可能会用复杂数据结构组织。

应用数据表实现

应用数据层建设步骤如下：

调研业务应用对数据内容、使用方式、性能的要求，需要明确业务应用需要哪些数据，数据是怎么交互的，对于请求的响应速度和吞吐量等有什么期望。这个时候需要参与沟通的可能不仅仅是业务部门的业务专家，业务系统的研发人员也需要参与讨论。
盘点现有标准数据域的数据是否满足业务数据需求，如果满足则直接跳到第3步；如果有个性化指标需求，标准数据域的数据无法满足，则进行个性化数据加工。
组装应用域数据。组装考虑性能和使用方式，比如应用域是多维的自由聚合分析，那就把标准数据域以及个性化加工的指标组装成大宽表；如果是特定指标的查询，可以组装成K-V结构数据。

数据服务体系建设

数据服务开发系统设计

数据服务是敏捷的数据虚拟化平台产品，可以将共享数据通过Web页面快速封装成API接口，以API接口形式对外提供数据服务。通过实时统一的数据访问入口提供数据服务，一方面可以屏蔽共享异构数据的复杂性，同时也大幅降低了传统硬编码共享接口的工作量，显著缩短项目工期。

此外，数据服务系统应具备完善的权限控制能力，可以满足用户在多种复杂的应用场景中对数据访问和内容安全的权限控制需求。

数据服务开发系统架构图

产品的系统架构可以分为以下几个部分：

执行引擎：在执行引擎中，系统具备完善的适配模块，可以适配国内外主流的关系型数据库、扩展支持文件数据源以及NoSQL数据源等。用户可以依托产品提供的各功能模块完成数据接口封装，权限控制以及OData解析等功能。
控制台：控制台负责为用户提供多种管理和监控功能，包括API接口调用情况的监控、API接口维护管理、用户管理和元数据管理等。
第三方接口：系统提供了种类丰富的第三方服务接口，包括API Gateway接口以及服务集成类的接口等。通过上述服务接口，用户可以在第三方系统中进行产品的集成和二次开发，以满足用户不同业务场景的功能需求。

支持数据源管理

产品具备国内外各类主流数据库的访问能力，包括Oracle、MySQL、SQLServer、DB2、Sybase、PostgreSQL、HBase、神通、达梦、金仓、南大通用等等。同时也支持灵活扩展新的数据源类型。

支持发布数据服务接口

支持基于国际通用的OData V4.0标准发布REST API标准接口。

发布数据服务接口图

支持多表关联发布

产品既可以针对单表的应用场景发布共享服务接口，也可以针对多表关联的复杂场景，提供数据服务接口的封装，并提供查询、插入、修改和删除等功能。

此外，针对多级嵌套的关联查询场景，允许用户在任意的嵌套层级中过滤和筛选数据。

多表关联图

支持安全管理

产品可以提供完善的数据安全管理能力，具体包括：

设定接口类型：完全公开、需要申请、不公开。

对于完全公开的接口，使用者可以直接调用而无需管理员审批；对于需要申请的接口，用户首先要在客户端提交使用申请，当管理员在管理端审批通过后，方可正常使用；对于不公开的接口，用户无法查看到。

设定接口类型图

设定接口请求类型：全部、查询、新增、修改、删除

根据管理员设定的接口请求操作类型，调用者可以进行相应的请求操作。

设定请求类型图

设定数据资源项是否隐藏：针对数据资源中的某一项，管理员可以设定为对外公开或者对外隐藏。

当管理员设定某一个数据资源项为隐藏时，数据调用者获取的数据资源中，将对该项信息不可见。反之，数据调用者则可以正常获取并可见。

设定隐藏项图

设定查询条件：管理员可以通过自定义where查询条件，只返回满足查询条件的数据资源，而非全部数据，满足数据安全控制需求。

设定查询条件图

提供必填列校验，过滤列筛选校验以及必填过滤列校验等。

用户级别权限控制：针对同一个接口，管理员可根据不同的申请用户，设定返回不同的字段列，也可以通过where查询条件，设定只返回满足查询条件的数据资源。

支持加密解密

用户可以通过扩展接口的功能自定义数据加密和解密策略。

接口的入参可以是加密后的数据，产品在执行接口调用时应先根据解密策略对入参内容进行解密，之后进行接口调用并返回数据；在返回数据给接口调用者时，可以根据加密策略对返回的数据进行加密，再将加密后的返回数据提供给接口调用者，防止数据被窃听和篡改。

配置加密解密规则图

支持访问控制

产品能够以白名单的形式控制IP地址访问权限，不在IP地址白名单内的服务器无法调用API接口。

访问地址控制功能应提供两级设置，包括全局设置和用户级别的白名单设置。全局设置里的白名单可以针对所有用户都起作用。用户级别的白名单功能，可以针对某一个用户，指定允许调用接口的合法IP地址。

访问地址控制图

调试功能

产品内嵌数据服务调试功能，可基于自定义的条件格式和数据内容调试服务接口，便于用户实时掌握接口的健康状态。

服务调试页面图

可以调试GET,POST,PUT,DELETE操作，目前支持的操作包括：

带过滤条件查询
单条或批量插入
单条或批量更新
单条或批量删除
插入更新（merge）

选择具体服务，并输入相应参数，点击"执行"，即可进行相应调试，如下图所示：

服务调试页面图

审计日志

产品将用户对数据服务的调用时间、调用行为、调用结果、客户端IP和登出系统时间等信息都可以持久化到数据库中，形成审计日志以便后续查询审计。

审计日志实时及历史查询图

仪表盘统计

通过仪表盘提供数据服务系统概览，包括"数据源数量"、"接口数量"、"用户数量"等数据。此外，仪表盘还应提供"接口访问趋势图"、"用户访问TOP"、"接口访问TOP"等分析数据，并允许用户自定义时间段进行联动数据的统计分析。

仪表盘之统计功能图

数据资源目录管理系统设计

数据资源目录是面向数据类型资源开放共享和数据交换场景，为数据提供方与数据需求方之间搭建共享数据资源的统一平台，提供数据资源注册、发现、查询和获取的统一入口。

通过数据资源目录的应用，可以打破数据共享交换的部门墙，实现跨部门、跨系统、跨地区的数据资源共享发布、资源检索和订阅等相关功能，降低部门间沟通和系统对接的成本，提升数据资源利用率和应用价值。

产品的系统架构可以分为以下几个部分：

目录服务：在目录服务模块中，产品对所有文档资源提供统一的元数据管理功能。同时，该模块提供了文档资源的发布、审核、申请和订阅等全流程管理功能，满足文档资源日常管理需求。
浏览检索：提供文档资源的全局检索功能。
管理监控：提供目录管理和统计功能。
服务接口：系统提供了种类丰富的第三方服务接口，包括管理集成服务接口，以及下载服务接口等。通过上述服务接口，用户可以在第三方系统中进行产品的集成和二次开发，以满足用户不同业务场景的功能需求。

支持资源目录管理

资源提供部门应建立自己的资源目录。目录管理模块提供对目录的定义功能，包括新增、修改、删除目录等操作。允许用户根据自身业务特点灵活创建和定制目录结构及内容。

目录管理图

支持发布数据资源

系统支持发布多种类型的数据资源，包括关系型数据库、大数据等。在发布数据资源，需要基于已经标准化或者分析计算的结果形成的数据资产进行发布，在发布数据资源时，支持按需选择对外公开的数据列，以控制数据的安全性。

选择数据资源类型图

发布数据资源图

支持检索数据资源

数据资源的检索方式应支持多种维度的组合过滤和模糊检索。

检索数据资源图

支持订阅数据资源

订阅数据资源是指数据资源需求方通过系统提供的操作入口，自助的获取数据的过程。系统提供的订阅数据资源功能，能够实现将数据资源提供方的数据资源自动拉取到本地的数据资源存储中。具体流程包括：

（1）资源发布：当用户基于本部门的业务梳理出职责目录、数据目录以及系统相关信息后，可以将上述目录和信息发布到数据目录系统中，形成目录资源并根据相关要求进行资源共享。

（2）订阅申请：当用户检索到所需要的资源时，可以选择订阅该数据资源。订阅申请提交后，系统会将订阅申请提交给相应机构的审批者。

（3）订阅审批：当被订阅机构管理员收到订阅申请时，可以在审批管理中进行授权或驳回等操作。管理员可以针对某一条申请进行授权或驳回，也可以针对多个订阅申请进行批量的授权或驳回。

（4）订阅数据同步：

在订阅申请审批通过后，系统可以驱动交换前置机按照订阅者制定的同步策略进行数据同步，实现一次性或周期性地将被订阅资源向订阅者发送和传输，最终实现目录驱动数据共享。该功能可以将从前的线下数据使用审批流程转移到线上处理，大幅缩短审批周期，显著提升数据流转效率。

（5）订阅状态管理：对订阅申请审核后的任务进行管理，提供订阅撤回等功能。当订阅被撤回时，原有的订阅任务将不能再被执行。

订阅数据资源图

数据资产管理体系建设

元数据管理系统设计

元数据是信息共享和交换的基础和前提，用于描述数据集的内容、质量、表示方式、管理方式以及数据集的其他特征。

元数据管理则是对技术元数据和业务元数据进行管理，能够集成、链接和集中管理多个分散系统的元数据，便于在整个用户系统中妥善维护、分析、消费和解释数据。当从业务元数据和技术元数据中得出数据的含义时，可以更有效地汇总和集成数据。

元数据管理的目标是为了提升共享、获取与理解数据资产的水平，充分发挥各类数据资产的潜在价值。

元数据管理系统应采用业界先进的设计理念和成熟的技术路线。架构设计遵循自主可控、安全、高效、开放、稳定的原则，确保整个产品平台的安全性、高效性、易用性、可扩充性和可维护性。其系统功能架构如下所示：

元数据管理系统架构图

产品的系统架构可以分为以下几个部分：

获取层：产品提供手动录入和自动录入两种方式，满足用户不同场景的录入需求。
存储层：产品遵从CWM（公共仓库元模型）标准，基于此标准构建了Oracle、MySQL等常用第三方工具模型，规范从获取层得到的各类元数据的属性要求和关联对象约束。产品允许用户自定义元数据模型。
功能层：产品提供丰富的元数据管理功能，包括元数据检索、维护、版本管理、元数据比对、元数据接口、血缘分析、影响分析等。
应用层：依托元数据管理，用户可以实现基于元数据的管理和二次开发工作，寻找性能瓶颈、辅助应用优化和领导决策。

支持元数据采集

元数据采集可以提供多种采集方式，包括自动采集方式、手动录入方式以及Excel模板批量创建方式等。自动采集方式支持国内外主流的数据库类型，可以通过连接多类型数据库，实现自动化元数据采集并统一管理。针对部分元数据类型，用户可以通过自定义元模型的方式，实现手动录入元数据。此外，用户也可以通过Excel模板的方式，实现批量创建元数据。当元数据入库后，对元数据的版本信息进行维护，形成版本记录。

支持元模型管理功能

系统应基于CWM 标准规范提供元模型管理功能，提供数据库、大数据、文件、文件系统、数据标准、ETL工具等多种内置的元模型，同时也允许用户自定义元模型，并基于自定义的元模型录入自定义元数据。

元模型示例图

元模型示例-元素内容图

元模型示例-关联关系图

在创建元模型之后，用户可以在资产库中依据已创建的元模型自定义创建相应的资产，创建成功后可以将该自定义资产纳入到系统中进行统一的管理和分析。

基于元模型新建资产图

支持资产库管理

系统应具备全局的资产库统一管理功能。通过资产库功能实现对元数据的精确匹配或模糊查询，对检索到的元数据可以显示各类属性信息。此外，用户应可以按照数据源，资产类型和已关联的业务术语等维度进行高级检索。

资产库图

支持版本管理

系统可以记录元数据的每次变更信息，便于元数据版本的追踪及回溯。用户可方便地查询元数据版本变更历史，查看每次变化的具体内容。元数据版本管理包括元数据版本查看、版本比对等功能。

采集监控图

元数据版本比对图

同时，用户在版本列表中可以选择任意的两个历史版本进行比对，进而查看不同版本之间的比对差异。

版本比对结果图

当有列资产被更新时，用户可以通过"详情"按钮，查看更新的具体内容和细节。

比对详细图

支持关联分析

系统可以对某个元数据进行全方位的关联分析。以TOPN图的形式展示当前元数据所有直接或间接关联的全部元数据信息，并能够以全局图谱的形式自动的进行分组和展示。

此外，用户可以针对某一个分组进行点击展开，查看其中的所有关联的元数据，并能够针对该分组中的某个元数据进行下钻式的关联分析。

关联分析图

在关联分析的TOPN图中，用户可以通过产品提供的多样化的个性定制功能，将不关心的分组信息隐藏，或通过搜索功能快速定位出关联的某个元数据信息，实现精准的关联分析。

支持血缘/影响分析

元数据管理产品提供完善的血缘和影响分析功能。用户可以通过该功能全面掌握某个元数据的数据来源和数据走向，便于用户做数据追溯和管理。

针对复杂的数据流转链路，用户可以通过产品提供的"分析度量调节"的功能，自定义展示数据链路的流转细节和显示分析结果的粒度。

血缘分析图

血缘明细图

在分析结果中，用户可以在右侧提供的工具栏中，选择在数据链路中同步展现"业务术语"链路流，用业务术语描述并显示完整的分析链路，便于业务人员理解数据的业务走向。

展示业务术语图

支持查看资产全景图

元数据全景图能够允许客户以全局角度对组织元数据流向进行展现，可以通过全景图的下钻功能查看不同元数据层次的数据流向。若数据流向发生变更，全景图能够自动调整展现内容。

元数据全景图可以查看如下元数据地图及对象关系：

看本体：查看对象本身定义，例如表的名称、注释等信息。
向上看：查看对象所属对象的定义，例如表所归属的数据库。
向下看：查看对象包含的对象的定义，例如表所包含的字段、索引等。
向前看：查看对象的上游信息对象，例如该表的数据的来源表。
向后看：查看对象的下游信息对象，例如该表的数据的目标表。
看历史：查看对象的历史变更信息。例如该表在上一个版本中的内容。
看友邻：查看与对象有关系的其他对象，例如涉及该表的脚本等信息。

全景图

支持数据剖析

系统可以在采集元数据的过程中剖析数据库表和列信息，剖析内容包括数据值分布情况，数据类型和数据模式等等，能够方便数据需求方即使不连接到数据库，也可以了解数据的基本数据质量和数据形状等，让数据需求方加深对于数据的理解，掌控数据。

数据质量管理系统设计

数据作为信息化应用的主体，本身具有多重特性，不仅有适用性、准确性、完整性、及时性、有效性等质量特性，还具有可取得性、可衔接性、可解释性、客观性、专业性、可比性等非质量的应用属性。

所采集原始数据的真实性是确保整个统计数据质量的基础。要对数据质量进行较好地控制，就必须对数据的质量特性进行很好了解，从而在各个方面采取措施，杜绝数据质量问题的出现，使数据监督工作能够真正达到控制数据质量的目的。

数据质量管理可以根据用户的业务规则和逻辑，通过大量内置的质量校验模型对原始的业务数据进行检查，并生成质量检查报告。业务人员可以根据质量检查报告及时修正原始的业务数据，提升业务数据的完整性、一致性、准确性等质量问题，实现改善数据质量的目的。

数据质量管理系统应采用业界先进的设计理念和成熟的技术路线。架构设计遵循自主可控、安全、高效、开放、稳定的原则，确保整个产品平台的安全性、高效性、易用性、可扩充性和可维护性。其系统功能架构如下所示：

数据质量管理系统架构图

系统架构可以分为以下几个部分：

执行引擎：在执行引擎中，系统具备完善的数据源适配模块，可以适配国内外主流的数据库以及文件数据源。同时提供数据质量的分析、数据质量报告生成和评分等功能。产品通过规则库内置种类丰富的多种校验规则，包括字段级校验规则、表级校验规则，表间级的校验规则以及多种行业特有的校验规则等等。
控制台：控制台负责为用户提供多种管理和监控功能，包括质量评估的过程监控，规则和报告管理，调度管理以及异常数据的管理等。
第三方接口：系统提供了种类丰富的第三方服务接口，包括管理监控类的接口，以及服务集成类的接口等。通过上述服务接口，用户可以在第三方系统中进行产品的集成和二次开发，以满足用户不同业务场景的功能需求。

支持数据源管理

产品能够分析多种类型的数据源，包括国内外主流的数据库Oracle/MySQL/SQLServer /DB2/Sybase/Netezza/HIVE/HBase/神通/达梦/金仓/通用等；支持txt/csv格式的文本数据源校验。

同时，可以通过扩展接口配置，提供扩展新数据源功能。

支持质量模型管理

质量模型管理主要负责管理业务校验模型，功能包括新建校验模型、修改校验模型、删除校验模型、搜索校验模型、校验模型分组管理以及分发校验模型。内置多种校验维度，包括表间校验、表级校验和字段级校验三种。以上不同的校验维度均内置了大量的常用校验规则，满足用户日常的数据校验需求。

济南市智慧医保监管主题建设方案

整体概览大数据主题分析

分析主题描述

通过大数据分析与展示，实现对全市医保基金整体运行与管理情况的概览，包括监管整体接入情况、监管人员整体情况、疑点展示、医疗机构遵从率排名、医保医师遵从率排名、规则触发数排名等。通过相关分析内容，可以有效的掌握区域医疗机构或医保医师触发规则情况，有效杜绝社保基金流失风险，为医保局基金监管或制定相关工作提供决策参考。

数据分析展示

监管成效概览大数据主题分析

分析主题描述

通过大数据分析与展示，向管理人员呈现医保基金分项运行与管理情况，包括基金运行概览、各区县监管成效、稽查机构数量、解除协议数量、基金收支情况、事前事中监控、事后审核结果监控、门诊慢病监控整体情况等。

数据分析展示

济南市医保大数据风控主题分析

分析主题描述

通过大数据技术，对医保数据进行分析、挖掘，建立各类模型，主要包括超量购药、群体住院、虚假计费、购药时住院、理疗式住院等关键可以项。通过此类分析展示，可以直观呈现存在套取医保基金重大嫌疑的情况，为相关部门提供监管依据与数据来源。

数据分析展示

济南市门诊慢病运行情况大数据主题分析

分析主题描述

通过大数据技术，对济南市门诊慢病运行情况进行全面监控。门诊慢病备案人数逐年增加，是医保基金发生跑、冒、滴、漏风险的高发人群，需重点关注，通过分析与展示，可以直观展示门诊慢病各个维度的监管与运行情况。