实时数据仓库：事件驱动与轮询

Question

我知道PostgreSQL to Data-Warehouse: Best approach for near-real-time ETL / extraction of data之前已经问过这个问题。 但我想重新解释这个问题。

我正在尝试实时数据仓库。实时和近实时之间的差异是巨大的。 我发现实时数据仓库是事件驱动的和事务性的方法。 虽然接近实时将执行相同的批处理模式应用程序，但会更频繁地轮询数据。 它会给生产服务器带来如此多的额外负担，并且肯定会扼杀生产系统。 作为批处理方法，它将扫描所有表以进行更改，并将采用已更改的行 截止时间戳。 我的意思是通过事件驱动，它将特定于经历了更改的表仅关注事务 目前正在发生。

但源系统是系统的象，SAP，假设有25,000个表。对它进行建模并不容易 不容易在每个表上写入数据库触发器来捕获每个更改。我希望生产服务器上的影响最小化。

数据库级别是否有任何触发器，以便我可以在一个触发器中捕获数据库中发生的所有更改。 有没有办法在不同的数据库服务器上编写该数据库触发器，以便生产服务器不受影响。 我没有跟上数据库技术发生的变化，并且肯定会有一些不错的新技术可以轻松捕获这些变化。

我知道Log矿工和更改数据捕获，但是很难从重做日志中过滤出我需要的信息。 在旅途中捕获数据库写操作的替代方法。

为了完整起见，我们假设数据库是Oracle，SQL Server和DB2的异构组合。但我的论点是 我们想要发展的概念。

这是一个普遍的问题，每家公司都在寻找易于实施的解决方案。所以一个好的讨论会使所有人受益。

Answer 1

Don't ever try to access SAP directly. Use the APIs of SAP Data Services (http://help.sap.com/bods). Look for the words "Integrator Guide" on that page for documentation. This document should give you a good hint about where to look for your data sources (http://wiki.scn.sap.com/wiki/display/EIM/What+Extractors+to+use). Extractors are kind-of-somewhat like views in a DBMS, they're abstracting all the SAP stuff into somethin human readable. As far as near-real-time, think in terms of micro-batches. Run your extract jobs every 5 (?) minutes, or longer if necessary.

Answer 2

从Nathan Marz检查 Lambda架构（我没有提供任何链接，但您可以轻松找到资源）。实现是Java和No SQl，但主要思想也适用于经典的关系数据库。简而言之：您有两个实现，一个实时但只负责有限的时间间隔。 “长尾”通过经典的最佳实践批量实施来维护。

批量刷新后，实时部分总是被丢弃，有效地阻止了历史数据中实时处理问题的传播。

Answer 3

我刚刚将标题编辑为＆＃34;实时数据仓库：事件驱动与轮询＆＃34;。 正如Ron指出的那样，不要直接触摸SAP TABLE。有适配器和适配器可以访问SAP表。这将在其间构建另一层，但这是不可避免的。我想分享的一个好消息是客户对SAP表进行了研究，发现只有14％的表实际上是由SAP系统填充或触及的。即使这样，25,000个表中的14％也会进入2000多个实体的庞大数据模型。微批次就像将系统划分为采购，应收账款，应付账款等，这是前往数据集市而不是EDW。我想专注于企业数据仓库。

非常感谢

Answer 4

截至目前，我只能看到两种解决方案：

1. 在源系统上编写服务。如果source是COBOL，请将它们放入服务中。将所有服务放在服务总线上 一些变化发生在数据库时的陷阱。需要探索该陷阱如何工作。 但从一开始它似乎是一个非常 昂贵的命题和不确定性。令人信服的管理三年滞后时间将是困难的。服务并不容易。

2. 日志托运人：这是一个值得信赖的数据库解决方案。日志可以在另一台服务器上使用，生产服务器不需要 负担。有很多工具可供使用。 但精神不符合。事情驱动缺失所以事情的行动 发生的事情没有被捕获。我会为此安定下来。

你能否提出任何其他解决方案，我会等待。