『数据可视化工程师』未来的路在何方?

谢邀。
往数据链路方向发展和钻研可视化领域其实都很不错,这也是该类工程师往后主要的的两大道路。分别说说吧。
第一个方向:数据科学/可视分析数据链路(我习惯称它为“数据科学”或者”可视分析“)在工业界的产品形态是类似数据决策这类的整套解决方案,例如微博舆情监控、安全态势分析产品等等,企业习惯说“借助数据的力量为决策赋能”,但说到底其实是希望结合数据让做出的决策更准确、令人更加信服,对应于学术界研究名词“可视分析”。
如你所说,数据可视化在其中所处的作用确实比较尴尬,过去很长一段时间你几乎可以将它等同理解为 BI 报表——一个可有可无、仅仅是锦上添花的功能。在应对数据科学类问题时,不论是研究人员还是开发人员往往都是从数据挖掘方法入手,毕竟回归分析、分类聚类或者是偏差分析都可以给人们更准确的反馈(准确率/召回率),而另一方面我们看可视化,仅仅以 case study 或者用户调研作为评估有效性的手段,相比之下确实要弱不少。
不仅是工业界,在学术界,可视化也处于一个相对尴尬的地位。“可视化”一词最早出现于1987年,当时还只特指“科学计算可视化”。虽然短短30年数据可视化蓬勃发展,衍生出“科学计算可视化”、“信息可视化”和“可视分析”三个分支,但随着计算机技术的发展,更多工作还有待完善。
但令人兴奋的是,随着大数据概念的兴起以及深度学习等方法的流行,数据可视化也搭上了快车道。深度学习在处理语音、文本、图像和视频等方面具有出色的表现,但在训练数据标注、节点和层的参数设置、模型自动化等方面要取得长足进步仍旧遥遥无期。由于深度学习等方法的过程可解释性较差,学术界不少研究转向可视分析等方法,希望从这方面进行技术上的突破。类似的思路我相信正在蔓延至企业,未来算法工程师和可视化工程师将有可能坐在一起共同思考如何解决数据分析上的难题。
所以,如果你觉得自己更适合这个方向,就要突破现有对自己职位的设定,早日准备。如我在之前一个回答中所述:“由于可视分析针对的是数据,所以应该对数据有较强的敏锐嗅觉”,这个嗅觉需要你多接触数据、了解不同数据的维度特征,比如时空数据和文本数据有哪些异同点,非结构化数据的维度如何量化为可视化展现等等,具体可以移步问题「国内有哪些成熟的做前端数据可视化的团队,做工程的前端加入需要补充什么知识?」,这里就不展开了。
第二个方向:数据可视化/图形学数据可视化本身是一门水极深的学科……你可以说它对,这是因为相比传统意义上的 Web 开发人员或者前端开发人员,图形学这一套概念确实很陌生,虽然利用 WebGL API,前端人员可以接触到图形学的内容了,但操作 DOM 这类内容和图形学所关注的“数字合成与操作视觉的图形内容”还是有很大的差别。
你也可以说它不对,三维图形技术从90年代迅速发展至今,OpenGL 已被普遍认为是高性能图形和交互式视景处理的标准。OpenGL 被设计成独立于硬件、独立于窗口系统,基于该技术的应用已经遍地开花,技术积累与开发经验也层出不穷。最直接且最为人熟知的应用就是各类端游和手游了。
但退一步说,即使我们不考虑 3D 可视化内容,普通的数据可视化依旧有很多值得深入的地方。这里又要拉上 D3 来说事了。16年年中,D3 4.0版本发布。在这一版本中,D3 进行了大刀阔斧式的更新,布局上暴露了更多细节(力导向图功能函数由12个增至41个),大量 API 的改动(多个二级函数提升为一级函数,不论是给新手还是熟练开发人员都增添了不少记忆负担)以及最重要的模块拆分单独开发。
谈到这次 D3 历史上最大的版本更新,Mike 表示,D3的“受欢迎程度超出我的想象,我希望尽可能地把它开发好。”经过这次大变动,D3 未来的发展得到了充分的保证,社区可以更便捷的加入讨论、并贡献自己的力量,历史遗留问题被逐渐消灭(一个反面例子就是 three.js,由于不断的发展加上底层且繁琐的 canvas 2D/3D API,如今的 three.js 已经非常庞大,mrdoob 仍在不断贡献代码,但相比之下社区参与程度就要弱不少,一个压缩过的源码都有527KB,Echarts 做 ClayGL 的初衷估计也是考虑到 three.js 已经比较厚重了吧),但也正是这次大更新,使得众多依赖 D3 的优秀第三方可视化库停止了向前的脚步。你如果经常翻看 D3 Gallery 就会发现很多案例引用的依旧是 v3 版本的代码。


推荐阅读