技术前沿 on 易哥

云原生与数据智能

Sun, 11 Sep 2022 00:00:00 +0000

一、什么是数据智能

目前，数字化产业在国内发展迅速，渗透到了人民群众衣食住行的各个领域之中。从2005年到2020年，我国的数字经济占GDP的比重从14.2%提升到了38.6%，2020年数字经济增速是GDP增速的3倍多，数字经济为各行业的降本增效做出了重大的贡献。

而数字化的发展也经历了以下几个阶段。

第一阶段为信息化阶段。在这一阶段，数字化致力于实现流程的自动化。
第二阶段为数据应用阶段。在这一阶段，数据的离线处理成为可能，推动了业务数据化和数据业务化。
第三阶段为数据智能阶段。在这一阶段，全场景的智能、跨领域协同成为新阶段的发展目标，推动数字化不断拓展更多应用场景。

数据智能化有利于充分发挥数据在商业、制造、政务、金融等各个领域的作用，推动相关领域的成本降低、效率优化。

“十四五规划”中明确指出，2035年中国要基本实现新型工业化、信息化。其中，推动数据资源开发利用成为重要命题之一。

在国家自上而下政策的推动下，本就十分广阔的中国企业服务市场，其潜力将会得到进一步挖掘。同时在由内而外的企业改革中，数字化与协作的理念将会进一步普及。

二、数据智能的意义

数据智能有着广泛的意义。

从国家层面看，数据智能能够促进数据在社会主义市场经济中的流动，便于国家更好地实施宏观调控，并对调控的反馈进行实时收集和监控。提升调控在微观和宏观层面的指导作用。

从产业层面看，数据智能能够实现数据价值化、数据资产化，助力产业结构调整和数据市场的良性发展。

从企业层面看，数据智能能够整合企业的供应链、财务、售后、库存、促销等各方面数据，提升企业的运营能力，助力企业降本增效。

因此，数据智能化是一个涉及上下各个层级的趋势。将对商业、制造、政务、金融等各领域带来深刻影响。

以制造领域为例，数据智能的实施将促进智能制造的发展。我们举例说明数据智能在这一过程中的重要作用。

如今，同一版本同一型号的手机，几乎是一模一样的。当我们说去选购商品，其实是在有限的型号中选择我们需要的那一款。可是，人的需求千变万化，为什么偏偏要归结到几个固定的型号上去呢？每个人不应该根据自己的需求，定义自己的产品么？

这很难。因为每个人的需求都是不同的，而工业化的生产却是标准化的。

如今，库存问题依旧困扰着商业流程，那我们能否直接对接消费者和生产者，从而消除库存呢？

这很难。因为生产者和消费者之间的信息还没有顺畅到可以直接打通。

解决以上问题的答案就是数据智能。

在物资贫瘠的时代，人类通过屏蔽个性化的需求来创造出一个标准化的环境，从而能提升效率创造更多的物资；而当物资充盈的时候，人类终于有精力来满足每个人个性化的需求。

你再也不需要将自己的需求归结到几个特定的标准型号上，物资将被完全依照你的需求而生产。你不需要再购买XL的衣服，衣服将绝对贴合你的身材；你不需要再挑选合适的手机，工厂为你制造你的手机。

而数据智能的意义不仅于此。

当物资急剧匮乏时，提高生产力是最重要的。而当物资变得极为丰富时，哪怕不提高生产力，只要能让物资能被利用的稍微合理些，就能产生巨大的价值。例如，如果生产商的订单数据能够实时来自于市场，那库存问题不就解决了，这会避免巨大的资源浪费。而且，如果买卖双方之间的信息足够通畅，负责进行信息协调的中间商似乎也没有存在的必要了。

如今我们想购买一辆自行车，是到市场上选购一辆。而智能制造时代，我们可以直接登录自行车生产商的网站。然后根据自己的需求选取合适的车把、车架、车轮……然后全自动的生产设备按照你的选配组装一辆完全契合你需求的自行车。再进一步看，自行车生产商也会根据你的选取，去相应的车把生产商提交订单，获取完全符合你要求的车把，因此车把的参数你可以完全自定。而整个生产过程，完全为你进行，没有库存，没有中间商赚差价，没有生产力的浪费。

数据智能让我们渐渐地有能力实现上面描述的一切，也让我们渐渐地回到了遥远的过去，回到了买卖双方直接交流、物资协调更为便利的古代，毕竟，那时展露的才是我们需求的本质。愈发丰富的物资让着它们变得不可能，而数据智能又渐渐地使它们变得可能。

在制造业领域，数据智能是一个涉及信息、管理等多方面的革新，是对人类生产方式的又一次颠覆。像工业时代中的流水线给人类社会带来的冲击一样，数据智能也必将会给人类社会带来深远的影响。

当然，数据智能不仅可以在制造业领域发挥作用，在商业、政务、金融等各领域都大有可为。例如，在政务领域的智慧政务系统，便可以实现在线政务办理、自动事项审批、企业特征画像等众多功能，打造政务服务新模式，创建数字经济先行区。

三、数据智能的特点

不同于传统的信息化改造，数据智能需要收集被改造主体的多方面数据，并在此基础上进行智能分析，它具有以下特点。

首先，数据源多样。从来源上看，在数据智能系统中，其分析的数据可能来自于用户填入的数据，也可能来自于生产过程数据，还可能来自于供应链数据。从形式上看，在数据智能系统中，其分析的数据可能是传统数据库中的结构化数据，可能是网页中的半结构化数据，也可能是文本数据库中的非结构化数据。因此数据源十分多样。

其次，数据智能系统所分析的数据量巨大，且增长快速。不同于传统数据库中的高信息密度数据，这些数据的信息密度是低的，量是大的，并且会随着时间推移迅速增长。

再次，相比于数据应用阶段的以离线计算为主的数据分析方式，数据智能系统需要大量的实时性计算，其对增强性计算需求量较大。

第四，数据智能系统的程序异构性强。其可能包含提供网页服务的WEB程序，也可能包含提供分布式存储的数据库程序，还可能包含提供数据分析的流处理、批处理程序，等等。因此，其程序异构性强。

因为数据智能系统具有数据源多样、数据量大且增长迅速、需要大量的实时性计算、程序异构性强等特点，所以其搭建：

具有一定的门槛，对于普通机构而言，其实现成本较高。
采用传统应用方式搭建的系统在面对大数据、实时计算时无法保证可靠性。

那数据智能的出路在何方？

那就是云原生。

四、云原生

云原生是一种方法，它用于构建和运行充分利用云计算模型优势的应用。它主要包含如下的技术：

微服务架构:服务与服务之间通过高内聚低耦合的方式交互;
容器:作为微服务的最佳载体,提供了一个自包含的打包方式;
容器编排:解决了微服务在生产环境的部署问题;
服务网络:作为基础设施,解决了服务之间的通信;
不可变基础:设施提升发布效率,方便快速扩展;
声明式API:让系统更加健壮;
DevOps:缩短研发周期,增加部署频率,更安全地方便。

其中的容器、容器编排、服务网格将所有的异构应用都抽象为相同的服务，这可以方便地将异构应用组成系统，统一地对外服务，降低了系统的搭建难度。

其中的不可变基础、DevOps使得系统能够更好的利用云上的弹性资源，能够更有弹性地应对存储空间、计算能力的需求变化。

其中的声明式API是相对于命令式API而言的。命令式API接受的是让系统直接执行的具体命令，例如"启动应用"、“更新数据源"等，而声明式API接受的期望系统达到的状态。在这个过程中，系统可以不断调整自身现有状态，以最终达到期望状态。这提升了系统运行的智能性、可靠性。

可见，云原生是实现数据智能的途径。

五、云原生与数据智能

数据智能系统具有数据源多样、数据量大且增长迅速、需要大量的实时性计算、程序异构性强等特点，使得传统的应用架构无法实现。而云原生则为数据智能系统的落地提供了途径。

就以滴普科技提供的FastData能力矩阵为例，它基于云原生实现了对多数据源的支持，并为各类数据提供了统一存储。继而可以对各类数据进行流批一体的分析处理和湖仓一体的给出。

基于以上能力，能够继续提供离线、实时的数据分析服务，提供数据资产服务，提供调度服务，从而服务企业中的各类角色。

下面的图中，展示了滴普科技的产品架构图。

通过架构图我们可以看出，整个系统主要分为自下而上的三层结构：

最下层为新一代云原生数据智能平台FastData。整个FastData是搭建在云原生基础服务上的，每个子平台可以利用云原生提供的各项基础服务（权限验证等），实现了基础功能和子平台业务功能的解耦。这种设计确保了每个子平台的安全性，也提升了每个子平台的可拓展性。例如，在这种云原生的架构下，拓展湖存储引擎、流批计算引擎时的具体工作都仅限于业务子平台内部，而不用关系权限验证、数据安全等基础服。甚至这种拓展工作可以由全链路运维系统根据当前负载情况自动完成。

中间层为数据资产治理与运营平台。这一部分承载了主要的业务逻辑，可以根据需求实现商业、智能精益制造、智慧政务等不同领域的业务逻辑，而不需要关心存储、计算等底层信息。如果需要对业务逻辑进行更新、优化，则都只需要在这一层展开，这使得项目升级的过程更为简单和纯粹。

最上层则为交付服务，包括线上线下的交付。由于已经在最下层和中间层进行了逻辑梳理与隔离，这里的交付工作可以更为标准和快速的实现，可以大大减少系统的搭建时间和部署人员的工作量。

以上架构充分利用了云原生的优势，确保了整个系统的可拓展性、可靠性、可维护性。能够较好地应对机构的业务量增长，并能根据机构的需求增加各种特异性服务。例如为商业企业提供消费者运营分析、业财一体等服务，为智能精益制造企业提供质量追溯、EVA分析等服务，为政府机构提供数字双碳分析、经济大脑等服务。

云原生是数据智能落地的重要保障。它能在满足数据智能所需的多数据源、大数据量、实时计算、异构性强等要求的基础上，提升整个系统的可拓展性、可靠性、可维护性。因此，云原生是数据智能的发展方向。

一种适用于网格计算的主动存储计算机模型

Sun, 15 May 2022 00:00:00 +0000

图灵机作为一种基础的理论模型，在解决可计算性问题上十分重要。但是，在实际使用中，这种模型过于简单。通常，在算法设计和分析领域，我们使用随机访问计算机模型RAM（Random Access Machine）。但是，在网格计算中，RAM模型过于基础，因此产生了众多其他模型。

本文讨论一种适用于网格计算的主动存储计算机模型CAM（Computer with Active Memory），包括其提出背景，使用范围，局限性等。本文主要内容参考中科院计算所徐志伟等人编著的《网格计算技术》一书以及徐志伟先生的论文《一种主动存储计算机模型》。

同时，我们也对徐志伟先生所提的理论进行了一些修改，包括将字长等元组从模型中删除，修改了一些定义等。但具体思想仍由原作给出。

RAM模型

RAM模式是我们展开讨论的基础，因此我们先形式化定义RAM模型。

一个RAM计算机C可以定义为一个三元组，$C=(P,M,Ci)$，其中：

P是计算机的处理器
M是计算机的存储器。存储器M中包含众多的存储单元，我们依次记为$M(0),M(1),M(2)……$，因此M是以上各个存储单元的集合，即$M= { M(0),M(1),M(2)…… } $。
Ci是计算机的指令集。指令集Ci能够覆盖完成图灵机的操作，例如可以是下列指令的集合：load,store,add,subtract,multiply,divide,jump,jzero,halt。

在计算机C上执行一次计算Q可以被定义为一个四元组，$Q=(C,R,I,O)$，其中：

C为计算机
R为有限条指令组成的程序
I是M的一个有限子集，其中存储有输入数据
O是M的一个有限子集，用于存储输出数据

这样，在运行一次计算Q时，计算机C可以按照R的指令，从I中取出输入数据进行一系列运算，并将结果存入O中。

如果最后R调用了halt函数，则计算机最后停机，此时O中就是计算结果；如果Q不能结束，则Q是一个发散计算，例如流处理。

CAM模型

在讨论CAM模型之前，我们先粗略介绍网格计算中涉及的两个基本的参与者：

客户机：计算命令的发起者
服务器：网格中的一个节点，是计算命令的执行者

另外，这两个概念是相对的。在不同的计算任务中，以上角色都可以互换，而且我们对其中的一些协调层角色进行了省略。

使用RAM模型来进行网格计算是十分复杂的，这需要客户机完成大量的数据发送、任务下发工作，服务器完成大量的数据接收、计算等工作。因此，提出了CAM模型。

一个CAM计算机D是一个三元组，$D=(P,M,CI)$,其中这三个元素我们分别介绍。

P

P是计算机的处理器。要注意，这里的处理器不仅仅包含客户机的处理器，也包含网格上各个服务器的处理器。

M

M是计算机的存储器。同样的，不仅包含客户机的存储器，也包含网格上各个服务器的存储器。这些存储器统一编号，即也有$M={M(0),M(1),M(2)……}$。

另外要注意，CAM中的存储器M中的每个存储单元内部是划分区域的，例如将其划分为三个区域。这样，$M(1)$包含三个区域，我们分别记为$M(1,in)$,$M(1,f)$,$M(1,out)$。其中，我们可以让$M(1,in)$存储输入数据，让$M(1,f)$存储计算函数，让$M(1,out)$存储输出结果。对于每个存储单元都遵循这样的三个区域划分。

因此，对于任意一个$M(i)$，它包含了一个$M(i,in)$存储输入数据，一个$M(i,f)$存储计算函数，一个$M(i,out)$存储输出结果。于是，仅依赖这些信息，它可以完成一个计算。我们也让$M(i)$具有运行能力。

当运行$M(i)$时，实际是触发了下面的计算：

$$M(i,out)=(M(i,f))(M(i,in))$$

因此不同于RAM中的存储器，这里的存储器具有执行能力。

CI

CI是计算机的指令集合，该集合是RAM中指令集合Ci的超集。

例如，在CI中存在$Execute M(i)$表示触发运行$M(i)$，这条指令是Ci中没有的。

另外要注意，$Execute M(i)$指令在计算机中仅代表触发运行$M(i)$，而不需要等$M(i)$运行结束。因此，如果存在下面的指令序列：

a;
Execute M(i);
b;

则不等$Execute M(i)$执行结束，便会触发指令$b$。这种定义实际是在发挥计算网格的并行计算能力。

CAM模型讨论

相比于RAM，CAM是RAM的扩充，其P变为一个集群，M具有了运行能力，CI扩充了命令集合。

其中最重要的一点是M具有了运算能力，我们可以将其看做一个包。只要将包中的内容发送给网格中的一个节点$i$，然后使用$Execute M(i)$指令触发它，便可以在节点$i$上并发地进行这个任务。

例如，下面的程序片段便完成了任务下发、执行、回收的过程：

MOV InputData M(7,in);
MOV Function M(7,f);
Execute M(7);
MOV M(7,out) LocalFile;

但是CAM理论并不完善，因为各个节点之间的计算往往是有依赖关系的。例如，节点7的结果作为节点9和节点17的输入等。按照$Execute M(i)$指令的定义，这种异步执行的方式不能满足这种要求。

而如果将$Execute M(i)$修改为非并发的，则会导致网格计算失去并行能力。

什么是湖仓一体？它有什么意义？

Sat, 05 Dec 2020 00:00:00 +0000

看到阿里的湖仓一体，突然想起当时做大数据算法开发时，最怕的事情就是上线。

上线后的第一次运行，十有八九会异常。

那时最常用的还是Hadoop，往往一个任务跑了十几个小时后，总在Mapper到达99.9%的时候宕掉。

不是前期测试的不充分，而是无论如何，前期的测试数据集也无法覆盖真实数据的所有异常。然后，只要遗漏一个点，Mapper就会在最后宕掉。前功尽弃，只能重来。要是赶上工期紧，光吓就能吓个半死。

要想用全量的真实数据做前期验证是不可能的，因为任务所需要的数据往往在不同的地方，且常常数T大小。一是搬不动，二是没地放。因此，很多时候，只能从各处搬运一点数据出来做测试，数据量十分有限。

就别说是开发和测试了，就连算法最终上线后，还要系统专门进行数据搬运。对的，一般我们算法团队产出的是按照规定格式生成的文本文档，没法直接给应用使用。需要系统数据转移模块中的定时任务将其搬运到数据库中，才能在明天供应用使用。

那时就是这样的：开发时搬运数据的工作量大；上线后运行的故障率高；线上系统需要完成数据搬运工作；算法结果往往次日才能入库生效。

大家倒也习以为常，“我们做的就是大数据开发，数据量大，搬来搬去浪费些时间也正常。”

是的，数据量大，搬来搬去浪费些时间当然正常。

可是，真的需要搬来搬去么？

今天我们就来聊一聊。

1 数据湖与数据仓库

很多人说起大数据，对它的印象就是“大”，然后没然后了。但其实不然，大数据也分很多种，通常我们可以通过两个维度来衡量它：结构化程度和信息密度。

数据的结构化程度描述的是数据本身的规范性。例如传统数据库中的数据主要是结构化的，每条记录包含了众多的字段，每个字段是一个独立的信息块。而邮件正文、发言稿件等这些信息就是非结构化的，它没有结构化的格式来约束其中的信息。

数据的信息密度描述的是单位存储体积内包含的信息量的大小。显然，传统数据库中存储的数据的信息密度是很高的，例如性别字段中的0、1就用很小的存储体积标明了一个明确的信息。而邮件正文、发言稿的信息密度是低的，有很多重复的语句，语句中也夹杂很多意义不大的词语甚至可能还有歧义。

大数据处理的过程其实是一个提升数据的结构化程度和信息密度的过程：

获取到的原始数据往往是非结构化的、信息密度很低的；
然后通过数据清洗、分析等等，排除无用的数据、挖掘数据中的关联，不断提升其结构化程度、信息密度；
最后，得到结构化程度较高、信息密度较高的结果，加以利用。

整个过程中，信息的发展如下所示：

其实这时我们可以发现，在大数据的处理过程中，其特征在一直变化。而不同的数据，其适宜的存储介质也是不同的。这就引出了数据湖和数据仓库的概念。

1.1 什么是数据湖

数据湖适合存储非结构化的、信息密度低的、未经清洗的数据。例如生产中我们获取到的日志信息、长文本信息等都可以直接放到数据湖中。例如Hive、Spark等都属于这一类。

“湖”字将它的特点体现的淋漓尽致。水，纳百川，而无形。几乎任何数据都可以往里放，但也因为没有太多规范，里面很杂乱。

数据湖就像是办公桌子上的对其的文档，有一些事笔记，有一些是书本，有一些是打印的材料，杂乱、多样，但是使用起来很方便，你可以从中挑选你喜欢的数据随意组合。

数据湖的这种开放性非常有利于前期的开发、创造。毕竟据说，人的桌子越乱，就越有创造力。数据湖里杂乱的数据就是创造力的象征。

1.2 什么是数据仓库

数据仓库适合存储结构化的、信息密度高的、经过处理后的数据。例如我们通过大数据分析得到的关联信息、画像信息等，都可以放在数据仓库中。例如BigQuery、MaxCompute都属于这一类。

“仓库”一词也将它的特点表现的清清楚楚。仓库，东西要放在规整的货架上，甚至还会给货架编号。这里的数据很规范，用起来没那么灵活。

数据仓库就像是图书馆，里面的数据按照规范放好，你可以按照类别找到想要的信息。

数据仓库的规范性有利于数据的长期、大量存放。即使你到一个新的图书馆，只要按照图书分类法索引，你就能找到想看的书籍。

1.3 湖还是仓？

曾经有一段时间，大家对于大数据的存储形式分裂为了两派。不断询问是选择数据湖，还是选择数据仓库？

选择数据湖，才能拥有数据的多样与灵活，有利于将不同的数据组合在一起，发现新的规律。

选择数据仓库，才能拥有数据的规范与清晰，有利于数据的便捷使用，也利于数据的长时间存储。

2 湖仓一体下的开发

小孩子才做选择题，大人全都要。

最好的形式就是前期在数据湖中进行开发、创造，然后等一切成熟之后，将整理后的数据在数据仓库中存储。

这就带来了一个搬运问题，需要不断把数据湖中的东西搬运到数据仓库。而且，同一份数据可能在数据湖和数据仓库中均有存储。而后期可能会导致数据的不一致。

看来全都要是有代价的！

这就是这个回答最开始说的搬运问题。

那么大的数据，搬起来又冗余，有浪费时间。冗余，浪费的是公司的存储空间，是钱；时间，浪费的是程序员的青春，是钱，更是生命啊！

所以，小孩子不是不想全都要，是真没那个条件。

现在阿里的湖仓一体创造了条件。

湖仓一体，即打通数据仓库和数据湖两套体系，让数据和计算在湖和仓之间自由流动，从而构建一个完整的有机的大数据技术生态体系。这就像是在你的面前放了一个摆满了文档的书桌（数据湖），也放了一个小书架（数据仓库）。于是两者的数据都可以随意获取，在灵活与规范之间取得了平衡！

3 湖仓一体下的公司

刚才说的是我等程序员的开发过程。上升到程序员的集合体——公司，也是一样的。

公司开发大数据产品时，不可能一上来就定义好数据的字段，然后上数据仓库。所以前期肯定要在数据湖中开发，这时，数据量也不大，数据湖成本低且灵活，十分适合。

然是，随着公司的发展，数据湖中的数据就显得杂乱了起来。长此以往，没有人能知道其中数据的具体含义！

于是，得上数据仓库。只有规范数据，才能让数据长久地发挥价值。

可见，对于公司而言：数据湖灵活易上手，对于公司初期发展是好的；数据仓库规范有未来，对于公司的长久发展是好的。

这个时候，就得进行数据的迁移。从数据湖迁移到数据仓库。

哎？

怎么又是迁移？

所以，湖仓一体的好处就体现出来了。

4 总结

所以：数据湖的灵活对于大数据前期开发和公司的前期部署是友好的；数据仓库的规范对于大数据后期运行和公司长期发展是友好的。两者不存在二选一的问题，结合使用是趋势。

而湖仓一体创造了两者结合使用的桥梁，对开发者和公司而言，都比较有意义。

码农福音，公司利器。

什么是边缘计算？

Sat, 07 Nov 2020 00:00:00 +0000

计算机领域的各种概念炒作层出不穷，而我又是一个偏实干的码农。就是从写代码做起，而不是悬在空中做一些概念。

所以当我看到“边缘计算”这一新概念之后，第一反应是看它是不是个纯炒作的概念。

然后调研和思考了一番。

别说，还真不是：

从发展趋势上看，边缘计算是顺应发展的；
从工程实现上看，边缘计算是容易落地的；
从最终收益上看，边缘计算是存在价值的。

在介绍以上内容之前，先说一下边缘计算是什么。

“边缘”二字说的是边缘节点。这是一个网络概念，边缘节点是指那些离用户很近的、不在主干网络上的节点。用户在访问网络中的信息时，请求会先到达边缘节点，然后由边缘节点逐步转发到核心节点上。CDN部署的CDN节点其实就属于边缘节点，这样，用户请求静态资源时，可以在边缘节点上获得，而不需要经过层层转发后从核心节点获得。

“边缘计算”就是在边缘节点上展开计算。在此之前，如果有计算工作，需要边缘节点将请求转发到核心节点上进行。有了边缘计算，则计算工作可以在靠近用户的边缘节点上开展，不需要再到核心节点开展。

1、发展趋势分析

好多年以前，还在本科的我认准了物联网是未来的发展方向，然后侧重朝这方面发展。当然，事实证明，我的方向偏了，毕竟直到现在物联网也没大火过。

那时候，在我（和我的学校、实验室）受限的认知和受限的资金条件下，物联终端采集走的是“终端-上位机-互联网”的路线。终端与上位机之间通过有线或者无线的串口或者并口连接，上位机和互联网之间通过WIFI或者双绞线连接。

下面是本科发的某篇论文中的结构图，可以看到上位机的存在。

而那时的界面也主要在上位机中开发。

所以是以下的三层结构：

互联网：责任重，计算能力强，主要负责数据存储和展示
上位机：责任重，计算能力强，主要负责数据展示
终端：责任轻，计算能力弱，主要负责数据采集

而其实终端可以跨过上位机和互联网相连的。但那时的相关技术还不成熟，有两点：一是终端采用的单片机难以驱动WIFI或者GSM模块；二是有一些上述模块，但真的很贵。所以这两点可以总结为一点：我那时太穷，买不起这些芯片。

是的，那时我们几个团队还经常互相借12864……

到后来，实验室有钱了。这些芯片不在话下，于是我甚至可以终端直接从近海采集数据传到互联网了，如下图。

注意，这里回传的不是视频信号本身。而是一些其他的二值化后的信号。另外，这东西部署在一个近海的钻井平台上，照片中看到的是小岛。

这时变为了两层结构，如下：

互联网：责任重，计算能力强，主要负责数据存储和展示
终端：责任轻，计算能力弱，主要负责数据采集

以上有一个共同的特点就是终端的计算能力很弱，往往只能做数据采集。

曾经我们做项目时还做过数学计算表。就是单片机计算多级的三角函数等都太慢了，所以我们在单片机烧录完主程序后剩下的空间中全部烧录一个计算好的计算表，让单片机通过差别得出近似结果，而不是真正计算。可见，单片机计算能力真的很差，还有就是，计算能力差也有能力差的办法。

之后终端的计算能力并不是没有长进，但是，应用场景的复杂度长进的更快。例如，现在的智能音箱，需要完成自然语言处理等操作，终端显然无法完成。

那这时候，下面的两层结构基本没有改变。只是，终端可以具有展示功能。复杂的计算还是需要借助互联网的服务器集群完成。

互联网：责任重，计算能力强，主要负责数据存储和计算
终端：责任轻，计算能力弱，主要负责数据采集和展示

对于服务器集群而言，它将要负责大量终端传来的计算任务。

那此时，对其进行分流操作十分必要。边缘计算就是对互联网端的计算资源进行的分流。

因此，从趋势上看，边缘计算是顺应发展的。

2、工程实现分析

我们知道，分布式系统是有价值的，但是它的实现成本是极高的。各种分布式算法、分布式中间件绕晕了一群人。

而边缘计算的各个节点之间的网络距离更远，其实现可能比分布式系统更为复杂。如果真是如此的话，边缘计算将只能存在于理论界，难以落地。

然而，万幸，边缘计算的实施难度要比分布式系统低很多。

因为，它不需要追求节点间的一致性。

边缘计算的核心节点负责分配流量，一旦流量分配结束。则某个终端接下来的所有处理均由边缘节点完成，且在整个处理过程中，该边缘节点无需和其他边缘节点同步状态信息。最多，只需要和核心节点同步少量状态信息。

这使得众多边缘节点之间是解耦的，没有了共识、一致性的要求。其实现容易了很多！

然后唯一的难点在于计算逻辑的分发，这点类似于CDN中静态资源的分发，但要略微复杂。因为CDN中的静态资源可以被动同源站保持一致，而边缘计算节点的计算逻辑则要一一推送。但即使这样，实现难度也不大。因为，没有了一致性的要求，推送可以是逐个开展的，甚至可以是分批次地支持灰度测试的开展的。

因此，边缘节点是容易落地的。

3、最终收益分析

边缘计算是很有价值的，可以总结为以下几点：

避免了对单一节点的冲击，分散了计算压力、宕机风险。
减少了核心网络的数据流量。在以前，终端采集的数据量是小的，可能就是几个温湿度值之类的，但是现在，终端采集到的可能是- 声音、图像数据，量很大。采用边缘计算可以减少这些数据在核心网络的传输。
降低了通讯时延，提升了响应速度。大量的数据只需要经过较少的跳数便可以到达边缘节点，提升了网络速度。尤其是在5G推广之后，终端和边缘节点的通讯时延会大大降低。

可见，边缘计算真的很有价值。

4、再说一点

计算机系统的发展总是这样，分分合合。从终端到个人计算机，这是分；从个人计算机到超级计算机，这是合；从超级计算机到分布式系统，这是分。

而边缘计算，就是一次分，从唯一的计算集群分不到边缘节点；但从大视角看，它仍旧是合，所有的计算还是要在互联网上进行。

或许，等终端的计算能力真的突飞猛进，可以独立实现AI等复杂计算的时候，边缘计算才会寿终正寝。那时，也便迎来了真正的分。每个终端可以独立处理复杂事务。

所以，边缘计算是一次合中的分。

智能计算浅思

Sun, 03 Feb 2019 00:00:00 +0000

个人粗鄙地认为，计算智能可以分为三个阶段：

1 第一阶段

固定程序实现有规律的工作，例如专家系统。

给程序一个输入，它给出一个固定的输出。该阶段程序可以代替人类完成有规律的重复劳动。

2 第二阶段

计算智能的第二阶段是程序可以在运行中修正自身参数，例如现在正火的深度学习技术等。

给程序一个输入，它可以给出一个输出，并在此过程中修正自身参数，因此给出的输出可能是人类计算难以甚至不能预测的。

目前的人工智能即处在这一阶段。

该阶段程序可以找出规律的细节规则，并代替人类劳动。

3 第三阶段

程序可以自我生成、修正程序逻辑本身。

例如程序在运行时发生逻辑分支的增删等，直至可以生成程序自身。

目前有最新技术可以让程序自动生成简短的小程序，但是是基于从网上拷贝程序片段实现，离第三阶段要求还很远。

该阶段程序可以总结规律本身，并代替人类劳动。

4 总结

假设计算智能系统为f(ax)，则三个阶段可以概述为：

第一阶段：f(ax)固定不可变
第二阶段：参数a可自动产生并修正
第三阶段：函数f可自动产生并修正

未来可期，未来很远。