5

我的公司正在考虑使用 Web 服务作为 ETL 过程的手段。但是，我认为 Web 服务不适合这个目的，原因如下： 1. Web 服务在生成大型 xml 时可能会消耗大量内存。2. xml 是一种臃肿的格式。3. 如果服务器需要大量时间来生成数据，可能会超时 4. 文件大小限制？（对于 Windows，它是 2Gb，如果我没记错的话）

我不是网络服务专家，所以我需要你的意见。:)

谢谢。

4

6 回答 6

6

Web 服务工具棚中有很多技术可以规避您阐述的所有问题。有面向流的 XML 粉碎，有用于交付的 XML 压缩格式，有处理碎片和公平性的协议，还有许多存储系统可以保存数 TB 的数据。

如果通过 Web 服务，您想象一些大学新生的家庭作业混合了一个接口，该接口接受一个带有 2GB 序列化表的 glop 参数，那么您的所有参数都是有效的。但是，如果您将您的需求提供给了解WS-ReliableMessaging和WS-Transaction所涉及概念的经验丰富的团队， 那么没有理由不围绕 Web 服务制定 ETL 流程。请注意，我并不提倡 SOAP 协议本身，但我提倡了解和理解所涉及的概念。

话虽如此，面向 Web 服务的 ETL 过程是否对您有意义，这取决于一整套其他原因。但是，您对 Web 服务技术的反驳是站不住脚的。

于 2009-12-24T01:43:10.530 回答
1

这确实取决于您在做什么以及您如何尝试完成它。一般来说，Web 服务比您通常投入到 ETL 过程中需要更多的关注和馈送，但它们在任务中也可以非常有效。我没有得到足够的细节来说明你的方案是否可行。

我从事 Web 服务的工作，它传输和接收 100 多 MB 的文档，其中一些以 XML 编码，一些没有，并且在几秒钟内完成（在封闭的本地网络上）。这些服务需要大量的调整和规划，但它们确实适用于我们的场景，并且它们允许各种客户端通过相当标准的接口连接和传输不同数量的数据。这与我们拥有的其他一些 ETL 作业不同，该作业特定于每个客户，并且必须为每个客户设置和维护。

这一切都取决于你在做什么以及你的限制是什么。

如果您打算走这条路线，请坐下来从头到尾草拟整个流程，包括您希望客户端如何连接，验证是否收到了数据并验证工作是否完成。考虑一些场景、客户端和传输的数据类型，然后确定需要什么。将其与其他工具中已有的功能进行对比，以及完成它需要多少时间。

于 2009-12-24T01:39:47.873 回答
1

我不会将 Web 服务用于 ETL 任务。有更适合该任务的专用工具（例如，Ab Initio、Informatica 等）。

如果您有大量数据，我会说网络引入的额外延迟的代价将是令人望而却步的。

于 2009-12-24T01:18:16.263 回答
1

我真的很想知道为什么您的公司不考虑使用真正的 ETL 工具，例如duffymo 在他的回答中提到的那些工具，或者如果可以选择开源，则使用Talend或CloverETL 。

  1. 它们通常适用于 ETL 目的:)
  2. 构建自己的解决方案听起来像是重新发明轮子。
  3. 其中许多具有面向 Web 服务的功能（例如，请参阅在 Talend 的 wiki中将作业导出为 Web服务或CloverETL Server HTTP 启动服务）。

我不是 ETL 产品专家，也没有检查所有这些，但我很确定这是需要考虑的事情。

于 2009-12-26T01:00:13.487 回答
0

首先查找 MTOM，它允许在 Web 服务中流式传输任意非 XML 数据。

于 2009-12-26T00:10:40.810 回答
0

Web 服务非常适合 ETL 任务。请记住，每个任务都将在其自己的线程中免费处理，并且可以保证在请求之间进行适当的清理。在 Tomcat 之类的内部使用 Web 服务不会像您想象的那么繁重。

如果您担心 XML 的膨胀，请考虑 JSON 格式。

于 2009-12-26T00:21:49.977 回答