关于前端:实现一个通用的可视化中间件需要怎么做

前言

在大数据的背景下,随着信息技术的提高,大量的数据只有通过可视化能力失去所须要的法则。传统的表格展现在大数据量背后显得会很有力, 而数据可视化呈现目标就是让用户能从数据中更高效，精确提取要害信息。
数据可视化局部曾经成为数据分析的外围局部。

目前笔者涉猎可视化方面,覆盖面比拟广,chart图表,realtionGraph关系图,GIS地图,3d等等。秉着循序渐进的过程,本篇文章先介绍关系图。

从数据库来说

图的存储并非是存储图片的数据库
图数据的存储是俩个根本元素 节点 和 边

从用户交互界面来说

图能够更清晰的表白实体与实体的关系,也能更间接体现多实体是否存在关系
图能够体现更多重维度,更多类型实体间关系,并不像表格那样死板.

请看示意图:

从表格可能须要从多类型表格查看,而从图能够很直观的看到须要的信息

可视化现成的技术库很多,D3,Echarts,G6等等,然而它们仅仅是根底,或者能够比方说是盖房子的砖头,房子须要你去盖，如何盖呢?

须要满足各大企业,各类业务数据的对接展现,能够了解为不care任何数据起源,做到足够灵便即可。
如上一条所表白意思,为满足传统企业需要,须要一个数据映射的过程,并不是每一个企业都是用到图数据库,或者说在数据采集整顿部份曾经很欠缺了,那么就须要配置schema(数据转换的规定)
丰盛的图交互性能,简略易用的API去凭借业务拓展欠缺.图展现算法的弱小,可提供定制化布局算法(例如FR算法,能够依靠业务规定赋予每个实体不同比例的电荷来展现不同的成果)
图资源的提供,可视化作为剖析中的一个模块,那么就须要反馈可视化的剖析后果(图片,图数据)进行报告的定制,给到客户一个称心回答.

从上述几点角度登程,就能够打造一个关系可视化中间件利器!

根底渲染实体齐备,关系图中次要是节点&边,那么就须要提供不同几何形体的表白节点(圆形,正方形,菱形等等) 边(实线,曲线,虚线等等),为满足期业二次开发那么就须要反对节点和边的定制化拓展.
布局算法(layout algorithm) 关系图罕用算法蕴含circularlayout(环形布局),forcedirectedlayout(力导向布局),gridlayout,(网状布局)，treelayout(树形布局),sankey(桑基布局),Dagre (流程) 等等,布局算法类也须要齐备,当然也须要反对定制化算法接入
数据源对接和外部算法,数据源:如下面所提到的数据源能够是不同业务的数据,可视化这边只是暂存的一个过程,平台给到可视化什么数据,可视化须要还给平台什么.算法:根底图算法的反对,路径分析算法如:最短门路,链路,环路。社区散布算法等等
事件监听与error捕捉。作为通用性可视化中间件,那么图下面的交互应该有事件的监听,并且监听事件的灵便登记注册来管制性能的开销

.给到平台及时的用户行为反馈.error捕捉,图异样的解决(try,catch的机制) 当出现异常行为异样数据应该有对应的解决计划。

作为中间件的研发,那么就须要集成的产品/我的项目中,体现它的价值。

如果你的公司技术栈对立,那么采取对立技术栈,组件化注入计划去开发你的可视化中间件,而后组件援用就能够达到,偏理想化
采纳通用型技术计划,前端架构来说选取<iframe>接入+window.postmessage消息传递计划也是不错的.从兼容性,技术难度来说都是齐全能够胜任的.

目前笔者从事大数据分析畛域(侧重于可视化方向),近期也会把一些技术计划和一些技术细节在此分享。(保障更新效率和文章品质)心愿对大家有所帮忙。

最初有大数据分析需要的企业(老板)能够分割一下笔者.目前这边有较欠缺的团队，前沿的技术.有信念服务好每一个客户!