让数据可视化“更上一层楼”的修炼宝典

在ggplot2、seaborn、shiny、Dash、R或python之上，还有哪些更高级的程序语言？有关数据可视化“更上一层楼”的秘诀，本文将一一道来。

众所周知，对许多企业来说，数据即商机。因为数据能为企业提供更优质的决策和预测。开拓市场、模型诊断及生产制造，各个阶段都需要研究数据。而其中涉及的工具更是五花八门，从Excel到通过python matplotlib进行的Tableau。不同的要求会给数据研究的自动化带来不同程度的难处。

显而易见，在对股东或其他观众做汇报时，人人都想用美观炫酷、交互性强的商业仪表板来汇报业绩，沟通工作。其标准流程是将解决方案打包成网络应用程序（让其在客户端与服务器中共同运行）。

用数据科学领域的经典工具包创建网络应用，总会出现很多让人沮丧抓狂的问题。不过，有一个极好的解决方案可以提供给你——该方案涉及Lisp算法（该算法的一种特定语言），人工智能渊源最久的计算机语言之一。

本文适用于任何需要在工作中进行数据可视化的人，尤其是那些需要在网络应用里实现其高度个性化与灵活化的业界人士。话虽如此，任何致力于打造个性化用户界面的数据科学家也能从本文获益。在阅读全文前，如果你从未接触过ggplot2和plotly，建议你先恶补相关知识，因为它们涉及数据可视化的一些标准逻辑，能提供一个基准来对二维线画图函数作出预测。

问题

在数据科学家们看来，R或python是最杰出的计算机语言，两者都有一个用来制作互联网应用的标准数据库——Shiny库与Dash库。这两个数据库都可用来制作网络应用，搭建起沟通主语言与javascript——同时也相当于js——的桥梁。它们还可用于浏览器（前端）与服务器（后端）之间的信息交流（如数据传输与用户交互），在该过程中，应用以主语言运行，直到程序终止为止。

此外，它们还处理js的异步数据交互，为缓解应用部署压力起到积极作用。说句公道话，在上述方面，这两种语言的作用举足轻重。但是，前端与后端的归并也会带来很多不便，大幅降低这些应用框架的使用价值。

1. 用户如今已习惯了这样一个流畅迅捷、功能多样的动态行为界面，即使是错误信息也会以动态UI的形式得到呈现。出于对js的规避，shiny与dash的用户往往在按照要求实现HTML的个性化输出上力不从心。例如，根据浏览器的宽度尺寸来创建一个带色按钮，如果不用js，操作起来会很困难。就算真有这样的方法存在，它也需要一个联通前端与后端的通信循环，而这瑕疵颇多，并不理想。

2. 用shiny与dash这两种框架很难编写出真正意义上的模块元件。这里的关键原因在于HTML节点所进行的用户事件会触发HTML节点标识符与后端效应的强耦合。此外，就shiny而言，因为环境，命名空间与模块在R里并不常见，所以用其制作一个模块元件很难。

3. 最后，即最重要的一点，这两个框架的发展进程令人懊丧。以这些程序包为基础的反馈周期漫长得令人发指：生产环境中会生成新的特征、成分、视图与标签，每当源代码出现一处变动，后端就会重启，互联网浏览器就要刷新，研发者就要保存当前特定状态，以确认这次调整是否达到预期效果。在一定规模的项目中，数据和程序包在一开始便被上传，每一次迭代发生变化时，研发者就要费工夫进行初始化。最糟的是，区区一个句法错误，就会让整个应用在重载中崩溃（注意，模拟两种系统的热重载会有被黑的风险。后端在处理文本区域时还会根据eval command评估文本中的代码内容。换言之，这会带来信息安全问题）。

解决方案

前后端的再分离，辅之以前端控制，便能解决上述所有问题。

1. 方案会让你获得全部收益，并以此控制前端，鉴于所有的计算结果都呈现在浏览器上，所有用户界面操作都不再需要与后端进行信息交流。

2. 大多数的前端技术都能够处理模块与命名空间，因此你可以同时处理如种类、日期等多个变量（只要这些变量处于不同的命名空间），一切有条不紊。此外，由于该程序不需要与客户端进行数据通信，程序代码变得更加模块化，也因此更加耐用。

3. 模块热替换（即热重载）在其他框架中也能够实现。正是这一特征让人们对采用这一解决方案跃跃欲试。最后一点是最好的单一功能，这个功能的优越性打动了你，你将无法回到没有该功能的生活。

简单粗暴的方法

学习js与ReactJS(与dash联系紧密)，可不是桩易事，因为如上文所述，Js古怪颇多，很是难学。

“寄生语言”（ParasiteLanguages）

“寄生语言”是一种编程语言，它利用现有的语言及工具，将句法根据特定的基本技术进行转化。例如，Scala是Java的寄生语言，TypeScript是js的寄生语言。寄生语言的优势在于它可添加某种范式并规避目标语言的一些弱点。例如，TypeScript在js基础上添加了类型属性。我认为，Clojurescript(cljs)，即Clojure的一个以js为原型的版本，是所有数据科学家最得力的辅助工具。因为cljs代码实质上就是js代码，所以你能享受到和js一样的由高速带来的恩惠。命名空间是cljs的标配，而且要比Javascript简单得多。多亏了figwheel及shadow-cljs，热重载也是行之有效。

但是，如果js也能达到上述效果，为何我会偏爱cljs呢？这是因为这款计算机语言极其简单，且格外稳定，可用于制造出精致且简明的代码。它消除了许多js语言的代码陷阱，并搭建起一个置数据于代码中心而非容器的模型（从此不再有包含1500个类的项目）。此外，cljs还有一个身经百战的标准数据库，可用来处理数据。

后端

就后端而言，虽然运算部分与执行业务逻辑的代码保持原样，但为了响应前端发出的HTTP（S）需求，代码上需要增添一个包装器。用R语言的plumbr包或python的flask应用框架便可轻松搞定。一些可由客户执行的简单操作（如按照组别对表格进行筛选与分组），输入数据将以csv或json的形式存储，只需配上一台HTTO服务器即可（如根目录里的python3-mhttp. server命令 ）。例子详见个人网页。

利弊权衡

学习cljs后，用户对任何新方案都会持怀疑态度。那么，采用cljs又会有哪些不足之处呢？

就特征而言，如今数据科学家需要对客户和服务器间的通信负责，这意味我们需要学习如何设计一些基础的应用程序编程接口。但是，这也意味着后端会将用户通过不同URL请求发出的数据一一遣返。

RStudio和Plotly从部署到生产所提供的解决方案有所不同。换言之，尽管网络应用（前后端分离）结构只有一个标准范式，可供选择的存储云供应商与教程却是不少。

代码基址如今有两种程序语言。引进一种新的程序语言与对应的工具总是有风险的。不过，我坚信这种方法带来的益处远大于其潜在风险。

锦上添花

学习cljs并使用建议的层次结构会给我们带来许多额外的好处。

· 鉴于cljs属于Lisp语言，因此它是一个功能性语言。

· 鉴于js以网络，电脑与移动客户端为目标，cljs也能达到同样的效果。

· clojure上手极其简单，所以很快便能在java虚拟机上编程。

· Google Closure上如代码拆分与无用代码删除等工具都适用于cljs，这能优化应用代码尺寸，利于用户体验的流畅性。

· 尽管plotly是一个很好的默认选项，你还是可以使用任何js可视化框架。有听说过Vega吗？有了它，编写R或python便不再需要包装器。

· 多亏了cljs与js的互操作性，你可以充分利用任何在包装器上以js语言写成的ReactJS组件，来完善自己的程序语言。你甚至可以重新使用dash-html组件。

· 在某种情况下，你会学习emacs，这是目前效率最高的工具。将其与Lisp相结合，配置程序将变得信手拈来，游刃有余。（但切勿同时学习emacs和cljs这两种语言）

结论

本文中，笔者建议数据科学家学习网络发展中的关键技术（cljs），以此丰富制作应用的发展经验。虽然R Shiny与python Dash也能奏效，但他们的前端技术缺乏关键特征，如模块热替换（浏览器的无刷新更新），这会导致发展经验的次优化。

本文还对cljs优于js这一观点做出论证。但笔者想提出另一个观点，让任何人最终都愿意体验一把cljs：用cljs创建数据可视化与网络应用实在是其乐无穷。cljs处理问题迅捷，专注与灵感常伴人左右，只须灵光一闪，一切难题便迎刃而解。这样的体验，值得一试。