2009年11月13日
第7卷，第10期

  PDF

其他人的数据

Stephen Petschulat，SAP

公司可以访问比以往任何时候都更多的外部数据类型。他们如何最有效地整合这些数据？

每个组织都将其一些关键决策建立在外部数据源的基础上。除了传统的平面文件数据馈送外，Web服务和网页在数据仓库中也扮演着越来越重要的角色。Web服务的增长使得数据馈送在部门甚至最终用户级别都易于使用。现在有超过1,500个公开可用的Web服务和数千个数据混搭，范围从零售销售数据到天气信息再到美国人口普查数据。³ 这些混搭证明，当用户需要信息时，他们会找到获取信息的方法。有效的企业信息管理策略需要同时考虑内部和外部数据。

外部数据的类型

外部数据源的结构和访问方法各不相同。有些数据源是广为人知的，并且多年来一直是数据仓库流程的一部分：证券数据、公司信息、信用风险数据和地址/邮政编码查找。这些数据通常是正式结构化的，包含“基础”（最详细）级别的数据，并且可以通过成熟的数据服务提供商以多种格式获得。最常见的访问方法仍然是通过FTP传输平面文件。

从软件开发的角度来看，Web服务是广为人知的，但它们与企业数据管理的相关性才刚刚显现。传统的数​​据服务提供商，如邓白氏和汤森路透，已经开始通过Web服务提供他们的大部分产品。数百家规模较小的Web服务公司正在以下领域提供数据：零售销售、Web趋势、证券、货币、天气、政府、医药、时事、房地产和竞争情报。

借助Web服务，可以以功能服务的形式增加价值。数据提供商可以很容易地在数据之上添加服务，而不是允许检索平面文件数据（实际上是一个 fetch() 函数）：转换、计算、搜索和过滤。事实上，对于大多数小型初创公司来说，重点一直放在功能服务上，这些服务通常呈现的是整体数据的高度处理子集。当提供的功能正是您所需要的时，这可以节省时间和精力。数据是预先清理的，聚合到正确的级别，并且您不必实现自己的搜索。

然而，当功能接口与您的确切需求不符时，这也可能导致挑战。EBay提供关于各个类别中每日最畅销产品、顶级供应商和产品竞标价格的市场研究数据。如果这些特定查询是您想要的，那么这效果很好，但是如果您需要eBay没有想到的查询，您将无法访问基础数据来创建自定义查询。

另一个重要的数据来源是Web本身。大量的非结构化数据存在于网页和搜索引擎背后。竞争情报领域一直在推动非结构化和半结构化Web资源与数据仓库的融合。竞争情报也是一个推动从纯粹的后端数据馈送到贯穿整个堆栈的数据馈送转变的领域。¹ 来自亚马逊和eBay的结构化Web服务是特定市场和销售信息的来源之一，而来自Kapow和Dapper等公司的技术允许用户通过将页面上的一些可视字段映射到动态馈送中的数据字段，将任何外部网页内容转换为半结构化数据馈送。

尽管这些工具开始使Web抓取变得更容易，但大多数最终用户仍然求助于从竞争对手的网站复制和粘贴到电子表格中，以便获得他们完成工作所需的见解。这是一种人工密集且容易出错的方法，但替代方案——获取市场信息、与IT部门沟通、将数据集集成到核心数据仓库模型、暂存、测试、部署——耗时太长，尤其是在数据源可能每周或每月都在变化的情况下。

架构考虑

外部数据应与内部数据区别对待和规划。正如分布式计算架构必须考虑延迟和数据故障一样，稳健的数据仓库计划必须考虑到外部数据源从定义上来说不受接收组织的控制。它们更容易出现不可预测的延迟、数据异常、模式更改和语义数据更改。这并不是说它们的质量较低——许多内部数据源也存在同样的问题，而且数据服务公司是为了提供高质量的数据而获得报酬的——相反，通信通道和处理系统是公司间而不是公司内的，这会产生额外的的问题和延迟来源。

（合法地）从公共可用站点抓取的竞争情报数据不仅必须应对数据清理问题，而且模式也可能随时更改，并且发布者没有义务通知消费者该更改。如果预定的报告依赖于此信息，那么它通常会中断，从而导致报告为空或无法理解。更糟糕的是，它可能导致不正确的数字，从而导致错误的业务决策。数据可靠性和准确性需要被认为是整个组织数据流中的基本属性。

灵活性、质量和成本

并非所有数据都需要经过整个数据仓库工作流程。在信息密集型组织中，IT部门很少能及时满足每个用户的数据需求。必须做出权衡。这些权衡可以沿着灵活性、质量和成本维度来考虑。在大多数情况下，您可以选择两个，而必须权衡第三个。

灵活性是指您可以多么容易地将数据用于最终用户的需求。从原始平面文件获取基础数据可以最大限度地提高您进一步处理数据的能力；然而，所涉及的工作量远高于从Web服务供应商那里获得高度汇总的馈送。例如，国际证券交易所单个股票代码的历史期权每日行情数据有80多个字段。²

以CSV（逗号分隔值）格式拥有所有基础数据提供了最大的灵活性；您可以从中导出您想要的任何信息。但是，如果您只想要高级摘要信息，那么最好放弃这种灵活性，以换取来自StrikeIron或Xignite等Web服务提供商的更简单的API。

在证券信息的情况下，很少有IT部门能够直接管理来自交易所的原始股票馈送。国际证券交易所历史期权行情数据的每月未压缩数据超过1太字节，因此即使处理每日增量也可能在完整的金融流上达到数千兆字节。²

如果没有符号查找表和其他公司数据来交叉引用，仅凭行情信息用处不大。这些可能来自不同的来源，并且可能或可能不会为您处理数据更改——有人必须识别从SUNW到JAVA到ORCL的更改，并确保对其进行有意义的处理。不同的馈送也以不同的速率进入。数据可能因技术、业务和监管原因而发生变化，因此使其与可用的数据模型保持同步是一项全职工作。

质量是数据来源和数据在组织中流动的过程的函数。如果一个复杂的公式出现在数百个不同的人编写的不同报告中，那么引入错误的可能性几乎是肯定的。将所有发票加起来将产生收入数字，但它可能没有考虑到退货、退款、批量折扣和税收减免。收入和利润等计算通常依赖于基础数据的特定假设，并且任何基于它们的公式都需要知道这些假设是什么

• 所有公式都使用完全相同的算法吗？
• 它们如何处理舍入误差？
• 是否应用了货币换算？
• 数据是否经过季节性调整？
• 空值被视为零还是缺少数据？

公式的管理位置越多，引入错误的可能性就越大。

成本可以与质量和灵活性进行权衡。如果有足够的人手动检查每份报告，那么事情重复多少次都无关紧要——可以通过人工质量保证来维护质量。但这并不是运行数据仓库的最有效方法。成本和灵活性通常基于将原始数据转换为有用数据所需的工作量进行权衡。每个处理级别都需要付出努力并失去灵活性，除非您愿意投入更多精力来维护基础数据和处理后的数据。

当然，您可以始终保留所有基础数据，但维护这些数据的成本可能令人望而却步。在核心数据仓库中以尽可能低的详细级别拥有所有内容，代表了最大程度地提高灵活性和质量，同时权衡成本的极端情况。

外部Web服务通常以牺牲灵活性为代价来换取质量和成本。具有内置假设、计算和隐式过滤器的高度汇总、有针对性的数据服务不如灵活，但它们通常是解决特定问题所需的全部。都市区每日平均天气实际上是在机场采样的，并且平均方法不明确，这并不重要。当您只关心当天的温度在+/-3度范围内时，这种灵活性的丧失是公平的权衡。

以下是在确定哪些权衡对于给定数据源有意义时要问的问题

• 不正确的数据对业务有什么影响？
• 维护数据馈送的成本是多少？
• 数据集有多大？
• 数据多久更改一次？
• 数据模式多久更改一次？
• 数据有多复杂？
• 消费场景有多复杂和多样？
• 数据质量如何（预计有多少错误、频率、影响程度）？
• 数据对决策制定有多关键？
• 审计和可追溯性要求是什么？
• 是否存在任何监管问题？
• 是否存在任何隐私或保密问题？

企业数据混搭

传统的数据仓库生命周期、拓扑和建模方法不太适合外部数据集成。数据仓库通常被认为是真理的单一来源的中央存储库。实际上，它很少能跟上组织信息需求的多样性。这导致用户求助于自行获取外部数据，导出到Excel，并在电子表格中进行自己的数据连接。

数据的自给自足和用户驱动的数据集成可以减轻IT部门的一些负担，但也可能导致问题。基于从互联网下载的数据混搭做出关键任务决策并不总是最佳的。很少有用户了解数据清理、关系连接和管理缓慢变化维度的复杂性。正确的数据建模并没有变得更容易。

从最终用户驱动的屏幕混搭到具有详细主数据管理计划的集中式数据管理团队，各种方法在现代数据仓库策略中都有一席之地。分散的数据策略具有明显的质量和一致性权衡，但并非所有数据都是相同的——有时更快、更灵活地访问数据比使其完美更重要。决策应基于对质量、灵活性和成本权衡的认识。这些通常与集成发生的位置有关。

在架构的不同层进行集成

外部数据可以合并到企业信息流的任何阶段：在ETL（提取-转换-加载）期间、在核心数据仓库中、在部门级数据集市中，以及在最终用户通过报告、BI（商业智能）工具和应用程序进行消费期间。数据集成的两个最常见阶段是在初始摄取或最终消费时，但所有阶段都值得考虑。

ETL

在数据进入时丰富数据是一种常用技术。所有主要供应商都提供ETL工具，以在数据集进入仓库的过程中对其进行清理、转换和扩充。数据问题（错误、遗漏和不兼容性）在此层以显式方式处理，从而在数据甚至进入仓库之前就实现了高质量的数据。许多此类工具现在都包含一定程度的Web服务集成；然而，ETL工具通常面向大批量批处理，而大多数Web服务接口倾向于假设每个请求的单个或小型数据集。因此，当数据更接近用户时，Web服务往往会发挥更突出的作用。

某些类型的数据非常适合纯粹的丰富角色，不需要扩充现有数据模型。这些数据通常是ETL阶段集成的良好候选者。这是地址和地理位置相关数据的常见角色。在ETL过程中，地址会与外部数据源进行比较。邮政编码被纠正，街道名称被规范化，并且添加了纬度和经度字段。外部数据源不会在仓库中生成新表，并且不会与内部数据连接。数据只是在进入时被修复，可能在此处或彼处添加一个字段。

核心数据仓库

在核心模型中集成（如传统的通过FTP传输平面文件模型中常用的方法）可确保最大程度地遵守企业数据标准和数据管理流程。数据清理问题、服务中断和语义不匹配都在仓库的核心模型中处理。“货币转换表”在整个系统中保持一致，从而促进了备受追捧的“真理的唯一版本”。对于财务信息，这通常至关重要。

然而，在许多情况下，这也是维护成本最高的方法。对于快速变化的业务状况，最终用户必须与IT部门进行对话，并忍受他们可能不理解或不在乎的数据策略和程序（即使他们应该在意）。更改数据库模式比更改报告更难。如果信息对用户足够重要，并且系统摩擦太大，那么他们将找到解决方法。

数据集市

在数据集市层集成外部数据减少了核心数据仓库模型集成的典型摩擦。尽管数据仓库拓扑结构差异很大，但出于此目的，我们将数据集市视为至少部分在部门控制范围内的实体。每个数据集市——无论是与仓库分离的数据库实例、OLAP（在线分析处理）多维数据集，还是完全不同的数据库技术——都可以获取和集成自己的馈送，从而创建与该部门或用户群相关的视角。营销部门可能需要外部地址数据库进行清理，然后再进行群发邮件，而客户支持组织可能对地理标记更感兴趣，以便分析案例分布模式。

随着集成越来越接近最终用户，需要注意的关键问题是数据控制的丧失。如果每个数据集市以略微不同的方式集成相同的数据，那么引入不一致性的可能性就更大。北美销售团队可能会调整退款以考虑其仓储式商店的高周转率，而亚太地区团队则不会。试图汇总来自这两个独立数据集市的结果的报告可能会天真地对数字求和，从而导致不正确的结果。数据集市级别的不同规则可能有充分的理由，但是当值在下游组合或比较时，这些差异可能会导致问题。

BI工具

大多数BI工具供应商现在都集成了数据混搭功能，因此最终用户可以将外部数据和内部数据连接起来。与在数据集市层进行集成相比，这种方法往往更由最终用户驱动，并且通常不需要对数据库或正式数据建模专业知识进行管理访问。供应商的工具在方法上各不相同，但通常可以选择进行轻量级业务用户建模，以及通过公式语言在屏幕上组合数据集。这在保持审计和跟踪使用情况的能力的同时提供了极大的灵活性。

在此层面临的问题与数据集市的问题类似。数据管理和集成的各个方面仍然是分散的，这可能导致同一业务概念的冗余定义，从而增加错误解释的风险。用于审计和跟踪的工具，以及通用的业务用户级语义层，有助于克服一些问题。

桌面

光谱的这一端代表了最常见的混搭场景。Excel、平面文件、宏和Web应用程序集成很容易组合在一起，有时甚至很准确。虽然数据库管理员和仓库架构师可能会畏缩，但底线是，当人们需要信息时，他们会找到获取信息的方法。从信息架构的角度来看，规划这种可能性使您可以决定哪些数据属于何处，以及潜在的影响将是什么，从而做出明智的决定。对于某些数据源，在这些数据源中，准确性和可追溯性并不重要，这是一个完全可以接受的选择。但是，随着这些数据源的使用越来越频繁，将它们进一步推入堆栈以确保数据集成工作仅由一个人而不是多人完成可能更有意义。

结论

将外部数据集成到企业信息流中没有“正确”的层，而是要考虑一组权衡。数据的特征、其消费场景以及业务背景都需要考虑。这些因素也需要定期重新评估。随着数据源变得更加广泛使用，经济学可能会决定集中化和规范化数据采集。为外部数据源选择正确的集成方法可以平衡灵活性、质量和成本的变量，同时为最终用户提供对其业务问题的及时解答。

参考文献

1. Boncella, R. J. 2003. 竞争情报和Web。《信息系统协会通讯》12: 327-340; http://www.washburn.edu/faculty/boncella/COMPETITIVE-INTELLIGENCE.pdf.

2. 国际证券交易所; http://www.ise.com/.

3. Programmableweb.com; http://www.programmableweb.com/.

喜欢它，讨厌它？请告诉我们

[email protected]

Stephen Petschulat 是SAP Business Objects高级分析领域的高级产品架构师。

© 2009 1542-7730/09/1100 $10.00

最初发表于Queue vol. 7, no. 10—
在 数字图书馆 中评论这篇文章

---

更多相关文章

Ethan Miller, Achilles Benetopoulos, George Neville-Neil, Pankaj Mehra, Daniel Bittman - 远内存中的指针
有效利用新兴的远内存技术需要考虑在父进程上下文之外操作丰富连接的数据。正在开发中的操作系统技术通过公开诸如内存对象和全局不变指针之类的抽象来提供帮助，设备和新实例化的计算可以遍历这些抽象。这些想法将允许在具有分离内存节点的未来异构分布式系统上运行的应用程序利用近内存处理来实现更高的性能，并独立扩展其内存和计算资源以降低成本。

Simson Garfinkel, Jon Stewart - 磨砺你的工具
本文介绍了我们在最初发布十年后更新高性能数字取证工具BE（bulk_extractor）的经验。在2018年至2022年期间，我们将程序从C++98更新为C++17。我们还进行了完整的代码重构并采用了单元测试框架。DF工具必须经常更新，以跟上其使用方式的变化。对bulk_extractor工具更新的描述可以作为可以而且应该做什么的一个例子。

Pat Helland - 自主计算
自主计算是一种使用协作来连接领地及其使者的商业工作模式。这种基于纸质表格的模式已经使用了数百年。在这里，我们解释领地、协作和使者。我们研究使者如何在自主边界之外工作，并且在保持局外人身份的同时很方便。我们还研究了如何启动、长时间运行并最终完成跨不同领地的工作。

Archie L. Cobbs - 持久性编程
几年前，我的团队正在进行一个商业Java开发项目，用于增强型911（E911）紧急呼叫中心。我们试图使用传统的Java over SQL数据库模型来满足该项目的数据存储需求，但感到沮丧。在对项目的特定需求（和非需求）进行一些反思之后，我们深吸一口气，决定从头开始创建我们自己的自定义持久层。

---

---

© 保留所有权利。