远程数据处理的方法#
---
创建日期: 2023-06-14
---
如题。
除了 模块化工具以提升开发效率、 高效的数据流动以提升使用效率、 结构化数据以提升后处理（统计性分析）效率， 我们面临的一个问题是 大量的数据（高采样、多通道、长时间）会被远程处理的情形。
列了一些潜在方案，其实一个可行的方案都没有，只是列举好玩的。
处理程序在本地#
处理程序在本地，是最常规的情况，虽然有工具部署问题，不过总有办法，不做讨论。
1. 数据传输到本地
最简单的当然就是把要处理的数据从远端复制到本地，再用工具进行处理。 或者读取数据的时候直接浏览远程数据，让系统服务后台载入，不过如果中断就要重新来过了。
这当然算作一种方法，简单粗暴。 只不过我们常碰到的问题是网络太慢了。
不同的策略速度会不一样一些，比如公司内部网络传输速度就很慢，使用OneDrive下载会快一些，OneDrive的同步会更快。
如此原始的方法还会涉及到另一个问题，就是数据的组织。 如何能高效的找到想要的数据？而围绕这个又引出不同的解决方案。
2. 本地发送指令
另一种程序在本地的方案是，由本地发送指令，让远端执行。
这个不算处理程序在远端的原因是，远端部署的是计算服务，分析的方法是由客户端定义的。 MATLAB并行计算库提供这种能力，不过你要既有服务端的许可证，还有客户端的并行计算库的许可证，满满的钱 ( $ _ $ )
因为远端计算服务和数据很近，载入速度快很多。 不过最终结果还是要返回本地，如果数据信息没有大量压缩，还是没有避开传输。 而且过程中就不太能数据交互，否则就是成倍的传输成本。
所以这种服务，偏向于做成熟的、交互少的、大量数据中提取压缩结果的计算过程。
处理程序在远端#
3. 远程桌面
这种方式部署工具的过程和在本地是一致的，只不过部署在离数据近的节点上，再用远程桌面去操作工具。 离数据近，读取速度就快，中间结果也可以保存在远端。
不过操作若延迟比较严重就很影响体验了。 另外，处理的结果是否需要传输回本地、结果的大小，决定是否要使用这种方法。
（在Windows下）在服务器端开启远程桌面，本地系统自带客户端连接。 不过通常只能有一个用户交互界面，开多个要许可证啦。
支持多个界面的虚拟用户，VNC或许是不错的选择。 不过此时VNC的账户系统就不是公司组织的账户系统（AD）， 得通过代理账户进行。
4. 浏览器/服务器
使用网页技术（浏览器/服务器）是可能是现在最普遍、首选的方式了。 使用网页前段技术构建交互界面也十分成熟。
在这种情况下，数据的浏览、载入，中间过程存储，都需要做一套组件， 毕竟浏览器调用文件浏览，是会从本地上传为服务器端会话文件的。
做浏览器的工具，就不能像桌面程序一样了，把几个G的数据以文本的形式返回给浏览器进行渲染。
5. X11
之所以青睐网页技术，因为可以在全平台上访问。 而且远程操作不会需要（也不能）巨量的数据传输，因为数据处理会在服务端完成。 可是我们不擅长用网页技术，需要搞定前端和后端。
通常网页应用还有用户机制， 可我们没有用户管理需求（只是做个工具，不要月活量）， 都是直接工具界面访问数据，访问权限由AD定义。
如果应用程序能在远程端运行，但是在本地显示界面？好像有这种技术来着。
X11协议，就是把本地的显示作为一个“X Server”，而“X Client”在这上渲染界面。 以前玩虚拟机的时候，在宿主Windows下装了个Xming，然后显示了许多虚拟机Linux的程序。
这种方式需要SSH端口转发（Port Forwarding），先SSH登录到远端，配置完了再执行程序，总之挺麻烦。
还要装个Xming，要是浏览器本身就是一个X Server，URL再是某种X11的协议，输入网址就可以执行远端的程序就好了！ 而且X11的上下文都是远端的，也就是文件浏览显示的也不是本地的文件夹。 然而转头一想，我们公司平常就不提供Linux的服务器啊。
想用X11的方式，一方面不会网页技术做界面，能复用桌面的工具就好了； 另一方面，觉得只是单独显示程序，不用加载整个桌面Shell，应该更省资源。
然而X11似乎其实很慢，还不如远程桌面的交互来得顺滑。
这种只显示单独程序的远程桌面，Windows下也有，Citrix（的某个产品？）。 不过这种情况要部署应用就要牵扯到IT部门了。（前面部署服务器难道就不要了？）
6. WebApp
既然说到在浏览器中显示桌面程序，不想（不会）用网页技术重做桌面程序， WebApp呀，一次构建，桌面和网页双重部署！
可是……好吧，我就是不爱用。
我觉得界面构建自由度不高，而且服务端也没什么自由度，不能获知服务端周围环境。 更像个一次性的工具，可能要很熟练才能突破这些限制。
非要多平台编译的话，我看看还是学基于Dart的Flutter吧。
7. 远程数据服务
这个就是构建数据处理的API，可以扩展成使用Docker创建微服务。 类似于网页技术，只不过没有用网页作为前端。 又有点类似于本地程序发送指令，但是服务端不是通用的计算服务。
能够作为更大、更深远计算的基础。
8. Jupyter
其实前面的各种选项都隐含围绕着一个重点：交互界面。 不论这个界面是在本地还是在远端，是桌面程序还是网页程序。
高端点、专业点，用库、用命令行做分析行不行？！
其实用命令交互的方式，数据结构定义得很清晰，专心于处理方法，也不要许多的界面封装。 如果用Jupyter，组织好分析的notebook，多么简洁、高效、有序。
Jupyter还支持模拟终端（Terminal）。 诶？似乎也不一定非得是Jupyter啊，有个绑定账号系统的Linux服务器，就可以多用户SSH远程登陆了。 直接命令行执行脚本分析啊。
如果是这样，只怕是普及无望了……
无论是在桌面端构建工具，使用文件浏览器+分析工具+文件存储的方式； 还是网页形式，访问存储服务，网页中的分析模块进行处理，再将结果作为服务的方式提供给下游。
本质上都是处理数据、理解数据，最后呈现。
不断地有人会尝试用新的方法去封装这些过程。 我们向各个方向试图迈进，却又困难重重而止步或者退回。
大概以后也会有人试图带着前往他觉得美好的方向，而后退回，可是停下的位置又比我们进步了一点点。