组织报告系统。建筑建议需要

Question

我们有几个遗产＆amp;组织中使用多个RDBMS供应商（以及更具体的数据存储）的三方系统。图表和模板群（winword，excel）需要跨系统数据报告（以及未在3人制系统中实施的额外报告）。报告系统被视为内部网站点，可以自定义用户访问报告。我们预计每天约有50份报告。

如果商业部门不打算购买昂贵的东西，您会建议使用BizTalk或任何其他集成软件。

您是否建议为定期填充的报告创建集中式数据存储，或者依靠提供始终最多请求数据的按需服务。 集中式数据存储将使用标准工具（如MSSQL Reporting Services），但模板化报告将使用轻量级解决方案进行自定义编码（我怀疑）

提前谢谢！

Answer 1

要选择理想的架构，您需要检查系统的某些动态。一些相关的问题：

• 源数据多久更改或更新一次？
• 数据必须在报告中“新鲜”和实时？
• 您怀疑源系统将来可能会发生变化吗？
• 源数据结构彼此有何不同？
• 将来除报告系统外还有其他消费者吗？
• 除了示意图差异外，数据中是否存在语义异构性？
• 模式有多复杂？

考虑到这一点，让我们来看看两种数据聚合方法的优缺点：

中央数据仓库

• 报告系统和其他消费者的简单统一架构。
• Hub-and-spoke拓扑意味着每个源只需要一个连接器。如果源更改，则只需要一个位置即可修复连接。
• 数据可能不是新鲜的，因为它依赖于与终端系统的定期同步。
• 如果您的数据仓库架构未涵盖将来的某些需求，则hub-and-spoke拓扑意味着您必须替换所有源系统连接器。
• 架构是严格定义的，但需要一个广泛的验证器系统来强制执行语义。
• 您有机会在一个位置执行数据清理，纠正您已知的某些类脏数据。

点对点自定义连接器

• 尽可能接近实时数据。
• 所有连接器彼此隔离，如果源​​更改，则只需更改一个连接器。
• 模式和语义的一致性可能隐含在您的连接器中，但可能不会严格执行到公共数据库目标所暗示的程度。
• 对报告系统的更改或添加新目标可能需要您重新修改所有连接器。
• 报告系统必须承担必要的任何数据清理责任。
• 如果这些连接器是面向消息的，那么ESB（例如Biztalk）可能是管理这些连接器的好方法。它会增加一些开销和费用，但你会获得可靠性和中央经纪人来帮助你。根据此聚合系统的规模和预期增长情况，ESB可能会或可能不会显示复杂性的净减少。

在这两种情况下，我认为连接器的构造可以通过商业产品，开源产品或普通旧代码来实现。当您开始为产品付费时，可能会有一些额外的花里胡哨（这可能会提高生产率），但主要费用将是您工程师的时间（编码和分析）。我建议：

• 如果您已经熟悉连接器的给定工具（例如ETL），请继续考虑。特别是，它会削减很多样板。
• 如果您没有使用这些系统的经验，请三思而后行 - 您正在使用可能比一次性项目的帮助更容易混淆的工具中的代码。但是从长远来看，切割样板并利用强制在你身上的结构可能是一件好事。
• 考虑到有一天需求会发生变化。确保您选择了一种易于调整和维护的技术。

当然没有一个答案，但希望这可以帮助您检查正确的问题。我认为关键是管理复杂性，并意识到整个聚合网络将在某一天发生变化。这只是时间问题。