PostgreSQL 到数据仓库：近实时 ETL/数据提取的最佳方法

Question

背景：

我有一个针对 OLTP 进行了大量优化的 PostgreSQL (v8.3) 数据库。

我需要在半实时的基础上从中提取数据（有人肯定会问半实时意味着什么，答案是尽可能频繁地回答，但我会务实，作为基准，可以说我们希望每 15 分钟一次）并将其输入数据仓库。

有多少数据？在高峰时段，我们所说的 OLTP 端每分钟大约有 80-100k 行，非高峰时段这将大幅下降至 15-20k。最频繁更新的行每行约为 64 字节，但有各种表等，因此数据非常多样化，每行最多可达 4000 字节。OLTP 24x5.5 处于活动状态。

最佳解决方案？

据我所知，最实用的解决方案如下：

• 创建触发器以将所有 DML 活动写入轮换 CSV 日志文件
• 执行所需的任何转换
• 使用原生DW数据泵工具将转换后的CSV高效泵入DW

为什么采用这种方法？

• 触发器允许将选择性表作为目标，而不是在系统范围内+输出是可配置的（即转换成 CSV）并且相对容易编写和部署。SLONY 使用类似的方法，开销是可以接受的
• 轻松快速地转换 CSV
• 轻松将 CSV 泵入 DW

考虑的替代方案....

• 使用本机日志记录（http://www.postgresql.org/docs/8.3/static/runtime-config-logging.html）。问题在于，相对于我所需要的内容，它看起来非常冗长，并且解析和转换有点棘手。然而，它可能会更快，因为我认为与触发器相比，开销更少。当然，这会让管理变得更容易，因为它是系统范围的，但同样，我不需要一些表（有些表用于持久存储我不想记录的 JMS 消息）
• 通过 Talend 等 ETL 工具直接查询数据并将其输入 DW ...问题是 OLTP 模式需要调整才能支持这一点，这会产生许多负面影响
• 使用经过调整/破解的 SLONY - SLONY 在记录和迁移对从属设备的更改方面做得很好，因此概念框架已经存在，但建议的解决方案似乎更简单、更干净
• 使用 WAL

以前有人这样做过吗？想分享您的想法吗？

Answer 1

假设您感兴趣的表具有（或可以增强）唯一的、索引的、顺序的键，那么您将通过简单地发出获得更好的价值 SELECT ... FROM table ... WHERE key > :last_max_key 输出到文件，其中 last_max_key 是上次提取的最后一个键值（如果是第一次提取，则为 0。） 增量、解耦的方法避免了 介绍 插入数据路径中的触发延迟 （无论是自定义触发器还是修改后的 Slony），并且根据您的设置可以更好地扩展 CPU 数量等。（但是，如果您还必须 追踪 UPDATEs, ，并且顺序键是您添加的，然后您的 UPDATE 陈述应该 SET 关键列 NULL 因此它会获得一个新值并被下一次提取所选择。你会 无法追踪 DELETEs 没有触发器。）这就是您提到 Talend 时想到的吗？

我会 除非您无法实施上述解决方案，否则不要使用日志记录功能;日志记录最有可能涉及 锁定开销 确保日志行按顺序写入，并且当多个后端写入日志时不会相互重叠/覆盖（检查 Postgres 源）。锁定开销可能不是灾难性的，但如果可以使用增量式，则可以不用它 SELECT 选择。而且， 语句记录会被淹没 任何有用的警告或错误消息，以及 解析本身不会是瞬时的.

除非你愿意解析 WAL（包括事务状态跟踪，并准备好在每次升级 Postgres 时重写代码），否则我也不一定会使用 WAL —— 也就是说，除非你 有额外的可用硬件, ，在这种情况下你可以 将 WAL 发送到另一台机器进行提取 （在第二台机器上你可以 无耻地使用触发器 -- 甚至语句记录 -- 因为那里发生的任何事情都不会影响 INSERT/UPDATE/DELETE ）请注意，就性能而言（在主计算机上），除非您可以将日志写入 SAN，否则您将通过传送 WAL 获得相当的性能损失（主要是在文件系统缓存的抖动方面）到与运行增量不同的机器 SELECT.

Answer 2

如果您能想到一个仅包含 id 和“校验和”的“校验和表”，您不仅可以快速选择新记录，还可以快速选择已更改和已删除的记录。

校验和可以是您喜欢的 crc32 校验和函数。

Answer 3

PostgreSQL 中新的 ON CONFLICT 子句改变了我进行许多更新的方式。我将新数据（基于 row_update_timestamp）拉入临时表，然后在一个 SQL 语句中使用 ON CONFLICT UPDATE INSERT 到目标表中。如果您的目标表已分区，那么您需要跳过几个步骤（即直接点击分区表）。当您加载临时表（最有可能）或在 ON CONFLICT SQL（如果微不足道）中时，可能会发生 ETL。与其他“UPSERT”系统（更新、零行插入等）相比，这显示出巨大的速度改进。在我们特定的 DW 环境中，我们不需要/不想容纳 DELETE。查看 ON CONFLICT 文档 - 它与 Oracle 的 MERGE 相媲美！