数据科学工具伴随着计算机技术的发展也在持续的演进。数据库、大数据以及人工智能等时代标志性技术的出现，对数据科学工具的能力也有了更高的要求。一般而言，工具发展的趋势都是首先会出现一个能够支持数据科学计算的开发框架，方便用户能够更加便捷的使用最新的计算机技术解决数据科学相关的计算。而后，伴随着开发框架的逐渐成熟，为进一步降低用户的使用难度，此时会出现一些数据科学相关的低代码工具。
这些低代码工具可以是基于开发框架衍生的，也可以是独立于开发框架之外的。比如当大数据技术出现后，首先出现了Spark以及Flink等这样可以支持对大数据进行ETL以及分析计算的开发框架，伴随着两个计算框架应用的逐渐成熟，出现了很多依托于二者的低代码开发平台，如：StreamSets、SAS的Viya等；再比如2023年LLM爆火后，立刻出现了LangChain，该开发框架支持更好的应用大模型，随后出现了基于LangChain的低代码工具Flowise，用来简化LangChain的应用。
由此可见，降低工具或开发平台的使用难度始终是一个会持续存在的需求。降低使用难度就意味着可以降低对使用者的能力要求，提升使用效率，并最终达成节省成本的效果。其物理学上的意义就是可以降低能量的消耗。更低能量消耗的特点使其符合了社会发展的总趋势，也再次证明了其存在的合理性。但数据科学低代码工具能否普及并被广泛应用还存在着很多其它制约因素。
相信绝大多数读者都或多或少见过如下经典界面表现形式的低代码工具：
Kettle流程图示例
这类工具都支持使用节点和节点间的连线定义流程。节点描述了具体功能，不同的节点表示不同的功能；连线表示数据的流转关系及节点的执行顺序。这种组织方式直观易懂，除了在数据科学低代码领域(包括：ETL工具、分析建模工具)被广泛应用外，我们也经常可以在其它类型的软件中见到，如：工作流软件、RPA(机器人自动化)软件、SOAR(安全编排自动化与响应)软件等。
随着近些年大数据技术的蓬勃发展，在数据清洗领域出现了ELT理念。其与传统ETL理念的最大区别是，其将数据转换工作迁移到了数据转移之后，即进行数据处理任务时，先采用抽取(E)、装载(L)两个步骤，将数据从源存储系统转移到目标存储系统，然后再利用目标存储系统的计算能力，按需对数据进行转换。这种数据处理方式可最大限度的利用目标存储系统的计算能力，用其内置算法解决数据的复杂清洗问题。这类低代码数据清洗工具以国外的Fivetran、Stitch等为代表，他们配置界面更简单，对使用者要求更低。但这是以牺牲能够支撑复杂的数据数据清洗场景作为代价的，比如同时完成多源数据插入多目标数据的场景。另外，这种低代码表达方式相对不够直观，无法给出数据处理过程的总览。给人一种之见树木，不见森林的感觉。因此，笔者更喜欢上面谈及的经典的点线模式的低代码表达方式。但支持这种表达方式的低代码工具开发起来更困难一些，做到好用、易用很不容易，直接影响到了这类工具在市场上的认可度与普及度。
早期的经典点线模式的数据科学低代码工具，如：Kettle、RapidMiner、SPSS Modeler等都是单机工具。他们全部是面向结构化数据的，且数据处理量不大，单机提供的算力足以应付。这种单机工具能够提供丰富的操作交互，给出足够多的提示信息，其中最重要的就是流程中的每个功能节点输出的结构是什么，流程编写者将根据输出结构选取和使用后续功能节点。单机工具的一般实现手段是以选中的功能节点为终点，执行一遍前序流程，最终根据执行结果给出输出结构。这种实现方式在早期数据规模不大时可以提供不错的交互体验。但伴随着我们迈入大数据时代，发现面对海量的数据，这种实现方式已行不通。我们无法提供这样的计算方式来获得输出结构，因为没人知道这需要花费多长时间。对于正在编写数据处理流程的工程师，这样的交互体验是完全无法接受的。因此，如我们所见，很多基于Spark、Flink计算框架的低代码工具无法给出合适的信息提示，以至于用户的交互体验不足。
另外，如我们上面给出的Kettle工具的低代码流程图，我们可以看到每个功能节点可通过接入连线获取数据，并通过输出连线输出数据。这是一种非常普遍的表达方式，除Kettle外，SPSS Modeler、阿里Dataworks、Integrate.io等工具皆采用了这种模式，这种模式有一个比较明显的缺点，就是通过节点的外观，使用者不清楚该功能节点可以或必须接受几个输入，能够输出几种结果。如图中的“主表-子表连接”功能节点，需要接受2个输入，但从外观却看不出来。那么更好的一种低代码表达形式如下：
RapidMiner流程图示意
上图是RapidMiner工具的流程表达方式，可以看到其每个功能节点上都有输入/输出端口的表达，通过端口我们可以直观的看到一个功能节点工作时需要几个输入并会有几种输出结果(注：我们可以看到图中的每个功能节点都有多个输出，这是由于RapidMiner的每个端口只能有一个连线的设计导致的。即其输出端口只能连接一个后续的输入端口。如果某个前置输出端口希望连接两个不同后续输入端口时，其无法表达。故其在每个功能节点上都保留了一个可以将输入原封不动的输出的端口，这样可以变相的实现一个输出端口连接多个后续输入端口的功能。但这的确不是一个好的设计，一个输出端口是否可以同时连接多个后续输入端口，一个后续输入端口是否可以同时接受多个输出也是低代码工具是否易用的一个考察点。这里我们忽略不足，着重探讨RapidMiner给出的端口的这一概念。)。这种为功能节点明确输入/输出端口的表达方式显然是一种更清晰的表达。如同编程中的函数声明一样，函数包括名称、参数、返回值。参数约定了输入(有时也包括输出)，而返回值约定了输出，使用者一目了然。功能节点的输入与输出端口也对应扮演了函数的参数与返回值角色，让使用者能够更清晰的使用功能节点。
现入今随着计算机技术的不断演进，数据科学从小数据集到大数据，从结构化延伸到文本、图片等非结构化数据。低代码科学工具也层出不穷，用户跟着不断的迭代更新。这些因新技术催生的低代码工具往往与之前的工具无法兼容，是一种全新的工具，这使得用户为使用新技术，而不得不切换和学习新工具。如文章开头介绍的，依托于Spark、Flink技术构建的低代码工具并不兼容传统小集合数据的工具，但我们也知道，并不是有了大数据，小数据集分析的需求就不存在了。小数据集分析使用Spark、Flink框架也能分析，但使用这样的大数据框架去分析小数据集显的过于笨重，有种大炮打蚊子的感觉，使用成本也有所增加。再比如，目前用于大模型与人工智能技术的Flowise低代码工具，其表达风格与传统低代码工具也有一定差别，如下：
用户使用时需要再次熟悉这种风格的低代码工具。虽然成本不算太高，但我们知道用户的场景中，一定还少不了对结构化数据的应用处理需求，比如：让大模型处理结构化数据等。此时的Flowise又显的力不从心了。如果用户想解决所有这些问题，除了选用多个不同的低代码工具外就只剩自己开发了……
如果有一款低代码工具，他能够统一解决小数据集、大数据集、结构化数据、非结构化数据的所有相关问题，能极大的节省使用者的学习成本，使用者不必在焦虑于不断出现的如Spark、Flink、Tensorflow、Pytorch、LangChain等各类技术，而是更聚焦数据科学的应用，岂不是更好？
这就是笔者与团队梦想开始的地方。笔者将在下一篇文章中介绍我们梦想的低代码工具的样子。好奇的读者也可以先看看笔者有关HuggingFists的文章和视频。