国际惯例：项目Github地址，欢迎来到Stardonsuo/vue-data-board先放一个在线地址给大家体验（因为后端使用leancloud的免费包，所以可能会比较慢）：vue-data-板P.S.建议您尝试自己注册一个账号（可以随便填一个密码）。如果你使用默认的测试账号，不要乱改，否则别人进来的时候是看不到的，因为你的任何修改都会保存到后台数据库中。不知道为什么，公司对数据分析和数据可视化的需求越来越多。这些需求有的来自数据分析师（如果公司有数据分析师），有的来自产品、运营、开发，有的来自公司中高层领导，有的只是想导出数据某个表格，有的希望从多个维度对数据进行分析和可视化，有的希望将多个可视化图表整合到一个页面中，形成一个可视化报表。有的是一次性需求，有的是周期性归一化需求。这些需求往往比较杂乱，而且数据维度多，交互比较复杂，可视化图表参数多，很难通用。而且很多数据都是敏感的，需要严格的权限控制。久而久之，权限的管理就成了问题。头疼，各种因素导致各种数据需求在前端开发中耗费了大量的精力，发量越来越少。相信很多公司都会有类似的数据需求，虽然零散但又很有必要。虽然市面上有很多产品提供类似的数据管理功能，但很多企业因为数据的敏感性，不愿意把自己的数据放在其他地方。其次，这些数据管理产品大多价格昂贵，功能难以定制。所以在很多公司，这种数据需求都会落在前端的头上。尽管这些需求是分散的，甚至是临时的，但实现起来并不容易。可视化视觉效果需要配置各种参数，需要验证大量数据。清洗和转换使得接口调试和对接非常麻烦，增加了前端的工作量，也让前端的编码变得非常烦人。这时候，搭建一个功能强大、灵活易用的数据分析后台就非常有用了。傻瓜式拖拽生成图表，没有数据基础的同事也能快速上手；整合公司数据源，方便管理数据；通过构建看板整合多个图表，可以快速生成报表，方便查看和分享；通过用户自定义图表参数，可以有效解决前端调参的痛点。（很工整的一句平行句，ohyeah！）我在我们公司做数据分析后台已经快一年了。其实我从第一次实习开始就接触过BI和数据相关的东西。在搭建过程中，我踩了很多坑。这期间，我经历了同事们的各种抱怨，也尝试了各种解决方案。虽然代码能力没有太大的提升，但是对于混乱的、变幻莫测的业务需求，我还是有很多体会的。.经过半年多的痛苦折磨，我根据业务需求，参考其他数据分析产品，搭建了一个全新的数据分析平台。该平台目前在我们公司运行良好。该方面还具有良好的可扩展性，可以处理更复杂的业务场景。我将前端部分分离出来，形成了这个开源项目：dongsuo/vue-data-board首先介绍一下这个项目的基本情况。本项目主要使用Vue+ElementUI搭建。可视化部分使用的是echarts，拖拽和布局部分是vue-grid-layout和vuedraggable这两个库。本项目的一些技术、思路和一些辅助代码参考了潘神的后端项目：PanJiaChen/vue-element-admin项目后端部分使用了[leancloud]，除了少数数据使用了mockdata。(http://leancloud.cn)搭建，Demo数据的数据库部分是免费的国外数据库FreeMySQLHosting，速度比较慢，而且没有root权限，但是测试够用了，其他用户数据、图表、看板等使用leancloud对象存储。主要功能点和实现原理首先介绍一下项目的主要功能点和实现原理：1.通过拖拽字段查询数据。统一查询多个数据库。除了传统的关系型数据库，还可以查询HDFS，查询能力比较强大。数据查询前端部分，通过SQL语句的解构，主要分为维度、数据、过滤、排序、数据编号等交互元素，方便没有SQL基础的用户使用。前端用户交互根据特定的语法规则动态生成SQL，发送到后端进行数据库查询。当然，目前SQL构建功能还不完善，部分SQL语法尚待支持，已列入开发计划。2、数据的可视化渲染数据的可视化渲染主要是通过数据查询的维度和值来判断可用的图表类型，然后使用vue.js的动态组件渲染对应的图表组件：//Vue.js动态组件渲染对应的图表类型有问题这里是图表与数据的映射关系问题，不同的数据适合用不同的图表展示，比如饼图的数据和堆积柱形图的数据是不一样的，所以需要定义每个图表需要的数据结构：//这里是饼图的匹配规则定义matchRule:{desc:'1dimensionwith1value;具有多个值的0个维度',isUsable(dimensions,calculs){return(dimensions.length===1&&calculs.length===1)||(dimensions.length===0&&calculs.length>=1)}},和然后根据匹配规则判断图表类型是否可用。3.保存并回显图表。前端生成图表后，可以保存到后端。由于定义一个图表需要的字段太多，而且这些字段可能会经常变化，不可能让后端数据库一一定义这些字段，所以我们采用的方案是前端维护这些字段，后端以字符串或json对象的形式统一存储数据库某个字段中的所有内容（如content）。这样图表的呼应就没有问题了，按照生成图表的逻辑解析content字段的内容即可。4.图表集成到看板中。很多时候业务需要同时查看多个图表。这时候就需要一个看板来整合多个图表。看板其实就是指Dashboard。其实中文也没有很贴切的译法与之相对应。看板勉强表达了意思。多图表的看板整合只是对后台的一种关系管理。对于前端来说，需要根据看板关联的图表进行页面布局，然后根据保存的图表进行数据查询和可视化渲染。页面布局主要使用vue-grid-layout进行网格布局，也支持拖拽和调整大小。可视化逻辑与创建图表时的可视化相同，这里不再赘述。这里遇到的问题是，在已有布局的看板中添加新图表时，如何计算新图表的定位。这个其实有点类似于图片瀑布流的问题，但是因为每个item的宽高都是可变的，所以其实相对来说难度更大一些。我找到了一个想法并做了一些计算，但还不完美。完成后我会写一篇文章。介绍。5.数据权限问题公司的数据其实是比较敏感的。对上市公司而言，数据会影响股价走势，对非上市公司而言，会影响投融资进度。这些都是关系到公司财务乃至生死存亡的大事。因此，数据权限管理非常重要。在这个项目中，这部分的解决方案其实并不简单，复杂的地方主要在后端，而不是前端。简单来说，我们的权限在数据表层面。管理员在系统中添加数据源，同时定义数据源的权限范围，如产品、运营、开发等权限角色。用户进入系统后，管理员为用户分配权限角色，用户只能查询其对应角色可以查看的数据。由于权限和数据源管理的部分暂时没有加入到这个开源项目中，所以就不细说了，先挖个坑，以后补上。6.其他技术点：首先，使用Vue-cli@3.0搭建项目。除了默认配置外，还通过vue.config.js进行了一些自定义配置。项目中使用了很多图标。ElementUI的图标虽然在2.8.x版本之后增加了很多，但是还是不能满足我们的需求（一些常用的图标还是没有，比如保存），所以需要我们自己解决图标问题，我会感谢iconfont上的设计师Rushan提供了这套精美的数据可视化图标库。我使用postman来管理项目的后端接口文档。其实postman有很多强大的功能，不仅仅是一个接口测试工具，接口文档管理就是其中之一。我在开发的时候，一般都是在本地同时启动前端和后端项目。在本地开发时，我使用环境变量来确定本地后端接口的地址：constfetchInstance=axios.create({baseURL:process.env.VUE_APP_BASE_API*}*)本地开发完成后，前端是打包发布到gh-page分支（gitsubtreepush--prefixdocsorigingh-pages），后台通过leancloud提供的cli工具一键部署，相当方便。前端打包发布其实可以配置Travis-ci实现自动部署，这个我还没有配置（这里是放弃治疗的拖延症患者）。项目的登录授权，图表、看板的增删改查，都由leancloud提供的解决方案提供。其实使用leancloud的js-sdk，前端也可以很方便的实现对象存储的增删改查，无需写后端。界面。但是为了保持项目代码的纯净，避免在代码中引入诡异的AV.query，我还是自己做了后端部分。当然，这部分比较简单。毕竟只是一个Demo，主要是基于koa.js做的一些增删改查，基本都是面向文档的编程。项目中的状态管理使用的是vuex，但实际上目前为止对全局状态管理的需求并不多，store中只存储了usertoken。另外，关于状态管理，我在这个项目中创建图表的部分也尝试使用了Vue的简单状态管理模式（代码在这里）。这种模式用起来没问题，对于大型项目中的复杂组件非常好用。使用简单，方便的解决了复杂组件内部的状态共享问题。但是目前不是特别适合我的项目，因为把这部分状态管理放在全局状态中也很合适。当然，这里不同的人有不同的看法，我觉得像现在这样还是挺好的。最后，这个项目的核心功能已经七八十年代完成，还有一些功能还不完善，后期会逐步完善。数据分析和可视化平台国内社区好像讨论的不多。一些中文讨论多是介绍设计和产品，过于理想化。在实践中可能并不容易实施。技术实现上讨论的不多（当然终端和运维方面还有很多），开源的项目也不多，所以在这个项目上做了一些探索。当然，我没有太多经验。虽然参考了几个商业平台的产品交互设计，但很多地方都是摸着石头过河。有些地方应该有更好的解决办法。希望我的项目能吸引更多的想法，也希望大家多提意见。
