本帖最后由 vincent 于 2017-12-10 22:43 编辑
在前端数据完成了清理，通过了模型的校验，在前端展示的时候会频繁的出现性能问题，报错难以定位等这样的问题，通过长期的指导和积累发现往往是由于命名不规范导致定位难，模型不规范导致了排查难，页面不规范导致了性能慢等问题，通过长期实践，建议大家按照最佳实践来规范BI的应用。 一、命名规范最佳实践 1) 报表名称 Ø 按照主题、子主题、报表名称的层级去设定报表分布。 Ø 若存在历史版本报表，要单独创建文件夹和正式版本区分开。 Ø 报表文件夹的层级不能超过8层。 图一、较好的案例 图二、较差的案例 2) 数据源名称 Ø 数据源名称要准确，避免产生误导。 Ø 如果一个数据源有多个ip，建议在名称后添加ip。例如mysql139；mysql137。 3) 数据集名称 Ø 数据集命名的原则同报表一致，按照主题、子主题、数据集名称的层级去设定分布，名称和报表互相对应。 Ø 如果有集市，创建一个sql文件夹和一个集市文件夹分别存储。 案例： 4) 定时任务名称 Ø 建议任务文件夹名称与数据集文件夹一致；任务名称与数据集一致。 5) 报表控件名称 Ø 控件要重命名，名称要有意义，例如：文本输入框-t_date；table1-客户端部署情况统计。尤其是页面控件很多，又需要写脚本的时候，不命名的话，过滤器和脚本会看不明白。 （2）隐藏控件的名称以hidden_开头，位置统一放到右上角，采用设置背景色、字体颜色、透明、去边框、设置边框颜色的方式隐藏，置于顶层，不要被已有控件遮挡。 二、性能最佳实践 1) 数据集 Ø 所有计算都尽量在一个大宽表中完成，避免表间计算。 Ø 能在数据集处理的字段尽量不在报表编辑端处理，能用sql函数转换的字段，尽量不用JavaScript表达式处理。 Ø 在初期制作报表时，应尽量设计一个查询对应一个主题，一个主题可以对应一个或多个报表页面，这样一个页面尽量保障1个查询。避免一个页面，对应一二十个查询，反复组合，导致在出现问题时，IT都不知道如何下手。 Ø 尽量使用UNION替代JOIN关联。 Ø 尽量避免上万条数据以上的跨数据源组合查询。 Ø 建立sql查询时，尽量使用select 字段名1，字段名2，... from 表名，查询所需要的字段，避免select*，浪费数据库的资源。 2) 制作报告 Ø 有的不同业务分析内容，放在一个页面，或为了达到美化效果，单页面组件过多，导致页面展示缓慢，问题排查困难。考虑通过业务分离、逻辑分层，分为多页面显示，通过超链接进行逐层展示，同时尽量保障一报表刚好一屏，能少用一个组件尽量不多用。 Ø 尽量避免大量明细数据导出（超过1w条）的场景，明细数据导出往往需要线下二次加工，可以把这部分需求整理好放到BI上。 Ø 细节数据展现，在页面上加参数，根据参数过滤后，再进行少量数据展现。 Ø 有筛选条件时，尽量新增一个按钮做批量提交。在页面属性中勾选批量提交，可以减少报表前端向后台发请求的次数，提升性能。 Ø 筛选控件较多时，在页面属性中去掉“过滤组件直接是否关联”，也可以提高性能。 Ø 尽量避免对数据集市进行频繁的修改与删除操作。 Ø 一个报表中，尽量避免大量的使用文本框、仪表组件，因为一个组件相当于一个查询。 3) 定时任务 Ø 所有任务的执行时间尽量安排在限时，并且把时间分散开来，避免同一时间执行多个任务，以免在忙时影响用户使用。如果在忙时倒数，可以采用单独节点倒数，和用户访问区分开。 Ø 增量导入和同步查询的区别和适用场景。 区别：同步查询数据<span] 5) 表达式和脚本的使用 Ø 表达式嵌套使用最多不能超过两次，如，时间字段-->日期粒度拆分-->利用日期字段再新生成字段，超过两层会提示错误，时间字段不存在。 Ø 尽量避免逻辑复杂的，一环扣一环的脚本使用，如使用脚本从组件中获取数据-->将数据赋给一个参数-->参数传递到新建的表达式中-->表达式绑定到组件中。 Ø 报表完成后，如果带有脚本，尽量整理个文档，注明用了什么脚本，原因，作用等，编写脚本时，尽量带有代码注释，如下页图：
三、其他最佳实践 1) 组件的使用 Ø 门户、门户组件使用时，尽量使用永洪推荐的IE11以上，谷歌，火狐浏览器以及最新的flash。 2) 认证授权 Ø 查看用户，开发用户，创建数据集用户，权限严格区分，只开放对应权限，避免误操作。 相信按照最佳实践进行BI应用，能够给大家带来更好的体验感和高效的数据分析效率。
| 
