数据迁移:高难度带来高回报

译文
运维 数据库运维 新闻
在过去的十年中,我已经遇到过数不清的数据再加工任务。无论是把古老的数据库迁移到现代化数据库当中,还是将大规模数据集利用新型处理工具进行牵引等,将数据由一种格式转化为另一种新格式的任务始终不断出现、频度极高甚至每天都有。而且对于包括IT部门在内的绝大多数人来说,这一转换过程仍然神奇乃至神秘。

【51CTO译文】请允许我花几分钟向大家解释整个转换处理方式,至少是在宏观上形成概念。在阅读之后,大家可能会发现这方面知识有助于帮助各位向非技术人士详尽阐释相关的后端流程。

一切从Excel开始

让我们先从最困难的常见情况:可怕的Excel电子表格开始。就在前一阵子,某家远在他方的企业打算对有价值的业务流程数据进行一番收集与整理,其中包括库存、销售额、客户资料等等。由于缺乏合适的工具,员工制作了一份Excel电子表格,并利用它承载信息。随着时间的推移,其中逐渐积累起数千条记录、电子表格本身的功能性缺失也开始暴露出来。最终,企业管理者决定将这部分数据转换成到真正的数据库当中。不知道他们当时是选择聘请咨询服务公司还是利用内部资源加以处理,总之有人接手了这份工作。

这项任务的第一步是检查数据本身的纯洁度。在理想状态下,电子表格本身会以数据库的方式对信息进行分类,且每个数据填充区都处于对应的列之下——例如姓氏、名字、街道、城市等等。然而事情并不总能如此顺利,有时候两类包含信息交集的单元格会自上而下位于同一列当中。就以联系人列为例,其中很可能囊括了全名、公司、地址、电话号码等多种独立单元。紧随其后的下一列也可能是对方最新订购信息或2012年采购总额等数据,这就给转换工作带来了极大的挑战。

让我们先看看第一种情况——即理想情况,这是最易于处理的状态。数据比较单纯且具备良好的排序,我们可以通过CSV将其导出并通过自定义解析器把它翻译成数据库内容。优秀的CSV解析器能够将所有这些记录逐一抽离出来汇总成整体数组,然后插入到新的数据库当中。在整个过程中,我们可以对数据进行检查及修改,进而使数据格式更好地适应新数据库的要求。

举例来说,我们可能会利用正则表达式处理电话号码信息,旨在将不同格式的电话号码转化为同一标准。这要求大家在将内容插入新数据库之前,调整好表格中包含的一切特殊符号并对字符串进行格式化处理。操作将把(212)555-1212、212-555-1212、2125551212、212555 1212或者212.555.1212等数字转化成统一的电话号码格式(2120555-1212,这既能提高数字的可读性、又便于未来进行搜索。

我们会利用/[^0-9]+/ 这样的正则表达式实现去格式化,然后通过/([0-9]{3})([0-9]{3})([0-9]{4})/表达式将内容重新加工为新的格式,这样最终结果才能正确处理组成分段号码信息的212、555与1212三部分。只要愿意,我们马上就可以对电话号码进行二次格式化。但请注意,如果我们遇到那些因为太长或太短而不可能是电话号码的数字对象时,也要想好对应的解决方式。

让自由格式贯穿始终

然而一旦表格的格式更加自由,处理的难度也就随之提升。地址就是其中最不容易打理的类型,因为它们的格式比较随意、可能需要通过多种不同方式进行格式化。另外大家还需要留意形态万千的街道与城市名称。举例来说,我们必须确保自己能正确识别“华盛顿哥伦比亚特区”、“华盛顿特区”和“华盛顿”这三种缩写(分别为Washington,DC、Washington, DC以及Washington DC),并弄清楚"Winston-Salem, NC," "King of Prussia, PA," "Scranton, Penn.," "N. Providence RI," "Houston, tx," and "O'Fallon, IL."等令人头痛的城市名称与所在州名称组合。

如果不对内容进行严格界定,这些层出不穷的变化完全可能把解析器逼到崩溃,因为我们无法去除其中存在的特殊字符。另外,我们也不能指望通过不同数量的空格来区分城市名称、州名称、州名称缩写或者地名大写等。因此,我们需要创建一套条件表达式,以最大程度确定这些数据所对应的实际城市与国家,甚至必须与包含美国所有城市与州名称的标准数据库进行比照。根据检测结果,我们可能需要对记录进行重新清查或者至少将对应记录加以标记,以备日后手动检查。

到这里,我们才仅仅剥开问题的表面。光是搞清楚每条记录中城市、州名与电话号码就需要我们投入大量资金与精力,更不要说重新加工并重复电子表格中的其它文本信息了——具体工作量取决于其实际内容。

为什么会出现如此被动的局面?这是因为数据项使用了不受约束的自由格式,而它几乎困扰着世界各地的每一家企业。需要强调,Excel并不是这一切问题的罪魁祸首。Access、自主开发的数据库或者其它任何应用都可能引发此类难题。可以说,除非我们严格把住输入数据的类型与格式关,否则数据积累的结果只会是一团乱麻。很显然,解决问题的关键在于建立一套合适的数据库前端来处理数据输入:我们可以在数据进入的同时对其进行清理与调整,这将大大提高数据的准确性与可用性。准确性与可用性,这是优先使用数据库处理信息的主要优势之一。

然而我们也不能忽视利用后端处理这些数据库集类型的努力。目前我们已经拥有各类相当成熟的工具来简化这一流程,但它们仍无法在每个用例中都切实生效。尽管它们能在一定程度上让输入数据保持“标准”,但漏掉的部分同样会引发问题,这种冲突甚至比不进行预处理来得更加严重。

这类工作相当乏味,需要技术人员将全部精力集中在细节之上。它要求我们投入大量人工进行数据检验、试运行、调整并对部分项目开发工作加以前瞻性考量。但总体而言,这一切付出几乎都能获得令人满意的高额回报。

纯洁清爽的数据令日常工作变得极富效率,这也是每家企业所追求的目标。但大家也千万不能低估整个转换过程中可能出现的严峻挑战。

原文链接:http://www.infoworld.com/d/data-center/data-migration-hard-do-216342

原文标题:Data migration is hard to do

【编辑推荐】

责任编辑:彭凡 来源: 51CTO
相关推荐

2014-06-13 11:25:41

WiFi华为

2012-10-23 17:04:44

2019-08-13 16:40:14

2014-06-19 14:57:40

网络·安全技术周刊

2013-08-01 10:07:45

Splunk

2013-01-21 10:46:34

公有云IaaS云计算

2024-09-23 13:41:05

2009-09-15 16:52:19

Linq To Dat

2010-02-24 17:01:44

路由器

2024-12-05 14:50:31

2014-08-07 10:49:20

debugdebug技巧

2014-02-28 13:27:08

程序员代码

2021-03-15 22:56:55

大数据技术高薪

2024-12-23 10:20:00

数据训练模型

2021-06-03 12:16:18

腾讯云机器人Robotics X

2017-03-02 13:23:53

订单系统水平分库

2024-08-19 09:38:00

2022-02-12 22:16:53

TypeScript类型字符串

2024-02-06 12:49:48

AI模型

2021-12-07 14:54:27

人工智能病毒算法
点赞
收藏

51CTO技术栈公众号