实时通信方法、代理装置、客户端及服务器端

技术领域

本公开属于计算机技术领域，具体涉及一种实时通信方法、代理装置、客户端及服务器端。

背景技术

现有技术中客户端与服务器端之间的实时通信存在着一些问题，例如需要使用多个不同的技术和工具进行整合和协作，这需要耗费大量的时间和精力，同时容易出现兼容性和稳定性等问题。此外，在现有技术中对于客户端与服务器端之间的通信往往需要进行定制化开发，对技术人员的要求较高，不够灵活。

发明内容

本发明旨在至少解决现有技术中存在的技术问题之一，提供一种灵活高效的实时通信方法、代理装置、客户端及服务端。

第一方面，解决本发明技术问题所采用的技术方案是一种实时通信方法，所述方法应用于代理端，其特征在于，所述方法包括：

基于WebSocket协议获取客户端消息，所述客户端消息为第一语句；

对所述客户端消息进行处理，并生成代码段，所述代码段为第二语句；

将所述代码段发送给服务器端运行，接收所述服务器端的运行结果，并将所述运行结果发送至所述客户端。

在一些实施例中，所述对所述客户端消息进行处理，并生成代码段，包括：

解析所述客户端消息；

响应于所述客户端消息符合预设规则，对解析后的所述客户端消息进行操作；

基于操作结果将所述客户端消息从第一语句转换成第二语句，并生成代码段。

在一些实施例中，所述将所述运行结果发送至所述客户端，包括：

对所述运行结果进行过滤、处理，得到响应消息，并将所述响应消息进行转换，将转换后的响应消息发送至客户端。

在一些实施例中，所述客户端消息包括source表和sink表，所述基于WebSocket协议获取客户端消息包括：

基于实时流数据创建source表，并基于离线数据库数据创建sink表；

获取所述source表和所述sink表。

在一些实施例中，所述source表包括数据源、端口号、用户名和密码中的一个或多个；

所述sink表包括包括数据源、端口号、用户名和密码中的一个或多个。

在一些实施例中，所述source表为kafka表；所述sink表为PostgreSQL、SQLServer、Oracle、ClickHouse、Hana、Mongo、Redis、ElasticSearch中的一种。

在一些实施例中，所述将所述代码段发送给服务器端运行，包括：

将所述代码段发送给服务器端，以使所述服务器端基于PyFlink技术执行所述代码段，其中，所述代码段包括第二语句形式的source表和所述sink表。

在一些实施例中，所述将所述代码段发送给服务器端运行，包括：

将所述代码段发送给服务器端，以使所述服务器端基于local模式运行或所述服务器端基于yarn模式运行。

在一些实施例中，所述第一语句为SQL语句，所述第二语句为python语句。

第二方面，本公开实施例提供一种实时通信方法，所述方法应用于客户端，所述方法包括：

基于WebSocket协议将客户端消息发送给代理端，以使所述代理端对所述客户端消息进行处理，并生成代码段，其中，所述客户端消息为第一语句，所述代码段为第二语句；

接收所述代理端反馈的运行结果，其中，所述运行结果为服务器端运行所述代码段的结果。

在一些实施例中，所述客户端消息包括source表和sink表，所述基于WebSocket协议将客户端消息发送给代理端，包括：

基于实时流数据创建source表，并基于离线数据库数据创建sink表；

将所述source表和所述sink表发送给所述代理端。

第三方面，本公开实施例提供一种实时通信的方法，所述方法应用于服务器端，所述方法包括：

运行代理端发送的代码段，并将运行结果发送给代理端，以使代理端将所述运行结果发送给客户端；其中，

所述代码段由所述代理端对接收的客户端发送的客户消息进行处理后生成的，且所述客户端消息为第一语句，所述代码段为第二语句。

在一些实施例中，所述运行代理端发送的代码段，包括：

基于PyFlink技术执行所述代码段，其中，所述代码段包括第二语句形式的source表和所述sink表。

在一些实施例中，所述运行代理端发送的代码段，包括：

基于local模式运行所述代码段；或

所述服务器端基于yarn模式运行所述代码段。

在一些实施例中，所述方法还包括：

将所述运行结果在显示区进行显示。

第四方面，本公开实施例提供一种代理装置，所述装置包括：

获取单元，用于基于WebSocket协议获取客户端消息，所述客户端消息为第一语句；

处理单元，用于对所述客户端消息进行处理，并生成代码段，所述代码段为第二语句；

发送单元，用于将所述代码段发送给服务器端运行，接收所述服务器端的运行结果并将所述运行结果通过发送至所述客户端。

第五方面，本公开实施例提供一种客户端，所述客户端包括：

发送单元，用于基于WebSocket协议将客户端消息发送给代理端，以使所述代理端对所述客户端消息进行处理，并生成代码段，其中，所述客户端消息为第一语句，所述代码段为第二语句；

接收单元，用于接收所述代理端反馈的运行结果，其中，所述运行结果为服务器端运行所述代码段的运行结果。

第六方面，本公开实施例提供一种服务器端，所述服务器端包括：

运行单元，用于运行代理端发送的代码段；

发送单元，用于将运行结果发送给代理端，以使代理端将所述运行结果发送给客户端；其中，

所述代码段为所述代理端对接收的客户端发送的客户消息进行处理后生成的，且所述客户端消息为第一语句，所述代码段为第二语句。

附图说明

图1为本公开实施例提供的一种基于代理端实现客户端与服务器端实时通信的示意图；

图2为本公开实施例提供的一种实时通信的方法流程图，该方法应用于代理端；

图3为本公开实施例提供的一种实时数据处理的示意图；

图4a为本公开实施例提供的一种创建source表的示意图；

图4b为本公开实施例提供的一种创建sink表的示意图；

图4c为本公开实施例提供的一种将source表插入sink表的示意图；

图5为本公开实施例提供的一种代理装置框图；

图6a为本公开实施例提供的一种处理单元的结构框图；

图6b为本公开实施例提供的又一种处理单元的结构框图。

具体实施方式

为使本领域技术人员更好地理解本发明的技术方案，下面结合附图和具体实施方式对本发明作进一步详细描述。

除非另外定义，本公开使用的技术术语或者科学术语应当为本公开所属领域内具有一般技能的人士所理解的通常意义。本公开中使用的“第一”、“第二”以及类似的词语并不表示任何顺序、数量或者重要性，而只是用来区分不同的组成部分。同样，“一个”、“一”或者“该”等类似词语也不表示数量限制，而是表示存在至少一个。“包括”或者“包含”等类似的词语意指出现该词前面的元件或者物件涵盖出现在该词后面列举的元件或者物件及其等同，而不排除其他元件或者物件。“连接”或者“相连”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电性的连接，不管是直接的还是间接的。“上”、“下”、“左”、“右”等仅用于表示相对位置关系，当被描述对象的绝对位置改变后，则该相对位置关系也可能相应地改变。

首先介绍本公开中涉及到的实时通信技术。

WebSocket技术：WebSocket技术是一种基于TCP协议的全双工通信协议，可以实现客户端和服务端之间的实时通信。

Jupyter Notebook技术：Jupyter Notebook是一种基于Web的交互式计算环境，可以用于编写、运行和共享代码。

PyFlink技术：PyFlink是Apache Flink的Python API，可以用于实时数据处理和流式计算。

Kafka技术：Kafka是一个分布式流数据处理平台，可以用于处理大规模的实时数据流。

在实际应用场景中，为了能更好的处理实时通信、低延迟、断线重连、跨平台等问题，一般基于WebSocket技术实现客户端与服务端之间的实时通信。然而，在现有技术中，基于WebSocket技术的通信往往也需要技术人员提前准备好客户端与服务器端所需的通信数据，然后再通过WebSocket技术实现客户端与服务端之间的实时通信。这种通信方法需要使用多个不同的技术和工具进行整合和协作，消耗大量的时间与精力。针对现有技术中存在的问题，本公开实施例提供一种实时通信方法。

图1为本公开实施例提供的一种基于代理端实现客户端与服务器端实时通信的示意图。图2为本公开实施例提供的一种实时通信的方法流程图，该方法应用于代理端。如图1-图2所示，该实时通信方法包括：

S101：基于WebSocket协议获取客户端消息，其中，客户端消息为第一语句。

S102：对客户端消息进行处理，并生成代码段，代码段为第二语句。

S103：将代码段发送给服务器端运行，接收服务器端的运行结果，并将运行结果发送至客户端。

其中，代理端P1指的是基于代理WebSocket协议提供WebSocket服务的程序。其中，代理端可以为可执行二进制的程序，也可以是一个应用程序(APP)，本公开对代理端P1的形式不做限定，只要可以基于WebSocket协议提供WebSocket服务即可。

在基于代理端实现客户端与服务器端S1的实时通信过程中，首先，开发一个应用程序作为代理端P1，用于提供WebSocket代理服务。代理端P1将为客户端和服务器端S1提供消息处理和代理功能，并在一台计算机PC或服务器上部署。然后部署服务器端S1，以便接收并处理代理端P1发送的代理消息。

具体地，当客户端需要发送消息给服务器端S1时，客户端通过WebSocket协议与代理端P1建立连接，以将客户端消息发送给代理端P1，客户端还可以接收代理端P1返回的运行结果。如果客户端与代理端P1建立连接失败，则直接将连接失败的信息返回给客户端。同理，代理端P1与服务器端S1也通过WebSocket协议建立WebSocket连接，以将代理端P1生成代码段发送给服务器S1端运行，代理端P1还可以接收服务器端S1的运行结果，并将运行结果发送给客户端。如果代理端P1与服务器端S1建立连接失败，则直接将连接失败的信息返回给代理端P1，并断开客户端与代理端P1之间的WebSocket连接。

如果客户端与代理端P1、代理端P1与服务器端S1均建立连接成功，则表示客户端、代理端P1和服务器端S1均处于正常状态。此时，客户端和服务器端S1可以完成消息双向通信。在这个过程中，客户端基于WebSocket协议将客户端消息发送给代理端P1，其中，该客户端消息为第一语句，即为客户端原始的消息类型，并未进行过处理。代理端P1对接收到的客户端消息进行处理，处理为服务器S1端可以直接识别的消息类型，并生成代码段发送给服务器端S1运行。其中代码段为第二语句，即为服务器端S1可以直接识别并运行的消息类型。代理端P1接收到服务器端S1的运行结果后对该运行结果进行处理，并将处理后的结果转达给客户端。需要说明的是，在这个过程中，如果客户端或者服务器端S1的任何一方出现服务中止异常时，则会通知另一方断开连接。

本公开提供的实时通信方法可以用于金融、物流、医疗、园区等多个领域，具体不仅可以用于处理实时数据处理，例如实时数据的获取、下载等；还可以用于实时信息的处理，例如聊天等；本公开实施例不限制具体的应用于场景。本公开实施例提供的通信方法，应用于代理端P1，该代理端P1通过对获取的客户端消息进行处理，生成可以直接被服务器端S1识别运行的代码段。这样，在客户端与服务器端S1进行通信时无需额外的第三方工具及繁琐的其他技术将客户端消息进行整合协作，可以仅仅通过代理端P1实现。进一步，对应的技术人员也无需了解第三方工具及其他技术对应的专业知识，只需要掌握客户端输入的客户端消息对应的技术即可，也就是只需要掌握第一语句对应的专业技术即可。该实时通信方法不仅可以适应不同的数据处理需求，提高了开发效率，而且降低了使用的门槛，提高了用户的使用效率，是一种灵活高效的处理开发方式，使得用户可以根据不同需求自由选择数据源和处理方式，从而提高了效率和易用性。

在一些实施例中，步骤S102对客户端消息进行处理，并生成代码段，包括以下步骤：

S11：解析客户端消息。

S12：响应于客户端消息符合预设规则，对解析后的客户端消息进行操作。

S13：根据操作结果将客户端消息从第一语句转换成第二语句，并生成代码段。

具体地，代理端P1在接收到客户端发送的客户端消息后，首先对该客户端消息进行解析，来验证该客户端消息是否内容正确，是否符合预设的格式要求。其中，预设的格式要求可以为文件格式。例如，客户端与服务端S1传输文件的格式可以为json格式、xml格式等或者未其他预设的格式，每种文件格式都有一个固定的规范，只有符合该规范后续才能继续对该客户端消息进行解析处理等。当解析的结果发现异常时，例如客户端消息不符合预设的规则，则代理端P1会向客户端返回错误消息。当客户端消息符合预设规则时，代理端P1就会对解析后的客户端消息进行进一步的操作。其中，该操作可以根据具体的应用场景具体设置。例如，当应用场景为查询数据操作时，该进一步操作可以指操作数据库，将客户端消息记录到数据库中。比如，当客户端消息为查询张三的信息，那么可以首先查询张三的信息是否存在于数据库中，如果没有存在于数据库中，进一步还可以将张三的信息记录到数据库中，以供后续服务器端S1从数据库中获取相应的信息进行运行等。客户端发送给代理端P1的客户端消息是第一语句形式的，在一些情况下，服务端S1能识别和处理的消息的第二语句形式的，因此，代理端P1在将客户端消息发送给服务端S1之前还需要进行数据转化，将客户端消息从第一语句转换成第二语句，同时生成代码段，以代码段的形式发送到服务器端S1。在数据转换的过程中，理论上不会出现异常，但是如果发生异常，代理端P1会直接断开与客户端及服务器端S1的连接。

在一些实施例中，步骤S103中将运行结果发送至客户端，包括：对运行结果进行过滤、处理，得到响应消息，并将响应消息进行转换，将转换后的响应消息发送至客户端。

具体地，客户端发送给服务器端S1的消息有些是不需要处理的，或者服务器端S1运行生成的运行结果中有些是未知的服务端消息，这时服务器端S1是不需要响应的。例如，客户端与服务器端S1之间的网络连接是不稳定的，客户端可以每隔一段时间向服务器端S1发送一个客户端消息，以确保客户端与服务器端S1之间处于连接状态。此时，服务器端S1对这类客户端消息可以不做处理。代理端P1接收到服务器端S1的运行结果后需要过滤掉不需要处理或者未知的服务器消息。如果发现异常，代理端会将接收的运行结果丢弃。如果没有发现异常，代理端P1进一步对过滤后的运行结果，也即响应消息进行处理。此处理过程与步骤S12中对解析后的所述客户端消息进行操作是对应的，具体处理步骤与具体的应用场景相关。仍以客户端消息是查询数据为例，此处理过程也可以为操作数据库步骤，具体为将服务器端S1的响应消息记录到数据库中。同样地，在此过程中，如果发现异常代理端P1会将该响应消息丢弃。最后对响应消息进行转化，转化为方便用户查看的形式。比如把字符串man转换成男，woman转换成女等等，这样客户端显示就比较明确，方便用户的查看。

在一些实施例中，在步骤S103中将运行结果发送至客户端，还包括：对服务器端S1的运行结果进行解析。此过程与步骤S11类似，此处不再重复赘述。

本公开实施例提供的实时通信方法，实现了客户端与服务器端S1之间的实时通信，有效地提高了数据处理的效率和可靠性。同时，代理端P1还具有灵活的定制化功能，可以根据具体需求进行消息处理、转换、过滤和存储等操作，具有较高的可扩展性和适应性。

在一些实施例中，客户端消息包括source表和sink表，步骤S101基于WebSocket协议获取客户端消息包括：基于实时流数据创建source表，并基于离线数据库数据创建sink表；获取该source表和该sink表。

具体地，该实时通信方法在应用于实时数据处理中时，服务器端S1不能直接对实时流数据进行处理，因此需要首先将实时流数据转化为离线的数据库数据，然后服务器端S1直接访问离线的数据库数据。本公开实施例提供了一种灵活高效的流处理开发方式，部署在服务器端，用于进行实时数据处理和流式计算，将实时流数据转换为离线数据库数据。其中，本公开实施例中服务器端在执行代码时必须指定source表和sink表才能工作。source表用于表征源数据的信息，sink表用于表征目标数据源的信息。需要说明的是，离线数据库中的数据和实时数据中的数据相同，只是形式不同。

现有技术往往需要进行定制化开发，对技术人员的要求较高，不够灵活。相比之下，本公开通过将客户端消息以source表和sink表的形式发送给代理端处理，提供了一种灵活高效的流处理开发方式，使得用户可以根据不同需求自由选择数据源和处理方式，从而提高了效率和易用性。

可以理解的是客户端消息发送给代理端的形式除了上述提到的source表和sink表，还可以针对该客户端消息的技术功能以其他形式传输，该技术功能如文件转换、服务监控、上传下载等功能。

在一些实施例中，source表包括数据源、端口号、用户名和密码中的一个或多个；sink表包括包括数据源、端口号、用户名和密码中的一个或多个。

在一些实施例中，实时流数据可以通过Kafka技术得到，source表为kafka表。

在一些实施例中，sink表可以配置为各种关系或者非关系型的离线的数据库，sink表为PostgreSQL、SQLServer、Oracle、ClickHouse、Hana、Mongo、Redis、ElasticSearch中的一种。

在一些实施例中，步骤S103中将代码段发送给服务器端运行，包括：将代码段发送给服务器端，以使服务器端基于PyFlink技术执行代码段，其中，代码段包括第二语句形式的source表和所述sink表。

在一些实施例中，第一语句为SQL语句，第二语句为python语句。在PyFlink技术中使用的语句是python语句。

本发明通过可视化页面和SQL语法，提供了一种灵活高效的流处理开发方式，使得用户可以根据不同需求自由选择数据源和处理方式，从而提高了效率和易用性。

在一些实施例中，服务器端S1还部署有Jupyter Notebook技术，用于基于Web的交互式计算环境编写、运行和共享代码，以运行代理端P1发送的代码段。具体可通过JupyterNotebook的WebSocket接口获取代理端P1发送的代码段进行实时运行处理。其中，JupyterNotebook天然支持WebSocket协议，并且提供了内核管理器、代码执行、实时日志输出、内核自动回收等功能，使得开发实时数据处理更加便捷，开发者可以不必过多关注基础环境。当然，在实时通信方法中也可以开发与Jupyter Notebook功能相同的定制化工具来实现相同的效果，本公开对此不做限制。

在一些实施例中，步骤S103、将代码段发送给服务器端运行，包括：将代码段发送给服务器端，以使服务器端基于local模式运行或服务器端基于yarn模式运行。

具体地，Jupyter Notebook执行代码时，可配置两种执行模式：local和yarn，其中，local模式基于本地资源运行，即部署Jupyter Notebook服务器的资源，部署简单灵活但资源受限，一般用于研发测试阶段。yarn模式基于hadoop的集群资源运行，由yarn进行资源调度，充分利用集群资源，一般用于生产阶段。

本公开实施例中，以实时数据处理场景为例，基于WebSocket协议实时处理数据，通过Jupyter Notebook的WebSocket接口实现实时处理，并通过创建和管理source表和sink表基于PyFlink技术实现与Kafka、MySQL、PostgreSQL等数据源的交互。

以园区为例，园区部署的许多摄像头设备为客户端，大数据平台为服务器端。园区中通过Kafka将摄像头设备的数据发送到大数据平台。在现有技术中，摄像头设备的数据发送到大数据平台后会被存储在ClickHouse数据库中，并通过开发人员或者是其他第三方工具将摄像头设备的数据转化为大数据平台可执行的形式，以使大数据平台使用离线计算方法进行人流量、性别、年龄、轨迹等数据的统计，计算周期为每10分钟或每小时。在这个过程中，需要开发人员具备一定的与数据处理转化的相关技能水平或者能够掌握使用第三方工具的技能，需要一定的技术门槛，对开发人员的技能水平要求较高，灵活性和可维护性较差，同时，现有技术中的计算是周期性的，并非实时计算。

而本公开提供的通信方法，由于代理端可以对摄像头设备的数据进行解析、处理、转换，代理端可以直接将摄像头设备的Kafka数据处理并转换为大数据平台可以直接运行的代码段形式，然后大数据平台可以直接对Kafka数据进行实时计算，从而产生实时的数据结果。本公开实施例提供的方案可以不再需要ClickHouse数据库，也不再需要开发人员或者是第三方工具对摄像头设备的数据进行处理转换，而且在本公开实施例中的方案中，大数据平台对数据是实时处理的，能够产生实时的数据结果，更方便用户的体验。

从客户端的角度来看，用户只需编写SQL语句，就能完成客户端功能开发。SQL语句包含数据源表source表、目标表sink表以及source表与sink表之间的连接方式，大大降低了客户端开发的成本。在实际业务开展中，用户有时需自行维护部署在本地的系统时，而用户并不像技术人员那么专业，那么此时，对于用户(即B端运维人员/可视化终端的面对者)是有极大好处的。

从服务器端的角度来看，原本需要使用ClickHouse作为中间存储，并通过通用的调度任务进行离线周期性计算(例如每10分钟或每小时)。但这种链路既冗长又无法满足实时数据处理的需求。采用本公开实施例提供的方案可以去除ClickHouse数据库，直接对从Kafka抽取的数据进行实时计算，实时将计算结果显示在终端看板上。本公开实施例还提供一种实时通信方法，该方法应用于客户端，包括：客户端基于WebSocket协议将客户端消息发送给代理端P1，以使代理端P1对客户端消息进行处理，并生成代码段，其中，客户端消息为第一语句，代码段为第二语句；客户端接收代理端P1反馈的运行结果，其中，运行结果为服务器S1端运行代码段的结果。

在一些实施例中，客户端消息包括source表和sink表，基于WebSocket协议将客户端消息发送给代理端P1，包括：基于实时流数据创建source表，并基于离线数据库数据创建sink表；将source表和sink表发送给所述代理端P1。

在该实时通信方法中的其他细节与上述应用于代理端P1的实时通信方法相同，此处不再重复赘述。

本公开实施例还提供一种实时通信方法，该方法应用于服务器端，包括：服务器端S1运行代理端P1发送的代码段，并将运行结果发送给代理端P1，以使代理端P1将运行结果发送给客户端；其中，代码段由代理端P1对接收的客户端发送的客户消息进行处理后生成的，且客户端消息为第一语句，代码段为第二语句。

在一些实施例中，服务器端S1运行代理端P1发送的代码段，包括：基于PyFlink技术执行代码段，其中，代码段包括第二语句形式的source表和sink表。

具体地，服务器端S1运行的代码段中使用了pyflink技术，当然除了包括pyflink技术，还可以包含其它技术功能，如文件转换、服务监控、上传下载等功能，本公开实施例对此不做限制。

在一些实施例中，服务器端S1运行代理端发送的代码段，包括：基于local模式运行代码段；或服务器端S1基于yarn模式运行代码段。

在一些实施例中，服务器端S1还用于将运行结果显示在显示区进行显示。

图3为本公开实施例提供的一种实时数据处理的示意图。该实施例是基于代理端实现客户端与服务器端之间的通信，本公开实施例以客户端为WEB可视化终端，代理端为WebSocket代理端，服务器端以Jupyter Notebook执行代码为例进行说明，具体过程包括：1、WEB可视化终端与WebSocket代理端创建连接。

2、WebSocket代理端与Jupyter Notebook首次连接。

3、WebSocket代理端响应Jupyter Notebook端的kerelID。

4、当1、2均没有异常时，表示WEB可视化终端、WebSocket代理及Jupyter Notebook端之间连接成功。

5、客户端消息发送。具体地，用户通过可视化前端工作区，输入SQL语句，完成source、sink表创建：以"create table"表示创建表语句，该表包括source、sink表创建表时需要指定数据源、端口号、用户名、密码等，并以”insert into”表示把source表中的数据插入到sink表中。图4a为本公开实施例提供的一种创建source表的示意图。图4b为本公开实施例提供的一种创建sink表的示意图。图4c为本公开实施例提供的一种将source表插入sink表的示意图。如图4a所示，表示创建一个数据源为kafka的表，表中有id、name、event_time三个字段，with后面是连接kafka的配置信息。如图4b所示，表示创建一个数据源为mysql的表，表中有id、name、event_time三个字段，with后面是连接mysql的配置信息。如图4c所示，以”insert into”表示把source表中的数据插入到sink表中。然后用户通过点“运行”，WEB可视化终端通过WebSocket将SQL语句以JSON格式发送给WebSocket代理端。

6、WebSocket代理端发送代码段给Jupyter Notebook端。

具体地，WebSocket代理端接收到客户端消息后，WebSocket代理端完成以下操作：

61、解析客户端消息，以验证用户输入的SQL语句是否符合JSON格式的规则。如果SQL语句不符合JSON格式的规则，直接返回错误信息并提示用户重新输入。如果SQL语句符合JSON格式的规则，WebSocket代理端可以通过"；"号将用户输入的SQL语句切割成多个SQL语句；对每个SQL语句进行处理，转换；

62、生成Jupyter Notebook可执行的代码段；

63、根据生成的代码段生成客户端日志。

7、Jupyter Notebook运行代码段，生成运行结果。具体地，Jupyter Notebook执行代码时，可配置两种执行模式：local和yarn。其中，local模式基于本地资源运行，即部署Jupyter Notebook服务器的资源，部署简单灵活但资源受限，一般用于研发测试阶段。yarn模式基于hadoop的集群资源运行，由yarn进行资源调度，充分利用集群资源，一般用于生产阶段。

8、Jupyter Notebook将第一运行结果发送给WebSocket代理端。具体地，JupyterNotebook可能会对一次客户端消息分多次输出，每次输出都会通过WebSocket代理端响应给客户端。

9、WebSocket代理端将第一响应消息发送给客户端。具体地，包括以下步骤：

91、对第一运行结果进行解析、处理、转换生成第一响应消息。

92、生成服务器端日志。

10、Jupyter Notebook将第二运行结果发送给WebSocket代理端。

11、WebSocket代理端将第二响应消息发送给客户端。

本公开实施例中，通过以上步骤，可以实现基于WebSocket实时处理数据流的方案，该方案具有实时性和可扩展性，支持从Kafka中读取、修改数据，并将数据写入指定的数据源中。同时，通过可视化操作界面和代理服务的协同作用，用户可以方便地进行实时数据处理任务的创建、启动、调试和停止。

本公开实施例还提供一种代理装置。图5为本公开实施例提供的一种代理装置框图，包括获取单元51、处理单元52及发送单元53，其中，获取单元51用于基于WebSocket协议获取客户端消息，客户端消息为第一语句。处理单元52用于对客户端消息进行处理，并生成代码段，代码段为第二语句。发送单元53用于将代码段发送给服务器端运行，接收服务器端的运行结果并将运行结果通过发送至所述客户端。

图6a为本公开实施例提供的一种处理单元52的结构框图，可以用于处理客户端消息。

在一些实施例中，处理单元52包括解析器521、处理器522和转换器523，其中，解析器521用于解析客户端消息；处理器522响应于客户端消息符合预设规则，用于对解析后的客户端消息进行操作；转换器523用于基于操作结果将所述客户端消息从第一语句转换成第二语句，并生成代码段。

图6b为本公开实施例提供的又一种处理单元52的结构框图，可以用于处理服务器端的消息，与图6a对应的处理单元52相比，该处理单元52还包括过滤器524。具体地，图6b对应的处理单元在处理服务器端的消息时，解析器521用于解析服务端消息。过滤器524用于过滤不需要处理或未知的服务端消息。处理器522用于操作数据库。转换器523用于将服务端消息转换为客户端所需消息，最后发送单元将转换后的消息发送给客户端。

本公开提供的代理装置的具体细节与上述实时通信方法类似，此处不再重复赘述。

本公开实施例还提供一种客户端，具体包括发送单元、接收单元，其中，发送单元用于基于WebSocket协议将客户端消息发送给代理端，以使代理端对客户端消息进行处理，并生成代码段，其中，客户端消息为第一语句，代码段为第二语句。接收单元用于接收代理端反馈的运行结果，其中，运行结果为服务器端运行代码段的运行结果。

本公开实施例中的代理端可以为上述实施例中的代理装置。关于代理端的具体细节参见上述代理装置实施例，此处不再重复赘述。

本公开实施例还提供一种服务器端，包括运行单元和发送单元，其中，运行单元用于运行代理端发送的代码段；发送单元用于将运行结果发送给代理端，以使代理端将运行结果发送给客户端；其中，代码段为代理端对接收的客户端发送的客户消息进行处理后生成的，且客户端消息为第一语句，代码段为第二语句。

本公开实施例中的代理端可以参见上面实施例中的代理装置，客户端可以参见上面实施例中的客户端，此处不再重复赘述。

本公开提供的方案，第一方面，通过使用WebSocket、Kafka和pyflink等技术，可以实现实时数据处理，快速响应数据流中的变化。另一方面，在实时数据处理过程中，需要对数据流进行清洗、转换和聚合等操作，以便更好地满足业务需求。本方案通过使用代理端和Jupyter-Notebook，将用户输入的SQL语句转换为可执行的PyFlink代码段，并在执行过程中对数据流进行转换，实现数据流的实时处理和转换。再一方面，通过设计可视化操作界面，用户可以方便地创建、启动和停止实时数据处理任务，提高用户的操作效率和体验。同时，在代理端中监听可能产生的输出信息，并将这些信息实时展示在客户端的实时控制台中，提高了用户的交互体验。

本公开的方案通过代理端实现了客户端与服务端之间的实时通信，有效地提高了数据处理的效率和可靠性。同时，代理还具有灵活的定制化功能，可以根据具体需求进行消息处理、转换、过滤和存储等操作，具有较高的可扩展性和适应性。

可以理解的是，以上实施方式仅仅是为了说明本发明的原理而采用的示例性实施方式，然而本发明并不局限于此。对于本领域内的普通技术人员而言，在不脱离本发明的精神和实质的情况下，可以做出各种变型和改进，这些变型和改进也视为本发明的保护范围。