大数据平台下的数据治理建设方案118

大数据平台下的大数据治理建设目录大数据治理概述大数据现状及问题大数据治理阶段目标成效和特点数据管理系统建设情况第一部分大数据治理概述大数据治理意义、作用和价值意义是构建完善、共享、统一管理数据环境的基本保障和重要组成部分是把数据作为资产来管理的有效手段作用确定了一系列岗位角色和相应的责任及管理流程保证了业务数据在采集、集中、转换、存储、应用整个过程中的完整性、准确性、一致性和时效性价值企业进行大数据治理的最大驱动力来自数据质量，通过提高数据质量实现更多的业务价值将实现业务目标作为数据管理和服务的核心驱动力，优化数据架构，提升数据仓库/信息化管理系统建设，支持管理能力的提高、精细化和决策的科学性大数据治理整体架构大数据治理流程数据战略数据应用与服务数据管理保障机制促进支撑实现支撑数据战略与规划数据组织与职责数据与管理流程数据服务管理数据需求管理应用系统建设数据服务数据架构与模型管理数据管理数据质量管理元数据管理主数据管理数据保留与归档管理数据安全管理内容管理大数据治理框架数据调度与处理大数据平台数据结构化转换大数据分析计算分布式数据库分布式文件系统数据生命周期管理数据平台数据传输数据服务数据集市数据质量检核元数据管理数据管理平台数据应用统计报表基础数据平台贴源层整合层汇总层数据切分数据源业务系统物联网互联网数据交换平台内部数据外部数据其他系统数据接口数据架构数据挖掘高管驾驶舱一、应用（需求）驱动主导数据平台的实现，加强业务的关注和参与二、初期能够快速见效并体现建设价值，不盲目投入三、借鉴同业的成功经验和成果，选择成熟技术架构和解决方案四、重视内部人员培养，建设配套运营制度和管理体系应用是展现数据总线建设效果的门户，因此需要建设业务人员最紧迫和最关注的需求和应用，让业务部门最快参与数据总线的建设当中。实施周期不易过长，规模不易过大，能够快速的见到数据总线带来的效果和价值。尽量参考同行业、同规模、同类型企业行的建设经验，适当创新。前期让公司内IT人员尽量更多、更深入的参与到数据总线的建设中，后期角色以管理为主，尽量与合作伙伴共同建设二期以上。配套的管理规范、技术规范、运营体系。数据平台建设原则1大数据治理体系与大数据治理体系的联系与区别大数据治理是一项系统工程，大到大数据技术平台的搭建、组织的变革、政策的制定、流程的重组，小到元数据的管理、主数据的整合、各种类型大数据的个性化治理和大数据的行业应用。组织必须治理全部大数据，将大数据治理定义如下：大数据治理是广义大数据治理计划的一部分，即制定与大数据有关的数据优化、隐私保护与数据变现的政策。将上述大数据治理的定义分解为以下部分：　大数据是广义大数据治理计划的一部分大数据治理机构必须采取以下措施，以将大数据整合到既有的大数据治理框架中：　　扩展大数据治理宪章的外延，将大数据治理纳入其中；　　拓宽大数据治理委员会成员的范围，将数据科学家等大数据的超级用户吸纳进来；　　任命处理社交媒体等特定大数据的主管；　　将大数据与元数据、隐私、数据质量和主数据等大数据治理结合。大数据治理关乎政策制定政策包括人们在特定情形下如何作为的成文和非成文的宣告。譬如，大数据治理政策可能申明，未经顾客知情并同意，组织不得将顾客的Facebook资料整合到其主数据记录中。大数据必须优化考虑一下组织是如何将现实世界的准则应用到大数据治理中的。公司设计了精致的企业资产管理计划，对机器、飞机、交通工具和其他资产进行妥善管理。与对实物资产进行登记类似，组织必须对大数据进行如下优化：　　元数据——建立大数据类别信息；　　数据质量管理——像公司对实物资产进行定期检修一样，定期净化大数据；　　信息生命周期管理——对大数据进行存档，并在没必要继续保存某些数据时，将其删除。大数据隐私至关重要组织同样必须建立旨在防止大数据误用的适当政策。组织在处理社交媒体、地理定位、生物计量学和其他形式的个人可识别信息(PII)时，必须考虑涉及的声誉、规制和法律风险。大数据必须变现所谓变现，就是将数据等资产转化为现金的过程，变现的方式可以是将数据卖给第三方，也可以是利用数据开发新的服务。在当下，公司意识到，必须将大数据视为具有财务价值的企业资产。例如，运营部门可以通过传感器数据，根据定期检修计划，提高设备正常运行时间。呼叫中心可以分析客户代表的记录，通过了解顾客呼叫的原因，降低呼叫量。此外，零售商可以使用主数据激活Facebook的应用程序，提升顾客忠诚度。2.1大数据治理框架大数据治理框架由三大部分组成：大数据类型、大数据治理领域、行业与功能产业和功能场景保险业电信业零售业公共事业医疗保健业组织元数据隐私数据质量大数据类型web和社交媒体数据机器对机器的数据生物计量学数据大体量交易数据人工生成的数据信息治理大数据治理需要高度聚焦于数据本身。传统的大数据治理领域同样适用于大数据大数据分析受用例驱动，用例的具体情况因产业和功能而异。客户服务IT业务流程整合情绪分析Facebook忠诚度计划客户流失分析索赔调查IT日志分析车载通信技术位置服务索赔欺诈分析智能仪表患者监测索赔分析客户流失分析通话质量保证基因测试人脸识别承保电子病历RFI日志3.1大数据治理成熟度模型实施大数据治理的第一步，是评估大数据治理成熟度的当前状态和期望的未来状态。现将某信息治理委员会的成熟度模型用于成熟度评估。该模型设立了4个领域的11个大数据治理成熟度指标。支持准则数据架构数据标准审计信息日志和报告核心准则数据质量管理信息生命周期管理信息安全与隐私支持要素管理人员数据风险管理政策目标业务成果要求支持增强组织机构和认识元数据3.1.1大数据治理成熟度模型介绍及问题示例目标目标指信息治理计划的预期结果。目标倾向于关注降低风险与提升价值，这反过来又受降低成本和提高收入的驱动。业务成果：代表信息治理计划的目标和目的。业务成果：A是否已经确定了大数据治理计划的关键业务关联方？B是否对大数据治理可带来的财务收益进行了量化？支持要素核心准则支持准则组织结构和认识：指业务部门和IT部门间的相互责任，以及对治理不同管理层次中数据的信托责任的认识。管理人员：旨在保证数据监护，实现资产增值、风险消解和组织控制的质量控制准则。数据风险管理：据以识别、保留、量化、规避、接受、消解和转嫁风险的方法论。政策：期望得到落实的组织行为的书面表达。数据结构和认识：如关键角色的职位说明中，是否包含大数据治理，如配备首席数据官和信息治理官？管理人员：是否已经建立了责任分配（RACI）矩阵，以定义针对大数据关键属性的角色和责任？数据风险管理：是否在大数据治理与风险治理之间建立了联系？政策：是否已经归档了一组大数据治理政策？数据质量管理：指测量、提高和保证产品数据、测试数据和归档数据的质量和集成性的方法。信息生命周期管理：有关信息采集、使用、保留和删除的系统化的、基于策略的方法。信息安全与隐私：组织用于消解风险和保护数据资产的策略、实践和控制手段。数据质量管理：对于与大数据相关的质量问题（数据价值不高或不显著），是否达成了一致意见？信息生命周期管理：是否制定了流程，根据法律和业务要求合法处理不再需要的大数据？信息安全和隐私：首席信息安全官是否是大数据治理计划的关键支持者？数据架构：结构化和非结构化数据系统及应用的架构式设计，用于实现数据的可用性，并将数据分配给合适的用户。元数据：指用于创建常见的语义定义、IT术语、数据模型和数据库的方法和工具。审计信息日志和报告：指监测和测量数据价值、风险和信息治理有效性的组织流程。数据架构：Hadoop、NoSQL以及与当前架构相关的其他新兴大数据技术的共存战略是怎样的？分类和元数据：业务词库是否包含与大数据相关的关键业务术语（如针对点击流数据的“独立访客”）？审计信息日志和报告：企业如何检测特权用户对医保索赔和通话详单等敏感大数据的访问？问题示例模型介绍案例5.2某大型金融机构资金管理部的大数据治理路线图创建Hadoop基础设施大数据治理的演进关键活动每日头寸快照社交媒体和非结构化内容治理大数据某大型金融机构的资金管理部，为大中型企业提供现金管理和流动性管理的综合服务。该部门处于部署大数据计划的早期阶段，其最初的大数据治理路线图如右图所示：第1-6个月构建技术基础设施，获得Linux服务器和ApacheHadoop发行版。由于大数据是一个新事物，在切入业务前，必须设计一个可行的用例，并进行财务可行性论证。此外，组织要认真审视数据管理的传统方面：怎样将数据导入并导出Hadoop?Hadoop中的数据质量如何？大数据的元数据是怎样的？如何将大数据整合到未来12个月将要部署的主数据管理数据库中？大数据已经成为主流媒体的热门词汇，高管层至少很有可能同意支持一个大数据试点项目。因此，大数据治理团队需要及时更新路线图，将与大数据有关的人员、流程和技术计划纳入其中。第6-12个月引入详细的交易记录，以分析每日头寸快照。受传统基础设施成本高昂的影响，以往的金融机构从未进行这样细致入微的分析。第12-24个月将社交媒体数据和其他非结构化内容引入Hadoop环境。由于金融机构的大多数客户是大企业，对交易对手的10-K和10-Q归档等非结构化内容，进行探索性分析。第24-36个月资金管理部已经有了现成的聚焦于大企业客户的主数据的信息治理计划。大数据处理框架的组成大数据治理需要高度聚焦于数据本身。我们将大数据分为五种：web和社交媒体数据、机器对机器的数据、大体量交易数据、生物计量学数据和人工生成的数据。大数据类型信息治理准则产业与功能传统的信息治理准则，同样适用于大数据，相关准则包括组织、元数据、隐私、数据质量、业务流程整合、主数据整合和信息生命周期管理。大数据分析是受例驱动的，用例的具体情况因产能和功能而异。限于篇幅，我们只列出了部分的产业和功能。大数据的类型大数据大体可分为五种类型Web和社交媒体数据二的点击流数据TwitterFeedsFacebook帖子网络内容Web和社交媒体数据二的点击流数据TwitterFeedsFacebook帖子网络内容机器对机器的数据二的公用事业智能仪表读数RFID读数石油钻探设备传感器读数网络内容Web和社交媒体数据二的点击流数据TwitterFeedsFacebook帖子网络内容Web和社交媒体数据二的点击流数据TwitterFeedsFacebook帖子网络内容类型6.1职责分配（RACI）所代表的内涵应负责方（Responsible）指授权管理某属性的人。（一种属性可有多个负责人）最终负责方（Accountable）指数据属性承担最终责任的人。咨询方（Consulted）指通过双向沟通接受咨询的某人或某些人。被告知方（Informed）指通过单向沟通被告知的某人或某些人。7大数据治理计划需要实施的最佳实践1324创建一个体现关键大数据术语的业务定义的词库。理解对ApacheHadoop中元数据的持续支持。对业务词库中的敏感大数据进行标记。从相关的大数据存储中输入技术元数据。将相关的数据元与业务词库中的术语进行链接。5768使用运营元数据监测大数据的流动。保留技术元数据，以支持数据血统和影响分析。从非结构化文件中采集元数据，支持企业搜索。扩展既有的元数据角色，将大数据纳入其中。9元数据是描述数据产品特征的任何信息，如名字、位置、可感知的、重要性、质量、对企业的价值，以及与企业认为值得管理的其他数据产品的关系等。元数据决定信息架构的如何满足业务需求，因此元数据是信息治理计划的关键。7.1业务词库业务词库业务词库是企业用于传达其对信息的认识的语言。创建并维护该层业务元数据，对表达要求的含义和描述IT系统可用的信息至关重要。业务词库保证了信息开发的准确性和速度。术语代表着企业和业务层面对信息的理解，所以许多组织倾向于自下而上创建数据词典，对已有的信息进行归类。在处理大数据时，业务驱动的数据定义和数据目录之间的区别尤为重要业务词库保证了信息开发的准确性和速度。在处理大数据时，业务驱动的数据定义和数据目录之间的区别尤为重要。7.3对业务词库中的敏感数据对敏感的大数据进行分类发现敏感数据对业务词库中的敏感数据进行标记执行大数据隐私政策进行分类大数据治理计划需要对社会保险号码等敏感数据进行分类。分类应来自业务词库模型并被传承到不同数据库中数据的所有物理实例中。敏感的大数据可能隐藏在非结构化文本中。大数据治理计划应考虑数据分析工具的利用，以便自动发现非结构化字段的敏感数据。首席信息安全官制定有关敏感数据的政策。只有在识别到敏感数据的位置时，组织才能执行政策，因此，在业务词库中标记敏感数据就非常关键。大数据治理团队可以通过使用数据分析工具发现敏感的大数据，以监督对政策的遵从度。从相关的大数据存储中输入技术元数据在创建业务词库后大数据治理团队需要从大数据源中采集合用的、相关的元数据。大数据源Hadoop文件商业智能报告应用数据库数据模型准结构化非结构化数据结构化信息管理经销商元数据中央存储库桥接器连接器7元数据元数据创建一个体现关键大数据术语的业务定义的词库理解对ApacheHadoop中元数据的持续支持对业务词库中的敏感大数据进行标记从相关的大数据存储中输入技术元数据将相关的数据元与业务词库的术语进行链接使用运营元数据监测大数据的流动保留技术元数据，以支持数据血统和影响分析从非结构化文件中采集元数据，支持企业搜索创建非结构化数据的索引，也是元数据的一种形式，许多企业的搜索供应商已开发相应工具。保险业通过向呼叫人员提供客服关怀、告警、保单和客户信息文件等多个文件库的可搜索访问，可将平均处理时间减少三秒，年节约数百万美元。通过提供对EMCDocumentum、文件系统、微软Share-Point、内网和外部数据库中客户、患者和研究数据的快速访问，加快科研进程。让临床医生可访问来自医学刊物和其他文件库的最新研究成果。制药业医疗保险业7.9拓展既有的元数据角色，将大数据纳入其中信息治理团队可能安排许多与原数据相关的角色。组织需考虑这些角色进行拓展，以将大数据治理纳入进来。业务词库管理者数据科学家元数据管理者数据血统管理者数据主管数据架构师本角色负责保管应将大数据术语包含在内的业务词库。本角色负责在相关数据源识别和输入技术元数据。数据血统管理者与数据管理者配合，确保数据血统分析中数据源之间的数据流可得到准确地反映。本角色参与大数据特别是关键业务术语定义的管理。本角色监督元数据模型的创建及其与企业数据模型的连接。本角色缩短了大数据原始卷和使其有用的业务洞察间的距离，其通过创造力和想象力创建原型，以揭开大数据中的秘密。9大数据质量数据质量管理是测度、提高、验证质量以及整合组织数据的方法等一套行为准则。体量极大、速度极快和多样的特点，决定了大数据质量所需的处理有别于传统信息治理计划的质量管理。维度传统数据的质量大数据的质量处理频率处理是面向批量的处理是实时的或面向批量的数据多样性数据格式大部分是结构化的数据格式可能是结构化的、准结构化的或非结构化的置信度数据需处于原始阶段，以方便数据仓库的分析糟糕的数据质量可能会阻碍分析工具获得业务洞察数据进化的时间选择在下载到数据仓库前数据需要进化数据的体量和速度可能要求采取流式的、内存中的分析来进化数据、从而降低存储要求关键数据元素评估客户地址等关键数据元素的数据质量数据可能被模糊定义或错误定义，关键数据元素可能会反复变化分析位置数据迁移到数据质量和分析引擎数据质量和分析引擎可进入数据中，以保证可接受的处理速度管理工作数据主管可管理大部分数据由于体量大和速度快，数据主管只能管理相对更小的数据大数据治理计划必须采取的实践9.1与商业上的利益攸关者协作，建立并测度大数据质量的置信区间9.2利用准结构化和非结构化数据，提高人口稀疏的结构化数据的质量9.3使用流数据分析技术解决内存中的数据质量问题，无需将中间结果输入硬盘9.4任命对信息治理委员会负责的主管，由其负责提高10业务流程整合1.大数据源图21.1大数据技术参考架构Web和社交媒体数据机器对机器的数据大体量交易数据生物计量学数据人工生成的数据15.大数据安全和隐私16.大数据生命周期管理17.云2.开源的基础组件HDFSMapReduceHadoopCommonHBaseOthers5.数据库NoSQLIn-MemoryRelationalLegacy6.大数据整合批量迁移复制虚拟化7.文本分析8.大数据发现9.大数据质量10.元数据11.信息政策管理12.主数据管理13.数据仓库和数据集市14.大数据分析和报告3.Hadoop发行版4.流媒体分析18.大数据标准8.大数据发现9.大数据质量微软的大数据平台1.微软Hadoop发行版6.WindowsAzureExcel5.大数据分析与报告SQLServerAnalysisServicesSQLServerParallelEditionSQLServerReportingServices4.数据仓库与数据集市3.大数据整合2.数据库开源基础组件大数据源SQLServerIntegrationServicesSQLServer理解对ApacheHadoop中元数据的持续支持名称节点数据块A数据节点机架1数据块B数据块C数据块A数据节点机架2数据块B数据块C数据块A数据节点机架3数据块B数据块C图：Hadoop分布式文件系统（HDFS）的技术构架作为Hadoop关键支持要素的元数据如图Hadoop分布式文件系统（HDFS）是一个带单个名称节点和多个数据结点的主/从架构。单点故障因为HDFS很容易受到名称节点故障的损害，所以Hadoop经销商建议管理者存储一些不同本地硬盘的备份可拓展性随着数据存储动能的扩大，主服务器名称节点可能出现可拓展性的问题，主服务器名称节点必须将所有元数据保存在内存中。HCatalogHcatalog项目是Apache孵化器的一部分，旨在解决Hadoop中缺乏元数据支持的问题。大数据安全与隐私部分漏洞变通方案HDFS没有授权系统，注册用户可以在群中读写任何数据Hadoop注册用户通过“whoami”命令访问，这是不安全的Hbase没有访问控制，Hadoop群中任何工作运行均可以访问群中任何数据……不要在Hadoop中存储任何敏感数据对敏感数据进行加密，包括隐藏文本和非结构欧化领域的内容将每个数据置于自己的群中，以便用户仅可以访问被授权的数据……Hadoop是一项新技术，我们预计随着大公司和供应链的介入，上述问题将被得到解决。第二部分大数据现状及问题数据应用现状分析-总体情况？综合业务系统信贷管理国际业务系统债券管理系统……数据交换平台综合报表平台财务会计部信贷管理部国际业务部资金计划部…….业务职能不清晰或相互重叠，观察数据视角不尽相同，缺少数据标准与业务统一定义，语轨不一致IT架构中中都是以部门级应用为主（如计财、资金计划部等），缺乏从大的管理职能（财务、风险、运营等）综合方面的数据整合、数据标准和统一业务定义缺乏数据梳理，造成行领导看到的数据相互冲突和矛盾由于业务系统输入的随意性，导致部分关键业务数据质量较差X\?567行领导业务人员数据应用现状分析-数据架构方面由于全行的数据散落在各个业务系统中，没有进行有效整合，形成竖井式架构，造成多个信息孤岛，整体架构缺少一个稳定的、抗源变化的保存最细粒度历史数据的数据层。无法支撑未来共享性应用。集市层客户风险客户一部中间业务汇总数据层主题层报表应用共用主题数据客户风险报表客户一部报表中间业务报表支付报表支付业务ODS层DEP层BDS层其它报表业务表现信息孤岛数据冗余共享性差历史数据缺失问题数据分散，难以管理没有一个稳定的，抗源变化的数据层综合业务信贷管理国际结算债券核算源系统竖井式架构，造成信息孤岛缺少一个稳定的、抗源变化的数据层客户管理绩效考核……没有进行整合，无法共享，不能支持如客户管理等共享性应用数据应用现状分析-数据应用难题业务表现各集市系统指标存在重复各集市系统在保有存量的同时，不断产生新的指标（增量）集市指标派生无法实现指标逻辑视图（指标分类）不一致问题重复投入数据不一致指标设计、口径不一致指标难以共享客户风险集市客户一部集市资金计划部借据号期末余额。。。借据编号期末贷款余额总资产我想看本期贷款余额，看哪个呢？主营业务收入负债总额《活期存款流水采集单》《G21流动性期限缺口统计表》。。。我想看客户经营情况信息，有哪些呢？活期存款指标数据怎么不一致呢？活期存款缺少统一的应用分析标准用户用户数据应用现状分析-数据应用难题业务表现各系统存在冗余数据各系统存在业务含义一致，名称定义不一致的属性各系统存在含义不一致，名称定义一致的情况业务代码定义混乱问题重复投入数据不一致、不准确难以利用和管理各系统数据难以共享缺少统一的基础数据标准核心贷款分户账表贷款主档代码贷款余额。。。五级分类标志计息方式信贷管理借据表贷款账号贷款余额。。。5级分类标志借据计息周期业务含义一致，名称定义不一致数据冗余相同业务代码定义不一致核心五级分类代码信贷管理五级分类代码1正常01正常2关注02关注3次级（不良）03次级4可疑（不良）04可疑5损失（不良）05损失数据应用现状分析-数据质量方面没有归纳并总结数据质量问题，缺少反馈机制,导致长期存在各类数据质量问题。业务表现指标难以共享数据不一致、不准确问题部分关键业务数据缺失源系统校验关系缺失及业务人员操作随意非现场监管报表统计各省分支机构每笔借据的五级分类信贷管理源系统操作错误《贷款质量五级分类情况简表》信贷管理客户表核心客户表由于信贷管理系统业务人员没有填写或填写错误借据的五级分类信息，导致报表数据不准确，需要手工补录修改不同系统相同客户号对应的客户简称不一致客户号客户简称75682839综合厂97326762国鑫资产客户号客户简称75682839粮食局粮油综合97326762乳山市国鑫资产数据应用现状分析-总结随着业务的不断发展和信息化的不断深入，需建设的业务系统越来越多，随着业务系统的数据种类不断丰富完善，数据量的不断增大，如果不采取有效手段解决数据架构、数据标准、数据质量问题，随着信息化建设的深入，这些问题将像雪球一样越滚越大，越积越多。第三部分大数据治理阶段目标数据平台逻辑架构数据调度与处理元数据管理数据传输数据生命周期管理非现场报表财会报表客户风险报表…..机构客户账户…...非现场监管集市财会报表集市风险报表集市高管驾驶舱集市…….数据仓库源数据数据应用贴源层整合层汇总层集市层数据管理系统综合业务系统CM2006国际结算系统债券管理系统ETLETL数据切分作业调度作业调度作业调度ETLCBSCM2006EEBONDPEFESMCS整合层数据平台部署架构数据平台项目建设目标目标建设方法-发现数据质量问题建设内容分析源系统表数据，从及时性、完整性、准确性、有效性、一致性方面对源系统数据进行数据校验，发现并记录数据质量问题，生成数据质量问题报告建设数据质量检核系统，对源系统基础业务数据的进行全面的数据质量检查，并实现重要业务数据质量的周期性动态检查，对发现的数据质量问题生成数据质量报告，反馈给业务部门目标建设方法-发现数据质量问题源系统分析阶段全面分析主要源业务系统数据质量问题检查阶段根据制定的检查规则编写程序，对源系统数据进行检查数据质量问题分析阶段分析有质量问题数据对现有应用的影响；提出解决措施123工作阶段源系统分析阶段产出物源系统表结构，包括主键、外键、唯一性约束源系统表间关系源系统字段长度和类型技术角度分析调研业务角度分析调研源系统表和字段的业务含义源系统业务规则和流程数据质量检查阶段数据质量分析阶段数据质量反馈系统概述建设目标对业务数据进行数据质量检核，准确掌握业务系统各种数据质量问题，促进基础业务数据质量的提高建设内容质量检查规则定制实现质量检查规则的灵活定制数据质量检查系统按照预定义的数据质量检查规则，对数据的准确性、有效性、关联性、一致性、及时性进行检查，生成并保存的数据质量检查信息。数据质量分析报告生成不同类型的数据质量检查报表，对不同的数据质量问题进行分析和展示架构和功能系统架构数据质量检核与反馈系统检核对象管理导入、查询、修改、删除检查对象检核规则管理新增、删除、修改检核规则检查频度管理制定检查周期和时间权限管理用户建立权限管理问题报告问题查询规则查询打包下载......问题管理维护并管理发现的数据质量问题日志查询报告管理系统功能调度管理整合层汇总层集市层贴源层功能分类功能名称功能说明检核对象管理对象编辑修改导入表，修改表和字段的相关属性检核规则管理有效性灵活定制自定义检核规则，实现可视化规则配置和管理关联性一致性准确性及时性检查频度管理检核频度管理质量监控周期频度，可按日、周、月、年等频度制定检核时间问题管理 问题管理对发现的数据质量问题进行进一步的描述和分析，并划分问题归属业务分类报告管理 报告管理质量问题报告查询，并可按照部门、系统、问题进行汇总查询系统管理权限管理管理员、操作员权限设置检核对象配置管理需检核的表数据质量管理建议通过逐套的解决报表数据质量问题，以数据标准为依据，来切实解决基层手工修改报表的问题源头负责制，谁录入谁修改操作层面数据纠错管理层面形成数据质量管理的机制：发现问题，定位问题，解决问题的管理流程IT系统建设层面将数据质量问题检查规则固化到系统中，形成数据质量台账，为解决数据质量问题和考核提供依据数据平台项目建设目标数据标准梳理及归纳基础数据标准指标数据标准数据标准梳理及归纳对我行日常业务开展过程中所产生基础性数据，从业务方面、技术方面、管理三个方面，对数据的业务表达、数据格式、数据关系等方面进行一致约定，从而规范数据在全行内外共享和使用中的一致性和准确性对数据的管理、应用过程进行统一和规范，明确数据的定义、格式、规则以及数据与数据间的关系为系统开发实施提供全行统一的规范准则为数据加工和应用提供统一来源和依据作用定义定义通过对我行经营管理资料的分析，并参考同业的类似成果以及监管部门要求，梳理和筛选出直接反映我行业务经营管理状态的重要指标，并对指标的业务含义、业务规则、统计口径等内容进行标准化定义，形成全行一致的指标数据标准作用统一全行对各项经营指标的理解和认识，促进各项经营指标在经营管理决策中的运用；统一全行指标标准的业务含义、计算口径等内容，从而解决我行取数口径不一致、业务含义不清晰、指标分类不清晰的情况，促进部门间数据共享目标建设方法-数据标准解决的问题数据孤岛数据质量制定了全行统一的标准，实现了业务数据信息统一定义，统一命名、统一来源对于数据质量造成的数据准确性、一致性等问题，找出造成这些问题的原因，违背业务和约束的数据不进入标准体系中举例例如：在标准制定过程当中，对于业务数据之间关联不上的问题，首先要找出关联不上的原因，之后通过和业务人员的有效沟通，制定出以哪一类数据为准的标准，比如信贷管理系统的贷款余额和核心系统的贷款余额不一致，在制定“协议金额”标准的过程当中，必须明确以那个系统的贷款余额为准，且以此贷款余额制定全行标准，从而解决此类问题。例如：不同部门的贷款余额由于取数来源不同而造成差异，通过建立完整的分析数据标准体系后，统一了业务定义和取数口径，有利于全行范围内重复利用，杜绝出现各业务部门多次重复定义类似的指标，并且因为标准的权威性和标准的严格管理，有效防止指标定义和口径的二义性。目标建设方法-数据标准-建设步骤基础数据标准指标数据标准分析数据标准发布执行标准映射数据源和基础标准数据映射数据源和分析标准数据映射标准执行标准定义数据标准基础数据标准发布执行业务定义、业务规则、业务含义、计算口径……业务含义、业务规则、业务描述、数据来源……目标建设方法-数据标准-建设内容目前存在问题业务访谈系统调研结合最佳实践分析、诊断形成标准化定义初稿和框架对定义初稿征求意见和讨论根据意见反馈和讨论结果和修正并形成数据标准确定映射的系统范围制定源系统与标准的映射规则根据数据验证映射规则提出标准在未来各影响面执行的遵循原则就标准与现状的实际差异给出具体的执行建议目标建设方法-数据标准-基础数据标准调研调研分析业务字段源业务系统模型匹配整合1、名称不同，业务含义相同2、名称相同，业务相同3、名称相同，业务含义不相同分析调研记录整合层模型源系统表名字段名业务含义业务规则业务描述是否代码对应主题对应实体对应属性………………实体属性核心客户信息客户名称否……xxxxxxxxxxxxxxxxxxxx信贷管理贷款客户信息贷款客户名称否……xxxxxxxxxxxxxxxxxxxx客户对公客户对公客户名称…核心贷款分户账表贷款余额否……xxxxxxxxxxxxxxxxxxxx协议协议金额表贷款余额…信贷管理贷款借据表贷款余额否……xxxxxxxxxxxxxxxxxxxx信贷管理贷款展期台账贷款方式是……xxxxxxxxxxxxxxxxxxxx协议贷款展期信息表抵押方式协议贷款信息表贷款方式…信贷管理贷款基本信息贷款方式是……xxxxxxxxxxxxxxxxxxxxXXXXXXXXXXXX……xxxxxxxxxxxxxxxxxxxxXXXXXXXXXXXX…目标建设方法-数据标准-基础数据标准框架梳理基础数据标准框架梳理参考补充标准分类标准主题参考：1、同业标准体系框架2、TD模型的结构与分类源系统表名字段名是否代码…..业务含义业务描述……业务规则对应主题对应实体对应属性……筛选保留重命名分类整合合并分析调研记录标准中文名称标准英文名称标准依据相关标准标准管理部门业务规则业务描述数据类型长度业务含义源系统数据格式协议账户贷款账户存款账户协议xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx协议贷款贷款余额xxxxxxxxxxxxxx信贷管理xxxxxxxxxxx…………………………………………………………客户对共客户客户名称xxxxxxxxxx信贷管理xxxxxxxxx目标建设方法-数据标准-基础数据标准定义及确认标准分类标准中文名称标准信息类业务规则业务描述数据类型长度标准依据相关标准标准英文名称业务含义源系统标准管理部门数据格式基础数据标准化方案代码标准方案技术人员业务人员整合.定义补充.完善补充.完善沟通.确认技术部分业务部分基础数据标准沟通.确认xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx…………………………………………………………xxxxxxxxxxxxxxxxxxxxxxxxxxxxx目标建设方法-基础标准-制定框架基础数据标准框架属性参考人民银行标准规范文档和他行标准，由3部分22个属性项组成，分别为业务属性、技术属性、管理属性。目标建设方法-基础标准-指标标准建设思路目标建设方法-基础标准-指标标准筛选方法经营管理资料：行领导讲话我行各业务部门的业务经营分析报告我行的各类管理报表筛选原则：反映我行规模、风险、盈利、业务增长等各方面业务状况的典型指标口径稳定不易变化的指标外部资料：同业相关建设资料城商行银行国有银行建设银行人民银行、银监会监管指标要求筛选原则：监管部门有强制监管要求的指标同业用到，与我行业务有关的指标筛选、确认方式：项目组内部讨论筛选外部需求调研，进行补充和确认目标建设方法-基础标准-指标标准框架制定方法设计依据：指标的业务共性的归纳及提炼参考行内资料我行业务分类源业务系统操作手册及业务简介文档统计集中系统指标分类参考外部资料监管部门的管指标及指标分同业相关资料的指标分类设计原则分类体系覆盖筛选出的所有业务指标，并能为每个指标确定唯一的分类易于根据业务和指标变化进行扩展设计依据：人民银行《JRT0105-2014银行数据标准定义规范》外部资料设计原则：可以从业务、技术、管理不同角度对标准进行全面定义对指标标准必须清晰、明确满足未来对满足标准进行管理的需要目标建设方法-基础标准-指标数据标准框架指标数据标准框架业务属性技术属性管理属性指标中文名称指标英文名称指标范围类别计算公式业务规则相关指标标准是否手工录入显示精度指标落地系统数据来源系统数据源表数据格式度量单位取值范围归口业务部门业务负责人技术负责人反馈结果描述指标编码指标别名指标定义指标大类指标小类指标来源口径明细取数口径相关基础类数据标准指标生成频度取值精度指标应用-高管驾驶舱从经营概况到具体指标分析今日快报全行7项核心业务指标的展现和分析最重要3项监管指标进行展现和分析指标总览按分类展现全部指标的本期值及与往期的比较值的列表经营概览对某一具体指标进行比较、结构、趋势等方面的分析专项分析从业务角度对一组反映类似业务的指标进行分析热点地图　显示全国地图，可以展示各一级分行重要的经营简报数据我的指标规模分析利润分析风险分析主驾驶舱选取13个行领导重点关注的指标展示我的指标根据用户对指标的重视程度，实现指标的个性化定制功能简介指标总览主驾驶舱经营概览专项分析热点地图指标应用-高管驾驶舱-界面截图数据平台项目建设目标数据仓库层次架构主题逻辑视图实体属性共性提炼分类分层主题主题是模型按业务划分的最顶层的分类根据我行业务实际，划分10个业务主题逻辑视图（子主题）逻辑视图是根据实体涉及的业务，将实体划分为不同子集同一实体可属于不同逻辑视图实体实体是一组具有业务相关性的属性组成的集合，是描述和构成业务逻辑、业务流程的基本单位一个实体可能涉及多类业务属性模型最明细一级结构对应具体的业务数据项（字段）数据仓库层次架构…………风险评级内部机构对公客户对公客户信息对公客户管理信息不良贷款信息对公客户领导信息对公客户资本金构成财务信息机构信息…………当事人主题客户名称所属领域注册资本企业规模法人代表基本账户开户行……………………数据仓库模型设计方法TD模型业务剪裁保留与我行业务有关的主题、实体和属性删除与我行业务无关的主题、实体和属性根据我行业务实际需求对主题进行新增和合并逻辑模型设计复制：系统间业务含义、名称均不重复的字段整合：系统间业务含义相同的多个字段拆分：系统间业务含义不同，名称相同的多个字段物理模型设计当前业务及数据都支持的实体进行理化当前业务不支持或数据不支持的不进行物理化模型映射目标的建设方法-数据仓库模型框架整合层模型设计-基础模型（业务匹配）基础模型是TD模型在我行进行初步客户化后的产物。将TD模型的主题和实体，与我行的实际业务行的实际业务进行对比分析，根据匹配结果对TD模型进行裁剪、合并和扩充，形成匹配我行实际业务的情况的模型框架。当事人主题Teradata金融模型10.0基础模型我行无关业务我行现有关务我行未来关务我行现有业务我行无关业务我行未来业务对公客户合同机构……个人业务营销活动保险投资……合并当事人主题当事人主题保留保留增加业务匹配营销主题当事人资产主题产品主题事件主题协议主题地址主题渠道主题内部组织主题财务主题内部组织主题营销主题代码主题数据质量反馈目标的建设方法-数据仓库模型框架整合层模型设计-属性匹配对源业务系统的字段进行梳理分析，筛选出具体业务价格的字段，将业务字段与基础模型的主题、实体和属性进行匹配分析，根据匹配结果对基础模型的实体、属性进行增删。基础模型源业务系统业务字段分析匹配实体属性保留（整合）并映射新增并映射未来业务相关则逻辑化保留未来业务无关则删除数据仓库模型实体属性?新增属性？沟通确认数据质量反馈主题代码主题地址主题渠道主题财务主题事件主题当事人资产主题产品主题协议主题当事人主题逻辑模型设计-主题划分当事人当事人资产渠道财务产品地域协议事件代码逻辑模型设计-当事人主题当事人是一个独立的人或者一组人组成的机构、团体等，主要分为个人、机构和家庭，他们是和我行有往来或者出于营销、管理等各种需要希望关心和分析的个体或人群。从模型角度考虑，应该包括以下当事人信息：在我行登记注册开立账户的对公普通客户；我行担保客户和我行有业务往来的其他金融机构；机构的内部组织（如分支机构、部门等）；机构的员工（含我行柜员、员工等）；协议地址产品当事人渠道反馈域财务事件当事人资产代码逻辑模型个人信息联系信息关联信息财务信息风险信息评价信息集团信息柜员信息公司信息内部机构外部机构粮棉油对全行客户进行统一识别与数据整合当事人个人当事人家庭机构内部员工柜员外部组织机构内部机构金融机构（同业）对公客户其它内部组织金融机构内部组织逻辑模型设计-代码主题代码：是指将源业务系统所涉及到的所有代码进行整合，在整合层模型中统一存储，依据前端应用需求的需要，将代码主题的整合分为两大类：简单代码表和复杂代码表，简单代码表指的是只需要关注代码值和代码值业务含义描述；复杂代码表指的应用需求除关注代码值和代码值业务含义描述外，该代码表的其他属性也有应用需求，同样需要关注，这样的码表将作为普通的数据表对待；自定义代码，是属于简单码表的一种。公共类代码表协议类代码表分类模式编码表协议地址产品当事人渠道反馈域财务事件当事人资产代码逻辑模型简单码表复杂码表自定义代码分类模式编码表当事人类代码表公共类代码表分类模式枚举值编码表协议类代码表资产类代码表源和目标代码映射关系表事件类代码表财务类代码表对全行业务代码进行统一识别代码当事人类代码表事件类代码表分类模式枚举值编码表源和目标代码映射关系表逻辑模型设计-协议主题协议地址产品当事人渠道反馈域财务事件当事人资产代码协议是指金融机构与当事人之间针对某种特定产品或服务而签立的契约关系，如账户、客户和银行签订的合同等。当金融机构与客户之间针对某种产品或服务的条款和条件达成协议时，一个协议（Agreement）就会被开立，因此协议是客户和银行往来的重要载体，我行模型包括以下协议信息：我行涉及金额、期限、利率等的具体协议细项的金融账户我行与当事人之间针对某种特定产品或服务而签立的金融合约我行在支付结算业务中使用到的各种银行票据：汇票逻辑模型抵质押合同贷款借据项目额度申请贷款申请项目贷款贷款合同抵质押合同押品信息借据还款计划贷款帐户存款帐户贷款合同抵押合同质押合同贷款借据国际结算银行本票银行汇票其他信息银行承兑汇票客户理财签约银行与客户之间针对某种特定产品或服务而签立的契约关系，将所有协议和关系，整合和归并协议金融账户申请金融合约贷款账户银行票据存款账户内部账户贷款类合约逻辑模型设计-事件主题事件：可以记录各种与银行相关的活动的详细情况。既可以与资金相关，也可以与资金无关；既可以有客户参与，也可以没有客户参与；既可以与帐户相关，也可以与帐户无关；可以由客户发起，也可以由银行发起。总之它可以记录的范围非常广泛，包括交易数据，比如存款、提款、付款、收取信用卡年费、计算利息和费用、投诉、查询产品、查询地址、查询余额、网上交易等。我行模型包括以下事件信息：存款信息、贷款信息；库存管理、现金管理、账户管理、资产管理；资金调拨、支付结算、现代化支付；报文清算、国际业务；外汇、票据、市场交易、十二级分类、核心账务。商品棉贷款信息采集粮油库存核查同业定期存款汇入同业定期存款汇出新棉收购进度采集棉花农资库存变动协议地址产品当事人渠道反馈域财务事件当事人资产代码逻辑模型同业定期存款汇入贷款缩期事件新棉收购进度采集同业定期存款汇出贷款展期事件商品棉贷款信息采集大额支付事件贷款转移事件粮油库存核查小额支付事件分段计息事件棉花农资库存变动该主题可以记录各种与银行相关的活动的详细情况，进行客户行为分析、重大事件侦测等，以便更好的进行客户细分、客户关怀。事件贷款事件存款事件库存管理事件贷款缩期贷款展期分段计息贷款转移逻辑模型设计-财务主题财务：主要包括银行的总账信息，是描述科目组织、控制、内部核算等银行核心科目账务以及预算管理有关的内容。该主题抽象地描述了银行内部账务的组织模式，能够适应不同的科目组织体系。我行模型包括以下财务信息：总账（分户）总账明细科目/科目组/科目类：对于科目的层次级别设置和管理财务预算总账日旬余额总账月余额协议地址产品当事人渠道反馈域财务事件当事人资产代码逻辑模型总账科目信贷总账科目内外科目对照关系总账日旬余额日明细内部科目余额科目与产品对照关系总账月余额月明细内部科目余额日明细外部科目余额外汇准备金科目余额外汇科目损益余额日明细外部科目余额财务主题抽象地描述了银行内部账务的组织模式，能够适应不同的科目组织体系，它侧重于“财务管理”总账科目总账内外科目对照关系科目产品对照关系信贷总账科目逻辑模型设计-当事人资产主题当事人资产：描述当事人的所有资产，该主题包含两大类的资产，既包含我行自有资产又包含客户所拥有的资产。一个资产可以被多个当事人所拥有，一个当事人可以与多个资产有关。资产可分为实物资产、金融资产与无形资产。客户资产信息的来源很多情况下是在客户申请贷款时所提供的各种担保品信息、抵质押品信息等。我行模型包括以下资产信息：银行自有资产，具体又细分为：银行自有无形资产、固定资产、经营性租赁资产、其他资产等；客户自有资产，具体又细分为：客户抵债资产、客户担保资产、金融资产、实物资产、无形资产等。客户担保资产金融资产客户抵债资产实物资产抵质资产房产信息交通运输设备协议地址产品当事人渠道反馈域财务事件当事人资产代码逻辑模型银行自有资产客户抵债资产客户担保资产经营性租赁资产抵债资产房产抵质押物银行自有无形资产抵债资产设备押品外部评估信息银行自有固定资产抵债资产地产押品内部评估信息客户资产信息的来源很多情况下是在客户申请贷款时所提供的各种担保品信息、抵质押品信息等，将这种信息进行整合和归并资产银行自有资产客户自有资产固定资产无形资产其他资产租赁资产数据映射和ETL开发源表映射文件目标表开发规范合并拆分复制ETL业务含义不同，名称相同，进行拆分业务含义相同、名称不同，进行合并业务含义相同、名称相同，进行合并转换生成新键值代码值转换数据类型转换值域转换值转换ETL开发人员按照映射文件中规定的映射逻辑要求，结合开发规范，编写作业，通过数据源分析，制定加载策略，开发JOB调度直接拷贝加载策略数据源分析常量赋固定值1表间关联/单表操作（LeftJoin,InnerJoin,FullJoin,Union）映射文件通过映射文件，确定表间关系数据映射和ETL开发定义源：配置作业源表的表名、表结构等信息创建映射：根据作业详细设计中表与表之间及字段之间的映射关系，使用相应的组件实现其数据转换逻辑定义目标：配置作业目标表的表名、表结构、加载方式等信息定义源创建映射定义目标项目提交物（总共108项交付文档）目标的建设方法-数据仓库模型框架（4）整合层模型建设对应用的支撑整合层的稳定性整合层提供全行统一的业务视图整合层的数据全面性整合层提供明细的数据整合层保留完整的历史数据保证模型对未来业务的业务支持的快速响应，不需要随业务的变化而频繁调整整合层模型形成明确业务含义和数据来源，确保字段业务定义的唯一性，形成全行统一的业务视图保留了业务系统中最细粒度的业务数据，保证整合层可以支持明细级的数据查询和分析应用整合层涵盖我行主要源业务系统的业务信息，提供全面的业务数据，可以为客户、风险、绩效等各类分析应整合层中可以完整保留业务系统的历史数据，保证了对历史类查询分析的支持客户360度统一视图通过整合层模型落地ETL客户360度统一视图客户额度信息联系人/关联信息客户大事记交易信息理财产品信息产品/账户信息国际结算信息资本构成/股权投资客户财务信息客户基本信息客户合作协议其它信息贷款存款中间业务利润贡献关联关系联系人/关键人统一客户关联信息视图对公客户统计与分析管理客户基本信息客户额度信息客户财务信息客户关联信息客户关键人信息客户联系人信息客户上市信息客户存款信息客户贷款信息账务交易信息账户日均余额客户考核利润客户管户信息国际结算信息网银交易信息机构信息……统计数据业务规模统计资金流向统计额度信息统计客户分类统计授信客户统计行业客户统计……整合层模型对客户营销的支持当事人主题协议主题事件主题CRM-客户贡献度分析核心信贷管理对公客户表客户表存款账户表存款交易明细表客户号客户名称存款余额借据表贷款余额季度存款交易量。。。。。。债项评级。。。。。。五级分类同一客户信息整合整合层模型营销策略-客户贡献度分类：存款余额大于xx万，贷款余额大于xxxx万，并且属于正常贷款，且季度存款交易量大于xxx条的为A客户；存款余额大于xx万，贷款余额大于xxxx万，并且属于正常贷款，且季度存款交易量大于xxx条的为B客户；存款余额大于xx万，贷款余额大于xxxx万，并且属于次级贷款，且季度存款交易量大于xxx条的为C客户；通过客户贡献度的分类，制定营销策略，比如贡献度为A的客户，可进行贷款利率上的优惠或存款利率的上浮的方式稳定此利润点客户贡献度分类整合层模型对客户营销的支持当事人主题协议主题事件主题核心信贷管理对公客户表客户表存款账户表存款交易明细表借据表。。。。。。债项评级。。。。。。同一客户信息整合整合层模型营销CRM-客户忠诚度分析客户号客户名称是否基本户账户日均余额贷款期限贷款金额现金流量是否异常账户睡眠时间业务量是否异常客户忠诚度分类营销策略-客户忠诚度分类：通过客户忠诚度的分类，忠诚度越大、则是我行重点的目标客户，可作为战略重点客户。如果忠诚度不大，则要进行重点客户关系维护，即精准营销汇总层目标与定位作为整合层和集市层的衔接，从业务的视角出发，提炼出对数据仓库具有共性的数据访问需求，抽取出公共指标，形成由维度和指标组成的维度模型，对符合要求的数据进行预汇总和预加工。为集市层统一提供规范的、准确的数据。完成整个汇总层的逻辑模型、物理模型的设计并全部实现物理化。并根据业务性质将业务数据，划分为以下七大类主题分类存放和管理建设阶段和步骤2.2参考模型到数据源的匹配2.1数据源到参考模型的匹配1.2当前用到的属性分析1.1参考模型设计3.1物理模型设计一、逻辑模型初步设计二、逻辑模型具体设计三、开发实现2.3应用驱动模型完善业务驱动循环客户需求调研逻辑模型设计3.2数据映射3.3ETL个人、存款、贷款、贷款、信用卡建设重点协调业务系统开发商对系统进行讲解，了解具体的业务流程并对开发人员整理出的源业务系统调研提纲中所提出的问题进行解答对源系统表对象调研对源系统表字段调研根据源系统数据验证调研结果依据调研结果对模型进行属性的补充完善存储策略设计思想将汇总层划分为两个存储区域，数据集市应用从历史数据区和快照区获取数据。历史数据区数据集市数据集市数据集市快照区（T-1日，数据日期）应用层数据存储区ODS层、整合层月表历史区流水类表第四部分成效和特点项目成效-中长期价值进一步扩展了数据范围，容纳了新数据，实现对业务数据的全覆盖，当未来有新的业务需求时，保证了数据架构的稳定性支撑全行级的数据应用，数据平台可提供全行级的最细粒度数据，满足未来建设决策支持系统如：客户关系管理、资产负债管理、管理会计、信用风险管理、管理驾驶舱等业务数据模型支撑数据挖掘，支持各业务部门进行客户价值分析、客户行为分析、货款偿还预测分析、客户信用政策分析、业务关联分析等数据挖掘应用项目建设特点-多方参与，字段级加工整合层模型业务字段业务答疑源业务系统公司方业务人员技术人员源系统厂商模型验证数据质量检查分析系统调研ETL数据质量数据标准业务调研技术调研数据调研模型映射ETL加工结果验证技术答疑技术讲解业务相关标准定义业务相关标准确认技术相关标准定义技术相关标准确认标准化分析标准映射源系统答疑源系统讲解资料提供项目建设特点-分工协作，共同推动（1）本期项目建设实施过程遵循“技术先行，业务配合”的原则，需要技术部门主导、业务部门解决数据“如何整合”的问题，合作公司解决数据“是什么”的问题技术人员提交标准后，对应的业务部门人员需确认结果,对有异议的结果进行修改和补充，这个过程可能需要经过多次反复确认，从而制定最终的标准化产物并发布，形成全行标准项目建设特点-分工协作，共同推动（1）业务部门解决数据“如何整合”的问题业务部门需要确认技术部门提出的整合规则（标准）是否合适，以便解决信息孤岛和准确性问题，整合规则分为两个方面，分别为：系统间整合规则和系统内整合规则，确认内容如下：对技术部门提出的，名称相同，业务含义相同的数据整合标准是否认可对技术部门提出的，名称不同，业务含义相同的数据整合标准是否认可对技术部门提出的，名称