设备管理 技术架构及移动设备.pdf

设备管理 技术架构及移动设备 第1章 技术方案 1.1 体系架构 1.1.1 总体架构 采用 B/S 架构，为了更好的扩展性和灵活性，总体分成4 层，图如下： 每一层之间有清晰的接口，每一层内部可以独立的扩展而不影响其它层。根据 BI 商务智能分析的特点，要求支持各种类型的数据库，支持复杂的统计分析函数，支 持丰富的展现形式。 1.1.1.1 数据层 数据层分 2 个库，一个是元数据库，存储用户、报表、数据仓库模型等系统信 息，一个是业务数据库，存储要分析的数据。两个库可以独立存储在不同的数据库 中，也可以存储在同一个数据库中。同一个元数据库可以基于多个不同的业务数据 库进行分析，大大降低了同一个企业机构实施多个项目的成本和周期。另外，允许 元数据库和业务数据库分开存储可以提高并发访问效率。 1.1.1.2 执行引擎 流行的数据库都兼容 sql99 标准，但是都有各自的扩展，为了最高的执行效率， 执行引擎为不同的数据库产生不同的 sql ，并生成一致的查询结果给分析引擎。另外， 很多报表的数据来自多张业务表，需要多次查询，通过对查询的合并可以大大提高 查询性能。高效的执行引擎是性能的保证。 1.1.1.3 分析引擎 为了支持复杂的统计分析——同期、上期、同比、环比、topN/top%等等，灵活 的分析引擎必不可少。分析引擎是报表到查询对象的桥梁，强大的分析引擎可以让 用户简单定义就查询出复杂的数据。 除了支持不同的统计分析方法，还支持从多种展现对象中提取查询信息，包括 表格、统计图、多维分析、地图等。 1.1.1.4 展现引擎 报表的展现方式日新月异，从表格到统计图、地图，从个人电脑到移动设备， 从浏览器方式查看到用 excel 、pdf 、word 格式查看，要能做到一张报表多种方式在 多个设备上展现。 1.1.2 多级缓存 现在企业机关的数据量都比较大，查询一张报表可能要几分钟的时间，当不同的 用户计算同一张报表时，如果每个人都要到数据库中进行查询，势必会很慢。为了 在大数据量环境中仍有很快的查询性能，有必要建立多级缓存。 1.1.2.1 计算结果的缓存 报表在计算之后会生成结果表，将结果表存储起来，下次计算时直接从缓存中读 取计算结果，这样可以最大限度提高查询效率。 结果的缓存要同时考虑查询条件、用户身份、权限等影响查询结果的因素，避免 返回错误的缓存结果。 对于结果的缓存，还要有定时清理机制，避免过多的缓存占用大量的磁盘空间。 1.1.2.2 展现对象的缓存 当多个用户查看同一张报表时只需要生成一个展现对象。在为每张报表生成展 现对象时将展现的结果缓存起来，下次查看报表时可以立即先展现结果，而不需要 经过计算过程。这样可以最大限度提高查看效率。 展现对象通常都是文件，比如 html 文件、excel 文件、paf 文件，通常比较大， 为了不占用过多数据库空间，它们将存储在本地文件系统中。 1.1.2.3 统计图的缓存 作为报表的重要组成部分，统计图可以让数据更直观。在浏览器或其它设备上 查看报表时，统计图快速显示是非常重要的。为了加快统计图的显示速度，有必要 对它生成的内容进行缓存，避免每次都取生成。 统计图缓存和报表的缓存类似，它的尺寸比较大，放在文件系统中更合适。 1.1.3 第三方扩展接口 产品很难做到面面俱到，为了满足不同用户的个性化需求，提供完善的扩展结 果很有必要。当分析或者展现的需求不满足用户需求时，有条件的用户可以自己 展功能，实现自己的需求。 1.1.3.1 扩展分析引擎 分析引擎产生的结果是一个通用的标准格式——xml 格式，用户可以采用通用的 技术修改产生的结果。通过扩展分析引擎可以优化查询对象、统计方法。 并且，用户在扩展分析引擎时不必关心分析结果如何执行，这个由执行引擎来 负责执行。 1.1.3.2 允许扩展展现层 用户对结果的显示往往是个性化的，根据不同的项目有不同的展现需求。当产 品自带的展现不符合用户需求时，可以扩展展现层。 展现层包括界面布局、图表、交互，这些元素都可以扩展。客户端的展现层提 供面向对象的接口，内部采用 ajax 技术访问服务器。访问服务器的链接地址采用最 新的 rest 风格的链接地址，可读方便。 1.1.3.3 允许扩展新的分析函数 在报表中支持使用