创建一个360°视图(3):数据设计及导入策略

在本系列关于360°视图的第一部分中,我们描述了在MongoDB中创建一个360°视图的原因。在第二部分中,我们探讨了一个360°视图数据模型实例的具体实现。本周,我们将讨论如何真正将你的数据导入到现有的360°视图。

现在已经是2015年了,将数据从一个地方迁移到另一个地方应该很简单,不是吗?当然,真正尝试过的人才会了解到这并不简单。

 

为什么迁移仍然会这么困难?

表面看上去非常简单。你在某个系统中拥有数据,并且工作得非常好。而你在另一个系统中拥有其它数据,它们也运行得非常好。难道你不应该尝试将它们组合到一个新的系统中以完成新的、激动人心的工作,并且也能运行得非常好吗?

 

这样不是很好吗?

当然,问题在于这些看上去非常简单的蓝色箭头实际上代表着许多不同的操作。你或许要从许多文件中提取大量的表、解决编码和格式问题、重新调试以及基于各种各样的目的而对数据进行不同的切割等等。

它的根源问题在于:在原始的系统中,数据(最好是)有一个实体的逻辑表示——产品、顾客或者其它任何东西。但是当你真正试图提取数据的时候,在大多数情况下,数据都会失真。

例如,如果你的原始系统是一个关系型数据库,在数据库之上也许会有一个对象关系映射,这就将有意义的对象转化到了合理的关系型数据中。你也应该能够反转这个过程从而能够提取出有意义的对象,不是吗?好吧,在大多数情况下,将数据还原所选择的方法是开启一个软件后门,然后仅仅是将所有的关系型数据导入到CSV文件中。如果你曾经试图通过一个CSV文件导入数据,你将会知道那是一个易于出错、难于理解的过程。如果你想对数据做些修改,那基本上就要重新来过这个导入过程。

XML被认为是一个更好的选择。在理论上说来,XML文件可以维护你的数据结构,因此你的对象:

可以被转化为一些XML中看似可管理的东西。

但是,XML也有大量缺点。它本身不能很自然地处理数组,并且对数组和属性的处理有很多变化。解析XML的底层方法性能较高并且非常灵活,但是要转化成良好结构的对象是很麻烦的一件事情。而将XML解析成对象的高级/简单方法经常依赖于编译时间/配置文件,削弱了灵活性以及动态的数据处理。因此,人们最终还是使用扁平化、属性众多的XML——这些XML文件看上去和他们极力想回避的CSV极其相似。

但是,在内容的格式化之上,我们也将会面临需要响应随着时间迁移而产生变化的问题,特别是伴随着数据源的数目增长到10、20甚至更多的情况。在传统的系统中,伴随着每次数据输入源系统的改变,目标的模式也必须改变。其花费的努力伴随着数据源的增加也会线性增长, 因为随着多个变化请求开始重叠时必须通过测试及发布进行管理,“摩擦”也开始出现。在只用2个或者3个数据源的情况下,目标队伍也许还能够应付,但是在20个数据源甚至更多的情况下,很有可能出现目标系统管理一直处于发布合并及分流的持久状态。

那么,如何解决这个问题呢?这里有一些简单的指导方针,可以减轻你在为360°视图提取和导入数据时的负担:

  1. 基于实体,而不是物理数据库进行导出数据设计。是的,当你将产品对象(上述案例中提到的)导入到一个关系型数据库的时候,你不得不扁平化它们从而使它们能够存入表中。然而,这并不意味着你应该使用表。而应该在结构中使用对它们有意义的实体。
  2. 获取全真的数据。丢弃部分你认为不需要的数据是非常有吸引力的,简化类型的合适表示,将对象使用字符串表示(特别是日期)看起来更加吸引人。放弃这些想法,让数据顾客来决定如何处理这些数据。
  3. 在360°视图上运行交叉引用以及额外逻辑,而不要在迁移过程中运行。其最大的原因在于你可以追踪到对数据进行了什么操作。如果你需要在各个阶段重新调试,你可以验证直接从数据源提取数据,然后查看审核日志以展示你如何处理。如果你在蓝线中间的某个部分使用一个perl脚本改变数据,那么回顾及查看已经进行的操作会变得非常困难。特别是要对来自于几十个输入源一整天的数据进行上下文处理的时候这一点就更显得重要。

那么你如何迁移数据?一般说来,最好的选择是编写一个从数据源抓取数据的工具——可以是实时的也可以是批量的,将数据迁移到MongoDB中。没错,创建这样一个工具将会需要一个初始的时间投资。但是,长远看来,这将是一个比其它选择更好的一个做法。一旦数据导入程序开发完成,提取新数据的花费将最小化。此外,将提取出来的数据装载到MongoDB中将会变得非常容易,而不用考虑形状的复杂性。

那么格式化怎么样呢?好的,如果可以的话,尽量避免一次性装载所有文件。MongoDB拥有多种语言的API。如果你依赖这些API,你可以直接将你的对象导入MongoDB中就行了。

 

API的魔力

如果出于某种原因,你不能使用MongoDB的驱动API,那么你可以选择使用JSON。不是常规的JSON-而是使用有MongoDB元数据标识的数据类型(特别是日期)的JSON。记住,JSON本身并没有日期的类型,而你不希望牺牲数据的准确类型。使用MongoDB中和JSON100%兼容的语法来描述那些除字符串、数字或数组之外的一些数据类型。

 

对象→JSON

最后,将所有这些归结到一些建议:

不要使用已经现有数据库中已经变形过的数据。务必以一种对业务实体而言有意义的形式使用数据。不要将数据转储到CSV或XML中然后希望获得最好的结果。务必使用API或者保留对象结构的JSON。不要丢弃数据的任何一个部分,或者尝试在中途修改数据。务必等数据到达你的目标360°视图数据库之后再进行操作。

你现在已经知道了使用MongoDB构建360°视图的基础知识。我们已经介绍了什么是360°视图,了解了360°视图数据模型,并且回顾了数据的导入策略。

如果你想了解更多关于一个真实公司在MongoDB上构建360°视图获取的商业利益,你可以下载白皮书以了解MetLife的360°顾客视图。

1 1 收藏 评论

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部