首页 > IT资讯 > 正文

大数据含义之大多样性

大多样性意味着试图处理来自极多数据源的数据,造成了数据整合方面的巨大挑战。我集中考虑结构性数据的整合,由其他人考虑文本数据的整合。

上世纪九十年代,在巨型零售商的带领下,大多数大型企业建立了“企业数据仓库”。这些仓库含有货品级的销售历史数据,供产品经理查询。实际上,其目的是确定哪些商品开始流行(如芭比娃娃)、哪些商品过时了(如宠物石)。芭比娃娃就被搬到商店前端促销、宠物石则被快速下架。零售商发现,因存货周转和采购决策改善,销售数据仓库不到一年就收回了成本。大多数大型企业步零售商后尘,建立了销售及客户数据仓库。此类仓库一般整合了最多十余个数据源,成为ETL(萃取、转换、加载)供应商的焦点。涌现出的ETL方法论是:

对每个需要整合的数据源 {

分派一位程序员去理解该数据源(通过与人交谈、读文档等).

程序员用脚本语言写程序来从数据源提取数据

程序员弄清如何把该局部数据源映射到预先定义的全局模式(schema)

程序员编写任何所需的数据清理及/或转换程序

}

这一极其广泛采用的方法论具有若干劣势:

全局模式也许事前并不存在。在我熟悉的一个用例中,一个大型制药公司意图把几千位湿法化学师和生物学家的电子实验记录本整合。全局数据模式必须通过组合局部模式拼起来。故全局模式是整合的副产品、而不是一开始就有的。

编写转换程序也许很难(甚至不可能)。例如,来自巴黎的局部数据源中的“薪金”属性也许是指某人的税后欧元工资、包括午餐费。这些语义也许在任何数据字典中都查不到。如此,程序员在理解局部数据源属性时会步履艰难。

数据清理程序编写也许极其困难。例如,很难确定两个不同的餐馆共用一个地址是有效的(如美食广场)、还是其中一个已经破产被另一个所取代了。

数据整合无法一次完成。所有数据模式、转换、映射也许会依时间而变化、依局部数据源更新而变化。这些要素每月即有变化也并非罕见。

此方法论不具备规模效应。因为许多步骤都靠人力,整个过程规模扩大到几十个局部数据源之后,成本就变得难以承受了。

鉴于大数据的全部理念就在于规模效应,本帖的其余部分将专注于上述第5条。

我听说过若干企业把数据整合视为头等大事。一般而言,大多数都在几年前投资于数据仓库,将销售、客户、或产品信息整合成了组合式的数据库。然而,绝大多数均面临这个小故事中所显示的难题。

九十年代晚期我到访一家大啤酒公司,该公司有个传统的数据仓库,存的是销售信息,以分销商、品牌、时间段分类。当时,气候预报称将有一个“厄尔尼诺”冬季,即是说,预测西海岸的降雨量和东北地区的温度均高于常态。我问该公司的商业智能(BI)员工:“您认为啤酒销售与温度或降雨量有关联吗?”他们回应说,能找到答案就太棒了,但不幸地是,数据仓库里没有气候数据。

实际上,业务分析师想通过新数据源关联企业数据以期获得商业洞察力,这一胃口是无法满足的。一个典型的企业具有5,000以上操作型数据源,部分涉及对业务的深入了解。再者,很多企业的财务数据存于电子表格,也许在财务总监的笔记本电脑中。最后,互联网上有公开数据源的金矿(例如气候数据)。最终结果是,业务分析师施压要求整合越来越多的数据源,从而造成了日益艰难的数据整合问题。

新业务需求也将经常产生相同的压力,例如企业部门产品间的交叉销售、通过对网站会话中网民的进一步了解以改进广告投放。一个案例是车险行业,该行业正处于把“大规模个性化”用于保险费率的过程。该过程十年前由Progressive保险公司启动,即在车内安装传感器、奖励驾车者的安全驾驶行为。此概念正被推广到包括驾驶的时间与地点及其他信息(信用级别、近期生活变化等)。同样地,新业务需求决定了数据整合相当困难。

本帖其余部分是我对规模化数据整合的若干建议。

人工干预:首先,传统方法论的规模可达到几十个数据源,但不可能把规模扩大到几百个、上千个。欲使规模扩大,传统的方法论不得不让位于机器学习和统计学以自动“摘取低悬的水果”(译注:成语,避难就易的意思)。只是在自动算法失败时才应人工干预。本人在CIDR '13的论文介绍了此方法的一种策略,可供参阅。

转换:第二,以程序员编写转换(transformation)程序绝不可能有规模效应。替代方案是,简单的转换应通过自动猜测实现,较复杂的则应采用“所见即所得”(WHYSWIG)式界面供非程序员完成。此方向一个好的起点是采用斯坦福大学的软件Data Wrangler(vis.stanford.edu/wrangler)。只是最复杂的转换才应需要程序员。尽管大部分专有ETL框架具有转换库,但是,为转换建一个不涉及软件特许权的公共目录,会是极其有益的服务。我猜测,因为程序员找不到已有的转换版本,故不得不从零开始编写、重复劳动。

实体合并:其最简单的实例是数据去除冗余。然而,在大多数情况下,数据源对同一实体(entity)所含有的信息不尽相同,故需要一个合并(consolidation)阶段。合并可以是特定领域的(例如英语姓名或公司名称),也可以是通用的(例如只在属性空间中寻找记录丛集)。所有低悬的水果均应由自动算法摘取,人工干预只用于复杂的情形。

清理:据推测采用“所见既所得”式的清理工具(例如DbWipes,www.mit.edu/~eugenewu/files/papers/dbwipes-vldb2012.pdf/)可获益良多。我预期将有许多具备大量可视化组件的好理念出现。

进一步说,当同一个实体(例如名为“红龙虾”的餐馆)出自多个数据源时,一些清理工作可在实体合并时自动启动。假如自动算法确认同一个实体列在了不同的地址里或具有不同的电话号码,那么数据更正可自动执行。

由于任何自动系统都难免发生错误,应该建立处理错误数据的业务程序。因此,百分之百的准确性是虚幻的,企业需要应对错误的机制。例如,一个大型的网上零售商承认,操作总会发生错误,故建有系统来处理由此可能引起的顾客投诉。

包装器:最头疼的问题之一是从遗留系统中提取数据(例如从SAP或PeopleSoft系统)、再将其造型(cast)为数据整合系统可读的格式。遗留系统ETL供应商已经用了大量时间来为流行系统建立包装器(wrapper)。但对其余的数据源如何建包装器呢?同样令人望而生畏的是网上数据。尽管在HTML表格中有些数据很容易读取,但大多数有意义的数据埋在文本、下拉菜单之内,或者在按钮之后(所谓深层网站里)。在此情况下造出高成本效益的萃取器(extractor)仍问题多多,亟需好的理念。


上一篇:程序员应该具备的意识
下一篇:Python 软件基金会达到和解,商标争议结束

PythonTab微信公众号:

Python技术交流互助群 ( 请勿加多个群 ):

群1: 87464755

群2: 333646237

群3: 318130924

群4: 385100854