组织的报告制度。需要架构建议

Question

我们在组织中有几个遗留的第三方系统，它们使用几个RDBMS供应商(&更具体的数据存储)。跨系统数据报告(以及3D-party系统中未实现的额外报告)需要图表和填充模板(winword、excel)。报告系统被设想为具有自定义用户访问报告的intranet网站。我们预计每天大约有50份报告。

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

您是建议为定期填充的报告创建集中式数据存储，还是依赖始终提供最新请求数据的按需服务。集中式数据存储将带来使用标准工具(如MSSQL Reporting Services )的能力，但模板化报表将使用轻量级解决方案进行自定义编码(正如我怀疑的那样)

提前谢谢你！

Answer 1

要选择理想的体系结构，您需要检查系统的一些动态特性。以下是几个相关问题：

• 源数据多长时间更改或更新一次？
• 报表中的数据必须有多“新鲜”和实时？
• 您怀疑未来源系统可能更改的频率是多少？
• 源数据结构彼此之间有多大差异？
• 未来除了报表系统之外，还会有其他消费者吗？
• 数据中是否存在语义异构性？
• 模式有多复杂？

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

中央数据仓库

用于报告系统和其他consumers.

• Hub-and-spoke拓扑的
• Easy统一架构意味着每个源只需要一个连接器。如果源发生更改，则只有一个位置需要修复connection.
• Data可能不是最新的，因为它依赖于与终端系统的定期同步。
• 如果您的数据仓库方案不能满足将来的某些需要，则中心辐射型拓扑意味着您必须替换所有源系统semantics.
• You方案是严格定义的，但需要一个广泛的验证器系统来强制执行
• 有机会在一个点执行数据清理，从而更正您已知的某些类脏数据。

点对点自定义连接器

像possible.

• All连接器一样接近实时数据的connector.

• The
• 是彼此隔离的，如果源发生了变化，那么您只需要更改一种模式和语义的一致性。但可能没有严格强制到通用数据库目标将imply.
• Changes到您的报告系统的程度，或者添加一个新目标可能需要您重新编写所有connectors.
• The报告系统必须承担的任何数据清理责任。如果这些连接器是面向消息的，necessary.
• An ESB (例如Biztalk)可能是管理这些连接器的一种很好的方法。这将增加一些开销和费用，但您将获得可靠性和一个中央代理来帮助您解决问题。根据聚合系统的大小和预期增长，企业服务总线可能代表复杂性的净降低，也可能不代表复杂性的净降低。

在这两种情况下，我认为连接器的构造都可以使用商业产品、开源产品或普通代码来完成。当你开始为产品付款时，可能会有一些额外的花哨(这可能会提高生产力)，但主要的费用将是你的工程师的时间(编码和分析)。我建议：

• 如果你已经熟练地使用了一个用于连接器的工具(例如ETL)，那就考虑一下吧。特别是，它将削减大量你没有使用这些系统的经验的boilerplate.
• If，三思而后行--你将代码隐藏在工具中，这可能不仅仅是对一次性项目的帮助。但是，在需求总有一天会发生变化的漫长run.
• Consider中，去掉样板并利用强加于您的结构可能是一件好事。确保你选择了一种易于修改和维护的技术。

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