• 关于

    数据处理函数

    的搜索结果

回答

阿里云提供基于函数计算(Function Compute)处理数据并分发的解决方案。阿里云函数计算是一款基于Serverless架构的轻计算高弹性的产品。 使用函数计算处理数据并分发有以下优势: 便捷:函数计算与表格存储产品对接配置简便,通过控制台上简单配置即可完成产品间的数据对接。弹性:表格存储间隔1秒将更新的数据批量透传给函数计算,如果函数计算一秒内处理不完请求,函数计算会启动新的执行环境来处理后续的请求,实现自动弹性伸缩。业务逻辑:业务逻辑编写到函数计算里,处理好数据后,通过接口调用直接把数据发送给移动推送、消息通道等产品。经济:函数计算是按照触发来计费,业务低谷期的费用非常低廉,不需要额外维护一些服务环境。
剑曼红尘 2020-03-23 15:07:53 0 浏览量 回答数 0

回答

整个架构图分成 2 部分内容: Web应用:模拟一个社交内容更新和数据处理的流程,Web用户通过API网关把请求转发到函数计算进行处理,函数计算把处理后的内容更新到数据库中,并更新索引,另外一个函数计算把索引更新推送的搜索引擎供给外部客户进行检索,完成整个数据闭环处理。 智能设备:通过IoT网关把设备状态推送到函数计算处理,函数计算通过API接口把消息通过移动推送服务,推送给移动端进行状态确认和管理。 在智能设备状态处理的场景中,同样也会碰到几个核心技术问题要解决。当海量设备把状态发送到IoT平台后,如何设计一套高效非轮询的技术框架来处理设备状态数据;如何把处理后的数据高效透传其他产品,例如写数据库或者推送给移动端。 IoT设备状态场景常规做法: 设置消息通道接收事件,并编写业务代码。 购买服务器资源做后端数据处理。 开通多个产品,并调用SDK代码来完成业务交互。 维护相关硬件软件环境。 函数计算解法: 定制IoT平台的事件通知,直接把业务代码写到函数计算中。 不需要维护运行环境,用完即可释放。 控制台配置,就可以把信息透传给相关产品。 通过 2 种方式的对比,能看出函数计算的解法更具备通用性,可以大量减少维护工作。
游客pklijor6gytpx 2019-12-02 03:24:01 0 浏览量 回答数 0

问题

如何自定义ETL?

日志服务提供流式的全托管数据加工服务,您可以配置一个ETL Job,日志服务将定时生成ETL Task并触发函数执行:增量消费日志服务logstore的数据,在函数里完成自定义加工任务...
轩墨 2019-12-01 21:55:51 1872 浏览量 回答数 0

Quick BI 数据可视化分析平台

2020年入选全球Gartner ABI魔力象限,为中国首个且唯一入选BI产品

回答

“服务编排能力:可以将流程逻辑与任务执行分开,支持多种控制原语,比如顺序执行多个函数,根据函数执行结果选择执行其它函数,让多个函数并行处理数据,或者让一个函数并行处理一组数据等,以及上面的 Fan-In 模式。函数工作流还内置了错误重试和捕获能力,节省了编写编排代码的时间。
游客pklijor6gytpx 2019-12-02 03:23:30 0 浏览量 回答数 0

回答

这是一个非常典型的解决方案, 对象存储 OSS 可以支持海量视频存储,采集上传的视频被转码以适配各种终端,CDN 加速终端设备播放视频的速度。此外还有一些内容安全审查需求, 比如鉴黄、鉴恐等。 而在视频点播解决方案中, 视频转码是最消耗计算力的一个子系统,虽然您可以使用云上专门的转码服务,但在很多情况下,您会选择自己搭建转码服务。比如: 您已经在虚拟机/容器平台上基于 FFmpeg 部署了一套视频处理服务,能否在此基础上让它更弹性,更高的可用性? 您的需求只是简单的转码需求,或是一些极其轻量的需求,比如获取 OSS 上视频前几帧的 GIF、获取视频或者音频的时长,自己搭建成本更低。 各种格式的音频转换或者各种采样率自定义、音频降噪等功能 您有更高级的自定义处理需求,比如视频转码完成后, 需要记录转码详情到数据库, 或者在转码完成后, 自动将热度很高的视频预热到 CDN 上, 从而缓解源站压力。 您有并发处理大量视频的需求。 自定义视频处理流程中可能会有多种操作组合, 比如转码、加水印和生成视频首页 GIF。后续为视频处理系统增加新需求,比如调整转码参数,希望新功能发布上线对在线服务无影响。 您的视频源文件存放在 NAS 或者 ECS 云盘上,自建服务可以直接读取源文件处理,而不需要将它们再迁移到 OSS 上。 如果您的视频处理系统有上述需求,或者您期望实现一个 弹性、高可用、低成本、免运维、灵活支持任意处理逻辑 的视频处理系统,那么本文则是您期待的最佳实践方案。 Serverless 自定义视频处理 在介绍具体方案之前, 先介绍两款产品: 函数计算 :阿里云函数计算是事件驱动的全托管计算服务。通过函数计算,您无需管理服务器等基础设施,只需编写代码并上传。函数计算会为您准备好计算资源,以弹性、可靠的方式运行您的代码,并提供日志查询、性能监控、报警等功能。 函数工作流:函数工作流(Function Flow,以下简称 FnF)是一个用来协调多个分布式任务执行的全托管云服务。您可以用顺序,分支,并行等方式来编排分布式任务,FnF 会按照设定好的步骤可靠地协调任务执行,跟踪每个任务的状态转换,并在必要时执行用户定义的重试逻辑,以确保工作流顺利完成。 免费开通函数计算,按量付费,函数计算有很大的免费额度。 免费开通函数工作流,按量付费,函数工作流有很大的免费额度。 函数计算可靠的执行任意逻辑, 逻辑可以是利用 FFmpeg 对视频任何处理操作, 也可以更新视频 meta 数据到数据库等。 函数工作流对相应的函数进行编排, 比如第一步的函数是转码, 第二步的函数是转码成功后,将相应 meta 数据库写入数据库等。 至此,您应该初步理解了函数计算的自定义处理能力 + 函数工作流编排能力几乎满足您任何自定义处理的需求,接下来,本文以一个具体的示例展示基于函数计算和函数工作流打造的一个弹性高可用的 Serverless 视频处理系统,并与传统方案进行性能、成本和工程效率的对比。 简单视频处理系统 假设您是对短视频进行简单的处理, 架构方案图如下: 如上图所示, 用户上传一个视频到 OSS, OSS 触发器自动触发函数执行, 函数调用 FFmpeg 进行视频转码, 并且将转码后的视频保存回 OSS。 OSS 事件触发器, 阿里云对象存储和函数计算无缝集成。您可以为各种类型的事件设置处理函数,当 OSS 系统捕获到指定类型的事件后,会自动调用函数处理。例如,您可以设置函数来处理 PutObject 事件,当您调用 OSS PutObject API 上传视频到 OSS 后,相关联的函数会自动触发来处理该视频。 简单视频处理系统示例工程地址 您可以直接基于示例工程部署您的简单视频处理系统服务, 但是当您想要处理大视频(比如 test_huge.mov ) 或者对小视频进行多种组合操作的时候, 您会发现函数很大概率会执行失败,原因是函数计算的执行环境存在一些限制, 比如最大执行时间为 10 分钟, 最大内存为 3G。 为了突破函数计算执行环境的限制,引入函数工作流 FnF 去编排函数实现一个功能强大的全功能视频处理系统。 全功能视频处理系统 如上图所示, 假设用户上传一个 mov 格式的视频到 OSS,OSS 触发器自动触发函数执行, 函数调用 FnF,并行进行提取音频文件,同时进行 avi,mp4,flv 格式的转码。 所以您可以实现如下需求: 一个视频文件可以同时被转码成各种格式以及其他各种自定义处理,比如增加水印处理或者在 after-process 更新信息到数据库等。 当有多个文件同时上传到 OSS,函数计算会自动伸缩, 并行处理多个文件。 对于每一个视频,先进行切片处理,然后并行转码切片,最后合成,通过设置合理的切片时间,可以大大加速较大视频的转码速度。 所谓的视频切片,是将视频流按指定的时间间隔,切分成一系列分片文件,并生成一个索引文件记录分片文件的信息 结合 NAS + 视频切片, 可以解决超大视频(大于 3G )的转码。 全功能视频处理系统示例工程地址
保持可爱mmm 2020-04-15 23:08:12 0 浏览量 回答数 0

回答

楼主这是节点遍历时,通过函数指针动态加载节点处理函数的设计方法。这个几年前写过,后来不这么写了。主要有以下几个问题。 1、每个节点被访问时,操作可能不一样,通用的函数指针的入口参数,要么可变参,要么多套,入口指针,都是很繁琐的事情,把代码逻辑结构搞的会更复杂。 2、操作函数和操作对象没有绑定,这个在规模开发时,很容易引起混乱。这样设计的代码,我自己到后面都觉得混乱,更别说基于我的架子让别人开发,楼主你的例子不够复杂可能感觉不到。 3、上面两个问题,也导致,代码复用率不高。 现在我的设计思想,如果是基础的数据结构,如同你这个例子中就是个线形表,我都全部独立成模版,在头文件中。 特定数据的处理不会和处理方法绑定,而是调用不同通用模块来处理,这样是尽可能的让数据和处理松耦合。而关联数据再怎么关联,处理时,也是一类整体处理的,同时一批数据再怎么复合,总可以拆成不同大部分串联处理(例如,读取、处理、写出,通过增加cache的方式可以分批分步骤完成,而不是读、处理、写 、一个完整操作周期,仅针对一个单元)。所以这类数据的整体处理落在通用模块里,通过数据和处理的紧耦合的提升效率。 ###### 另外,补充说一下,楼主的函数式风格,和我的函数式风格理解相差颇大。我的理解如下,所谓函数式风格,是将一批数据的若干处理,分解为正交串接的多个子步骤,每个步骤都是对整体数据的某个操作的实现。楼主的方案实质是对一个处理,可以挂接不同的操作方法。 我的理解函数式的风格在于每个独立模块处理极少的有逻辑关联的操作,可以看作针对一个数据池的原子操作。依次将数据池的数据灌入不同的独立模块,实现数据处理。当然差异的模块调用顺序和不同处理模块的组合,可以有不同的效果。 但无论如何,都是函数与数据松耦合的设计。这个和面向对象是反过来的。 ######相互嵌套耦合,牵一发动全身######楼主的代码有很浓重的其他语言的味道######楼主文章不错,我看现在的C模块基本就是你所说的面向对象风格,其实就是用数据结构组织起来。###### 引用来自“中山野鬼”的答案 楼主这是节点遍历时,通过函数指针动态加载节点处理函数的设计方法。这个几年前写过,后来不这么写了。主要有以下几个问题。 1、每个节点被访问时,操作可能不一样,通用的函数指针的入口参数,要么可变参,要么多套,入口指针,都是很繁琐的事情,把代码逻辑结构搞的会更复杂。 2、操作函数和操作对象没有绑定,这个在规模开发时,很容易引起混乱。这样设计的代码,我自己到后面都觉得混乱,更别说基于我的架子让别人开发,楼主你的例子不够复杂可能感觉不到。 3、上面两个问题,也导致,代码复用率不高。 现在我的设计思想,如果是基础的数据结构,如同你这个例子中就是个线形表,我都全部独立成模版,在头文件中。 特定数据的处理不会和处理方法绑定,而是调用不同通用模块来处理,这样是尽可能的让数据和处理松耦合。而关联数据再怎么关联,处理时,也是一类整体处理的,同时一批数据再怎么复合,总可以拆成不同大部分串联处理(例如,读取、处理、写出,通过增加cache的方式可以分批分步骤完成,而不是读、处理、写 、一个完整操作周期,仅针对一个单元)。所以这类数据的整体处理落在通用模块里,通过数据和处理的紧耦合的提升效率。 你说的问题#1和文章中函数式风格一节抱怨employee_read无法和Callback兼容的问题是类似的,说到底就是因为C语言静态类型等语法特性导致了对函数式风格支持不好;同时也反向说明了为什么大多数支持函数式风格的语言会选择“动态类型”,并且支持灵活的可变个数参数等特性,都是为了辅助函数式风格的编码。 #2这一点我不太同意。C语言里虽然没有类的概念把数据和函数在语法层次上绑定在一起,但通过规范地命令提供隐喻,比如代码中,所有操作Employee对象的函数都以employee_前缀开头。而且,这些接口之间也有层级关系,符合下表描述的抽象屏障。如果你把Employee相关的声明、操作独立出来放在一个文件里,然后头文件里只放置公开的接口信息,这样就变得简洁多了。 最高层:使用API的程序 main 基于Employee的接口实现的高级操作 employee_print, employee_adjust_salary 基于最底层的C,对象Employee的最基础的操作,包括读入、释放、遍历等 employee_read, employee_free, foreach, with_open_file C语言本身提供的最底层的工具 struct Empoloyee, for, free, calloc... 例如C语言自带的操作文件的接口同样符合这样的抽象屏障:我们只需要使用fopen、fclose、fread、fwrite等一系列操作FILE对象的接口,无需关心FILE结构体里有些什么内容,表示什么意思,以及各个接口是怎么实现的。 #3的确是一个问题,而且我在文章里也可以没有提及,因为这不是这篇文章要表达的重点。它最本质的问题在于将集合的数据结构和单个对象的信息保存在同一个地方。其他语言,例如Java的java.util.*容器、C++的STL容器,都符合你的设计,将容器这个单一职责抽象出来。当然,我自己实际的工作也是这样做的。 ###### 引用来自“中山野鬼”的答案 另外,补充说一下,楼主的函数式风格,和我的函数式风格理解相差颇大。我的理解如下,所谓函数式风格,是将一批数据的若干处理,分解为正交串接的多个子步骤,每个步骤都是对整体数据的某个操作的实现。楼主的方案实质是对一个处理,可以挂接不同的操作方法。 我的理解函数式的风格在于每个独立模块处理极少的有逻辑关联的操作,可以看作针对一个数据池的原子操作。依次将数据池的数据灌入不同的独立模块,实现数据处理。当然差异的模块调用顺序和不同处理模块的组合,可以有不同的效果。 但无论如何,都是函数与数据松耦合的设计。这个和面向对象是反过来的。 我认为你说的是“责任单一原则”,让每个函数、每个模块责任都尽可能地单一,然后通过类似搭积木一样的灵活组合,完成不同的任务。就像UNIX下的命令,每个单独命令都只完成一件事情,通过管道等把这些功能单一的命令组织在一起,协作完成一个复杂的任务! 我个人认为这是一种设计思想,和源自Lambda演算的函数式风格并没有太大关系。 ###### 引用来自“杨同学”的答案 楼主的代码有很浓重的其他语言的味道 因为其他语言也能写“面向对象风格”和“函数式风格”的代码,并且看起来比C更“专业”。 ###### 引用来自“优游幻世”的答案 楼主文章不错,我看现在的C模块基本就是你所说的面向对象风格,其实就是用数据结构组织起来。 嗯,将数据和操作数据的方法集中在一起会让代码更容易维护。 就像我在六楼回复里提到的,很多C模块往往还会更进一步,把容器和对象也分离开来。这样容器能容纳各种不同的对象,对象则只保留数据本身,不关心和其他对象是以什么形式组织在一起的。 ###### 引用来自“redraiment”的答案 引用来自“中山野鬼”的答案 楼主这是节点遍历时,通过函数指针动态加载节点处理函数的设计方法。这个几年前写过,后来不这么写了。主要有以下几个问题。 1、每个节点被访问时,操作可能不一样,通用的函数指针的入口参数,要么可变参,要么多套,入口指针,都是很繁琐的事情,把代码逻辑结构搞的会更复杂。 2、操作函数和操作对象没有绑定,这个在规模开发时,很容易引起混乱。这样设计的代码,我自己到后面都觉得混乱,更别说基于我的架子让别人开发,楼主你的例子不够复杂可能感觉不到。 3、上面两个问题,也导致,代码复用率不高。 现在我的设计思想,如果是基础的数据结构,如同你这个例子中就是个线形表,我都全部独立成模版,在头文件中。 特定数据的处理不会和处理方法绑定,而是调用不同通用模块来处理,这样是尽可能的让数据和处理松耦合。而关联数据再怎么关联,处理时,也是一类整体处理的,同时一批数据再怎么复合,总可以拆成不同大部分串联处理(例如,读取、处理、写出,通过增加cache的方式可以分批分步骤完成,而不是读、处理、写 、一个完整操作周期,仅针对一个单元)。所以这类数据的整体处理落在通用模块里,通过数据和处理的紧耦合的提升效率。 你说的问题#1和文章中函数式风格一节抱怨employee_read无法和Callback兼容的问题是类似的,说到底就是因为C语言静态类型等语法特性导致了对函数式风格支持不好;同时也反向说明了为什么大多数支持函数式风格的语言会选择“动态类型”,并且支持灵活的可变个数参数等特性,都是为了辅助函数式风格的编码。 #2这一点我不太同意。C语言里虽然没有类的概念把数据和函数在语法层次上绑定在一起,但通过规范地命令提供隐喻,比如代码中,所有操作Employee对象的函数都以employee_前缀开头。而且,这些接口之间也有层级关系,符合下表描述的抽象屏障。如果你把Employee相关的声明、操作独立出来放在一个文件里,然后头文件里只放置公开的接口信息,这样就变得简洁多了。 最高层:使用API的程序 main 基于Employee的接口实现的高级操作 employee_print, employee_adjust_salary 基于最底层的C,对象Employee的最基础的操作,包括读入、释放、遍历等 employee_read, employee_free, foreach, with_open_file C语言本身提供的最底层的工具 struct Empoloyee, for, free, calloc... 例如C语言自带的操作文件的接口同样符合这样的抽象屏障:我们只需要使用fopen、fclose、fread、fwrite等一系列操作FILE对象的接口,无需关心FILE结构体里有些什么内容,表示什么意思,以及各个接口是怎么实现的。 #3的确是一个问题,而且我在文章里也可以没有提及,因为这不是这篇文章要表达的重点。它最本质的问题在于将集合的数据结构和单个对象的信息保存在同一个地方。其他语言,例如Java的java.util.*容器、C++的STL容器,都符合你的设计,将容器这个单一职责抽象出来。当然,我自己实际的工作也是这样做的。 第二个问题其实是不同设计思想的核心问题。你举的例子只能说是些简单的系统中的模块。如果是个大系统中的底层模块特别是引擎方面(会产生数据加工的),这种方法最终组合出来的系统,会比面向对象出来的类套类更复杂。说实话,还不如用面相对象实现。 面向对象,是将数据和操作,进行耦合,并且封装在类里面。这种做法是有它的好处的。这样不会导致数据和操作之间出现问题。而c如果这么写,说实话还不如用c++的类进行实现,因为类描述这些逻辑更为清晰,而且语法和编译器可以帮你做大量的事情。 而相反面向数据,是一批数据(不是一个具体数据单元),存在一批不同操作。如何分析数据之间的无关性和前后操作的无关性是重点,这两个分析清楚,那么并发计算,和分步骤计算就得以实现。并发计算不谈,分步骤计算的思想就是原子操作,或者微指令集管道设计思想。这样设计,可以令复杂的数据处理,根据流程细分到步骤,每个步骤细分到子步骤单元,而每个子步骤单元只负责处理,不负责数据的格式问题。 上面这段的设计思想和面向对象是反过来的,数据和操作松耦合。数据的特殊性导致的操作,是通过各种操作模块组合调用实现(这些操作模块可以看作上面独立的子步骤单元和外部特定数据结构无关的)。 这样做的好处是,模块的设计,可以独立进行,让外部数据格式依赖自身,而不是操作对应数据格式(面向对象是后者,成员变量类型决定了成员函数的实际操作),模块复用率高,同时是整批数据处理,只要数据流程(调用不同模块的系统设计良好),运行效率会很高。而且便于并发操作。 并发操作并不单单是一批数据,分层几组让同一个操作的多个进程处理。流水线技术的使用,一样可以实现。 这里顺带喷下hadoop。貌似hadoop的map reduce并没有在流水线方面有什么突破的思路,这块需要考虑到不同计算单元之间数据流动的费用, hadoop整天扯分布计算,根本不考虑数据整体计算周期内的相关性的问题,基本上都是推给用户自己处理,而用户应该无法控制具体计算硬件设备,最后能有好效果就扯淡了。
kun坤 2020-06-09 22:08:58 0 浏览量 回答数 0

回答

楼主这是节点遍历时,通过函数指针动态加载节点处理函数的设计方法。这个几年前写过,后来不这么写了。主要有以下几个问题。 1、每个节点被访问时,操作可能不一样,通用的函数指针的入口参数,要么可变参,要么多套,入口指针,都是很繁琐的事情,把代码逻辑结构搞的会更复杂。 2、操作函数和操作对象没有绑定,这个在规模开发时,很容易引起混乱。这样设计的代码,我自己到后面都觉得混乱,更别说基于我的架子让别人开发,楼主你的例子不够复杂可能感觉不到。 3、上面两个问题,也导致,代码复用率不高。 现在我的设计思想,如果是基础的数据结构,如同你这个例子中就是个线形表,我都全部独立成模版,在头文件中。 特定数据的处理不会和处理方法绑定,而是调用不同通用模块来处理,这样是尽可能的让数据和处理松耦合。而关联数据再怎么关联,处理时,也是一类整体处理的,同时一批数据再怎么复合,总可以拆成不同大部分串联处理(例如,读取、处理、写出,通过增加cache的方式可以分批分步骤完成,而不是读、处理、写 、一个完整操作周期,仅针对一个单元)。所以这类数据的整体处理落在通用模块里,通过数据和处理的紧耦合的提升效率。 ###### 另外,补充说一下,楼主的函数式风格,和我的函数式风格理解相差颇大。我的理解如下,所谓函数式风格,是将一批数据的若干处理,分解为正交串接的多个子步骤,每个步骤都是对整体数据的某个操作的实现。楼主的方案实质是对一个处理,可以挂接不同的操作方法。 我的理解函数式的风格在于每个独立模块处理极少的有逻辑关联的操作,可以看作针对一个数据池的原子操作。依次将数据池的数据灌入不同的独立模块,实现数据处理。当然差异的模块调用顺序和不同处理模块的组合,可以有不同的效果。 但无论如何,都是函数与数据松耦合的设计。这个和面向对象是反过来的。 ######相互嵌套耦合,牵一发动全身######楼主的代码有很浓重的其他语言的味道######楼主文章不错,我看现在的C模块基本就是你所说的面向对象风格,其实就是用数据结构组织起来。###### 引用来自“中山野鬼”的答案 楼主这是节点遍历时,通过函数指针动态加载节点处理函数的设计方法。这个几年前写过,后来不这么写了。主要有以下几个问题。 1、每个节点被访问时,操作可能不一样,通用的函数指针的入口参数,要么可变参,要么多套,入口指针,都是很繁琐的事情,把代码逻辑结构搞的会更复杂。 2、操作函数和操作对象没有绑定,这个在规模开发时,很容易引起混乱。这样设计的代码,我自己到后面都觉得混乱,更别说基于我的架子让别人开发,楼主你的例子不够复杂可能感觉不到。 3、上面两个问题,也导致,代码复用率不高。 现在我的设计思想,如果是基础的数据结构,如同你这个例子中就是个线形表,我都全部独立成模版,在头文件中。 特定数据的处理不会和处理方法绑定,而是调用不同通用模块来处理,这样是尽可能的让数据和处理松耦合。而关联数据再怎么关联,处理时,也是一类整体处理的,同时一批数据再怎么复合,总可以拆成不同大部分串联处理(例如,读取、处理、写出,通过增加cache的方式可以分批分步骤完成,而不是读、处理、写 、一个完整操作周期,仅针对一个单元)。所以这类数据的整体处理落在通用模块里,通过数据和处理的紧耦合的提升效率。 你说的问题#1和文章中函数式风格一节抱怨employee_read无法和Callback兼容的问题是类似的,说到底就是因为C语言静态类型等语法特性导致了对函数式风格支持不好;同时也反向说明了为什么大多数支持函数式风格的语言会选择“动态类型”,并且支持灵活的可变个数参数等特性,都是为了辅助函数式风格的编码。 #2这一点我不太同意。C语言里虽然没有类的概念把数据和函数在语法层次上绑定在一起,但通过规范地命令提供隐喻,比如代码中,所有操作Employee对象的函数都以employee_前缀开头。而且,这些接口之间也有层级关系,符合下表描述的抽象屏障。如果你把Employee相关的声明、操作独立出来放在一个文件里,然后头文件里只放置公开的接口信息,这样就变得简洁多了。 最高层:使用API的程序 main 基于Employee的接口实现的高级操作 employee_print, employee_adjust_salary 基于最底层的C,对象Employee的最基础的操作,包括读入、释放、遍历等 employee_read, employee_free, foreach, with_open_file C语言本身提供的最底层的工具 struct Empoloyee, for, free, calloc... 例如C语言自带的操作文件的接口同样符合这样的抽象屏障:我们只需要使用fopen、fclose、fread、fwrite等一系列操作FILE对象的接口,无需关心FILE结构体里有些什么内容,表示什么意思,以及各个接口是怎么实现的。 #3的确是一个问题,而且我在文章里也可以没有提及,因为这不是这篇文章要表达的重点。它最本质的问题在于将集合的数据结构和单个对象的信息保存在同一个地方。其他语言,例如Java的java.util.*容器、C++的STL容器,都符合你的设计,将容器这个单一职责抽象出来。当然,我自己实际的工作也是这样做的。 ###### 引用来自“中山野鬼”的答案 另外,补充说一下,楼主的函数式风格,和我的函数式风格理解相差颇大。我的理解如下,所谓函数式风格,是将一批数据的若干处理,分解为正交串接的多个子步骤,每个步骤都是对整体数据的某个操作的实现。楼主的方案实质是对一个处理,可以挂接不同的操作方法。 我的理解函数式的风格在于每个独立模块处理极少的有逻辑关联的操作,可以看作针对一个数据池的原子操作。依次将数据池的数据灌入不同的独立模块,实现数据处理。当然差异的模块调用顺序和不同处理模块的组合,可以有不同的效果。 但无论如何,都是函数与数据松耦合的设计。这个和面向对象是反过来的。 我认为你说的是“责任单一原则”,让每个函数、每个模块责任都尽可能地单一,然后通过类似搭积木一样的灵活组合,完成不同的任务。就像UNIX下的命令,每个单独命令都只完成一件事情,通过管道等把这些功能单一的命令组织在一起,协作完成一个复杂的任务! 我个人认为这是一种设计思想,和源自Lambda演算的函数式风格并没有太大关系。 ###### 引用来自“杨同学”的答案 楼主的代码有很浓重的其他语言的味道 因为其他语言也能写“面向对象风格”和“函数式风格”的代码,并且看起来比C更“专业”。 ###### 引用来自“优游幻世”的答案 楼主文章不错,我看现在的C模块基本就是你所说的面向对象风格,其实就是用数据结构组织起来。 嗯,将数据和操作数据的方法集中在一起会让代码更容易维护。 就像我在六楼回复里提到的,很多C模块往往还会更进一步,把容器和对象也分离开来。这样容器能容纳各种不同的对象,对象则只保留数据本身,不关心和其他对象是以什么形式组织在一起的。 ###### 引用来自“redraiment”的答案 引用来自“中山野鬼”的答案 楼主这是节点遍历时,通过函数指针动态加载节点处理函数的设计方法。这个几年前写过,后来不这么写了。主要有以下几个问题。 1、每个节点被访问时,操作可能不一样,通用的函数指针的入口参数,要么可变参,要么多套,入口指针,都是很繁琐的事情,把代码逻辑结构搞的会更复杂。 2、操作函数和操作对象没有绑定,这个在规模开发时,很容易引起混乱。这样设计的代码,我自己到后面都觉得混乱,更别说基于我的架子让别人开发,楼主你的例子不够复杂可能感觉不到。 3、上面两个问题,也导致,代码复用率不高。 现在我的设计思想,如果是基础的数据结构,如同你这个例子中就是个线形表,我都全部独立成模版,在头文件中。 特定数据的处理不会和处理方法绑定,而是调用不同通用模块来处理,这样是尽可能的让数据和处理松耦合。而关联数据再怎么关联,处理时,也是一类整体处理的,同时一批数据再怎么复合,总可以拆成不同大部分串联处理(例如,读取、处理、写出,通过增加cache的方式可以分批分步骤完成,而不是读、处理、写 、一个完整操作周期,仅针对一个单元)。所以这类数据的整体处理落在通用模块里,通过数据和处理的紧耦合的提升效率。 你说的问题#1和文章中函数式风格一节抱怨employee_read无法和Callback兼容的问题是类似的,说到底就是因为C语言静态类型等语法特性导致了对函数式风格支持不好;同时也反向说明了为什么大多数支持函数式风格的语言会选择“动态类型”,并且支持灵活的可变个数参数等特性,都是为了辅助函数式风格的编码。 #2这一点我不太同意。C语言里虽然没有类的概念把数据和函数在语法层次上绑定在一起,但通过规范地命令提供隐喻,比如代码中,所有操作Employee对象的函数都以employee_前缀开头。而且,这些接口之间也有层级关系,符合下表描述的抽象屏障。如果你把Employee相关的声明、操作独立出来放在一个文件里,然后头文件里只放置公开的接口信息,这样就变得简洁多了。 最高层:使用API的程序 main 基于Employee的接口实现的高级操作 employee_print, employee_adjust_salary 基于最底层的C,对象Employee的最基础的操作,包括读入、释放、遍历等 employee_read, employee_free, foreach, with_open_file C语言本身提供的最底层的工具 struct Empoloyee, for, free, calloc... 例如C语言自带的操作文件的接口同样符合这样的抽象屏障:我们只需要使用fopen、fclose、fread、fwrite等一系列操作FILE对象的接口,无需关心FILE结构体里有些什么内容,表示什么意思,以及各个接口是怎么实现的。 #3的确是一个问题,而且我在文章里也可以没有提及,因为这不是这篇文章要表达的重点。它最本质的问题在于将集合的数据结构和单个对象的信息保存在同一个地方。其他语言,例如Java的java.util.*容器、C++的STL容器,都符合你的设计,将容器这个单一职责抽象出来。当然,我自己实际的工作也是这样做的。 第二个问题其实是不同设计思想的核心问题。你举的例子只能说是些简单的系统中的模块。如果是个大系统中的底层模块特别是引擎方面(会产生数据加工的),这种方法最终组合出来的系统,会比面向对象出来的类套类更复杂。说实话,还不如用面相对象实现。 面向对象,是将数据和操作,进行耦合,并且封装在类里面。这种做法是有它的好处的。这样不会导致数据和操作之间出现问题。而c如果这么写,说实话还不如用c++的类进行实现,因为类描述这些逻辑更为清晰,而且语法和编译器可以帮你做大量的事情。 而相反面向数据,是一批数据(不是一个具体数据单元),存在一批不同操作。如何分析数据之间的无关性和前后操作的无关性是重点,这两个分析清楚,那么并发计算,和分步骤计算就得以实现。并发计算不谈,分步骤计算的思想就是原子操作,或者微指令集管道设计思想。这样设计,可以令复杂的数据处理,根据流程细分到步骤,每个步骤细分到子步骤单元,而每个子步骤单元只负责处理,不负责数据的格式问题。 上面这段的设计思想和面向对象是反过来的,数据和操作松耦合。数据的特殊性导致的操作,是通过各种操作模块组合调用实现(这些操作模块可以看作上面独立的子步骤单元和外部特定数据结构无关的)。 这样做的好处是,模块的设计,可以独立进行,让外部数据格式依赖自身,而不是操作对应数据格式(面向对象是后者,成员变量类型决定了成员函数的实际操作),模块复用率高,同时是整批数据处理,只要数据流程(调用不同模块的系统设计良好),运行效率会很高。而且便于并发操作。 并发操作并不单单是一批数据,分层几组让同一个操作的多个进程处理。流水线技术的使用,一样可以实现。 这里顺带喷下hadoop。貌似hadoop的map reduce并没有在流水线方面有什么突破的思路,这块需要考虑到不同计算单元之间数据流动的费用, hadoop整天扯分布计算,根本不考虑数据整体计算周期内的相关性的问题,基本上都是推给用户自己处理,而用户应该无法控制具体计算硬件设备,最后能有好效果就扯淡了。
kun坤 2020-06-10 09:29:21 0 浏览量 回答数 0

回答

概述 本实践通过模拟搭建电商网站 Demo,演示如何使用阿里云日志服务接入电商系统 Web 服务器的接入日志,并在函数计算中编写 ETL 托管程序,对日志服务中数据进行处理,然后通过日志服务的仪表盘进行可视化展示。ETL 托管程序通过日志服务触发器以秒级准实时的频率被调用。 应用场景 数据加工场景:实时消费日志服务写入的日志 数据投递场景:从数据源抽取(Extract)出所需的数据,经过数据加工(Transform),最终按照预先定义好的数据仓库模型,将数据加载(Load)到数据仓库中去。 方案介绍 通过日志服务 + 函数计算 ETL,快速完成日志采集、加工、查询、分析和展示。 etl 日志服务+函数计算 ETL 的优势 一站式采集、存储、加工、分析和展示 全托管日志加工任务,按时间周期进行触发执行,自动重试 日志库资源按Shard水平扩展,满足大数据需求 基于函数计算提供数据加工、弹性资源、按需付费以及自定义代码逻辑 持续增加内置函数模板,降低主流需求下的函数开发代价 方案详情: 使用函数计算对日志服务中的数据进行 ETL 数据处理
1934890530796658 2020-03-27 17:15:25 0 浏览量 回答数 0

回答

session中保存的值可能是字符串、数组、类等各种数据类型,就算是单一数据类型,它表示的意义也存在多种可能,如一本书信息,一个用户信息,一个销量排行等,除此之外,返回一个默认值还有可能要处理一些逻辑、事务等等,在这种情况下,将处理逻辑作为参数传入方法,可以方便的解决这类问题。class Session { public static function get(String $key, Closure $func) { // 取key的value,如果为空则调用匿名函数 return $func(); // 只专注于自己的业务(k-v),其它业务委托匿名函数处理。 } }匿名函数是不需要定义函数名的,可以作为参数传递给其他函数, 通常用于回调函数。
落地花开啦 2019-12-02 02:42:49 0 浏览量 回答数 0

问题

java 主函数中启动第二个线程,然后主函数继续向下执行

需求是这样的,请求过来,先将所有的数据存下来,启动第二个线程去处理数据,主函数里面不关心第二个线程是否处理完成,直接返回成功,这样怎么写...
51干警网 2019-12-01 19:41:23 966 浏览量 回答数 1

回答

场景描述 用户通过手机终端、Web应用、或者PC工具把各种文件包括图片、视频以及文本等上传到OSS(对象存储,下同)后,利用OSS的PutObject事件可以触发函数计算对上传后的文件进行处理。 典型场景 当用户把视频文件上传到OSS后,触发函数计算把对象的Meta信息获取并传输给核心算法库,核心算法库根据算法把相应的视频文件推送CDN源站,达到特定视频热加载的处理。另外一个场景,视频文件上传到OSS后也同时触发函数计算同步做多转码率的处理,并把处理后的视频文件存储到OSS中,完成轻量的数据处理。 在多媒体的处理场景中,经常会碰到海量文件上传到OSS后,还需要对文件进行进一步的加工,例如加水印、转码率、获取文件属性等操作,这个场景中,用户在处理的时候会遇到以下需要解决的技术难点: 如何接收文件上传后的动作事件,通常的做法是定制消息通道来接收OSS事件通知,搭建一个运行环境,并编写相关的代码来处理事件通知。 如何高效的处理完海量上传的文件。 如何无缝的把多个云产品连接起来。 通过函数计算能比较方便解决以上几个技术难点: 函数计算可以设置OSS的触发器来接收事件通知,在函数计算中编写业务代码来处理文件,并通过内网把文件传输到OSS中,整个流程简单易用可扩展。 可以把核心代码部署到函数计算中,通过函数计算来并发处理事件通知。 函数计算目前打通了多款产品的内部交互,通过控制台简单配置就可以高效的解决产品间连接问题。 事件触发场景常规做法: 设置消息通道接收事件,并编写业务代码。 购买服务器资源做后端数据处理。 设计一套多并发框架完成业务上传文件峰值的处理。 开通多个产品,并调用SDK代码来完成业务交互。 函数计算解法: 在控制台上配置事件源通知,编写业务代码。 代码写到函数计算里,不需要管理软硬件环境。 业务高峰期函数计算会动态伸缩,无需管理。 内置打通多款产品,简单配置就可以无缝对接。
游客pklijor6gytpx 2019-12-02 03:24:00 0 浏览量 回答数 0

问题

什么是函数计算

阿里云函数计算是一个事件驱动的全托管计算服务。通过函数计算,您无需管理服务器等基础设施,只需编写代码并上传。函数计算会为您准备好计算资源,以弹性、可靠的方式运行您的代码,并提供日志查询...
boxti 2019-12-01 21:47:55 948 浏览量 回答数 0

回答

如何实现 JavaScript RPC 应用 一、一个 JavaScript RPC 的实现 1、RPC工作流程 JavaScript RPC 的简单实现过程是: 在客户端JavaScript脚本中,将要调用的服务端PHP函数名和函数参数(本地的JavaScript变量值)作为要传输的数据,通过Ajax传输到服务端,同时,Ajax设置一个回调函数,以便使用服务端函数的返回结果。在服务端PHP脚本中,接收Ajax传输的数据,从中取出要执行的函数名和函数参数。然后执行指定的函数,并将执行函数的返回值作为传输的数据,直接输出到浏览器,以此作为响应AJax的请求。客户端的Ajax在接受服务端的响应后,把返回的数据传递给AJax的回调函数。到此完成了一个RPC的流程。 2、传输的数据 在RPC执行过程中,客户端与服务端需要相互传输数据,我们分别称之为客户端数据和服务端数据。对此的说明如下表: 客户端数据: 函数名:服务端PHP脚本中存在的函数。 函数参数:客户端JavaScript脚本中的变量值。 服务端数据: 函数返回值:执行服务端PHP函数的返回值。 3、序列化与反序列化 为了要传输客户端的变量值和服务端的函数返回值,需要对其进行序列化处理。与之相对应的在传输后还要进行反序列化处理。 JavaScript中的变量的类型:基本类型和JSON类型(普通数组、元对象) PHP中的变量类型:基本类型和数组(普通数组和关联索引数组) PHP语言具有序列化和反序列化函数,而JavaScript语言中没有,因此我们要自己实现它。 由于我们进行JavaScript和PHP之间的数据交换,所以直接把JavaScript变量序列化为PHP的序列化形式。我们实现Js2PhpSerialize函数来完成这个任务。 Js2PhpSerialize:主要是把JSON对象及嵌套调用的JSON对象和基本类型的数据表示为PHP的序列化形式。 服务端的PHP在执行函数后,把结果序列化为JavaScript能理解的形式,以便于eval动态生成变量。我们实现php2JsSerialize函数来完成这个任务。 4、功能实现 我们创建两个类来完成上述功能。一个是客户端的JavaScript类,一个是服务端的PHP类。 文件名:jsrpc.class.js 要实现的功能: A、序列化JavaScript的数据。 B、Ajax传输序列化数据 C、反序列化JavaScript数据。 D、设置回调函数。 文件名:jsrpc.class.php 要实现的功能: A、响应Ajax请求,接收序列化数据。 B、反序列化PHP数据,基本类型和数组。 C、序列化PHP数据为JavaScript数据。 将JavaScript的数据类型转换为PHP可以理解的形式,通过Ajax把转换后的数据传递到服务端,由PHP的eval函数解析为PHP的数据类型。 PHP函数执行后,将执行结果数据转换为JavaScript可以理解的形式,由Ajax的回调函数响应,并由JavaScript的eval函数解析为JavaScript的数据类型。 二、应用示例 代码片段: JavaScript端: <SCRIPT language=javascript src="jsrpc.class.js"></SCRIPT> <SCRIPT language=javascript> var arr = new Array(1,'abc', new Array(3,'xyz'),5); var rpc = new JsRPC(); rpc.call('ajax_server.php', 'checkBook', response, arr); function response(result) { alert(result[1]); } </SCRIPT> PHP端(即文件ajax_server.php): <?php require_once('jsrpc.class.php'); $ar = new JsRPC(); $ar->register('checkBook'); $ar->start(); function checkBook($param) { return $param; } ?> 如上所示,它使用方法与一个叫CPaint的类库相似,只是省去了将数据装到一个对象中的步骤。 三、获取源码 “答案来源于网络,供您参考”
牧明 2019-12-02 02:15:31 0 浏览量 回答数 0

问题

魔乐MLDN李兴华主讲Oracle视频教程

百度网盘:http://pan.baidu.com/s/1c08H79Y 文件大小:3.04G 提取密码:m46x 解压密码:www.he11oworld.com 1-Oracl...
webssss 2019-12-01 20:58:21 13867 浏览量 回答数 5

问题

go语言里,如果读取标准输入的数据,怎么正确处理超时:报错

新手请教 go语言里,如果读取标准输入的数据,怎么正确处理超时? 启动一个 go routinue 从 os.Stdin 读取数据, 在另外go routinue检测到超时时, 应该怎么处理., 尝试用 os.Stdin.Close()...
kun坤 2020-06-06 15:17:18 0 浏览量 回答数 1

问题

函数计算处理数据并分发的解决方案有什么亮点?

函数计算处理数据并分发的解决方案有什么亮点?...
剑曼红尘 2020-03-23 15:07:20 0 浏览量 回答数 1

问题

jquery ajax不能上传图片

form里既有数据也有图片上传js代码: &lt;script type="text/javascript"&gt; $(document).ready(function(){ //DOM的onload事件...
杨冬芳 2019-12-01 19:57:05 1035 浏览量 回答数 1

问题

MaxCompute产品简介:文档变更历史

序号文档名称变更内容变更时间1INSERT操作、SELECT操作DML相关文档中添加MaxCompute2.0版本 扩展支持的新功能,包括values、CTE、SEMIJOIN等;2017.92日期函数、数学函数...
行者武松 2019-12-01 22:01:15 1123 浏览量 回答数 0

回答

数据中可能会有缺失值,处理的方法有两种,一种是删除整行或者整列的数据,另一种则是使用其他值去填充这些缺失值。在Pandas库,有两种很有用的函数用于处理缺失值:isnull()和dropna()函数能帮助我们找到数据中的缺失值并且删除它们。如果你想用其他值去填充这些缺失值,则可以是用fillna()函数。
珍宝珠 2019-12-02 03:14:11 0 浏览量 回答数 0

回答

BN是在当前层最后进行处理的,原始数据还是要经过至少一层的网络,在这一层网络中不同的数据规模和范围肯定会有影响,BN在后面会有所矫正,但是问题避免不了,所以还需要做标准化。 onvolution layer需要激活函数 pooling layer需要激活函数 normalization layer不需要激活函数 fully-connected layer需要激活函数 cost layer不需要激活函数 答案来源于网络
养狐狸的猫 2019-12-02 02:15:15 0 浏览量 回答数 0

回答

函数计算是事件驱动的全托管计算服务。使用函数计算,您无需采购与管理服务器等基础设施,只需编写并上传代码。函数计算为您准备好计算资源,弹性地可靠地运行任务,并提供日志查询、性能监控和报警等功能。 借助函数计算,您可以快速构建任何类型的应用和服务,并且只需为任务实际消耗的资源付费。 工作流程 函数计算工作流程如下图所示: 数据流向 编号说明 ①. 开发者使用编程语言编写应用和服务。函数计算支持的开发语言请参考 开发语言列表。 ②. 开发者上传应用到函数计算。上传途径包括 函数计算控制台(推荐)、命令行工具 Fun(推荐)、API/SDK 以及 命令行工具 fcli。 ③. 触发函数执行。触发方式包括 OSS、API 网关、日志服务、表格存储以及函数计算 API/SDK 等。 ④. 动态扩容以响应请求。函数计算可以根据用户请求量自动扩容,该过程对您和您的用户均透明无感知。 ⑤. 根据函数的实际执行时间按量计费。函数执行结束后,可以通过账单来查看执行费用,收费粒度精确到 100 ms。更多详情,请参阅 计费方式。 集成服务 函数计算以事件驱动的方式连接其他服务。借助这些方式,您可以构建弹性的、可靠的以及安全的应用和服务,甚至在数天内就能完成一套多媒体数据处理后端服务。当事件源触发事件时,我们会自动调用关联的函数处理事件。例如,对象存储(OSS)在新对象创建 / 删除事件(ObjectCreated/ObjectRemoved)时会自动触发函数处理。或者 API 网关在收到 HTTP 请求时自动触发函数处理请求。此外,函数还可以由 日志服务 或者 表格存储 等其他阿里云服务触发。 函数计算支持的事件源类型请参考文章 触发器列表。 无服务器架构 假设您计划采购服务器开发一款短视频社交应用,那么您需要考虑很多的问题,例如: 如何构建和运维一套弹性的稳定的视频处理后端服务? 需要采购多少台服务器? 服务器采用什么规格? 如何配置网络和操作系统? 如何部署环境? 如何负载均衡? 如何动态伸缩? 如何升级配置? 如何应对服务器宕机? 如何应对用户请求峰值? 如何应对系统监控报警? …… 可喜的是,基础设施的云化,使您能快速调动和使用海量计算资源,无需担心如何短时间内获取合适规格的服务器。但当前云计算的抽象粒度大多在机器级别,要管理和使用这些计算资源仍然有不小的门槛和成本。阿里云函数计算为解决计算成本和效率问题而生,将计算服务的抽象粒度提高到了函数级别,打造无服务器概念的应用设计模式。 使用函数计算,你无需管理底层的基础设施,只需要将您的代码部署到函数计算,并以事件驱动的方式触发函数执行,服务就可以平稳运行。您无需再为环境部署、服务器扩容、服务器宕机等问题烦恼,函数计算提供弹性的扩容机制,并按量计费。此外,函数计算提供日志查询、性能监控和报警等功能,帮助您快速定位问题、排查故障。 产品优势 因此,函数计算主要具备以下优势: 您无需采购和管理服务器等基础设施,运维成本低。 您只需专注业务逻辑的开发,使用函数计算支持的 开发语言 设计、优化、测试、审核以及上传自己的应用代码。 以事件驱动的方式触发应用响应用户请求。与阿里云 对象存储OSS、API 网关、日志服务 和 表格存储 等服务无缝对接,帮助您快速构建应用。例如,通过 OSS 解决图片和视频的存储问题,当有新数据写入您的 OSS 资源时,自动触发函数处理数据。 提供日志查询、性能监控和报警等功能快速排查故障。 毫秒级别弹性伸缩,快速实现底层扩容以应对峰值压力。 按需付费,支持百毫秒级别收费。只需为实际使用的计算资源付费,适合有明显波峰波谷的用户访问场景。更多详情,请参阅 计费方式。 学习路径 您可以通过 函数计算学习路径图 快速了解产品,由浅入深学习使用和运维函数计算。
1934890530796658 2020-03-27 16:02:38 0 浏览量 回答数 0

回答

函数计算(Function as a Service)是 Serverless 中最具代表性的产品形态。通过把应用逻辑拆分多 个函数,每个函数都通过事件驱动的方式触发执行,例如当对象存储(OSS)中产生的上传 / 删除对象等事件, 能够自动、可靠地触发 FaaS 函数处理且每个环节都是弹性和高可用的,客户能够快速实现大规模数据的实时 并行处理。同样的,通过消息中间件和函数计算的集成,客户可以快速实现大规模消息的实时处理。
Pony马 2021-01-14 21:56:51 0 浏览量 回答数 0

回答

函数计算(Function as a Service)是 Serverless 中最具代表性的产品形态。通过把应用逻辑拆分多 个函数,每个函数都通过事件驱动的方式触发执行,例如当对象存储(OSS)中产生的上传 / 删除对象等事件, 能够自动、可靠地触发 FaaS 函数处理且每个环节都是弹性和高可用的,客户能够快速实现大规模数据的实时 并行处理。同样的,通过消息中间件和函数计算的集成,客户可以快速实现大规模消息的实时处理。
Pony马 2021-01-15 11:15:42 0 浏览量 回答数 0

问题

如果需要原样输出用户输入的内容,在数据入库前,要用哪个函数处理?

如果需要原样输出用户输入的内容,在数据入库前,要用哪个函数处理?...
珍宝珠 2019-12-01 21:59:02 24 浏览量 回答数 1

回答

JSON 是一种数据交换格式,基于文本,优于轻量,用于交换数据。 JSON 可以表示数字、布尔值、字符串、null、数组(值的有序序列),以及由这些值(或数组、对象)所组成的对象(字符串与 值的映射)。 JSON 使用 JavaScript 语法,但是 JSON 格式仅仅是一个文本。文本可以被任何编程语言读取及作为数据格式传递。 JSON 是一种基于文本的轻量级的数据交换格式。它可以被任何的编程语言读取和作为数据格式来传递。 在项目开发中,我们使用 JSON 作为前后端数据交换的方式。在前端我们通过将一个符合 JSON 格式的数据结构序列化为 JSON 字符串,然后将它传递到后端,后端通过 JSON 格式的字符串解析后生成对应的数据结构,以此来实现前后端数据的一个传递。 因为 JSON 的语法是基于 js 的,因此很容易将 JSON 和 js 中的对象弄混,但是我们应该注意的是 JSON 和 js 中的对象不是一回事,JSON 中对象格式更加严格,比如说在 JSON 中属性值不能为函数,不能出现 NaN 这样的属性值等,因此大多数的 js 对象是不符合 JSON 对象的格式的。 在 js 中提供了两个函数来实现 js 数据结构和 JSON 格式的转换处理,一个是 JSON.stringify 函数,通过传入一个符合 JSON 格式的数据结构,将其转换为一个 JSON 字符串。如果传入的数据结构不符合 JSON 格式,那么在序列化的时候会对这些值进行对应的特殊处理,使其符合规范。在前端向后端发送数据时,我们可以调用这个函数将数据对象转化为 JSON 格式的字符串。 另一个函数 JSON.parse() 函数,这个函数用来将 JSON 格式的字符串转换为一个 js 数据结构,如果传入的字符串不是标准的 JSON 格式的字符串的话,将会抛出错误。当我们从后端接收到 JSON 格式的字符串时,我们可以通过这个方法来将其解析为一个 js 数据结构,以此来进行数据的访问。
剑曼红尘 2020-04-03 15:30:04 0 浏览量 回答数 0

回答

事件请求场景 定制图片 网店店家进行商品图片维护时,需要根据商品陈列位置,将图片动态切割成不同尺寸,或者打上不同水印。当店家把图片上传到对象存储 OSS上,会通过函数计算上定制的trigger来触发函数计算。根据计算规则,生成不同尺寸的图片,满足在线商品陈列需求,整个过程无需再搭建额外服务器,也无需网站美工干预。 物联网中的低频请求 物联网行业中,物联网设备传输数据量小,且往往是以固定时间间隔进行数据传输,因此经常涉及低频请求场景。例如:物联网应用程序每分钟仅运行一次,每次运行 50ms,这意味着CPU的使用率仅为 0.1%/小时,或者说有 1000 个相同的应用可以共享计算资源。而Serverless架构下,用户可以购买每分钟 100ms 的资源来满足计算需求,既能有效解决效率问题,也能降低使用成本。 定制事件 用户注册时发邮件验证邮箱地址,同样可以通过定制的事件来触发后续的注册流程,而无需再配置额外的应用无服务器来处理后续的请求。 固定时间触发 事件触发固定时间触发,例如在夜间或者服务空闲时间来处理繁忙时候的交易数据,或者运行批量数据,来生成数据报表,通过Serverless方式,不用再额外购买利用率并不高的处理资源。 流量突发场景 弹性扩展应对突发流量 移动互联网应用经常会面对突发流量场景。例如:移动应用的通常流量情况是 QPS 20,但每隔 5 分钟会有一个持续 10s 的 QPS 200 流量(10 倍于通常流量)。传统架构下,企业必须扩展 QPS 200 的硬件能力来应对业务高峰,即使高峰时间仅占整个运行时间的4%。 在Serverless架构下,您可以利用弹性扩展特性,快速构建新的计算能力来满足当前需求,当业务高峰后,资源能够自动释放,有效节省成本。 转码和流量扩容 视频直播某次专场活动,由于无法预估会有多少点播的观众视频接入,把转码和流量扩容这部分内容通过Function来处理,无需考虑并发和流量扩容。 处理大数据场景 由于安全审计问题,您需要从OSS(多个地域)过去一年的数据(1 个小时一个文件)中找出特定关键字访问的日志,同时做聚合运算(计算出总值)。如果使用阿里云函数计算,您将高峰期每 2 小时的访问日志,或者低谷期每 4 小时的访问日志交给一个计算函数处理,并将处理结果存到RDS中。使用一个函数分派数据给另一个函数,使其执行成千上万个相同的实例。 这样会同时运行近千个计算函数(24 x 365 / 10),在不到一分钟的时间内完成整个工作。同样的事情交给ECS+计算脚本来做计算,单单为这些instance配置网络就让人头疼(不同地域无法走内网下载OSS文件):instance的数量可能已经超出了子网中剩余IP地址的数量(比如,您的VPC使用了24位掩码)。 下面结合阿里云的函数计算产品来讲解各个应用场景中地架构以及如何解决场景中的痛点。阿里云的函数计算是基于Serverless这种架构实现的一个全托管产品,用户只需要上传核心代码到函数计算,就可以通过事件源或者SDK&API来运行代码。函数计算会准备好运行环境,并根据请求峰值来动态扩容运行环境。函数计算是按照执行时间来计费,请求处理完成后,计费停止,对于有业务请求有明显高峰和低谷的应用来说,相对节省成本。
剑曼红尘 2020-03-23 15:07:05 0 浏览量 回答数 0

回答

用mysql自带函数有什么不好?1.很可能造成where后的条件无法走索引2.把一些php层面简单的业务逻辑交给mysql来做,加大了mysql的压力(尽管可能你看来执行一次sql语句影响很小),对小系统而言没什么。如果对于大型系统,那会是灾难。大型系统的瓶颈基本都在数据库层面难以扩展,php很容易的水平扩展,php不会是瓶颈,因此,尽可能的降低数据库的处理压力,包括减少查询次数通过cache来解决,减少每次查询的时间则通过索引以及尽可能的业务在php层面处理,mysql只做最基本简单的查询少使用自带函数。那mysql自带函数为什么存在?比如一些数据初始化是可以用,或者存储过程等..小型系统可以使用mysql自带函数,反正没啥瓶颈不能因为大型系统不建议查询用自带函数就不提供,因为考虑到普遍的需求比如php框架的ORM设计,很费资源又慢,大型系统也不建议用,小系统就随便用,方便又快速。总结就是不能因为一些场景不建议用就不提供...方便快速的代价就是性能。
西秦说云 2019-12-02 01:33:16 0 浏览量 回答数 0

回答

前言 随着计算机技术和 Internet 的日新月异,视频点播技术因其良好的人机交互性和流媒体传输技术倍受教育、娱乐等行业青睐,而在当前, 云计算平台厂商的产品线不断成熟完善, 如果想要搭建视频点播类应用,告别刀耕火种, 直接上云会扫清硬件采购、 技术等各种障碍,以阿里云为例: image 这是一个非常典型的解决方案, 对象存储 OSS 可以支持海量视频存储,采集上传的视频被转码以适配各种终端,CDN 加速终端设备播放视频的速度。此外还有一些内容安全审查需求, 比如鉴黄、鉴恐等。 而在视频点播解决方案中, 视频转码是最消耗计算力的一个子系统,虽然您可以使用云上专门的转码服务,但在很多情况下,您会选择自己搭建转码服务。比如: 您已经在虚拟机/容器平台上基于 FFmpeg 部署了一套视频处理服务,能否在此基础上让它更弹性,更高的可用性? 您有并发处理大量视频的需求。 您有很多超大的视频需要批量快速处理完, 比如每周五定期产生几百个 4G 以上的 1080P 大视频, 但是希望当天几个小时后全部处理完。 您有更高级的自定义处理需求,比如视频转码完成后, 需要记录转码详情到数据库, 或者在转码完成后, 自动将热度很高的视频预热到 CDN 上, 从而缓解源站压力。 自定义视频处理流程中可能会有多种操作组合, 比如转码、加水印和生成视频首页 GIF。后续为视频处理系统增加新需求,比如调整转码参数,希望新功能发布上线对在线服务无影响。 您的需求只是简单的转码需求,或是一些极其轻量的需求,比如获取 OSS 上视频前几帧的 GIF、获取视频或者音频的时长,自己搭建成本更低。 各种格式的音频转换或者各种采样率自定义、音频降噪等功能 您的视频源文件存放在 NAS 或者 ECS 云盘上,自建服务可以直接读取源文件处理,而不需要将它们再迁移到 OSS 上。 如果您的视频处理系统有上述需求,或者您期望实现一个 弹性、高可用、低成本、免运维、灵活支持任意处理逻辑 的视频处理系统,那么本文则是您期待的最佳实践方案。 Serverless 自定义音视频处理 在介绍具体方案之前, 先介绍两款产品: 函数计算 :阿里云函数计算是事件驱动的全托管计算服务。通过函数计算,您无需管理服务器等基础设施,只需编写代码并上传。函数计算会为您准备好计算资源,以弹性、可靠的方式运行您的代码,并提供日志查询、性能监控、报警等功能。 函数工作流:函数工作流(Function Flow,以下简称 FnF)是一个用来协调多个分布式任务执行的全托管云服务。您可以用顺序,分支,并行等方式来编排分布式任务,FnF 会按照设定好的步骤可靠地协调任务执行,跟踪每个任务的状态转换,并在必要时执行用户定义的重试逻辑,以确保工作流顺利完成。 免费开通函数计算,按量付费,函数计算有很大的免费额度。 免费开通函数工作流,按量付费,函数工作流有很大的免费额度。 函数计算可靠的执行任意逻辑, 逻辑可以是利用 FFmpeg 对视频任何处理操作, 也可以更新视频 meta 数据到数据库等。函数工作流对相应的函数进行编排, 比如第一步的函数是转码, 第二步的函数是转码成功后,将相应 meta 数据库写入数据库等。 至此,您应该初步理解了函数计算的自定义处理能力 + 函数工作流编排能力几乎满足您任何自定义处理的需求,接下来,本文以一个具体的示例展示基于函数计算和函数工作流打造的一个弹性高可用的 Serverless 视频处理系统,并与传统方案进行性能、成本和工程效率的对比。 Simple 视频处理系统 假设您是对视频进行单纯的处理, 架构方案图如下: image 如上图所示, 用户上传一个视频到 OSS, OSS 触发器自动触发函数执行, 函数调用 FFmpeg 进行视频转码, 并且将转码后的视频保存回 OSS。 OSS 事件触发器, 阿里云对象存储和函数计算无缝集成。您可以为各种类型的事件设置处理函数,当 OSS 系统捕获到指定类型的事件后,会自动调用函数处理。例如,您可以设置函数来处理 PutObject 事件,当您调用 OSS PutObject API 上传视频到 OSS 后,相关联的函数会自动触发来处理该视频。 Simple 视频处理系统示例工程地址 强大的监控系统: 您可以直接基于示例工程部署您的 Simple 音视频处理系统服务, 但是当您想要处理超大视频(比如 test_huge.mov ) 或者对小视频进行多种组合操作的时候, 您会发现函数会执行失败,原因是函数计算的执行环境有最大执行时间为 10 分钟的限制,如果最大的 10 分钟不能满足您的需求, 您可以选择: 对视频进行分片 -> 转码 -> 合成处理, 详情参考:fc-fnf-video-processing, 下文会详细介绍; 联系函数计算团队(钉钉群号: 11721331) 或者提工单: 适当放宽执行时长限制; 申请使用更高的函数内存 12G(8vCPU) 为了突破函数计算执行环境的限制(或者说加快大视频的转码速度), 进行各种复杂的组合操作, 此时引入函数工作流 FnF 去编排函数实现一个功能强大的视频处理工作流系统是一个很好的方案。 视频处理工作流系统 image 如上图所示, 假设用户上传一个 mov 格式的视频到 OSS,OSS 触发器自动触发函数执行, 函数调用 FnF,会同时进行 1 种或者多种格式的转码(由您触发的函数环境变量DST_FORMATS 参数控制)。 所以您可以实现如下需求: 一个视频文件可以同时被转码成各种格式以及其他各种自定义处理,比如增加水印处理或者在 after-process 更新信息到数据库等。 当有多个文件同时上传到 OSS,函数计算会自动伸缩, 并行处理多个文件, 同时每次文件转码成多种格式也是并行。 结合 NAS + 视频切片, 可以解决超大视频(大于 3G )的转码, 对于每一个视频,先进行切片处理,然后并行转码切片,最后合成,通过设置合理的切片时间,可以大大加速较大视频的转码速度。 所谓的视频切片,是将视频流按指定的时间间隔,切分成一系列分片文件,并生成一个索引文件记录分片文件的信息 视频处理工作流系统示例工程地址 示例效果: gif 函数计算 + 函数工作流 Serverless 方案 VS 传统方案 卓越的工程效率 自建服务 函数计算 + 函数工作流 Serverless 基础设施 需要用户采购和管理 无 开发效率 除了必要的业务逻辑开发,需要自己建立相同线上运行环境, 包括相关软件的安装、服务配置、安全更新等一系列问题 只需要专注业务逻辑的开发, 配合 FUN 工具一键资源编排和部署 并行&分布式视频处理 需要很强的开发能力和完善的监控系统来保证稳定性 通过 FnF 资源编排即可实现多个视频的并行处理以及单个大视频的分布式处理,稳定性和监控交由云平台 学习上手成本 除了编程语言开发能力和熟悉 FFmpeg 以外,可能使用 K8S 或弹性伸缩( ESS ),需要了解更多的产品、名词和参数的意义 会编写对应的语言的函数代码和熟悉 FFmpeg 使用即可 项目上线周期 在具体业务逻辑外耗费大量的时间和人力成本,保守估计大约 30 人天,包括硬件采购、软件和环境配置、系统开发、测试、监控报警、灰度发布系统等 预计 3 人天, 开发调试(2人天)+ 压测观察(1 人天) 弹性伸缩免运维,性能优异 自建服务 函数计算 + 函数工作流 Serverless 弹性高可用 需要自建负载均衡 (SLB),弹性伸缩,扩容缩容速度较 FC 慢 FC系统固有毫秒级别弹性伸缩,快速实现底层扩容以应对峰值压力,免运维,视频处理工作流系统 (FnF + FC) 压测;性能优异, 详情见下面的转码性能表 监控报警查询 ECS 或者容器级别的 metrics 提供更细粒度的 FnF 流程执行以及函数执行情况, 同时可以查询每次函数执行的 latency 和日志等, 更加完善的报警监控机制 函数计算 + 函数工作流 Serverless 方案转码性能表 实验视频为是 89s 的 mov 文件 4K 视频: 4K.mov,云服务进行 mov -> mp4 普通转码需要消耗的时间为 188s, 将这个参考时间记为 T 视频切片时间 FC转码耗时 性能加速百分比 45s 160s 117.5% 25s 100s 188% 15s 70s 268.6% 10s 45s 417.8% 5s 35s 537.1% 性能加速百分比 = T / FC转码耗时 从上表可以看出,设置的视频切片时间越短, 视频转码时间越短, 函数计算可以自动瞬时调度出更多的计算资源来一起完成这个视频的转码, 转码性能优异。 更低的成本 具有明显波峰波谷的视频处理场景(比如只有部分时间段有视频处理请求,其他时间很少甚至没有视频处理请求),选择按需付费,只需为实际使用的计算资源付费。 没有明显波峰波谷的视频处理场景,可以使用预付费(包年包月),成本仍然具有竞争力。 函数计算成本优化最佳实践文档。 假设有一个基于 ECS 搭建的视频转码服务,由于是 CPU 密集型计算, 因此在这里将平均 CPU 利用率作为核心参考指标对评估成本,以一个月为周期,10 台 C5 ECS 的总计算力为例, 总的计算量约为 30% 场景下, 两个解决方案 CPU 资源利用率使用情况示意图大致如下: image 由上图预估出如下计费模型: 函数计算预付费 3CU 一个月: 246.27 元, 计算能力等价于 ECS 计算型 C5 ECS 计算型 C5 (2vCPU,4GB)+云盘: 包月219 元 函数计算按量付费占整个计算量的占比 <= 10%,费用约为 3×864×10% = 259.2 元,(3G 规格的函数满负载跑满一个月费用为:0.00011108×3×30×24×3600 = 863.8,详情查看计费) ITEM 平均CPU利用率 计算费用 总计 函数计算组合付费 >=80% 998(246.27×3+259.2) <= 998 按峰值预留ECS <=30% 2190(10*219) >=2190 在这个模型预估里面,可以看出 FC 方案具有很强的成本竞争力,在实际场景中, 基于 ECS 自建的视频转码服务 CPU 利用甚至很难达到 20%, 理由如下: 可能只有部分时间段有视频转码请求 为了用户体验,视频转码速度有一定的要求,可能一个视频转码就需要 10 台 ECS 并行处理来转码, 因此只能预备很多 ECS 因此,在实际场景中, FC 在视频处理上的成本竞争力远强于上述模型。 即使和云厂商视频转码服务单价 PK, 该方案仍有很强的成本竞争力 我们这边选用点播视频中最常用的两个格式(mp4、flv)之间进行相互转换,经实验验证, 函数内存设置为3G,基于该方案从 mp4 转码为 flv 的费用概览表: 实验视频为是 89s 的 mp4 和 flv 格式的文件视频, 测试视频地址: 480P.mp4 720P.mp4 1080P.mp4 4K.mp4 480P.flv 720P.flv 1080P.flv 4K.flv 测试命令: ffmpeg -i test.flv test.mp4 和 ffmpeg -i test.flv test.mp4 mp4 转 flv: 分辨率 bitrate 帧率 FC 转码耗费时间 FC 转码费用 某云视频处理费用 成本下降百分比 标清 640480 889 kb/s 24 11.2s 0.003732288 0.032 88.3% 高清 1280720 1963 kb/s 24 20.5s 0.00683142 0.065 89.5% 超清 19201080 3689 kb/s 24 40s 0.0133296 0.126 89.4% 4K 38402160 11185 kb/s 24 142s 0.04732008 0.556 91.5% flv 转 mp4: 分辨率 bitrate 帧率 FC 转码耗费时间 FC 转码费用 某云视频处理费用 成本下降百分比 标清 640480 712 kb/s 24 34.5s 0.01149678 0.032 64.1% 高清 1280720 1806 kb/s 24 100.3s 0.033424 0.065 48.6% 超清 19201080 3911 kb/s 24 226.4s 0.0754455 0.126 40.1% 4K 38402160 15109 kb/s 24 912s 0.30391488 0.556 45.3% 成本下降百分比 = (某云视频处理费用 - FC 转码费用)/ 云视频处理费用 某云视频处理,计费使用普通转码,转码时长不足一分钟,按照一分钟计算,这里计费采用的是 2 min,即使采用 1.5 min 计算, 成本下降百分比基本在10%以内浮动 从上表可以看出, 基于函数计算 + 函数工作流的方案在计算资源成本上对于计算复杂度较高的 flv 转 mp4 还是计算复杂度较低的 mp4 转 flv, 都具有很强的成本竞争力。 根据实际经验, 往往成本下降比上表列出来的更加明显, 理由如下: 测试视频的码率较高, 实际上很多场景绝大部分都是标清或者流畅视频的转码场景, 码率也比测试视频低,这个时候计算量变小, FC 执行时间短, 费用会降低, 但是通用的云转码服务计费是不变的. 很多视频分辨率在通用的云转码服务是计费是有很大损失的, 比如转码的视频是 856480 或者 1368768, 都会进入云转码服务的下一档计费单价, 比如856480 进入 1280720 高清转码计费档,1368768 进入 19201080 超清转码计费档, 单价基本是跨越式上升, 但是实际真正的计算量增加可能还不到30%, 而函数计算则是真正能做到按计算量付费. 操作部署 免费开通函数计算,按量付费,函数计算有很大的免费额度。 免费开通函数工作流,按量付费,函数工作流有很大的免费额度。 免费开通文件存储服务NAS, 按量付费 详情见各自示例工程的 README Simple 视频处理系统示例工程地址 视频处理工作流系统示例工程地址 总结 基于函数计算 FC 和函数工作流 FnF 的弹性高可用视频处理系统天然继承了这两个产品的优点: 无需采购和管理服务器等基础设施,只需专注视频处理业务逻辑的开发,大幅缩短项目交付时间和人力成本 提供日志查询、性能监控、报警等功能快速排查故障 以事件驱动的方式触发响应用户请求 免运维,毫秒级别弹性伸缩,快速实现底层扩容以应对峰值压力,性能优异 成本极具竞争力 相比于通用的转码处理服务: 超强自定义,对用户透明, 基于 FFmpeg 或者其他音视频处理工具命令快速开发相应的音视频处理逻辑 原有基于 FFmpeg 自建的音视频处理服务可以一键迁移 弹性更强, 可以保证有充足的计算资源为转码服务,比如每周五定期产生几百个 4G 以上的 1080P 大视频, 但是希望当天几个小时后全部处理完 各种格式的音频转换或者各种采样率自定义、音频降噪等功能, 比如专业音频处理工具 aacgain 和 mp3gain 可以和 serverless 工作流完成更加复杂、自定义的任务编排,比如视频转码完成后,记录转码详情到数据库,同时自动将热度很高的视频预热到 CDN 上, 从而缓解源站压力 更多的方式的事件驱动, 比如可以选择 OSS 自动触发(丰富的触发规则), 也可以根据业务选择 MNS 消息(支持 tag 过滤)触发 在大部分场景下具有很强的成本竞争力相比于其他自建服务: 毫秒级弹性伸缩,弹性能力超强,支持大规模资源调用,可弹性支持几万核.小时的计算力,比如 1 万节课半个小时完成转码 只需要专注业务逻辑代码即可,原生自带事件驱动模式,简化开发编程模型,同时可以达到消息(即音视频任务)处理的优先级,可大大提高开发运维效率 函数计算采用 3AZ 部署, 安全性高,计算资源也是多 AZ 获取, 能保证每个用户需要的算力峰值 开箱即用的监控系统, 如上面 gif 动图所示,可以多维度监控函数的执行情况,根据监控快速定位问题,同时给用户提供分析能力, 比如视频的格式分布, size 分布等 在大部分场景下具有很强的成本竞争力, 因为在函数计算是真正的按量付费(计费粒度在百毫秒), 可以理解为 CPU 的利用率为 100% 最后一一回答一下之前列出的问题: Q1: 您已经在虚拟机/容器平台上基于 FFmpeg 部署了一套视频处理服务,能否在此基础上让它更弹性,更高的可用性? A: 如工程示例所示,在虚拟机/容器平台上基于 FFmpeg 的服务可以轻松切换到函数计算, FFmpeg 相关命令可以直接移值到函数计算,改造成本较低, 同时天然继承了函数计算弹性高可用性特性。 Q2:您的需求只是简单的转码需求,或是一些极其轻量的需求,比如获取 OSS 上视频前几帧的 GIF 等。 自己搭建成本更低。 A: 函数计算天生就是解决这些自定义问题, 你的代码你做主, 代码中快速执行几个 FFmpeg 的命令即可完成需求。典型示例: fc-oss-ffmpeg Q3: 您有更高级的自定义处理需求,比如视频转码完成后, 需要记录转码详情到数据库, 或者在转码完成后, 自动将热度很高的视频预热到 CDN 上, 从而缓解源站压力。 A: 详情见视频处理工作流系统(函数计算 + 函数工作流方案),after-process 中可以做一些自定义的操作, 您还可以基于此流程再做一些额外处理等, 比如: 再增加后续流程 最开始增加 pre-process Q4: 您有并发同时处理大量视频的需求。 A: 详情见视频处理工作流系统(函数计算 + 函数工作流方案), 当有多个文件同时上传到 OSS, 函数计算会自动伸缩, 并行处理多个文件。详情可以参考 视频处理工作流系统 (FnF + FC) 压测 Q5:您有很多超大的视频需要批量快速处理完, 比如每周五定期产生几百个 4G 以上的 1080P 大视频, 但是希望当天几个小时后全部处理完。A: 详情可以参考视频处理工作流系统 (FnF + FC) 压测, 可以通过控制分片的大小, 可以使得每个大视频都有足够多的计算资源参与转码计算, 大大提高转码速度。 Q6: 自定义视频处理流程中可能会有多种操作组合, 比如转码、加水印和生成视频首页 GIF,后续为视频处理系统增加新需求,比如调整转码参数,希望新功能发布上线对在线服务无影响。 A: 详情见视频处理工作流系统(函数计算 + 函数工作流方案), FnF 只负责编排调用函数, 因此只需要更新相应的处理函数即可,同时函数有 version 和 alias 功能, 更好地控制灰度上线, 函数计算版本管理 Q7: 您的视频源文件存放在 NAS 或者 ECS 云盘上,自建服务可以直接读取源文件处理,而不需要将他们再迁移到 OSS 上。 A: 函数计算可以挂载 NAS, 直接对 NAS 中的文件进行处理
1934890530796658 2020-03-27 18:21:36 0 浏览量 回答数 0

问题

odps 自定义函数 根据参数查询表,返回数据

我们要在大数据平台做数据标准化,想通过函数查询字典表的方式把源数据标准化处理。请问这个方案可行不,如果可行,性能如何,还有没有更好的方案。是否有参考案例给出?...
hackyun 2019-12-01 20:09:30 1099 浏览量 回答数 2

回答

详细解答可以参考官方帮助文档 使用规则引擎时,若您的数据为JSON格式,可以编写SQL来解析和处理数据。规则引擎对二进制格式的数据不做解析,直接透传。本文主要讲解SQL表达式。 SQL表达式 JSON数据可以映射为虚拟的表,其中Key对应表的列,Value对应列值,这样就可以使用SQL处理。为便于理解,我们将规则引擎的一条规则抽象为一条SQL表达(类试MySQL语法): 例如某环境传感器用于火灾预警,可以采集温度、湿度及气压数据,上报数据内容如下: { "temperature":25.1 "humidity":65 "pressure":101.5 "location":"xxx,xxx" } 假定温度大于38,湿度小于40时,需要触发报警,可以编写如下的SQL语句:SELECT temperature as t, deviceName() as deviceName, location FROM /ProductA/+/update WHERE temperature > 38 and humidity < 40 当上报的数据中,温度大于38且湿度小于40时,会触发该规则,并且解析数据中的温度、设备名称、位置,用于进一步处理。 FROM FROM 需要填写Topic通配符,用于匹配需要处理的消息Topic。当有符合Topic规则的消息到达时,消息的payload数据以json格式解析,并根据SQL语句进行处理(如果消息格式不合法,将忽略此消息)。您可以使用topic()函数引用具体的Topic值。 上文例子中,"FROM /ProductA/+/update"语句表示该SQL仅处理符合/ProductA/+/update格式的消息,具体匹配参考 Topic。 SELECT JSON数据格式 select语句中的字段,可以使用上报消息的payload解析结果,即json中的键值,也可以使用SQL内置的函数,比如deviceName()。不支持子SQL查询。 上报的json数据格式,可以是数组或者嵌套的json,SQL语句支持使用json path获取其中的属性值,如对于{a:{key1:v1, key2:v2}},可以通过a.key2 获取到值v2。使用变量时需要注意单双引号区别:单引号表示常量,双引号或不加引号表示变量。如使用单引号'a.key2',值为a.key2。 内置的SQL函数可以参考函数列表。 例如上文,"SELECT temperature as t, deviceName() as deviceName, location"语句,其中temperature和loaction来自于上报数据中的字段,deviceName()则使用了内置的SQL函数。 二进制数据格式 目前二进制数据不支持解析payload中的字段,SELECT语句固定为SELECT *,表示透传二进制数据。 WHERE JSON数据格式 规则触发条件,条件表达式。不支持子SQL查询。WHERE中可以使用的字段和SELECT语句一致,当接收到对应topic的消息时,WHERE语句的结果会作为规则是否触发的判断条件。具体条件表达式列表见下方表格。上文例子中, "WHERE temperature > 38 and humidity < 40" 表示温度大于38且湿度小于40时,才会触发该规则,执行配置。 二进制数据格式 目前二进制格式WHERE语句中仅支持内置函数及条件表达式,无法使用payload中的字段。 SQL结果 SQL语句执行完成后,会得到对应的SQL结果,用于下一步转发处理。如果payload数据解析过程中出错会导致规则运行失败。 转发数据动作中的表达式需要使用 ${表达式} 引用对应的值。 对于上文例子,配置转发动作时,可以${t}、${deviceName}和${loaction}获取SQL解析结果,如果要将数据存储到TableStore,配置中可以使用${t}、${deviceName}和${loaction}。 数组使用说明 数组表达式需要使用双引号,比如设备消息为:{a:[{v:1},{v:2},{v:3}]},那么SQL语句中的select写法为:select "$.a[0]" data1,".a[1].v" data2,".a[2]" data3,则data1={v:1},data2=2,data3=[{v:3}]。 条件表达式支持列表 操作符 描述 举例 = 相等 color = ‘red’ <> 不等于 color <> ‘red’ AND 逻辑与 color = ‘red’ AND siren = ‘on’ OR 逻辑或 color = ‘red’ OR siren = ‘on’ ( ) 括号代表一个整体 color = ‘red’ AND (siren = ‘on’ OR isTest) + 算术加法 4 + 5 - 算术减 5 - 4 / 除 20 / 4 * 乘 5 * 4 % 取余数 20 % 6 < 小于 5 < 6 <= 小于或等于 5 <= 6 > 大于 6 > 5 >= 大于或等于 6 >= 5 函数调用 支持函数,详细列表请参考函数列表。 deviceId() JSON属性表达式 可以从消息payload以json表达式提取属性。 state.desired.color,a.b.c[0].d CASE … WHEN … THEN … ELSE …END Case 表达式 CASE col WHEN 1 THEN ‘Y’ WHEN 0 THEN ‘N’ ELSE ‘’ END as flag IN 仅支持枚举,不支持子查询。 比如 where a in(1,2,3)。不支持以下形式: where a in(select xxx) like 匹配某个字符, 仅支持%号通配符,代表匹配任意字符串。 比如 where c1 like ‘%abc’, where c1 not like ‘%def%’
2019-12-01 23:11:54 0 浏览量 回答数 0
阿里云企业服务平台 陈四清的老板信息查询 上海奇点人才服务相关的云产品 爱迪商标注册信息 安徽华轩堂药业的公司信息查询 小程序定制 上海微企信息技术相关的云产品 国内短信套餐包 ECS云服务器安全配置相关的云产品 天籁阁商标注册信息 开发者问答 阿里云建站 自然场景识别相关的云产品 万网 小程序开发制作 视频内容分析 视频集锦 代理记账服务 北京芙蓉天下的公司信息查询