Jupyter Notebook 交互式编程 & 低代码拖拽式编程 | 数据科学生态下的理想平台

近几年，Jupyter Notebook 为数据科学家们提供了与数据有效交互的工具。用户可以运行代码、查看结果，然后重复数据之间的循环和迭代。使用 Jupyter Notebook 进行研究成为了数据科学家们快速制作原型和探索分析的首选。

然而，数据科学的实际工作流程，不仅包括数据科学家们利用 Jupyter Notebook 处理数据、制作模型，还包括其他成员之间大量的沟通协作，如：数据科学家和数据源端沟通数据的接入、和开发运维沟通服务的容器化和部署、和业务方沟通业务需求和数据服务效果等。因此，在线 Jupyter Notebook 和低代码、拖拽式编程工具逐渐发展，用于优化数据模型开发和应用的全流程。

本文介绍了数据科学分析工具的发展进程，并对应了不同形态的工具的主要特征、应用场景，以期帮助数据科学家、业务专家等各领域的人员了解数据科学生态下的关键工具，进而优化工作流，加速数据驱动的研究及决策。

Jupyter Notebook 交互式编程

Jupyter Notebook 是什么？

对于数据分析、数据挖掘、机器学习或是深度学习等数据科学领域的专业人员来说，除了需要具备一些数理统计知识外，还会需要通过代码来实践或验证理论想法，Jupyter Notebook 便成了数据科学家们最熟悉且常用的工具。通过它独特的交互式开发，适用于科研、教学等场景。

Jupyter 即是 Julia、Python 和 R 的缩写组合，另如 Notebook 含义所示，它可以以笔记的形式记录和保存相关的代码和输出，并将结果以文档的形式与其他人共享。

Jupyter Notebook 主要有三大优点：文学编程、交互展示、易于调试。

1. 文学编程

文学编程的思想强调人的思维逻辑的可读性，即在对阅读者友好的文本中插入代码块，让学习进程和探索进程变得可记录可回溯，不断累积知识，获得增量式进步。这种形式非常适合研究性、探索性工作。

想象一下，当你需要做数据处理、分析建模、观察结果时：

• 如果是在终端运行程序，包含函数和类的脚本存在其他文档，可视化结果在不同窗口显示，此时还需要写一份囊括全部的说明文档记录分析思路、程序运行、结果呈现......整个研究过程杂乱无章，无法专注于研究本身。
• 如果是用 Jupyter Notebook 进行分析，代码、可视化结果、说明文档都留存在同一页面中，整个分析过程和研究思路变得异常清晰。

2. 交互展示

Jupyter Notebook 由 Cell 模块构成，Cell 分为 Code 和 Markdown，其中 ：

• Code Cell 可以独立编写、运行代码，并单独反馈结果，方便试错和验证结果，对于学习数据分析、入门数据科学或者编程语言的初学者来说，这种交互形式非常友好。
• Markdown Cell 可撰写文档，展示图片、表格、链接、公式等丰富的内容，可读性强、学习成本低，一个文档就可以涵盖课程章节的理论知识点+编程实战+可视化结果，将课程知识点完整表达，适合教学展示、课堂交互、数字化培训等。

Jupyter Notebook 本质是开源的 Web 应用，文档可以被轻松创建和共享。在团队协作时，代码、叙述文本、可视化结果结合可以清晰地表述出完整的分析过程，轻易地与他人分享研究思路、复现研究成果，团队之间迅速建立有效沟通，极大地提高协作研究效率。

3. 易于调试

在数据研究中，如果需要调用深度学习模型来测试功能时，模型往往几百M甚至几个G，将模型全部加载到内存里需要耗费大量时间。当加载模型确定无误，只需调试调用模型预测数据时：

• 如果用 IDE，每加一行代码或每改一个参数都会花费大量时间重新加载模型。
• 如果用 Jupyter Notebook，运行一遍代码以后变量占用的内存不会自动释放。模型加载的所有数据都在内存里，不覆盖变量就不需要重跑 ，因此只需将代码分段执行，灵活调整参数。

Jupyter Notebook 并非理想的 Notebook

基于数据科学的繁荣，尤其是探索性数据分析和开放科学的发展，Jupyter Notebook 作为一种交互式编程的范式实现了自己的价值，但随着数据科学领域近年的飞速变化，它面临着更现实的业务问题和技术挑战。

1. 繁复、易出错的环境搭建与版本管理

研究之初和实际研究中，不论是对于编程新手还是技术人员，都难免经历一系列费时费力的环境搭建与版本管理过程。

[1] 环境配置问题

不同研究项目使用的 Python 的解释器版本不相同，各版本之间互不兼容且长期并行，但是却需要运行在同一个服务器环境中。而不同的 Python 解释器版本，对软件包、依赖库的管理也是个问题。因此，在本地使用 Jupyter Notebook 时经常因为冲突问题导致系统出问题，安装环境或服务组件失败。

[2] 版本控制问题

在实际使用 Jupyter Notebook 进行研究的过程中难免会遇到文件回退、历史文件对比等操作，但是 Jupyter Notebook 内容结构通过 JSON 的方式进行组织，源代码 、Markdown、outputs 输出都储存在一个体积较大的 .ipynb 文件中，复杂的数据结构会导致 .ipynb 文件在版本比对时的可读性很差，无法很好地做版本控制。

2. 编程使用习惯与 IDE 不同

数据科学研究人员如果有其他编程语言的经验，经历过传统的 IDE 时代，使用过 Visual Studio 或者类似的 IDE 进行开发，对编程开发平台有着固有印象和特定期许，那么对 Jupyter Notebook 的接受程度可能不是很高。

• Jupyter Notebook 定义为研究类调试环境，不是一个真正意义上的集成开发环境；
• Jupyter Notebook 对于成规模的项目来说功能过于简单，缺少必要的项目工具，而 IDE 的文件管理、代码管理、工具集成以及自动补全、智能提示都相对较强大；
• Jupyter Notebook 对于分布式调测、重型异步任务的支持不够友好；
• Jupyter Notebook 对于分布式的训练可以通过单机多进程的方式进行模拟，但对于运行非常大规模的训练作业，还是需要工程化代码开发，并搭配测试逻辑，将任务部署在集群中进行批量运行。

P.S.（我是彩蛋）CloudIDE 是后文即将出现的 ModelWhale 数据科学平台另一种形式的数据分析工具，后期推文将会着重介绍。

在线 Jupyter Notebook

时下，我们面临着数据科学的诸多挑战：

• 数据量呈指数级增长，对大型计算、存储、及数据管理提出了新的要求。
• 机器学习、人工智能、增强现实、物联网以及几乎所有其他突破性技术，正在进入工业化阶段。
• 自然科学（如气象学和生命科学）、经济学、工程学和社会科学等研究领域都开始利用数据科学解决领域问题。
• 模型的大规模、复杂性和实验性成为各行业工作流程的主要挑战。

这意味着你可能需要一个云端数据科学工具来整合现有的生态系统和数据平台。在 Jupyter 交互式的基础上，ModelWhale 应“云”而生，更加关注基础架构、资源配置、功能拓展、协作开放。

1. 云原生

ModelWhale 对现有的本地设施没有侵入性，能够与原有的基础设施很好地兼容，提供数据科学应用特性所配套的计算调度引擎，使得不同的研究团队、工作团队可以根据实际需求实现云资源的快速拓展与高效调度，同时可便捷地接入各主流厂商的云平台、各种类型的计算实例，对基础设施的陈旧与不足提供有力的支撑补给。高校、企业、科研机构可以利用 ModelWhale 的云原生架构轻易搭建一站式数据科学平台，助力研究、应用和业务的发展。

2. 功能拓展

ModelWhale 对数据探索的流程做了许多针对性的功能优化，包裹了实现细节，提供了好用的功能。个人和团队都可轻松上手数据分析，快捷高效地开展数据研究工作。

[1] 数据接入

• 支持多种类型格式的本地数据文件上传接入，或直接调用公开数据集。
• 支持超大数据的云上调用及分析。用户除了可以在 ModelWhale 使用数据连接调取存放在数据库、对象存储的数据外，还可以通过创建 NAS 空间调取 NAS 中的各类数据。

[2] 算力接入

• 面向多种规格的计算资源一键接入。不论是单卡CPU/GPU运算，还是多机多卡的 GPU 组成集群算力进行分布式训练，可随实际需求一键勾选。多机 GPU 集群，支持基于 Horovod 的环状规约架构，可显著分散网络传输的压力，随着集群的规模增大计算性能线性增加。
• 资源用量可视可控。ModelWhale 可以对每个资源的可用群体、使用时长、使用时间进行管理配置，能够对资源的使用情况进行可视化监控，支持对资源的权限审核机制。

[3] 环境管理

• ModelWhale 真正做到了开箱即用，无需任何软件安装及环境部署，解决了科研初期基础设施配置搭建的繁琐消耗，提供了丰富的镜像资源，包含大量数据科学和其他交叉学科的常用工具包（如：气象、生命科学等）。
• 用户可以根据需求利用标签筛选官方预置的安全稳定的镜像环境，也可以自定义镜像环境，满足个人或团队的特定运算需求。
• ModelWhale 的环境管理为每一个数据科学项目创建了隔离的开发环境，每个开发环境所安装的包和依赖相互独立，可以确保项目的开发环境不相互干扰和污染。

[4] 版本控制

面对研究过程中多次修改或者迭代数次的项目内容，如果打算保留每个版本，就需要在每次修改前创建副本并重新命名，最终很可能导致研究者本人都无法区分有效版本。

ModelWhale 支持为复杂研究项目的阶段性工作进行版本管理，提供了生成项目版本、版本比对、内容替换、合并版本的功能。针对每处修改，用户可以实现文件级回退与 Cell 级回溯。团队成员也能直接查看修改历史，将注意力放在最为重要的创作上，安全高效地开展团队协作。

[5] 生产资料共享

大部分的数据研究，实质是对非结构化数据进行重构和再构，是利用数据再生内容和驱动内容的过程。已有研究内容的开放、分享和共享，是生产和应用的基础，也是团队协作的前提。

ModelWhale 可以一键 Fork 团队成员以及和鲸社区产出的相关项目、数据集。科研过程中的所有生产内容，如数据、代码、环境，皆可打包为项目复制到自己的工作区，或者发布为云端的数据集、算法、模型服务，便于重用和管理，让团队不同成员、企业不同部门之间有效协作，提升工作效率。

3. 协作开放

数据研究离不开团队协作，ModelWhale 提供了清晰易用的协作空间和灵活可控的管理体系。团队成员之间资源共享、信息融合，有效地推进项目进展，提高团队科研创新的质量和水平，同时为基础设施赋能，计算资源弹性调度，从容应对多变科研场景。

[1] 团队空间

ModelWhale 提供了团队的共享视图，可以灵活地对各类研究课题、算法项目、分析任务，进行分工拆解、任务分配、数据接入、资源分配、进度监控、成果验收、成果复用等项目管理工作。

同时为有教学和培训需求的团队提供了教学评一体的课程模块，整合了教学内容管理、课程管理、作业评测系统，有效提高了教师的工作效率，改善了教学管理的质量，促进了学生对数据分析实战的参与性和积极性。

团队数据、代码、项目等资料可沉淀在共享知识库中，并轻松接入官方预置实战案例及外部丰富的案例资源。

[2] 组织管理

ModelWhale 可实现统一高效的数据管理和资源调度。

(1) 数据管理

ModelWhale 始终保障数据安全，对多数据源类型进行统一管理，各环节具有严格的权限控制。管理员可以控制和分配数据库的访问权限，每个数据集都有独立的权限管理、文档管理。结构化数据可自动解析统计性描述，提供数据文档记录数据字典与背景信息，帮助用户在使用前快速了解数据。数据可一键挂载到不同的研究项目、关联到团队知识库中，便于管理具体研究协作中的数据使用情况。

(2) 算力管理

ModelWhale 以云计算能力为基础，自主研发了高可用的算力调度器，具备按需计算、弹性扩容的优势，从而可以支持从1个用户到数千个用户的低成本、高效率地快速拓展，也可满足大规模分布式的模型训练需求。

ModelWhale 同时提供了对单个成员的资源用量监控，在项目开展前后可以有效规划资源、保障计算资源的合理分配使用。企业机构无需提前进行资源容量规划，资源成本有效降低，不再为闲置资源付费。

低代码、拖拽式编程

低代码是什么？

低代码是基于可视化和模型驱动理念，让不懂代码的人，直接使用经封装的常用机器学习算法组件，通过“拖拉拽”组件，完成应用模型的搭建。

ModelWhale Canvas 基于这种低代码范式，结合云原生与多端体验技术，在多数业务场景下实现大幅度的提效降本，为团队协作提供了一种全新的高生产力开发范式。运用 Canvas：

• 不需要写很多代码，对于纯业务侧、低代码能力的科研人员通过可视化的图形连接就能构建研究框架和模型雏形。
• 结果可以一键导出 Notebook，组件直接转化为代码，确保可复现性的同时，支持在基础的分析框架上进行更精细的建模工作，方便数据科学家等进一步优化。
• 技术人员可以在 Canvas 里面预构建模型组件和封装常用工作流 Flow，方便业务人员直接套用。
• 技术人员可以根据分析需求编写自定义组件，优化组件内容结构，提升组件能力上限。

为什么要用低代码？

1. 可视化模型驱动数据研究

低代码提供了新的交互形式：可视化的图形组件。可视化的模型是业务和技术共享的视觉语言，无差别无二义性，为业务人员搭建模型和数据研究人员优化模型带来了沟通的桥梁。双方基于可视化的图形组件：

• 业务专家可以向开发人员展示业务的主要需求和难点，便于数据科学家熟悉和理解业务架构。
• 数据科学家可以向业务专家演示一些常见的或者创新的解决方案，方便业务人员调整业务逻辑。

2. 低代码拖拽改善协作方式

按照传统的模式，在实际的数据工作中，业务部门只能描述需求，开发人员又不熟悉业务，项目上线通常需要耗费大量时间才能开发完成，这会影响业务创新的进程。低代码可以有效促进业务人员和数据科学家、IT人员之间的协作，突出了协作中的敏捷开发理念和数据科学实践的结合。业务人员更接近生产，并且不影响原本生产环境的安全性、可扩展性和长期可维护性。使用低代码、拖拽式编程：

• 业务人员可以快速搭建出模型，同时可以一边试用模型，一边与数据科学家进行探讨，找到思路差异的部分；
• 数据科学家也可以轻易将模型组件转化为代码，一边优化完善，一边与业务人员确认。

使用这种敏捷开发模式，数据建模通常可以快速推进，修改部分业务逻辑后，模型服务很快就能上线。同时，推广到各部门应用之后，会继续反馈各种开发需求，基于低代码开发的模型服务核心业务逻辑采用配置的方式实现，只需要调整参数配置就可以快速的响应需求，并更新到正式环境。

Canvas 与 Notebook 的互补与转换

同样是基于云端平台的基础架构和功能延拓，Canvas 与 Notebook 之间不止是分析建模方式的不同，更重要地是协同方式的互补与转换。ModelWhale 针对不同场景的数据团队，提供不同的工作方式，支持以项目为主体来管理实际的研究。项目内提供不同角色不同工作流下的协作功能。包括 Notebook 的代码级协作、Notebook 的常用代码封装组件、Canvas 拖拉拽分析建模、Canvas 结果与 Notebook 的转化。

• Canvas 专注于数据建模和业务逻辑实现，重点关注的是模型框架而不是具体编程。对于业务人员、领域专家来说，采用图形化的拖拽操作就可以完成简单的模型构建，表现业务逻辑和领域经验；
• Notebook 注重研究思路的记录，关注数据科学本身。对于代码优先的数据科学家、IT人员，可以直接在 Notebook 中编写代码、探索创作，并可将常用的代码封装为 Canvas 组件便于业务人员的直接调取使用；也可以选择在 Canvas 低代码界面编写代码、自定义组件来实现功能，或通过 Canvas 一键转换为 Notebook 延续 Notebook 的代码编写习惯直接优化代码。

ModelWhale 以人为径，助力协同创新

ModelWhale 以人为径，是将不同业务能力、不同技术水平的企业机构成员，当作连通解决方案的途径，助推高校、企业、机构的人才赋能，改进工作流程，改善共享与协作方式，回应业务痛点，达成研究目标，实现创新价值。

海量数据挖掘、数据密集型研究的应用范式

很多行业的数据私密性很高，数据量庞大，而大部分数据研究平台的基础设施不足以支撑大型高并发GPU运算需求，研究人员的算法环境也不近相同。在实际数据挖掘分析过程中会经常遇到多来源数据管理难、大规模计算调度难、数据分析环境统一难、交叉领域研究协同难等瓶颈，缺乏新的平台助推研究人员的数据建模工作以及各领域数据挖掘成果的协同与管理工作。ModelWhale 可以提供：

• 从底层架构保障数据安全，基于现有基础设施优化工作结构，提供私有化部署的云端计算平台；
• 本地计算资源有效扩容，多类型数据源与GPU集群轻松接入，实现数据和硬件资源的集约化管理和弹性调度分配，大幅度提效降本；
• 研究环境开箱即用，有效降低科研门槛，集成最新机器学习算法库，以及各领域专业工具包，即使是复杂研究项目也可多版本管理，赋能数据研究的开展；
• 为协作共享提供了新的交互形式，数据、代码、环境等研究资料一键打包共享，让跨地域、跨部门、跨团队之间的协作在云端实现。

专业性强、工程能力相对较弱的复合型分析研究者的强力支撑

业务人员大多拥有丰富的一线经验，但相对代码工程能力薄弱。目前主要依赖口口相传及业务需求分享，提出高价值的数据研究应用思路，再进一步与数据科学家、IT技术人员合作实现领域数据的分析需求，但跨角色协作传播力度有限，分析思路与研究成果难以系统化地被复现转化应用。利用 ModelWhale 的低代码、拖拽式 Canvas 可以：

• 降低科研门槛，直观地保留了业务经验：使业务人员通过拖拽式组件直接搭建工作流 Flow ，完成业务逻辑的直观体现和模型应用的雏形。
• 有效提高了信息研究的教学质量：将复杂的数据分析代码图形化简易封装、繁琐的数据分析步骤用可视化组件的连接有序展现、数据分析流程及每一步的产出结果清晰可见，再通过 Canvas 转 Notebook 代码的方式，以数据分析流程思维一一对应代码的编写，更易理解和上手代码。
• 优化跨角色的工作流程：Canvas 转化后的代码可以交由更熟悉编程的数据科学家、IT人员进一步优化，进行精细化调整。

从而强力支撑：

• 面向业务人员、领域专家的数据分析教学、培训、应用，让不同学科背景下编程能力较弱的非专业级数据科学家、复合型分析研究者掌握独立自主的数据分析能力；
• 同时满足数据分析部门和业务部门的不同技术水平的需求，为业务人员与数据科学家、IT技术人员的有效沟通协作建立了桥梁，实现了复杂研究领域的跨角色协同工作。

结尾

ModelWhale 数据科学平台所提供的，不论是 Jupyter Notebook 交互式编程，还是低代码拖拽式编程，都是为了协助不同角色、不同编程能力的用户能够更流畅高效地进行分析建模及项目协作。ModelWhale 不仅可以云端即开即用，同时还支持本地私有化部署，满足企业、高校、科研机构、政府机构不同应用场景下多样化的研究及业务需求。

可以肯定的是，数据科学平台会随着数据研究壁垒的逐渐降低，企业机构以数据为导向的决策需求的不断推进，云端数据分析工具的不断发展，更加重视可扩展性、强调用户体验、重视非专业级数据科学家、重视团队协同创新的场景，尤其是借助低代码拖拽式工具实现的自动建模，数据科学平台将会更先进和完善，甚至可以成为一种更低门槛、更强交互、可广泛培训的工具技能。