数据科学低代码工具思考—期望与梦想

    前两篇文章笔者介绍了数据科学低代码的“起源”与“现状”，而本文将介绍笔者对该类工具的“期望”。而这些“期望”，就是笔者与团队创业出发时的动力。其实，很多期望在不同的工具平台中已经有了功能落地。但笔者现在罗列的“期望”，更希望是在一款低代码工具中“all-in”所有期望。

支持多人协同完成数据科学工作

    传统而成熟的数据科学工具，如：Kettle、RapidMiner、SPSS等都是单机版工具。这些工具都是“小”数据时代的产物。那时候人们对于协同完成数据科学工作的需求并不强烈。而伴随着“大数据”时代的到来，数据的体量与处理、分析需求都变得复杂、多样，单打独斗模式的数据科学工作方式，不止是在算力方面行不通了，更在人力方面也走不动了。团队协同工作，完成复杂的数据科学工程成为了无法回避的需求。

    如今一些基于大数据的数据科学工具以及SAAS模式的数据科学工具，都支持多人协同的工作模式。

一站式数据科学功能支撑

    数据科学包括：采集、处理、分析、可视化等不同阶段的工作内容。传统上，会有不同的工具支持不同阶段的工作内容。如：专门进行ETL的工具，Kettle、StreamSet；专门进行数据分析的工具，SPSS、RapidMiner、KNIME；此外，还有能解决部分工作内容的RPA(机器人自动化)工具，以及伴随着LLM(大语言模型)发展兴起的另类应用工具Flowise等。这些工具各有侧重点，在数据科学工程中都有一定的应用需求。团队成员之间使用多种不同的工具完成不同阶段的功能无疑会增加团队的学习成本、交流成本以及对接、集成的成本。

一款能够一站式支持数据科学各阶段工作的工具，能够为使用者提供一致的操作体验，使从事不同阶段工作的团队成员能够更有效的协同。

良好的低代码可视化交互体验

    曾有不少人与笔者探讨过“数据科学低代码工具”的市场前景。所有人都认为“低代码”的理念很好，市场上也有认同度，但就是普及不开，不知何故。也有人多年前就曾尝试过“低代码”工具，本想着可以节省代码编写的时间，但发现由于工具提供的交互信息不够友好，无法顺利的编写出期望的流程。从而作罢，改回通过代码来完成功能。

    总结来看，可视化交互的友好程度对于“数据科学低代码工具”至关重要。较差的交互体验将使使用者对工具望而却步。无法简单、直观帮助使用者完成处理或分析流程编写的工具，将最终让使用者失去兴趣。这也将导致工具只能在开发团队有能力支持的有限场景中应用，无法得到广泛的推广。我们能够看到目前比较流行的低代码工具如：Kettle、RapidMiner等都是国外工程师开发的，国内也有非常多的厂商开发了类似工具，但推广普及度都不够，主要还是因为系统提供的可视化交互体验不足，使得团队之外的人很难基于不完善的信息将平台应用起来。

笔者认为，类似Kettle等工具提供的低代码流程编写方式是一种可视化编程方式。低代码工具提供了一种可视化的编程语言，由于其仅是面向数据科学领域的，我们可以认为其是面向数据科学的DSL(领域描述语言)。当我们进入编程语言的思考层次时，我们就可以大量的借鉴通用编程语言进行开发时的经验来指导“数据科学低代码工具”的可视化交互了。由于低代码工具中的处理与分析功能都已经被组件化了，这与通用开发语言中的函数封装概念极为相似。当我们要使用一个函数时，我们最重要的是需要知道函数可接受的参数有几个，类型是什么；函数的输出结果是什么。为了保证使用者能够像调用函数一样，顺畅使用组件，低代码平台必须支持获取组件的这些相关信息。

这个需求听起来比较简单，但进入开发阶段确变的非常困难，尤其是在B/S架构下。传统的单机工具一般是通过直接执行当前组件之前的部分来告诉使用者输入当前组件的数据的结构是何样的。这种做法在小数据时代行的通。但到了大数据时代、B/S架构时代，远程驱动流程执行、前置流程的海量数据计算都使得这个方案不再适用。

除去上面部分我们提到的获取流程的上下文场景外，“数据科学低代码工具”还应该提供更多交互优化。因为其可视化编程语言与编程工具天然的集成在了一起。为了让使用者开发更方便，工具提供商应该提供更多的编程支撑。

全结构数据支持

    数据科学早期的目标数据以结构化数据为主，那时主要发展了关系型数据库、OLAP等能够存储与分析结构化数据的技术；当进入大数据时代时，以Json、XML为代表的半结构化数据成为了主要目标数据，NOSQL技术在这个阶段开始蓬勃发展；如今我们进入了AI时代，文本、图片、音频、视频等非结构化数据成为了这个时代的主要目标。虽然，时代的发展主要目标会发生改变，但旧有数据类型的需求并没有消失。本质上应该是随着技术的发展，我们对数据目标的范围增大了。

    传统的“数据科学低代码工具”都是在结构化数据时代发展起来的，他们能够很好的应对结构化数据应用的场景。当进入大数据时代时，不少工具进行了升级，能够对半结构化数据进行处理。但以笔者用过的低代码工具而言，鲜有对半结构化数据支持较好的工具。因为半结构化数据支持嵌套，能够表达编程级别的各类数据结构，因此其处理的方式也更接近传统编程，至少要了解的概念会比结构化、非结构化数据更多。进入AI时代，面向非结构化数据，有些RPA(机器人自动化)工具以及像Flowise这样新出的特定领域工具支持低代码方式操作。但这类工具一般又缺乏对结构化、半结构化数据的处理能力。因此，一款具有全结构数据支持能力的低代码工具将对数据科学发展非常有意义。

全数据量&流批一体

在数据科学的发展过程中，计算框架等新技术层出不穷。小数据时代的单机计算框架；大数据时代的Spark、Flink等分布式计算框架；AI时代的Tensorflow、Pytorch等计算框架，不断涌现。数据科学从业者迎接不暇。相当多的从业者需要不断学习新的计算框架并应用它们完成持续发展的业务需求。由于大量精力会投入到新技术的学习中，故而业务方面演进、提高的速度就大大变缓。虽然目前存在针对各类计算框架的“数据科学低代码工具”，但这些工具都只能解决一个特定场景的需求，基于Spark的工具更擅长批计算；基于Flink的工具更擅长流计算；对于数据规模与预算都比较小的客户上Spark或Flink显然都不如单机计算框架来的经济实惠。

    为此，一个能够支持多种不同类型计算框架，能够适应大数据、小数据各种数据规模，能够同时支持流式计算与批式计算的低代码工具，将更快、更便捷的满足数据科学工程中会碰到的各类问题。

开放的开发生态

    在之前的期望中，笔者希望“数据科学低代码工具”是一个一站式的包打天下的工具。那么必然要求工具拥有极其丰富的组件库，能够支撑使用者各种不同的应用需求。现实中根本不可能存在一种如此完美的工具。在没有进入某个行业的之前，不可能准备好该行业所需的所有功能组件，比如行业内特殊格式的数据文件等。这就要求工具需要具备持续扩展组件的能力。这种扩展能力只由工具开发商来支撑也不现实，现实世界的多元性、复杂性决定了这件事必须发动更多的人一起参与才有可能完成。

    因此，“数据科学低代码工具”必须提供标准的组件开发规则，通过构建开发生态，团结更多的开发者一起来完善工具。

总结

    以上六条是笔者对于“数据科学低代码工具”的期望与梦想，也是笔者创业团队的目标。目前我们还在路上，但所有的期望都已经有了落地方案与实践。可以在我们的社区版工具HuggingFists中部分体验到。欢迎有兴趣的朋友试用、指正。