system: [SYSTEM]

user: 3. 数据治理体系 3.1. 组织构建 数据治理体系的组织构建旨在通过建立组织架构明确各级角色和职责，保障数据治理的各项管理方法、工作流程的实施，关联数据治理工作的有序开展。组织架构主要包括数据治理决策者、数据分析者、数据关 联者、数据测试者，数据质量管控者，数据清洗者。 具体包括如下人员：北京燃气集团信息档案中心、北京燃气集团销售服务部、北京燃气集团第一至五分公司和郊区子公司、北京信息科技大学，角色职责见表1。 3.2. 数据摸底 数据摸底工作在整个流程中非常关键，是对地址数据进行数据抽取，充分了解数据情况，从而制定合理的解决方案。通过数据抽取我们发现地址存在多样性，ic地址和kf地址存在严重差异，导致信息无法关联，主要分为以下几类：地址别称、信息缺失、重复记录等等，如下表2所示 [ 2 ] 。 Table 1 Role role 参与人员 对应职责 北京燃气集团 信息档案中心 甲方、协调关系、提供数据资源 销售服务部 需求发起方，数据核验与使用 分公司人员 数据确认、根据客户电话人工录入 北京信息科技大学计算机学院 项目经理 制定策略、协调、仲裁 数据分析人员 数据分析、分类及总结 数据关联人员 数据关联、设计算法 数据测试人员 数据核验、检查 质量管理人员 数据质量审查、把控 数据清洗人员 数据分词、过滤、清洗 表1. 角色职责表 Table 2 Common address error typ 地址类型 ic地址 kf地址 地址缺失 南华里 陶然亭街道南华里 拼写错误 俊景园 俊景苑 地址别称 韵竹园 陶然亭街道虎坊路19号院 地址重复 枣苑6号楼1单元905 北京市东花市街道花市枣苑6号楼1单元905 表2. 常见的地址错误类型 地址信息中楼号、单元号、门牌号缺失情况均有，导致整个小区无法关联，也有描述不清晰导致未关联的情况，例如“团河苑小区(团河农商行)”小区名表述模糊，实际分为东南西中四个区，地址信息中楼号、单元号、门牌号有重复的情况导致关联时出现一对多，多对一，由于有一个地址，存在多个用户的情况，例如：平房或四合院用户、写字楼类 用户、壁挂炉和普通家庭用户，导致数据库管理系统不能正确识别，造成重复记录。由于系统中用户的联系人和电话登记信息不完整，很难根据记录所包含的描述信息来确定与之相对应的实体，因此采用相似匹配技术，利用记录的文本相似度来判断两条记录是否相似，并且结合记录的语义信息来提高匹配的精度。 3.3. 策略制定 首先制定项目总体实施进度，确定任务交付时间有利于更好的制定计划。每周会议形式汇报本周工作完成情况以及下周工作计划，明确落实情况。及时反馈存在问题的数据情况，需要业务人员配合的事项要及时沟通。 针对全部地址数据的关联建立一套流程，包括地址预处理模型、关键词知识库迭代模型和地址数量猜测模 型，得到地址标准化结果和已匹配地址、未匹配地址。流程如下图1所示。地址预处理模型即数据清理过程，由数据抽取、数据分词、数据过滤、数据存储和数据标准化五个模块整合组成。关键词知识库迭代模型是将小区名进行字符串匹配和地理坐标定位，得到不同小区之间的关系，并构建了关键词知识库。数量猜测模型是指根据小区包含的户数做猜测，判断包含别名的小区之间的关系。 图1. 地址关联流程设计 数据清理遵循以下原则，如下表3所示： 1) 计算机+人工协同处理； 2) 不同数据使用不同关联方法； 3) 基于小区的模块处理方法； 4) 综合考虑多种方法结果进行双向预测与判定； Table 3 Data cleansing principle 处理步骤及方法 采取方法 单纯的计算机处理 直接对地址进行模糊匹配； 基于中文分词、结巴分词和词向量技术进行地址关联； 基于正则表达式的确定状态自动机的精确匹配 基于小区的计算机处理 通过分类算法将剩余数据按小区分类，基于小区的经纬度、户数、楼号等维度，按模块进行条件概率下的双向检索与判定，快速实现数据的分析、预测、关联与整合 基于用户信息的数据关联 通过用户姓名、电话和购气记录信息进行异源异构的数据关联 人工处理 人工校对后执行前两步分析处理 表3. 数据清理原则 3.4. 数据治理 通过数据摸底我们已经了解了地址数据的多样性，制定了处理策略，针对全部待清理数据进行数据治理，首先设计了一套数据清理方案，包含五个模块，分别是数据抽取、数据分词、数据过滤、数据存储、数据标准化，最后进行数据关联。方案如下图2所示。 图2. 数据清洗方案图 3.4.1. 数据抽取 数据的抽取必须能够充分满足数据清洗的需要，同时又要保证不影响源系统(民用IC卡系统、用户客服系统)的性能。一般情况下采用专用数据库驱动接口，必要的时候采用API接口编程实现数据的抽取，以提高数据抽取效率，同时减少对源系统性能的影响。对原始系统数据进行抽取，包括对分词后、标准化后以及关联后的每一步结果进行抽取都是必要的，都作为下一步的输入。 3.4.2. 数据分词 本项目基于特征字符的分词方案可以将地址按逻辑意义分为行政区域、街道、小区、楼、单元及门牌号六组信息分段管理。数据分词采用正则表达式结合特征字符进行分词。 分词的基本思想是首先创建基于行政区域、街道、小区、楼、单元标准信息的元数据库，根据能够区分出五组信息的特征字符的位置进行行政区域、街道、小区、楼、单元信息的截取。对于含有多语言文本表示的字段可先将西文和数字分离出来，再将地址字段按特征字符进行分词。应用基于元数据内容进行匹配的方法将截取的信息与元数据库中的标准信息进行校验，若匹配成功则返回元数据库中的标准信息，删除地址信息中相应长度的字符后再进行下一级别的信息匹配，从而实现信息的分割。进而保证了分词的准确性。 具体操作分类如下： ① 时有行政区域、街道、小区、楼、单元特征字符； ② 只含有街道、小区、楼、单元特征字符的地址信息； ③ 只含小区、楼、单元特征字符而不含街道特征字符； ④ 只含小区、单元特征字符而不含街道、楼特征字符； ⑤ 只含小区、门牌特征字符而不含街道、楼、单元特征字符； ⑥ 不含任何级别特征字符。 结果表明该方案能将绝大多数的地址类信息按逻辑意义进行分组。分析实际地址情况后建立特征字符集如表4所示，基于表4中列举的特征字结合正则表达式进行不同情况数据的分词。 Table 4 Feature character se 元组 对应特征字符 行政区划 东城区、西城区、朝阳区、丰台区、石景山区、海淀区、门头沟区、房山区、通州区、顺义区、昌平区、大兴区、怀柔区、平谷区密云区、延庆区、崇文区、宣武区 街道 街、街道、斜街、道、路 小区、机构、别墅区、 平房、院落、号 小区、社区、数字+“区”、大学、中学、小学、学校、学院、别墅、公寓、院、水库、园、“街”+数字+“号”、大厦 栋楼、座 座、号楼、楼 单元 单元 门牌号 室、门 表4. 特征字符集 3.4.3. 数据过滤 数据过滤的流程是重复记录清洗的过程，包括重复记录检测及处理。为了使数据库中每条记录都表示不同用户地址的准确数据，通常对相似重复记录聚类中数据的处理可采用合并或删除的方法。 依据实际情况将计算机自动处理与人工处理相结合。针对地址类信息的相似重复记录进行检测和处理，分为预处理和重复记录匹配两个模块。预处理模块包括属性选择(选取用于记录匹配的属性)、初步聚类(将潜在的可能重复的记录调整到邻近的位置)及清洗脏字段(处理不规范的数据)三个步骤，然后通过重复记录的匹配及其相似度的计算，能简单地、准确地确定两条记录间的相似度，其次是重复记录的聚类，使用基本近邻排序方法、多趟排序近邻方法和优先队策略等方法，即在前者的基础上，快速地在一个记录集中检索出所有相互匹配的相似记录集。 3.4.4. 数据存储 按计划分阶段完成一分、二分、三分、四分、五分和昌平公司的民用IC卡用户数据通过质量检查的数据导出工作。导出数据格式需要按照用户管理系统系统要求，支持导出数据可以导入用户管理系统。 3.4.5. 数据标准化 常见的地址不规范情况如下： ① 小写数字混淆； ② 全角、半角字符混淆； ③ 存在“-”、“--”、“#”等不规范符号表达； ④ 要素中包含冗余的“0”或者冗余汉字，如5号楼可能表达为“005号楼”。 针对以上的表达不规范情况，总结字符映射转换表格如下表5所示，进行多样表达的规范统一。 Table 5 Character map transform tabl 原始数据字符 标准化字符 一、二、三、四、五、六、七、八、九、十 1、2、3、4、5、6、7、8、9、10 全角符号 半角符号 号楼、楼、-、# 号楼 门、户、室 室 a座、b座 A座、B座 表5. 字符映射转换表 3.4.6. 数据关联 标准化的数据，通过关键词知识库迭代模型，将小区名进行字符串匹配和地理坐标定位调用高德API接口进行地理坐标确认，得到不同小区之间的关系，并构建了关键词知识库，基于小区之间的关系进行详细地址的匹配。输出已匹配的关键词，未匹配关键词通过数量猜测模型，根据小区包含的户数做猜测，判断包含别名的小区之间的关系。在创建别名知识库过程中涉及制定的情况标记规则，规则如表6。 Table 6 Situation mark rule tabl 标记编号 情况说明 1 两个相似名称所指范围不一致，如“天通苑”与“天通苑北区” 2 有冗余信息 3 简称与全称并存 4 有小区别名情况 5 两种表达方式，如同一个地址可以表达为“xxx小区”，也可以表达为“xxx街(胡同)xx号”。 6 有错别字 7 无法处理 表6. 情况标记规则表 进行地理坐标定位具体设计步骤如下： ①创建账户后申请key ②引入高德地图API ③创建地图容器 ④创建默认地图 var map = new AMap.Map('container'); map.setZoom(10); //setzoom指定缩放级别 map.setCenter([116.39，39.9]);//指定地图中心 ⑤点标注可以添加参数 var marker = new AMap.Marker({ icon : 'http://vdata.amap.com/icons/b18/1/2.png'，//24px*24px//自定义图标 position : provinces[i].center.split('，')， offset : new AMap.Pixel(-12，-12)， map : mapObj }); 3.5. 数据验证 对已经关联的数据，进行全面的质量检查，只有通过检查的数据才能导入用户管理系统，检查失败的数据支持打回，重新进行分词、关联和核对。为了验证本文提出的数据治理体系的可用性，计算的“关联率”和“准确率”指标衡量地址关联的完成程度。关联率为两个系统“一一对应”的关联条数除以系统的数据总条数，准确率是达到地址中行政区域、街道、小区、楼、单元、门牌号的“一一关联”。从燃气IC系统真实用户数据中随机抽取样本7个小区，计算其关联率 [ 3 ] ，结果如表7所示。 Table 7 Roportion of associated dat 小区 总数 原始关联 关联处理后 剩余 增量 关联率 A 132 0 132 0 100.00% 100.00% B 259 1 259 0 99.61% 100.00% C 712 1 705 7 98.88% 99.02% D 1145 7 1127 18 97.82% 98.43% E 398 0 367 31 92.21% 92.21% F 979 201 975 4 79.06% 99.59% G 2527 1791 2482 45 27.34% 98.22% 表7. 关联数据所占比 分别从未关联数、关联后增量、关联率几个数据进行分析发现此关联方案能达到预期效果，针对每个小区的关联结果都有不同幅度从27%~100%的增量，各关联率均在92%以上。下面抽取各分公司已关联数据和总数据进行对比，分析其关联的准确率，结果如表8所示。 Table 8 Association accurac 公司 已关联数据 总数据 已关联的准确率 一分 82，541 105，490 95% 二分 236，453 317，550 97.50% 三分 325，962 408，502 97.20% 四分 403，442 477，441 100% 五分 382，665 482，304 98% 昌平 15，314 20，517 100% 总计 1，445，741 1，811，804 98.10% 表8. 关联准确率 各分公司地址数据关联准确率都达到97%以上，四分和昌平达到100%，其他公司未达100%的原因一方面是由于原始数据中还存在一些要素严重缺失的数据，例如有的地址没有楼号、单元号、门牌号；另一方面是由于重复数据的存在，单元号和门牌号的对应错误。总体来看，本数据治理体系在处理复杂地址数据关联时可以获得较高的关联率和准确率，证明了此体系的可用性和有效性。