dasein58
dasein58_个人页
dasein58
文章
958
问答
0
视频
0
个人介绍
暂无个人介绍
擅长的技术
-
发表了文章 2022-08-15
前端：如何在 JavaScript 中获取当前日期
在我们开发的许多应用程序都会用到某种日期功能，无论是内容的创建日期还是活动的时间戳等等。 处理日期和时间戳格式可能会很麻烦。在本文中，我们将一起学习如何在 JavaScript 中以各种格式获取当前日期。 JavaScript具有一个内置 Date 对象，该对象存储日期和时间并提供相应的处理日期和时间的方法。 要创建 Date 对象的新实例，请使用 new 关键字： const date=new Date(); 该 Date 对象包含一个 Number，表示从新纪元（即1970年1月1日）起经过的毫秒数。 您可以将日期字符串传递给 Date 构造函数以创建指定日期的对象： const date=new Date('Jul 12 2011'); 要获取当前年份，可以使用Date对象的 getFullYear() 实例方法 。getFullYear() 方法返回日期对应的年份： const currentYear=date.getFullYear();console.log(currentYear); //2020 同样，有一些方法可以获取当月的当前日期和当前的月份： const today=date.getDate();const currentMonth=date.getMonth() + 1; getDate() 方法返回当月的当前日期（1-31）。 getMonth() 方法返回指定日期的月份。需要注意的一点是， getMonth()方法返回的是索引值（0-11），其中0表示一月，11表示十二月。因此，加1可以使月份的值标准化。 now()是 Date 对象的静态方法。它返回以毫秒为单位的值，该值表示自纪元以来经过的时间。您可以将now()方法返回的毫秒数传递给Date 构造函数以实例化新的 Date 对象： const timeElapsed=Date.now();const today=new Date(timeElapsed); 我们可以使用Date对象的方法将二手交易平台日期格式化为多种格式（GMT，ISO等）。 toDateString()方法以人类可读的格式返回日期： today.toDateString(); // "Sun Jun 14 2020" toISOString()方法返回遵循ISO 8601扩展格式的日期： today.toISOString(); // "2020-06-13T18:30:00.000Z" toUTCString()方法以UTC时区格式返回日期： today.toUTCString(); // "Sat, 13 Jun 2020 18:30:00 GMT" toLocaleDateString()方法以对地区敏感的格式返回日期： today.toLocaleDateString(); // "6/14/2020" 我们可以在MDN文档中找到Date有关方法的完整参考。 除了上一节中提到的格式外，我们开发应用程序可能具有不同的数据格式。它可以是yy年mm月dd日或yyyy-dd-mm格式，或者类似的东西。 为了解决这个问题，最好创建一个可重用的日期格式化函数，以便可以在多个项目中使用它。 因此，在本节中，我们会创建一个函数，该函数将接收时间格式作为参数，返回对应格式的日期： const today=new Date();function formatDate(date, format) { //}formatDate(today, 'mm/dd/yy'); 我们需要给函数传递格式字符串，字符串中的月份，日期和年份分别用“ mm”，“ dd”，“ yy”来代替。 有了这个格式字符串，我们就可以使用replace()来替换字符串中对应的部分，如下所示： format.replace('mm', date.getMonth() + 1); 但这样会形成链式调用，而且会影响我们函数的灵活度： format.replace('mm', date.getMonth() + 1) .replace('yy', date.getFullYear()) .replace('dd', date.getDate()); 所以我们可以使用正则表达式代替方法来replace()。 首先创建一个对象，该对象将代表子字符串的键值对及其各自的值： const formatMap = { mm: date.getMonth() + 1, dd: date.getDate(), yy: date.getFullYear().toString().slice(-2), yyyy: date.getFullYear()}; 接下来，使用正则表达式匹配并替换字符串： formattedDate=format.replace(/mm|dd|yy|yyy/gi, matched=> map[matched]); 完整的功能如下所示： function formatDate(date, format) { const map={ mm: date.getMonth() + 1, dd: date.getDate(), yy: date.getFullYear().toString().slice(-2), yyyy: date.getFullYear() } return format.replace(/mm|dd|yy|yyy/gi, matched=> map[matched])} 希望通过这篇文章，能让你对JavaScript 中的Date对象有更好的了解。 其实你还可以使用其他第三方库（例如datesj和moment）来处理日期。 可以点击下方"了解更多”报名了解更多学习信息，还可以体验线下十多天的基础培训哦
-
发表了文章 2022-08-13
10本大数据领域经典好书，助力你的学习
学习大数据并不是一蹴而就的事情，即使是工作多年的开发工程师都需要不断补充新鲜的知识内容。目前学习大数据知识可以通过视频和图书两种方式学习，视频的优势在于能够将老师的个人开发经验传授给学习者，而图书的优势在于能够随时翻阅，内容比较丰富。 这里为大家推荐零基础学习大数据的10本经典图书，希望同学们能够通过不同的学习途径充分掌握大数据开发技能。 大数据学习10本经典图书推荐 1、《大数据时代》 《大数据时代》是国外大数据系统研究的先河之作，本书作者维克托·迈尔·舍恩伯格被誉为“大数据商业应用一人”，拥有在哈佛大学、牛津大学、耶鲁大学和新加坡国立大学等多个互联网研究重镇任教的经历，早在2010年就在《经济学人》上发布了长达14页对大数据应用的前瞻性研究。《大数据时代》认为大数据的核心就是预测。大数据将为人类的生活创造前所未有的可量化的维度。书中展示了谷歌、微软、IBM、苹果、facebook、twitter、VISA等大数据先锋们具价值的应用案例。作者围绕“要全体不要抽样、要效率不要绝对精确、要相关不要因果”三大理念，通过数十个商业和学术案例，剖析了万事万物数据化和数据复用挖掘的巨大价值。 2、《一本书读懂大数据》 进入大数据时代，让数据开口说话将成为司空见惯的事情，本书将从大数据时代的前因后果讲起，全面分析大数据时代的特征、企业实践的案例、大数据的发展方向、未来的机遇和挑战等内容，展现一个客观立体、自由开放的大数据时代。 3、《Hadoop权威指南》 Hadoop是大数据技术中的核心内容之一。本书内容丰富，展示了如何使用Hadoop构建可靠、可伸缩的分布式系统，程序员可从中探索如何分析海量数据集，管理员可以了解如何建立与运行Hadoop集群。 4、《Hive编程指南》 Hive是基于Hadoop的一个数据仓库工具。一本ApacheHive的编程指南，旨在介绍如何使用Hive的SQL方法，通过大量的实例，首先介绍如何在用户环境下安装和配置Hive，并对Hadoop和MapReduce进行详尽阐述，演示Hive如何在Hadoop生态系统进行工作。 5、《HBase权威指南》 HBase是一个分布式的面向列的开源数据库。如何通过使用与HBase高度集成的Hadoop将HBase的可伸缩性变得简单；把大型数据集分布到相对廉价的商业服务器集群中；了解HBase架构的细节，包括存储格式、预写日志、后台进程等；在HBase中集成MapReduce框架；了解如何调节二手交易平台集群、设计模式、拷贝表、导入批量数据和删除节点等。 6、《Flink入门与实战》 Flink是一款开源处流处理框架，其河西是Java和Scala编程的分布式流数据流引擎。这是一本Flink入门级图书，力求详细而完整地描述Flink基础理论与实际操作，旨在帮助读者从零开始快速掌握Flink的基本原理与核心功能。 7、《Kafka入门与实践》 Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者在网站中的所有动作流数据。本书是基于Kafka 0.10.1.1版本，深入剖析Kafka源码与框架。书中的大量实例来源于作者在实际工作中的实践，具有现实指导意义。 8、《Spark快速大数据分析》 这是一本为Spark 初学者准备的书，它没有过多深入实现细节，而是更多关注上层用户的具体用法。不过，本书绝不仅仅限于Spark 的用法，它对Spark 的核心概念和基本原理也有较为全面的介绍，让读者能够知其然且知其所以然。 9、《大数据技术全解：基础、设计、开发与实践》 可以作为计算机软件专业的本科生和研究生的大数据技术教材，也可作为大数据技术开发培训、大数据系统咨询规划培训的教材，更是大数据领域内一线的需求分析人员、系统分析人员、高级开发人员和开发管理人员的必备参考书。重点不在于对大数据技术的原理性介绍，而是从实战角度出发，系统地阐述如何基于hadoop开源软件为客户设计、安装和开发一个大数据系统。《大数据技术全解：基础、设计、开发与实践》还着重分享了具体实践中的一些案例，不仅对于从事大数据系统开发的it技术人员具有珍贵的参考价值，而且对准备实施大数据系统项目的企业级客户也具有指导作用。 10、《大数据项目实战》 本书定位在实战系统学习大数据技术实现，是有传智播客教育黑马程序员系统编撰。本书旨在令读者具备Hadoop生态系统的分析能力，并能够构建强大的解决方案来执行大数据分析，同时毫不费力地从大数据分析结果中获得敏锐的洞察力。本书涉及Java语言、Hadoop、Hive、Sqoop的综合运用，同时实现了大数据分析的可视化结果。本书适合Hadoop的初学者阅读，也可以作为高等院校相关课程的教学参考书。读者不仅能够通过项目实战巩固基础知识的学习效果，还能学习商业智能系统的开发过程。全书共分为6章，分别是项目概述、搭建大数据集群环境、数据采集、数据预处理、数据分析与数据可视化。 以上10本书基本覆盖了目前大数据领域的大部分的常用技术，无论是对于零基础入门大数据，还是初级大数据开发工程师都是非常有用的。
-
发表了文章 2022-08-13
6年资深开发带你10分钟了解Kafka ACL机制
在Kafka0.9版本之前，Kafka集群时没有安全机制的。Kafka Client应用可以通过连接Zookeeper地址，例如zk1:2181:zk2:2181,zk3:2181等。来获取存储在Zookeeper中的Kafka元数据信息。拿到Kafka Broker地址后，连接到Kafka集群，就可以操作集群上的所有主题了。由于没有权限控制，集群核心的业务主题时存在风险的。 2.2 身份认证 Kafka的认证范围包含如下： Client与Broker之间Broker与Broker之间Broker与Zookeeper之间 当前Kafka系统支持多种认证机制，如SSL、SASL（Kerberos、PLAIN、SCRAM）。 2.3 SSL认证流程 在Kafka系统中，SSL协议作为认证机制默认是禁止的，如果需要使用，可以手动启动SSL机制。安装和配置SSL协议的步骤，如下所示： 在每个Broker中Create一个Tmp密钥库创建CA给证书签名配置Server和Client 执行脚本如下所示： #! /bin/bash 2# 1.Create rsa 3keytool -keystore server.keystore.jks -alias dn1 -validity 365 -genkey -keyalg RSA 4# 2.Create CA 5openssl req -new -x509 -keyout ca-key -out ca-cert -days 365 6# 3.Import client 7keytool -keystore client.truststore.jks -alias CAROOT -import -file ca-cert 8# 4.Import server 9keytool -keystore server.truststore.jks -alias CAROOT -import -file ca-cert 10# 5.Export 11keytool -keystore server.keystore.jks -alias dn1 -certreq -file cert-file 12# 6.Signed 13openssl x509 -req -CA ca-cert -CAkey ca-key -in cert-file -out cert-signed -days 365 -CAcreateserial -passin pass:123456 14# 7.Import ca-cert 15keytool -keystore server.keystore.jks -alias CARoot -import -file ca-cert 16# 8.Import cert-signed 17keytool -keystore server.keystore.jks -alias dn1 -import -file cert-signed 2.4 SASL认证流程 在Kafka系统中，SASL机制包含三种，它们分别是Kerberos、PLAIN、SCRAM。以PLAIN认证为示例，下面给大家介绍PLAIN认证流程。 2.4.1 配置Server 首先，在$KAFKA_HOME/config目录中新建一个二手文件，名为kafka_server_jaas.conf，配置内容如下： 1KafkaServer { 2 org.apache.kafka.common.security.plain.PlainLoginModule required 3 username="smartloli" 4 password="smartloli-secret" 5 user_admin="smartloli-secret"; 6}; 7 8Client { 9 org.apache.kafka.common.security.plain.PlainLoginModule required 10 username="smartloli" 11 password="smartloli-secret"; 12}; 然后在Kafka启动脚本（kafka-server-start.sh）中添加配置文件路径，设置内容如下： 1[hadoop@dn1 bin]$ vi kafka-server-start.sh 2 3# Add jaas file 4export KAFKA_OPTS="-Djava.security.auth.login.config=/data/soft/new/kafka/config/kafka_server_ 接下来，配置server.properties文件，内容如下： 1# Set ip & port 2listeners=SASL_PLAINTEXT://dn1:9092 3advertised.listeners=SASL_PLAINTEXT://dn1:9092 4# Set protocol 5security.inter.broker.protocol=SASL_PLAINTEXT 6sasl.enabled.mechanisms=PLAIN 7sasl.mechanism.inter.broker.protocol=PLAIN 8 9# Add acl 10allow.everyone.if.no.acl.found=true 11auto.create.topics.enable=false 12delete.topic.enable=true 13advertised.host.name=dn1 14super.users=User:admin 15 16# Add class 17authorizer.class.name=kafka.security.auth.SimpleAclAuthorizer 2.4.2 配置Client 当Kafka Server端配置启用了SASL/PLAIN，那么Client连接的时候需要配置认证信息，Client配置一个kafka_client_jaas.conf文件，内容如下： 1KafkaClient { 2 org.apache.kafka.common.security.plain.PlainLoginModule required 3 username="admin" 4 password="admin-secret"; 5}; 然后，在producer.properties和consumer.properties文件中设置认证协议，内容如下： 1security.protocol=SASL_PLAINTEXT 2sasl.mechanism=PLAIN 最后，在kafka-console-producer.sh脚本和kafka-console-producer.sh脚本中添加JAAS文件的路径，内容如下： 1# For example: kafka-console-producer.sh 2hadoop@dn1 bin]$ vi kafka-console-producer.sh 3 4# Add jaas file 5export KAFKA_OPTS="-Djava.security.auth.login.config=/data/soft/new/kafka\ 6/config/kafka_client_jaas.conf" 2.5 ACL操作 在配置好SASL后，启动Zookeeper集群和Kafka集群之后，就可以使用kafka-acls.sh脚本来操作ACL机制。 （1）查看：在kafka-acls.sh脚本中传入list参数来查看ACL授权新 1[hadoop@dn1 bin]$ kafka-acls.sh --list --authorizer-properties zookeeper.connect=dn1:2181 （2）创建：创建待授权主题之前，在kafka-acls.sh脚本中指定JAAS文件路径，然后在执行创建操作 1[hadoop@dn1 bin]$ kafka-topics.sh --create --zookeeper dn1:2181 --replication-factor 1 --partitions 1 --topic kafka_acl_topic （3）生产者授权：对生产者执行授权操作 1[hadoop@dn1 ~]$ kafka-acls.sh --authorizer kafka.security.auth.SimpleAclAuthorizer --authorizer-properties zookeeper.connect=dn1:2181 --add --allow-principalUser:producer --operation Write --topic kafka_acl_topic （4）消费者授权：对生产者执行授权后，通过消费者来进行验证 1[hadoop@dn1 ~]$ kafka-acls.sh --authorizer kafka.security.auth.SimpleAclAuthorizer --authorizer-properties zookeeper.connect=dn1:2181 --add --allow-principalUser:consumer --operation Read --topic kafka_acl_topic （5）删除：通过remove参数来回收相关权限 1[hadoop@dn1 bin]$ kafka-acls.sh --authorizer-properties zookeeper.connect=dn1:2181 --remove --allow-principal User:producer --operation Write --topic kafka_acl_topic3 在处理一些核心的业务数据时，Kafka的ACL机制还是非常重要的，对核心业务主题进行权限管控，能够避免不必要的风险。
-
发表了文章 2022-08-09
接口自动化测试之Mock
在某些时候，后端在开发接口的时候，处理逻辑非常复杂，在测试的时候，后端在未完成接口的情况下该如何去测试呢？ 我们需要测试，但是有些请求又需要修改一下参数，或者改变一下request实现的方式，比如修改状态码，产生的图片要进行替换，或者是替换执行文件等 Mock介绍 Mock这个词在英语中有模拟的这个意思，因此我们可以猜测出这个库的主要功能是模拟一些东西。准确的说，Mock是Python中一个用于支持单元测试的库，它的主要功能是使用mock对象替代掉指定的Python对象，以达到模拟对象的行为。在项目的单元测试过程中，会遇到：1、接口的依赖2、外部接口调用3、测试环境非常复杂单元测试应该只针对当前单元进行测试, 所有的内部或外部的依赖应该是稳定的, 已经在别处进行测试过的.使用mock 就可以对外部依赖组件实现进行模拟并且替换掉, 从而使得单元测试将焦点只放在当前的单元功能。解决测试依赖例如，我们要测试A模块，然后A模块依赖于B模块的调用。但是，由于B模块的改变，导致了A模块返回结果的改变，从而使A模块的测试用例失败。其实，对于A模块，以及A模块的用例来说，并没有变化，不应该失败才对。这个时候就是mock发挥作用的时候了。通过mock模拟掉影响A模块的部分（B模块）。至于mock掉的部分（B模块）应该由其它用例来测试。例子import requests from unittest import mock def request_lemonfix(): """ :return: """ res=requests.get('http://www.ershouyi.com') return res.status_code.encode('utf-8') if __name__=='__main__': request_lemonfix=mock.Mock(return_value="我已经替换了数据") print(request_lemonfix()) 结果： 我已经替换了二手数据 ` 基本功能 # function.py def multiply(x, y): return x * y def add_and_multiply(x, y): addition=x + y multiple=multiply(x, y) # 回调函数 return (addition, multiple)针对 add_and_multiply()函数编写测试用例 import mockimport requestsimport unittesturl="www.ershouyi.com/login"data={ "user_id": "001", "password": "caichen"}def post_request(url, data): """登陆百度账号""" res=requests.post(url, data).json() return resclass TestLogin(unittest.TestCase): """单元测试""" def setUp(self) -> None: print("case开始执行") def tearDown(self) -> None: print("case执行结束") def test_01(self): """模拟数据判断是否正确""" url="www.ershouyi.com/login/tieba" data={ "user_id": "001" } sucess_test=mock.Mock(return_value=data) post_request=sucess_test res=post_request self.assertEqual("654321", res()) # self.assertEqual({'user_id': '001'},res())if __name__=='__main__': unittest.main()# 错误结果Fcase开始执行======================================================================case执行结束FAIL: test_01 (__main__.TestLogin)模拟数据判断是否正确----------------------------------------------------------------------Traceback (most recent call last): File "C:/Users/x1c/Desktop/untitled/mocktest.py", line 35, in test_01 self.assertEqual("654321", res())AssertionError: '654321' !={'user_id': '001'}----------------------------------------------------------------------Ran 1 test in 0.001sFAILED (failures=1)# 正常结果case开始执行.case执行结束----------------------------------------------------------------------Ran 1 test in 0.000sOK 举个例子来说：我们有一个简单的客户端实现，用来访问一个URL，当访问正常时，需要返回状态码200，不正常时，需要返回状态码404。首先，我们的客户端代码实现如下：import requestsdef send_request(url): r=requests.get(url) return r.status_codedef visit_ustack(): return send_request('http://www.ershouyi.com')# 外部模块调用visit_ustack()来访问ershouyi的官网。下面我们使用mock对象在单元测试中分别测试访问正常和访问不正常的情况。import unittestimport mockimport clientclass TestClient(unittest.TestCase):def test_success_request(self): success_send=mock.Mock(return_value='200') client.send_request=success_send self.assertEqual(client.visit_ustack(), '200')def test_fail_request(self): fail_send=mock.Mock(return_value='404') client.send_request=fail_send self.assertEqual(client.visit_ustack(), '404') 1.找到要替换的对象：我们需要测试的是visit_ustack这个函数，那么我们需要替换掉send_request这个函数。 2.实例化Mock类得到一个mock对象，并且设置这个mock对象的行为。在成功测试中，我们设置mock对象的返回值为字符串“200”，在失败测试中，我们设置mock对象的返回值为字符串"404"。 3.使用这个mock对象替换掉我们想替换的对象。我们替换掉了client.send_request 4.写测试代码。我们调用client.visit_ustack()，并且期望它的返回值和我们预设的一样。 上面这个就是使用mock对象的基本步骤了。在上面的例子中我们替换了自己写的模块的对象，其实也可以替换标准库和第三方模块的对象，方法是一样的：先import进来，然后替换掉指定的对象就可以了。 Mockrunner用在J2EE环境中进行应用程序的模拟测试。它不仅支持Struts actions，servlets，过滤器和标签类，还包括一个JDBC和一个JMS测试框架，可以用于测试基于EJB的应用程序。 Mockrunner扩展了JUnit并模拟了必要的行为，而无需调用实际的基础结构。它不需要正在运行的应用程序服务器或数据库。此外，它不会调用web容器或Struts ActionServlet。它非常快速，使用户可以在测试的所有步骤中操纵所有涉及的类和模拟对象。它可以用于为基于J2EE的应用程序编写非常复杂的单元测试，而不会产生任何开销。Mockrunner不支持任何类型的容器内测试。 Mockrunner不会读取任何配置文件，例如web.xml或struts-config.xml。您可以使用Mockrunner API指定所有参数。因此，可以将servlet，过滤器，标签和Struts动作作为可重用组件进行测试，而不管您在一个或另一个应用程序中使用的设置如何。无法测试配置文件中的定义。如果要这样做，可以将StrutsTestCase用于基于Struts的应用程序或Cactus。 Mockrunner支持Java版本从1.3到1.6以及J2EE 1.3，J2EE 1.4和JavaEE5。尚不支持EJB 3.0。Mockrunner支持Struts版本1.1、1.2和1.3。 下载地址：Mockrunner download | SourceForge.net mockrunner必须配置java环境使用命令启动：java -jar moco-runner-0.12.0-standalone.jar http -p 8801 -c config.json配置config.json文件就可以进行mock数据[ { "response" : { "text" : "Hello, Moco" } } ] ` 使用命令启动： java -jar moco-runner-0.12.0-standalone.jar http -p 8801 -c config.json 访问localhost:8801 就会显示 Hello, MocoMockRunner在工作中运用 构建一个复杂的链接规则[ { "request":{ "uri":"/monitorApplication/alert/confirm", "method":"PUT", "text":"{"id":"123"}" }, "response":{ "status":200, "json":{ "code":"0", "msg":"OK！", "data":null } } } ] 项目中如何做接口测试？通过测试工具...进行参数、请求参数、返回参数效验接口开发过程中如何进行case编写规则文档熟悉通过mock校验格式如何理解Mock模拟返回参数，模拟接口Mock在工作中的运行？帮助前端实现正常开发 好了各位，以上就是这篇文章的全部内容了，能看到这里人啊，都是人才。
-
发表了文章 2022-08-08
Python 中让你相见恨晚的 20 个骚操作
今天和大家分享二十个 Python 编程中新手必会的“骚操作”，使用的频率超高！记得点赞，收藏哦！话不多说，进入正题！ 使用列表推导式创建一个列表。 私信小编01即可获取大量python学习资源 >>> n*10 for n in range(5) 一行代码交换两个变量的值。 >>> m, n=1, 2>>> m, n=n, m>>> m2>>> n1 链式比较操作符。 >>> m, n=3, 'c'>>> 1 < m < 5True>>> 'd' < n < 'f'False 通过切片快速获取序列片段。 >>> lst = [1, 2, 3, 4, 5]>>> lst[:3] # 取前三个数[1, 2, 3]>>> lst[::-1] # 逆序[5, 4, 3, 2, 1]>>> lst[::2] # 步长为2[1, 3, 5]>>> lst[::-2] # 逆序步长为2[5, 3, 1] 通过切片替换序列片段的值。 >>> lst=[1, 2, 3, 4, 5]>>> lst[1:3]=[]>>> lst[1, 4, 5]>>> lst[1:3]=['a', 'b', 'c', 'd']>>> lst[1, 'a', 'b', 'c', 'd'] 计算 10000 次列表推导式创建列表所用时间。 %timeit -n 10000 [n for n in range(5)]# 2.41 μs ± 511 ns per loop (mean ± std. dev. of 7 runs, 10000 loops each) 获取 m，n 中较大的值。 >>> m=4>>> n=2>>> if m > n: print('m')else: print('n')m>>> 'm' if m > n else 'n''m' 还有一种比较少见的写法。 >>> m=4>>> n=2>>> ("n", "m")[m > n]'m' 格式： (, )[condition] 可迭代对象都支持解包。 >>> a, b, c = [1, 2, 3, 4]>>> a1>>> b2>>> c[3, 4]>>> print(range(3))0 1 2 lambda 函数可以接收任意多个参数 (包括可选参数) ，返回单个表达式值。 lambda 函数不能包含命令，只能包含一个表达式。 >>> def func(x, y):return x y>>> func(2, 3)6>>> func=lambda x, y: x y>>> func(2, 3)6 对序列中每一个元素调用指定函数，返回迭代器。 >>> def func(x): return x ** 2>>> list(map(func, [1,2,3]))[1, 4, 9] 使用 lambda 表达式。 >>> list(map(lambda x: x ** 2, [1, 2, 3]))[1, 4, 9] 过滤掉不符合条件的元素，返回二手迭代器。 >>> def func(x): return x % 3==0 >>> list(filter(func, [1, 2 ,3]))[3] 使用 lambda 表达式。 >>> list(filter(lambda x: x % 3 == 0, [1, 2, 3]))[3] 获取两个序列每个元素两两组合的结果。 >>> list1=['a', 'b']>>> list2=['1', '2']>>> (m, n) for m in list1 for n in list2>>> from itertools import product>>> list(product(list1, list2))[('a', '1'), ('a', '2'), ('b', '1'), ('b', '2')] 随机选取序列中的一个元素。 >>> from random import choice>>> lst=[1, 2, 3, 4]>>> choice(lst)3 随机选取序列中的多个元素( 可重复 )。 k 值指定数量。 >>> from random import choices>>> lst = [1, 2, 3, 4]>>> choices(lst, k=3)[4, 3, 4] 随机选取序列中的多个元素( 不重复 )。 k 值指定数量。 >>> from random import sample>>> lst = [1, 2, 3, 4]>>> sample(lst, k=3)[4, 3, 2] 统计序列每个元素出现的次数。 >>> from collections import Counter>>> s = 'python+py'>>> counter = Counter(s)>>> counterCounter({ 'p': 2, 'y': 2, 't': 1, 'h': 1, 'o': 1, 'n': 1, '+': 1}) 返回的结果类似字典，可以使用字典的相关方法。 >>> counter.keys()dict_keys(['p', 'y', 't', 'h', 'o', 'n', '+'])>>> counter.values()dict_values([2, 2, 1, 1, 1, 1, 1])>>> counter.items()dict_items([('p', 2), ('y', 2), ('t', 1), ('h', 1), ('o', 1), ('n', 1), ('+', 1)]) 统计出现次数最多的两个元素。 >>> counter.most_common(2)[('p', 2), ('y', 2)] 字典按照键( key )降序排序。 >>> dic = { 'd': 2, 'c': 1, 'a': 3, 'b': 4}>>> sort_by_key = sorted(dic.items(), key=lambda x: x[0], reverse=False)>>> { key: value for key, value in sort_by_key}{ 'a': 3, 'b': 4, 'c': 1, 'd': 2} 字典按照值( value )降序排序。 >>> dic = { 'd': 2, 'c': 1, 'a': 3, 'b': 4}>>> sort_by_value = sorted(dic.items(), key=lambda x: x[1], reverse=False)>>> { key: value for key, value in sort_by_value}{ 'c': 1, 'd': 2, 'a': 3, 'b': 4} >>> dict1={ 'name': '静香', 'age': 18}>>> dict2={ 'name': '静香', 'sex': 'female'}update() 更新字典。 >>> dict1.update(dict2)>>> dict1{ 'name': '静香', 'age': 18, 'sex': 'female'}字典推导式 >>> { k: v for dic in [dict1, dict2] for k, v in dic.items()}{ 'name': '静香', 'age': 18, 'sex': 'female'}元素拼接 >>> dict(list(dict1.items()) + list(dict2.items())){ 'name': '静香', 'age': 18, 'sex': 'female'}chain() 可以将序列连接，返回可迭代对象。 from itertools import chain>>> dict(chain(dict1.items(), dict2.items())){ 'name': '静香', 'age': 18, 'sex': 'female'}collections.ChainMap 可以将多个字典或映射，并将它们合并。 >>> from collections import ChainMap>>> dict(ChainMap(dict2, dict1)){ 'name': '静香', 'age': 18, 'sex': 'female'}在 Python3.5 以上的版本中，可以通过字典解包进行合并。 >>> { dict1, dict2}{ 'name': '静香', 'age': 18, 'sex': 'female'} zip() 将序列中对应的元素打包成一个个的元组，然后返回由这些元组组成的迭代器。 如果序列的元素个数不一致，则返回列表长度与最短的对象相同。 >>> list1=[1, 2, 3]>>> list2=[4, 5, 6]>>> list3=['a', 'b', 'c', 'd']>>> res=zip(list1, list2)>>> res>>> list(res)[(1, 4), (2, 5), (3, 6)]>>> list(zip(list2, list3))[(4, 'a'), (5, 'b'), (6, 'c')] enumerate 函数可以将可迭代对象组合成一个索引序列，这样遍历时就可以同时获取索引与对应的值。 >>> lst=['a', 'b', 'c']>>> for index, char in enumerate(lst):print(index, char)0 a1 b2 c any(iterable) any all(iterable) all >>> any('')False>>> any([])False>>> any([1, 0, ''])True>>> any([0, '', []])False>>> all([])True>>> all([1, 0, ''])False>>> all([1, 2, 3])True 求 x 的 y 次方，使用 ** 速度更快。 %timeit -n 10000 c = pow(2,10)# 911 ns ± 107 ns per loop (mean ± std. dev. of 7 runs, 10000 loops each)%timeit -n 10000 c = 2 ** 10# 131 ns ± 46.8 ns per loop (mean ± std. dev. of 7 runs, 10000 loops each) 这就是今天要分享的内容，记得点赞哦~提前感谢
-
发表了文章 2022-08-08
Monorepo与multirepo区别何在？
Monorepo是一个新的名词，但不是一个新的概念。从软件开发最开始，我们已经在开始用这种模式了。这种模式的一个中心思想就是，用一个repo来管理所有的源代码。除了这种模式以外，另一个比较受推崇的模式就是multirepo,也就是用多个repo来管理自己的源代码。 不需要深刻思考这两种模式，各有利弊。今天我们来分别说一下这两种模式,但会着重来讲使用Monorepo可能会遇到的问题。 现在比较大型的软件开发公司，比如说Google, Uber, Netflix他们都在使用monorepo。但是对于我们中小型公司或者个人开发者来说，到底需不需要用monorepo,还是选择multirepo? 好，我们就现在具体谈一下monorepo。在这种模式下，你所有的设计文档，所有的源代码，所有的所有都放在一个repo里面。这样做的好处有这些: 你的一次提交可以解决所有的问题。 这个提交可以是添加一个功能，修改一个bug，这个功能添加或者代码修改会涉及很多不同的模块儿，这些模块都可以在一个change request里面做完。 因为所有的这些修改都在一个repo里面，这样你查找历史，查看这些修改之间的关联都比较容易。 当然了，这个好处的获取需要所有的程序员和文档提交者都遵循一个统一的格式。 另一个好处，是所有的人都有访问权限。这样就杜绝了权限申请方面的种种问题。不存在这些代码，某些人看不了的问题。整个开发团队里面没有任何秘密。 好，上面说了monorepo的好处, 那为什么现在很多人都在用multirepo呢? 现在就来说说monorepo的坏处。 Monorepo, 一个最大的问题就是随着程序规模的不断增加，代码量的增加，文档的增加，整个repo会变得越来越大。 我以前做过一个Nike的项目, 那个项目使用的就是monorepo的模式。那个repo当时的大小是21g。怎么样？你的小心肝还能承受得住吧？ 试想一下，一个程序员只想改一下其中的一个翻译文字，你就需要把这21G大小的整个repo都拿到你的本地来。这个过程一定是欲仙欲死的。现在使用multirepo的人一定会对你说good luck。 另一个坏处也是上面说的好处，就是权限访问的问题。Monorepo模式下的权限是开放的。代码安全，文档安全，都会是一个需要好好考虑的问题。 这个方面如果处理不好的话，对整个团队整个项目带来的后果可能是灾难性的。 像google这样的大公司他们都用自己的代码管理系统，那一个程序员要修改一个模块的代码的时候，他需要把所有的项目代码都下载到本地来，并获取最新的代码。做一个修改以后，check in完成就会进行整个项目的编译。整个项目可能需要两个小时的编译时间，这个时候，这个程序员可以跟别人聊聊天，可以学点东西，这也是很好的一种程序员生活。在monorepo的开发模式下，这是一个非常常见的工作状态。 为了对这些修改做好标志，每一次一些标志性的修改都会添加一个版本号。对应一个版本号都会有一个版本历史。对应每个版本号又会有一个对应的标签。大部分时间我们只对最新的版本感兴趣。 接下来我们来看一下multirepo, 在这种模式下，你很少见到一个非常庞大的代码库或者文档库。但这不能说这种模式，就是完美的。它还会有别的其他的问题。 这种模式的总的设计是一个把一个大的问题分成几个小的问题来解决。通过问题的细化，减少整个问题解决的复杂度，从而让自己的工作更加顺手，更加有保障。 上面这个设计是不是听起来很熟悉，对了， 它跟微服务架构是一个理念。 通过这个分解，每一个小部分作为一个单独的repo。每个repo,可以分给不同的小组来开发和管理。每个小组只需要关心这一小部分工作就可以了。每一个小的部分都可以单独的进行买酒测试和开发。这个是好的一个方面。 下面来说一个坏的方面。因为每个小组可以各自为战。这样就给协同工作带来很大的问题。比如说一个小组的模块进行了升级，导致现有的大系统其他模块儿无法正常工作。这种现象在微服务架构系统的开发中非常常见。 如果把这个坏的方面再发挥到极致，就是每个组件之间互相依赖互相破坏，这样子你整体系统可能就陷入万劫不复的深渊。也就是说，随着微服务架构，继续把模块儿进细化，每个模块失去了紧密的联系，与此同时又没有很好的管理机制把握全局， 导致整个项目开发失去了控制，这也是很多微服务架构系统失败的原因。 所以在multirepo的开发过程中，非常重要的一点就是避免过度的细分。一定要有一个机制来把握全局，时刻监控整个开发环境是否正常。 制定标准是一个很有意思的话题， 虽然说技术上很难争高下, 但是总会辩论出一个最好的方案来，但是最严重的有时候根本不是技术上的问题。这个里面就会有很多说不清道不明的问题了。 就因为如此，在一些大公司当中，因为人员的素质都比较高，都是高手，常言说一山不容二虎，这里山中有好几只，几十只老虎。在这种情况下，用一只老虎的标准来把握全局是很难的。 所以宁愿牺牲一些下载时间，编译时间上的代价，最终他们还是继续使用monorepo的模式。 还有一个在multirepo中不可忽视的一个问题就是为了保证一个功能的完整运行, 即使再小的改动，也有可能对所有的repo进行更新。这是一个非常烦人的过程。 我工作过的一个multirepo项目，它里面有20多个模块。要想使整个系统工作完整，你需要把这20多个模块都下载到本地来，当然，你可以采用一些比较简洁的方式，比如说docker container的image, 尽可能的减少与过多的模块儿直接的接触。在这种模式模式下我相信你是非常喜欢黑盒模式的。因为模块太多，你根本不想搞清楚它里面到底在干什么。只要能给你工作就行了。一个是太烦人，另外一个是时间太紧张了。 那么现在的问题就是，上面两种模式哪种更好呢？我的观点是，不管你喜欢哪种模式，选择哪种模式，他们都是你的工具，你要控制他们，而不是他们控制你。 这种模式的本意都是想让你的工作做得更好。 Monorepo你需要做的是尽可能的把你的测试案例细分开。这样你在提交一个修改的时候，就不需要把所有的测试都过一遍，那样太费时间了。 Multirepo对于你自身模块的测试案例，你需要做的是把与你的模块相关的测试案例都放进来。在你提交一个修改的时候，要保证所有的这些案特殊案例都通过。如果需要下载相关模块的修改更新，要尽快通知大家去下载。 一个很常用的模式是这两种模式的结合。你比如说一个修改，你可能需要修改很多个repo， 那你可以考虑把这多个repo合成一个。 这个话题还有很多要可以谈的，我们这一期就先谈这些吧。
-
发表了文章 2022-08-08
Keepalived+LVS+nginx搭建nginx高可用集群
nginx是一款非常优秀的反向代理工具，支持请求分发，负载均衡，以及缓存等等非常实用的功能。在请求处理上，nginx采用的是epoll模型，这是一种基于事件监听的模型，因而其具备非常高效的请求处理效率，单机并发能力能够达到上百万。nginx接收到的请求可以通过负载均衡策略分发到其下一级的应用服务器，这些服务器一般是以集群方式部署的，因而在性能不足的情况下，应用服务器可以通过加机器的方式扩展流量。此时，对于一些特大型的网站，性能的瓶颈就来自于nginx了，因为单机的nginx的并发能力是有上限的，而nginx本身是不支持集群模式的，因而此时对nginx的横向扩展就显得尤为重要。 keepalived是一款服务器状态检测和故障切换的工具。在其配置文件中，可以配置主备服务器和该服务器的状态检测请求。也就是说keepalived可以根据配置的请求，在提供服务期间不断向指定服务器发送请求，如果该请求返回的状态码是200，则表示该服务器状态是正常的，如果不正常，那么keepalived就会将该服务器给下线掉，然后将备用服务器设置为上线状态。 lvs是一款用于四层负载均衡的工具。所谓的四层负载均衡，对应的是网络七层协议，常见的如HTTP协议是建立在七层协议上的，而lvs作用于四层协议上，也即：传输层，网络层，数据链路层和物理层。这里的传输层主要协议有TCP和UDP协议，也就是说lvs主要支持的方式是TCP和UDP。也正是因为lvs是处于四层负载均衡上的，因而其处理请求的能力比常见的服务器要高非常多，比如nginx的请求处理就是建立在网络七层上的，lvs的负载均衡能力是nginx的十倍以上。 通过上面的介绍，我们可以发现，在特大型网站中，应用服务器是可以横向扩容的，而nginx是不支持横向扩容的，此时nginx就会成为性能瓶颈。而lvs是一款负载均衡工具，因而如果我们结合lvs和nginx，那么就可以通过部署多台nginx服务器，通过lvs的负载均衡能力，将请求均衡的分发到各个nginx服务器上，再由nginx服务器分发到各个应用服务器，这样，我们就实现了nginx的横向扩展了。由于nginx本质上也是一款应用服务器，因而其也有可能宕机，因而这里结合keepalived就可以实现nginx的故障检测和服务切换。也就是说，通过keepalived+lvs+nginx，我们实现了nginx的高可用集群模式。 在上面的介绍中，我们会注意到，虽然keepalived+lvs+nginx实现了nginx的集群模式，但是在我们使用nginx的时候，其本身是有一个ip和端口的，默认监听的端口是80和443，那么lvs是如何实现将请求分发给具有不同ip和端口的nginx服务器的呢？这里就是通过虚拟ip实现的，所谓虚拟ip就是对外提供一个公共的ip，外部客户端请求的都是这个ip，lvs在接收到虚拟ip的请求之后，通过配置的调度器和负载均衡策略，选择一个目标nginx服务器，然后将请求转发给该服务器。这里lvs有两个概念，就是调度器和负载均衡策略，所谓的调度器指的是lvs将会以何种方式处理请求和响应数据，其主要有三种调度器： Virtual Server via Network Address Translation(VS/NAT)：这种方式的主要原理是，用户发送请求到虚拟ip上后，lvs会根据负载均衡算法选择一个目标处理服务，然后将请求报文中的目标ip地址修改为计算得到的目标服务器，并且发送给该服务器。对于响应的报文，调度器会将目标服务器返回的响应数据中的源地址修改为虚拟ip地址。通过这种方式，对客户端而言，其形式上面向的是一台服务器。不过这种方式的缺点在于，所有的响应数据都需要通过调度器，如果请求量比较大的情况下，那么调度器就会成为整个系统的瓶颈。Virtual Server via IP Tunneling(VS/TUN)：这种方式主要解决的就是VS/NAT中，响应数据会经过调度器的问题。同VS/NAT一样 ，调度器还是会接收请求的数据，并且将报文中的目标ip修改为目标服务的ip，但是在目标服务处理完数据之后，其会直接将响应报文中的源ip修改为虚拟ip，然后将请求发送给客户端。通过这种方式，响应数据就由各个目标服务进行了处理，而无需通过调度器进行返回，这种方式会大大提高系统的吞吐量，而且由于一般请求报文比响应报文小很多，调度器也只需要处理请求报文，那么系统的整体负载将会被均摊到各个服务器上。Virtual Server via Direct Routing(VS/DR)：这种方式相对于VS/TUN，其主要区别在于，VS/NAT是将请求报文中的ip地址修改为目标服务的ip地址，而VS/DR则是直接将请求报文中的MAC地址修改为目标地址，这种方式效率会更高，因为VS/TUN中的ip地址最终还是需要转换为MAC地址来发送数据的。 1. 环境准备 1. VMware; 2. 4台CentOs7虚拟主机：172.16.28.130, 172.16.28.131, 172.16.28.132, 172.16.28.133 3. 系统服务：LVS, Keepalived 4. Web服务器：nginx 5. 集群搭建：LVS DR模式 2. 软件安装 在四台虚拟机上，我们以如下方式搭建集群： 172.16.28.130 lvs+keepalived 172.16.28.131 lvs+keepalived 172.16.28.132 nginx 172.16.28.133 nginx 这里我们使用172.16.28.130和172.16.28.131两台机器作为lvs+keepalived的工作机器，也就是说这两台机器的作用主要是进行负载均衡和故障检测和下线的；我们使用172.16.28.132和172.16.28.133两台机器作为应用服务器，主要是对外提供服务的。这四台服务器作为整个后端集群服务，并且对外提供的虚拟ip是172.16.28.120。需要说明的是，这里的keepalived所检测的服务是两台lvs服务器，这两台服务器，一台作为master服务器，一台作为backup服务器，两者在负载均衡的配置上是完全一样的。在正常情况下，客户端请求虚拟ip的时候，lvs会将该请求转发到master服务器上，然后master服务器根据减肥配置的负载均衡策略选择一台应用服务器，并且将请求发送给该应用服务器进行处理。如果在某个时刻，lvs的master服务器由于故障宕机了，keepalived就会检测到该故障，并且进行故障下线，然后将backup机器上线用于提供服务，从而实现故障转移的功能。 2.1 lvs+keepalived安装 在172.16.28.130和172.16.28.131上安装ipvs和keepalived： # 安装ipvs sudo yum install ipvsadm # 安装keepalived sudo yum install keepalived 在172.16.28.132和172.16.28.133上安装nginx： # 安装nginx sudo yum install nginx 需要注意的是，在两台nginx服务器上需要将防火墙关闭，否则lvs+keepalived的两台机器就无法将请求发送到两台nginx服务器上来： # 关闭防火墙 systemctl disable firewalld.service 查看两台负载均衡机器是否支持lvs： sudo lsmod |grep ip_vs # 如果看到如下结果，则说明是支持的 [zhangxufeng@localhost ~]$ sudo lsmod|grep ip_vs ip_vs 145497 0 nf_conntrack 137239 1 ip_vs libcrc32c 12644 3 xfs,ip_vs,nf_conntrack 如果上述命令没有任何结果，则执行sudo ipvsadm命令启动ipvs之后，再通过上述命令进行查看即可。启动ipvs之后，我们就可以在/etc/keepalived/目录下编辑keepalived.conf文件，我们以172.16.28.130机器作为master机器，master节点配置如下： # Global Configuration global_defs { lvs_id director1 # 指定lvs的id } # VRRP Configuration vrrp_instance LVS { state MASTER # 指定当前节点为master节点 interface ens33 # 这里的ens33是网卡的名称，通过ifconfig或者ip addr可以查看 virtual_router_id 51 # 这里指定的是虚拟路由id，master节点和backup节点需要指定一样的 priority 151 # 指定了当前节点的优先级，数值越大优先级越高，master节点要高于backup节点 advert_int 1 # 指定发送VRRP通告的间隔，单位是秒 authentication { auth_type PASS # 鉴权，默认通过 auth_pass 123456 # 鉴权访问密码 } virtual_ipaddress { 172.16.28.120 # 指定了虚拟ip } } # Virtual Server Configuration - for www server # 后台真实主机的配置 virtual_server 172.16.28.120 80 { delay_loop 1 # 健康检查的时间间隔 lb_algo rr # 负载均衡策略，这里是轮询 lb_kind DR # 调度器类型，这里是DR persistence_time 1 # 指定了持续将请求打到同一台真实主机的时间长度 protocol TCP # 指定了访问后台真实主机的协议类型 # Real Server 1 configuration # 指定了真实主机1的ip和端口 real_server 172.16.28.132 80 { weight 1 # 指定了当前主机的权重 TCP_CHECK { connection_timeout 10 # 指定了进行心跳检查的超时时间 nb_get_retry 3 # 指定了心跳超时之后的重复次数 delay_before_retry 3 # 指定了在尝试之前延迟多长时间 } } # Real Server 2 Configuration real_server 172.16.28.133 80 { weight 1 # 指定了当前主机的权重 TCP_CHECK { connection_timeout 10 # 指定了进行心跳检查的超时时间 nb_get_retry 3 # 指定了心跳超时之后的重复次数 delay_before_retry 3 # 指定了在尝试之前延迟多长时间 } } } 上面是master节点上keepalived的配置，对于backup节点，其配置与master几乎是一致的，只是其state和priority参数不同。如下是backup节点的完整配置： # Global Configuration global_defs { lvs_id director2 # 指定lvs的id } # VRRP Configuration vrrp_instance LVS { state BACKUP # 指定当前节点为master节点 interface ens33 # 这里的ens33是网卡的名称，通过ifconfig或者ip addr可以查看 virtual_router_id 51 # 这里指定的是虚拟路由id，master节点和backup节点需要指定一样的 priority 150 # 指定了当前节点的优先级，数值越大优先级越高，master节点要高于backup节点 advert_int 1 # 指定发送VRRP通告的间隔，单位是秒 authentication { auth_type PASS # 鉴权，默认通过 auth_pass 123456 # 鉴权访问密码 } virtual_ipaddress { 172.16.28.120 # 指定了虚拟ip } } # Virtual Server Configuration - for www server # 后台真实主机的配置 virtual_server 172.16.28.120 80 { delay_loop 1 # 健康检查的时间间隔 lb_algo rr # 负载均衡策略，这里是轮询 lb_kind DR # 调度器类型，这里是DR persistence_time 1 # 指定了持续将请求打到同一台真实主机的时间长度 protocol TCP # 指定了访问后台真实主机的协议类型 # Real Server 1 configuration # 指定了真实主机1的ip和端口 real_server 172.16.28.132 80 { weight 1 # 指定了当前主机的权重 TCP_CHECK { connection_timeout 10 # 指定了进行心跳检查的超时时间 nb_get_retry 3 # 指定了心跳超时之后的重复次数 delay_before_retry 3 # 指定了在尝试之前延迟多长时间 } } # Real Server 2 Configuration real_server 172.16.28.133 80 { weight 1 # 指定了当前主机的权重 TCP_CHECK { connection_timeout 10 # 指定了进行心跳检查的超时时间 nb_get_retry 3 # 指定了心跳超时之后的重复次数 delay_before_retry 3 # 指定了在尝试之前延迟多长时间 } } } 将master和backup配置成完全一样的原因是，在master宕机时，可以根据backup的配置进行服务的无缝切换。 在lvs+keepalived机器配置完成之后，我们下面配置两台应用服务器的nginx配置。这里我们是将nginx作为应用服务器，在其配置文件中配置返回状态码为200，并且会将当前主机的ip返回，如下是其配置： worker_processes auto; # pid /run/nginx.pid; events { worker_connections 786; } http { server { listen 80; # 这里是直接返回200状态码和一段文本 location / { default_type text/html; return 200 "Hello, Nginx! Server zhangxufeng@172.16.28.132 "; } } } worker_processes auto; # pid /run/nginx.pid; events { worker_connections 786; } http { server { listen 80; # 这里是直接返回200状态码和一段文本 location / { default_type text/html; return 200 "Hello, Nginx! Server zhangxufeng@172.16.28.133 "; } } } 可以看到，两台机器返回的文本中主机ip是不一样的。nginx配置完成后，可以通过如下命令进行启动： sudo nginx 在启动nginx之后，我们需要配置虚拟ip，这是因为我们使用的lvs调度器是DR模式，前面我们讲到过，这种模式下，对客户端的响应是真实服务器直接返回给客户端的，而真实服务器需要将响应报文中的源ip修改为虚拟ip，这里配置的虚拟ip就是起这个作用的。我们编辑/etc/init.d/lvsrs文件，写入如下内容： #!/bin/bash ifconfig lo:0 172.16.28.120 netmask 255.255.255.255 broadcast 172.16.28.120 up route add -host 172.16.28.120 dev lo:0 echo "0" > /proc/sys/net/ipv4/ip_forward echo "1" > /proc/sys/net/ipv4/conf/lo/arp_ignore echo "2" > /proc/sys/net/ipv4/conf/lo/arp_announce echo "1" > /proc/sys/net/ipv4/conf/all/arp_ignore echo "2" > /proc/sys/net/ipv4/conf/all/arp_announce exit 0 lo：表示当前主机真实网卡的名称；172.16.28.120：表示虚拟ip； 编写完成后运行该脚本文件即可。然后将两台lvs+keepalived机器上的keepalived服务启动起来即可： sudo service keepalived start 最后可以通过如下命令查看配置的lvs+keepalived的策略： [zhangxufeng@localhost keepalived]$ sudo ipvsadm -ln IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 172.16.28.120:80 rr -> 172.16.28.132:80 Route 1 0 0 2.2 集群测试 根据上述步骤，我们配置完成了一个lvs+keepalived+nginx的集群。在浏览器中，我们可以访问www.ershouyi.com即可看到如下响应： Hello, Nginx! Server zhangxufeng@172.16.28.132 多次刷新浏览器之后，可以看到浏览器中显示的文本切换如下，这是因为lvs的负载均衡策略产生的： Hello, Nginx! Server zhangxufeng@172.16.28.133 3. 小结 本文首先对lvs和keepalived的工作原理进行了讲解，分别介绍了其工作的几种模式，然后对lvs+keepalived+nginx搭建nginx集群的方式进行详细讲解，并且说明了其中所需要注意的问题。 作者：爱宝贝丶
-
发表了文章 2022-02-16
如何快速构建Slim Docker映像
您还记得那些日子，当您编写出色的软件，但无法将其安装在其他人的计算机上，或刚安装就崩溃？ 虽然这从来都不是很好的体验，但我们总是可以说 如今，由于容器化，这已不再是借口。 简而言之，通过容器化，您可以将应用程序和所有必要的依赖项打包到镜像中。 执行时，您将该镜像作为容器运行。 这样一来，您就不必为弄乱他人的系统而运行您的软件。 如果容器在您的计算机上运行，则您的软件应随即运行。 这对于数据科学家在部署依赖于不同软件包和版本的模型时也很有用。 对我来说，数据科学家必须知道如何创建镜像和容器。 众所周知，Docker是该领域的主要参与者，并且Docker镜像无处不在。 这很棒，因为您可以轻松地并排启动不同版本的数据库。 将您的应用程序镜像合并在一起也非常简单。 这是由于大量的基本镜像和简单的定义语言所致。 但是，当您在不知道自己在做什么的情况下将镜像混合在一起时，就会遇到两个问题。 · 由于镜像不必要地发胖，您浪费了磁盘空间。· 您等待太长时间的构建会浪费时间。 在本文中，我想向您展示如何缓解这两个问题。 幸运的是，这仅需要您了解Docker提供的一些技巧和技术。 为了使本教程有趣且有用，我向您展示了如何将Python App打包到Docker映像中。 你准备好了吗？ 让我们继续。 教程 假设我们所有的代码都位于一个Python文件main.py中。 因为我们很酷，所以我们使用最新最好的Python版本，在撰写本文时为3.8。 我们的应用程序只是一个简单的Web服务器，它依赖于Pandas，fastapi和uvicorn。 我们将依赖项存储在requirements.txt文件中。 在本地，我们在虚拟环境中开发应用程序。 该环境位于与代码位于同一文件夹中的名为.venv的文件夹中（这很快变得很重要）。 现在，我们决定将所有内容打包到Docker映像中。 为此，我们要做的就是 · 使用可用于Python 3.8的基本映像。· 复制代码和需求文件。· 在映像中安装需求和依赖项。· 公开运行我们的应用程序的命令 我们的Docker映像的第一个版本看起来像 FROM python:3.8.0-slim COPY . /app RUN apt-get update \ && apt-get install gcc -y \ && apt-get clean WORKDIR app RUN pip install --user -r requirements.txt ENTRYPOINT uvicorn main:app --reload --host 0.0.0.0 --port 8080 除了我们的代码和要求之外，我们还需要安装GCC，因为FastApi在安装时需要这样做。 我们通过以下方式建立我们的形象 docker build -t my-app:v1 . 该映像的大小约为683 MB，需要大约一分钟的时间来构建（不下载基础映像）。 让我们看看这种情况如何减少时间。 基本镜像 关于基本镜像，我已经使用Python slim做出了明智的选择。 我为什么要选择那个呢？ 例如，我可以使用完整的Ubuntu或CentOS映像，这将导致映像大小> 1GB。 但是，由于我只需要Python，因此无需安装所有组件。 在图像大小的低端，我们可以使用python：3.8.0-alpine。 但是，我的代码依赖于Pandas，这在高山上安装很麻烦。 高山也有关于稳定性和安全性的问题。 此外，slim仅比alpine大80MB，这还是可以的。 有关如何选择最佳Python图像的更多信息，请向有兴趣的读者介绍该文章。 构建上下文 构建镜像时，打印到控制台的第一行显示：将构建上下文发送到Docker守护程序。 在我的计算机上，这花费了大约5秒钟，并且发送了154 MB。 这是怎么回事 Docker将构建上下文中的所有文件和文件夹复制到守护程序。 在这里，构建上下文是存储Dockerfile的目录。由于我们只需要两个文本文件，所以154 MB听起来很多，不是吗？ 这样做的原因是Docker复制了所有内容，例如包含虚拟环境的.venv文件夹或.git文件夹。 要解决此问题，您只需在Dockerfile旁边添加一个名为.dockerignore的文件。 在此文件中，逐行列出了Docker不应该复制的内容。 就像git对.gitignore文件所做的一样。 举一个小例子，假设我们的文件夹中有几个Excel文件和PNG，我们不想复制它们。 .dockerignore文件看起来像 *.xlsx *.png venv .venv .git 在我们的示例中，添加此文件后，"将构建上下文发送到docker"仅花费几毫秒，并且仅发送了7.2 kb。 我将映像大小从683 Mb减小到了529 Mb，这大约是以前构建上下文的大小。 真好！ 添加.dockerignore文件有助于加快构建速度并减小图像大小。 层缓存 如前所述，在我的计算机上构建此映像大约需要60秒钟。 我估计大多数时候，大约有99.98％的时间用于安装需求和依赖项。 您可能会认为现在这里没有太多的改进空间。 但是有些时候您必须经常构建映像！ 为什么？ Docker可以利用层缓存。 Docker文件中的每一行都代表一个层。 通过添加/删除行中的内容，或更改其引用的文件或文件夹，可以更改图层。 发生这种情况时，将重建此层以及其下的所有层。 否则，Docker将使用该层的缓存版本。 要利用该漏洞，您应该对Dockerfile进行结构化，以便经常不变的层应该出现在Dockerfile的开头附近。 在这里安装编译器是一个很好的例子。经常变化的层应该出现在Dockerfile的结尾附近。 复制源代码是古董的完美示例。 酷。 理论足够，让我们回到我们的例子。 假设您没有更改要求，而只更新了代码。 开发软件时，这很常见。 现在，每次构建映像时，都会重新安装这些讨厌的依赖项。 建立镜像始终需要相同的时间。 烦人！ 我们还没有使用缓存。 神奇的新Dockerfile来解决您的问题 FROM python:3.8.0-slim RUN apt-get update \ && apt-get install gcc -y \ && apt-get clean COPY requirements.txt /app/requirements.txt WORKDIR app RUN pip install --user -r requirements.txt COPY . /app ENTRYPOINT uvicorn main:app --reload --host 0.0.0.0 --port 1234 看起来并没有什么魔力和不同，对吧？ 我们要做的唯一一件事就是首先安装GCC，然后分别复制需求和复制源代码。 GCC和依赖项更改很少。 这就是为什么此层现在显示得很早的原因。 需求变更也比GCC缓慢但频繁。 这就是为什么该层位于GCC之后。 我们的源代码经常更改。 因此，将其复制会发生得较晚。 现在，当我们减肥源代码并重建映像时，由于Docker使用缓存的层，因此不会重新安装依赖项。 现在，重建几乎不需要时间。 太好了，因为我们可以花更多的时间来测试和执行我们的应用程序！ 多阶段构建 在示例图像中，我们必须安装GCC才能安装FastApi和uvicorn。 但是，对于运行该应用程序，我们不需要编译器。 现在想象您不仅需要GCC，还需要其他程序，例如Git，CMake，NPM或…。 您的生产形象越来越胖。 多阶段构建，助我们一臂之力！ 使用多阶段构建，您可以在同一Dockerfile中定义各种镜像。 每个镜像执行不同的步骤。 您可以将从一个镜像生成的文件和工件复制到另一个镜像。 最常见的情况是，您有一个用于构建应用程序的镜像，另一个是用于运行应用程序的镜像。 您需要做的就是将构建工件和依赖项从构建镜像复制到应用程序映像。 对于我们的示例，这看起来像 # Here is the build image FROM python:3.8.0-slim as builder RUN apt-get update \ && apt-get install gcc -y \ && apt-get clean COPY requirements.txt /app/requirements.txt WORKDIR app RUN pip install --user -r requirements.txt COPY . /app # Here is the production image FROM python:3.8.0-slim as app COPY --from=builder /root/.local /root/.local COPY --from=builder /app/main.py /app/main.py WORKDIR app ENV PATH=/root/.local/bin:$PATH ENTRYPOINT uvicorn main:app --reload --host 0.0.0.0 --port 1234 构建该文件时，最终的生产映像大小为353 MB。 这大约是我们第一个版本的大小的一半。 恭喜，还不错。 请记住，您的生产镜像越小，效果越好！ 附带说明，多阶段构建还可以提高安全性。 为什么呢？ 假设您需要一个密钥（例如SSH密钥）来在构建时访问某些资源。 即使您在以后的层中删除了该机密，它仍在先前的层中存在。 这意味着有权访问您的图像的人可以获取该密钥。 在多阶段构建中，您仅复制必要的运行时工件。 因此，生产镜像永远都看不到密钥，而您已经解决了该问题。 有关多阶段构建的更多详细信息，我请读者参考本文和本文。 总结 在本文中，我向您展示了一些简单的技巧和窍门，说明如何创建更快构建的较小的Docker映像。 记得 始终添加.dockerignore文件。考虑一下图层的顺序，并将其从缓慢变化的动作转变为快速变化的动作。尝试使用和利用多阶段构建。 我希望这将为您节省一些磁盘空间和时间。 感谢您关注这篇文章。 与往常一样，如有任何问题，意见或建议，请随时与我联系。
-
发表了文章 2022-02-15
小程序云开发入门介绍
微信小程序刚出没多久时，曾经上手写过demo，但开发体验比较差，所以一直没怎么关注。不过自从诸多适配方案出炉，以及云端的开通，觉得还是有必要上手体验一番的。 原生开发我是不想再试了，那就选一种适配方案，目前比较知名的有基于vue的 mpvue，umi-app，基于react 的 taro，以及TX团体出的全新框架 wepy。个人对 react 的好感 以及 taro 框架的走向成熟，促使我选择了 taro。 云端开发就是将普通小程序的传统后端切换为微信提供的轻量级云端。而这个云端服务部分的开发其实是针对前端开发的，前端工程师很容易就能全栈开发出一整个小程序。但是这种轻量级解决方案也只是针对业务简单的项目，因为公共平台肯定有各种限制，它的出现只是让我们多了一个选择方案而已。 接着进入主题，项目大体目录结构如下 client #前端目录 ├── config #配置 ├── dist #输出 ├── src #源目录 └── index.html #入口文件 cloud #云目录 ├── dao #数据库操作函数集合 ├── login #登录云函数 └── ... #其他 前端 小程序的前端部分，想必不用过多讲解，因为这都是古玩论坛前端的基本功。就以首页为样例，使用了typeScript，主要功能是分页加载数据，调用微信提供的触发到达底部的api，onReachBottom即可。 taro 相关部分的使用请看 taro import Taro, { Component, Config } from "@tarojs/taro"; import { View, Text, Navigator } from "@tarojs/components"; import "./index.scss"; interface IState { loading: boolean; size: number; page: number; total: number; list: Array<{ _id: string; summary: object }>; context:object; } export default class Index extends Component<{}, IState> { state={ loading: false, size: 10, page: 0, total: -1, list: [], context:{} }; config: Config={ navigationBarTitleText: "Jeff's Blog", onReachBottomDistance: 50 }; componentWillMount() { this.getList(); this.getLogin(); } getDbFn(fn, param) { return Taro.callFunction({ name: "dao", data: { fn, param } }); } onReachBottom() { this.getList(); } getList() { const { size, page, total, loading }=this.state; if (loading) return; TaroLoading({ title: 'loading', }); if (total >=0 && size * page >=total) return; this.setState({ loading: true }); this.getDbFn("getList", { size, page: page + 1 }).then(res=> { Taro.hideLoading(); const total=res.result.total; const list=this.state.list.concat(res.result.list); this.setState({ loading: false, page: page + 1, total, list }); }).catch(err=> { Taro.hideLoading(); this.setState({ loading: false }); }); } onShareAppMessage (res) { return { title: "Jeff's Blog", path: '/pages/index/index' } } render() { return ( {this.state.list.map(l=> ( {l.summary.title} {l.summary.tags.map(t=> ( {t} ))} {l.summary.date} ))} ); } } 与普通小程序不同的地方就是调用云端，云函数调用如官方样例所示 getLogin(){ Taro.callFunction({ name: "login", data: {} }).then(res=> { this.setState({ context: res.result }); }).catch(err=>{ }); } 云端 云端数据库是个文档型，操作风格与mongodb如出一辙，格式自然是json。最有用的还是操作数据库的部分，操作方法都已经 Promise 化，调用还是比较方便的。具体内容请查看文档: 小程序云开发 //数据库引用 const db=wx.database() //获取数据集合 const todos=db.collection('todos') //获取记录数 todos.count(); //条件查找 todos.where({done: false,progress: 50}).get() //插入 todos.add({data: {content:'11',time:new Date()}},success:(res){}); //更新 todos.doc('todo').update({ data: { done: true}},success:(res){}); //删除 todos.where({done:true}).remove(); //分页查找 todos.orderBy('time','desc') .skip(start) .limit(size) .get(); 云函数 调用云端的方式就要使用云函数，就以下面数据库操作库为例 // 云函数入口文件 const cloud=require("wx-server-sdk"); cloud.init(); // 云函数入口函数 exports.main=async (event, context)=> { const { fn, param }=event; return daofn; }; // 调用数据库 const db=cloud.database(); // 表 const posts=db.collection("posts"); const tags=db.collection("tags"); const dao={ async getList({ page=1, size=10 }) { const start=(page - 1) * size; try { const { total }=await posts.count(); const { data }=await posts .field({ summary: true }) .orderBy('num','desc') .skip(start) .limit(size) .get(); return { code: 0, list: data, total, message: "sucess" }; } catch (err) { return { code: -1, list: [], total: -1, err: err, message: "error" }; } }, getPost({ id }) { return posts.doc(id).get(); }, async getTagList({ tag }) { try{ const { data }=await tags.where({ name: tag }).get(); if(!data.length){ return { code:0, list:[], message: "success" }; } const list=data[0].list.sort((a,b)=> b.num - a.num); return { code:0, list:list, message: "success" }; } catch(err){ return { code: -1, list:[], err: err, message: "error" }; } } } 将操作数据库的所有云函数合并成一个文件，将云函数入口封装一下，即把函数名字和参数都做完参数 exports.main=async (event, context)=> { const { fn, param }=event; return daofn; }; 对应前端部分也封装出一个调用数据库的方法 getDbFn(fn, param) { return Taro.callFunction({ name: "dao", data: { fn, param } }); } 云端部分开发完之后，在微信开发者工具里面上传云端代码即可，而其余部分的流程和普通小程序一样，这里也不再介绍。
-
发表了文章 2022-02-14
刘江川：从“边缘”到“中心”，边缘计算科学家的创业之路
随着人工智能、物联网、5G等前沿技术的迅猛发展，海量数据、超低延时等需求都对现有的云计算模式提出了挑战，一时间，边缘计算成为了技术领域炙手可热的话题。 边缘计算是指在靠近物或数据源头的一侧，采用网络、计算、存储、应用核心能力为一体的开放平台就近提供本地化服务，应用程序在边缘侧执行，在节省带宽的情况下产生更快的网络服务响应，满足行业在实时业务、应用智能、安全与隐私保护等方面的基本需求。据权威市场调研公司预测，到2023年，全球边缘计算市场将从2022年的106亿美元增加到210亿美元，复合年增长率为14.2%。 正当联想、阿里等名企纷纷宣布布局边缘计算业务时，一家成立于2022年的初创公司-江行智能已经凭借先发优势，立足空白市场，成为该领域的领跑者。 江行智能江是一家致力于先进边缘计算技术的开发及其在能源互联网、工业安监、智慧仓储等领域的应用。公司成立伊始即获得红杉资本中国种子基金数千万元的风险投资。经过一年的发展，公司团队逐渐壮大，在深圳、北京设有分部，总部位于南京，并与南方电网、北控水务、中国联通等大客户建立合作，在边缘计算领域独占鳌头。 那么江行智能缘何成为边缘计算的佼佼者？背后又有着怎样的创业故事及产业发展思考，带着这些疑问， 清华校友总会AI大数据专委会、清数大数据产业联盟独家采访了江行智能董事长刘江川。 刘江川，香港地区第一位微软学者，微软中国研究院(后来的微软亚洲研究院）成立后的第一批实习生；1999 年毕业于清华大学计算机系，2003 年获得香港科技大学的博士学位，于 2022 年被评为 IEEE Fellow（国际电气与电子工程师协会院士，学术科学界公认的顶级荣誉和重要职业成就）。并且在 2022 年，他被评为加拿大工程院院士，现任加拿大西蒙菲莎大学计算机学院终身教授，清华大学EMC讲席教授。 以下内容为采访实录整理。 一、成功的科学家转型创业者 当被问及为什么要从一个成功的科学家转型到创业时，刘江川教授坦诚表达出想要看到自己科学研究的成果实现转化落地的愿望，他认为市场验证是科学研究的另一种更大的挑战，并以一颗学者的赤子之心将创业看做是一次学习与经验的积累，甚至希望从中获得更多启示。 1、您是著名学者、院士，应该说已经登上了科学研究的高峰，您创业的动机是什么？是哪些因素促使您开始创业的？ 刘江川：首先，我从事的是IT行业，IT行业自带创业基因， IT产业的发展始终遵循着摩尔定律预测的速度，在IT产业内还有许多崭新的东西需要不断地去开拓。 第二，在学术方面我做的是与工程领域接近的基础科学研究，有很多算法、技术接近产品的应用都可以在工程领域应用，甚至和微软、诺基亚、华为以及诸多加拿大本地公司有着紧密的合作，所以我希望自己的研究能够完整落地，而且我认为只有从创业到落地，才能真正理解IT行业精髓或技术精髓。 第三，时机成熟了，早期我的精力主要集中在科学研究方面，现在事业到达一定阶段了，积累的技术、人脉使我有信心来创业。 2、您创业又是为了实现怎样的人生追求？ 刘江川：人生追求主要有两点，技术方面，我想见到自己的基础研究能够真正的在现实场景落地。原来论文为主的研究大部分以原型验证为主，并不是真正在市场上得到验证。市场验证是另外一种更大的挑战，我希望能够真正做到这一点。 第二个追求，理论上的东西最终抵不过实践上的体验，像OFO、社交媒体、云计算厂商很多例子，从前对我来说都只是故事，我不会把它跟我的研究直接挂钩。但实际上很多研究，比如网络的可扩充性（Scalability），网络或云计算技术应该往哪个方向走，实际上跟资本的发展、落地面临的挑战或者行业的需求是息息相关的。 所以我认为很多信息技术的发展实际上是由资本力量来推动的。社交媒体、自媒体、云计算和边缘计算背后都有资本的专科力量推动，那么资本的力量是怎样推动信息技术发展的，推动过程中会带来哪些好处和弊端，我想通过创业获得一些经验，对于事业发展，对于推动IT行业，对于将来继续从事研究工作，都能得到不少启示。如果只是在实验室里面，停留在纸面理论推导，就会导致跟实际脱节。 3、从一个成功的科学家到一个创业者，您如何应对这种角色和身份的转换？ 刘江川：从科学研究到产品落地，这是一个不断学习的过程。一方面是有困惑、有痛苦的挑战，另一方面又能学到新的知识。过去科学研究没有真正接触过市场，现在可以通过产品在市场上的反馈，指导市场行为，或者对具体的行为做抽象的理论化分析是很有意思的事情。另外，角色转换的调整还源自于团队给予的力量，团队会推动我更快的进入新角色。 4、您创业一年多的时间，这个过程当中有没有遇到一些比较困难的问题？我们是如何解决的？ 刘江川：我认为对初创公司来说三件事，第一，组建团队，由大学教授组建的团队基本是师生模式，在创业后会面临着学生会天然敬畏老师，缺乏自主权，嫡系误解团队融合等问题。江行智能的创始团队主要都是我的学生和我同学，大家都有创业的想法聚集在一起，彼此信任。为了避免前面问题的发生，我们在创业之初就理清了从师生关系到合伙人关系的转变，要做一家正规的公司，并通过社招扩张推动公司从学校实验室阶段脱离。 第二，产品需要在市场上得到认可和推广，我认为初创公司来做有两种模式，一种是初期并不考虑市场需求，长的时间对一款拥有核心技术的产品精雕细琢，用这款产品设法打开市场。但产品能不能打开市场，实际上是在初期会存在疑问的。江行智能采用的模式是在有价值和潜力的市场内，挖掘市场需求，基于市场反馈打造产品并不断提升。 在与市场反馈结合的过程中，也会面临反复或者是推倒重来的情况，比如初期设想的产品测算市场容量未必如你想象的那么大，或者中途发现潜在竞争对手在特定的方向做的比你更好。另外原本你以为并不大的市场最后发现竞争对手在这一领域做成功了，甚至有些竞争对手还有特殊渠道，即使你有跟对手同样的技术或者领先于对手的技术，也没有办法公平竞争。以上各种情况都要做好心理准备。 第三，融资，如何说服投资方是一个需要学习的过程，幸运的是我们团队的COO庞海天既有技术储备又有融资经验，在融资这块我们比较幸运。 创业一年多也曾感觉过迷茫，甚至放弃的念头都是有的。创业之初，想象的产品形态和市场都很美好，真正开始跟市场接触的时候发现并非如此，需要经历一段摸索期，初创公司可能会面临有钱却花不出去的尴尬境地。这有点像做研究，博士找不到课题时，有充足的富裕时间不知道做什么，但一旦真正找对课题之后，速度和进展就会快很多。江行智能在找对市场和产品之前也有过一段迷茫期，经过充足的市场调查、竞品调研后，我们凭借团队本身在研究方面的技术积累和深刻理解，与研究机构或者其他先进的研发机构建立紧密交流与合作，快速洞悉市场信息，消化信息，并将此反映在产品形态上面。后来度过了这个阶段，江行智能进入了全力扩张期。 5、您作为一个知名的科学家，院士的身份，对您的创业有没有什么帮助？ 刘江川：院士的身份在资本认可、地方政府认可、特别在PR上面都有一定的帮助。当然，我们做的是一家企业，不是单纯拿院士头衔圈钱，做企业是实打实的落到产品上面。对于市场开拓，院士头衔最多在初期起到推动作用，一个敲门砖，往后还是产品说话。 二、江行智能边缘计算的应用和产业落地 所谓边缘计算是把计算往前推进到跟用户比较接近的数据源。与云计算类似,两者都是处理大数据的计算运行方式。 随着5G时代的来临，物联网边缘服务器市场规模呈现飞速增长的态势，根据国际电信联盟电信标准分局ITU-T的研究报告，到2022年，每个人每秒将产生1.7MB的数据。 庞大体量的数据随之涌来，如果传输到云端进行计算处理，互联网将会产生100ms以上的延时，对于工业互联网或者能源互联网如电网，100ms的延时太高，同时，租用乐器大全云资源和宽带也需要付出一定代价，况且我国很多地方还没有好的网络环境。对于具备低功耗、高速率、低成本以及延时低的5G特性来说，如果不能配合边缘计算，也就不能发挥5G 1ms-10ms的超低延迟效应。所以工业互联网、5G等的概念如果要落实下去，就不可避免的要做边缘计算。 边缘计算被部署到几乎每个行业，由物联网数据的收集提供动力，并由大量可以应用到边缘计算的业务用于驱动。在这种情况下，江行智能将边缘计算应用在工业、智慧城市、能源等领域，企业发展稳步向前，未来非常可期。 6、请您介绍一下江行智能的总体情况，提供哪些产品和服务？拥有怎样的技术？ 刘江川：在边缘计算概念还没有被广泛接受之前，江行智能就成立了。核心产品 EdgeBox（边缘计算盒子），已广泛应用于工业、智慧城市、能源等领域。这个神奇的盒子包括底层硬件、ARM主板、 MCU控制系统、各种物联网接口，上层是一个经典化的量子系统，设计了容器编排，可以灵活配置应用于各种AI场景。 在输电线路维护、变电站巡检和配电台区智能化场景中，EdgeBox 借助其多传感器融合、超低功耗的识别技术及人工智能深度学习等能力，在边缘侧进行实时计算，及时回传预警信息，有效降低电力行业的通信开销和计算延迟。在制造、水务、安防领域，以 EdgeBox 为核心的边缘计算方案也在各个场景中提供降本、增效和安全的服务。比如现在落地的电网应用场景是承担通道可视化的工作，对两个高压铁塔之间的线路进行长时间监控，对外力破坏、火警、局部现象等进行准确判断并通报。根据需要，还可以不断添加新的功能，比如红外夜视功能等。通过边缘计算技术，将工业数据在本地进行处理、预警与控制，EdgeBox 可以极大地提高工业的智能化水平。 第二个产品就是智能配电终端的应用，把配电系统里面的开关替换成一个智能控制系统。当前也是电网大力推进的，在公司做数据采集和数据分析。在与北控水务合作的环保工业园区中，经过长时间的数据采集和分析，主要监控水质和空气状况，作出及时预警，对环保投料作出指导。 7、我们是如何切入到电网业务的？怎么看到了电网里面的这种需求或者市场？ 刘江川：有几个因素，第一，我和我的CTO过去做的研究电的节能，电池的管理，都属于电网的研究内容，所以我们天生有这方面的背景和经验；还有我们的副总是电网出身，他对电网这块的认识由更深度的理解，专业的知识能够帮助我们了解和理解边缘计算与电网行业紧密结合。 第二，电网行业有足够的给付能力和推动能力协助落地。很多行业的中小企业有升级改造的需要，但给付资金能力不强，且特定需求非常多，这类需求完成后又很难推广或者快速复制到其他企业，电网就不存在这些问题，一方面能够给付能力强，另一方面电网里的标准化程度、信息化程度相对较高。所以它能够进行快速复制。 电网是一个非常好的落地场景，近两年的改造投入非常多，特别是今年3月国家电网提出建设泛在电力物联网概念，边缘计算在其中拥有巨大的潜力，现在5G热潮对于电网也有着大量的需求，每年投入以几千亿计算。在电力生态系统中，养活不少大中小企业。 第三，瞄准电网行业欠缺的技术市场，电网合作兴趣高。合作时，根据需求完成各种功能，比如电磁防护，天气防护等等的需要过检的要求，实际上也构成了产品上的壁垒。 当然我们也不只做电网，比如工业园区，生产流水线等方面，我们也在开始做产品推广。 8、有很多技术创业者，做的技术和产品相当不错，但可能与市场有些脱节，市场化过程受阻，我们是怎么避免这一问题的？ 刘江川：这样考虑这个问题，做公司需要把市场放在技术之前，需要一个专业的市场团队，比较幸运的是我们副总和市场负责人都有专业技术背景和市场经验，所以公司一方面是技术推动，另一方面也是市场驱动。 对于公司目前所在的主营电网领域来说，我们不是单纯的以技术来说服对方，市场真正落地的时候往往比拼的不仅仅是技术的先进性，对稳定性、成熟度或者完成度要求非常高，需要根据市场反馈不断锤炼迭代才能真正做好。所以在电网方面我们走的脚踏实地，把稳定性和成熟度放在第一位，在此基础上再去做先进的技术。 我相信电网这块和其他行业也是一样，不可能一上来就吃进一大块市场，我们通过跟各种集成商合作，跟各种渠道商合作来证明自己的实力和独特之处。 另外我本人做过很多基础研究，跟上层也有一定联系，所以我希望借此机会推动政策的制定和规范制定等等。上中下几层都要同时开打，而不是说单单依靠一个方面。 9、在创业浪潮中，一个成功的创业项目被模仿或者竞争几乎是不可避免的，江行智能从哪些方面来构建企业壁垒？ 刘江川：有两点，第一点中国环境下IT行业软件是比较容易被跟风的，硬件或者软硬一体的系统不容易被跟风，所以我们产品尽量做到软硬一体化，门槛相对较高，难以被模仿和抄袭。 第二，边缘计算行业先发优势比较重要，完成度和稳定性需要一定的时间积累，并根据实际安装和市场反馈不断优化调整，对手产品如果想要做到同样的稳定性和完成度是不容易的。 10、边缘计算他在落地的过程当中，跟这些产业结合的过程当中，可能都会遇到哪些问题？ 刘江川：产业互联网和工业互联网的分支太多，即使是同一个行业，比如说电力行业里面也分发电、输电、配电、用电不同侧，然后每一侧里面又有各种不同的用户需求，所以产业互联网面临的异构性比较高。从这个角度讲，边缘计算与产业的结合很难出现通用型产品，基本以细分产品形式呈现。 三、新时代背景下的创新思考 11、我们说现在其实是一个科技创新的时代，也是一个大众创业的时代，您作为一位投入到创业浪潮里面的国际顶尖的科学家，可以谈谈您对于科技创新和大众创业关系的思考么？ 刘江川：当代科学家在新的时代背景下，我认为有两类使命，一类科学家以基础研究为主，这是最主要的道路。另外一类科学家在投入到创业的过程中也是很重要的。 现在许多新兴领域是需要技术驱动的，完全由资本市场主导或者不懂技术的人来做，高度难以提升。我们看新一代的IT企业，像以技术起家的google，如果没有google起来的话，我们的搜索引擎或者地图可能仍然停留在比较原始的阶段。 当然，科学家的归宿不一定都要去创业或者适合去创业，大部分科学家从事的基础研究是非常有必要的，而且大量的基础研究不需要得到市场验证，还可以通过培养人才和更高层次的推动这一途径走向市场，所以不是所有的科学家都要出来创业，也不是说所有的基础研究都要直接转化产品。 12、我国家在大力提倡科研成果转化服务到实体经济或者实体产业的转型。结合江行智能的科研成果转化，您有哪些想法或者经验可以分享给大家么？ 刘江川：有几点需要注意的，第一，科研成果转化一定要明确版权、所有权；第二。科学家的经验和博士生培养的过程有利于科研成果的转化。博士训练的过程或者说积累的十多年过程，能够使你快速地洞察出行业问题和产品问题，同时也能快速解决这些问题。 — 完 —
-
发表了文章 2022-02-14
你不了解的Linux二进制分析
二进制分析属于信息安全业界逆向工程中的一种技术，通过利用可执行的机器代码（二进制）来分析应用程序的控制结构和运行方式，它有助于信息安全从业人员更好地分析各种漏洞、病毒以及恶意软件，从而找到相应的解决方案。 要反编译Linux二进制文件，首先需要理解二进制格式本身。ELF目前已经成为UNIX和类UNIX操作系统的标准二进制格式。在Linux、BSD变体以及其他操作系统中，ELF格式可用于可执行文件、共享库、目标文件、coredump文件，甚至内核引导镜像文件。因此，对于那些想要更好地理解反编译、二进制攻破和程序执行的人来说，学习ELF至关重要。要想学习ELF这样的二进制格式，可不是一蹴而就的，需要随着对不同组件的学习来逐步掌握并加以实际应用。要达到熟练应用的效果，还需要实际的动手经验。ELF二进制格式比较复杂，也很枯燥，不过可以在进行反编译或者编程任务中应用ELF二进制格式相关的编程知识，通过这样的方式学习，倒是一种很有趣的尝试。ELF跟程序加载、动态链接、符号表查找和许多其他精心设计的组件一样，都是计算机科学非常重要的一部分。 在本文中，你将会更加深入地了解程序如何映射到磁盘并加载到内存中。程序执行的内部逻辑比较复杂，对于有抱负的二进制黑客、逆向工程师或者普通的程序员来说，对二进制格式的理解将会是非常宝贵的知识财富。在Linux中，程序就是以ELF二进制的格式执行的。 像许多Linux反编译工程师一样，我也是先了解ELF的说明规范，然后把学到的内容以一种创造性的方式进行应用，通过这样的方式来进行ELF的学习。 2.1 ELF文件类型 一个ELF文件可以被标记为以下几种类型之一。 ET_NONE：未知类型。这个标记表明文件类型不确定，或者还未定义。 ET_REL：重定位文件。ELF类型标记为relocatable意味着该文件被标记为了一段可重定位的代码，有时也称为目标文件。可重定位目标文件通常是还未被链接到可执行程序的一段位置独立的代码（position independent code）。在编译完代码之后通常可以看到一个.o格式的文件，这种文件包含了创建可执行文件所需要的代码和数据。 ET_EXEC：可执行文件。ELF类型为executable，表明这个文件被标记为可执行文件。这种类型的文件也称为程序，是一个进程开始执行的入口。 ET_DYN：共享目标文件。ELF类型为dynamic，意味着该文件被标记为了一个动态的可链接的目标文件，也称为共享库。这类共享库会在程序运行时被装载并链接到程序的进程镜像中。 ET_CORE：核心文件。在程序崩溃或者进程传递了一个SIGSEGV信号（分段违规）时，会在核心文件中记录整个进程的镜像信息。可以使用GDB读取这类文件来辅助调试并查找程序崩溃的原因。 使用readelf–h命令查看ELF文件，可以看到原始的ELF文件头。ELF文件头从文件的0偏移量开始，是除了文件头之后剩余部分文件的一个映射。文件头主要标记了ELF类型、结构和程序开始执行的入口地址，并提供了其他ELF头（节头和程序头）的偏移量，稍后会细讲。一旦理解了节头和程序头的含义，就容易理解文件头了。通过查看Linux的ELF（5）手册，可以了解ELF头部的结构： #define EI_NIDENT 16 typedef struct{ unsigned char e_ident[EI_NIDENT]; uint16_t e_type; uint16_t e_machine; uint32_t e_version; ElfN_Addr e_entry; ElfN_Off e_phoff; ElfN_Off e_shoff; uint32_t e_flags; uint16_t e_ehsize; uint16_t e_phentsize; uint16_t e_phnum; uint16_t e_shentsize; uint16_t e_shnum; uint16_t e_shstrndx; }ElfN_Ehdr; 在本文的后续内容中，我会用一个简单的C程序来展示如何利用上面结构中的字段映射一个ELF文件。我先继续介绍现存的其他类型的ELF头。 2.2 ELF程序头 ELF程序头是对二进制文件中段的描述，是程序装载必需的一部分。段（segment）是在内核装载时被解析的，描述了磁盘上可执行文件的内存布局以及如何映射到内存中。可以通过引用原始ELF头中名为e_phoff（程序头表偏移量）的偏移量来得到程序头表，如前面ElfN_Ehdr结构中所示。 下面讨论5种常见的程序头类型。程序头描述了可执行文件（包括共享库）中的段及其类型（为哪种类型的数据或代码而保留的段）。首先，我们来看一下Elf32_Phdr的结构，它构成了32位ELF可执行文件程序头表的一个程序头条目。 在后续内容中有时还会引用Phdr的程序头结构。 下面是Elf32_Phdr结构体： typedef struct { uint32_t p_type; (segment type) Elf32_Off p_offset; (segment offset) Elf32_Addr p_vaddr; (segment virtual address) Elf32_Addr p_paddr; (segment physical address) uint32_t p_filesz; (size of segment in the file) uint32_t p_memsz; (size of segment in memory) uint32_t p_flags; (segment flags, I.E execute|read|read) uint32_t p_align; (segment alignment in memory) } Elf32_Phdr;2.2.1 PT_LOAD 一个可执行文件至少有一个PT_LOAD类型的段。这类程序头描述的是可装载的段，也就是说，这种类型的段将被装载或者映射到内存中。 例如，一个需要动态链接的ELF可执行文件通常包含以下两个可装载的段（类型为PT_LOAD）： 存放程序代码的text段； 存放全局变量和动态链接信息的data段。 上面的两个段将会被映射到内存中，并根据p_align中存放的值在内存中对齐。建议读者阅读一下Linux的ELF手册，以便理解Phdr结构体中所有变量的含义，这些变量描述了段在文件和内存中的布局。 程序头主要描述了程序执行时在内存中的布局。本章稍后会使用Phdr来说明什么是程序头，以及如何在反编译软件中使用程序头。 通常将text段（也称代码段）的权限设置为PF_X | PF_R（读和可执行）。 通常将data段的权限设置为PF_W | PF_R（读和写）。 感染了千面人病毒（polymorphic virus）文件的text段或data段的权限可能会被修改，如通过在程序头的段标记（p_flags）处增加PF_W标记来修改text段的权限。 2.2.2 PT_DYNAMIC——动态段的Phdr 动态段是动态链接可执行文件所特有的，包含了动态链接器所必需的一些信息。在动态段中包含了一些标记值和指针，包括但不限于以下内容： 运行时需要链接的共享库列表； 全局偏移表（GOT）的地址——ELF动态链接部分（2.6节）会讨论； 重定位条目的相关信息。 表2-1是完整的标记名列表。 表2-1 标 记 名 描 述 DT _ HASH 符号散列表的地址 DT _ STRTAB 字符串表的地址 DT _ SYMTAB 符号表地址 DT _ RELA 相对地址重定位表的地址 DT _ RELASZ Rela表的字节大小 DT _ RELAENT Rela表条目的字节大小 DT _ STRSZ 字符串表的字节大小 DT _ SYMENT 符号表条目的字节大小 DT _ INIT 初始化函数的地址 DT _ FINI 终止函数的地址 DT _ SONAME 共享目标文件名的字符串表偏移量 DT _ RPATH 库搜索路径的字符串表偏移量 DT _ SYMBOLIC 修改链接器，在可执行文件之前的学历提升共享目标文件中搜索符号 DT _ REL Rel relocs表的地址 DT _ RELSZ Rel表的字节大小 DT _ RELENT Rel表条目的字节大小 DT _ PLTREL PLT引用的reloc类型（Rela或Rel） DT _ DEBUG 还未进行定义，为调试保留 DT _ TEXTREL 缺少此项表明重定位只能应用于可写段 DT _ JMPREL 仅用于PLT的重定位条目地址 DT BIND NOW 指示动态链接器在将控制权交给可执行文件之前处理所有的重定位 DT _ RUNPATH 库搜索路径的字符串表偏移量 动态段包含了一些结构体，在这些结构体中存放着与动态链接相关的信息。d_tag成员变量控制着d_un的含义。 32位ELF文件的动态段结构体如下： typedef struct{ Elf32_Sword d_tag; union{ Elf32_Word d_val; Elf32_Addr d_ptr; } d_un; } Elf32_Dyn; extern Elf32_Dyn _DYNAMIC[]; 本文稍后会继续对动态链接进行更深入的探讨。 2.2.3 PT_NOTE PT_NOTE类型的段可能保存了与特定供应商或者系统相关的附加信息。下面是标准ELF规范中对PT_NOTE的定义： 有时供应商或者系统构建者需要在目标文件上标记特定的信息，以便于其他程序对一致性、兼容性等进行检查。SHT_NOTE类型的节（section）和PT_NOTE类型的程序头元素就可以用于这一目的。节或者程序头元素中的备注信息可以有任意数量的条目，每个条目都是一个4字节的目标处理器格式的数组。下面的标签可以解释备注信息的组织结构，不过这些标签并不是规范中的内容。 比较有意思的一点：事实上，这一段只保存了操作系统的规范信息，在可执行文件运行时是不需要这个段的（因为系统会假设一个可执行文件是本地的），这个段成了很容易被病毒感染的一个地方。由于篇幅限制，就不具体介绍了。更多NOTE段病毒感染相关的信息可以从vxheavens/ lib/vhe06.html了解到。 2.2.4 PT_INTERP PT_INTERP段只将位置和大小信息存放在一个以null为终止符的字符串中，是对程序解释器位置的描述。例如，/lib/linux-ld.so.2一般是指动态链接器的位置，也即程序解释器的位置。 2.2.5 PT_PHDR PT_PHDR段保存了程序头表本身的位置和大小。Phdr表保存了所有的Phdr对文件（以及内存镜像）中段的描述信息。 可以查阅ELF（5）手册或者ELF规范文档来查看所有的Phdr类型。我已经介绍了一些最常用的Phdr类型，其中一些对程序执行至关重要，有一些在反编译时会经常用到。 可以使用readelf–l 命令查看文件的Phdr表： Elf file type is EXEC (Executable file) Entry point 0x8049a30 There are 9 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PHDR 0x000034 0x08048034 0x08048034 0x00120 0x00120 R E 0x4 INTERP 0x000154 0x08048154 0x08048154 0x00013 0x00013 R 0x1 [Requesting program interpreter: /lib/ld-linux.so.2] LOAD 0x000000 0x08048000 0x08048000 0x1622c 0x1622c R E 0x1000 LOAD 0x016ef8 0x0805fef8 0x0805fef8 0x003c8 0x00fe8 RW 0x1000 DYNAMIC 0x016f0c 0x0805ff0c 0x0805ff0c 0x000e0 0x000e0 RW 0x4 NOTE 0x000168 0x08048168 0x08048168 0x00044 0x00044 R 0x4 GNU_EH_FRAME 0x016104 0x0805e104 0x0805e104 0x0002c 0x0002c R 0x4 GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x4 GNU_RELRO 0x016ef8 0x0805fef8 0x0805fef8 0x00108 0x00108 R 0x1 从上面的片段中，可以看到可执行程序的入口点，还有刚刚讨论的不同段的类型。注意看中间部分的PT_LOAD段，从最左边的偏移量到最右边的权限标识和对齐标识。 text段是可读可执行的，data段是可读可写的，这两个段都有0x1000（4096）的对齐标识，刚好是32位可执行文件一页的大小，该标识用于在程序装载时对齐。 本书是目前为止唯一一本剖析Linux ELF工作机制的图书，共分为9章，其内容涵盖了Linux环境和全日制相关工具、ELF二进制格式、Linux进程追踪、ELF病毒技术、Linux二进制保护、Linux中的ELF二进制取证分析、进程内存取证分析、扩展核心文件快照技术、Linux/proc/kcore分析等。 本书适合具有一定的Linux操作知识，且了解C语言编程技巧的信息安全从业人员阅读。 目 录（滑动手机查看全部） 第1章 Linux环境和相关工具1 1．1 Linux工具1 1．1．1 GDB2 1．1．2 GNU binutils中的objdump2 1．1．3 GNU binutils中的objcopy3 1．1．4 strace3 1．1．5 ltrace4 1．1．6 基本的ltrace命令4 1．1．7 ftrace4 1．1．8 readelf4 1．1．9 ERESI——ELF反编译系统接口5 1．2 有用的设备和文件6 1．2．1 /proc//maps6 1．2．2 /proc/kcore6 1．2．3 /boot/System．map6 1．2．4 /proc/kallsyms7 1．2．5 /proc/iomem7 1．2．6 ECFS7 1．3 链接器相关环境指针7 1．3．1 LD_PRELOAD环境变量8 1．3．2 LD_SHOW_AUXV环境变量8 1．3．3 链接器脚本9 1．4 总结10 第2章 ELF二进制格式11 2．1 ELF文件类型12 2．2 ELF程序头14 2．2．1 PT_LOAD14 2．2．2 PT_DYNAMIC——动态段的Phdr15 2．2．3 PT_NOTE17 2．2．4 PT_INTERP17 2．2．5 PT_PHDR17 2．3 ELF节头18 2．3．1 ．text节20 2．3．2 ．rodata节20 2．3．3 ．plt节21 2．3．4 ．data节21 2．3．5 ．bss节21 2．3．6 ．got．plt节21 2．3．7 ．dynsym节21 2．3．8 ．dynstr节22 2．3．9 ．rel．*节22 2．3．10 ．hash节22 2．3．11 ．symtab节22 2．3．12 ．strtab节23 2．3．13 ．shstrtab节23 2．3．14 ．ctors和．dtors节23 2．4 ELF符号27 2．4．1 st_name28 2．4．2 st_value28 2．4．3 st_size28 2．4．4 st_other28 2．4．5 st_shndx29 2．4．6 st_info29 2．5 ELF重定位34 2．6 ELF动态链接43 2．6．1 辅助向量44 2．6．2 了解PLT/GOT46 2．6．3 重温动态段49 2．7 编码一个ELF解析器52 2．8 总结55 第3章 Linux进程追踪57 3．1 ptrace的重要性57 3．2 ptrace请求58 3．3 进程寄存器状态和标记60 3．4 基于ptrace的调试器示例61 3．5 ptrace调试器67 3．6 高级函数追踪软件75 3．7 ptrace和取证分析75 3．8 进程镜像重建77 3．8．1 重建进程到可执行文件的挑战78 3．8．2 重建可执行文件的挑战78 3．8．3 添加节头表79 3．8．4 重建过程算法79 3．8．5 在32位测试环境中使用Quenya重建进程81 3．9 使用ptrace进行代码注入83 3．10 简单的例子演示复杂的过程91 3．11 code_inject工具演示92 3．12 ptrace反调试技巧92 3．13 总结94 第4章 ELF病毒技术——Linux/UNIX病毒95 4．1 ELF病毒技术96 4．2 设计ELF病毒面临的挑战97 4．2．1 寄生代码必须是独立的97 4．2．2 字符串存储的复杂度99 4．2．3 寻找存放寄生代码的合理空间100 4．2．4 将执行控制流传给寄生代码100 4．3 ELF病毒寄生代码感染方法101 4．3．1 Silvio填充感染101 4．3．2 逆向text感染106 4．3．3 data段感染108 4．4 PT_NOTE到PT_LOAD转换感染110 4．5 感染控制流112 4．5．1 直接PLT感染113 4．5．2 函数蹦床（function trampolines）113 4．5．3 重写．ctors/．dtors函数指针114 4．5．4 GOT感染或PLT/GOT重定向115 4．5．5 感染数据结构115 4．5．6 函数指针重写115 4．6 进程内存病毒和rootkits——远程代码注入技术115 4．6．1 共享库注入116 4．6．2 text段代码注入120 4．6．3 可执行文件注入120 4．6．4 重定位代码注入——ET_REL注入120 4．7 ELF反调试和封装技术121 4．7．1 PTRACE_TRACEME技术121 4．7．2 SIGTRAP处理技术122 4．7．3 /proc/self/status技术122 4．7．4 代码混淆技术123 4．7．5 字符串表转换技术124 4．8 ELF病毒检测和杀毒124 4．9 总结126 第5章 Linux二进制保护127 5．1 ELF二进制加壳器127 5．2 存根机制和用户层执行128 5．3 保护器存根的其他用途133 5．4 现存的ELF二进制保护器133 5．4．1 DacryFile——Grugq于2001年发布134 5．4．2 Burneye——Scut于2002年发布134 5．4．3 Shiva——Neil Mehta和Shawn Clowes于2003年发布135 5．4．4 May's Veil——Ryan O'Neill于2014年发布136 5．5 下载Maya保护的二进制文件142 5．6 二进制保护中的反调试142 5．7 防模拟技术143 5．7．1 通过系统调用检测模拟144 5．7．2 检测模拟的CPU不一致144 5．7．3 检测特定指令之间的时延144 5．8 混淆方法145 5．9 保护控制流完整性145 5．9．1 基于ptrace的攻击145 5．9．2 基于安全漏洞的攻击146 5．10 其他资源147 5．11 总结147 第6章 Linux下的ELF二进制取证分析149 6．1 检测入口点修改技术150 6．2 检测其他形式的控制流劫持154 6．2．1 修改．ctors/．init_array节154 6．2．2 检测PLT/GOT钩子155 6．2．3 检测函数蹦床158 6．3 识别寄生代码特征159 6．4 检查动态段是否被DLL注入161 6．5 识别逆向text填充感染164 6．6 识别text段填充感染166 6．7 识别被保护的二进制文件170 6．8 IDA Pro175 6．9 总结175 第7章 进程内存取证分析177 7．1 进程内存布局178 7．1．1 可执行文件内存映射179 7．1．2 程序堆179 7．1．3 共享库映射180 7．1．4 栈、VDSO和vsyscall180 7．2 进程内存感染181 7．2．1 进程感染工具181 7．2．2 进程感染技术182 7．3 检测ET_DYN注入184 7．3．1 Azazel：用户级rootkit检测184 7．3．2 映射出进程的地址空间184 7．3．3 查找栈中的LD_PRELOAD187 7．3．4 检测PLT/GOT钩子188 7．3．5 ET_DYN注入内部原理190 7．3．6 操纵VDSO194 7．3．7 共享目标文件加载195 7．3．8 检测．so注入的启发方法196 7．3．9 检测PLT/GOT钩子的工具197 7．4 Linux ELF核心文件198 7．5 总结204 第8章 ECFS——扩展核心文件快照技术205 8．1 历史205 8．2 ECFS原理206 8．3 ECFS入门206 8．3．1 将ECFS嵌入到核心处理器中207 8．3．2 在不终止进程的情况下使用ECFS快照208 8．4 libecfs——解析ECFS文件的库208 8．5 readecfs工具209 8．6 使用ECFS检测被感染的进程210 8．6．1 感染主机进程210 8．6．2 捕获并分析ECFS快照211 8．6．3 使用readecfs提取寄生代码215 8．6．4 Azazel用户级rootkit分析216 8．7 ECFS参考指南224 8．7．1 ECFS符号表重建225 8．7．2 ECFS节头226 8．7．3 使用ECFS文件作为常规的核心文件229 8．7．4 libecfs API的使用229 8．8 使用ECFS恢复中断的进程230 8．9 了解更多ECFS相关内容231 8．10 总结232 第9章 Linux/proc/kcore分析233 9．1 Linux内核取证分析和rootkit233 9．2 没有符号的备份vmlinux234 9．3 探索/proc/kcore和GDB236 9．4 直接修改sys_call_table237 9．4．1 检测sys_call_table修改238 9．4．2 内核函数蹦床238 9．4．3 函数蹦床示例239 9．4．4 检测函数蹦床241 9．4．5 检测中断处理器修复243 9．5 Kprobe rootkit243 9．6 调试寄存器rootkit——DRR244 9．7 VFS层rootkit244 9．8 其他内核感染技术245 9．9 vmlinux和．altinstructions修补245 9．9．1 ．altinstructions和．altinstr_replace246 9．9．2 arch/x86/include/asm/alternative．h代码片段246 9．9．3 使用textify验证内核代码完整性247 9．9．4 使用textify检查sys_call_table247 9．10 使用taskverse查看隐藏进程248 9．11 感染的LKM——内核驱动249 9．11．1 方法一：感染LKM文件——符号劫持249 9．11．2 方法二：感染LKM文件——函数劫持249 9．11．3 检测被感染的LKM250 9．12 /dev/kmem和/dev/mem250 9．12．1 /dev/mem251 9．12．2 FreeBSD /dev/kmem251 9．13 K-ecfs ——内核ECFS251 9．14 内核黑客工具252 9．14．1 通用的逆向工程和调试253 9．14．2 高级内核劫持/调试接口253 9．14．3 本章提到的论文253 9．15 总结254
-
发表了文章 2022-02-13
现代数据堆栈的趋势：展望未来
在第1部分中，我们在现代数据堆栈的演变周围分享了一些背景。在这一部分中，我们采取了水晶球方法，以预测数据空间如何从这里发展。我们很高兴能够与突破性的初创公司一起工作，这将在数据堆栈的演变中发挥重要作用，以下几乎只是对此空间前方的内容的有限视图。 没有进一步的东西，让我们挖掘。 重新思考存储范式 数据的圣杯已经建立了一个“单一的真理来源”，在那里分析师（人类越来越多地成为机器）可以逐地找到众所周知的洞察力黄金。Enterprise Data Warehouse在80年代突出以存储结构化数据，并且存储范例现在在同一前提下大部分地移动到云。仓库需要存储“相关”数据的需求是由成本 - 智能存储的管辖昂贵，并且仓库用于存储在“时间点”中相关的数据。这种方法有局限性，因为今天认为有关的内容可能并不相关，反之亦然。此外，经典仓库非常严格（来自数据科学的角度来看），因为它们往往是结构化数据存储。 进入数据湖，通过允许组织以任何格式存储所有格式来扩展圣杯的前提。根据利用企业内的AI和ML应用的非结构化数据的角度，这尤其相关。但是，由于底层的架构，传统数据湖中的计算并不容易，因此组织开始在湖面上构建数据仓库，以使计算（基本上分析）更容易。谈谈冗余和单片思维。 我们从哪里开始？我们相信最好的数据团队正在重新称解存储范式。一方面，数据仓库和数据湖之间的融合迹象是“Lakehouse” - 这是两个世界的最佳选择。虽然所产生的架构尚不清楚，但现任者有不同的需要。例如，Snowflake 追随仓库 - 第一个方法，DataBricks的Delta Lake有一个湖泊 - 首先的方法。 并行地，我们观察到新数据存储库架构获得牵引力的标准的分歧。这些数据存储库架构旨在解决特定用例中仓库和湖泊的低效率。例如，数据结构/数据网格旨在利用企业知识图来描述不同数据集之间的关系，这些数据集将有助于提取洞察力。这些是由Stardog和Cinchy等初创公司开发的，并且像NetApp和Talend这样的遗留玩家。 另一个新兴趋势是开发可以处理混合数据流的架构，该流动数据流涉及处理大批量数据以及低延迟时间序列流。后者对于从社交网络到自动驾驶汽车的实时数据尤其有用。我们相信这是一个具有很多中断和增长潜力的有希望的地区。 虽然我们在谈到存储时展望未来，但重要的是要注意只有?15,000家公司使用Redshift和?3,100使用Snowflake，截至2022年，还有很长的路要发展单一来源提高数据可用性的架构。 可操作的BI和闭环 “商业智能”一词归因于决策支持系统的世界。这个想法是简单的管理者需要报告制定业务决策。鉴于这种情况，假设总是在循环中有一个人。但是，这种范式正在变成越来越古老的古代。一个极端的例子位于自动车辆（AV）空间中，前提是消除循环中的这种人的因素。虽然一个完全自主未来的想法仍然是一个想法，但我们相当肯定的是，人类在循环中的作用将继续减少，或者变得更加了解，因为被淘汰了冗余。 让我们从今天的地方接。经典BI工具无法帮助地执行。汇集领域的银行代理不会从中央仪表板上的分支级贷款绩效数据中受益。需要一个映射的路由，指示他们需要顺序访问所需的每个位置。在一个理想的世界中，每个专家都应该配备五个讨论指南 - 每个人都适用于他们正在访问的不同部分 - 以及提示应该使用哪些指南的证书工具。这是可操作的双 - 我们认为越来越成为现实。我们可以进一步绘制这张照片，但希望你得到这个想法。 今天的数据流水线是为了帮助采取高级业务决策，而不是直接运行业务。因此，Excel仍然是运营团队使用的流行工具，因为它很容易使用。作为投资者，我们有一个固有的信念，无论我们在业务垂直何处找到过度的Excel使用情况，现在是某人建立一个首先消除Excel的平台，然后添加特定于用例特定的铃声和吹口哨的时候了。以下是这可能播放的几种方式： 循环工作流程：团队一直认为工作流程和BI作为单独的实例。由于内部工具具有增殖的工作流程，组织开始意识到工作流程和BI可以很好地联系在一起。摘要，我们认为数据流水线和运营管道之间的差距可以由内部应用程序开发平台（如Retool和Appsmith）桥接，这些平台可能会将BI和工作流合并为一个可自定义的低/无代码可操作的BI平台-in-循环工作流程。自动反馈循环：BI已经是单向的 - 数据从源头到分析师，他们可能会或可能不会采取行动。例如，销售领导者可能不会三次考虑一个地区的增长减缓，智力显示该公司正在失去市场份额。然而，在理想的世界中，这样的活动应该在区域经理的待办事项列表中自动创建任务，指导销售团队激活促销活动。这是从BI到SaaS的连接器的使用示例，也称为Reverse ETL，在此处的人口普查和托盘构建有趣的产品。这些可能性是无限的：从BI到存储的反馈循环，存储到SaaS，您命名为SaaS，可能会彻底彻底改变操作团队的功能。垂直化可视化：狐狸世界的刺猬，垂直BI工具专为特定的用户角色设计。例如，古玩论坛ML可视化工具，如Plotly Dash和Streamlit使数据科学家能够构建其模型的视觉表示，并将其作为WebApps传送给非技术用户。这些用户可以轻松解释模型推论，并在手头的数据中采取后续操作。像Amplitude, Locale 和 Glean的其他公司也是非技术团队的可视化和分析解决方案，以便立即将洞察力转换为在行动点的结果。数据运维 dataops：现在和现在 在印度有22,000多个职位列表Devops角色。Dataops的相同号码低于2,000。我们愿意在肢体上出去，并说这个数字将在不久的将来爆炸。在过去十年中，数据变得越来越复杂。数据团队的大小庞大跳跃，任何组织处理的数据都变得更加复杂。这导致了需要管理层来协调数据流水线，以及专业的工具以及（人类）资源。 兴奋我们的一些Dataops机会包括： 元数据管理：思考更好地编制组织的数据集。虽然这一想法已经存在，但很棒的工具刚刚开始出现，并将改变元数据管理的完成方式。一些工具包括Collibra，Aliatal和Lyft的开源Amundsen。数据可观察性和质量：防止“垃圾垃圾垃圾垃圾垃圾”的格言是重要的，Monte Carlo，ActeLDA和Soda等平台，旨在验证数据质量和可靠性，功能解决数据新鲜度监测，分配跟踪，异常和异常值检测和架构错误。SISU，ANADOT和Outlier等其他人可以使指标对各种业务单位重要的可观察性。数据治理和隐私：我们想在这方面写一下 - 特别是考虑到这一话题是如何误解的，这一话题是印度的消费公司（我们仍然可能，留在调整）。然而，有一套整个平台，解决治理和隐私，我们期望更多地出现，因为这些主题继续全球中心舞台。 有趣的是，一些平台正在涌现，以支持多个DataOps支柱，例如Data，Atlan，Datakitchen等。这些玩家旨在成为组织内的数据工作场所，我们预计更多的初创公司试图以Github为基础构建数据库。 数据团队未来和协作 什么好的文章没有提到新的正常？全球团队，远程工作，分布式知识资产等。意味着协作必须是前面和中央的数据。这对于具有复杂数据用例和大型数据团队的组织的关键组织 - 因为它们从组织和地理角度往往更复杂。 数据科学家正在使用笔记本作为默认工作区。例如，jupyter是一个很好的平台，提供数据团队的工作空间，包括可视化，文本和数学模型，以及代码，都在交互式Web环境中。若干公司正在建立在这个想法上扩展的产品，包括Jovian.ML，Zepl（Vertex Ventures Us Portfolio Company）和Polynote。我们相信更多使用案例和功能将建立以增加笔记本。 在数据集上的协作也一直在获得牵引力。像Popsql和dataform等工具，可以在SQL查询和查询库上进行常用搜索的查询库。还有平台可以实现实时协作。例如，Mode和Graphy正在构建Google文档的BI，而Cord的工具旨在通过在任何软件上启用注释和聊天来构建Figma-for-Emares。 总之，堆栈中存在巨大的潜力。但是，在下面的图表中突出了我们大致概述的关键领域和趋势。 这是数据的十年，顶点企业东南亚和印度的团队热衷于解决这些全球挑战的合作团队！很高兴听到思想并接受数据空间。
-
发表了文章 2022-02-13
如何使用Python将几十个PDF文件合并成一个PDF？其实只需要这四步
假定你有一个很无聊的任务，需要将几十个PDF文件合并成一个PDF文件。每一个文件都有一个封面作为第一页，但你不希望合并后的文件中重复出现这些封面。即使有许多免费的程序可以合并PDF，很多也只是简单的将文件合并在一起。让我们来写一个Python程序，定制需要合并到PDF中的页面。 总的来说，该程序需要完成： 找到当前工作目录中所有PDF文件。按文件名排序，这样就能有序地添加这些PDF。除了第一页之外，将每个PDF的所有页面写入输出的文件。 从实现的角度来看，代码需要完成下列任务： 调用os.listdir()，找到当前工作目录中的所有文件，去除掉非PDF文件。调用Python的sort()列表方法，对文件名按字母排序。为输出的PDF文件创建PdfFileWriter对象。循环遍历每个PDF文件，为它创建PdfFileReader对象。针对每个PDF文件，循环遍历每一页，第一页除外。将页面添加到输出的PDF。将输出的PDF写入一个文件，名为allminutes.pdf。 针对这个项目，打开一个新的文件编辑器窗口，将它保存为combinePdfs.py。 第1步：找到所有PDF文件 首先，程序需要取得当前工作目录中所有带.pdf扩展名的文件列表，并对它们排序。让你的代码看起来像这样： #! python3 # combinePdfs.py - Combines all the PDFs in the current working directory into # into a single PDF. ? import PyPDF2, os # Get all the PDF filenames. pdfFiles=[] for filename in os.listdir('.'): if filename.endswith('.pdf'): ? pdfFiles.append(filename) ? pdfFiles.sort(key=str.lower) ? pdfWriter=PyPDF2.PdfFileWriter() # TODO: Loop through all the PDF files. # TODO: Loop through all the pages (except the first) and add them. # TODO: Save the resulting PDF to a file. 在#!行和介绍程序做什么的描述性注释之后，代码导入了os和PyPDF2模块?。os.listdir('.')调用将返回当前工作目录中所有文件的列表。代码循环遍历这个列表，将带有.pdf扩展名的文件添加到pdfFiles中?。然后，列表按照字典顺序排序，调用sort()时带有key/str.lower关键字参数?。 代码创建了一个PdfFileWriter对象，保存合并后的PDF页面?。最后，一些注释语句简要描述了剩下的程序。 第2步：打开每个PDF文件 现在，程序必须读取pdfFiles中的每个PDF文件。在程序中加入以下代码： #! python3 # combinePdfs.py - Combines all the PDFs in the current working directory into # a single PDF. import PyPDF2, os # Get all the PDF filenames. pdfFiles=[] --snip-- # Loop through all the PDF files. for filename in pdfFiles: pdfFileObj=open(filename, 'rb') pdfReader=PyPDF2.PdfFileReader(pdfFileObj) # TODO: Loop through all the pages (except the first) and add them. # TODO: Save the resulting PDF to a file. 针对每个PDF文件，循环内的代码调用open()，以'wb'作为第二个参数，用读二进制的模式打开文件。open()调用返回一个 File 对象，它被传递给PyPDF2.PdfFileReader()，创建针对那个PDF文件的PdfFileReader对象。 第3步：添加每一页 针对每个PDF文件，需要循环遍历每一页，第一页除外。在程序中添加以下代码： #! python3 # combinePdfs.py - Combines all the PDFs in the current working directory into # a single PDF. import PyPDF2, os --snip-- # Loop through all the PDF files. for filename in pdfFiles: --snip-- # Loop through all the pages (except the first) and add them. ? for pageNum in range(1, pdfReader.numPages): pageObj=pdfReader.getPage(pageNum) pdfWriter.addPage(pageObj) # TODO: Save the resulting PDF to a file. for循环内的代码将每个Page对象拷贝到PdfFileWriter对象。要记住，你需要跳过技术教程第一页。因为PyPDF2认为0是第一页，所以循环应该从1开始?，然后向上增长到pdfReader.numPages中的整数，但不包括它。 第4步：保存结果 在这些嵌套的for循环完成后，pdfWriter变量将包含一个PdfFileWriter对象，合并了所有PDF的页面。最后一步是将这些内容写入硬盘上的一个文件。在程序中添加以下代码： #! python3 # combinePdfs.py - Combines all the PDFs in the current working directory into # a single PDF. import PyPDF2, os --snip-- # Loop through all the PDF files. for filename in pdfFiles: --snip-- # Loop through all the pages (except the first) and add them. for pageNum in range(1, pdfReader.numPages): --snip-- # Save the resulting PDF to a file. pdfOutput=open('allminutes.pdf', 'wb') pdfWriter.write(pdfOutput) pdfOutput.close() 向open()传入'wb'，以写二进制的模式打开输出PDF文件allminutes.pdf。然后，将得到的File对象传给write()方法，创建实际的PDF文件。调用close()方法，结束程序。 第5步：类似程序的想法 能够利用其他PDF文件的页面创建PDF文件，这让你的程序能完成以下任务： 从PDF文件中截取特定的页面。重新调整PDF文件中页面的次序。创建一个PDF文件，只包含那些具有特定文本的页面。文本由extractText()来确定。 本文摘自：《Python编程快速上手 让繁琐工作自动化》 本书是一本面向实践的Python编程实用指南。本书的目的，不仅是介绍Python语言的基础知识，而且还通过项目实践教会读者如何应用这些知识和技能。本书的第一部分介绍了基本的Python编程概念，第二部分介绍了一些不同的任务，通过编写Python程序，可以让计算机自动完成它们。第二部分的每一章都有一些项目程序，供读者学习。每章的末尾还提供了一些习题和深入的实践项目，帮助读者巩固所学的知识。附录部分提供了所有习题的解答。 本书适合任何想要通过Python学习编程的读者，尤其适合缺乏编程基础的初学者。通过阅读本书，读者将能利用最强大的编程语言和工具，并且将体会到Python编程的快乐。
-
发表了文章 2022-02-13
选择Pulsar而不是Kafka的5个原因
datastax.·7分钟阅读 作者的注意事项：我最初在2022年发布了这篇博客文章，而我是Kesque的首席执行官，是Apache Pulsar的实时消息服务，云本机分布式消息传递和流式媒体平台。这是一个早期帖子的后续行动，“选择Apache Pulsar的7个理由选择Apache Kafka。”由于这两个帖子的原因，包括Kesque的收购。然而，选择Pulsar的原因没有改变。 一段时间后，我写了一个关于7个理由的帖子，我们选择Apache pulsar过度Apache Kafka。从那时起，我一直在研究一个详细的报告，比较Kafka和Pulsar，与开源Pulsar项目的用户交谈，并与我们管理的Pulsar服务的用户交谈Kesque。我意识到的是，我错过了第一篇文章的一些原因。所以，我以为我会做一个增加到列表的后续帖子。 在潜入新的原因之前，让我们快速回顾上一篇文章中提到的七个： 统一流媒体和消息队列 - 在一个平台中的Kafka和Rabbitmq。分区是可选的 - 如果您不想，则使用pulsar，您不需要使用分区删除分区。（我不想。）分布式日志 - Pulsar日志是水平扩展的，因为它是分布式的。我听到耳朵里的音乐吗？无状态的代理 - 云原住民梦想场景。我在哪里放置自动缩放者？本机地理复制 - 任何人和我的意思是任何人，都可以获得地理复制权。它更快 - 测试证明这一点。所有Apache软件基金会开源 。 那些是前七个原因。这些似乎很多，但我发现了一些。让我们进入他们。 1.支持多租户 我真的应该在第一篇文章中谈论多租户，因为这是一个大的问题。即使您没有计划建立托管Pulsar活动（以及为什么我们已经为您建立了一个？），除非您是隐士，否则将有多个团队在使用您的多个项目上工作消息传递基础架构。必须为每个团队或项目旋转群集是一种痛苦。它也很贵。 使用Pulsar，您可以拥有多个租户，那些租户可以有多个名称空间来保持所有组织的东西。添加到每个命名空间的访问控制，配额和评分限制，您可以想象我们所有人都可以使用这个群集。我们不仅可以想象这个未来，但Kafka也可以想象它。您可以在KAFKA改进提案（KIP）KIP-37中阅读它。现在已经讨论了一段时间。 我们有一个霸权吗？复制 您想确保您的邮件永远不会丢失，因此您将消息传递系统配置为在出现问题时制作每条消息的两个或三个副本。 Kafka使用以下领导型来实现这一目标。领导者存储消息，追随者制作它的副本。一旦足够的追随者承认他们已经得到它，Kafka很开心。Pulsar使用仲裁模型。它将消息发送到一堆节点，一旦超过他们承认他们已经得到它，Pulsar很高兴。 法定复制更为民主，没有这一领导者跟随者层次结构。大多数总是赢，所有选票都是平等的。但这对技术无关紧要。重要的是，致法量复制往往会随着时间的推移提供更一致的行为。这可能解释了为什么Pulsar提供更一致的延迟性能。 如果您想进入Kafka和Pulsar Latency的细节，请查看我写的博客文章。（这很长。不要说我没有警告你。）哦，Kafka一直在考虑Quorum复制来提高延迟一致性。检查KIP-250是否讨论。 3.分层存储，事件订阅的梦想 关于kafka这样的流系统的伟大事物之一是它能够重播已经消耗的消息。如果您第一次喜欢这些消息，请重播它们以纠正某些内容或构建周围的新应用很有趣。 如果你非常喜欢这些消息，你想永远保持它们吗？喜欢，说你是否正在做事。这听起来像是一个很好的主意，但永远是一个强大的长时间，永远存储邮件可以变得昂贵 - 特别是如果你在那些保持你的消息传递系统嗡嗡声的高性能SSD上。 如果你可以移动那些旧消息 - 你需要保持的旧消息，因为你可能需要它们，那么有一天需要它们 - 更便宜的存储解决方案？如果你可以使用像亚马逊S3桶这样的便宜的云存储，那不是很棒吗？ 你可能会猜到我在这里去哪里。使用Pulsar分层存储，您可以自动将尘土飞扬的旧消息推入实际上无限，廉价的云存储，并类似于您执行那些较新的新鲜的消息。 我敢打赌，Kafka希望拥有这个功能。你猜到了，他们会。它在KIP-405中描述。 4.端到端加密 显然，安全性很重要，您希望将您的信息保证免于窥探。当然，您将在游戏论坛客户端和消息传递系统之间使用TLS（在传输中加密）。 当您这样做时，消息传递系统必须解密连接，因此它可以弄清楚客户端试图说的。然后将在磁盘上保存未加密的消息。当然，您将坚持认为磁盘被加密，以便如果有人窃取磁盘，您的消息将是安全的（在休息时加密）。但在这两种情况下，消息传递系统都有对您的数据的键。如果没有，它将处理难以理解的GobbledyGook流。 在许多情况下，这种加密级别足够好。但如果你想绝对确定没有人可以偷看你的消息，你需要端到端加密。Producer在使用与将收到消息的消费者共享的密钥发送键之前加密消息。当消息保存在消息传递系统的磁盘上时，它加密，消息传递系统没有键。消息系统可以执行其工作。但是您的消息是超级安全的GobbledyGook到消息传递系统。 Pulsar可以在其Java客户端中进行端到端加密。Kafka一直在谈论在KIP-317中做它。 代理平衡行为 在我的最后一篇文章中，我谈论了Pulsar活动代理是无状态的，这很好。但实际上还有这个故事。 无状态组件是可取的，因为当一个人超载时，您只需添加另一个“来处理负载即可。当新客户端连接时，它们可以被定向到新实例。但这并没有帮助首先被过载的实例。您需要将一些工作从超载实例转移到新的新鲜的工作。 换句话说，您需要重新平衡负载。 Pulsar为您自动进行代理负载。它监控CPU，内存和网络（不是磁盘;我提到代理是无论如何的吗？）代理的使用，并将移动负荷以保持平衡。这意味着您不必添加那个新代理，直到您使用所有代理的容量 - 而不是因为其中一个热运行。 您可以使用Kafka进行代理负载平衡。但是，您将必须安装另一个包，例如LinkedIn的巡航控制。或者，如果您喜欢（最终）支付东西，您也可以使用Confluent的重平衡器工具。 社区和生态系统 我上一篇文章的批评之一是我没有提到Kafka社区和生态系统的大小和丰富性。这是一个公平的一点。 在社区和生态系统类别中，Kafka强于Pulsar。Kafka有一个五年的首页开始作为一个开源项目，因此它只会推出它将拥有更大的社区，更多相关项目以及堆栈溢出的更多答案。 我所能说的是，脉冲节社区正在增长，人们经常促进新的组成部分和集成，社区休闲频道的人们是友好和支持的。 实际上，我可以说还有一件事：很明显，很多Pulsar是由Kafka启发和通知的，Pulsar站在巨人的肩膀上。Kafka项目和社区赢得很多信誉和尊重。我知道它有时会听起来像是我不尊重Kafka，但我真的很兴奋Pulsar取得的成绩。 合法的Kafka替代品 在这篇文章与最后一个之间，我最多有十几个理由选择Pulsar。很酷的是，我潜入pulsar的更深，我发现的原因越多。因此，在将来可能需要在这个主题上成为第三个博客帖子。敬请关注。 我认为这很清楚，Pulsar是Kafka的合法替代品。Pulsar支持与Kafka相同的大多数功能，但有几个的优势，并且随着越来越多的人们了解它的势头。 如果您正在评估流和/或队列系统，您可以看看Pulsar。这很简单。
-
发表了文章 2022-02-13
从万物互联到万物皆数-数字化转型中数据驱动的核心逻辑
在前面谈企业数字化转型技术应用趋势的时候，我更多的是从万物互联和泛终端化，技术平台和云原生，IT组织架构重塑，生态构建等方面展开描述。而没有对一个关键内容的数据展开进一步的阐述。 对于企业数字化，在前面多次强调了三大核心内容，即连接，数据，智能。 其内在的逻辑是首先通过连接解决了基本的业务协同问题，其次是连接产生数据，数据反哺业务，同时进一步实现数据驱动运营；最后才是进一步的基于数据来实现智能化场景应用和人工智能等高阶场景。 在最新的十四五规划和国资委下发的企业数字化转型的专题报告里面，都多次提到了大数据，数据中台，包括数据治理和元数据管理。数据作为企业的核心资产越来越受到重视，从最初的数据协助业务协同，变化为了数据驱动业务，数据驱动运营，乃至数据驱动人工智能和智能场景应用。 简单来说，万物皆可以用数据化的方式进行表示，不论是文字，数字，图像还是视频，所有都是数据的结构化或非结构化展现形式而已。 信息化时代，如果库房里面有一个箱子，里面存放了我们需要的原材料，实际我们只会关系箱子里面原材料的数量，而不太会去关心箱子本身的地理位置，形状，已经箱子本身在库房里面是否移动过等信息。 数字时代，我们从单纯的关注具体的数量，到了对整个事物所有地理空间，时间上位移，状态的关注。即从简单的对事物数量的关注到了对事物整体时空信息和动态线索的关注。 在信息时代，如果组织了一场会议，我们往往会在会议后整理一份会议纪要，记录会议的内容，但是文字的会议纪要却丢失了会议上类似人员沟通互动过程的形象化内容。而到了数字时代，结构化并不是唯一选择，我们完全可以通过更多的终端设备来实现会议过程视频化和图像化的全程记录。 简单来说，在数字化时代，我们对事物的观察不再是简单的状态或数量，而变成了对整个事物时空信息和所有动态变化的全程记录。所有的文字，视频，声音，地图都是信息，最终都会转变为类似01比特流的数据化表示。 对于企业数字化谈得比较多的一个词就是数据驱动，那么什么才能够叫数据驱动？ 两个业务员到非洲去卖鞋，发现非洲人都不穿鞋。一个业务员说，非洲人不穿鞋子，这里没市场。而另外一个业务员则说，不对，非洲人都没鞋子穿，这里的市场一片大好。 上面这个例子大家都听过，实际体现的是两种不同的思考方面。在业务驱动下的思考更多的是当前是否有市场和需求，我基于市场需求去生产对应的产品；而对于数据驱动更多则是应该考虑你当前有哪些数据和资源可以利用，如何去引导或产生需求。 在业务驱动IT的传统信息化建设模式下，实际可以看到数据库或者数据的形成往往只是业务运作最终形成的历史记录。即数据本身是一个业务协同后的附属品，形成的数据作用也仅仅是后续的历史数据查询统计，后续的基于数据的决策分析等。 业务驱动下，虽然形成了数据，但是我们对数据的使用是有明显延迟的。我们对业务场景和流程的满足体现出了足够的敏锐度，但是在数据层面却是明显的钝感。 在谈数据中台的时候谈到了一个关键点，即数据要实时的反哺业务，数据能力要及时地开放出来，并实时的为业务服务。 那么这个是否就是数据驱动业务，数据驱动运营的核心逻辑？ 我个人理解数据驱动的含义不应该局限在上面这个层面，数据反哺富贵论坛业务，本质还是业务驱动，只是加快了数据利用的敏捷度，减少的数据的钝感。在本质上你并没有走出业务驱动的本质思维。 在谈数字化的时候，我们比较容易谈到类似物联网，各类传感设备，5G，云计算，区块链，数字孪生等各种技术发展趋势。但是所有技术存在的目的仍然是为业务服务，为数据的产生服务。 信息无处不在，关键是你需要如何去采集和转化。 语言的产生加速了信息的传递，群体和组织的形成；而对于文字的产生让我们进入到专科信史时代，大的历史事件可以被记录和追溯。而随着物联网，各类视频音频等电子设备的产生让我们进入了大数据时代。 所有事物静态特征和动态行为表现都是信息，所有信息皆可以被数据化。 在信息化时代，更多的信息都是结构化的表单数据，需要的是人工去手工录入和变更。而在数字化时代，我们认为所有的事物静态特征，动态的时空位移信息都应该被自动化地采集和记录。数据不应该简单停留在人工录入形态，而是应该通过连接后自动产生和形成，被自动采集，加工和存储。 数据可以精确地还原你在过去某一天的地理位置，静态特征，行动归结和路线，你开过的会，去过的餐馆等诸多信息。而这些信息并不是你特意进行了人工输入和录入，而是被自动化的进行了采集和存储。 经过前面的分析可以看到，数据驱动的逻辑不应该是数据如何反哺业务，而应该是数据如何去产生新的商业模式或业务形态。 你可以考虑你当前手里面有哪些数据资产，你如何去将这些数据资产变现，或者说为了支持你的业务战略或运营，你需要什么样的数据来支撑，然后是通过什么样的方式来采集或获取这些你需要的数据。 简单来说，数据驱动逻辑步骤应该如下： 业务目标或商业形态如何分解为数据构成当前已有哪些数据，还需要采集或集成哪些数据如何完成数据的采集和集成操作如何去运营数据完成你第一步的业务目标和商业形态 在整体思考的第3步，我们可能涉及了一个独立的业务流程或业务功能来完成数据的采集和形成过程。即业务流程本身为数据形成和积累提供服务。 CSF关键成功因素法是以关键因素为依据来确定系统信息需求的一种MIS总体规划的方法。在现行系统中，总存在着多个变量影响系统目标的实现，其中若干个因素是关键的和主要的（即成功变量）。通过对关键成功因素的识别，找出实现目标所需的关键信息集合，从而确定系统开发的优先次序。 这个实际和很多年前谈的CSF关键成功要素法类似，即先找到关键要素，要素即数据，找到关键要素后再考虑如何通过业务或流程去落地。 业务流程或协同最终服务于数据的积累和形成，业务流程是辅助，数据资产形成反而成为了核心竞争力。这才谈得上真正的数据驱动。 否则你会看到当前的数据中台，大数据分析平台等仍然是在走传统的BI和数据仓库的老路，构建的数据资产也仅仅是满足旧业务形态，为旧的业务运作服务。可以看到数据驱动思维本身又回到我们传统的目标管理和结果思维，即你关注的是最终数据资产，其次才是形成数据资产的过程，过程的价值是为结果服务。 类似当我我们谈得最多的数据驱动运营也是同样道理，你首先考虑的是运营目标和KPI，然后再考虑要达成这个目标需要采集和形成哪些数据，构建哪些模型。然后再有针对性的通过业务流程或业务功能，智能的泛终端设备等来实现数据的采集。 在很早以前的人工智能研究里面，更多的就是想着去模仿人脑思考和推理的过程。通过提供不同的输入方式让计算机进行学习，产生一个算法模型。然后对于新的问题可以用模型去解决。类似人工神经网络，遗传算法等都是这个思路。但是当你提供的输入不足够多的时候，这个模型很难快速地收敛，也很难得出一个精确化的确定模型。 在大数据出现后，形成了计算机解决问题的新思路。 深度学习+大数据=人工智能 即从传统学习和建模推理思路转移到基于统计学的思路，简单来说就是只要有足够多的数据，我就可以自我学习，自我训练，形成了类似人脑一样的智能处理和分析能力。 比如一个计算机能够识别一只动物图片是猫，并不是计算机能够精确地描述出来猫应该具备的体型特征，而是图片中的动物的特征矩阵和数据库里面的动物猫最匹配而已。包括谷歌的阿尔法狗战胜李世石在17年也引起了轰动，再次展示了深度学习算法和人工智能的威力。 以阿尔法狗为例，再来看数据驱动思维就应该是： 目标：期望开发一款阿尔法狗的围棋大师数据：需要收集所有的历史棋谱信息过程：对数据进行录入，并进行深度学习训练 这也进一步的说明数据驱动下的思维过程是目标驱动的，并不是说你以前的业务产生了多少数据，如何更好地利用这些数据。而是在谈我们希望有一种什么样的智能化能力，这个智能化的能力需要我们去采集哪些数据，开发哪些功能，如何进行建模和训练。 在业务驱动的思路下，你老想着你已有的历史数据资产，想着这些数据资产能够产生哪些价值，但是这些数据资产往往除了做一些辅助决策支持外，并不能产生大的作用。 如果真在要做大数据分析和人工智能，那么你需要采集数据的范围，时空的广度都必须成倍地增加，也就是谈到的一些信息既数据，要以目标驱动来思考究竟需要哪些，然后有针对性的去采集和集成。
-
发表了文章 2022-02-12
40岁C++没有中年危机
强大、灵活、复杂：C++ 的起源可以追溯到 40 年前，但它仍然是当今使用最广泛的编程语言之一。为了找出原因，TechRepublic 采访了 C++ 之父 Bjarne Stroustrup。 C++ 的起源可以追溯到 1979 年，那时编程语言的创造者 Bjarne Stroustrup 第一次开始研究 C++ 这门语言，当时被称为“带类的 C”（C with Classes）。该语言的设计初衷是作为对 C 编程语言的改进，添加了一些基于面向对象编程的功能。 Stroustrup 告诉 TechRepublic 说：“C++ 的成功显然令人吃惊。我认为 C++ 的成功在于其最初的设计目标：高效地使用硬件，再加上强大的抽象机制，并在实际使用反馈的基础上谨慎地改进”。如今，它已经成为最受开发人员欢迎的语言之一，支撑着世界各地的系统和服务。 Stroustrup 解释道：“我想建立一个多计算机系统，它有一个通信系统，既可以是共享内存，也可以是网络。” “我的重点是软件。我需要编写接近硬件的低级代码，例如内存管理器、进程调度器和设备驱动程序来分离软件组件，以便它们能够在通信方式定义明确的不同计算机上运行。” 在那时，还没有一种语言能够胜任这项任务，因此 Stroustrup 致力于构建一种语言来胜任这项任务。他这样描述这种语言：“带类的 C 应该结合了 C 接近硬件工作的能力和类似 Simula 的抽象和代码组织能力。” 从相当早的时候起，Stroustrup 就认识到，他不能在控制语言方面实行“专制”。尽管早期 C++ 的工作仅仅涉及到他和贝尔实验室（Bell Labs）的几个同事，但当 C++ 语言标准化的努力开始时，这方面的工作才迅速增加到几十人。 如今，C++ 的标准委员会中有大约 400 名成员，以及关注并试图影响该语言发展方向的广大用户社区。 那么，在面对满怀热忱的人们时，该如何使编程语言保持连贯性呢？“这是一个机遇，也是一个巨大的问题，”Stroustrup 说。 “最困难的部分是确定重要内容并保持连贯性。一旦你知道自己想要什么，最终，你就会发现一种很好的技术方法来达到目的。” 1998 年，C++ 正式实现了标准化，并成为可靠的主力军。至此，C++ 已成为世界上最常用的编程语言之一，并且一直保持到今天。 Stroustrup 说，正是 13 年后 C++11 的到来，这才为该语言未来的发展奠定了基础。他说：“C++11 使 C++ 感觉像是一种全新的语言。” “对并发类型的安全支持是必不可少的。C++11 提供了一个密集的网络，其中包含相互支持的功能，如用于编译时计算的（常量表达式）函数、lambdas、自动类型推导以及可变模板。” 尽管 C++11 引入了一些新的特性和功能，使得该语言变得更简单，更快速，更具表现力，但这种语言仍然以难以掌握而著称，Stroustrup 也承认了这一点。 Stroustrup 说：“C++ 确实很复杂，要想学好用好它，需要付出很多努力。不幸的是，人们不只是想要简单，他们还想要某种不可能的东西：一种更简单的语言，拥有更多的特性，并且还不会破坏他们现有的代码。” Stroustrup 对这个“三难问题”的回应，正如他所说的那样，就是增加一些特性，“让简单的事情变得简单”，举例来说，通过对常见的用例进行泛化或直接支持——同时还要保持兼容性和稳定性。 对于像 C++ 这样的“庞然大物”，或者任何主流编程语言来说，这件事说起来容易做起来难。Stroustrup 解释说，在决定采用哪种新特性还是省去哪种特性方面，达成共识是一个巨大的挑战，需要大量的努力、讨论、时间和耐心。 即便如此，也并不是所有的优秀特性都能被接受。他解释说：“你必须试着只加入那些真正能帮助人们的东西，然后再加入一些这样的东西——因为如果我们接受那些能够帮助人们的特性，语言就会不堪其重而倾覆。” Stroustrup 指的是Vasa，这是 17 世纪瑞典的一艘大型战舰，由于设计不佳，在处女航时就在斯德哥尔摩港沉没了。 他说：“在国王——最高管理者的坚持下，这艘战舰满载漂亮的雕塑和大炮，这与技术人员的专业判断相悖，造成这艘战舰头重脚轻，结果被一阵风给掀翻了。” “我反复谈论并撰写关于 Vasa 的文章，来提醒和警告那些渴望通过添加特性来改进 C++ 的人：记住 Vasa！因此到目前为止，C++ 还没有‘倾覆’。” 这么多年来，是什么秘密使 C++ 保持活力？“从小处着手，阐明基本原则，明确长期目标，并根据现实世界中实际使用的反馈进行开发。” 事实上，C++ 在诞生 35 年后，依然保持着强大的生命力。今天的 C++ 远比早期的 C++ 更强大，更具表现力。但即使在今天，最初的设计依然可见。 Stroustrup 说：“40 年前编写的一些简单的程序，到今天还可以运行。” “对必须工作几十年的语言来说，稳定性是一种重要的特征。实际上，许多早期的想法只有在 C++20 中才能实现。我从一开始就知道，我不可能构建理想的语言，因此我必须以渐进式发展为目标：改进。说真的，我并不相信完美语言的想法：要怎样就算是完美呢？对谁来说（是完美的）？” 他补充说：“为了应对不断变化的世界的挑战，融入新思想，改进是必须的。” 截至 2021 年 9 月，C++ 是全球第四大流行的编程语言，仅次于 C、Java 和Python，而且根据最新的 TIOBE 索引来看，它也是增长最快的语言。 作为一种通用的编程语言，C++ 以其强大的功能和灵活性而受到开发人员的青睐，这使得它成为操作系统、网络浏览器、搜索引擎（包括 Google 的）、游戏、学历证企业应用等的理想选择。 Stroustrup 总结道：“如果你有一个问题需要高效地利用硬件，同时还需要处理高度复杂性，那么 C++ 显然是一个不错的选择。如果你没有这两种需求的话，那么低级高效的语言或者高级但不高效的语言都是可以的。” 然而，即使 C++ 广泛流行，Stroustrup 也指出，要想准确地确定 C++ 确切的用途和用处，是非常困难的。 “对这两个问题的答案，估计是‘无处不在’，”他说。 “在任何大型系统中，你通常会在低级和性能关键部分发现 C++ 的影子。系统的这类部分往往不会被最终用户看到，甚至不被系统其他部分的开发人员看到，所以我有时把 C++ 称为一切的无形基础。” 同时他也强调了在评估特定编程语言的学历流行程度时，开发人员调查相对不可靠：“计算程序员的人数既困难又简单。网络调查通常只是测量‘噪音’，也就是说，统计的是人们都在谈论的，而非他们实际使用过的。” 如今，Stroustrup 是 Morgan Stanley 的技术研究员。他与国际标准化组织（ISO）合作制定 C++ 标准和 C++ 核心指南的工作，这被认为是他在这家金融巨头公司的角色的一部分，他仍然非常积极地参与 C++ 的开发。 最值得注意的是，Stroustrup 是方向小组的成员，该小组提出并讨论关于编程语言未来的建议。他还关注改进小组，并参与有关新语言特性的讨论。 然而，当涉及到 C++ 的日常运行方面时，Stroustrup 更乐意担任次要角色。“我关注行政工作，但尽量少做。我并不是一个伟大的管理者，”他承认。 在新冠肺炎疫情之前，Stroustrup 会经常四处授课，并通过他的书籍、文章和采访向全世界解释 C++，但和世界其他地方一样，这一工作在 2020 年暂告一段落。 Stroustrup 说：“在我的工作中，我非常依赖于与人们交谈，了解他们的问题，并且倾听我的想法是如何帮助他们的。” “在这个新冠肺炎疫情期间，我得不到急需的反馈。而虚拟会谈和现实不一样，在讨论设计和想法时，Zoom 会议的效果并不如真正的面对面会议。” 新冠肺炎疫情阻碍了 C++ 编程语言的下两个迭代版本：C++20 和 C++23 的开发。但 Stroustrup 确认，“几乎所有”的C++20 将在 2020 年发布。 “除此之外，还有 Unicode、数字、游戏开发和低延迟、工具、人工智能等方面的工作都要去做。”他说。 “当一个特性（语言和库）准备就绪时，我们就会进行发布，并且我们每三年会发布一个修订的标准。已按时发布的有 C++14、C++17 和 C++20。值得一提的是，标准的制定与主要实现者是高度同步的。” “让 C++ 保持连贯性，并作为一个稳定的开发平台，这一点至关重要。”
-
发表了文章 2022-02-12
2022年前端技术观察
关于前端的核心竞争力 如果说服务端同学进击全栈是试试水，Native进击全栈是试试水，那前端里很多同学进击全栈就是在拿生命在玩全栈了。 服务端玩玩Node，不喜欢就算了，玩玩Angular和Bootstrap也就在后台开开荤，前台各位视觉设计，UAT还原检查，各种动效，用Angular和Bootstrap能把自己玩死，而后台基本上一直是服务端的自留地，很多做前端开发的同学甚至没开发过后台界面吧？Django甚至都自动给你生成了。后端的核心竞争力在哪儿？在添删改查，在数据库设计，在性能优化，在shell脚本，在分布式，在网络安全。玩玩票不影响自己的大本营。 同样可以一门语言前后台通吃的Android开发，你看看他们对全栈是不是像前端圈那样热情。从DNA来看，对Java语言可比JavaScript和Node更亲吧？再往远了说，看看C++客户端的同学对服务端有没有那么大热情？ 还是那句话，好学是好的，前提是自己的大本营要守住，一专多长。你得先专一门，再想着横向扩展其他领域知识。前端开发的核心竞争力是什么？2016年年中，我在微博上说，前端的核心竞争力在于一些HTML标签、CSS，JavaScript的熟练度上。这些东西是前端自己领域的知识，比如Form2.0、Websocket、离线缓存、Webworker、Border-image、Canvas。一些同学回复说“核心竞争力居然只是些API，这有什么难度？”此言差矣。或许这样认为的，以跨界而来的“全栈”工程师居多。有些知识确实只是API，比如JSON.stringify和window.getComputedStyle之类，看了就会用，用起来也没有什么实践方面的坑。但并不全是，比如Form2.0可是有一系列新东西，新标签如output，新类型如number，新属性如pattern，新的CSS伪类如:valid，需要融合在一起考虑，形成一个Form2.0的解决方案。再比如Canvas2d，Canvas提供了像素级API，可以直接存取颜色，可以把像素导出成base64的字符串，提供了DOM没有能力，但同时也完全没有了DOM的便利，比如Canvas上画的某个按钮该如何进行事件监听呢？比如不能使用CSS了，该如何实现:hover伪类，又如何让布局实现自适应性呢？什么样的情况下该使用Canvas，什么情况下该使用DOM，如果有某个功能必须依赖Canvas实现，比如在网页上做个美图秀秀，将产品的哪些元素放到Canvas上，哪些元素放到DOM上，两者又如何合作呢？换成纯Canvas解决方案会不会更适合呢？前端的知识不同于服务端，大部分的工作量都在图形界面上，而图形界面是件很细的活，工作量和技术含量全在细节。我经常对非前端的同学举一个例子——你知道垂直居中有几种方法，不同方法的优缺点吗？有些跨界而来的同学，以及部分前端圈的新同学都不以为然，嘲笑说这叫“回字的四种写法”。其实，前端在实战时，垂直居中有多种方法，基本上没有方法是无副作用的，要看情况，不同的情况要选用不同的方式才能实现最好的自适应性。感兴趣的同学可以去搜搜看前端的垂直居中方法整理。看完之后，就能明白前端CSS的精彩和玄妙。 我批评很多同学基础不扎实就开始乱折腾，不是说多学习不好，而是说大本营都未扎牢，如何实打实地高效完成日常工作？ES6、CoffeeScript、React、Webpack等，都解决不了你在实战时遇到的具体挑战。这全是些外围功夫，并非核心。先把核心学好，外围功夫什么时候学都可以，又不难，你说对吧？ 那么什么是核心呢？HTML、CSS和JavaScript。我指的是原生的这些东西，不用上来就跟我说React的JavaScriptx语法重定义了HTML，Sass改良了CSS，TypeScript给JavaScript带来了静态语言的语法，这些都是外围，今天是React，明天可以换成Angular，今天是Sass明天可以换成Less，今天是TypeScript明天可以是CoffeeScript，这些不重要。就像jQuery鼎盛时期，很多同学不学原生JavaScript，上来直接就上手jQuery一样，走不远。要理解jQuery为什么这么封装，其实在底层发生了什么，用原生会遇到什么问题，直接用原生能解决吗？把原生的技巧学熟了，这些外围的东西上手很快，而且什么情况下用什么，心里会非常有底。 过去，前端领域并不像如今这样浮躁，很多人都知道基础的重要性，也知道基础是什么。但当跨界的“全栈”进入前端圈以后，很多浅显的道理都被有意无意地搅昏了。速成、革命、淘汰、全栈成了主旋律和政治正确。可是，就像投资界里爱说的一句话一样：“风起来了，在风口上猪都会飞。可是等风停了，还在飞的是老鹰，而猪会摔死。”风会停吗？当然。该潜心修炼还得修炼，基本功不扎实以前，别糊里糊涂跟风浪费自己时间，缺什么要恶补。 今天说得很热闹的HTML5其实是从HTML4加强而来，两者不是替换关系，而是“强化”，就像ES6之于ES3一样。很多新入行的同学希望可以速成，然后从哪儿热门往哪儿入手，这其实不对，最好的学习方法是从HTML4学起，尽管在实践时有很多HTML4时代的技巧，在HTML5时代有了更好的替换方案，但也有很多HTML4时代可以一直用过来的技巧。让我担心的是，HTML4时代的好书，到了HTML5时代已经不再出版了，而HTML5相关的书籍基本上只讲了HTML5相较于HTML4的增量部分。而HTML4时代的书和相关技巧就这么失传了。除了书，博客和所谓社区也是一样，现在已经不再讨论以前的一些精华技巧了，有些技巧确实是淘汰掉了没有什么价值，比如IE6的hack技术，但也有些技术是很棒的CSS技巧，比如CSS滑动门依然适用。我推荐一下几本书和学习步骤，给有心弥补基本功的同学： 《CSS网站布局实录》——国产CSS2入门书，有些技巧已经淘汰，但仍不失为最好的CSS入门教程。 《无懈可击的Web设计》——讲CSS应用技巧的书，国内外粉丝别多，说是开创了CSS技巧流派也不为过。 《DOM JavaScript编程艺术——JavaScript最好的入门书，没有之一，这本书是帮助你了解如何将DOM、CSS和JavaScript连接起来的一本书。严格来说，后端Node根本不算JavaScript，JavaScript是基于ES语法的一门脱水语言，如何实现的胶水？这本书将带你入门。 《JavaScript高级程序设计》 ——JavaScript必读的一本精典，读完之后对JavaScript的理解和实 践会上升非常大的一个台阶。 《编写高质量代码——Web前端开发修炼之道》 —— 举贤不避亲，这本书是我写的。推荐的原因是，这本书重点讲团队合作的注意事项。虽然一些具体的技巧，在今天已然过时，比如IE6的hack，但在团队合作方面的思考，直到今天我也没看到其他书在讲，这些思想没有其他书可替代。 《HTML5和CSS3权威指南》——目前为止，我读过的HTML5方面最好的一本原创书。配合实例进行API讲解，非常详细具体。连HTML5都提供了哪些底层的东西都不知道，又该如何去用好它呢？在我看来，是学习HTML5的必读书。 《响应式Web设计：HTML5和CSS3实战》——作者是《无懈可击的Web设计》忠实粉丝，所以很自然地，这也是本CSS技巧流派的书，侧重点在CSS3的实践技巧上，让人大开眼界。 《JavaScript设计模式》——JavaScript在实战时的高级技巧。 前端很棒的书有很多，这只是几本我觉得最不该错过的书而已。从HTML4一路到HTML5和移动时代，一路上有了很多新技巧，也淘汰了一些旧技巧。当下的学习氛围虽然前所未有的强烈，但急功近利和盲目无头绪现象也很严重。在我看来，很多人不愿意做苦活累活扎扎实实打基本功，一句“那些都淘汰了”就拒绝了所有的优秀遗产，希望花少量时间看看流行时髦的新工具新框架，然后就迅速挤身行业顶端，这想法既偷懒又幼稚。什么是外围功夫，什么是真核心技巧，什么是珍珠什么是盒子要分得清，自欺欺人并不是什么明智的想法。你可以几天几个星期就掌握的东西，别人也可以，就算人家比你笨，多花一倍的时间也能跟上你吧？要真的拉开和其他人的距离，只有下苦功这一途。 这些话，恐怕没有几位前端老人愿意说。当我问他们，拼命强调新风向，而不再提基本功，造成知识断层，造成这些同学心高气傲但完成不了工作怎么办时，一些老人的回答是“他们自己不重视基本功，怪我喽”。如果你基本功很扎实了，想学什么外围功夫都可以，虽然多学总不是坏事，只是在决定投入使用时，还需要看团队情况再慎重决定，团队合作要考虑的事情有很多，要有责任感，别只顾着自己当Geek。 关于Angular，后台，SPA 关于Angular，我是不认同的。Angular是Google服务端团队折腾的作品，整套代码组织的思路和服务端的MVC框架如出一辙：URL路由 + Controller + 数据抽象 + 模板引擎。虽然服务端出身的同学会倍感亲切，但这真的不是前端代码最好的组织方式。 我对此的判断是，Angular团队因为自身服务端出身的基因和思维模式，创造了一个对服务端团队最友好的框架，目前用户群体也是以服务端团队为主，适用场景以后台这种定制动效和定制UI要求不高的场景为主。事实上，Angular2决定使用TypeScript开发我也毫不意外，因为TypeScript本来就是Java服务端团队更喜欢的静态严格语法，Angular团队决定讨好他们自己讨好和他们相同背景的程序员群体，放弃普通前端工程师习惯的脚本弱类型习惯，也完全是情理之中的事。 唯一让我奇怪的是，我们的传统前端工程师为什么要去追捧这么一个框架呢？人家根本就没在意你好吗？就像从传统服务端转到Node服务端的同学会奇怪，为什么一群前端工程师对Node服务端这么感兴趣一样？这关前端什么事？我们去凑什么热闹？最近流行一个段子，说一个放羊的和一个砍柴的聊了一天，然后天黑了，人家放羊的羊吃饱了回家去了，可你砍柴的呢，你的柴呢？你的前端基本功呢？你的前台应用场景呢？ 我觉得“全栈”这个词很讨厌，原因在于它搅混了很多事。从定岗上来说，后台的前端部分，到底是由谁来开发？是由前端工程师来开发呢，还是由服务端工程师自己来开发？在过去相当长的一段时间里，后台是怎么开发的？是由Frameset来组织代码的，并非SPA，后台的界面往往非常难看，基本上只是后端工程师自己顺手就给做了，没什么UI定制需求，也没什么动效，了不起有些正则表达式验证而已，连AJAX的要求都不高。前端工程师基本上是不做后台相关的工作的。那么如果后台并不是给自己使用的，而是给第三方使用的呢？是外包公司呢？后台界面如果需要有更好的卖相怎么办？Extjs就派上用场了，还算不错的界面设计和丰富的组件，而且完全支持SPA开发，只不过Extjs组织SPA是以组件为单位来组织的，并非服务端熟悉的MVC那一套。所以这种情况下，后台是需要依赖专业的前端工程师介入的。Angular最适用的场景应该就是这样的情况了，取代Extjs，让后端工程师自己按照自己的熟悉的方式进行“全栈”开发。 问题是，后台因为种种原因，从来也不是前端工程师的主战场啊。后端能自己搞定自己玩去嘛，前端工程师在实际工作中，更多的工作在什么地方，在前台啊，和视觉设计师的PSD直接打交道吧？和交互设计师或产品经理设计的交互动效直接打交道吧？要切页面，要玩透CSS吧？跟人后端工程师屁股后面追Angualr，结果人家Angular升级到2用TypeScript了，不兼容了，傻眼了吧？信不信人服务端过来的“全栈”比你一前端玩Angular玩的更溜？而且就算你辛辛苦苦把Angular那么复杂约束性那么强的一套框架学得特别顺了，可是别忘了你的工作主战场在什么地方？你是天天在写后台，当我没说，可是如果你天天在写前台，那是真心找虐……醒醒，你这砍柴的别陪人放羊的一起谈全栈了。 前台最适合以什么方式组织代码，下面我会再讲，现在先跟后端工程师谈谈心 ——以Angular来为后台组织SPA真的是最好的实践吗？和传统的Frameset相比，真的性价比更高吗？首先，我赞成从纯技术角度来看，Angular是适合后台场景的方案之一，只是即使是后台开发，也有三种技术方案可以使用： Frameset——一般的后台，能用就行了，样式，无刷新都不重要，反正给自己人用的，怎么快怎么来。开发速度快，需要前端配合，分工也容易，维护也容易，招人门槛、人流失进行交接都风险小得多。在技术选型之前，先想想你是否真的需要为后台提供SPA。 Angular——给第三方使用的后台，对样式，无刷新体验要求较高的，而团队中又没有专职前端工程师，需要服务端工程师自己上的，结合Angular和Bootstrap是个不错的选择。只是Angular这一套的学习成本不低，而这一套其实又很难和普通前端前台需求普适，性价比不高。如果想用一套技术完美通吃前后台的前后端代码组织，你应该考虑方案3。 组件化组织，自己抽象——其实思路和Extjs一样，以组件化方式来组织后台的SPA。只是Extjs的学习成本也不低，而且样式也不好定制，所以你需要的并不是去学Extjs，而是学习如何自己封装组件。封装些Scene、SceneManager、Widget抽象类、组织个SPA出来很简单的，模块化组件化可维护性都不是问题。有同学会问了，那模板呢？通信呢？首先模板不是必须的，我个人不推荐在前端使用模板引擎，这在本质上和组件化是相悖的，就算真的要用模板引擎，有很多垂直的JavaScript模板引擎可以选择，通信也不用Angular那么麻烦，通信最主要是想解决一个什么问题？组件和组件之间解耦，但又需要保留组件内部的Context，很简单，通过全局的自定义事件，为事件进行传参，就可以轻松实现组件的通信了。多简单一件事，折腾出约束性这么强的一个框架出来，何苦呢？ 关于自定义事件，以及组件化，我做过一个视频教程，不依赖React之类的框架，很原生态，方便对组件化的具体技巧有更深入的理解。有兴趣的同学可以看看“阿当大话西游之Web组件”。 关于React 2015年底我批了Angular，同时也批了React。但我反对它们的理由其实并不一样。 首先，React是组件化的思路，这个我是认同的。首先跳出Web前端这个圈子，咱们看看别的GUI技术，无论是桌面软件开发、Flex、移动还是游戏，都是以组件的方式来组织代码的，可以说GUI编程按组件来组织代码是普适的最佳实践。Web前端有两方面的原因，导致其代码组织方式出现了Angular这种非主流： Web服务端是唯一可以和HTML无缝结合的，这是为什么JavaScript、PHP、ASP又被叫做动态网页的原因。所以前端和服务端有扯不断理还乱的历史原因。看看服务端染指iOS或者桌面开发容易不？ 前端的原生控件实在太少也太弱（看看.NET和Flex的控件），数都数得清楚，text、radio、checkbox、password、button、img、audio、video等，长期以来，前端不得不自己封装组件，Extjs、YUI、Dojo、Prototype无不如此，还有丰富的各种jQuery组件。成也封装败也封装，封装给前端带来了强劲表现力的同时，也降低了前端同学自己动手写组件的能力。大多数人都是拿来主义，但拿来主义并不是最可怕的，可怕的是拿来主义的同学没有意识到组件之于GUI的意义是那么不可动摇。 举个简明的例子说明Angular的MVC和组件化之间的不同吧： Angular是什么思路： 而组件化是什么思路： Angular为代表的类服务端MVC框架，上来直接分成M、V、C三个层，然后将互相关联的三块分到了三个层里去，这么干最大的坏处是破坏了抽象。而组件化的核心就在于抽象，将相关的属性方法内聚到一个组件里去，这是符合面向对象的思维模式的。我自己既做前端开发也做服务端开发，服务端开发在MVC框架的帮助下，基本上在应用层不需要做任何的抽象，Controller不过是函数而已，M是和数据库、缓存打交道的命令而已，即使有ORM抽象，那也是毕业证框架替我抽象好的，不用我自己做任何抽象，而模板引擎就更加机械化操作了。但我做前端开发时状态完全不一样，我需要通过组件化来将界面变成一个个自定义的组件，我需要不停地抽象：这是不是可以抽象成一个组件？它的属性有什么？它的方法有什么？它的DOM节点最外层容器是什么？我如果要封装方法该封装什么方法为公用，什么方法为私用呢？我需要不停地进行思考，因为前台的界面是各种各样的，不可能像服务端一样由框架高度抽象出一些通用逻辑进行封装的。事实上，前端除了少数的通用组件可以直接使用第三方的，比如模拟弹窗、富文本编辑器什么的，大多数的需求只能自己封装，这是件非常考验人面向对象思维能力的事。 所以，我认为前端的前台需求，不应该由重框架来提供减肥解决方案，“轻框架 + 组件化 + OO”设计才是最优解。也就是说，前端不应该多提供约束性的框架，而应该提供基础工具帮助和通用组件就可以了，在应用层，要考验前端工程师自己的能力，没有任何框架可以帮你去抽象你的业务需求。所以我觉得前端比服务端苦逼很多。 那么我说的“轻框架 + 组件化 + OO”设计是不是之前没有业内的实践呢？当然不是。事实上，前端长久以来，一直是轻框架 + 第三方组件的模式。只不在过应用层，各家公司的前端工程师大多数能力水平很有限，而业务需求也并不复杂，所以在前端圈里OO设计和自定义组件并没有流行开来，究其原因主要是门槛有些高，而大多数程序员们又自我要求很低。 听不明白轻框架 + 第三方组件 + 应用层面条代码？想想jQuery + jQuery组件 + 大多数前端工程师用jQuery写的代码你就明白了。 既然jQuery已然可以提供必要的帮助了，那么还要React干嘛？jQuery有一个致命的问题，就是jQuery本身是基于plug模式来写扩展的，对第三方组件并没有统一的更组件化的方式来标准化它们，这就直接造成了不同的人写jQuery组件会有不同的风格。这对团队合作并不是什么好事情，如果说是第三方组件，如果封装的质量很好，倒也罢了，毕竟只使用它的API就够了，内部实现再怎么乱也不用去计较。问题出在自家公司的自定义组件，如果公司里有几个人团队合作，一个人一个风格怎么行？我们需要一套标准来约束大家按相同的风格来组织代码。这就是React最大的意义所在，填补了jQuery的这个不足。但这是否意味着离开React就无法组件化了？当然不是，比如我的视频教程里就有另一套风格的组件化范式。 这套风格并非是我原创，而是从YUI3学来的，思路是可以穿越语言和框架的，我不过是将这套思路从YUI3带到了jQuery。事实上我是YUI的忠实粉丝，真的是座巨大的金矿，随着雅虎日渐衰落而停止了维护，真是让人遗憾不已。requireJs、React的组件生命周期，YUI早已在2008年就实现了，它的思想超出这个时代很多年。但这又如何？技术理念的先进有什么用呢？还不如会推广和上手门槛低来得实惠，我觉得YUI和jQuery相比，一个是航空母舰，一个是小渔船，但又如何？jQuery获了开源大奖，API上了犀牛书，成了事实上的工业标准，而YUI呢，谁还记得这个低调的大拿呢？ 我不再追流行，也不看理念是否先进，而是重视工业标准，原因正因为我并没觉得有多少新东西，而且理念先进不等于接地气，不接地气不讨好普通的懒惰的程序员就很可能活不下来。可能因为受过太多伤，所以变得不再容易被挑唆，变得格外挑剔吧。有兴趣的同学可以看看我曾经写过的一篇文章，文章写于Flex在前端圈异军突起，无比时髦的2008年。现在看来，这些激情还是太幼稚了。《[RIA之争，我的看法]》一些喜欢说我不求上进倚老卖老的同学，想送给他们一句王朔的话：谁没有年轻过，可是你老过吗？ 说回到React的问题上。我之所以不认同，并不是认为React在技术上一定是走错了路，而是因为React把简单的事情越搞越复杂，现在一提React就是React全家桶，它的野心很大，还想解决Native开发的问题，但经验告诉我，这很危险，这意味着学习门槛、团队合作成本、招人成本、人员流失风险。如果React并不能带来技术普及，只是昙花一现呢？谁来为公司里的那些遗留代码负责？谁又来为初出茅庐基本功都未扎实的同学浪费的时间负责呢？我脑子里时常想的是YUI、Dojo、Extjs这些过去前辈们的心血，就这么基本毫无痕迹地被遗忘了，而jQuery这小草根居然活下来了。谁能保证React这个套路下去，不是个短暂的狂欢呢？除了一些在社区里闹腾的同学，这些技术真的被广泛采纳和推广下去了吗？以我的经验，深表怀疑。 再强调一下，对于个人要学习，没有任何人会阻拦你，而且学习是对的。问题是，别轻易在团队里强推，想清楚在公司里推广起来坑多还是利多。我总是习惯性站在一个技术负责人的立场上来看问题，难免保守，我只是希望激进的同学理解，公司并非个人的实验田，你不开心你会考虑换工作，但你留下的摊子，还得有人收拾。所以我想，冲突的根本应该就在于此吧。 React总的来说，不像Angular走错了路，但因为全家桶的原因门槛越来越高，这不是个好现象，未来有待观察。个人不是太看好，但确实也没有更有力的挑战者。要么像我一样坚守jQuery，自己做组件抽象类，配合jQuery的第三方组件工作，等待更有冠军相的角色出现，代替jQuery成为新工业标准，要么就小心翼翼用上React好了，我也想不到有什么别的路可走，当下这阶段确实挺邋里尴尬的。另外，别小看jQuery，我认为jQuery仍然非常坚挺，而且仍然有非常大的可能性成为最后赢家——补上组件抽象类和单向数据绑定就可以了。而这些通过jQueryui都不难做到。 组件化是对的，但组件化框架其实是很轻量级的，用不用框架，以及用什么框架问题都不大，不是说有了什么组件化框架，就像奢龙刀一样开了外挂了，不是的。组件化不过是编写高质量代码的基础而已，真正的挑战在抽象上。能不能养成面向对象的思维模式才是关键，而面向对象要具体去抽象组件时，是没有定式的，要看应用层具体的需求去做抽象，这也是为什么我说前端不该去做约束性特别强的框架的原因所在。轻框架，重应用层抽象才是GUI编程的正途。 关于抽象和面向对象，你真的掌握了吗？封装、继承、多态、设计模式、解耦、API设计这些真的都熟练了吗？我接触过的前端，绝大多数同学都毫无概念，均表示听说过，尝试过，但实践不多。 可以看看我的源码，如果是你自己开发，又会如何组织代码。 关于SPA和Web Site 说到Angular、React之类，很多同学都会提到SPA和Web App。然后说SPA的春天来了，说代码质量要提高了，jQuery可以去死了。但事实上，真的如此吗？ 后台是否搞SPA我其实并不关心，搞不搞都可以，搞的话我也不打算用Angular来做，服务端的全栈们如果要用Angular搞后台我也没意见，只是你自己开发的自己维护，别你做的技术选型硬拉上我。但对于前台部分，我期待SPA其实很多年了。从我用Flash做RIA应用时，我就知道前端做SPA比起Web Site要复杂多少了。我2008年开始写HTML的SPA，早期做的一个很复杂的例子，现在还有保存，真的很复杂，当时通宵了好几天。我从2009年开始，做的前端程序基本全是SPA，我很早就在一些技术大会上讲，前端应用时代会来临（当时还没有SPA这个叫法），模糊C/S和B/S的产品形态边界，同学们要抓紧时间提高自己，不要到时被淘汰了。但我等了很多年，也没迎来SPA的大爆发。Web Site一直是主力产品形态，根本就等不来SPA时代。今天很多同学说SPA说得很热闹，事实上很可能只是这些同学的一厢情愿。 事实上，SPA时代等是等不来的。一个可悲的事实是，工程师在公司里的定位都是执行层，而非策划层，策划是上游，对应的岗位是公司老板，最次也是产品经理，不是工程师。而产品经理们会什么呀？他们身上没有技术基因，不会主动想到Web前端可以做新的产品形态的。如果产品层面没需求，你怎么等来SPA时代？只有一个可能性能等来，就是国外有一个非常成功的项目，是用SPA做的。那么国内很可能从老板到产品经理会跟风去抄袭一个。也就是说，国外的老外们不做出点什么产品创新，我们国内的工程师就很难有机会有生产环境上做些SPA的富应用了。有些同学拿了几个简单的页面给我看， 到了AJAX无刷新，然后display：none和block实现了场景切换，跟我说，看，我们SPA了。其实真不是。在我看来，SPA真正的威力不是把多个网页变成单个网页，而是在产品形态上就彻底跳出网页般的排版布局。比如说做游戏、做网络IDE、做网页版PhotoShop之类。而这，需要的不仅是技术能力，而进一步需要产品设计能力，能不能技术驱动产品创新，不要再折腾什么技术工程化，发点力在技术产品化上。如果Google的工程师不用AJAX做Gmail，网络邮箱是不是会一直是Frameset方式？如果Google不做Google Map，是不是我们就一直没有网页地图可用了？我们自己能不能主动想想Websocket、Canvas2d、WebGL、CSS3之类的东西能不能做些和HTML4时代不同的产品出来？我举个例子，带图画板的网络聊天室怎么样？基于WebGL的Mmorpg怎么样？在同一个页面上打通DOM和WebGL会怎么样？我再留一个问题给各位思考：Canvas可以实现截图，toDataURL方法嘛，那么DOM能不能通过技术手段实现截图功能？给个提示：遍历DOM节点，然后做z轴上的排序，然后一个一个将他们画到一个看不见的Canvas上去…… 几年前我就一直置力于技术驱动产品创新，号召圈里的同学们多投入点精力在技术产品化上，不然HTML5那么多牛逼的功能都白瞎了，说是进入了HTML5时代，可是产品形态依然没有啥变化，身为前端工程师我觉得很耻辱。可是，我一个人的能力实在有限，我努力了几年，我也号召了几年，然后终于放弃了。现在我已经死心转型做产品了。相信我写了这样的文章，看官看完之后，依然会该干嘛干嘛。 关于SPA，再多说两句，就是SPA的代码组织方式不用围绕URL路由来组织，如果是个纯单机应用没有服务端，是不是代码就没法组织了？当然不是。路由是好东西，但我推荐用自定义事件来进行路由，不要用URL。 最后，SPA什么时候可以迎来大爆发？我反正挺悲观的，我等了6、7年没等来。现在说得热闹，可是没见着几个SPA的强产品需求。没有产品层面的强需求，其实意味着折腾来折腾去，不过是前端圈自己在玩，孤芳自赏，以及面试时为难应聘者，跟前端面试时面算法似的。 React Native和PhoneGap 再说说React Native。我不看好这种方式，阉割版的CSS导致前端技能的受限，对Native底层的黑盒导致调试和扩展的困难，另外“learn once write anywhere”的性价比也并不高。而且，公司定岗的原因，iOS和Android团队也绝对不会对你友好，就像前端学了点Node服务端去挑战Java、PHP后端位置一下。于技术，于团队，真的是坑多于利的技术。 相比之下，PhoneGap那种思路，GUI交给Webview里的H5，底层交给iOS和Android，Native和H5通过jsBridge通信，是团队合作成本最低的方式，而且只要jsBridge写得好，一套HTML5代码也是最容易实现“write once run anywhere”的。三端的界面可以共用一套代码。我更倾向于后者。 当然，一个不容忽视的问题是，webview当前的性能还有严重问题，如果交互效果复杂一些，在低端机上的表现就会卡顿，所以采用这种技术方案时，受限于性能，产品的设计要尽量简单。 当下并没有完美的解决方案，但各方面原因考虑下来，hybird仍然是更好的选择。React Native唯一能拿出来说事的只有webview性能不好这一点，只是如果webview的性能问题在未来得到解决了呢？记得摩尔定律吗？所以说React Native不过是个不怎么样的临时解决方案而已，一旦webview的性能问题得到质的变化，React Native就没什么存在价值了。当然，话又说回来了，webview性能问题什么时候能够被解决呢？也没那么乐观，反正我从2011年等到现在也没等到。iOS其实已经很不错了，Android的碎片化是个深坑。 对了，我徒弟就用HTML5做了个SPA，用hybrid方式包成了iOS和Android的App，叫做“健康日记”（一个致力于帮助你养成健康规律生活习惯的App）。在Android下确实被碎片化折腾死了，但开发团队确实成本很低。感兴趣的同学可以下载试试。 关于微信小程序 今年一个很热闹的词就是微信小程序，从上半年张小龙宣布应用号在筹备，到下半年小程序SDK掀开神秘面纱，小程序着实牵动了很多人的心。 很多人稀里糊涂说微信小程序是H5技术，其实看完SDK我发现这跟HTML5没有半毛钱关系。微信小程序和之前百度、UC、QQ浏览器、Chrome Web Store、Firefox OS的Webapp完全不同。作为一个开放平台，不知道微信为什么放弃百度轻应用的思路，设计这么个SDK。坦白讲，这么设计SDK讨好不到任何人，Native开发的同学并不熟悉，而前端开发的同学也会觉得怪怪的很受限制。最重要的是，HTML5代码没法简单适配一下移植过来，还得重新开发一套。也就是说，这是一个伪HTML5的技术，开发的同学又多了一个平台要侍候。 我猜微信平台的同学可能会说，这是出于性能上的考虑。但我只能说，店大欺客，仗着用户量高，对开发者真不友好。做“健康日记”时，本来打算借应用号的东风的，希望在应用号发布上简单适配一下就上微信的，结果等了半年等来这么个SDK，一看程序完全没法移植，要完全重新开发一套出来，只好放弃了。 就仗着用户量，iPhone不也活活逼死了Flash吗，你牛。 关于前端的缺人和高薪水 我工作十年以来，前端圈前所未有如此盛世，技术圈也热闹，薪水也涨得飞快。但不得不说，技术圈的热闹和薪水涨得飞快并没有关系，仅仅是个巧合。 技术圈的热闹，原因在于跨界和伪全栈。薪水涨得飞快，原因在于HTML5的应用场景变多了，和技术没有关系。 说说HTML5现在的应用场景吧： PC端浏览器 移动端浏览器 超级App的Hybrid 微信公众号这种App开放平台 微信朋友圈微博的营销页面 百度轻应用（很小众） 后台（部分公司） 微信小程序（姑且也算） 特别需要注意的是“超级App的hybrid”、“微信公众号”和“微信朋友圈微博营销”这三点，在移动互联网之初的2011、2012年，C/S结构的App是主流，Web已死是主基调，这两年前端的日子不算好过。然后随着淘宝、京东这种超级App越来越多，C/S结构更新麻烦，特别是iOS还需要在App Store审核的问题越来越放大，超级App不得不选择Hybrid的方式来进行发布和团队合作。而随着App也提供开放平台，Hybrid是唯一的选择（直到微信小程序打破它），前端的需求量突然大增，供不应求，于是前端长久以来一直被严重低估的局面终于得以扭转，薪水一路水涨船高。这种局面其实在2011、2012年的Android和iOS圈里也发生过，然后培训机构大量提供Android和iOS培训，再然后供求关系得以平衡，Native工程师的薪水恢复到了正常情况。有需求就会有供给，值得注意的是现在培训机制也在开展HTML5培训了，等到HTML5工程师被培训机制批量提供出来，前端的好日子也就到头了。 到那时，风就停了，猪就会摔下来。所以不要稀里糊涂地被技术圈的大跃进冲昏了头脑，你学会了两个时髦工具，面试官也在面试时问到了你时髦工具，然后你也顺利到了很高的薪水，就真以为是工具帮了你，你的能力真的就高了。不是的，是时代的原因。那个坐你旁边工作了好几年的一声不吭的老Java工程师薪水没你这个小毛头高，并不是人家水平没你好，并不是人家工作技术含量低，并不是人家比你笨，仅仅是因为做Java开发的太多了，市场饱和度高，仅此而已。所以偷着乐就可以了，然后赶紧补基本功。 写在最后 我曾经写过一篇文章，叫“置疑精神”。所以也请读者带着置疑精神来看我的这篇文章，认为有道理的，就听，认为不对的，保留你的疑问，不要迷信任何权威，这是技术人该有的美德。虽然我写了这么多，但也有可能，全是错的。
-
发表了文章 2022-02-12
学会MATLAB到底能做什么？
MATLAB是Mathworks公司于1984年推出的一套高性能的数值计算的可视化软件，它集数值分析、矩阵运算、信号处理和图形显示于一体，可方便地应用于数学计算、算法开发、数据采集、系统建模和仿真、数据分析和可视化、科学和工程绘图、应用软件开发等方面。MATLAB之所以能够被广泛应用，是因为它将科研工作者从乏味的Fortran、C编程中解放出来，使他们真正把精力放在科研和设计的核心问题上，从而大大提高了工作效率。在MATLAB环境中描述问题及编制求解问题的程序时，用户可以按照符合人们的科学思维方式和数学表达习惯的语言形式来书写程序。 MATLAB这个词代表“矩阵实验室”（matrix laboratory），它是以著名的线性代数软件包LINPACK和特征值计算软件包EISPACK中的子程序为基础，发展而成的一种开放型程序设计语言。在它的发展过程中，许多优秀的工程师为它的完善做出了卓越的贡献，使其从一个简单的矩阵分析软件逐渐发展成为一个具有极高通用性的、带有众多实用工具的运算操作平台。工具箱是MATLAB函数的子程序库，每一个工具箱都是为某一类学科专业和应用而定制的，主要包括信号处理、控制系统、神经网络、图像处理、模糊逻辑、小波分析和系统仿真等方面的应用。借助于这些现有的工具，科研人员可以直观、方便地进行分析、计算及设计工作，从而大大节省了时间。 MATLAB是一种高效的工程计算语言，它将计算、可视化和编程等功能集于一个易于使用的环境。在MATLAB环境中描述问题及编制求解问题的程序时，用户可以按照符合人们科学思维的方式和数学表达习惯的语言形式来书写程序。其典型应用主要包括以下几个方面： 数学计算；算法开发；数据采集；系统建模和仿真；数据分析和可视化；科学和工程绘图；应用软件开发（包括用户界面）。 MATLAB是一个交互式系统（写程序与执行命令同步），其基本的数据元素是没有维数限制的阵列。这使得用户可以解决许多工程技术上的问题，特别是那些包含了减肥矩阵和向量的公式的计算。采用MATLAB编制解决上述函授问题的程序比采用只支持标量和非交互式的编程语言（如C语言和Fortan语言）更加方便。 20世纪80年代初期，Cleve Moler和John Little采用C语言改写了MATLAB的内核，不久他们便成立了Mathworks软件开发公司，并将MATLAB正式推向市场。历经十几年的发展和竞争，MATLAB成为国际认可的最优化的科技应用软件。在大学里，它是用于初等和高等数学、自然科学和工程学的标准教学工具；在工业界，它是一个高效的研究、开发和分析的工具。随着科技的发展，许多优秀的工程师不断地对MATLAB进行了完善，使其从一个简单的矩阵分析软件逐渐发展成为一个具有极高通用性，并带有众多实用工具的运算操作平台。 MATLAB的一个重要特色就是它有一套程序扩展系统和一组称之为工具箱（toolboxes）的特殊应用子程序。工具箱是MATLAB函数的子程序库，每一个工具箱都是为某一类学科专业和应用而定制的，主要包括信号处理、控制系统、神经网络、模糊逻辑、小波分析和系统仿真等方面的应用。 MATLAB系统由以下5个主要部分组成，下面具体进行介绍。 开发环境：由一系列工具组成。这些工具方便用户使用MATLAB的函数和文件，其中许多工具采用的是图形用户界面。包括MATLAB桌面和命令窗口、历史命令窗口、编辑器和调试器、路径搜索和用于浏览帮助、工作空间、文件的浏览器。MATLAB数学函数库：这是一个包含大量计算算法的集合，这些函数包括从最简单最基本的函数（如加、正弦等）到诸如矩阵的特征向量、快速傅立叶变换等较复杂的函数。MATLAB语言：这是一个高级的矩阵/阵列语言，它包含控制语句、函数、数据结构、输入输出和面向对象的编程特点。用户可以在命令窗口中将输入语句与执行命令同步，也可以先编写好一个较大的复杂的应用程序（M文件）后再一起运行。图形处理：用MATLAB可以将向量和矩阵用图形表现出来，并且可以对图形进行标注和打印。高层次的作图包括二维和三维数据可视化、图像处理、动画和表达式作图，低层次的作图包括定制图形的显示和为用户的MATLAB应用程序建立的图形用户界面。MATLAB应用程序接口（API）：这是一个库，它允许用户编写可以和MATLAB进行交互的C或Fortran语言程序。 MATLAB软件从1984年推出的第1个版本到目前发布的第14个版本MATLAB 7.0（Release14），有了较大的改进和增补，增加了许多新功能和更为有效的处理方法。 新的用户界面环境和开发环境，使用户更方便地控制多个文件和图形窗口，用户可以按照自己的习惯来定制桌面环境，还可以为常用的命令定义快捷键；功能更强的数组编辑器和工作空间浏览器，用户可更方便地浏览、编辑和图形化变量；提供的M-Lint代码分析器，可以方便用户修改代码以取得更好的性能和可维护性；更强大的编辑器，用户可以选择执行M文件中的部分内容等。支持函数嵌套、有条件中断点；可以用匿名函数来定义单行函数等。整数算法，方便用户处理更大的整数；单精度算法、线性代数、FFT和滤波，方便用户处理更大的单精度数据；Linsolve函数，用户可以通过定义系数矩阵更快地求解线性系统；ODE求解泛函数，操作隐式差分等式和求解多点式边界值问题。新的绘图界面窗口，用户可以不必通过输入M函数代码而直接在绘图界面窗口中交互式地创建并编辑图形；用户可以直接从图形窗口中生成M代码文件，使得用户可以多次重复地执行用户自定义的作图；更强大的图形标注和处理功能，包括对象对齐、连接注释和数据点的箭头等；数据探测工具，用户可以在图形窗口中方便地查询图形上某一点的坐标值；功能更强大的图形句柄等。面板和分组按钮使得用户可以对用户界面的控件进行分组；用户可以直接在GUIDE中访问ActiveX控件。新的文件I/O函数支持用户可以读更大的文本文件，并且可以向Excel和HDF5文件中写入内容；支持压缩格式的MAT文件，使得用户可以使用较少的磁盘空间保存大量的数据，而且速度更快；可以使用Javaaddpath函数来动态添加、删除或重载Java类，而不必重启MATLAB 7.0；支持COM用户接口、服务器事件和Visual Basic脚本；可以基于简单的对象访问协议（SOAP）来访问网页服务器；提供FTP对象用于连接FTP服务器，实现对异地文件的处理；支持Unicode国际字符集标准，使得MAT文件中的字符数据可以在不同语言之间共享。
-
发表了文章 2022-02-12
90 后开源老司机徐亮：从大学开始全职做开源是一种怎样的体验？
“如果你有正确的态度，有趣的事情自然会找到你。” Eric S. Raymond 在被奉为“开源运动独立宣言”的《大教堂与集市》一文中，总结了 19 条在开源开发中非常有用的理论，上面是其中一条。开源项目总会在不经意间升级，参与者可能最初只是做一些小打小闹的贡献，后来逐步维护越来越重要、越来越多的代码，甚至是负责整个程序。在一个鼓励代码共享的软件文化中，这是一种很自然的项目演化方式。 徐亮在开源社区的经历也遵循着同样的演化路径。从一开始因为兴趣入圈、负责翻译工作，到后来成为Ubuntu、Debian资深官方开放人员，甚至把开源变成一份全职工作，今年已经是徐亮与开源结缘的第 12 个年头。 徐亮，摄于河北丰宁坝上草原 作为一名进入开源圈子已超过 10 年，有丰富开源社区经验的“90 后”，徐亮接触开源的契机来自他对于计算机的浓厚兴趣。用徐亮自己的话说，“左玩玩右玩玩，比较偶然地遇到了 Linux 操作系统，然后就走上不归路了。” 徐亮读初中的时候，每个班级的教室里都会有一台装了 Windows XP 系统的中控电脑，主要用来给老师上课播放 PPT，当时徐亮和几个朋友的一大乐趣就是折腾这台电脑。后来大家觉得 XP 系统太无聊，开始到处寻找新玩具。徐亮“斥巨资”在电脑城买了一套经典的 Red Hat Linux 9（Shrike）光盘，一共六张 CD，其中 3 张都是源代码盘，而源代码盘其实一般都用不上，卖家只是很忠实地把官网提供的东西都刻出来了。一直到现在，徐亮都觉得这事“很坑”，因为“浪费了非常多零花钱”。 换着玩了几个不同的 Linux 发行版之后，徐亮开始重点折腾 Ubuntu。在玩的过程中，徐亮发现操作系统的汉化非常不完整，就顺着源代码中留下的译者联系方式接触到了当时国内负责 Ubuntu 操作系统翻译的小圈子，并在侯正鹏的引荐下加入 Ubuntu 社区，从软件翻译开始实际参与到开源社区工作中。 那时候还是 2009 年左右，在国内搞开源社区的人只是一个不大的圈子，搞翻译的人更少。很多“老人”已经背着翻译的职责好多年，彼时刚刚入圈、还是个高中生的徐亮于是成了“继任者”。他慢慢接手了翻译的职责，并在 2012 年左右成为了国内好几个大项目唯一的翻译负责人，直到今年他才找到可以接替自己的人。 在扛起 Ubuntu 简体中文翻译大旗的同时，徐亮也更深入地参与到了各种社区活动中。当时 Ubuntu 的商业发行公司Canonical每年都会在国外组织开发者大会，并邀请 Ubuntu 社区里比较活跃的社区用户代表参加。徐亮也得到了一次参加开发者大会的机会，借此接触到了 Ubuntu 社区开发人员，并从打包工作开始逐步做一些开发相关的工作。 2011 年，徐亮正式成为 Debian 的开发人员，两年后，他又申请成为 Ubuntu 的核心开发人员，并得到了进入 Canonical 公司工作的机会。 Ubuntu wiki 上徐亮个人介绍页面中的推荐人感言，第二位和第三位推荐人分别是侯正鹏和李道兵，他们也是国内操作系统开源社区的早期参与者。 Ubuntu 有几个官方特色版本，优麒麟（Ubuntu Kylin）是其中之一。 2013 年，中国工信部软件与集成电路促进中心、中国国防科技大学与 Ubuntu 的商业发行公司 Canonical 在北京联合创立“CCN 开源软件创新联合实验室”，优麒麟正式创立，第一个版本随 Ubuntu 13.04 同时推出。这是一个针对中国市场特色的基于 Ubuntu 的操作系统，也是 Ubuntu 的官方中国版本，专注服务中国市场。优麒麟不仅实现了语言本地化，还在 Ubuntu 原版基础上增加了众多中国特色应用，如原创的 UKUI 界面、内置中文输入法、集成 WPS、网银支付等。 同样在 2013 年，那时还在上大二的徐亮正式加入 Canonical 公司全职做 Ubuntu 主线版本研发，主要负责输入法、network-manager 和 ZFS 三块。他既是优麒麟开源项目的核心开发者，也是搜狗输入法 Linux 版的主要开发者。 在 Canonical 的工作一直持续到 2017 年 5 月，之后徐亮短暂尝试了一段时间的创业。2019 年，在与华为持续沟通 9 个月之后，徐亮加入了华为开源能力中心。 据介绍，华为开源能力中心是一个公司级别的开源能力部门，主要负责公司内部开源管理、内源开发、整体开源知识体系架构的构建等，同时也为产品线提供包括运营能力和技术能力的支持。如果说业务线做的是 N，那么开源能力中心负责的就是 N+1、N+2 的部分，比如承担业务线尚不具备的能力建设，包括整体的开源合规体系管理等。 那么，跟有自己的本职工作、用业余时间做开源相比，全职做开源的好处是什么？在徐亮看来，全职做开源会让自己有更多的时间和精力思考开源这件事情、在社区里做出更多贡献，同时公司也会提供更好的资源和平台；兼职做开源则主要凭兴趣爱好，可能投入的时间精力以及能动用的文凭资源相对来说比较有限。但徐亮认为全职做开源不一定适合所有人，当兴趣变成职业，到底是好事还是坏事，结果本身也因人而异。此外，全职做开源也有不是那么好的一面，有时候可能会错失一些接触更先进的技术的机会。“虽然开源是一个很好的协作模式，但不代表每时每刻开源的东西都是最好的、最先进的。” 徐亮表示，如今开发者想要把做开源变成全职工作的难度相比以往已经小了很多，但仍然不是每个人都可以做到，毕竟开源开发不管在国内还是国外所占的比例都非常有限，目前在大公司做开源可能相对比较容易一些。 除了需要公司提供相应的岗位之外，全职做开源对于开发者个人的学习能力、沟通交流能力也提出了更高的要求。因为需要沟通的人不再只是身边的同事，要学习的东西也不再局限于在公司里做的项目。与此同时，由于代码开放、人人皆可参与，随时可能会出现一些意外情况，比如突然有一个技术很牛的人看不惯来“砸场子”，这类事情在开源圈里已经发生过无数次，徐亮自己早期也经历过类似情况。虽然很多时候这种踢馆并非出自恶意，但依然会给被踢馆的一方带来极大的压力，如何跟进沟通和处理，对个人的挑战非常大。 当下，开源在国内可以说是前所未有的热度空前。不仅很多企业大力投入，连高校学生在找工作的时候也会拿自己的 GitHub Profile 去展示自己参与过哪些开源项目、写过什么代码。越来越多企业和个人重视开源、参与开源，对开源在中国的发展肯定是件好事，但同时也有人担心，很多企业和个人抱着“开源为我所用”的目的参与进来，会导致开源这件事掺杂过多功利心。 在徐亮看来，不管是抱着什么样的初衷和目的参与开源，最终还是要回归开放代码、协作分享的本质。“有人的地方就有江湖，一直以来国外的开源圈子很大程度上也是公司之间的一个商战场所，现在开源在中国的发展并没有违背这一点。所以并不是说开源本来不是这样、现在变成了这样，只是以前在中国大家还没有参与进来而已。” 徐亮认为，开源一派火热背后的隐忧在于，当前国内参与开源的人很多，但不同事情投入的精力分配并不完全合理。比如，做开源运营和治理的与真正做开源技术的人数比例就有些失衡。 其实国外已经有很多开源社区和组织的经验可以借鉴，因此制定开源准则等治理工作并不需要太多人。只不过现实情况是，国内可能基于对形势的合理考虑，什么都希望有自己的一套，包括自己的许可证、自己的社区、自己的社区行为准则、自己的治理架构等等，过程中会涉及消化吸收其他开源社区的经验，就导致这变成了一件高度专业化的事情。从这个角度来看确实缺少一些能够很好地理解和解读现有社区做法的人。 但是从开源本身来讲，更重要也更需要的是真正参与项目开发和贡献的人，包括开发、测试等等。可能再过几年，中国开发者整体水平更高了，大家不再需要那么多条条框框去约束，类似“自建一套社区治理架构和流程”的需求就会减弱。基于徐亮参与 Ubuntu/Debian 社区的经验，很多时候一个几千万行代码的开源项目并不需要一套特别形式化的治理体系，也能够运作得很好（甚至反而运行得更好），如果在社区参与者还不够丰富的时候就先建立起一套治理体系，反而可能会产生一些掣肘。 此外，过去几年国内一些头部企业的开源工作屡屡引发争议，比如被批“刷 KPI”、“PPT 开源”等等，徐亮认为这也是因为大家太重运营。确实，开源有帮助企业构筑生态、打造影响力、建立事实标准的能力，但要“徐徐图之”。如果论坛运营走在前面，就会出现“发声在前、贡献在后”，或者不贡献，或者贡献得一团糟；同时也会导致企业内部出现不好的导向，可能今天公司说要做开源、在行业构建影响力，然后一下子所有人都在搞开源，各种 KPI 就出来了。 当然，这背后也有社会环境和氛围的因素。中国加入世贸后这十来年一直处于经济高速增长的阶段，导致大家更愿意赚快钱，当下国内软件行业整体也会比较浮躁，企业对开源的规划更倾向在短期的一两年内见效，而不是慢慢做十年二十年。但徐亮认为，浮躁不会一直持续，中国的增长速度总归会慢慢回落，未来整个软件行业（包括开源在内）都会慢慢趋于理性，变得正常化。 “当所有人都重运营，争相去抢事实标准的名头，可能中间花了几年时间和很多的钱，最后大部分人都没尝到甜头，因为事实标准就那么几个。这就会倒逼他们去反思这件事这么做到底对不对。国内软件开发的积累与国外还有差距，如果不依赖开源可能技术要倒退十年。所以企业还是不得不参与到开源里面来，但未来可能会更理性地参与。对自己有价值就参与，代码不想永远自己本地维护同时又不影响核心竞争力的就回馈给社区，这就是一个很正常的开源使用管理和贡献的方式，不是所有事情都一定要搞得轰轰烈烈。” 很多时候在开始做一件事之前，并不需要多么坚定的信念或崇高的动机，只要怀抱一点好奇心开始去做，事情自然会在做的过程中变得越来越重要。徐亮参与开源的经历也是如此：因为好奇心驱使而开始，又因为认可开源理念和开放共享的文化走到现在，更多是一个“顺其自然”的过程。 好奇心同样影响了徐亮在开源和职业道路上的一些选择。他决定加入华为有一部分原因是因为想要看看在这种全球国际关系动荡的时候，华为内部会发生哪些变化、怎么去做开源；而加入开放原子开源基金会则有一个重要原因是想要置身其中去看看国内第一个开源基金会怎么运转，如果它成功了，它的收获是什么，过程中得到的教训又是什么。 开源作为一种高效的人与人之间协作的方式，主要解决了两种问题，第一种是对于一些“重复造轮子”成本极高的大型项目，比如 Linux 内核开发，任何公司都无法负担得起重做一次的成本，因此企业和个人就会选择以开放协作的方式一起完成这项工作，减少了社会成本的浪费；另一种也是开源本身所体现的协作共享精神，很多人可能不觉得这件事我做了很大的贡献，只是觉得这个东西做完了可能会对别人有用就把这个东西开放出来了。从这两方面来看，开源对个人、企业乃至整个社会来讲都有很大的价值。因此，徐亮希望能够借助现在所处的平台和个人能力，把开源这件事请做得更好，让开源产生更大的价值。 在他看来这并不是什么高大上的目标，只是做开源的技术人的一个朴实的愿望。 采访嘉宾介绍： 徐亮（Aron Xu），Ubuntu、Debian 资深官方开发人员，搜狗输入法 Linux 版主要开发者。开放原子开源基金会 TOC 成员，现任华为开源能力中心技术专家。 新的一波开源浪潮正在席卷中国，InfoQ 希望通过系列访谈深入了解国内外开源发展现状，总结国内外企业以及个人在开源方面的成功经验以及失败教训。
-
发表了文章 2022-02-12
十年重生，Linux QQ 全新回归
腾讯发布 Linux QQ 2.0.0 Beta 版，官方宣称： Linux QQ 全新回归 有网友认为，这大概是为了庆祝程序员节，因此腾讯推出 QQ for Linux。众所周知，作为开源操作系统，Linux 在全世界的程序员中”粉丝众多“，以这种形式致敬 1024，想来也说得过去。 QQ Linux 2.0，腾讯官方定义为“从心出发，趣无止境”。 在版本特性上，QQ Linux 2.0 有三点改变： 支持 x64、ARM64、MIPS 三种架构；优化消息体验，完善消息收发能力；性能优化 根据官方解释， Linux QQ 目前支持 x64（x86_64、amd64）、arm64（aarch64）、mips64（mips64el）三种架构，每种架构支持 Debian 系、红帽系、Arch Linux 系、其它发行版中的一种或几种（未来可能继续扩充）。 在 V2EX 论坛上，有一条“QQ For Linux 我哭了，官方版”的帖子在 6 小时内获得近 8000 次点击。 于是乎，很多网友第一时间下载安装，在登录界面，有网友称是“梦回 2008 年”，也有网友非常赞这个复古的登录风格。 一名 yylzcom 的网友发表了自己的看法，总结了槽点和优点以及前景： 槽点： 只能用扫码登录、09 年的界面，非常简陋，有高手解析发现用的是 09 版本的资源包依赖于 GTK2、估计这是修复了登录 API 之类的、图标闪动点击弹不出来对话框，只在屏幕最上面有一条、聊天列表里又看不到是哪个群 优点： 原生的确实比 wine 的好，比较顺畅（不知道是不是用的 09 年的超简洁代码，所以顺畅） 目前来说，整体体验比 Deepin-Wine 里的 TIM 差很远，果断卸载。 前景： 不乐观，Linux 桌面用户体量实在太小； 上个 Linux QQ 版本“死得多惨”，相信 Linux 桌面用户都有体会； 关键在于腾讯自己不做，也不开放权限给别人做。 如果细心的网友肯定会发现，本次发布的是 QQ Linux 2.0。这意味着之前出过 QQ Linux 1.0。 实际上，腾讯十年前也做过 QQ Linux，大概是 08 年和 09 年，当时的版本应该是 1.0。 在知乎上一个关于“腾讯当初为何开发 qq for linux？的问题中，有一个名为吴章金 falcon 的网友解释道， 首先，当时 Linux 在国内推广势头比较猛，特别是 Ubuntu 的乐器架势很猛，免费分发光盘，所以估计腾讯不想丢掉这部分潜在的增长市场。其次，随着 Linux 用户的增多，从 Windows XP 转到 Linux 的用户确实需要可用的 QQ，所以 Linux 的社区呼声也很高。另外，当时，飞信也有开源版本的支持，比如 libfetion。这个作为新生事物，腾讯可能也有顾虑。类似的，MSN、Skype 等在开源社区也风生水起，腾讯可能担心自己会彻底失去 Linux 这个市场的用户。 当时，Linux 的 QQ 版本最早用上了标签式聊天窗口，而且无任何广告和弹窗，非常的干净。 “如果能坚持做下去，腾讯在用户的口碑上肯定能上一大截。”知乎网友 Antokha Yuuki 说。 不过，后来 Linux QQ 就停止更新，逐渐销声匿迹，连官网也死了。 如果我们再深入一步，就涉及到“腾讯为什么不开发 LINUX 下的 QQ?”这个问题。 在腾讯这样的大公司，Linux QQ 肯定属于一个小众产品。 fullsail 的知乎网友总结了一下，小众产品为啥在大公司搞不好的原因。 第一，一个产品的小众版本维护更迭是耗费时间精力的事情。表面看，一个版本 OK 了。但其实远远不是，虽然维护可能人力不多，但总是要不停的游戏维护，因为周边也在变化。Linux 版本在升级，而且 Linux 版本还众多。而且一旦增加一个分支，对其他系统也是扰动。 第二，小兵不愿干。维护人力不大，但这个事情交给什么人做就是第二个问题了。这种活，并不简单（代码量不小，修 bug 并不轻松），但高手往往不愿维护。因为人少，产出少。没有绩效产出，就没有升职加薪。而且人类是群居动物，大部分人不愿窝在小团队。小兵不愿意干，就招不到人，人员流失大。没有人就反应慢，维护难。 第三，领导看着烦。大公司的 KPI 文化下。这种产品没法定 KPI，你让它增长 1% 都难，那留着何用。 这位网友最后说，“这个问题不光腾讯，谷歌、微软、百度、网易、阿里都一样。如何在一个大公司里维护一堆小而美的东西，这是一个难题。” 实际上，这个问题有点像大公司做开源。开源的东西，免费，无法直接为公司创造利润，但是还需要花时间、精力去维护。这很难！ 至于 QQ Linux 2.0，有人欢迎，有人不喜欢。 用一位网友的话说， 下一个，微信 For Linux？
-
发表了文章 2022-02-12
专访香港科技大学教授杨强：国内的人工智能研究不能太跟风
杨强，香港科技大学计算机科学与工程学系系主任，人工智能领域学术界的领军人物，华人界唯一的国际人工智能协会 (AAAI)councilor，IEEE 大数据期刊主编，ACM 杰出科学家。两次获得国际数据挖掘领域最高级别竞赛 KDD Cup 世界冠军。杨强教授发表论文 400 多篇，被引用超过 20000 次。 但同时，除了扎根科研界，杨强教授还是人工智能领域深入商业应用领域的顶级专家之一。目前，杨强教授担任人工智能技术与服务提供商第四范式的首席科学家，带领这家被广泛看好的人工智能公司不断取得科技突破，近期第四范式在乌镇世界互联网大会上发布了可供大部分互联网公司使用的人工智能公有云产品，也是基于杨强教授与团队「AI for everyone」的共同价值观。日前，极客公园对杨强教授进行了专访。其中，杨强教授不仅向我们介绍了第四范式这家公司的研发方向，还就人工智能领域的很多动向及发展状况做了解答，其中颇有很多值得琢磨的地方。 同时，杨强教授本周也出席了腾讯网媒体高峰论坛，他在现场也就人工智能和媒体行业的关系与发展发表了精彩的演讲。我们将他的演讲实录附在文后，希望能对你有所裨益。 采访实录： 问：作为「迁移学习」这个领域的专家，您觉得它对人工智能产业的影响和作用是什么？能给我们举两个例子吗？ 杨强：首先，现在人工智能过多依赖大数据，这是很危险的。危险来自几个方面，首先收集大数据需要很多时间资源，有了数据以后还得去处理数据，之后机器才能学习，在这个处理过程中需要有人参与，而凡是有人工干预的，要求就特别高。迁移学习的思想是，通过发现大数据的模型和小数据问题之间的关联，然后把模型迁移过去，这样一来如果在大数据领域先得到了机器学习模型，在研究下一个相关领域时，只用一部分数据或者小数据就可以完成。利用迁移学习这一特征，我们就不用花大力气去收集资源了，这对人工智能的发展非常关键。比方说新开一个网店卖一种新的糕点，因为没有任何的数据与模型，我们没有办法对用户进行推荐，此外，当我们看到用户购买一种糕点后，也无法预测用户还会买其它哪种糕点；但如果我们知道用户在另外一个领域已经有了很多的数据，例如是用户购买饮品的历史数据，那么利用这些数据建立模型后，根据用户饮品习惯和糕点习惯间的关联性，我们就可以把饮料的推荐模型给成功迁移到糕点领域，成功的推荐给每个用户他们喜欢的糕点。 其次，人的思维是在一个形象的符号空间的思维，而不是深度学习那样的特别细粒度的机器学习思维。符号空间的思维能够归纳、抽象知识，并且在不同领域做关联和联想，能够很自然地进行迁移学习，这是人的思维特点；如果想要机器做到这一点，同样也要做到归纳和迁移，这就是迁移学习的基础理论。此外，还要从大量数据升华到符号空间的逻辑，再通过迁移学习技术做类比，真正做到举一反三，并可以基于此去预测、概述未来发生的事情。迁移学习是人工智能的下一发展阶段——机器不再是就事论事，而是拥有了像人一样的举一反三的能力。 问：有评论认为「作为人工智能实现的核心，算法将成为未来国内人工智能行业最大的竞争门槛。」你觉得就国内的情况来说，算法方面的发展情况怎么样？ 杨强：国内的算法现在和国外的差距不大。因为大家已经可以获得大量标注数据，深度学习在语言和图像方面取得很大成功。但除了语音和图像，其他领域公共的数据其实非常有限，所以更商业方面的研究只集中在几个公司，电商数据集中在 BAT，银行业务数据集中在金融机构，在这样较为封闭的环境中，发展就会受到一定影响。 另外，国内机器学习方面的创新还没有国外多，开放的系统也没有国外多。在国内，我们有必要鼓励开放数据、开源系统。第四范式刚刚发布的「先知公有云版」就是面向互联网企业，可部署在公有云上的机器学习平台。它打破了数据、人才和技术的壁垒，让各个阶段的互联网企业都能掌握并受益于人工智能。 问：人工智能的应用在由专业领域向通用领域过渡的过程中，哪些是最需要解决的困难？未来多久我们才能迎来在这方面的突破？ 杨强：在通用领域我们已经取得了一些突破，比如亚马逊出了一款叫 Echo 的硬件，可以满足人们在某些场景下的需求，比如在家庭场景，可以让它帮助放音乐，问它今天的新闻是什么，这个产品已经有几百万的用户。Echo 成功的原因是它找到了一个特别好的场景，在家庭中，大家有获取知识和音乐的需求，抓住需求后就把家庭这个场景运用起来了。这种人工智能的做法就是从一个或几个垂直领域的成功，往外扩展，再把它们连成一片。我认为以后类似场景很多，比如工作、开车、出行、教育等。下一个人工智能的突破，应该是在几个场景下有限的通用性，而不是没有限制的通用性，可能先达到的就是这样一个阶段。 问：人工智能如果想进入更高级的水平，您觉得下一个要做的工作是什么？比如说我们人类比较重要的是处理一些隐性的知识，还有情感的问题，下一步人工智能在这个方面会不会有更多的提高？ 杨强：情感问题也可以按理性的方式来处理，我们可以去检测处理的效果是否符合人的情感。但其实情感问题并不是机器学习目前的首要问题，首要问题是建立一个通用的机器学习系统。现阶段还没有出现非常强的通用系统，主要原因是现阶段机器学习的成功主要集中在大数据上面，我们知道，大数据比较多的地方是比较垂直的领域，这些领域的特点是范围比较窄，远远没有达到通用性。所以机器学习包括情感计算的瓶颈是，我们如何能把通用领域里用户在系统里的交互行为用数字化的形式留下来。这个瓶颈的解决办法需要传感器网络或者物联网的普及，带来更多的数据的流通。 问：您觉得目前国内人工智能领域的发展情况如何？最大的不足是什么？您对国内人工智能科研人员及创业公司有哪些建议？ 杨强：国内目前人工智能发展还是相当乐观的，很多大学都在研究人工智能。但与国外相比，国内的不足之处也比较明显，国内过多去做机器学习，而忽略了人工智能的其他领域，比如逻辑推理、智能规划、机器学习的可解释性和多智能体等前沿领域。 如果是对人工智能科研人员的建议，我觉得国内的人工智能研究不能太跟风，要对自己的研究领域有信心、不断创新，尤其是在大学的研究者，每个大学的教授应该是独树一帜的，自己领先一个子领域，而不是跟着别人去做。其实在科研和工业界都是需要持续创新力的，不过对公司而言，还是要首先考虑生存，也不要以为人工智能可以包罗万象。 问：您目前担任人工智能初创企业第四范式的首席科学家，作为一家人工智能技术提供商，你们提到自己是「全球第一个商用人工智能系统的架构、中国最大的人工智能系统研发和运营」。同时，你们也称自己的产品「先知」也是人工智能领域第一个平台级产品。如何理解「平台级产品」这个概念？ 杨强：以前基于云端的机器学习在大众化的应用不多，机器学习大部分都是单机的，缺点是需要客户把大批数据上传，这对于客户来说是一个隐私流失，是很多客户所不希望看到的。为了避免数据流失，一些有条件的客户会做本地的数据中心，这需要非常大的投入，包括资源、资金和人力的投入。但很多客户、尤其是互联网公司，他们真正关心的其实不是建立这样的 IT 小组或者数据中心，而是怎么利用人工智能来提升自己的业务。那么如何帮助他们解决数据上传问题、满足机器学习在业务方面的需求呢？「部署即可用」的平台级产品就变得非常重要。在云上就可以快速完成从问题定义、数据接入、特征工程直至上线应用的整个机器学习流程。第四范式的先知公有云版就是这样一个平台，利用先知公有云版企业不需要再重建机器学习团队，现有团队一个月内就能搭建出自己适用的 AI 系统。这极大降低了机器学习的门槛，同时能使得大家把精力放在自己的业务上。 问：现在有说法说「国内的人工智能产业链将更为明显地分化为以 BAT 为代表的生态平台、以科大讯飞和格灵深瞳为代表的垂直技术解决平台等。」您怎么看人工智能公司的几种不同类型的路线选择？第四范式目前正在走哪种路线？ 杨强：第四范式走了第三条路。第四范式不像 BAT 或者电商那么宽泛，要打造自己的生态；同时也没有只追求纵向的专业领域突破，而忽略了横向的业务延展。第四范式在一个垂直领域扎得很深，了解这个领域的痛点和背景，然后基于实战经验与案例来提供一个领域内的通用平台，同时这个平台又在该领域做得比较成功，提供的算法都是特别适用于领域里的。比如大规模的自动特征工程就是一个例子，用很少的人工就可以自动获取大量特征，然后就自动进行机器学习，最终实现人工智能在个性化推荐、精准营销等业务场景中的应用。所以可能用第三个路径来描述第四范式可能更恰当。 问：怎么看目前人工智能技术在 C 端的应用情况，比如智能家居？ 杨强：智能家居一直以来都是大家关心的题目，工业界诸如小米、联想等企业都试图在这个领域有所突破。我觉得技术上应该问题不大，但还没有抓住很好的场景。好场景的要求是，可以提供高质量的数据，数据要持续不断地更新，而且场景要一直向客户提供反馈，总的来说就是不断地提供数据和数据反馈标注。所以，如果能够找到一个好的场景，有这样的数据，更大的突破应该是早晚的事。但除非找到这样的场景，否则只能做一个好的框架，没有数据和服务，智能家居很难取得重大突破。 问：您个人这两年在国内参加了很多人工智能方面的创业项目，相比纯粹的科研工作，您会觉得参与企业的创业对这个行业更有帮助吗？ 杨强：我觉得这两者一定要结合起来，实验室的工作和接触大规模的工业问题是不可分割的。在实验室工作、参加学术会议或者拜访一些其它的实验室，可以关注整个业界的发展；在工业界，可以解除人工智能在应用上所产生的很多实际问题。现在这个时代离不开数据，在人工智能领域，实验室和工业的结合是双向有益的。 杨强教授本周在 2016 腾讯网媒体高峰论坛现场的演讲速记 大家好！今天我很高兴能够跟大家分享一下我的一些看法，尤其是人工智能的到来和媒体会怎么发展的技术路径。 今年 AlphaGo 是一个大事件，我们现在要问，AlphaGo 为我们带来了什么？从技术和商业上、从未来的发展方向上，能不能从 AlphaGo 的发展看出一些端倪？ 首先我们看到在过去人工智能的发展经历了几次大事件。首先是 IBM 深蓝、沃森为我们带来了很大的惊喜，告诉我们计算能力真的是很重要。有了这种计算能力，我们就能够比人搜索的要深，比你回答的要快，能够回答一些尝试性的任务。 但是 AlphaGo 又加了一条，告诉我们原来数据也很重要。不仅如此，高质量的富贵数据更加重要。什么是高质量的数据呢？其实创造 AlphaGo 这个系统是需要几个条件的： 首先就是能够很清楚的认识到那些是我们的目标。这些目标要清楚到什么程度呢？要用数学公式写下来。 其次要清楚认识到数据来自于哪里。这不是一天就可以做好的，比如 AlphaGo 是经历了十几年的时间，才获得了如此高质量的大量的数据。 同时对问题的了解要深入到特征的层面，要从一个问题能够抽取出大量的特征。 最后是要有非常合适的自学习的方法来做这件事。 下面我们来看一下今天具体感兴趣的题目是 A.I. 能够为媒体带来什么，说起媒体就离不开文本和自然语言的分析，什么是文本呢？文本就是小说、新闻这些，我们可以把这些数据认为是非结构化的数据，是一个非常有意思的数据，不枯燥，但是对于机器来说却是一个难题，因为没有结构，是需要我们人去理解它才会有结构。 今天有一种技术叫机器阅读，阅读的成果是中间的理解、表达，这个表达叫做隐式表达。 这种表达通过第二种模型，也就是说我们所说的机器学习、自然语言的生产模型，能够为我们人产生出各种各样的我们所需要的数据。就好像我们旁边有一个助手在我们帮助进行了大量的阅读，然后根据我们每个人的需求可以跟他进行对话来获得他阅读的知识，所以是这样两个过程。一个是机器阅读系统，一个是自然语言的生成系统。 机器阅读有哪些应用呢？比方说在谷歌的邮件中就可以通过模型对大量邮件的阅读形成一个端到端、序列到序列的模型，这个模型通过阅读一个新的用户邮件，自动地产生一个可能的用户反馈，这样用户在给最后一个决策就可以很简洁地恢复邮件，这样就大大提高了用户的体验。 机器翻译就不用说了，这是非常有用。但是最近深度学习的发展，可以让机器能够自动地用算法学习到一种语言到另外一种语言，可以自动对应。这种对应在之前是很少的，但是用机器学习来做就大大增强了。它的效果是可以使注意力机制大大加强，什么叫注意力机制呢？就是在一句话里面哪些部分是关键部分，我们可以拿这些部分来代表整个话的意思，这样可以用聚焦的方式来加强理解。应用了这个以后，比分就大大提高了。 还有一个应用可以让计算机去做很多阅读，阅读的结果可以由我们人来询问。比方说让他看了一个语文的试卷、历史的故事，我们可以问一些关于历史人物、历史事件的问题，计算机可以圆满地做出回答。 还有一种就是我刚才说的注意力机制，可以帮助人描画出哪些文本的部分是我们阅读者应该去注意的，就好像我们学生在上课的时候经常会画一些需要关注的重点，这样我们考试的时候就会有的放矢。机器在今天已经会做到这一点了，这个叫做完形填空的回答。 这个再发展下去，又可以让机器大量地背唐诗，并且可以自己写诗。这里是香港科技大学的图片，图片有山有水，这个模型可以在唐诗里面选择最合适的唐诗来配这副画。同时利用生成式的模型，还可以自动地产生。比方说当输入对联上联的时候，就可以拿它作为输入，这样的生成模型可以自动产生下联，而且通过注意力的机制使上下联对仗非常公正，这在人看来都是一个智慧的象征，但是今天对于机器来说已经是非常简单了。 我说了这么多对智媒的进化预示着哪些呢？首先我对我的观点进行打分，5 分是最高，1 分是最低。我们看看刚才讲到的 5 个必要条件，分别是数据量、边界够不够清晰/问题定义得够不够清楚、外界的反馈够不够好、计算资源是不是足够、有没有跨界人才，以此来判断这个领域的爆发力的指数。 我们先看看在媒体方向上最关心的是能不能用 A.I. 来帮助新闻编辑室做一些人工智能的编辑，机器人的编辑助手来大大提高我们的编辑效率。在这一方面，应该说一个重要的方向是给了一个文章或文本能不能够自动写出一些摘要，给出一个文章，能不能自动地产生一个吸引用户的标题。在过去的做法，这个领域叫做摘要的编辑，摘要编辑过去的做法叫做抽取式的新闻写作。 这里有一个例子，就是在一个足球赛里面，通过对解说词的分析，用解说词来训练一个模型，最后这个模型可以在解说词当中抽取特征。另外是再把这些重要的特征所指出的句子给摘出来，再把他们拼接起来形成一个很短的摘要。这个事已经可以做了，在过去十年、二十年已经做得不错了。但是毕竟不像人一样去读一篇文章，再根据我们的理解重新写出一个摘要，或者是编出一个非常好题目。 如果要做到这一点，我们就需要一个所谓的生成式的模型，这个模型可以做什么呢？可以把每一句话读进来，并且可以对应到输出，这个输出往往是上文对下文的序列到序列的对应。这种对应还不足以产生我们所想要的高质量的摘要。在这个基础上，我们又在上面可以加一层强化学习或者增强学习，使得这样的摘要过程有目的性。也就是说两种学习，一种是序列的深度学习，另外一种是增强学习，这两种加在一起就可以产生基本上跟人差不多水平的一个摘要。比方说这里的一个例子，是对一个新闻的文章产生一句话的摘要。 我们来开一个脑洞，也可以让机器去读小说，比方说有《射雕英雄传》、《笑傲江湖》，可以把这两个小说给合并起来，怎么合并呢？利用模型来合并输出一个新的小说，这个小说是《笑傲英雄传》，这个事是怎么做的？可以用循环的神经网络（RNN）来产生各自的模型。阅读了以后，产生的模型通过迁移学习迁移到一个共同的空间，这个共同的空间就是得什么呢？生成的模型可以使得我们阅读小说。比如说洪七公和令狐冲这样的人物可以进行打斗，可以看得非常通顺。这个跟人的反馈、强化学习、增强学习的机制是分不开的，也是今天大数据的一种结果。 刚刚讲的是第一种新闻编辑和摘要的产生，第二种我认为有希望的方向是信源捕获。什么意思呢？我们可以在一个新的领域利用新的手段获得一些信号，并且把这些信号转变成我们要的新闻内容。在这里举几个例子，首先是假设我们有很多的文章，可以自动地把这些文章给产生成一些问题和答案的配对，也就是问题和答案的集合。这就像我们理解了一些过去某个政治人物或某个著名人物写过的文章或关于他的文章，以后自动产生一些想要问他的一些问题，这个过程是需要人去理解文章，然后产生一些高质量的问题。 今天我们可以用深度学习来做到这一点。这是怎么做到的呢？这是两种信息的结合，一种是知识库，也就是对整个领域的认识。另外一种就是文本。我们把这两种结合起来，就可以自动地生成一些挺不错、质量挺高的一些问题，就好像我们下面就可以去面对这位被访问的人物了。 这也可以延伸到从文字到图片，比如看了一个图片，现在也有一种方法可以利用计算机神经网络抽取出特征，用另外一个模型来产生问题。也就是说对着一个图片，可以产生对于这个图片的问题。这个问题也就变成了这个图片的一个标注，或者可以到外面去邀请别人来回答这样的问题。 假设今天有了很多的传感器，可以把传感器收集的数据、信号自动转变成人可以去读的文章，比方说我有一个学生很热爱骑马，它造了一个传感器可以放在马尾巴上去观察马的健康状况，同时可以把它翻译成人可以读懂的信号，以此来了解整个赛马的成长过程。 进一步就是想把传感器放在宠物的身上，在宠物的日常活动当中和人的交互当中，可以把宠物的行动变成人能读懂的自然语言，就好像宠物在跟你用说话的方式在交流一样。 我还有一个学生在用手机作为传感器来记录用户每一天的行为，到晚上的时候就自动把所有收集的手机信号转成一个自然语言的日记，把这个日记给这个人，可以修改一下，也可以发朋友圈。 还有一个方向是信源可视化的追踪，比方说我们有了很多社会网络，里面有很多的信息的传播、新闻的传播，通过可视化可以观察到这个传播的路径、地点和传播的方式，可以根据人群来细分。同样一个新闻内容，我们就可以对不同的人进行不同的服务。比方说小朋友得到的内容，可以和成年人得到的内容形式不一样，但是基本内容都是一样的。这样可以自动化个性去投放。 还有一个方向是视频和资讯的一种互动，这方面的数据量是庞大的，边界也足够清晰。但是一个重要的问题是跨界的人才特别少，我指的这个资讯和 A.I. 的互动到底是什么呢？比方说很多的视频，能不能有能力让计算机看这种视频，然后用文字的形式告诉我们，给我们一个文字的摘要。像这样的是我们的一个梦想，这样就可以自动地去检索很多的视频，自动地去搜索，可以找到我们想要的视频。 另外一些新闻视频也可以帮助编辑去找到他们人为的高质量的适合编辑内容的视频，这个事在大学的实验室里面已经有很多的尝试了。其中一个方法是把视频通过深度学习转化成特征，然后在通过这些特征再转化成文字。从视频到文字，甚至可以从文字到视频，你可以描述一个像电影的脚本一样，然后自动地一个通过拼接的方法产生一个可能的视频。这方面还有所欠缺，关键点是跨界的人才和用户的反馈还不够多。 大家关心的另外一个方向是智能分发，这个新闻怎么分发到想看这个新闻的用户的手里。在过去这个方向叫做推荐系统，在电商里面已经大量地使用。但是新闻有它的特点，因为新闻是靠内容来取胜，所以一定不能忽略信息的内容。比方说我们人看新闻，是因为我们好奇，对于新闻感兴趣，怎么样能够把好奇的人和好奇的内容给结合起来，怎么能把桥梁给建立起来。比方说一个用户带历史上经常读一些财经的文章，现在又比较关注美国大选，能不能以此来推断他关心的就是特朗普对财经的政策，以此可以推送很多这样的新闻。这种信息既有用户的行为信息，又要有内容的信息，像这种的结合现在已经开始有这方面的研究了。 举个例子，用推荐系统来做基于内容的推荐。这个时候一个特点重要的点是用户的兴趣会随着时间而变的。比如我去年感兴趣的东西，今年不一定感兴趣。今天在上班时候喜欢看的新闻，和我放假时喜欢看的新闻完全不一样。怎么样通过杂乱的信号源发现用户的兴趣点在哪儿，然后能够把变化用模型描述出来，这个是有一个叫做部分可观察的马可夫决策过程。但是应该说数学模型是在的，但是有很多的计算局限，一个局限是高质量的数据，第二个局限是计算能力。随着时间的推演，我觉得数据一定能够收到，计算能力也一定能达到那一天。我觉得我们有能力来预测用户长期的兴趣变化。 还有一点是资讯服务，我们有了资讯怎么把资讯和用户非常顺畅地进行交流。在这一点上，我觉得大家可以关注的是人机对话的系统，也许是用自然语言对话，也许就是人机交互的系统。比方说我们在车里，在这样的一个场景中，但是又特别关心美国大选的结果，所以我就可以问机器人这样的问题。比如问在美国选票情况如何，机器人会告诉我各州开票的情况，这种对话的方式是需要机器人做大量的阅读，去现在的场景。另外对当前的舆情分析也是非常了解，最后根据我的兴趣来做一个总结。 要做到这一点，这个机器人的智能点来自于几个方面。 第一个要能够有对话的基本功能，这个是来自于一个技术，叫做深度神经网络。 第二个要能够完成某种任务，比如信息搜索或者是总结，或者是生成一个对话，这个是需要强化学习的能力。 第三个是一个新的研究方向，叫做迁移学习。它能够做什么呢？可以把一个通用模型给个性化，把一个大数据产生的模型能够在个人的小数据上面给个性化，这样可以产生一个很体贴的机器人。 未来这三种方式都不可缺少，最好的方式是把这三个放到一个统一的通用富贵模型里面。我们期待这样的机器人可以做些什么呢？他们可以跟你闲聊，可以给你推荐信息，可以引导你去学习一些东西，并且可以提醒你该读这样的问题了，该看那样的东西了。 在这里举一个例子，比方说一个任务型的对话系统在读了很多古诗的信息、财经类的信息以后，你就可以跟他对话了。比方你问他 700 的股票现在情况怎么样？这个模型会产生一个侯选集，也就是这里的 A1、A2、A3。根据你的兴趣它可以进行排序，排序的结果就会产生出它对你的回答。比如说它的回答是「你想知道 700 最新的新闻吗？或者你想知道这个股价的走向吗？」这样就是一个很自然的任务型自然语言对话的系统。 总结起来说，我们今天的这种变革应该说确实是一种变革，因为就类似于工业革命。工业革命对应过来就是我们今天所说的智能的革命。当时的工业资本家、金融的资本家今天对应过来，应该是所谓的数据资本家。智能的能力能够建模，可以有跨界的能力、计算的能力、好的反馈、明晰的边界，这些能力的总和是我们所说的智能的能力。这种智能的能力如何能够把它赋予给大众，使得 A.I. for everyone，使得人人可以享受智能的红利，这也是今天我们所要严肃思考的。 因为这样发展下去的一个趋势，是数据有可能聚集在少数人手里，智能和智能的服务也许只有少数人才能够控制所有的发展。我们需要把门槛给降低，使得人人都成为内容的生产者，人人都能够用人工智能来促进他和媒体有机的结合。 我们下面需要思考的内容，包括 A.I. 时代是否还需要内容的生产者呢？是不是还需要人类的编辑？人工智能会带来一个崭新的不一样的内容生产方式吗？如何避免数据寡头的产生？我们如何能够把智能惠及所有的人群，让大家同时进步。这些是我们大家一起需要思考的问题。
-
发表了文章 2022-02-12
专访TensorFlow贡献者唐源：掌握 Google 深度学习框架的正确姿势
自 2015 年底开源到如今更快、更灵活、更方便的 1.0 版本正式发布，由 Google 推出的第二代分布式机器学习系统 TensorFlow 一直在为我们带来惊喜，一方面是技术层面持续的迭代演进，从分布式版本、服务框架 TensorFlow Serving、上层封装 TF.Learn 到 Windows 支持、JIT 编译器 XLA、动态计算图框架 Fold 等，以及 Inception Net、SyntaxNet 等数不胜数的经典模型实现，TensorFlow 已然已经成为深度学习框架的事实标准之一。 而另一方面，在开源一年多的时间里，TensorFlow 已经帮助了包括研究人员、工程师、艺术家、学生等在内的诸多用户在各个领域取得了卓越进展，据 Google 官方统计，目前人们已经在 6000 多个在线开放代码存储区中使用 TensorFlow。那么，在业务场景及个人摸索实践中，我们可以如何更好地使用 TensorFlow？以及掌握与运用深度学习、机器学习的正确姿势？带着诸多问题，我们特别采访了 TensorFlow 项目贡献者——美国 Uptake 数据科学家唐源，一起聊聊深度学习框架的那些事儿。 唐源，美国 Uptake 数据科学家，带领团队建立用于多个物联网领域的数据科学引擎进行条件和健康监控，同时建立公司的预测模型引擎，现已被用于航空、能源等大型机械领域。是 TensorFlow 和 DMLC 的成员，TensorFlow、XGBoost、MXNet 等软件的 committer，曾荣获谷歌 Open Source Peer Bonus。在美国宾州州立大学获得荣誉数学学位，曾在本科学习期间成为创业公司 DataNovo 的核心创始成员，研究专利数据挖掘、无关键字现有技术搜索、策略推荐等。 CSDN：您在大学获得荣誉数学学位，在此期间成为创业公司 DataNovo 核心创始成员，您是怎样开始接触到机器学习和深度学习？有哪些难忘的经历？ 唐源：这一切起源于本科与教授做的一个数值分析，接触到了 Matlab 这样的编程语言，由此开始对编程产生了特别浓厚的兴趣，学习各种编程语言，也上过大部分的软件工程的课程，因为在学校读的是宾州州立大学荣誉学院的学位，很多课程都加深了难度，也认识了很多非常聪明和勤奋的同学，在导师 Luen-chau Li 的鼓励下也慢慢开始上了好几门统计、数学、以及计算机研究生的课程，其中第一门就是统计系 Le Bao 老师的研究生难度的数据挖掘课程，开始逐渐接触机器学习，也对这方面产生了浓厚的兴趣，也自己开始跟进了这方面的研究。 DataNovo 是我在上斯坦福公开课的时候和几个小伙伴成立的公司，几个核心成员分布在世界各地，我们有几个经验非常丰富的软件工程师，有着对专利这一块非常有研究的律师，也有拥有沃顿商学院 MBA 的数学家，在凭着我们各自已有的经验基础上，我们通过大量的讨论和调查，一起探索了这个在当时还尚未被挖掘的领域，建立了许多基于机器学习和深度学习比较新颖的应用。比较难忘的是这个摸索的过程，有许多失败也有成功，大家一起用带着各国口音的英语，跨越世界上几个不同的时区，来讨论相关文献和项目进展，一起朝着一个目标努力，是非常有意思的事情，在本科的时候就能够有着这样的创业和合作经验，算是比较有成就感的一件事了。 CSDN：您在什么时候开始接触到开源社区？什么情况下成为了多个深度学习框架的 committer？ 唐源： 大四的时候在一家创业公司实习，公司对开源的政策特别开放，我们用到了各种各样的开源软件，用的过程中发现各种问题以及对用户体验度有着各种不满，Github 上面有地方可以提交建议，但是项目的管理者太忙，我就干脆自己对源代码进行研究然后提交修改，这样养成了一种习惯，遇到问题的第一反应是自己研究研究代码，然后自己直接去解决问题，独立阅读代码的能力也就这样慢慢培养出来了。很多时候由于对于某个开源软件特别熟悉，经常在做项目中会想到一些有趣的点子来对项目的性能进行改进和功能进行延伸。 至于成为深度学习框架的 committer，我最先开始参与的是 MXNet，当时只是业余时间做了一些小的深度学习的项目，发现这个开源项目还在初期，有很大的发展空间，然后又刚开始在其他项目中使用 Scala，在刘忆智的邀请和鼓励下，我们一起合作做了 MXNet Scala 语言包。又是机缘巧合，觉得 TensorFlow 的低阶 API 太难学也太难用，于是和谷歌的朋友合作建立了高阶的 API，也就是早期的 Scikit Flow, 类似数据科学领域中很热门的 Scikit-learn, 现在由于在 Google 内部和外部都需求特别大，也成为了 TensorFlow 中重要的一部分。 CSDN：机器学习在 Uptake 数据科学引擎的工作流程中扮演什么样的角色？ 唐源：数据科学是 Uptake 的核心，我们成功地和大型工业界的巨头，比如说 Catepillar，来合作建立比较有需求的产品，帮助解决传统工业上的一些痛点，比如 24 小时对火车每个重要部件进行条件和健康监控，帮助维修工程师找到问题所在，推荐高效的解决方式，新部件的自动下单订购，等等。机器学习在这个过程中起到非常重要的角色，我们需要用机器学习来建立很多有效的预测模型，由于数据量的庞大，数据性质的特别，以及出于物联网数据在传统大型工业领域还没怎么被深度探索的原因，我们也不能仅仅依赖于现有的技术，我们有着非常优秀的研发团队来支撑这一整个技术链。 CSDN：对于数据科学团队来说，您认为他们需要对深度学习了解到什么样的程度？ 唐源：深度学习并不是万能钥匙，很多问题往往用传统的机器学习算法就足够了。如果设计到很多图像，语音，文本这样的数据，深度学习的算法当然更加适用，基本上能大概清楚有一些什么样的算法以及他们适用于什么样的问题，就能实现一些简单的应用了。但是往往很多问题不是简单的分类和回归模型就能解决的，这中间可能涉及到多个值得研究和仔细设计的步骤，来让模型更加精确，这时候对深度学习扎实的功底就派上用场了，因为需要自己设计一些特殊的模型架构来解决这些问题，比如说涉及时间序列的应用，更需要仔细推敲和设计出最理想的算法，这涉及到对现有的多种类型的模型进行结合和改动，需要对这些已有模型有非常深的理解才行。 CSDN：对于数学功底不是很好的程序员，如果想掌握深度学习，甚至成为数据科学家，您有什么好的建议？ 唐源：深度学习其实一开始也就是从一个简单的神经网络发展来的。如果想扎扎实实做这一方面的研究，当然数学越好以及知识越广能够带你走的更远。但是如果没有很好的数学功底，走应用的路线也是非常好的，毕竟也不是所有的研究都有很大的影响力或者用到了很高深的数学，很多时候只要能够读懂大概的算法思路，知道这个算法在什么样的应用中适用就行了。现在数据科学家的门槛其实也是越来越低，以前是有 Scikit-learn 的帮助，现在是有着各种深度学习框架，甚至最近 TensorFlow 在机器学习应用方面的侧重，比如说大力研发高阶的 Estimator API，也更是让更多人能够更有效地学习和更快地进入到这个行业当中。 CSDN：如果没有数学基础的限制，能否给刚入门深度学习的开发者提供一些学习和实践经验？ 唐源：可以对这些深度学习的算法和架构都进行了解，要知道每个算法都适用于哪些类型的运用，基础好的话可以直接读一些好的会议以及期刊论文，关注一下前沿的研究。一定要多积累实战经验，可以多参与项目，参与像 Kaggle 这样的竞赛，最近的 Data Science Bowl 就是个很好的切入点，可以多融入到论坛中的讨论，来学习学习大家的思路和方法。如果对模型具体的实现感兴趣的话，可以尝试着读一读源代码，因为这不仅能帮助理解模型，也能了解到对于这个模型的实现，具体有哪些需要注意的地方，比如说性能上为什么这样处理会更好，API 为什么这样设计，等等。 CSDN：在忙碌的工作之余，您把大量的时间都贡献给了开源社区以及图书编写，但您是否有其他兴趣爱好（除了爬山和烧烤:)）？ 唐源：没错，爬山和烧烤！我还喜欢 K 歌，认识新的朋友，旅游，以及各种运动，比如说乒乓球，羽毛球，篮球，滑冰，游泳，等等。 CSDN：很多大公司都开源了自己的机器学习平台，侧重的模型可能有所不同，但都会有分布式、编程方面的优化，在您接触过的平台中，您如何推荐从业者在什么情况下采用哪种框架？ 唐源：我认为还是得具体看自己的应用、需求、以及团队的背景。如果在语音上面的应用很多的话，需要用到很多类似于 LSTM, RNN，等深度学习模型，那可以在做实验比较的时候会考虑到这些模型在不同框架上的速度。如果团队的背景很多元，比如在做研究的时候可能用的编程语言不统一，那就得考虑一下哪个平台能够对这些语言提供更好的支持。再具体一点，可能要考虑哪个平台使用起来是既能够实现目的又能够灵活地在现有基础上进行必要的拓展来达到各种需求。社区的支持也很重要，不仅仅是乐器学习社区，研究社区对某一平台的支持也是需要考虑进去的，比如说如果对 Facebook 的研究很感兴趣，那可能会更关注 Torch，因为他们的最新研究成果都会首先开源 Torch 的实现。 CSDN：TensorFlow 开发者大会给我们呈现了大量的信息，您最为关注的有哪些？ 唐源：我最关注的是那些高阶一点的 API，比如 Estimator 和 Keras 在 TensorFlow 内部的发展，我最早是和谷歌的 Illia Polosukhin 合作创建了 Scikit Flow 这个项目，然后紧接着被 TensorFlow 接受，放在了 TensorFlow 里面，得到了谷歌内部的大力支持和贡献，不仅仅适用于深度学习，也提供了许多机器学习的 Estimator，比如 KMeans、SVM、随机森林文凭，等等，来帮助更广范围的用户方便地使用像 TensorFlow 这样分布式的系统。TensorFlow 对一般用户来说确实很难学好也很难写得很正确，尤其是一些分布式的逻辑，这样的高阶的 API 是特别有需求的。还有比较关注也是一直在关注的就是 DeepMind 在研究上的一些进展，比如说对皮肤癌的图片分类，对艺术和音乐的自动生成，这些都是非常有意义的事情，我很高兴他们能够不仅仅花时间在研发这个框架，也能够好好利用这个框架来做这一些有意义有影响力的一些研究。这也是各种深度学习框架的意义所在：把先进的技术免费提供给大家，帮助大家更好更有效地做研究和分享研究成果。 CSDN：XGBoost 最初的优势在于 boosting，不了解 DMLC、MXNet 的人也可能很喜欢 XGBoost，您最开始改进和延伸了 XGBoost 项目，请介绍近期的发展或进展，未来的重要工作是什么？ 唐源： XGBoost 算是我比较早期的时候就开始一直参与的项目，经过了 Kaggle、学术界、以及工业界很多用户的千锤百炼，对于最近比较值得注意的一些进展，大家可以看看新增加的 Callback 功能，可以用来更方便地监控和观察模型的训练，最近也支持了 GPU，以及对 Spark、Flink 等大数据平台的结合使用的支持，未来的很大一部分工作就是更好地帮助用户使用，从他们的使用当中了解需求，尽可能帮助到大家更好地从事数据科学工作。 CSDN：如果用户已经使用 Spark 作为大数据处理平台，也用了 MLlib，有什么理由是他必须使用 TensorFlow 的？ 唐源： TensorFlow 提供的不仅仅只是现有的一些比较热门的模型实现，深度学习和机器学习这个领域的发展是非常快的，很多问题往往不是简单的现有模型能够解决的，最重要的是一个框架的灵活性和可拓展性一定是不能丢的，Spark 的 MLlib 很优秀地实现了一些工业界需求比较大的一些算法，但是 TensorFlow 能提供的不仅仅是这些，它提供了很多建立机器学习和深度学习必有的元素，比如，TensorFlow 有着自己的 metrics、losses、optimizers、layers 等模块来帮助建立各种各样的深度学习模型，它也提供了许多高阶的 Estimator API 来帮助用户更好地搭建和定义自己的分布式的模型，FeatureColumn 模块来帮助数据科学工作中很重要的特征工程，DataFrame 和 QueueRunner 等模块来更好地实现数据的预处理，提取批量队列，等等。另外，TensorFlow 省去了在各种不同的设备（比如 CPU、GPU、TPU）上的实现，用户只需要集中精力调用已经实现好的 API 就可以在各种设备上进行自动优化以及资源分配，这些都是 Spark 目前还不能或者是很难做到的。最近雅虎开源的 TensorFlowOnSpark 也挺有意思，可以在现有的 Spark/Hadoop 分布式集群的基础上部署 TensorFlow 的程序，这样可以避免数据在已有 Spark/Hadoop 集群和深度学习集群间移动，HDFS 里面的数据能够更好地输入进 TensorFlow 的程序当中。 CSDN：您如何与黄文坚老师配合完成《TensorFlow 实战》？怎样实现了工作和写作之间的平衡？写完此书有哪些收获和体会？ 唐源：我们一个在国内一个在国外，理论上来说合作起来本应该是相当困难。但由于我们都是 TensorFlow 的贡献者，对 TensorFlow 都是算比较熟悉的了，所以我们写起书来也是比较独立，每人负责几个章节。写的过程中也积极地互相交流，讨论书中的各个例子有没有更好的实现方法，书也不是一天两天就能写完的，所以在写的过程中也都得互相跟进和讨论 TensorFlow 的最近进展。写作基本上都是工作之余完成的，确实需要花很多的时间，因为毕竟是写出来帮助大家的，对很多代码和应用的解释，以及背景知识的介绍也需要反复推敲。写书的过程中也发现和激起了对 TensorFlow 没有贡献到的一些模块的兴趣，通常写着写着发现自己已经打开了无数的代码文件而只写下了一两段话，写书也是一个不断学习，灵感不断涌现的过程。 CSDN：在开发人员读完《TensorFlow 实战》之后，可能需更进一步的提升，您是否有下一步相关著作的计划？或者有其他的学习途径可以推荐？ 唐源：我们这次虽然大部分的例子都是基于最新的 1.0 版本，但是 TensorFlow 的发展特别快，我们会在下一版介绍更多的新的功能，也会根据读者的反馈意见来更好地帮助大家学习。其他的学习途径，可以参考官方的一些例子，一般都是和代码比较兼容的，然后 Github 上面也有很多值得学习的代码和例子，如果对源代码比较感兴趣，也鼓励大家积极参与贡献。
-
发表了文章 2022-02-12
他们发明了一门编程语言，名字叫：摇滚明星 Rockstar
Rockstar 是一门图灵完备的动态编程语言。设计这门语言的目的是能够像写歌词一样开发计算机程序。它的歌词风格主要受 20 世纪 80 年代重摇滚和电力民谣的影响。 为什么会有 Rockstar？ 如果我们让 Rockstar 成为一门真正的（虽然毫无意义）编程语言，招聘人员就不会在招聘时对“摇滚开发者”颇有微词。 另外，它很有趣，一门基于歌词编译的编程语言很值得我们一试。 我们还可以用它做贴纸，谁不想在自己的笔记本电脑上贴上“认证 Rockstar 开发者”这样的贴纸呢？ Rockstar 语言规范 注释 我们不建议在 Rockstar 程序中使用注释。这可是 Rockstar，所以要让阅读代码的人自己从中寻找意义。但如果你坚持要使用注释，那么请把注释放在括号里。是的，这意味着你不能在算术表达式中使用括号，如果有复杂的表达式，要将它们分解为多个子句。 Tommy was a lean mean wrecking machine. (initialises Tommy with the value 14487) 变量 在 Rockstar 中，有两种声明和使用变量的方式。 公共变量由一个关键字（a、an、the、my 或 your）和关键字后面的变量名组成，变量名只能包含小写 ASCII 字母 a-z。 特定变量由专有名词组成，专有名词是指任何不是保留关键字并以大写字母开头的单词。特定变量名称可以包含空格，只要每个空格后跟一个大写字母。可能有一些开发人员会创建类似 Customer ID、Tax Rate 或 Distance In KM 这样的变量名称，不过我们建议你使用惯用的变量名称，如 Tommy、Gina、Doctor Feelgood、Mister Crowley、Kayleigh、Tom Sawyer、Billie Jean 和 Janie。 Eleanor Rigby、Peggy Sue、Black Betty、Layla 和 Johnny B Goode 在 Rockstar 中也都是有效的变量名，尽管严格来说它们算不上是惯用的。 与 Ruby、Python 和 VBScript 一样，Rockstar 的变量是动态类型的，所以不需要在使用前进行声明。 代词 关键词 it、he、she、him、her、them、they 总是指向最近命名的变量。 类型 Rockstar 使用了与 ECMAScript 非常相似的类型系统，不过 undefined 听起来不是非常摇滚，所以我们使用 mysterious 替代它。 Mysterious——任何未赋值的变量，使用关键字 mysterious 表示。 ——空值类型，在计算时等于 0 或 false。关键字 nothing、nowhere 和 nobody 是 的别名。 Boolean——具有 true 和 false 值的逻辑实体。（关键字 maybe 和 definitely maybe 被保留下来，可能在未来会用到）。 right、yes 和 ok 是 true 的有效别名。 wrong、no 和 lies 是 false 的有效别名。 Number——Rockstar 中的数字使用 DEC64 数字类型进行存储。 String——Rockstar 中的字符串是 16 位无符号整数值的序列。 Object——数据属性的集合，与 ECMAScript 一样。 字面量和赋值 Rockstar 中的字符串字面量使用双引号括起来。 “Hello World” Rockstar 中的单引号被视为普通的字母。这似乎有点不寻常，直到你想起来 ain't talkin’ 'bout love 在摇滚中其实是一句完美有效的歌词。 Rockstar 中的数字字面量是十进制数字。 123 3.141592654 赋值使用 put/into 关键字组合： Put 123 into X 表示将 123 赋值给变量 X。 Put “Hello World” into the message 表示将“Hello World”赋值给 the message 变量。 递增和递减 我们分别使用 Build {variable} up 和 Knock {variable} down 关键字进行递增和递减。 Build my world up 将会让 my world 的值增加 1。 Knock the walls down 将会让 the walls 的值减 1 算术 基本的算术运算使用 plus、minus、times、over 和 by 关键字。 算术表达式： plus {b}——加法，别名为 with。 minus {b}——减法，别名为 without。 times {b}——乘法，别名为 of。 over {b}——除法，别名为 by。 例子： Put the whole of your heart into my hands——把 your heart 和 the whole 相乘，并把结果赋值给 my hands。 My world is nothing without your love——将零减去 your love，并将结果赋值给 my world。 If the tears of a child is nothing——检查 the tears 乘以 a child 是否等于零。 My love by your eyes——返回 my love 除以 your eyes 的值。 诗意字面量 Rockstar 还支持一种独特的语言特性，称为诗意字面量（poetic literal）。受 here-document 语法的启发，诗意字面量允许程序员在初始化变量的同时表达他们内心深处的焦灼。 诗意类型字面量 在使用关键字 true、false、nothing、nobody 和 nothing 进行赋值时，使用单行代码，包括变量名、is 关键字和字面量。 My heart is true——使用布尔值 true 来初始化 my heart。 Tommy is nobody——使用 nobody 别名将 Tommy 的值初始化为 。 诗意字符串字面量 在进行诗意字符串字面量赋值时，以变量名作为开头，后面跟一个关键字（如 says），然后再跟上一个空格。剩余部分（直到碰到 终止符）被视为不带引号的字符串字面量。 Billy says hello world! 表示使用字符串字面量 hello world! 来初始化 Billy。 The world says hello back 表示使用字符串字面量 hello back 来初始化 the world。 诗意数字字面量 在进行诗意数字字面量赋值时，以变量名作为开头，后面跟上关键字 is，或者别名 was 或 were。只要下一个符号不是保留关键字，这一行的其余部分将被视为一个十进制数，这个数由连续出现的字符串长度对应的数字组成。为了表示数字零，也为了弥补摇滚中缺少单字母单词和双字母单词，单词长度需要对 10 取模。句点（.）表示小数位。除第一个句点外，任何非字母字符都将被忽略。 Tommy was a lovestruck ladykiller 表示使用 100 来初始化 Tommy。 Sweet Lucy was a dancer 表示使用 16 初始化 Sweet Lucy。 A killer is on the loose 表示使用 235 初始化 a killer。 My dreams were ice. A life unfulfilled; wakin' everybody up, taking booze and pills 表示使用 3.1415926535 初始化 my dreams。 请注意，诗意字面量可以包含保留论坛关键字，比如这个例子中的 taking。 比较操作 与 Visual Basic 和一些脚本语言中的单个等号运算符类似，Rockstar 中的 is 关键字出现在二手语句中还是出现在表达式中所表示的意思也不一样。 Rockstar 中的比较操作只能在表达式中完成。 Tommy is nobody 使用 nobody 来初始化 Tommy。 If Tommy is nobody 表示在 Tommy 等于 nobody 时执行后面的代码块。 修饰符 not 会反转比较操作的结果，类似于 SQL 中的 IS / IS NOT 。关键字 ain’t 是 is not 的别名。这种用法与惯用英语相反，其中“Tommy isn’t anybody”、“Tommy ain’t nobody”和“Tommy ain’t not nobody”表示相同的意思。 Rockstar 还支持以下的比较语法： is higher/greater/bigger/stronger than 表示“大于”。 is lower/less/smaller/weaker than 表示“小于”。 is as high/great/big/strong as 表示“大于等于”。 is as low/little/small/weak as 表示”小于等于“。 输入输出 在 Rockstar 中，我们使用 Listen 关键字从 STDIN 读取一行输入，并使用 Listen to 将输入赋值给变量。 Listen to your heart——从 STDIN 读取一行，并将它赋值给 your heart。 使用 Say 关键字将变量的值写到 SDTOUT。 Say Tommy——将 Tommy 的值输出到 STDOUT。 Rockstar 将 Shout、Whisper 和 Scream 作为 Say 的别名。 流程控制和块语法 条件语句 条件表达式以 If 关键字作为开头，后面跟上表达式。如果表达式的计算结果为 true，则执行后续的代码块。在 If 代码块之后可以有可选的 Else 代码块。如果 If 表达式计算结果为 false，则执行 Else 关键字后面的代码块。 循环 与 If 语句类似，循环使用 While 或 Until 关键字表示，只要表达式得到满足，后面的代码块会被重复执行： Tommy was a dancer While Tommy ain't nothing, Knock Tommy down 使用 16 初始化 Tommy，然后循环，每次将 Tommy 减 1，直到 Tommy 等于零。 break 和 continue 语句的用法与其他大多数基于代码块的语言一样。Rockstar 将 Break it down 定义为 break 的别名，并将 Take it to the top 定义为 continue 的别名。 代码块 Rockstar 中的代码块以 If、Else、While 或 Until 作为开头，并以空行或 EOF 作为结尾。 Tommy was a dancer While Tommy ain't nothing Shout it Knock it down 函数 函数使用变量名和后面的 take 关键字以及由 and 关键字分隔的参数列表进行声明。 Multiply takes X and Y Search takes Needle and Haystack 函数体是一个没有空行的语句列表。空行表示函数体的结束。Rockstar 中的函数总是有返回值，使用 Give back 关键字表示。 使用 taking 关键字调用函数： Multiply taking 3, 5 相当于 returning (presumably) 15 Search taking "hands", "lay your hands on me" 示 例 使用极简的 Rockstar 表达 FizzBuzz，为了清晰起见，使用了缩进： 惯用的 Rockstar，使用诗意字面量，没有缩进： 一些想法 如果有可能，尝试改进这门语言。我并不热衷于连续块语法——对于初学者来说，还无法实现嵌套块。 想办法实现图灵完备的摇滚民谣编译器。或许是基于 BF 的东西，我们使用单词长度或首字母或其他东西将歌词编译成 BF，或者其他一些极简但图灵完整的语言。 制作”认证 Rockstar 开发者“贴纸，并将它们发给任何可以写 Rockstar 代码的人。 使用 composer 为代码生成乐谱。
-
发表了文章 2022-02-12
如何提高团队的研发效率？
研发效率是在现代企业都关注的，注意是因为靠谱的工程师是有限的，而且软件工程师的人力成本较高，时间成本更高。在大多数情况下，软件工程是一个团队活动，通过协作实现突破。好的想法从不匮乏，但高速执行却不那么容易。高效团队会习惯于更高的标准。当研发速度停滞时，人们会创造性地寻找重建高速产出的方法，但是如果长时间停滞，也会造成人员的流失。 如何提升研发效率呢？或者说，研发速度是否可控呢？ 速度是位移和时间的函数，很多时候，位移方向的目标更容易被忽视。然而，项目失败的最常见原因是团队构建了错误的东西。“绕树三匝，何枝可依。”，实际上，方向错了，停止就是进步。 确定方向本身就是很困难的事，例如预测产品或市场匹配度等。通常需要关注客户的声音，成功不是提供一个特性，而是学习如何解决客户的问题。理想情况下，我们希望倾听客户的意见，满足他们的需求，同时只发布他们最感兴趣的那20% 。 即使那些所谓具具远见的创新者，也很难预测客户到底需要什么。由于在选择方向时需要一些猜测，因此系统的灵活性和可扩展性就变得至关重要。灵活性可能表现为开放性，最大限度地提高试验的速度，减少对给定计划的承诺，快速发展的产品，以及在决策中区分可逆和不可逆的功能特性。尽管，可扩展性使犯错的代价比想象的要低，而“time to market”则肯定是昂贵的。 有很多人尝试直接观察软件团队的研发效率，但众所周知，这样的测量是非常困难的。为了弥补这一缺陷，企业会使用员工参与度来调查与研发效率相关的问题。这样的调查往往局限于对员工参与度和与公司目标一致性的高层次衡量，这也是OKR模式的辅助手段。利用这些调查来决定是否实现了高速迭代，询问工程师实际花费了多少时间来设计和编写代码，工具是否充分，过程是否有效，以及技术债务的影响等。 在着手进行这类问题的调查之前，一般会承诺根据调查结果采取行动，以便这些行动对目前的调查和今后对这类调查的答复产生积极影响。 可扩展性可以通过自治团队来改进，这些团队围绕着有良好边界的特定责任区形成高度的内部凝聚力。团队所负责的服务彼此公开API; 在理想情况下，不存在跨团队沟通，因为与业务逻辑交互所需的全部都是API，而业务逻辑是业务团队的责任。 服务的实现细节通常是不共享的，并且不存在对远程服务所依赖的数据存储进行私有访问。即使服务需要不前向兼容，API的新旧版本仍然通常会在重叠的一段时间内可用，因此业务可以在旧版本被弃用之前进行迁移。 服务的拥有者可以按照团队自己的速度发展并发布变更，独立于可能发生的其他变更，并在时间上与其脱钩。这就是所谓的“无许可创新”。然而，确定责任领域之间的接口是具有挑战性的，这些接口会不可避免地随着时间的推移而演变，完美的自治永远是虚幻的。 一组软件服务不断进化，就像一个鲜活的生命。发布新的接口，整个服务可能分离或合并，单个服务可能经历重大的重新设计或被弃用。理想情况下，内部团队拥有高度的自治，在组织结构上与“高内聚、低耦合”的软件设计原则相一致。 基于康威定律，这些团队提供的服务应该是独立的。理想条件下，不需要对所依赖的服务进行任何更改，任何团队就可以实现80% 的任务。在剩下的20% 中，通过特定的接口实现。 在符合研发路线图的情况下，服务拥有者会同意那些有意义的变更，但是在路线图上的优先级较低。这时，业务方可能会提供一个“援助团队”来实现所请求的更改。援助团队由来自业务团队的开发人员组成，这些工程师临时加入拥有服务的团队。设计、测试、编码和发布都需要服务拥有者的逐步批准; 当完成更改后，援助人员将返回到他们原来的团队。这个方式的一个附加价值是交叉授粉，在团队之间缺乏沟通的情况下尤其有效。 产品开发的敏捷方法可以迭代和速度之间做平衡。 即使在需求快速变化的世界里，团队井然有序的积压工作也是可以的，只要最新版本用于sprint即可。团队明确承诺从待办列表中完成一系列任务，而作为回报，则是团队获得了一个不可中断的受保护时间窗口，这是一个尽可能快速工作的冲刺。在完成这个不间断、无波动的幸福周期之后，sprint 的成果将展示团队履行的承诺。 在下一个 sprint 计划会议继续之前，团队将进行回顾。这是一个内省会议，其中团队评估其达到的速度，并确定在随后的sprint中提高速度的方法。一个诚实的回顾，建立在信任和自我意识的基础之上，可以找出在进入下一个sprint之前如何“提高研发效率”。 专注是实现高效研发的必要条件。 团队希望专注于解决客户的问题，高速实现所责任的业务逻辑。他们不希望不能控制自己的团队。可靠的基础架构和基础设施是无许可创新的助推器，更是是软件架构转变的推动者。勿在浮沙筑高台，不为繁华易匠心。 一个高效团队注重培养一种文化，这种文化鼓励团队成员高效交付成果。这是一种自我强化，具有高效文化的团队往往能够吸引到高手。重要的是，要假定团队成员是有才华的，与使命保持一致，并且希望高效工作。文化中对研发效率产生积极影响的方面包括: 多样性和包容性教程、谦逊、信任、乐于学习、愿意带着“紧迫感和重点”前进、自主性以及集体承诺取得成果的意愿等等。 为了实现高效研发，有必要投资那些使工程师能够高速工作的系统，并最大限度地将他们的时间花费在自己的文凭领域。显而易见，出发点是构建、集成和部署代码的工具和过程，以及那些在代码发布后用来运营的工具和过程，确保代码满足可用性、可靠性、性能和安全性的要求。 虽然基于服务的体系结构可能带来自治性的好处，但跨服务边界的故障可能更难排查。如果日志采集、传输、监控、报警和问题跟踪在各个服务之间都是通用的，那么就会很有帮助。可观测性的能力应能够进行分布式跟踪，便于精确检测关键信号和指标，并逐步细化排出空间，从而精确找到问题的根本原因。 为了提高创新速度，需要积极寻求降低实验成本，以便能够做更多的实验。高实验率可以促进更频繁纠错。但实际上，高比率的实验可以被看作是大量丢弃的想法、文档垃圾、死代码和失败，造成资源的大量浪费。 成功的团队拥抱失败，是指做出的大多数错误选择是容易逆转的。失败，如果处理得当，可能是一个成长的机会。错误并不是必要的罪恶，是做新事物的必然结果，可以被看作是有价值的。 但是，我们客观地认识到了自己的错误么？！ 尽管大家都觉得软件工程越来越重要，但是太多的软件项目最终还是偏离了目标，并且超出了预算。有效的交付需要对所要的东西有一个完美的视野，同时要朝着那个视野坚定地前进，对所有的干扰视而不见，这可能是一个长期存在的误区。提高研发效率的一个更可靠路径是优化研发速度，提倡高效文化，开放的实验和学习，自治而敏捷的组织，不忘初心。
-
发表了文章 2022-02-12
十大经典的零售业数据科学案例
数据已被证实是零售行业的重要资源，数据对于商业中的决策者来说非常重要。不同领域的大公司都在寻求利用数据的最佳方案。 零售领域发展非常的迅速，数据的应用也相当全面，例如零售商会分析数据并发展特殊的客户画像，以了解零售商TA的痛点。对大数据的全面分析可以影响甚至操纵客户的决策，很多的讯息流与多渠道的触及都用来实现这些目的。 本文介绍了零售业中排名前10位的数据科学用例，让你掌握最新的趋势。 1.推荐引擎 事实证明，推荐引擎对零售商来说非常有用，可以作为客户行为预测的工具。 零售商倾向使用推荐引擎作为影响客户意见的主要方式之一。 提供产品推荐使零售商能增加销售额并主导消费趋势。 推荐引擎根据客户的选择调整推荐的内容。推荐引擎利用大量的数据筛选来获取有价值的商业洞察。 通常，推荐引擎使用协同过滤或内容过滤的模型来实现，主要考虑客户过去的行为或一系列的产品特征。例如人口统计数据，消费偏好，需求，先前购物体验等各类型的数据，都会经过数据学习算法纳入模型中。 在构建协作和内容过滤关联模型后，推荐引擎就可以根据客户的偏好计算相似性指数，并相应地提供商品或服务的推荐。 而向上销售和交叉销售建议则取决于对客户的客户画像。 2.购物篮分析 购物篮分析被视为零售业中数据分析的经典工具。零售商多年来一直从中获利。 这个过程主要取决于梳理客户交易历史的大数据。消费者未来的决策和选择可以通过这个工具大规模的进行预测。了解篮子中的产品以及客户所有喜欢，不喜欢和预览记录，对于富贵零售商在货架管理，价格制定和内容放置方面都是相当有帮助的。分析通常通过规则挖掘算法进行，需要事先将数据进行处理，转换成以订单为基础的格式。在此基础上，建立产品之间的关联联系，并且进一步应用关联规则进行分析。这些分析有助于改善零售商的发展战略和营销技巧，并且可以极大化销售的效率。 3.保修分析 零售领域中的保修分析包含监控保修索赔，检测欺诈活动，降低成本和提高质量等等。该过程涉及数据和文本挖掘，以进一步识别索赔模式和有问题区域。 通过细分分析能将数据转换为可执行的实时计划，洞察和建议。 只要涉及处理模糊和密集的数据流，检测方法就会非常复杂。通常分析会专注于检测保修索赔中的异常情况。功能强大的互联网数据平台可加快分析过程中的大量保修索赔。这是零售商将保修挑战转化为可执行的情报的绝佳案例。 4.价格优化分析 为客户和零售商提供合适的价格是优化机制带来的绝佳优势。价格形成的过程不仅取决于生产的成本，还取决于TA客户的消费力和竞争对手的报价。数据分析工具将这个问题提升到一个新的水平. 价格优化工具包括很多不能公开的商业机密方式。但大致上从多渠道来源获得的数据，能定义价格的灵活性，并且考量位置，客户的个人购买意愿，季节性因素和竞争对手的定价等因素，计算极值和频率表，以进行预测变量和利润响应的变量评估和最优分布分析。 该算法先假定客户细分以定义对价格变化的响应。因此可以回推出满足企业目标的成本。使用实时优化模型，零售商有机会吸引客户，保持关注度并实现个人定价方案。 5.库存管理 库存涉及库存商品以供将来使用。 库存管理则是指在紧急时能使用的库存商品。 零售商的目标是在适当的时间，适当的条件下，在适当的地方提供合适的产品。 在这些目标下，零售商对库存和供应链必须进行深入的分析。 强大的机器学习算法和数据分析平台，可挖掘个个要素和供应链之间的模式与相关性。 通过不断调整和开发参数和值，算法可以算出最优的库存和库存策略。 分析师可以发现高需求的模式，并制定新兴销售趋势策略，优化物流并管理收到库存数据。
-
发表了文章 2022-02-12
历时2个月，深访6位大咖，我们完成了这份AIOps指南
2021年，业界对AIOps的关注和讨论可以说是达到了一个顶峰，许多国内外企业尝试落地AIOps的实践层出不穷。毋庸置疑，AIOps已是IT运维的大势所趋。可是想要坐上这趟飞驰的时代列车，必须掌握哪些要领？ 为帮助大家解决心中疑虑，捋清技术风向及思路，我们精心准备了一次专访，采访了阿里-柳明、新浪微博-彭冬、奇虎360-籍鑫璞、携程-徐新龙、新炬网络-宋辉、平安科技-汪洋等6位AIOps领域的先行探索者。 本系列文章将会汇集他们的研究心得与实践经验，解答目前业界对AIOps普遍存在的认知误区及疑惑难点，助力国内AIOps的建设和落地。本文为上篇，从大环境着眼，详析AIOps的现实路径。 目录大纲 认真读完本文，你可以了解到： AIOps在国内的真实发展现状； AIOps未来的应用主要集中于哪些方面？将实现怎样的技术突破？ AIOps是否适用于所有企业？为什么？ 同属运维领域，自动化运维、DevOps以及AIOps之间的关系是怎样的？ 下一步AIOps的发展将会走向何方？会对哪些领域产生影响？ Q1：今年AIOps这么火，但实际上它目前在国内究竟发展到了哪一步？ A 柳明（阿里） 我认为绝大部分公司目前AIOps还处于探索阶段，小部分公司处于系统性建设基础的阶段。很多吹得神乎其神的AIOps落地的公司或组织，我觉得很少能在大规模场景下经得起推敲。 彭冬（新浪微博） A 很高兴在AI的助推下，AIOps能够迅速出现在更多人的视野，我们从各种技术峰会就可以看到，AIOps的专题逐渐在增多。 就目前而言，国内实施AIOps的企业并不多，互联网企业由于天然的优势，在智能运维方面会早一些，但传统企业及中小企业几乎为零起步，大部分企业还处于原始人工运维的阶段。 随着互联网的发展及开源框架的兴起，很多企业逐渐意识到借助开源工具能够大幅度提高运维效率，这也大大缩短了企业实施DevOps的周期，为进一步实施AIOps打下了基础。因此，从节奏和趋势来讲，AIOps落地会比想象更快。 A 籍鑫璞（奇虎360） 2021年可以说是AIOps的元年，从今年起陆续有企业在这方面开始投入人力的研究，包括BAT、一些二线的互联网公司，也包括一些小的创业公司。但是总的来说，大家都处在开始阶段，远没有达到AIOps的终极目标——运维大脑这个阶段，AIOps还有很长的路要走。 徐新龙（携程） A 从行业整体水平看，目前还是处于场景探索和效果验证的阶段，在故障检测、故障根源定位、容量预测及规划、智能问答等方面已经有非常好的实践。 A 宋辉（新炬网络） AIOps当前还处于初步探索的阶段。在这方面国内互联网公司走得相对靠前一点，最近一些比较大型的传统企业也在开始尝试。大家目前实践和关注的内容基本也都还处于初级阶段，更多的是一种对AIOps的思考以及在现有运维能力上一些点的提升和突破，整个面的解决方案和能力尚未成形。 当然AIOps作为未来的运维发展方向，大家都是非常认可的。今后随着越来越多人的参与，大家能更多地形成一些合力，相信经过时间的增长和经验的积累，国内AIOps的发展也将变得越来越成熟。 汪洋（平安科技） A 实际上AIOps并不是从今年才开始流行，随着近些年人工智能的发展，大家开始相信通过AI可以做更多的事情，同样AI也被应用在运维领域，于是出现了AIOps。从最初的人工运维到自动化运维再到AIOps是一个很自然的发展过程。 总而言之，AIOps在运维领域的应用前景非常广泛。然而，虽然我们对AIOps已经谈了一段时间，但从我个人来看，仅处于发展的初级阶段，大家都还在摸索，落地的案例和算法都还不算多。很多情况下，使用的都还是传统的统计分析方法，只是被包装了一个AIOps的名字而已。但同时这也是任何事物发展过程中的一个必经阶段。 Q2：为什么说AIOps是运维发展的必然方向？它在未来的应用主要集中于哪些方面？将实现怎样的技术突破？ 之前很多运维决策都是靠人的经验，也就是所谓的PE角色线上解决运维问题。首先他这样的专家经验不是系统能力，只能是有多少这样的人才能解决多少这样的运维问题，不具备规模化复制的能力。之后大家意识到这样的问题，开始把这样的经验沉淀到系统，变成系统能力，也就是规则系统。 但这样规则系统的能力不具备泛化能力，也就是说系统很难对稍微不一样的输入做出正确性的判断。所以利用大规模数据挖掘、机器学习和人工智能技术对纷繁复杂的运维大数据进行实时分析和分类及预测，为系统维护提供更具泛化能力的有效决策的方案，是解决当下运维困境的唯一选择。 在未来我们可以利用运维产生的大数据数据、AI预测及分类算法的能力让我们在容量规划、弹性调度、故障检查、智能诊断、问题自愈等方面取得突破。 AIOps是历史发展的必然趋势，是运维技术发展的一个重要节点，不因人的意志而转移。运维从人工到二手工具，从自动化到智能化是互联网发展及企业业务发展共同选择的结果。 最近马化腾向合作伙伴发表了公开信，提到很重要的一点是，移动互联网的主战场正在从上半场的消费互联网向下半场的产业互联网方向发展。产业互联网的基础是大数据、人工智能等互联网技术，企业需要稳定发展，需要解决规模性和精细化的问题，而AIOps就很好地解决了这样的问题。 在披上AI华丽的外衣后，无论AIOps显得多么高大上，其本质上还是运维技术，还是要解决好运维中所面临的问题。因此AIOps的实施首先要看运维基础设施的成熟度。 运维基础设施包括：网络、CI/CD设施、自动化平台、大数据基础平台、机器学习平台等等。 在实践时，AIOps用的模型的准确率非常依赖数据的准确性，决策执行则依赖自动化能力。此外，AIOps的实施需要AI技术的支撑。当然，很多算法层面的东西已经工程化，比如我们用LR做故障分类时，都不需要太理解LR算法本身，调用Python库就可以，但这并不代表我们就可以不深入研究算法原理。 国内外一些企业也开源了一些故障检测、异常分析、趋势预测等框架，这都降低了门槛。但要想提升这些算法的准确率，甚至是发现一些新的算法来更好地解决业务问题，还需要大量的理论基础支撑和资源投入。 随着互联网的软硬件呈现爆发式增长，新的架构层出不穷，运维人员需要做到7*24小时的职守来保证系统的可靠性和稳定性。这种空前的压力，如果有一种“机器大脑”来减少甚至代替运维人员去做一些事情，将极大地减少他们的工作量，提高运维效率。如何得到这种“机器大脑”呢？ 很多运维场景都可以总结成一些规则化的东西，可以经过提炼总结生成人工经验库。除了人工经验以外，还可以通过AI算法对历史数据进行分析，得到一些由机器生成的规则。如果能将AI算法+人工经验应用到OPS中，代替一部分人工决策，将推动运维从普通的自动化阶段向智能化阶段迈进。 AIOps未来集中在两个大方面，一是成本，二是效率。成本方面需要从节约成本、提高资源利用率为出发点，而效率方面就需要提高效率为根本宗旨，做到及时发现问题，快速定位问题，最终解决问题。AIOps需要大量的实践和探索，需要运维人员、大数据工程师以及算法工程师一起努力，才能实现技术的突破。 规模效应和时间维度上的积累会导致运维数据（日志、监控数据、应用信息等）体量异常庞大，传统基于经验规则方式的运维已经不能很好地胜任，需要借助大数据+人工智能的手段，用“机器学习”替代“规则”。从这个意义上讲，AIOps无疑是解决此类问题最合适的方案。 从本质上讲，AIOps的出发点和立足点主要还是提升网站可用性、降低企业运维成本、提升效率等应用场景，未来的应用也主要是体现在这些方面。通过机器学习的方式，AIOps将攻克自动化运维无法解决的一些“痛点”问题，致力于构建一种基于数据化运维的生态环境。 技术上的突破主要还是体现在算法和算力方面：针对特定的应用场景，构建数据模型，算法需要不断迭代提升准确率和覆盖率；面对未来海量的运维数据，实时计算和处理能力将会是一个很大的考验。另外，提升运维数据的质量也是非常重要的，尽管数据体量非常庞大，但有效和有用的数据所占据的比例却非常稀少。实践表明，算法效果的上限很大程度上受制于数据质量的好坏。 A 宋辉（新炬网络） 早期的运维工作大部分是通过人力完成的，随着IT规模的增长及信息化的进展，我们通过自动化将一些重复劳动的效率进行提高。但到了现在以及可以预见的未来，IT系统架构的复杂度越来越高，规模越来越大，同时伴随人力成本不断提高，渐渐地对于一些大型企业或重型信息化企业来讲，运维就不一定是简单依靠人力能解决问题了。因此引入和发展AI能力，对于运维来讲确实是必然趋势。 从目前的技术能力来看，对于AIOps的应用主要集中在异常检测及根因分析两个方面，而且在一些头部公司已取得了比较成功的应用。通过两个应用场景的突破，可以解决海量指标的实时异常分析和异常场景下快速根因定位，大大提升问题分析处理的效率。 对于未来AIOps技术上的突破有很多可以值得期待的，现在异常检测及根因分析已经取得了很好的效果，还有大家在致力于研究的告警关联分析、告警传播关系、多指标关联分析、根源分析等，将来有希望能迎来大家所期待的无人值守的那一天。 Q3：AIOps是否适用于所有企业？为什么？ 我觉得不能一概而论。满足机器、IDC、业务具有一定规模，并且系统和业务运维在规模下遇到运维痛点的企业是比较适合推行AIOps的。原因在于，第一，这样的企业具有规模化的运维数据；第二，这样的企业有动力去推动AIOps落地。为什么一定强调这两点呢？因为AIOps是运维思维的完全颠覆，可能会对现有的运维基础设施带来很大冲击，虽然不是一切推倒重来，但是在一个没遇到瓶颈而只是凑热点，并没有动力去推动AIOps落地的公司来说，很难长时间投非常多资源去落地这个事情。 理论上，AIOps适合所有的企业，先行者是互联网企业，受益者是所有企业。因为大家都面临同样的问题，比如业务复杂性的提升、机器数量的增加、迭代周期的缩短等等。 2021年，天猫双11成交额达2135亿，每秒大概成交额为247万，可以想象网络抖动1秒或是某台服务器故障无法及时摘除会有多大的影响。 AIOps解决的是智能发现和智能决策的问题，只有让运维的过程自动化甚至智能化，才有可能解决规模化的难题，规模化伴随着任何一家企业成长的全过程。AIOps研究的范围涉及到企业成本控制、研发效率和质量保障的方方面面，因此也就跟企业发展息息相关。 我觉得AIOps并不适用于所有企业。所有概念的提出，都以解决问题为根本出发点。如果企业规模不是很大，场景并不是太复杂，用普通的运维手段，少数的人就可以搞定的话，没必要去花精力去研究AIOps。只有服务器数量、线上业务到了一定量级以后，才需要去考虑AIOps。 运维几乎是所有企业必设的岗位，无论传统企业，亦或者互联网企业无不如此。目前AIOps实践比较活跃和积极的企业主要还是大中型的互联网企业，因为规模效应，这些企业积累的数据体量和传统的企业相比有量级上的差异，很多小问题在数据量被放大后就会变得尤为突出和严峻，基于传统运维的经验规则这时已经不能很好的保障网站可用性、减低和优化运营成本、提高持续交付和持续集成效率等职能，所以说很大程度上“量”决定了企业适不适合实践和引入AIOps。 但从运维岗位的划分上看，职能大体都是相似的，同时运维数据在性质上差异也不大。从这个意义上说，AIOps是适合于所有企业的，只是中大型的企业在数据体量庞大之后“痛点”过早的暴露出来而已。 从AIOps给企业带来的好处来看，答案是肯定的。但从另一个方面想，AIOps很大程度上取决于数据的质量及样本的丰富性。也就是说，如果样本很少，数据本身带有倾向性，质量不高，那么AIOps的准确性和效果就会大打折扣。 从这点来看，我认为AIOps更适合大的企业，更适合云计算。中小企业想要享受AIOps带来的效益，可以考虑将系统部署在公有云上。公有云更加标准化和规范化，也拥有大量的数据，这些数据训练出来的模型准确性应该更高。举例来说，为什么Oracle的Autonomous Database只在其公有云上提供服务，原因也在于此。 Q4：同属运维领域，自动化运维、DevOps以及AIOps之间的关系是怎样的？ 自动化运维：利用规则、经验或者简单数据分析来自动化执行，可以认为是智能化运维的初级阶段——DataOps。 DevOps：开发运维一体化，解决的是开发迭代效率问题，是为运维效率低效提供的工具或平台化的能力 AIOps：智能化运维，是利用大规模数据挖掘、机器学习和人工智能技术对纷繁复杂的运维大数据进行实时分析分类及预测，为系统维护提供更具泛化能力的有效决策的方案。 所以我对运维发展阶段的看法是：人肉运维→DevOps→DataOps(自动化运维)→AIOps。所以自动化运维、DevOps、AIOps的关系更多是运维发展所处不同阶段。 自动化运维、DevOps和AIOps是运维发展不同阶段的产物： DevOps注重开发在运维领域的角色，其目的也是更好地实现自动化运维，DevOps想通过在运维技术的基础上注入开发能力，加速运维自动化的进程。 自动化运维与DevOps都没有明确包含智能化的概念，而AIOps则明确了机器学习、人工智能赋能运维的目标，将自动化提升到智能化的更高地层次。尽管如此，AIOps的基石还是自动化，广义来讲，AIOps应该是包含自动化基础设施的智能化运维技术。 解释这个问题，就不得不从运维的发展历程说起了。企业发展最早期，规模小和技术落后，基本都是人肉运维，通过手工编写特定的shell脚本，就可以完成特点运维目标； 随着企业规模的快速扩大，人力就成为瓶颈，运维效率已经难以适应业务的增长需求，自动化运维因此应运而生。通过预定义的规则脚本，执行重复性的日常运维工作，一来减少人为因素可能导致的失误；二来极大地提高了运维效率，减少人力成本。自动化运维时代出现了很多的运维工具，这些工具替代了原来某种需要人力手工完成的运维场景，同时对运维人员也提出了具备一定开发能力的要求。 自动化运维时代产生的工具如雨后春笋，但这些运维工具如豆腐块般零碎，有时甚至功能重叠，系统的使用门槛普遍比较高，工具的用户主要还是运维人员自身。DevOps的出现主要强调从价值交付的全局视角出发，端到端打通软件生命周期，强调横向的融合和打通，实现一站式的持续交付和持续集成。在这期间整合了很多功能相似的工具组合成一个运维平台，从产品设计的角度出发，减低用户的使用难度和费力度，同时将这些运维平台开放给更多的研发人员使用，提供一站式的交付申请和自助平台。 AIOps是继自动化运维和DevOps实践后的更高阶的运维实现，主张由机器学习算法自动地从海量运维数据中不断学习，提炼和总结规则。在自动化运维的基础上，增加了一个基于机器学习的大脑，对运维数据自动分析、决策，指挥自动化脚本去执行大脑的决策，从而达到运维系统的整体目标。 DevOps更多是指开发运维群体之间的一种办公合作模式，它不是一个部门、团队、工具的称呼，而是一种思维方式和开发运维工作理念，强调通过部门或组织之间更好的协同从而促进更加高效率、高质量地完成业务目标，所以DevOps更多的是一种文化。 而自动化运维和AIOps是一种具体的运维能力或工具。通过自动化运维和AIOps可以让工具在运维中产生更大的价值，从而更好地推动DevOps的落地效果。 前面提到从人工运维到自动化运维，再过渡到AIOps是一个自然发生的过程。自动化运维只是将人工运维的步骤通过代码实现自动化执行，来降低运维成本和风险，但并不具备自学习能力，所有的规则和动作都是写死的，并不会随着状态的变化而做出适应性改变。 而AIOps通过将人工智能算法代入运维，持续对数据进行分析，并且不断通过自学习来进行演化，能够对自己进行修正，从而可以不断地适应外界的变化。 DevOps更多的是一种文化，是从敏捷开发到快速交付和敏捷运维的延伸。DevOps和AIOps并不冲突，二者可以相辅相成，相得益彰，共同提升企业的开发和运维效率。 Q5：您认为AIOps下一步发展将会走向何方？会对哪些领域产生影响？ 目前我们更多的是在谈AIOps的一个个具体的点，解决的是具体服务的运维问题，很少从整体上去横向考虑整个机房和全局在线服务的成本、效率、稳定性相关，所以我认为未来的AIOps应该在局部优化到全局优化进行演进，而随着各行业推进AIOps，相信未来企业在IT方面的效率、成本、稳定性有非常大的提升，从而能够让企业IT机房、线上服务系统完成从人肉到无人值守的自我学习、自我提升，自愈的进化。 未来各行各业的企业注意力更聚焦，会更有资源和精力聚焦在如何提升服务水平和自身服务创新上。提供传统运维工具产品和平台的企业将消失，真正能够在原有运维系统平台之上赋予智能化运维能力的公司将会脱颖而出，并且成为时代的宠儿。 AIOps经过一年的发展，已经在一些单点的应用方面取得比较好的成果，接下来是结合具体的场景，在某些场景将这些单点成果串联起来，从发现问题、分析问题到最后解决问题，真正提高效率。 AIOps可能会对整个运维领域、AI领域产生一些影响，但是这都是后来的事情，AIOps还是需要脚踏实地，一步一个脚印地走下去。 运维的终极目标是无人值守的运维，彻底释放出人力资源。 如果把AIOps的实践内容比作手、眼和脑三个部分的联动，从行业现状看，目前比较成熟和通用实践的主要在于眼和脑，例如指标监控和智能告警分析；但大脑和手的联动从目前的实践场景和内容看并不是很普遍和通用，所以接下来AIOps主流的方向应该是朝着智能决策和自动执行方向发展，只有当系统可以自动发现问题、分析问题、并自动解决问题时，才有望实现运维无人值守的美好愿景。相信通过行业各方力量的不断贡献和推进，AIOps实现运维无人值守的目标终会到来。 AIOps的实践是对人工智能技术应用场景的重要丰富，其实践的经验来自各行各业无数运维人智慧的结晶，技术始终是为保障业务而服务的，技术的不断强大和发展反向作用于业务，从这个意义上讲，AIOps的成功，将会影响到各个领域。 AIOps的目标就是要尽可能地降低运维中人力的参与，提升运维的自动化、自管理能力，甚至达到无人值守的程度。 就目前阶段来说，对于AIOps的定义是在学历问题定位和分析这个层面，主要是在利用海量的数据，通过机器学习相关算法，快速发现异常点及利用相关数据的关系找到问题根因。 相信下一步，AIOps将会往更广义的方向发展，除了问题分析定位，包括组件关系的自动梳理画像、自动化的弹性容量管理、智能运营分析统计能力、智能化的资源交付、智能机器人管理等。 如果真的走到这一步并取得突破性进展，将会对整个企业的IT基础架构、研发体系、组织架构等产生深远的影响。 随着IT技术的持续进步，人工智能渐趋完善，AIOps也会不断前进。而且我认为AIOps的发展是有其第一推动力的，系统运维的规模越来越大，复杂度也趋于提升，大家都在谈建设生态圈，也意味着系统之间的依赖性越来越强，传统的人工运维甚至自动化运维无法解决，必须依赖AIOps。 这些在云计算上体现得尤其明显，因此我认为云计算和AIOps结合是必然的趋势。 云平台给AIOps提供了肥沃的土壤，可以让AIOps快速成长，例如标准化、规范化，海量的运维数据；反过来，AIOps也可以让云平台的优势更加明显，例如系统的可用性、稳定性，资源的合理充分利用，降低企业的运维成本。 在AIOps的协助下，未来的系统将会趋于自治化，这和自动驾驶技术的发展一个道理。从这点来看，AIOps带来的影响是深远的，IT技术的各个细分领域都会从AIOps中获益，包括数据库、存储、网络、计算等。我想不止依赖于这些组件的应用系统稳定性得以提高，还可以让我们不断对产品的功能和性能不断完善，从产品侧、从源头来改进。 至此，本次专访暂告一段落，如果大家对AIOps还有其他疑问，不妨在本文微信订阅号（dbaplus）评论区留言，我们会邀请专家进行解答~ 至于更多对AIOps的系统性答疑，请耐心等候下一篇专访的发布~
-
发表了文章 2022-02-12
历经外企、创业公司、大厂的程序员告诉你：第一份工作有多重要！
笔者毕业5年，先后经历了创业公司，外企和国内一线互联网公司。本文用经历告诉你，第一份工作对于你的重要性和怎么选择第一份工作。 笔者第一份工作去了外企，也正是因为去了外企让我学会了很多，也塑造了自己的编程习惯和工作方式，时至现在也未曾改变。其实公司就是学校，第一家公司对你的工作习惯的塑造很重要。因为是外企，公司的文化相对扁平，没有尔虞我诈也没有勾心斗角。举几个具体的公司特质说一下对笔者的职业习惯的塑造。 新人培训：这里的新人培训不同其他公司，它会有6个月试用期，这6个月会有一个老师专门负责你的成长，定期给你 Review 表现。同时每一个月所有和你接触过的人会去一个小黑屋说你“坏话”，然后通过你的老师转达给你，在6个月内改掉这些“坏毛病“。我通过6个月反复的改掉自己的坏毛病，慢慢塑造自己。 嗅觉和创新：这里形容的比较抽象，大概的意思是，圈子里面每次出现新技术、新思路公司总是第一个尝试的，而且公司愿意为技术买单。我印象最深的一次，当 Angular 2.0 刚出来的时候，项目组专门出了一个人用一个月时间把6年的 Angular 1.0 项目升级到 2.0，升级过程中遇到了很多问题，但是我们依然乐此不彼，而且升级完以后会第一时间和大家分享。对于一个新东西的嗅觉和采纳不是所有的团队和公司都可以接受的，这会让你把接纳和改进作为自己最重要的特质。 言论自由：在这里，如果你有不开心的，可以马上发一封邮件发送给全公司的人。CEO 如果觉得你的话题有意思也会回复你，而且你不需要顾虑会不会因此被开除，因为公司鼓励说出自己的想法，无论对错，我们拿出来讨论就是了。每个人都有自己的想法，接受别人的想法是学，让别人接受你的想法是一种包容，更是一种成长。 严于律己：在这里，每天都有 Code Review，如果你每一行代码没有推敲 10 分钟以上，没有查海量的资料确定它的正确性，那么每天6点的 Code Review 会让你狼狈不堪。每一天的代码都需要接受审判，也正是这个审判让你进步。如此一来重构，整洁代码便成了我的习惯。有争吵才会有结果，有批评才会有进步，有意识才会持续改变。 接下来笔者去了创业公司，思维发生了改变：时间就是金钱，可能一不留神对手就成功了，我们就失败了，所以留给我的只有 Coding 没有 Thinking。 时间就是生命：在这里，你没有时间思考自己的得失，因为对于创业者来说，如果晚于竞品发布，那样到达同样的体量的成本会变成先于对手的几倍，甚至几十倍。所以加班似乎变成了寻常的事情，需求变成了每天的家常便饭。记得创业最大的变化是原来6点就会下班去挤地铁，变成了总是9点以后等待免费的打车券。学而不思则罔，思而不学则殆。紧张的节奏压得你没有时间思考，也没有时间总结。你以为你做了很多，学了很多，但是你需要时间静下来思考和总结，这样最终才会变成自己的东西。 重要也不重要：你的重要因为你是团队的一份子，你需要用你的光和热鼓舞自己和影响别人，用你的力量去塑造公司的产品，公司的需要就是你的重要。如果你是来学习乐器的，抱歉，这里并不适合你。因为公司没有时间和经历花在培养一个人的身上，过多的是看到你的结果，而不是看到你的成长。所以你的个人成长显得又是那么苍白。然而事情并不是绝对的，创业的成功带来的回报远比你的个人成长带来的回报高得多，比如陌陌、映客的上市，对于那些初期加入的人来说是硕大的丰收——但是这需要你的慧眼。 坚持了一段时间创业以后，笔者发现公司不是另一个“陌陌”，于是选择了另一个行程：大厂。第一次加入国内的一线互联网公司还是有很多的不习惯，节奏、文化、压力扑面而来。 传承：大厂最重要的一个特质就是传承的购物文化，你进来以后会第一时间给你做至少一周的文化培训，让你了解公司的同时也会给你灌输思想。告诉你什么应该做，什么不该做，同时也会告诉你 N 多的规章制度。没有规矩不成方圆，但是规矩也会束缚一个人，限制你发散的思维，按照固有的方式去做事。举个例子，我是社招进入大厂的，进来以后开始使用集团的中间件，然而我会发现每一个中间件都是一个开源的升级版本，它实现了开源的功能同时做了改进，如果你是第一份工作，使用中间件会让你觉得理所当然，你也许只会感叹它的便捷性，而不是思考它的根源。 沉淀和成长：沉淀是大厂最宝贵的资源，海量的中间件、内部文献、骨灰级大佬都是你学习的资源。无论是业务还是技术，你都可以学到整个领域的精华，这就是大厂带给你的成长。外企小公司对于技术的沉淀是远远不如国内一线大厂的，这些经验不是你努力学习看书能得到的，周围的环境、整个团队的意识带给你的视野和成长是与众不同的。 压力与收获：大厂绝不会是你想的那样轻松，每一个人都很努力，每一个产品线也很努力，每一个 BU 也很努力，这会让你觉得，如果你歇歇，技术上业务上马上就会被超越，所以你必须时刻塑造自己。当然辛苦的努力也会有回报，因为大厂都不缺钱，所以如果你业绩足够好，你的回报也是相当可观。网传的经常看凌晨3点的太阳和LO*团队60个月的年终奖，不知道真假。可怕的不是别人比你聪明，而是比你聪明还比你努力。 与其说是总结不如说是心得：第一份工作对你的重要性。笔者没有更多的经历和你说其他公司的情况，只是罗列了自己的经历给大家，当然上面更多的是笔者自己的感受。所以对于找工作的你，则需要认真思考自己想要的究竟是什么？开放透明和悠然自得？高风险高回报？还是压力与荣耀并存？......
-
发表了文章 2022-02-10
新一代通用的Linux软件包管理工具
1. 前言 snap和flatpak都是新一代跨Linux发行版的软件包管理技术，这两种下一代打包方法在本质上拥有相同的目标和特点：即不依赖于第三方系统功能库的独立包装。上一篇我们简单介绍了flatpak的原理，今天我们接着简要介绍snap的安全机制。 2. 简介 snap是Canoncial公司提出的新一代linux包管理工具，致力于将所有linux发行版上的包格式统一，做到“一次打包，到处使用”。目前snap已经可以在包括Ubuntu、Fedora、Mint等多个Linux发行版上使用。首先我们来了解下snap相关的各种名词： 2.1 snap 新一代跨Linux发行版的软件包管理技术，支持各大主流Linux发行版，通过Linux内核安全机制保证用户数据安全，彻底解决包依赖关系相关问题，并大大简化应用软件的打包工序。snap同时为安装及管理snap包的命令行工具。 2.2 snapd 管理snap软件包的后台服务。 2.3 kernel snap 使用snap格式打包的内核，包含内核镜像及内核模块。 2.4 OS snap 使用snap格式重新打包的rootfs，包含了运行和管理snap的全日制统招基本资源，当你第一次安装snap时，OS snap 首先被安装。 2.5 snapcraft 将软件打包成snap格式的打包工具集。 2.6 snappy 原指完全基于snap构建的系统，此名称已弃用，现统一称为Ubuntu Core，即Ubuntu的全snap操作系统，有别于传统基于deb包的classic Ubuntu。 3. 安全策略 snap应用以沙箱的方式运行。系统通过一些机制限制应用访问资源的权限来实现其安全特性，比如通过对内核安全机制AppArmor，Seccomp等的配置实现的沙箱和snap文件系统等。开发者不必过多了解系统安全机制的细节。下面简要说明snap使用的部分安全策略。 3.1 Sandbox Linux Sandbox 是根据内核中支持的一些安全机制实现的进程访问控制方式。通常通过为进程分配随机uid，将进程置于chroot环境和为进程uid配置Capability等方式将进程置于严格受限的一种状态下。snap应用使用这种方式运行在系统为其分配的沙箱环境中。 3.2 security policy ID 每一个snap应用程序命令都有唯一的security policy ID，系统将此ID与命令绑定，由此可以为同一snap包内的不同程序配置不同的安全策略。作为系统识别命令的标示，当程序安装和运行时，系统会根据其Security Policy ID为其分配资源。在沙箱中运行的snap应用之间的通信控制也通过此ID来进行配置。 snap应用的security policy ID的命名规则为snap.namemand 例如，hello程序的security policy ID即为snap.hello.hello 3.3 snap文件系统 snap文件系统被划分为具有只读和读写两种不同权限的区域，每个snap应用有其独有的受限文件目录，如下图所示： 新一代通用的Linux软件包管理工具 snap文件系统 由此可见，一个snap应用具有写权限的目录是极其有限的，并且每个snap应用都有其独立的可写目录。snap文件系统对snap应用相关目录的权限配置说明，这种方式实现了应用与应用，应用与系统之间的隔离。 同时这种方式对snap应用的升级和回滚提供了很好的支持，升级时只需将确定版本的相关目录复制到更高版本的对应目录，而回退只需删除更高版本的目录。 3.4 AppArmor AppArmor是一个强制访问控制系统，在内核层面对进程可访问的资源进行控制。 在snap应用程序安装时，系统会为其中的每一个命令生成其特有的AppArmor配置文件。内核对可执行程序的Capability限制也可以通过Aparmor来配置。当执行应用程序中的命令时，AppArmor机制可保证此命令不会越权访问。 作为一种内核中的安全机制，在ubuntu classic系统中也同时支持AppArmor提供的机制。但与classic系统不同，snap系统对程序的访问控制更加严格，基本做到“只满足程序执行所需的最小权限”。 3.5 Seccomp Seccomp是一个内核接口访问过滤器，snap应用程序通过其独有的过滤器访问内核接口。在snap应用程序启动之前会自动配置过滤器。Seccomp在snap系统中的作用类似于AppArmor。都是控制应用程序对系统资源的访问。
-
发表了文章 2022-02-10
阿里开源：Dawn - 基于「中间件和 Pipeline」的自动化构建工具
Dawn 取「黎明、破晓」之意，原为「阿里云·业务运营团队」内部的前端构建和工程化工具，现已完全开源。它通过 pipeline 和 middleware 将开发过程抽象为相对固定的阶段和有限的操作，简化并统一了开发人员的日常构建与开发相关的工作。 采用中间件技术，封装常用功能，易于扩展，方便重用支持 pipeline 让多个 task 协同完成构建任务简单、一致的命令行接口，易于开发人员使用支持基于「中心服务」管理中间件和工程模板支持搭建私有中心服务，并统一下发构建规则，易于团队统一管理 依赖的环境、软件及其版本： Node.js v7.6.0 及以上版本Mac/Linux (Windows 基本支持未经严格测试) 安装或更新 Dawn: $ [sudo] npm install dawn -g 国内可以使用 cnpm 加速安装 $ dn init [template] [options] 示例： $ dn init ? Found 4 templates (Use arrow keys) ? 1. front : Blank front end project template 2. node : Blank node project template 3. middleware : Dawn middleware project template 4. react : Based on react-scripts, like create-react-app 选择一个工程类型，回车即可按向导初始化一个工程，还可以通过 -t 或 --template 直接按指定的模板名称，直接初始化工程。 比如，通过名为 front 的模板，初始化一个工程 $ dn init -t front $ dn dev 如果是一个「前端」工程通常会启动构建进程并监听文件的变化，通常，还会启动一个 Web Server，并自动打开浏览器。 $ dn test 在执行 test 的时候会先进行「语法检查」（通过 eslint），然后执行「单元测试」和「E2E 测试」。 $ dn build 执行构建任务，不同的工程类型的构建过程和结果可能不同，取决于初始化工程时使用的工程模板。 完成后，会在当前项目的根目录产生 build 目录，这是构建结果，当然，也可以指定为其它学历目录名称。 $ dn publish 可以通过 dn publish 命令发布代码和构建结果，不同的工程模板决定了最终发布位置，是否支持 publish 命令取决于选择的「工程模板」。 init/dev/build/test/publish 这几个命令可以直接作为「子命令」写在 dn 后边，对于其它名称的 pipeline 需要使用 run 命令 编辑 .dawn/pipe.yml 或 .dawn.yml demo: - name: shell script: - echo demo 可以通过如下方法执行 demo dn run demo Dawn是一个用于前端和nodejs的轻量级任务管理和构建工具。以上只是简单介绍和入门，详细的文档可以查看文中给出的文档地址！
-
发表了文章 2022-02-10
避开这些坑：面试问你为什么要离开上一家公司？你会怎么回答？
在进行社招面试时，有一个问题几乎是必问的：你为什么要离开上一家公司？ 其实这个问题主要是想试探一下你的核心诉求，并借此预估一下你在本公司工作的稳定性。常见的答案也无非就是这么几种：对薪酬不满意、干得不爽，或者是想换个环境。 我遇到过好几个初次跳槽的求职者给出的答案是：在原来的公司学不到技术。 一听到这个，我就不由得叹口气：今天这一小时又算是交代了，这人基本上没戏。因为根据我的经验，这句话如果由工作不满两年的人说出来，很大概率这是个不会学习不会感恩又特别爱抱怨的人。 避开这些坑：面试问你为什么要离开上一家公司？你会怎么回答？ 首先我不是HR，只是个前端工程师。为什么会给人面试，因为公司招的是做前端的程序员，公司就要求我去给求职者面试。 互联网公司发展迅猛，程序员之间的竞争力也是很大的。 程序员最重要的能力是什么？——学习力 互联网时代的技术来得快，去得更快。就像Flash这样曾经雄霸天下多年的技术，都有被人人唾弃的一天。如果没有足够强的学习能力，就无法跟上变化，被淘汰只是迟早的事。想想看，你苦心钻研多年引以为傲的技术，一夜之间就没有用武之地了，难免会有一种「身体被掏空」的感觉。 学习力强的程序员敢大胆地体验尝试新技术，他们的技术栈始终在保持不断地更新。他们能快速把握事物的本质，并判断出它能用来做什么，不能用来做什么。他们拥抱技术升级和革命，因为他们学习并掌握新技术的速度比其他人更快，所以他们永远不用担心失业。事实上，他们掌握的是驾驶和学习驾驶的技术，而不是驾驶XX牌汽车的技术。 而学习力差的程序员呢？为了继续停留在旧技术的舒适区，他们往往会抵制新技术的推广，甚至百般阻挠。因为那会使他们过去的经验统统无效，只能和后来者站在同一起跑线上。抱死一个框架好几年，脱离了框架啥都干不了的程序员实在太多了。事实上，这样的人不能驾驭技术，反而是被技术给奴役了。 避开这些坑：面试问你为什么要离开上一家公司？你会怎么回答？ 同样是自行车，为什么山地车比公路车更普及更流行？除了皮实耐用价格低外，主要是因为它的通过性好，什么泥地沙地都不在话下，上下马路牙子跟玩一样。而公路车呢？只能老老实实地跑在平路上。 公司不是学校 面对一些因为「想学点技术」而换工作的程序员们，说是不思进取貌似不太合适。但显然这样的思维模式还是被学校洗脑的那一套，没能真正地融入社会。那些人会认为，学习就是要由老师手把手带着，而自己之所以学不到技术，就是因为没遇到一个好leader，能替自己设计好成长路线，指出所有重难点，提供各种参考资料…… 在中国传统文化里，不管是匠人还是武师，收徒都要找毫无根基的幼童。这一方面是为了保持师父的绝对权威，方便贯彻落实教学；另一方面是为了尽量延长全日制证书获取时间，以考察徒弟的品性。拜师之后，徒弟便跟随师父一起生活，经过数年的言传身教，这才得以出师。 师父收徒的核心诉求，是传承自己的技艺和名声，希望徒弟日后能做出一番成就来光耀师门。这就要求徒弟流动性低、忠诚度高、归属感强。与其说是收徒，还不如说是在挑儿子，所以有句俗话叫作一日为师，终身为父。 然而公司是盈利性的商业组织，不是学校，更不是新手训练营。公司招聘员工的核心诉求，是生产出实实在在、对得起薪水的价值，而不是传承技艺。公司希望员工入职前就具备工作的能力，至少在经过短暂的培训和指导后就能独立开展工作，正所谓能干就干，干不了走人。 学习是自己的事，没有人能替你去做。这就跟吃饭一样，谁真的关心你吃没吃、饱没饱？就算你的亲人再怎么关心你，也不能替你去吃。我们都知道，人不吃饭肯定是要饿死的，那你为什么不去给自己找吃的，却在埋怨没有人给你嘴里喂食呢？ 避开这些坑：面试问你为什么要离开上一家公司？你会怎么回答？ 为什么你学不到技术？ 很多人在学习之路上已经饱尝了痛苦的滋味，因此在离开学校之后。他们不到万不得已，是决然不会去学习的。你不妨回顾一下，从参加工作以来到现在，自己哪段时间里学习最认真，进步最明显？ 如果不出意外的话，应该就是你找到的第一份工作的试用期。因为不想失去自己通过努力争取到的工作机会，所以你不得不逼自己打起十二份精神来学习，结果居然以自己都无法想象的速度掌握了工作必备的知识和技能。 然而，大多数人在自己的能力满足当前工作的要求之后，就丧失了学习的动力。下班之后要追剧，要玩游戏，要打球，要谈恋爱……为啥我要学习？不学又不会失业！学这个有啥用？谁知道用得上用不上？等要用的时候再学呗！ 其实，学不到技术最核心的原因只有一个：动机不足。 至于环境条件，只是影响学习效果的因素之一，但绝对不是最重要的因素。在一个恶劣的环境里选择放弃学习的人，不可能到了一个优越的环境里就会去主动学习，因为在他内心深处对学习是抗拒的。 在我看来，学习力的源泉就是好奇心，也就是对新知识的渴求，以及对探索未知的冲动。我们的大脑是用进废退的，如果不定期给它输送新鲜的知识营养，它就会逐渐退化。有学习力的人一段时间不看书，不折腾点新玩意，大脑真的是会饿的。 程序员该怎么学习技术？ 有的程序员觉得自己没学到技术，是因为公司不给机会，或者缺乏条件： 上次的H5让小王做了，这次的微信小程序又给了小李……完全没我什么事啊！ 引用块内容 学习技术最有效的方式是阅读、实践和交流 公司没给你安排这方面的工作，那你自己都做了些什么呢？八小时之外的时间都用在哪了？有没有读源码？有没有看原版书？有没有泡技术社区？有没有尝试最新流行的技术？有没有尝试把它们用在公司的项目上？有没有主动去接触行业里使用这些技术的团队和大牛？ 看文档其实是最快的学习方法。对于自己工作中常用到的技术，抽时间把官方文档通读一遍（其实篇幅都不大），绝对收获满满。没事的时候多翻翻自己使用的框架/系统/平台的API，看看有哪些自己不知道或者没用过的功能，想想这个功能可以用来做什么，能不能解决现存的问题，或者优化当下的解决方案。 如果你像我一样是个前端工程师，通读HTTP协议和ECMAScript标准，就能秒杀95%的同行，不开玩笑。 读源码是深入学习开源技术的唯一途径。只有理解了某个功能在底层是如何实现的，你才能真正把握它更适合用来做什么，不能用来做什么。正如不明白汽车的构造和原理，我们也能把车开好。而如果多少知道一点，开起来就会更得心应手。当车出现问题时，也不至于完全束手无策，只能蹲在路边等待救援。 你一个框架用了N年了，却连一行源码都没读过？如果它是你女朋友，估计早该分手了。 折腾是学习任何技术的必经之路。在有保护的环境下进行大量的试错，是最高效的学习方法。现在虚拟机技术已经那么成熟，VPS也很便宜，你为什么不分分钟弄一个，然后在上面花式作死呢？ 听说过无数次 rm -rf / 的事故，可你居然一次都没试过？知道输出啥样子么？ 避开这些坑：面试问你为什么要离开上一家公司？你会怎么回答？ 公司给你提供的最有价值的东西，就是实战的机会。 你所学习的技术，最终需要通过工作来变现。你有机会接触到真实的数据，了解真实的用户，观察真实系统是怎样运转的，积累真实的经验…… 然而，所谓的机会，只属于已经提前准备好的人。 不要等到工作都安排到你身上了再去学习。公司不是你的试验田，你也不该拿用户当小白鼠。公司不给你机会，那只说明你还没有准备好。 很多初入职场的程序员意识不到自己缺乏自我学习的能力，反而去责怪公司没有让他们学到东西。这种对原公司给予宝贵的实战和成长机会不知感恩，只知抱怨的态度，是令我很反感的。要知道，公司对你的个人成长并没有责任和义务，因为学习是你自己的事。 技术世界就如同一片汪洋大海，细分领域真是多如牛毛。我们只是站在其中一个小岛上，怎么确定自己该朝哪个方向进发呢？ 学习技术不外乎以下两个方向： 1、广度：整个使用链条由哪些环节构成？每个环节的作用是什么？都有哪些类似的可替代方案？它们之间有什么区别？各自优劣点是什么？…… 2、深度：这个技术 / 产品的本质是什么？都能做什么？运作原理是什么？底层是如何实现的？可以做怎样的改进？…… 不管你在做什么工作，都应该先把自己每天都要用的核心技术做到一定深度，再去拓展广度。 什么都知道一点，但都不甚了解是最可怕的，它会让你误以为自己已经很NB了。 学习，是一辈子的事。
-
发表了文章 2022-02-10
大数据小白如何入门？大数据领域75个核心术语讲解全盘奉上
本文约8420字，建议阅读17分钟。本文介绍Ramesh Dontha 在 DataConomy 上连发两篇文章，扼要而全面地介绍了关于大数据的 75 个核心术语。 近日，Ramesh Dontha 在 DataConomy 上连发两篇文章，扼要而全面地介绍了关于大数据的 75 个核心术语，这不仅是大数据初学者很好的入门资料，对于高阶从业人员也可以起到查漏补缺的作用。本文分为上篇（25 个术语）和下篇（50 个术语）。 如果你刚接触大数据，你可能会觉得这个领域很难以理解，无从下手。不过，你可以从下面这份包含了 25 个大数据术语的清单入手，那么我们开始吧。 算法（Algorithm）：算法可以理解成一种数学公式或用于进行数据分析的统计学过程。那么，「算法」又是何以与大数据扯上关系的呢？要知道，尽管算法这个词是一个统称，但是在这个流行大数据分析的时代，算法也经常被提及且变得越发流行。 分析（Analytics）：让我们试想一个很可能发生的情况，你的信用卡公司给你发了封记录着你全年卡内资金转账情况的邮件，如果这个时候你拿着这张单子，开始认真研究你在食品、衣物、娱乐等方面消费情况的百分比会怎样？你正在进行分析工作，你在从你原始的数据（这些数据可以帮助你为来年自己的消费情况作出决定）中挖掘有用的信息。那么，如果你以类似的方法在推特和脸书上对整个城市人们发的帖子进行处理会如何呢？在这种情况下，我们就可以称之为大数据分析。所谓大数据分析，就是对大量数据进行推理并从中道出有用的信息。以下有三种不同类型的分析方法，现在我们来对它们分别进行梳理。 描述性分析法（Descriptive Analytics）：如果你只说出自己去年信用卡消费情况为：食品方面 25%、衣物方面 35%、娱乐方面 20%、剩下 20% 为杂项开支，那么这种分析方法被称为描述性分析法。当然，你也可以找出更多细节。 预测性分析法（Predictive Analytics）：如果你对过去 5 年信用卡消费的历史进行了分析，发现每年的消费情况基本上呈现一个连续变化的趋势，那么在这种情况下你就可以高概率预测出：来年的消费状态应该和以往是类似的。这不是说我们在预测未来，而是应该理解为，我们在「用概率预测」可能发生什么事情。在大数据的预测分析中，数据科学家可能会使用先进的技术，如机器学习，和先进的统计学处理方法（这部分后面我们会谈到）来预测天气情况、经济变化等等。 规范性分析（Prescriptive Analytics）：这里我们还是用信用卡转账的例子来理解。假如你想找出自己的哪类消费（如食品、娱乐、衣物等等）可以对整体消费产生巨大影响，那么基于预测性分析（Predictive Analytics）的规范性分析法通过引入「动态指标（action）」（如减少食品或衣物或娱乐）以及对由此产生的结果进行分析来规定一个可以降低你整体开销的最佳消费项。你可以将它延伸到大数据领域，并想象一个负责人是如何通过观察他面前多种动态指标的影响，进而作出所谓由「数据驱动」的决策的。 批处理（Batch processing）：尽管批量数据处理从大型机（mainframe）时代就已经存在了，但是在处理大量数据的大数据时代面前，批处理获得了更重要的意义。批量数据处理是一种处理大量数据（如在一段时间内收集到的一堆交易数据）的有效方法。分布式计算（Hadoop），后面会讨论，就是一种专门处理批量数据的方法。 Cassandra：是一个很流行的开源数据管理系统，由 Apache Software Foundation 开发并运营。Apache 掌握了很多大数据处理技术，Cassandra 就是他们专门设计用于在分布式服务器之间处理大量数据的系统。 云计算（Cloud computing）：虽然云计算这个词现在已经家喻户晓，这里大可不必赘述，但是为了全篇内容完整性的考虑，笔者还是在这里加入了云计算词条。本质上讲，软件或数据在远程服务器上进行处理，并且这些资源可以在网络上任何地方被访问，那么它就可被称为云计算。 集群计算（Cluster computing）：这是一个来描述使用多个服务器丰富资源的一个集群（cluster）的计算的形象化术语。更技术层面的理解是，在集群处理的语境下，我们可能会讨论节点（node）、集群管理层（cluster management layer）、负载平衡（load balancing）和并行处理（parallel processing）等等。 暗数据（Dark data）：这是一个生造词，在笔者看来，它是用来吓唬人，让高级管理听上去晦涩难懂的。基本而言，所谓暗数据指的是，那些公司积累和处理的实际上完全用不到的所有数据，从这个意义上来说我们称它们为「暗」的数据，它们有可能根本不会被分析。这些数据可以是社交网络中的信息，电话中心的记录，会议记录等等。很多估计认为所有公司的数据中有 60% 到 90% 不等可能是暗数据，但实际上没人知道。 数据湖（Data lake）：当笔者第一次听到这个词时，真的以为这是个愚人节笑话。但是它真的是一个术语。所以一个数据湖（data lake）即一个以大量原始格式保存了公司级别的数据知识库。这里我们介绍一下数据仓库（Data warehouse）。数据仓库是一个与这里提到的数据湖类似的概念，但不同的是，它保存的是经过清理和并且其它资源整合后的结构化数据。数据仓库经常被用于通用数据（但不一定如此）。一般认为，一个数据湖可以让人更方便地接触到那些你真正需要的数据，此外，你也可以更方便地处理、有效地使用它们。 数据挖掘（Data mining）：数据挖掘关乎如下过程，从一大群数据中以复杂的模式识别技巧找出有意义的模式，并且得到相关洞见。它与前文所述的「分析」息息相关，在数据挖掘中，你将会先对数据进行挖掘，然后对这些得到的结果进行分析。为了得到有意义的模式（pattern），数据挖掘人员会使用到统计学（一种经典的旧方法）、机器学习算法和人工智能。 数据科学家：数据科学家是时下非常性感的一门行业。它指那些可以通过提取原始数据（这就是我们前面所谓的数据湖）进而理解、处理并得出洞见的这样一批人。部分数据科学家必备的技能可以说只有超人才有：分析能力、统计学、计算机科学、创造力、讲故事能力以及理解商业背景的能力。难怪这帮人工资很高。 分布式文件系统（Distributed File System）：大数据数量太大，不能存储在一个单独的系统中，分布式文件系统是一个能够把大量数据存储在多个存储设备上的文件系统，它能够减少存储大量数据的成本和复杂度。 ETL：ETL 代表提取、转换和加载。它指的是这一个过程：「提取」原始数据，通过清洗/丰富的手段，把数据「转换」为「适合使用」的形式，并且将其「加载」到合适的库中供系统使用。即使 ETL 源自数据仓库，但是这个过程在获取数据的时候也在被使用，例如，在大数据系统中从外部源获得数据。 Hadoop：当人们思考大数据的时候，他们会立即想到 Hadoop。Hadoop 是一个开源软件架构（logo 是一头可爱的大象），它由 Hadoop 分布式文件系统（HDFS）构成，它允许使用分布式硬件对大数据进行存储、抽象和分析。如果你真的想让某人对这个东西印象深刻，你可以跟他说 YARN(Yet Another Resource Scheduler)，顾名思义，就是另一个资源调度器。我确实被提出这些名字的人深深震撼了。提出 Hadoop 的 Apache 基金会，还负责 Pig、Hive 以及 Spark（这都是一些软件的名字）。你没有被这些名字惊艳到吗？ 内存计算（In-memory computing）：通常认为，任何不涉及到 I/O 访问的计算都会更快一些。内存计算就是这样的技术，它把所有的工作数据集都移动到集群的集体内存中，避免了在计算过程中向磁盘写入中间结果。Apache Spark 就是一个内存计算的系统，它相对 Mapreduce 这类 I/O 绑定的系统具有很大的优势。 物联网（IoT）：最新的流行语就是物联网（IoT）。IoT 是嵌入式对象中（如传感器、可穿戴设备、车、冰箱等等）的计算设备通过英特网的互联，它们能够收发数据。物联网生成了海量的数据，带来了很多大数据分析的机遇。 机器学习（Machine Learning）：机器学习是基于喂入的数据去设计能够学习、调整和提升的系统的一种方法。使用设定的预测和统计算法，它们持续地逼近「正确的」行为和想法，随着更多的数据被输入到系统，它们能够进一步提升。 MapReduce：MapReduce 可能有点难以理解，我试着解释一下吧。MapReduceMapReduce 是一个编程模型，最好的理解就是要注意到 Map 和 Reduce 是两个不同的过程。在 MapReduce 中，程序模型首先将大数据集分割成一些小块（这些小块拿技术术语来讲叫做「元组」，但是我描述的时候会尽量避免晦涩的技术术语），然后这些小块会被分发给不同位置上的不同计算机（也就是说之前描述过的集群），这在 Map 过程是必须的。然后模型会收集每个计算结果，并且将它们「reduce」成一个部分。MapReduce 的数据处理模型和 Hadoop 分布式文件系统是分不开的。 非关系型数据库（NoSQL）：这个词听起来几乎就是「SQL，结构化查询语言」的反义词，SQL 是传统的关系型数据管理系统（RDBMS）必需的，但是 NOSQL 实际上指的是「不止 SQL」。NoSQL 实际上指的是那些被设计来处理没有结构（或者没有「schema」，纲要）的大量数据的数据库管理系统。NoSQL 适合大数据系统，因为大规模的非结构化数据库需要 NoSQL 的这种灵活性和分布式优先的特点。 R 语言：这还有人能给一个编程语言起一个更加糟糕的名字吗？R 语言就是这样的语言。不过，R 语言是一个在统计工作中工作得很好的语言。如果你不知道 R 语言，别说你是数据科学家。因为 R 语言是数据科学中最流行的编程语言之一。 Spark（Apache Spark）：Apache Spark 是一个快速的内存数据处理引擎，它能够有效地执行那些需要迭代访问数据库的流处理、机器学习以及 SQL 负载。Spark 通常会比我们前面讨论过的 MapReduce 快好多。 流处理（Stream processing）：流处理被设计来用于持续地进行流数据的处理。与流分析技术（指的是能够持续地计算数值和统计分析的能力）结合起来，流处理方法特别能够针对大规模数据的实时处理。 结构化 vs 非结构化数据（Structured v Unstructured Data）：这是大数据中的对比之一。结构化数据基本上是那些能够被放在关系型数据库中的任何数据，以这种方式组织的数据可以与其他数据通过表格来关联。非结构化数据是指任何不能够被放在关系型数据库中的数据，例如邮件信息、社交媒体上的状态，以及人类语音等等。 这篇文章是上篇文章的延续，由于上篇反响热烈，我决定多介绍 50 个相关术语。下面来对上篇文章涵盖的术语做个简短的回顾：算法，分析，描述性分析，预处理分析，预测分析，批处理，Cassandra（一个大规模分布式数据存储系统），云计算，集群计算，暗数据，数据湖，数据挖掘，数据科学家，分布式文件系统，ETL，Hadoop（一个开发和运行处理大规模数据的软件平台），内存计算，物联网，机器学习，Mapreduce（hadoop 的核心组件之一），NoSQL（非关系型的数据库），R，Spark（计算引擎），流处理，结构化 vs 非结构化数据。 我们接下来继续了解另外 50 个大数据术语。 Apache：软件基金会（ASF）提供了许多大数据的开源项目，目前有 350 多个。解释完这些项目需要耗费大量时间，所以我只挑选解释了一些流行术语。 Apache Kafka：命名于捷克作家卡夫卡，用于构建实时数据管道和流媒体应用。它如此流行的原因在于能够以容错的方式存储、管理和处理数据流，据说还非常「快速」。鉴于社交网络环境大量涉及数据流的处理，卡夫卡目前非常受欢迎。 Apache Mahout：Mahout 提供了一个用于机器学习和数据挖掘的预制算法库，也可用作创建更多算法的环境。换句话说，机器学习极客的最佳环境。 Apache Oozie：在任何编程环境中，你都需要一些工作流系统通过预定义的方式和定义的依赖关系，安排和运行工作。Oozie 为 pig、MapReduce 以及 Hive 等语言编写的大数据工作所提供正是这个。 Apache Drill, Apache Impala, Apache Spark SQL：这三个开源项目都提供快速和交互式的 SQL，如与 Apache Hadoop 数据的交互。如果你已经知道 SQL 并处理以大数据格式存储的数据（即 HBase 或 HDFS），这些功能将非常有用。抱歉，这里说的有点奇怪。 Apache Hive：知道 SQL 吗？如果知道那你就很好上手 Hive 了。Hive 有助于使用 SQL 读取、写入和管理驻留在分布式存储中的大型数据集。 Apache Pig：Pig 是在大型分布式数据集上创建、查询、执行例程的平台。所使用的脚本语言叫做 Pig Latin（我绝对不是瞎说，相信我）。据说 Pig 很容易理解和学习。但是我很怀疑有多少是可以学习的？ Apache Sqoop：一个用于将数据从 Hadoop 转移到非 Hadoop 数据存储（如数据仓库和关系数据库）的工具。 Apache Storm：一个免费开源的实时分布式计算系统。它使得使用 Hadoop 进行批处理的同时可以更容易地处理非结构化数据。 人工智能（AI）：为什么 AI 出现在这里？你可能会问，这不是一个单独的领域吗？所有这些技术发展趋势紧密相连，所以我们最好静下心来继续学习，对吧？AI 以软硬件结合的方式开发智能机器和软件，这种硬件和软件的结合能够感知本科证书环境并在需要时采取必要的行动，不断从这些行动中学习。是不是听起来很像机器学习？跟我一起「困惑」吧。 行为分析（Behavioral Analytics）：你有没有想过谷歌是如何为你需要的产品/服务提供广告的？行为分析侧重于理解消费者和应用程序所做的事情，以及如何与为什么它们以某种方式起作用。这涉及了解我们的上网模式，社交媒体互动行为，以及我们的网上购物活动（购物车等），连接这些无关的数据点，并试图预测结果。举一个例子，在我找到一家酒店并清空购物车后，我收到了度假村假期线路的电话。我还要说多点吗？ Brontobytes：1 后面 27 个零，这是未来数字世界存储单位的大小。而我们在这里，来谈谈 Terabyte、Petabyte、Exabyte、Zetabyte、Yottabyte 和 Brontobyte。你一定要读这篇文章才能深入了解这些术语。 商业智能（Business Intelligence）：我将重用 Gartner 对 BI 的定义，因为它解释的很好。商业智能是一个总称，包括应用程序、基础设施、工具以及最佳实践，它可以访问和分析信息，从而改善和优化决策及绩效。 生物测定学（Biometrics）：这是一项 James Bondish 技术与分析技术相结合的通过人体的一种或多种物理特征来识别人的技术，如面部识别，虹膜识别，指纹识别等。 点击流分析（Clickstream analytics）：用于分析用户在网络上浏览时的在线点击数据。有没有想过即使在切换网站时，为什么某些谷歌广告还是阴魂不散？因为谷歌大佬知道你在点击什么。 聚类分析（Cluster Analysis）：是一个试图识别数据结构的探索性分析，也称为分割分析或分类分析。更具体地说，它试图确定案例的同质组（homogenous groups），即观察、参与者、受访者。如果分组以前未知，则使用聚类分析来识别案例组。因为它是探索性的，确实对依赖变量和独立变量进行了区分。SPSS 提供的不同的聚类分析方法可以处理二进制、标称、序数和规模（区间或比率）数据。 比较分析（Comparative Analytics）：因为大数据的关键就在于分析，所以本文中我将深入讲解分析的意义。顾名思义，比较分析是使用诸如模式分析、过滤和决策树分析等统计技术来比较多个进程、数据集或其他对象。我知道它涉及的技术越来越少，但是我仍无法完全避免使用术语。比较分析可用于医疗保健领域，通过比较大量的医疗记录、文件、图像等，给出更有效和更准确的医疗诊断。 关联分析（Connection Analytics）：你一定看到了像图表一样的蜘蛛网将人与主题连接起来，从而确定特定主题的影响者。关联分析分析可以帮助发现人们、产品、网络之中的系统，甚至是数据与多个网络结合之间的相关连接和影响。 数据分析师（Data Analyst）：数据分析师是一个非常重要和受欢迎的工作，除了准备报告之外，它还负责收集、编辑和分析数据。我会写一篇更详细的关于数据分析师的文章。 数据清洗（Data Cleansing）：顾名思义，数据清洗涉及到检测并更正或者删除数据库中不准确的数据或记录，然后记住「脏数据」。借助于自动化或者人工工具和算法，数据分析师能够更正并进一步丰富数据，以提高数据质量。请记住，脏数据会导致错误的分析和糟糕的决策。 数据即服务（DaaS）：我们有软件即服务（SaaS）, 平台即服务（PaaS），现在我们又有 DaaS，它的意思是：数据即服务。通过给用户提供按需访问的云端数据，DaaS 提供商能够帮助我们快速地得到高质量的数据。 数据虚拟化（Data virtualization）：这是一种数据管理方法，它允许某个应用在不知道技术细节（如数据存放在何处，以什么格式）的情况下能够抽取并操作数据。例如，社交网络利用这个方法来存储我们的照片。 脏数据（Dirty Data）：既然大数据这么吸引人，那么人们也开始给数据加上其他的形容词来形成新的术语，例如黑数据（dark data）、脏数据（dirty data）、小数据（small data），以及现在的智能数据（smart data）。脏数据就是不干净的数据，换言之，就是不准确的、重复的以及不一致的数据。显然，你不会想着和脏数据搅在一起。所以，尽快地修正它。 模糊逻辑（Fuzzy logic）：我们有多少次对一件事情是确定的，例如 100% 正确？很稀少！我们的大脑将数据聚合成部分的事实，这些事实进一步被抽象为某种能够决定我们决策的阈值。模糊逻辑是一种这样的计算方式，与像布尔代数等等中的「0」和「1」相反，它旨在通过渐渐消除部分事实来模仿人脑。 游戏化（Gamification）：在一个典型的游戏中，你会有一个类似于分数一样的元素与别人竞争，并且还有明确的游戏规则。大数据中的游戏化就是使用这些概念来收集、分析数据或者激发玩家。 图数据库（Graph Databases）：图数据使用节点和边这样的概念来代表人和业务以及他们之间的关系，以挖掘社交媒体中的数据。是否曾经惊叹过亚马逊在你买一件产品的时候告诉你的关于别人在买什么的信息？对，这就是图数据库。 Hadoop 用户体验（Hadoop User Experience ／Hue）：Hue 是一个能够让使用 Apache Hadoop 变得更加容易的开源接口。它是一款基于 web 的应用；它有一款分布式文件系统的文件浏览器；它有用于 MapReduce 的任务设计；它有能够调度工作流的框架 Oozie；它有一个 shell、一个 Impala、一个 Hive UI 以及一组 Hadoop API。 高性能分析应用（HANA）：这是 SAP 公司为大数据传输和分析设计的一个软硬件内存平台。 HBase: 一个分布式的面向列的数据库。它使用 HDFS 作为其底层存储，既支持利用 MapReduce 进行的批量计算，也支持利用事物交互的批量计算。 负载均衡（Load balancing）：为了实现最佳的结果和对系统的利用，将负载分发给多个计算机或者服务器。 元数据（Metadata）：元数据就是能够描述其他数据的数据。元数据总结了数据的基本信息，这使得查找和使用特定的数据实例变得更加容易。例如，作者、数据的创建日期、修改日期以及大小，这几项是基本的文档元数据。除了文档文件之外，元数据还被用于图像、视频、电子表格和网页。 MongoDB：MongoDB 是一个面向文本数据模型的跨平台开源数据库，而不是传统的基于表格的关系数据库。这种数据库结构的主要设计目的是让结构化数据和非结构化数据在特定类型应用的整合更快、更容易。 Mashup：幸运的是，这个术语和我们在日常生活中使用的「mashup」一词有着相近的含义，就是混搭的意思。实质上，mashup 是一个将不同的数据集合并到一个单独应用中的方法（例如：将房地产数据与地理位置数据、人口数据结合起来）。这确实能够让可视化变得很酷。 多维数据库（Multi-Dimensional Databases）：这是一个为了数据在线分析处理（OLAP）和数据仓库优化而来的数据库。如果你不知道数据仓库是什么，我可以解释一下，数据仓库不是别的什么东西，它只是对多个数据源的数据做了集中存储。 多值数据库（MultiValue Databases）：多值数据库是一种非关系型数据库，它能够直接理解三维数据，这对直接操作 HTML 和 XML 字符串是很好的。 自然语言处理（Natural Language Processing）：自然语言处理是被设计来让计算机更加准确地理解人类日常语言的软件算法，能够让人类更加自然、更加有效地和计算机交互。 神经网络（Neural Network）：根据这个描述（neuralnetworksanddeeplearning/），神经网络是一个受生物学启发的非常漂亮的编程范式，它能够让计算机从观察到的数据中学习。已经好久没有一个人会说一个编程范式很漂亮了。实际上，神经网络就是受现实生活中脑生物学启发的模型....... 与神经网络紧密关联的一个术语就是深度学习。深度学习是神经网络中一系列学习技术的集合。 模式识别（Pattern Recognition）：当算法需要在大规模数据集或者在不同的数据集上确定回归或者规律的时候，就出现了模式识别。它与机器学习和数据挖掘紧密相连，甚至被认为是后两者的代名词。这种可见性可以帮助研究者发现一些深刻的规律或者得到一些可能被认为很荒谬的结论。 射频识别（Radio Frequency Identification／RFID）：射频识别是一类使用非接触性无线射频电磁场来传输数据的传感器。随着物联网的发展，RFID 标签能够被嵌入到任何可能的「东西里面」，这能够生成很多需要被分析的数据。欢迎来到数据世界。 软件即服务（SaaS）：软件即服务让服务提供商把应用托管在互联网上。SaaS 提供商在云端提供服务。 半结构化数据（Semi-structured data）：半结构化数据指的是那些没有以传统的方法进行格式化的数据，例如那些与传统数据库相关的数据域或者常用的数据模型。半结构化数据也不是完全原始的数据或者完全非结构化的数据，它可能会包含一些数据表、标签或者其他的结构元素。半结构化数据的例子有图、表、XML 文档以及电子邮件。半结构化数据在万维网上十分流行，在面向对象数据库中经常能够被找到。 情感分析（Sentiment Analysis）：情感分析涉及到了对消费者在社交媒体、顾客代表电话访谈和调查中存在的多种类型的交互和文档中所表达的情感、情绪和意见的捕捉、追踪和分析。文本分析和自然语言处理是情感分析过程中的典型技术。情感分析的目标就是要辨别或评价针对一个公司、产品、服务、人或者时间所持有的态度或者情感。 空间分析（Spatial analysis）：空间分析指的是对空间数据作出分析，以识别或者理解分布在几何空间中的数据的模式和规律，这类数据有几何数据和拓扑数据。 流处理（Stream processing）：流处理被设计用来对「流数据」进行实时的「连续」查询和处理。为了对大量的流数据以很快的速度持续地进行实时的数值计算和统计分析，社交网络上的流数据对流处理的需求很明确。 智能数据（Smart Data）：是经过一些算法处理之后有用并且可操作的数据。 Terabyte：这是一个相对大的数字数据单位，1TB 等于 1000GB。据估计，10TB 能够容纳美国国会图书馆的所有印刷品，而 1TB 则能够容纳整个百科全书 Encyclopedia Brittanica。 可视化（Visualization）：有了合理的可视化之后，原始数据就能够使用了。当然这里的可视化并不止简单的图表。而是能够包含数据的很多变量的同时还具有可读性和可理解性的复杂图表。 Yottabytes：接近 1000 Zettabytes，或者 2500 万亿张 DVD。现在所有的数字存储大概是 1 Yottabyte，而且这个数字每 18 个月会翻一番。 Zettabytes：接近 1000 Exabytes，或者 10 亿 Terabytes。 编辑：晏斓辉 ——END——
-
发表了文章 2022-02-10
总结OLAP系统核心技术点，每一点都值得单独收藏
OLAP系统广泛应用于BI、Reporting、Ad-hoc、ETL数仓分析等场景，本文主要从体系化的角度来分析OLAP系统的核心技术点，从业界已有的OLAP中萃取其共性，分为谈存储，谈计算，谈优化器，谈趋势4个章节。 一、谈存储 1、列存的数据组织形式 行存，可以看做NSM (N-ary Storage Model)组织形式，一直伴随着关系型数据库，对于OLTP场景友好，例如innodb[1]的B+树聚簇索引，每个Page中包含若干排序好的行，可以很好的支持tuple-at-a-time式的点查以及更新等。 而列存（Column-oriented Storage），经历了早期的DSM（Decomposition Storage Model）[2]，以及后来提出的 PAX (Partition Attributes Cross) 尝试混合NSM和DSM，在C-Store论文[3]后逐渐被人熟知，用于OLAP，分析型不同于交易场景，存储IO往往是瓶颈，而列存可以只读取需要的列，跳过无用数据，避免IO放大，同质数据存储更紧凑，编码压缩友好，这些优势可以减少IO，进而提高性能。 2、编码与压缩 对于基本类型，例如数值、string等，列存可以使用合适的编码，减少数据体积，在C-Store论文中对于是否排序、NDV（Number of Distince Values）区分度，这4种排列组合，给出了一些方案，例如数值类型，无序且NDV小的，转成bitmap，然后bit-packing编码。 其他场景的编码还有varint、delta、RLE（Run Length Encoding）、字符串字典编码（Dictionary Encoding）等，这些轻量级的编码技术仅需要多付出一些CPU，就可以节省不小的IO。 对于复杂类型，嵌套类型的可以使用Google Dremel论文[4]提出Striping/Assembly算法（开源Parquet），使用Definition Level+Repetition Level做编解码。 一些数值类型有时也可以尝试大一统的用bitshuffle[14]做转换，配合压缩效果也不错，例如KUDU[7]和百度Palo（Doris）中有应用。在编码基础上，还可以进行传统的压缩，例如lz4、snappy、zstd、zlib等，一般发现压缩率不理想时可以不启用。 一些其他的选项，包括HBase，实际存储的是纯二进制，仅支持Column Family，实际不是columnar format，一些序列化框架和Hadoop融合比较好的，例如Avro，也不是列式存储。 3、存储格式 现代的OLAP往往采用行列混存的方案，采用Data Block + Header/Footer的文件结构，例如Parquet、ORC，Data Block使用Row Group（Parquet的叫法，ORC叫做Stripe）-> Column Chunk -> Page 三层级。 每一层又有metadata，Row Group meta包含row count，解决暴力count(*)，Column Chunk meta包含max、min、sum、count、distinct count、average length等，还有字典编码，解决列剪枝，并且提供基础信息给优化器，Page meta同样可以包含max、min等，跳页用于加速计算。 4、存储索引 在Parquet、ORC中，除了列meta信息外，不提供其他索引，在其他存储上，支持了更丰富的索引，索引可以做单独的块（Index Block），或者形成独立的文件。 例如阿里云ADB[5]，对于cardinality较小的，可以做bitmap索引，多个条件下推使用and/or。倒排索引也是可选的，需要在空间和性能上有所折中，还可以支持全文检索。Bloom Filter可以按照page粒度做很多组，加速"in", "="查询，快速做page剪枝。 另外，假设数据按照某个列或者某几个列是有序的，这样可以减少数据随机性，好处在于相似的数据对编码压缩有利，而且可以基于Row Group、Column Chunk、Page的meta做有效的过滤剪枝，有序列可以使用B-Tree、Masstree[6]（例如KUDU[7]），或者借鉴LevelDB的思想，在Index Block内对有序列做稀疏索引，方便二分查找，Index Block可以用LRU Cache尽量常驻内存，这样有利于按照排序列做点查（point query）和顺序扫描的范围查询（range query）。 另外其他列也可以做稀疏有序索引。有序列如果是唯一，可以看做OLTP中主键的概念。 5、分布式存储 DAC（Divide And Conquer）在分布式领域也是屡试不爽，要突破单机存储大小和IO限制，就需要把一个文件划分为若干小分片（sharding），以某个列做round-robin、constant、random、range、hash等，分布在不同的文件或者机器，形成分布式存储。 第一类，存储计算一体的架构，基于单机磁盘（SATA、SSD、NVM），例如Greenpulm基于PostgreSQL，还有ClickHouse、百度Palo（Doris）等，是share nothing架构，可实现多副本，扩容需要reshard往往比较耗时。 第二类，存储计算分离，文件存在分布式存储（GFS、HDFS）或者对象存储（S3、OSS、GCS），是share everthing（share storage）架构，好处在于扩展性和可用性的提高，由于存储网络延迟，所以一般都做批量、追加写，而非随机写，这把双刃剑也加大了OLAP在实时更新上难度，所以很多都放弃了实时写和ACID能力。 存储计算分离的架构上，例如文件如果存在HDFS上，每个分片是一个HDFS block（例如128MB大小），便于高吞吐大块IO顺序读，一个Row Group大小等于block size，便于上层计算引擎例如Spark SQL作业并行计算。 存储计算一体架构，可以更专心的设计文件和分片管理系统，采用Centralized Master + 多个Tablet架构，例如KUDU以及OLTP新兴的Tikv，分片的多副本依赖于一致性协议Multi-Paxos或者支持乱序提交的Raft协议，多个分片组成Raft-Group，这样可以打散一个表（文件）到多分片多副本的架构上，既保证了扩展性又保证了高可用。Centralized Master管理分片存放的位置，元数据，便于负载均衡、分裂合并等。 示例：数据按uid range分片。 shard1 shard2 +---------------+ +---------------+ |uid| date | |uid| date | +---------------+ +---------------+ | 1 | 2020-11-11| | 3 | 2020-11-13| | 2 | 2020-11-12| | 4 | 2020-11-14| +---------------+ +---------------+ 示例：数据按uid hash分片，f(uid)=uid mod 2。 shard1 shard2 +---------------+ +---------------+ |uid| date | |uid| date | +---------------+ +---------------+ | 1 | 2020-11-11| | 2 | 2020-11-12| | 3 | 2020-11-13| | 4 | 2020-11-14| +---------------+ +---------------+ 6、数据进一步分区 数据分片的基础上，可以进行更细粒度的分区（partition），便于做分区剪枝（partition prune），直接跳过不需要扫描的文件。分片（sharding）策略按照range，可以优化OLAP的范围查询和快速点查；按照hash分区，可以充分打散，有效解决hotspot热点。 将二者结合，做二级分区（two-level），例如阿里云ADB、ClickHouse、KUDU，支持DISTRIBUTED BY HASH再PARTITION BY RANGE，而百度Palo（Doris）一般先按时间一级分区，更好做冷热数据区分，二级分区分桶采用hash。 示例：数据按照二级分区，一级分区uid hash分片，二级分区按date，形成4个文件。 shard1 shard2 +---------------+ +---------------+ |uid| date | |uid| date | +---------------+ +---------------+ | 1 | 2020-11-11| | 2 | 2020-11-12| +---------------+ +---------------+ +---------------+ +---------------+ |uid| date | |uid| date | +---------------+ +---------------+ | 3 | 2020-11-13| | 3 | 2020-11-14| +---------------+ +---------------+ 7、实时写入和ACID 随着实时数仓和HTAP，HSAP[8]等概念的兴起，对于传统数据处理的Lambda架构弊端就凸显出来，链路长，数据冗余，数据一致性不好保证等。 融合OLTP的能力，第一点就是在之前所述的immutable table file上做实时增删改，要保证低延迟，高吞吐，可以借鉴LSM-Tree思想，优化写吞吐，将流式的低延迟随机写，最终变成聚批mini-batch的group commit顺序写，依赖write-ahead log保证持久性，最终形成Base + Delta的文件结构，读流程包括点查或者扫描，基于Base的同时，还需要merge Delta的变化，另外后台通过minor compaction和major compaction不断的合并Delta和Base，可以不断优化读性能，在阿里云ADB，KUDU，Google MESA[9]里面都采用了类似的方案。 在读写一致性层面，需要提供ACID和事务隔离特性，比较好保证单行和mini-batch的原子性，持久性不言而喻，对于一致性和事务隔离，可以采用MVCC机制，每个写都带有version，很简单的实现带版本查一致性，快照一致性（snapshot isolation）。 二、谈计算 1、查询步骤 SQL语言是OLAP的标配，一个完整的SQL查询步骤包括1）SQL词法解析，语法解析，2）形成抽象语法树（AST），3）校验检查，4）AST转成关系代数表达式（relational algebra），5）根据关系代数表达式生成执行计划，先生成逻辑执行计划（logical plan），6）经过优化器生成最优的执行计划，7）根据执行计划生成物理执行计划（physical plan），8）最终交由执行器执行并返回结果。 由SQL到AST的过程，类库和工具较多，C++可用Lex/Yacc，Java可用JavaCC/ANTLR，也可以自己手写实现。由AST到关系代数表达式，可以使用visitor模式遍历。下一章节谈优化器。本节聚焦在物理执行计划后的执行阶段。 2、OLAP数据建模分类 ROLAP和MOLAP。Relational OLAP（ROLAP）对SQL支持好，查询灵活，使用组合模型，雪花或者星型模型组织多张表。ROLAP计算的数据规模往往小于离线大数据计算（Hive/Spark），ROLAP产品很多，包括传统的Greenpulm、Vertica、Teradata，Sql-on-Hadoop系的Presto、Impala、Spark SQL、HAWQ，云计算厂商的阿里云ADB、Google BigQuery，AWS RedShift，有学术界出品的MonetDB[10]，还有新兴的ClickHouse。 如果把查询阶段分为： cache /\ | pre-computing -> computing -> post computing 上面的提到的存储技术更多是为了ROLAP在computing阶段优化考虑的，如果把计算中的熵前置到pre-computing阶段做预计算，也可以大幅优化computing阶段。 Multidimensional OLAP（MOLPA）可以把数据预计算，有些场景下不一定需要细粒度的fact，可以严格区分维度列和指标列，使用Kylin、Druid等，利用上卷（roll-up）做数据立方体（data cube），这样可以大大减少OLAP场景下聚合查询的IO。 另外百度Palo、Google MESA，基于上卷操作做物化视图，也减少了IO消耗，所以他们对于高并发查询支持普遍较好，但是缺点就在于查询不够灵活，数据有冗余。下文主要针对ROLAP谈计算。 3、计算引擎分类 物理执行计划往往是一个DAG，每个节点都是一种operator，最下游的叶子节点一般都是TableScan operator，这个DAG的分布式执行器就是计算引擎（Query Engine），分为两个流派。 第一类是基于离线计算引擎，例如Hive on MR，Spark SQL，阿里云MaxCompute，支持超大规模的数据，进行了容错保证，多个stage落盘（spill to disk），使用resource manager调度和queueing，作业可能持续非常长的时间，占用大量资源，并发低。 第二类是MPP，例如Greenpulm、Presto、Impala、阿里云ADB，RedShift支持大规模数据，不需要reource manager耗时的分配资源和调度任务，long-running的task manager，只需要轻量级的调度，查询一般不容错，算子并行执行，并行度有限制避免straggler node影响TP99，相比基于离线的计算引擎往往是短任务，查询耗时不会太长。 Presto、Impala属于Sql-on-Hadoop MPP，利用Hive metastore，直接读取Parquet、ORC等文件格式，Greenpulm、RedShift基于PostgreSQL，阿里云ADB采用私有的数据存储技术，计算存储分离的架构，存储表到分布式存储盘古上。 4、MPP架构 通用的MPP架构组成由coordinator，worker，metastore，scheduler组成，各个产品名称不同而已。通过metastore可以获取表元信息、分区/分片位置、辅助coordinator做校验等。 coordinator负责从SQL到物理执行计划的生成以及执行，一个计划往往被切分为多个plan fragment，plan fragment之间通过添加ExchangeOperator来传递数据（例如shuffle），逻辑上plan fragment等同于stage，scheduler管理所有worker节点，coordinator调用scheduler分发stage到不同的worker节点执行，就形成了很多task。 一个task，包含一个或者多个operator算子，最简单的学历证书算子实现就是解释执行（interpreted）的模式。算子包括Project、Filter、TableScan、HashJoin、Aggregation等，叶子节点一般是TableScan，拉取存储中数据。MPP架构就是充分利用分布式的特性，让算子分布式的并行计算，同时task内部也可以做并行处理，加速查询。 5、计算执行 数据流。DAG在进行数据流动时，采用pipeline方式，也就是上游stage不用等下游stage完全执行结束就可以拉取数据并执行计算。数据不落盘，算子之间通过内存直接拷贝到socket buffer发送，需要保证内存足够大，否则容易OOM。 火山模型（Volcano-style），是一种Row-Based Streaming Iterator Model算子的实现，只需要open、next、close三个函数，就可以实现数据从底向上的“拉”取，驱动计算进行。 向量化执行（Vectorized query）。MonetDB论文提出了火山模型的改进方案——向量化执行，火山模型tuple-at-a-time的实现，每个算子执行完传递一行给上游算子继续执行，函数调用过多，且大量的虚函数调用，条件分支预测失败，直接现象就是CPU利用率低（low IPC）。 而现代的CPU有多级流水线可以实现指令级并行，超标量（super scalar）实现乱序执行，对于forloop可以有效优化，超线程还能实现线程级并行，而CPU多级的Cache，以及cache line的有效利用避免cache miss，再配合编译器的优化，都会大大加速计算过程。 向量化执行的思想就是算子之间的输入输出是一批（Batch，例如上千行）数据，这样可以让计算更多的停留在函数内，而不是频繁的交互切换，提高了CPU的流水线并行度，而且还可以使用SIMD指令，例如AVX指令集来实现数据并行处理。 实际实现中，例如Impala各个算子的input虽然是RowBatch，但除了TableScan算子，其他的也是火山模型执行式的row by row处理，TableScan读存储，列式内存布局加速pushdown的filter执行，aggregation下推后还可以使用SIMD指令加速聚合。但是向量化也会带来额外的开销，就是物化中间结果（materlization），以牺牲物化的开销换取更高的计算性能。 动态代码生成（codegen）。解释执行（interpreted）的算子，因为面向通用化设计，大数据集下往往效率不高，可以使用codegen动态生成算子逻辑，例如Java使用ASM或者Janino，C++使用LLVM IR，这样生成的算子更贴近计算，减少了冗余和虚函数调用，还可以多个算子糅合成一个函数。另外表达式计算的codegen还可以做的更极致，一些简单的计算可以做成汇编指令，进一步加速。 关于向量化或者codegen，孰优孰劣，论文Everything You Always Wanted to Know About Compiled and Vectorized Queries But Were Afraid to Ask [11]进行了深入的对比。二者也可以融合，通过codegen生成向量化执行代码，另外也不一定做wholestage codegen，和解释执行也可以一起配合。 计算的耗时有一部分会损耗在IO、CPU的闲置上。内存的布局和管理，行式布局还是列式布局，对于CPU Cache是否友好，内存池还是按需分配，都会影响着系统的吞吐，C++可自行维护Arena或者使用jemalloc等框架，而Java的heap memory比较低效还影响GC，因此使用Unsafe API操作堆外内存。另外Arrow的兴起，也对于跨进程通信后，不必进行数据反序列化、内存分配再拷贝，就可以读取列式的数据，也进一步加速了计算。 6、常见算子实现 TableScan算子直读底层数据源，例如Presto，抽象了很好了connector，可对接多种数据源（Hadoop，对象存储等），一般都支持projection、filter，因此可以做filter pushdown和projection pushdown到TableScan，另外在做predicate的时候可以使用lazy materialization（延迟物化）的技巧去short circuit掉先不需要的列。 Join算子的实现，如果两个表都很小，最简单的利用in-memory hash join、simple nested loop join；一大一小，可以广播小表（broadcast），一般维度表都比较小，如果大表有索引，扫描小表，根据大表做index lookup join，否则基于小表做build table，大表做probe table，实现hash join。 两个大表，如果两个表的join key的一级分区策略相同，则可以很好的对齐，避免大表shuffle，直接在大表的shard做local join，如果不能对齐，则两个表按照join key shuffle到其他节点，重分布式后再做join；另外如果两个表的join key有序，还可以使用sort-merge join。 7、资源管理与调度 MPP架构下coordinator需要scheduler调度task到worker节点，对于长计算任务或者ETL任务，会占用很多资源，导致OLAP的并发度受限，其他请求需要排队，因此很难服务对外在线请求。 为了迎合混合负载，传统scheduler简单粗暴的调度和资源管理已经无法满足要求，因此可以进行任务的fine grained schedule避免空闲资源，请求间对资源的使用尽量的隔离，避免bad query吃满资源，简单的策略可以通过label化集群，或者用SQL hint实现，区分长短计算任务，让更多的短任务也可以快速得到响应。 当OLAP系统足够高性能后，更好的资源管理和调度，将会提升OLAP为一个支持高并发、低延迟的，可对外提供在线服务的系统，而不仅仅是一个in-house的分析系统。 三、谈优化器 查询优化器不光是传统数据库DB2、Oracle、MySQL的核心，在OLAP里也至关重要。AST转为SQL形式化表达语言——关系代数表达式（relational algebra），代码实现就是一颗关系运算符组成的树，查询优化主要是围绕着“等价交换”的原则做相应的转换，优化关系代数表达式。 关系代数的基本运算包括投影（project）、选择（select）、并（union）、差（set difference）、连接（join）等。优化器分为Rule-Based Optimizer (RBO) 和Cost-Based Optimizer (CBO) 两类。 1、RBO 会将原有表达式裁剪掉，遍历一系列规则（Rule），只要满足条件就转换，生成最终的执行计划。一些常见的规则包括分区裁剪（Partition Prune）、列裁剪、谓词下推（Predicate Pushdown）、投影下推（Projection Pushdown）、聚合下推、limit下推、sort下推、常量折叠（Constant Folding）、子查询内联转join等。 2、CBO 会将原有表达式保留，基于统计信息 + 代价模型，尝试探索生成等价关系表达式，最终取代价最小的执行计划。CBO的实现有两种模型，Volcano模型，Cascades模型，很流行的Calcite[12]使用Volcano模型，比如Flink、Hive都基于此，Orca使用Cascades模型，在Greenpulm中使用。 优化器需要尽量的高效，高效的生成搜索空间、动态规划遍历搜索空间（top down、bottom up、depth-first等），高效的剪枝策略等都可以加速优化过程。统计信息包括表数据大小，row count。 查询列的trait metadata（min、max、cardinality等），sortness、可利用的索引，直方图（Histogram）分布统计等。Join是OLAP最消耗吞吐的算子之一，也是ROLAP对于分析最强大的地方，可以进行多表的关联查询，常见的优化手段包括，join reorder，使用left-deep tree还是bushy tree执行join，以及如何选择join算法实现（上节提到的各种join实现的选择），结合高效索引结构实现的index join，group by下推、top-n下推等。 四、谈趋势 OLAP领域经历了从RDBMS建立起来的SQL + OLAP，到ETL + 专有OLAP的数仓阶段，目前仍在不断演进，更多的云厂商也加入这个领域，展示出、也正经历着如下的趋势。 实时分析。传统的OLAP需要做各种pipeline、ETL导入数据，这样的架构会存储多份数据，冗余并且一致性不好保证，也引入过多的技术栈和复杂度，也不能满足实时分析，即使mini-batch的处理仍然需要最快数分钟。 业界的趋势在于赋予OLAP高吞吐实时写，提供实时查询能力，例如上游数据源，经过流计算系统，老的架构基于lambda，写历史数据到存储再清洗，实时数据入一些NoSQL，使用方需要做各种数据源merge操作，流行的方式是流计算系统直接写OLAP，这样避免了数据孤岛，保证了链路简单，阿里云hologres团队提出的HSAP（Hybrid Serving/Analytical Processing）[8]正是这种理念。 HTAP。事务处理和分析处理在一个数据库中提供，是最理想的状态，但是二者的技术体系往往又很难融合，因此现在很多数据库厂商都在做这方面的尝试，保证数据一致性是很大的挑战，一种思路是从OLTP到OLAP，多副本存储时，有些副本是专门为OLAP定制的，使用专用的OLAP引擎提供查询，另外就是赋予ACID和事务能力到OLAP系统中，使得OLAP也支持INSERT/DELETE/UPDATE操作。 云原生。传统的OLAP，例如Exadata等依赖于高端硬件，很多on-premise的解决方案也面临扩展性和成本问题，云原生的架构通过虚拟化技术，可实现更好的弹性计算，如果采用存储计算分离的架构还可以实现弹性存储，这些水平扩展的机制可以很好的兼顾高性能、成本和扩展性。 多模数据结构分析。不仅限于结构化数据，半结构化、非结构化的数据分析也逐渐在OLAP中应用，包括向量检索，JSON、ARRAY检索等。 软硬一体化。计算方面，更好利用多核并行，使得查询满足NUMA-aware，亲核性（affinity）可以进一步榨干系统的吞吐，使用FPGA、GPU硬件加速，利用这些硬件提供的超高带宽和深度流水线可以加速一些向量计算和聚合操作；存储方面，随着存储查询带宽增大、延迟降低，可以应用更多新存储，例如Intel 傲腾NVM 3D-XPoint SSD[13]提供2.6G/s的顺序读吞吐，高并发点查延迟可控制在10几个us；网络方面，基于RDMA网络，DPDK等技术可替换传统的tcp，做kernel bypass，降低网络延迟。上层的OLAP软件可以基于这些新硬件做更深度的定制，提供更极致的性能。 >>>> 参考资料 [1] 从MySQL InnoDB物理文件格式深入理解索引 [2] A DECOMPOSITION STORAGE MODEL [3] C-Store: A Column-oriented DBMS [4] Dremel: Interactive Analysis of Web-Scale Datasets [5] AnalyticDB: Real-time OLAP Database System at Alibaba Cloud [6] Cache craftiness for fast multicore key-value storage [7] Kudu: Storage for Fast Analytics on Fast Data [8] 数据仓库、数据湖、流批一体，终于有大神讲清楚了 [9] Mesa: Geo-Replicated, Near Real-Time, Scalable Data Warehousing [10] MonetDB/X100: Hyper-Pipelining Query Execution [11] Everything You Always Wanted to Know About Compiled and Vectorized Queries But Were Afraid to Ask [12] Apache Calcite: A Foundational Framework for Optimized Query Processing Over Heterogeneous Data Sources [13] Intel Optane Series [14] bitshuffle 作者丨neoReMinD 来源丨 zhuanlan.zhihu/p/163236128?utm_source=wechat_session&utm_medium=social&utm_oi=30962498928640&utm_content=sec&from=timeline&s_r=0 dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus 当下，企业越来越重视数据分析，OLAP成为每个大数据从业人员必要掌握的技能。如何利用大数据为企业快速发展助力？如何在大数据建设与数据治理中更进一竿？不妨来看看10月30日举办的DAMS中国数据智能管理峰会上海站，部分大数据相关议题如下： 《大数据资产管理平台的设计、研发、运营实践》中国联通 大数据基础平台负责人/高级架构师 尹正军 《字节跳动数据治理实践》今日头条 数据BP/数据治理负责人 任长延 《万亿级消息队列Kafka在滴滴的实践》滴滴 OLAP&搜索平台负责人 张亮 《企业数字化转型落地指南：从数据资产管理到数据中台（拟）》新炬网络 董事/副总经理 程永新 《基于数据湖构建云上的数据分析架构》AWS 资深架构师 朱澜 立即扫码享受限时优惠，一起探讨大数据战略从顶层设计到底层实现的落地过程。 总结OLAP系统核心技术点，每一点都值得单独收藏
-
发表了文章 2022-01-29
区块链、无人驾驶、量子计算、感知智能……2050 年的技术什么样？
这些技术在 2050 年会是什么样子，估计目前还没有人能够想的出来。但是总是要去想，这样距离未来才会更进一步。半年前，杭州云栖科技创新基金会的王坚博士（也是阿里巴巴技术委员会主席和阿里云的创始人）和极客邦科技创始人霍泰稳碰了个头，说咱们有必要在现在的技术干货会议之外，搞一个面向未来科技的活动，给咱们热爱科技的同学一个展开想象的理由和空间。 一拍即合，这就是接下来要重点介绍的 2050 大会，半年来，多位志愿发起人和数百位志愿者奔波于全球，召集了近 500 位各行各业有创新的人来现场分享，还设置了大量的空间供大家“ZAO”，比如科学实验、迷你火箭、青春舞台、马拉松晨跑、星空露营等。 所以说，这次我们理由很简单，就是要给热爱科技的年青人一个超大的地儿，听听，看看，聊聊，放空自己，提升认知。脚踏实地工作很重要，抬头望星空想未来，也是必不可少，这样的人生才够精彩，够完美。 2050 大会是一场涵盖了人工智能、自动驾驶、区块链、量子计算、深度强化学习、开源软件、智能运维和技术创业等诸多热门话题的大会，请看： 1. 人工智能 王今朝，特许金融分析师，《华尔街流行的投资策略和热门的智能算法》 苗广艺，学霸君技术副总裁，《人工智能在教育行业的落地》 祝伟，同盾科技联合创始人兼副总裁，《新时代下如何利用人工智能重塑金融风控》 陈华钧，浙江大学教授、博导，《面向领域的知识图谱工初探》 鲁建凡，浙江鲸腾网络科技有限公司副总经理、TGO 鲲鹏会会员，《智能问答系统在证券投资领域的工程化之路》 刘燕，机器之心内容合伙人，《Let's AI - 你们说 AI 公司的未来是什么？》 印奇 / 唐文斌，旷视科技 CEO/CTO，《看得见的和看不见的城市》 肖仰，华复旦大学教授、博士生导师，《知识图谱与认知智能》 吴琨，触宝高级技术总监，《Ten Commandments of NLP Mobile Apps》 任腾，触宝首席科学家、TGO 鲲鹏会会员，《人工智能：感知智能升级》 李泽超，南京理工大学教授，《多媒体智能分析：表示、度量与理解》 2. 自动驾驶 楼天城，小马智行联合创始人兼 CTO，《人工智能：无人驾驶》 李一帆，禾赛科技联合创始人 &CEO，《激光雷达向固态和量产的演变》 张德兆，智行者 CEO，《自动驾驶的场景及挑战》 李星宇，地平线智能驾驶商务总监，《地平线自动驾驶芯片挑战 AI 产业之巅》 张天雷，主线科技 CEO，《智能驾驶产品之路》 翁炜，Velodyne 亚太区总监，《Driving the autonomous revolution》 郭继舜，广汽研究院智能驾驶技术部负责人 ，分享主题确认中 3. 区块链 王淙，Co-founder of IMO.VC，《区块链：技术革新与挑战》 Sam Lee，Blockchain Global 区块链集团创始人兼 CEO，《区块链和人工智能的结合会如何影响未来世界》 董博，世界经济论坛全球杰出青年社区董事会成员、Blockshine Communication 创始人，《2018 区块链与实体经济融合发展》 Quincy Larson，freeCodeCamp.org 创始人，《构建区块链的未来》 Stephane Laurent，Penta 首席营销官，《构建区块链的未来》 Susan Corbisiero，澳大利亚驻上海总领事馆商务领事，《构建区块链的未来》 Jay Zhou Loopring，联合创始人 & 首席营销官，《构建区块链的未来》 Steven Bai Sencity，联合创始人 &CEO 联合，《构建区块链的未来》 杨奇函，葫芦时刻联合创始人、第三季《中国诗词大会》策划，《区块链吐槽大会》 徐继哲，亦来云联合创始人，《2018 区块链与实体经济融合发展》 帅初，Qtum 量子链联合创始人，《2018 区块链与实体经济融合发展》 张天博，博聚科技 COO，《2018 区块链与实体经济融合发展》 呼涛，TokenInsight CEO，《2018 区块链与实体经济融合发展》 江泽武，哈希研究院院长，《2018 区块链与实体经济融合发展》 徐学朋，独立投资人《2018 区块链与实体经济融合发展》 4. 量子计算 曾蓓，美国麻省理工学院 (MIT) 物理学博士、加拿大 Guelph 大学数学系和 Waterloo 大学量子计算研究所 (IQC) 教授，《当我们谈量子计算时 我们谈些什么》 鲁大为，南方科技大学物理系助理教授，《漫话拓扑量子计算》 朱晓波，中国科学技术大学教授，《超导量子计算》 孙晓明，中科院计算所研究员，《量子搜索：从 Chebyshev 到 Deutsh 和 Grover》 李绿周，中山大学副教授、古玩博导，《量子世界的计算之法——谈谈量子算法》 翁文康，南方科技大学物理系副教授，《奇妙的量子世界》 鲁大为，南方科技大学物理系助理教授，《从薛定谔的猫到量子计算》 5. 深度强化学习 张雷，天壤智能 CTO，《围棋自我学习中的若干问题探讨》 Han Liu (刘晗) & Meng Fang (方蒙)， 腾讯 AI Lab 机器学习负责人 / 高级研究员，《Learning how to Active Learn: A Deep Reinforcement Learning Approach》 袁泉，启元世界（inspir.ai）创始人兼 CEO，《人机协作技术与挑战》 靳骏奇，阿里妈妈精准展示技术算法团队成员，《 强化学习在展示广告实时竞价中的应用》 仇光，阿里巴巴集团阿里妈妈事业部高级算法专家，《强化学习在搜索营销客户优化中的实践与思考》 张海峰，北京大学博士生，《Learning to Design Games: Strategic Environment in Reinforcement Learning》 俞扬，南京大学副教授，《强化学习：从虚拟走向现实》 吴宇怀，多伦多大学博士生，《Language grounding with human hindsight advice》 温颖，伦敦大学学院博士生，《Communication in Multi-Agent Reinforcement Learning》 顾世翔，剑桥大学博士生，《Deep Reinforcement Learning for Robotics: Frontiers and Beyond》 6. 开源软件 韩卿，Kyligence 联合创始人兼 CEO、TGO 鲲鹏会会员，《Apache 软件基金会运作机制及 Kylin 项目的实践》 刘奇，PingCAP 联合创始人兼 CEO，《TiDB 的三年开源历程回顾》 冯嘉，Apache RocketMQ 联合创始人、LInux OpenMessaging 标准创始人，《Apache 软件基金会运作机制及 Kylin 项目的实践》 彭涛，hyper.sh 软件工程师，《hyper 的开源之路: 从 runv 到 kata containers》 温铭，OpenResty 软件基金会主席、OpenResty Inc. 合伙人，《开源相关 NPO（非营利组织）在中国的落地和实践》 7. 智能运维 陈靖华，听云 CTO、TGO 鲲鹏会会员，《AIOps 智能运维》 龚诚，58 集团高级技术经理、智能运维团队负责人，《AIOps 在监控业务的落地探索》 赵宇辰，美国伊利诺伊大学芝加哥分校机器学习和数据挖掘方向博士，《智能运维中的时间序列》 裴丹，清华大学计算机系长聘副教授、特别研究员，《无人运维》 8. 技术创业 高阳，SegmentFault 思否 CEO，《那些一直在创业路上的 90 后：过去的 5 年和未来的 5 年》 Slush China，全球创投峰会，《中国创业未来 10 年的机会在哪里？》 Andreas Saar，i Slush Helsinki CEO，《To Win In 10 Years - Welcoming message from Finland》 ……
-
发表了文章 2022-01-29
李道兵：京东云的云原生理念及 Serverless 最佳实践
在云原生技术全面爆发之前，我们开发的应用可以被称为非云原生应用，非云原生应用并没有考虑到应用的弹性和规模性，甚至很多都不具备扩展性，当业务规模扩大时，特别依赖硬件的升级，进而带来了很多问题。云原生的出现带来了新的开发方式，然而这一技术处于快速的发展过程中，导致很难定义清楚各类概念和理解各种技术名词，本文采访了京东云中间件团队负责人李道兵，了解京东云在云原生领域的理念和相关探索，以期对开发者有所帮助。 如今，企业很难在聊云原生这个话题时避开容器，但是往回倒四年，容器在国内的应用并不普遍，大多集中在技术实力较强的互联网大厂，但也并非后来大火的 Docker，当时的不少文章还将这群早期实践者称作“敢于吃螃蟹的人”。显然，在云原生领域，容器的发展是推动其落地的重要条件，但最大的需求并不是为了使用容器，这个逻辑本身就很奇怪，为了出现而出现的技术往往不会有好的结局，容器所解决的问题才是组织或开发者最大的需求。那么，组织现阶段对云原生实践最大的需求是什么呢？ 过去几个月，InfoQ 先后就云原生这一话题采访了阿里巴巴、腾讯、青云、居然之家、华为等众多厂商，对值得关注的开源技术及相关落地实践进行了初步探索。本文，InfoQ 对京东云中间件产品研发部高级总监李道兵进行了独家专访，了解京东云在云原生领域的理念和相关探索。 关于云原生，其实每篇相关文章都会特意留出一部分讲解企业的理念，也多次提到了 Pivotal 公司的 Matt Stine 写的一本叫做迁移到云原生应用架构的小册子以及 CNCF 在今年 KubeCon 上海站提出的定义（V1.0）： 云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。 但是，正如李道兵在接受采访时所言：“与其说云原生涉及了众多理念，不如说现在社区还没有找到最佳实践应该是什么样子。”正因如此，每篇文章都会花费一些篇幅介绍本文所讨论的云原生理念的范围。 相比于“云原生”这个名字的诞生，李道兵认为这一概念的出现可以追溯到更早之前。 2008 年，通过将 cgroups 的资源管理能力和 Linux Namespace 的视图隔离能力组合在一起，LXC（Linux Container）这样的完整的容器技术出现在了 Linux 内核当中。当然，在这之前的虚拟机的概念此处就不赘述了，李道兵介绍道，LXC 比虚拟机轻量很多，但可以达到大部分虚拟机的效果，隔离性和安全性却不够好。 在这之后，Docker 项目的正式发布是对云原生领域产生深远影响的重要事件。李道兵补充道，Docker 真正的成功在于 Docker Hub，也就是官方维护的公共仓库，其内存储了大量镜像。其次就是构建镜像的方法，Docker 构造镜像的方法比其他的简单很多，也能更轻松地利用其他人的已有成果。总之，Docker 的出现大幅降低了微服务的运维负担，让微服务能真正成为一个可以大面积推广的技术。在服务拆分之后，组织就会出现服务治理的需求，包括服务发现、服务伸缩、日志收集、问题定位等，随即就出现了很多类似 Mesos、Kubernetes 的技术，做服务的方式由原来的用 Java 写完后跑在 Tomcat 上演变成将服务部署在容器之上，再利用 Kubernetes 进行管理，开发者已经不需要操心服务器的事情，这一系列由此产生的新理念可以称之为“Cloud Native（云原生）”。 不难看出，容器是云原生得以落地的重要条件，但这背后的真正诉求则是开发者对服务治理和去运维化的需求，可以认为在云原生时代，系统运维这个角色可能完全消失掉，因为不需要操心服务器，自然就无运维，容器镜像可以直接将一个应用运行所需的完整环境，即：整个操作系统的文件系统全部打包进去，这才是容器得以大面积普及的原因。换句话说，这样的服务交付方式才是开发者的真正诉求。 正如开篇所言，现在谈到云原生实践很难避开容器这个话题，同样也很难避开 Kubernetes(k8s)，这就好像曾经的 Hadoop 是大数据领域的事实标准一样，但 Kuberntes 的复杂性也是有目共睹的，李道兵表示：“我承认 Kubernetes 底层体系的重要性，但它的接口真的不够简单。相比较而言，早些年谷歌推出的 Google App Engine 反而是对未来很好的示范，但很可惜，由于种种原因（当时云的概念还没有起来、在 AppEngine 写一个有状态服务非常困难、对 AppEngine 的性能分析和优化困难等），Google App Engine 并没有获得很好的反响。但就这个层面来讲，未来，我们应该可以得到比 Kubernetes 友好得多的界面。” 既然如此，为什么 Kubernetes 顶着“复杂性”的古玩还可以发展得如此迅速呢？李道兵认为，首先，底层的复杂性是不可避免的，开发者只能在上层通过合适的抽象来简化使用界面；其次，过去几年采用 K8s 大都是技术好的团队，他们能驾驭这种复杂性，同时还能从底层的灵活性中获益。但最近几年随着 K8s 的更广泛采用，这个问题就愈发严重了，也有很多项目在尝试解决这个问题。 那么，K8s 是否会被新的框架取代呢？李道兵认为这个问题可以类比为编程语言来看待，比如“Java 就足够好到把所有编程语言都比下去吗？”这也未必，当年，Java 确实好到足以淘汰 COBOL（现在依旧有一些企业在使用），但一旦 Java 被大面积采用，你淘汰 Java 就需要比 Java 好一个数量级的语言出现。所以，尽管出现了一些针对 Java 作出改进的语言，比如 Groovy、Scala 等，但仍然无法撬动 Java 在企业市场的占有率，毕竟对于整个 IT 业界，做出决定更换编程语言是要耗费很多成本的。同理，Kubernetes 还是有非常多优点的，并且已被广泛采纳，所以要被取代其实很难。 如今，在 Kubernetes 上进行探索的大部分企业以技术见长的互联网大厂为主，这些企业有动力也有能力选择 Kubernetes，因为搞得定。但是，为了面向更加广泛的用户，Kubernetes 社区一直没有停止在这个领域的持续探索，并已经取得一些关键性突破。因此，云原生领域的核心技术其实是处在不断的发展和变化之中，现在很难对最佳实践给出定论。 京东云虽然是一个云服务的提供者，但其内部也需要进行云原生改造，比如京东云提供的对象存储服务，其下的数十个组件同样有服务治理的需求。因此，京东云在这个过程中有很多 Service Mesh 相关实践，主要是通过 Service Mesh 的 sidecar 将原本需要写在代码中的逻辑替换掉，而微服务改造和容器化可以认为在此之前已经陆续完成（如果对这部分感兴趣，可以阅读《专访京东云：愿云原生不再只有 Kubernetes》，本文不作为重点介绍）。 在 Service Mesh 方面，目前比较有代表性的开源工具就是 Istio。 Istio 的核心组件主要包括 Proxy 代理、Mixer 混合器、Pilot 引导、Citadel 堡垒和 Galley。其中，Proxy 代理的代理组件主要是 Envoy，用来拦截所有想拦截的流量；Mixer 混合器混合了各种策略以及后端数据采集或遥测系统的适配器，实现了前端 Proxy 与后端系统的隔离与汇合；Pilot 引导提供了一系列 rules api，允许运维人员指定一系列高级的流量管理规则；Citadel 堡垒管理着集群的密钥和证书，是集群的安全部门；Galley 主要是用来验证用户编写的 Istio api 配置。 目前来看，Istio 并没有太大的问题，但李道兵表示，Envoy 可能成为 Istio 发展的阻碍，Envoy 本身是用 C++ 编写的，主要由核心团队维护，社区参与度一般。Envoy 支持了多种调用机制，但仍然不能满足部分工业界的需求（比如 Backup Request)，而 Envoy 的复杂性又限制了使用者自行扩展，不排除未来 Envoy 会被更灵活的 Sidecar 组件替代掉。 除此之外，过去一段时间，京东云在 Serverless 层面进行了大量实践，这也是京东云整体改造中非常重要的一个环节。 Serverless 实践 2019 年，Serverless 被 Gartner 称为最有潜力的云计算技术发展方向，并被赋予是必然性的发展趋势。Serverless 从底层开始变革计算资源的形态，为软件架构设计与应用服务部署带来了新的设计思路。在行业内，对 Serverless 的解读并没有公认的准确定义，京东云认为 Serverless 技术目前有三种实现： 真正的无服务器，就是所谓的函数计算 FaaS；类似京东云的原生容器，容器直接呈现给用户，并且背后不需要有虚拟机来支持；应用比较广泛的无服务器，背后虚拟机由云厂商来提供，但是对用户不可见，仍然是以虚拟机的方式来提供容器。 目前，京东云在 Serverless 还在开发中，完整的 Serverless 实践需要包括如下几个模块: 负责提供计算能力的 FaaS负责提供通信能力的 Queue Service 和 Notification Service负责提供持久化能力的 Serverless KV 和 Object Storage负责提供入口的 API Gateway负责提供编排能力的 Step Function 京东云已经提供了 FaaS, Queue Service, Object Storage 和 API Gateway, 其他模块也会在近期陆续发布。 FaaS 在 FaaS 层面，京东云和 AWS 的 Lambda 以及 Azure 的 Function 类似，都是需要用户提供一段代码，这段代码以 HTTP 的入口形式可以访问。代码可以用 Java 等多种语言写出，处理完用户请求后给出一定反馈，整体代码的生存周期就是请求的处理过程。代码是由函数计算来提供包括 CPU、内存、语言平台等运行环境，用户完全不用关心代码运行在什么地方。 当并发请求非常多时，平台就会运行这段代码容器的多个副本，这样就能做到：用户无需预留计算资源，仅根据调用的时长、次数来付费。这种情况是目前为止计算资源能做到的最小化分配粒度。粒度越小时，越有可能填满服务器的计算能力，粒度越大，后期就可能有越多的计算能力被闲置。 李道兵表示，FaaS 的优势和劣势都很明显，主要优势包括：彻底的无运维、近乎无限的伸缩能力和零启动成本。劣势则包括：冷启动比较慢，相对常规服务延时较高、压力稳定时没有成本优势。不过这些劣势并不是 FaaS 的本质造成的，而是可以解决掉的问题，在解决掉这些问题之后，FaaS 就能获得更大的适用范围和更远大的前景。 现阶段，FaaS 比较适合的应用场景主要有两类：一是事件驱动型应用，比如 IoT、网页游戏等类型；二是实验性项目，这类项目租用虚拟机的成本比较高，而 FaaS 几乎是零成本，不调用的情况下不会产生开销。目前还有一个趋势是逐步用 FaaS 取代 AppEngine。京东云目前将 FaaS 应用在多媒体内容分析处理和 Serverless 后端服务两个场景： 通过对象存储上传事件可以触发多个函数，完成实时图片或文件筛选、转存、创建缩略图、转换视频编码等处理分析。通过事件触发机制，您能够快速部署复杂的应用与服务，构建一个弹性、可靠的后端系统。通过函数服务和 API 网关构建后端，以验证和处理 API 请求。采用函数服务构建可灵活拓展架构，轻松创造丰富、个性化的应用程序体验。 京东云目前的 FaaS 主要支持 Python 2&3 和 Nodejs 6&8，这两者是目前 FaaS 适用场景中使用较多的语言，而接下来也会陆续支持 Java 和 PHP 等编程语言，毕竟几行代码就可以处理的事件通常开发者更愿意用 Python 而不是 Java。笼统地说，可以通过 K8s 和 Docker 来实现的服务，也可以选择用 FaaS 实现，但要认清楚 FaaS 的优劣。李道兵表示，FaaS 的冷启动是业界目前在共同努力解决的问题，这个概念很好理解，就是指函数第一次调用时平台部署函数实例的过程。 在本地调用函数时，响应基本是实时的，而云上的 FaaS 需要部署计算环境，这个过程的时间从数百毫秒到数秒不等，难于应对时延敏感型应用；此外，FaaS 的优势是极度弹性伸缩，这让其在调用量下降时会进行资源回收清理，下次调用时则又需要冷启动，这个过程一直反复存在于服务的整个生命周期中。 李道兵表示，京东云在这方面进行了不少尝试，主要可以分为两部分：一是加快原生容器（下文将介绍这一概念）和云硬盘的启动速度，甚至说在云硬盘加载之前先按需加载数据；二是预留部分实例，需要的时候再启动，不过这未必适合所有场景，当 FaaS 运行在客户的 VPC 中时，使用的是 VPC 中的资源，第二种方案暂时并不适用。 目前，业界也有一些方案，比如 Kata、Firecracker 对 qemu，虚拟机镜像做裁剪来加速虚拟机的创建和启动，但是效果并没有那么好。李道兵表示，虚拟机启动慢的问题并不是第一天出现，因此没有那么好解决，而容器的问题则是安全性不够高，如果容器足够安全，也不需要造虚拟机了，直接物理机上运行可以节省不少时间，而原生容器算是平衡各种利弊后的一个不错的尝试。 队列服务 根据了解，京东云的队列服务（Queue Service）是一项基于 Serverless 架构的全托管消息队列服务，它可以提供高可靠并且几乎无限扩展的托管消息队列。 队列服务的架构图，主要分为底层分布式存储、功能及解决方案、安全管理及用户接入四层，其特点是毫秒级自动伸缩和无规格限制。在消息类型上，标准队列理论上无限制的 TPS 上限，最大努力的消息排序以及至少一次消息传达；FIFO 队列保证消息的传达顺序与消息发送顺序一致以及精确的一次性处理。主要的应用场景是如下两种： 异步解耦，削峰填谷。上下游系统处理能力存在差距的时候，利用队列作为数据的缓冲器，增加系统架构的可用性和可靠性，平滑处理峰值流量，解耦系统架构，避免对业务主流程的影响。性能扩展，容错处理。由于队列服务会解耦分离用户应用的处理进程，因此对于有扩展需求的应用，可以轻松提高从队列服务发送或接收速率来增加用户应用的处理能力，对于部分故障的模块可以从整个系统中摘除。 原生容器 原生容器与普通意义的容器还是有一些差别，通常容器会被认为是在 PaaS 层，由 PaaS 团队负责，而原生容器在京东云内部属于 IaaS 团队，这也可以看出原生容器与底层的关联比较密切。简单来说，可以将原生容器理解为普通容器和削薄后的虚拟机的结合体。 如上文所言，容器的安全性和隔离性是很大的问题，一旦容器被入侵，入侵者很容易通过穿透容器到达下面的物理机，从而影响整个云平台上的用户，虽然这也是老生常谈的问题，但要想既保证性能和启动时间不受影响，又达到更高的安全级别，这本身就是一件棘手的事情，常规的安全手法成本又太高，最好的方式是将虚拟机隔离起来，通过这个弥补容器安全性上的不足，当容器被入侵时，入侵者不至于影响整个云平台的用户。同时，原生容器对虚拟机做了大幅简化，资源损耗和启动时间均有所降低，这就是所谓的原生容器的概念。坦白地说，用户申请的每一个原生容器里面跑的就是一个 Docker 或者 Pod。 在原生容器方面，京东的产品推出时，Kubernetes 还没这么流行。所以为了实现节点容量的无限大，是通过一个叫 virtual kubelet 的插件让 Kubernetes 集群拥有一个虚拟节点。而如今，原生容器完全看用户需求。如果是一次性的任务处理批量计算工作，这种方式非常有效，因为虚拟节点可能会在某些方面不能实现 Kubernetes 所有的接口，某些特殊应用可能需要一定的适配工作，例如 daemonset。京东云正在考虑把原生容器运行的节点暴露出来，并提供和现在 Kubernetes 所有接口兼容的一个应用。而在 Docker 方面，京东云希望能向轻量化发展，可以随时创建、随时销毁，并且可以随时随地创建更多的副本。 此外，京东云也希望能将原生容器和 Kubernetes 通过比较紧密的方式结合在一起。比如在 Kubernetes 里的 Kata Container，其在 Kubernetes 里使用了更安全的容器；还有 Rancher Labs 基于 K8s 推出的轻量级的 Kubernetes 发行版 K3s，可以满足在边缘计算环境中运行在内存和处理能力受限的小型、易于管理的 Kubernetes 集群日益增长的需求。 面向未来，京东云的整体目标还是希望在云原生领域有更多投入。李道兵表示，具体来说，在 Service Mesh 方面达到更好的透视遥感能力，如果是较大调用量的分析需要很好地分析服务之间的关系以及出现瓶颈和延迟的原因，甚至在开发者不需要增加代码的情况下就可以享受这些功能。 在 Serverless 层面，需要进一步优化 FaaS 的冷启动能力，大幅缩短启动时间至毫秒级别，并尽可能降低延迟，因为现在需要过的层和转换的协议还比较多，这部分消耗的时间需要尽量减少，并增加更多语言支持，将界面简化到接近当年 Google App Engine 的样子。 作者简介：京东云中间件产品研发部高级总监，先后在金山、盛大云、七牛云等公司工作，曾任盛大云资深研究员，七牛云 SVP 兼首席架构师等职位。作为开源项目的爱好者，李道兵曾担任 Debian Developer、维基百科中文管理员，维护 iso-codes 等开源方面的工作。 关注服务安全、架构健壮性（高可用、可测试、可追溯）等领域，主导了多个高压力项目，推崇高可用、可伸缩、低耦合的架构设计。目前，京东云函数服务正在公测，点击链接可以申请试用，想了解京东云更多云原生技术实践可以关注京东云开发者社区。
-
发表了文章 2022-01-29
开发 iOS 应用，Kotlin Native 是否够格？
一直以来，因为有着 iOS、Android 等多个系统的存在，开发者在开发同一款应用时也需要根据不同的平台去进行相应的修改，在此情况之下，Flutter、React Native、Weex 等多款跨平台框架应运而生，有效提升了开发者代码的复用性，大大降低了开发成本。 而在 Google I/O 大会上，自 Google 宣布将 Kotlin 作为 Android 开发的官方语言之后，Kotlin 的首席语言设计师 Andrey Breslav 也在 KotlinConf 上宣布 Kotlin/Native 已支持用于开发 iOS 应用。不过同时，不少开发者也提出质疑，其认为 Kotlin Native 处于早期阶段，根本没有想象中那么美好。 在本文中，作者 Jeremy Rempel 将从跨平台的发展以及框架对比等多重角度，剖析 Kotlin Native 是否有存在的必要。 以下为译文： 基于历史原因，移动应用一直以来都要求在2个或更多不同的平台和工具包上进行开发。包括但不限于： iOS：Object C，Swift，XcodeAndroid：Java，Kotlin，Android Studio 逻辑抽象和公共代码共享以便在不同的功能上重用并不是一个新概念，在现代计算的起步阶段就有了。相比之下，iOS和Android的出现才刚过10年，还处于起步阶段。 为什么我们需要跨平台解决方案? iOS和Android平台都非常复杂，开发者要在某一个平台上成为专家需要数年的时间。掌握每个平台需要懂得两种官方支持的编程语言、硬件知识、平台SDK和各种各样的支持库。希望同时支持iOS和Android应用程序的组织和公司必须至少要维持两个开发团队，因为同时拥有两个平台的丰富经验的开发人员是非常罕见的。两个开发团队都试图保持应用程序在两个平台的功能对等，在修补缺陷的同时仍然能够利用每个平台的优势，这就导致开发团队的进一步的碎片化。而具备平衡各个平台的复杂性，降低平台的冲突，有选择性地跨平台共享公共逻辑的能力，就能够使团队集中精力，为真正重要的用户提供所需的功能和价值。 用户体验 从用户的角度来看，移动体验是他们在移动应用上能够看到和交互的一切。用户并不知道或并不关心应用程序使用的语言、框架或者使用了何种web服务。用户与应用程序的交互是通过屏幕、通知、平台以及与蓝牙、传感器和摄像头等硬件的交互来进行的。苹果和谷歌都在各自的平台上进行了大量投资，并使其各具特色。每一次年度更新都会带给我们新的功能、新的API以及诸如手表、可弯曲电话、电视等等目标设备。 用户体验主要指的是UI和它与原生系统SDK的集成、以及性能和其他能力（如离线支持）。任何有使用限制，和在原生平台上需要额外抽象的移动框架都会阻碍开发人员充分利用整个平台的优势，从而导致用户体验受损或额外的开发开销。能够使一个应用程序别具特色并为用户带来价值的是用户与之交互的方面，如UI、Notification（通知）以及和系统其它部分的集成。而UI后面的应用层（如业务逻辑、REST端点、缓存、JSON序列化和依赖注入）则与平台的相关性并不大。 理想平台 一个理想的平台应该具备如下特点： 应该能够集成到现有平台构建工具链和持续集成的基础架构中应该能够以最小的代价，充分利用底层平台API和语言，尤其是面向用户的组件，如UI和Notification（通知）应该能够无缝集成，而不引入额外runtime的开销在IDE支持、编译器和lint代码检查方面提供一流的工具支持有成熟社区和第三方库的支持 Flutter（注：谷歌的移动UI框架） Flutter之于移动应用就像Silverlight之于Web应用一样。它整合了自己的库、语言和页面渲染。Flutter是由谷歌的一个独立于Android的团队开发的，它使用DART编程语言，目标是通过直接写入视图层，并提供自己的SDK，UI widget(小部件)，runtime和编程环境，来开发出一个通用的开发平台和SDK。Flutter的主要目的是取代而不是扩充Android和SDK框架。它的主要应用场景是希望以一致的UI界面运行在多个平台上的新的待开发的项目。虽然Flutter可以提供高性能体验，但是对于期望使用每个平台独特功能的复杂应用，跨平台提供一致的外观和体验是很有挑战性的。巧合的是，最受欢迎和讨论最多的Flutter应用程序之一，Hamilton并没有使用Material或Cupertino组件。 Dart：谷歌之外很少见到的小众编程语言。现有开发人员需要重新培训，招募新人不容乐观。 Flutter SDK：目标是替换而不是补充原生SDK。 React Native React是一个由Facebook开发的Javascript UI框架，用于开发现代单页web应用（SPA）。React使用声明性的方式描述UI。由于更新DOM树的成本很高，框架将接收到所需的UI作为输入，而React框架将比较新旧DOM之间的差异，并且只执行所需的更新。 React Native使用React框架。但是它的目标不再是HTML，而是原生Android和iOS平台的SDK。React Native Javascript的runtime将通过bridge（桥接器）与原生框架异步通信。虽然它的目标是给两个提升平台提供最好的框架，但结果是喜忧参半的。React Native的最大贡献是它充分利用并增强了底层移动平台，而没有取代它们。 React Native的主要缺点 Javascript：不管你是爱它还是恨它，Javascript已经成为最流行的语言之一，但它会引入第三方语言生态系统。要想在iOS和Android上成功部署或调试一个复杂功能，开发人员必须了解第三方语言和runtime。这种级别的抽象还引入了另一个要调试和支持的层。 Bridge（桥接器）：原生模块和本机代码之间的任何通信都是通过桥接器完成的。这可能导致复杂的集成，并带来性能损失。 依赖项：React Native引入了许多依赖项，导致无法在Android上支持X64等问题。React Native是一个大型平台，它在原生平台上引入了许多限制，从而导致安全性和可维护性问题。 Kotlin Native Kotlin Native是由Kotlin编程语言的创建者Jetbrains开发的一个编译器和一组库。Kotlin Native旨在通过将代码编译成原生二进制文件并尽可能与原生平台紧密集成来解决代码共享问题，减少冲突，它并不是引入另一个runtime、语言或工具链。谷歌已经宣布将Kotlin作为Android开发的官方语言，因此大多数Android团队都公开接受它。不过，Kotlin对iOS开发来说显然是一门外语，但它与Swift、JavaScript和DART语言的相似性增加了它的内聚力。 与其他竞争框架相比，Kotlin Native的主要优势在于GUI、传感器、Notification以及每种设备独特的内容都能以原生语言开发和无限制的运行平台。与Flutter和React Native的解决方案相比，Kotlin Native解决方案减少了障碍并避免了损害。 在Android上，公共模块使用原生构建工具组装到最终的APK中。在iOS上，公共模块被编译到单个原生库中，并使用原生构建工具链和原生IDE组装到应用程序中。与React Native类似，Kotlin Native将尝试利用底层平台，并使开发人员能够基于特性或组件定义Seam，以及决定哪些特性应在特定平台或者在Kotlin Native上开发。Kotlin Native提供一个选项但并不强迫跨平台共享代码。 总结 移动计算的历史是一个代码分享和站在巨人肩膀上的历史。随着手机在我们的日常生活中变得越来越强大和无处不在，我们构建的移动应用将会越来越多，越来越复杂。能够跨平台共享代码在未来将变得更加重要。Kotlin Native仍然是早期的测试版，并非没有问题和挑战，但无论如何，它都将成为未来跨平台开发最实用的解决方案。
-
发表了文章 2022-01-28
豆瓣评分9.5,哈佛、斯坦福、普林斯顿等都在用的算法经典教材
先看看作者吧，Jon Kleinberg是美国国家科学院（NAS）、美国国家工程院（NAE）、美国人文与科学院（AAAS）三料院士，在计算机科学领域是“传说级”的人物。而且他还获得过国际数学家大会颁发“奈望林纳奖”，这个奖是数学家大会为了表彰信息科学方面的重要数学贡献而设的。——来自豆瓣 算法设计 作者乔恩·克莱因伯格（Jon Kleinberg） 是康奈尔大学计算机科学教授。他于 1996 年从麻省理工学院获得博士学位。他荣获过美国国家科学基金会事业奖 （NSF Career Award）、海军研究局青年研究员奖（ONR Young Investigator Award）、IBM 杰出创新奖（IBM Outstanding Innovation Award）、美国国家科 学院创新研究奖（National Academy of Sciences Award for Initiatives in Research），还获得过帕卡德基金会（Packard Foundation）和斯隆基金会（Sloan Foundation）的研究基金以及康奈尔工程学院与计算机科学系教学奖。 克莱因伯格的研究集中在算法上，特别是与网络结构和信息相关的算法，以及这些算法在 信息科学、优化、数据挖掘及计算生物学等方面的应用。他利用信息中心和权威信息进行网络 分析的工作，对形成最新一代因特网搜索引擎的基础起了很大的作用。 >>>> 正如书名所言，这本教材通篇都在讲述“如何针对具体问题设计算法”。 很喜欢这本书场景引出问题=>设计算法解决=>分析算法的结构，让人对问题所描述的内容更感兴趣，对算法所应用的场景印象也更加深刻。 以动态规划这个主题而言，在第一章就通过“如何高效分配会议室等资源”这个问题来引出具体算法：如果通过资源利用时长来衡量那么贪心算法显然是最符合直觉的；但如果引入了“权重”这个概念，那么贪心算法就不够用了。解决“加权区间调度”问题的更好方式是动态规划。 在第六章先以递归暴力求解，再优化、分析这个算法，进而抽象出动态规划的特征：先解决“多项式”个子问题、再从子问题的解计算出原始问题的解——来自豆瓣 >>>> 这本书不光细节满满，每章后面的带解答练习更是点睛之笔，一般书中的习题答案要么是最后解，要么简单的分析，这本书的建议解答几乎把每一个点都写在书中，让人更容易理解其意。 本书带入的算法研究，始于各种计算应用程序中出现的问题，构建在对算法设计技术理解基础之上，最终得到这些问题的有效解决方案。——来自豆瓣 >>>> 本书是IT人员改变码农身份和命运的力作，特别是立志于SDN和智能化网络管理系统设计和研发的IT人员应该要好好研读的佳作。——来自豆瓣 算法设计 这是一本被众多名校采用的算法设计课程教材，强调用实际示例阐明枯燥的算法理论，更注重算法设计思路而非算法复杂度分析。本书采用新颖的教学方式，通过分析真实世界的问题来激发算法思想。两位作者以一种清晰、直接的方式，指导学生自己分析和定义问题，并从中找出适用于给定场景的算法设计原则。本书鼓励读者更深入地理解算法设计过程，探索算法在计算机科学的更广阔领域中的应用。 本书具有以下特色： 强调问题分析和设计方法； 遵循结构化教学法，引导学生掌握问题形式化、算法设计和算法分析的全过程； 通过一系列带解答的问题，展示计算机科学家设计和应用算法的过程； 包含 200 多道作业题，其中一些题目出自 Yahoo! 和 Oracle 等公司； 提供广泛用于处理 NP 困难问题和随机应用的算法，这些是极其重要的算法主题。 算法这一主题是一个强大的“镜头”，透过 它可以查看计算机科学领域。算法问题构成了计算机科学的核心， 但它们很少以整洁、精确的 数学问题的形式出现。相反， 它们往往有许多杂乱的、应用程序特定的细节，由一些至关重要 和一些无关紧要的东西纠缠在一起。因此， 算法问题由两个基本部分组成：得到数学上整洁的 问题核心， 然后根据问题结构确定适当的算法设计技术。这两个部分相互影响： 越能自如地运 用各种可能的设计技术， 也就越能认识到世上混乱问题中的整洁形式描述。在最有效的情况下， 算法思想不但能提供适当问题的解决方案， 而且它们构成了一种语言， 让你可以清晰地表达基 本问题。 本书的目标是将这种方法带入算法研究，作为一个设计过程，它始于各种计算应用程序中 出现的问题，构建在对算法设计技术理解的基础之上，最终得到这些问题的减肥解决方案。我 们试图探讨算法思想在计算机科学中的作用，并将这些思想与一些精确制定的问题联系起来， 我们可以为它们设计算法并进行分析。换言之，导致这些问题的根本问题是什么？如何选择这 些特定的方式来描述它们？如何认识到不同情况下适用哪些设计原则？ “这（本书）是我看过的非常优秀的本科生教材，我认为它将为算法教材的新时代奠定基础……（它采用）新颖的教学方式，更强调算法的设计，并且配有丰富的练习。” ——Dieter van Melkebeek，威斯康星大学麦迪逊分校 “这本书完美融合了直觉和严密性，包含了计算机科学所有领域的各种奇妙的应用，并且提供了独特的问题分析和算法设计方法……” ——Anna R. Karlin，华盛顿大学 “两位作者将算法思想与真实问题联系起来的工作极其了不起，并且完成得非常精彩。” ——Michael Mitzenmacher，哈佛大学 第 1章 引言：一些典型问题 1 1．1 第 一个问题：稳定匹配 1 1．2 5个典型问题 8 带解答的练习 12 练习 14 注释和进一步阅读 17 第 2章 算法分析基础 18 2．1 计算可解性 18 2．2 增长的渐近阶 21 2．3 用列表和数组实现稳定匹配算法 26 2．4 常见运行时间综述 29 2．5 更复杂的数据结构：优先队列 35 带解答的练习 40 练习 41 注释和进一步阅读 44 第3章 图 45 3．1 基本定义和应用 45 3．2 图连通性和图遍历 48 3．3 用队列和栈实现图遍历 53 3．4 二分性测试：广度优先搜索的应用 58 3．5 有向图中的连通性 59 3．6 有向无环图和拓扑排序 61 带解答的练习 64 练习 66 注释和进一步阅读 69 第4章 贪心算法 70 4．1 区间调度：贪心算法保持领先 70 4．2 最小化延迟的调度：交换论证 76 4．3 最优缓存：更复杂的交换论证 80 4．4 图的最短路径 83 4．5 最小生成树问题 87 4．6 实现Kruskal算法：Union-Find数据结构 92 4．7 聚类 97 4．8 哈夫曼码和数据压缩 99 *4．9 最小开销树形图：多阶段贪心算法 109 带解答的练习 113 练习 116 注释和进一步阅读 125 第5章 分治 127 5．1 第 一个递推式：归并排序算法 127 5．2 进一步的递推关系 130 5．3 计数逆序 134 5．4 寻找最近点对 137 5．5 整数乘法 141 5．6 卷积和快速傅里叶变换 142 带解答的练习 148 练习 150 注释和进一步阅读 152 第6章 动态规划 153 6．1 加权区间调度：递归过程 153 6．2 动态规划原理：备忘录或子问题迭代 157 6．3 分段最小二乘：多重选择 159 6．4 子集和与背包：加一个变量 162 6．5 RNA二级结构：区间上的动态规划 166 6．6 序列比对 169 6．7 通过分治在线性空间中序列比对 173 6．8 图中的最短路径 177 6．9 最短路径和距离向量协议 182 *6．10 图中的负环 184 带解答的练习 187 练习 190 注释和进一步阅读 204 第7章 网络流 205 7．1 最大流问题和Ford-Fulkerson算法 205 7．2 网络中的最大流和最小割 211 7．3 选择好的增广路径 214 *7．4 预流推进最大流算法 218 7．5 第 一个应用：二分匹配问题 225 7．6 有向图和无向图中的不相交路径 228 7．7 最大流问题的扩展 232 7．8 调查设计 236 7．9 航空公司调度 237 7．10 图像分割 240 7．11 项目选择 243 7．12 棒球排除 246 *7．13 进一步的方向：为匹配问题增加开销 249 带解答的练习 253 练习 255 注释和进一步阅读 274 第8章 NP和计算难解性 276 8．1 多项式时间归约 276 8．2 通过“小配件”归约：可满足性问题 280 8．3 有效证书和NP的定义 283 8．4 NP完全问题 285 8．5 排序问题 289 8．6 划分问题 294 8．7 图着色 297 8．8 数值问题 300 8．9 co-NP和NP的不对称性 303 8．10 困难问题的部分分类 305 带解答的练习 307 练习 309 注释和进一步阅读 323 第9章 PSPACE：NP之外的一类问题 324 9．1 PSPACE 324 9．2 PSPACE中的一些难题 325 9．3 在多项式空间中求解量化问题和博弈 327 9．4 在多项式空间中求解规划问题 328 9．5 证明问题是PSPACE完全的 331 带解答的练习 334 练习 335 注释和进一步阅读 336 第 10章 扩展易解性的界限 337 10．1 寻找小的顶点覆盖 338 10．2 求解树上的NP困难问题 340 10．3 圆弧集着色 343 *10．4 图的树分解 349 *10．5 构造树分解 356 带解答的练习 361 练习 363 注释和进一步阅读 365 第 11章 近似算法 366 11．1 贪心算法和最优值的界限：负载均衡问题 366 11．2 中心选址问题 370 11．3 集合覆盖：一般贪心启发式 374 11．4 定价方法：顶点覆盖 378 11．5 用定价方法最大化：不相交路径问题 382 11．6 线性规划和舍入：顶点覆盖的应用 386 *11．7 再论负载均衡：更高级的LP应用 390 11．8 任意好的近似：背包问题 394 带解答的练习 398 练习 399 注释和进一步阅读 404 第 12章 局部搜索 406 12．1 优化问题的地形 406 12．2 Metropolis算法和模拟退火算法 409 12．3 局部搜索在Hopfield神经网络中的应用 412 12．4 通过局部搜索的最大割近似 415 12．5 选择邻居关系 417 *12．6 用局部搜索分类 418 12．7 最优响应动态和纳什均衡 423 带解答的练习 430 练习 431 注释和进一步阅读 433 第 13章 随机算法 434 13．1 第 一个应用：消除争用 435 13．2 寻找全局最小割 438 13．3 随机变量及其期望 442 13．4 MAX 3-SAT的随机近似算法 445 13．5 随机分治：找中位数和Quicksort 447 13．6 哈希：字典的随机实现 452 13．7 寻找最近点对：随机方法 457 13．8 随机缓存 462 13．9 切尔诺夫界 467 13．10 负载均衡 468 13．11 分组路由 470 13．12 背景知识：一些基本概率定义 474 带解答的练习 479 练习 483 注释和进一步阅读 489 后记：永远运行的算法 491 参考文献 497
-
发表了文章 2022-01-28
大多数程序员都不知道的6个YAML功能
提升您的YAML知识以编写更清晰的YAML文件大多数程序员都不知道的6个YAML功能 YAML是一种常用于数据序列化的文件格式。有大量使用YAML文件进行配置的项目，例如Docker-compose，pre-commit，TravisCI，AWS Cloudformation，ESLint，Kubernetes，Ansible等。了解YAML的功能可以帮助您实现所有这些功能。 让我们先介绍一下基础知识：YAML是JSON（源）的超集。每个有效的JSON文件也是一个有效的YAML文件。这意味着您拥有所有期望的类型：整数，浮点数，字符串，布尔值，空值。以及序列和图。根据您的编程语言，您可能说“ array”或“ list”而不是序列，而说“ dictionary”而不是map。 通常看起来像这样： mysql: host: localhost user: root password: something preprocessing_queue: # Line comments are available! - name: preprocessing.scale_and_center width: 32 height: 32 - preprocessing.dot_reduction use_anonymous: true等效符号 YAML有很多等效的编写方法： list_by_dash: - foo - bar list_by_square_bracets: [foo, bar] map_by_indentation: foo: bar bar: baz map_by_curly_braces: {foo: bar, bar: baz} string_no_quotes: Monty Python string_double_quotes: "Monty Python" string_single_quotes: 'Monty Python' bool_english: yes bool_english_no: no bool_python: True bool_json: true 这里有些警告： language: no # ISO 639-1 code for the Norwegian language 此否被解释为false。您需要输入“ no”或“ no”。 通常，我建议像布尔值JSON一样使用true和false，但是YAML支持11种写布尔值的方法。如果您想对字符串使用引号，我也将像JSON一样使用“。您仍然需要记住” no“，但是至少该文件看起来对YAML初学者更熟悉。 正如汤姆·里奇福德（Tom Ritchford）所指出的，还有更多类似的古玩案例： 013映射到11，因为前导零触发八进制表示法4:30映射到270。Max Werner Kaul-Gothe和Niklas Baumstark告诉我，这被自动转换为分钟（或秒？），因为它被解释为持续时间：4 * 60 + 30=270。有趣的是，这种模式仍然可以在1：1：1：1：1：1：1：1：4：30的情况下“工作”。长字符串 disclaimer: > Lorem ipsum dolor sit amet, consectetur adipiscing elit. In nec urna pellentesque, imperdiet urna vitae, hendrerit odio. Donec porta aliquet laoreet. Sed viverra tempus fringilla. 这等效于以下JSON（为便于阅读，添加了换行符；请忽略它们）： {"disclaimer": "Lorem ipsum dolor sit amet, consectetur adipiscing elit. In nec urna pellentesque, imperdiet urna vitae, hendrerit odio. Donec porta aliquet laoreet. Sed viverra tempus fringilla."} 多行字符串 mail_signature: | Martin Thoma Tel. +49 123 4567 这等效于JSON： {"mail_signature": "Martin Thoma Tel. +49 123 4567"} 请注意如何忽略前导空格。第一行（“ Martin Thoma”）确定忽略的前导空白的数量。 锚 email: &emailAddress "info@example.de" id: *emailAddress 这等效于以下JSON： {"email": "info@example.de", "id": "info@example.de"} ＆定义了一个变量emailAddress，其值为“ info@example.de。然后，*表示紧随其后的是变量名。 您可以对映射执行相同的操作： foo: &default_settings db: host: localhost name: main_db port: 1337 email: admin: admin@example prod: *default_settings dev: *default_settings 这使： { "dev": { "db": {"host": "localhost", "name": "main_db", "port": 1337}, "email": {"admin": "admin@example"}}, "foo": { "db": {"host": "localhost", "name": "main_db", "port": 1337}, "email": {"admin": "admin@example"}}, "prod": { "db": {"host": "localhost", "name": "main_db", "port": 1337}, "email": {"admin": "admin@example"}}} 现在，您可能想在开发和生产设置中插入密码。您可以使用合并键<<来做到这一点： foo: &default_settings db: host: localhost name: main_db port: 1337 email: admin: admin@example prod: <<: *default_settings app: port: 80 dev: *default_settings 等效于以下JSON： { "foo": { "db": {"host": "localhost", "name": "main_db", "port": 1337}, "email": {"admin": "admin@example"}}, "prod": { "app": {"port": 80}, "db": {"host": "localhost", "name": "main_db", "port": 1337}, "email": {"admin": "admin@example"}}, "dev": { "db": {"host": "localhost", "name": "main_db", "port": 1337}, "email": {"admin": "admin@example"}},}类型转化 双重爆炸！在YAML中有特殊含义。它被称为“第二标签句柄”和！tag：yaml，2002 :（源）的简写。 您可以像这样进行简单的转换： price: !!float 42 id: !!str 42 或更复杂的内容，例如映射到直接在YAML中未指定的默认Python类型： tuple_example: !!python/tuple - 1337 - 42 set_example: !!set {1337, 42} date_example: !!timestamp 2022-12-31 您可以这样阅读： import yaml import pprint with open("example.yaml") as fp: data=fp.read() pp=pprint.PrettyPrinter(indent=4) pased=yaml.unsafe_load(data) pp.pprint(pased) 你会得到这个： { 'date_example': datetime.date(2022, 12, 31), 'set_example': {1337, 42}, 'tuple_example': (1337, 42)} 本示例使用特定于Python的标记!! python / tuple和一些标准的YAML标记。PyYaml有一个不错的概述： ## Standard YAML tags YAML Python 3 !!null None !!bool bool !!int int !!float float !!binary bytes !!timestamp datetime.datetime !!omap, !!pairs list of pairs !!set set !!str str !!seq list !!map dict ## Python-specific tags YAML Python 3 !!python/none None !!python/bool bool !!python/bytes bytes !!python/str str !!python/unicode str !!python/int int !!python/long int !!python/float float !!python/complex complex !!python/list list !!python/tuple tuple !!python/dict dict ## Complex Python tags !!python/name:module.name module.name !!python/module:package.module package.module !!python/object:module.cls module.cls instance !!python/object/new:module.cls module.cls instance !!python/object/apply:module.f value of f(...) 请注意，加载非标准标签是不安全的！可以使用!! python / object / apply：module.f执行任意代码。在PyYaml中，您需要yaml.unsafe_load才能使用它。因此，您可能不应该使用它！ 一个YAML中的多个文档 YAML中的三个破折号分别表示文档： foo: bar --- fizz: buzz 在Python中，您可以使用PyYAML像这样加载它： import yaml with open("example.yaml") as fp: data=fp.read() parsed=yaml.safe_load_all(data) # parsed is a generator 如果将已分析的内容转换为列表并打印出来，则会得到： [{'foo': 'bar'}, {'fizz': 'buzz'}] 请注意，这不是写列表的替代符号。是不同的文件。 静态站点生成器Pelican使用它来区分元数据和内容。我还没有看到其他任何使用此功能的应用程序。编辑：Clemens Tolboom提醒我，静态网站生成器Jekyl也使用它。Chairat Onyaem（Par）指出oc进程也会生成此类YAML。谢谢你的评论！ 下一步是什么？ 有很多配置文件格式，例如TOML，INI，JSON，XML，dotenv，以及数据序列化格式，例如Pythons pickle，HDF5，Numpys NPZ，XML。如果您有兴趣了解其中一个的更多信息，请告诉我！
-
发表了文章 2022-01-28
程序员如何用Python编程暴力算法破解凯撒密码
破解凯撒密码可以用到一项密码分析技术，叫作暴力算法（brute-force），它的攻击是通过尝试每一种可能解密密文的密钥实现的。没有什么能够阻挡密码分析人员猜测密钥、用密钥解密密文、观察输出，并在没能破解出密文的情况下寻找下一把密钥。正因为这样的暴力算法对凯撒密码来说过于有效，所以在实际应用中根本不应该使用凯撒密码去加密一段秘密信息。 在理想的情况下，一段密文不会落入任何人的手中，然而Kerckhoffs原则（以19世纪密码学家Auguste Kerckhoffs命名）表明，一段密文即使在所有人都知道来源且某些人可能得到的情况下，也应该保持其安全性。20世纪时，数学家Claude Shannon在《香农格言》（Shannon's maxim）中重新提出了这个原则，即“敌人了解系统”。在密码算法中，是密钥保证了信息的机密性，而在凯撒密码中，密钥的信息非常容易被发现。 本章要点Kerckhoffs原则和香农格言。暴力算法技术。range()方法。字符串标准化（字符串插值）。 选中 File New File，打开一个新的编辑窗口，将下列代码输入编辑窗口并将其存储为caesarHacker.py。随后，如果读者的计算机中没有pyperclip.py模块，则可以下载它并将它放置在与caesarHacker.py相同的路径下（同一个文件夹中），该模块将在caesarHacker.py文件中被引入。 结束文件配置后，按 F5键执行程序，如果代码中出现了报错或其他问题，请仔细比对书上代码和文件中代码有何不同。 caesarHacker.py 1. # 凯撒密码破解 2. (BSD Licensed) 3. 4. message = 'guv6Jv6Jz!J6rp5r7Jzr66ntrM' 5. SYMBOLS = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz12345 67890 !?.' 6. 7. # 循环遍历所有可能的关键字 8. for key in range(len(SYMBOLS)): 9. # 将translated设置为空字符串很重要，这样可以清除上一个迭代中 10. # translated的值 11. translated = '' 12. 13. # 程序的其余部分与凯撒程序几乎相同 14. 15. # 循环遍历message中的每一个字符 16. for symbol in message: 17. if symbol in SYMBOLS: 18. symbolIndex = SYMBOLS.find(symbol) 19. translatedIndex = symbolIndex - key 20. 21. # 执行回环 22. if translatedIndex < 0: 23. translatedIndex = translatedIndex + len(SYMBOLS) 24. 25. # 添加解密的字符 26. translated = translated + SYMBOLS[translatedIndex] 27. 28. else: 29. # 添加未加/解密的字符 30. translated = translated + symbol 31. 32. # 显示每一个可能的解密值 33. print('Key #%s: %s' % (key, translated)) 注意，本段代码有很大一部分和原始的凯撒密码程序相同，这是因为凯撒密码的破解程序使用了和加密一样的步骤去解密信息。 运行凯撒密码的破解程序，将会得到如下输出。它使用全部66种可能的密钥解密密文“guv6Jv6Jz!J6rp5r7Jzr66ntrM”，将其成功破解。 Key #0: guv6Jv6Jz!J6rp5r7Jzr66ntrM Key #1: ftu5Iu5Iy I5qo4q6Iyq55msqL Key #2: est4Ht4Hx0H4pn3p5Hxp44lrpK Key #3: drs3Gs3Gw9G3om2o4Gwo33kqoJ Key #4: cqr2Fr2Fv8F2nl1n3Fvn22jpnI --snip-- Key #11: Vjku?ku?o1?ugetgv?oguucigB Key #12: Uijt!jt!nz!tfdsfu!nfttbhfA Key #13: This is my secret message. Key #14: Sghr0hr0lx0rdbqds0ldrrZfd? Key #15: Rfgq9gq9kw9qcapcr9kcqqYec! --snip-- Key #61: lz1 O1 O5CO wu0w!O5w sywR Key #62: kyz0Nz0N4BN0vt9v N4v00rxvQ Key #63: jxy9My9M3AM9us8u0M3u99qwuP Key #64: iwx8Lx8L2.L8tr7t9L2t88pvtO Key #65: hvw7Kw7K1?K7sq6s8K1s77ousN 由于第13把密钥得到的输出是标准的英文，因此可以断定原始的加密密钥就是第13把密钥。 破解程序生成了变量message，用于存储需要解密的密文字符串，常量SYMBOLS则包含了所有可以被加密的字符。 1. # 凯撒密码破解 2. # (BSD Licensed) 3. 4. message = 'guv6Jv6Jz!J6rp5r7Jzr66ntrM' 5. SYMBOLS = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz12345 67890 !?.' SYMBOLS的值需要和凯撒密码加密程序中使用的SYMBOLS的减肥值完全相同，同时待破解的密文正是由该加密程序得来；否则，破解程序将失效。注意，SYMBOLS字符串中的 0 和 ! 之间有一个空格。 第8行使用了一个for循环，然而它并没有在一个字符串值上进行迭代，而是在调用range()方法的返回值上进行迭代。 7. # 循环遍历所有可能的关键字 8. for key in range(len(SYMBOLS)): range()方法接收一个整型参数，并返回range数据类型的值。这种数据类型的值可以在for循环中用于进行指定次数的循环，循环次数由传递给range()方法的整数决定。尝试下面的例子，将下列代码输入交互式运行环境中。 >>> for i in range(3): ... print('Hello') ... Hello Hello Hello 由于将整数3传递给了range()方法，因此for循环将进行3次循环。 更确切地说，range()方法返回的range值会将for循环的变量值设置为0～输入的参数值（不包含后者），例如，将下列代码输入交互式运行环境中。 >>> for i in range(6): ... print(i) ... 这段代码将变量i的值设置为0～6（不包含6），与caesarHacker.py文件的第8行类似——文件的第8行将key的值设置为0～66（不包含66）。为了避免将66直接硬编码到程序中，程序使用了len（SYMBOLS）的返回值，因此即使改变SYMBOLS的值，程序的运行也不会受到影响。 程序首次执行到循环时，key被设置为0，message中的密文被密钥0解密（当然，如果0并不是真正的密钥，message会被解密为乱码）。for循环内部的第9～31行代码用于解密，并且与原始的凯撒密码加密程序类似，之后会对其进行解释。程序执行到下一次对for循环的迭代时，key被设置为1，继续进行解密。 尽管这个程序中没有用到，读者还是可以尝试向range()方法中传递两个整型参数，而不像本程序中只使用了一个。第1个参数是range的起始值，第2个参数则是range的终值（range从起始值开始取值，但并不会取到终值），两个参数用逗号隔开。 >>> for i in range(2, 6): ... print(i) ... 变量i的取值为2～6（含2而不含6）。 for循环之下用于解密的代码，每次执行都将解密后的文本添加到translated字符串的末尾。在第11行，translated被置为空字符串。 7. # 循环遍历所有可能的关键字 8. for key in range(len(SYMBOLS)): 9. # 将translated设置为空字符串很重要，这样可以清除上一个迭代中 10. # translated的值 11. translated = '' 在for循环的开始将translated置空非常重要，如果不这么做，则本次尝试的密钥解密出的文本将被添加到上一次迭代后生成的字符串后面。 第16～30行和第5章中的凯撒密码加密程序几乎是相同的，但是要比第5章中的代码更简单一些，因为它们只被用作解密。 13. # 程序的其余部分与凯撒程序几乎相同 14. 15. # 循环遍历message中的每一个字符 16. for symbol in message: 17. if symbol in SYMBOLS: 18. symbolIndex = SYMBOLS.find(symbol) 在第16行中，程序循环遍历了message中存储的每一个字符。每经过一次循环迭代，第17行就检查symbol是否存在于常量SYMBOLS中，如果存在，就对其进行解密。第18行的find()方法对symbol在SYMBOLS中的位置进行确定，并将这个位置的值记录在变量symbolIndex中。 随后，第19行从symbolIndex中减去key值进行解密。 19. translatedIndex = symbolIndex - key 20. 21. # 执行回环 22. if translatedIndex < 0: 23. translatedIndex = translatedIndex + len(SYMBOLS) 减法操作可能会导致translatedIndex的值小于0，这时就需要回到常量SYMBOLS的开头去寻找解密出的字符位置。第22行对可能的情况进行判断，如果出现了translatedIndex值小于0的情况，就为其加上66［len（SYMBOLS）的返回值］。 translatedIndex的值改变后，SYMBOLS[translatedIndex]就可以获取解密得到的字符了。第26行将这个字符添加到translated存储的字符串末尾。 25. # 添加解密的字符 26. translated = translated + SYMBOLS[translatedIndex] 27. 28. else: 29. # 添加未被加/解密的字符 30. translated = translated + symbol 如果symbol的值没有在SYMBOLS中找到，则第30行将把它保持不变地添加到translated的结尾。 虽然第33行是凯撒密码破解程序中唯一的一个print()方法，但它会得到多行执行结果，这是因为第8行的for循环每进行一次迭代，它就将被调用一次。 32. # 显示可能的解密值 33. print('Key #%s: %s' % (key, translated)) print()方法中的参数是一个使用了字符串标准化（string formatting，也叫作字符串插值）的字符串。字符串标准化使用%s将一个字符串放置到另一个字符串当中，在这个字符串的结尾，第1个%s被括号中的第一个值替换。 将下列代码输入交互式运行环境。 >>> 'Hello %s!' % ('world') 'Hello world!' >>> 'Hello ' + 'world' + '!' 'Hello world!' >>> 'The %s ate the %s that ate the %s.' % ('dog', 'cat', 'rat') 'The dog ate the cat that ate the rat.' 本例中，首先将字符串world插入字符串“Hello %s!”，替换掉%s。这个过程和连接起%s之前、待插入的字符串、%s之后这三部分文本的过程是类似的，当需要插入多个字符串的时候，%s按照这些字符串的顺序被依次替换。 字符串标准化往往比使用 + 操作符对字符串进行连接更便于输入，尤其是在面对长字符串的情况下。同时，与字符串连接不一样的是，使用字符串标准化甚至可以将非字符型的值（如整型）插入字符串中。将如下代码输入交互式运行环境。 >>> '%s had %s pies.' % ('Alice', 42) 'Alice had 42 pies.' >>> 'Alice' + ' had ' + 42 + ' pies.' Traceback (most recent call last): File "", line 1, in TypeError: Can't convert 'int' object to str implicitly 使用字符串插值的时候，整数42可以非常顺利地插入字符串中，然而如果想要通过字符串连接将它插入字符串中，就会出现报错。 caesarHacker.py文件的第33行使用字符串标准化生成了一个包含变量key和translated的字符串。由于key中存储的是一个整数的值，因此使用字符串标准化就可以将它作为字符串的值传递到print()方法中了。 凯撒密码的致命弱点在于，用于加密的密钥并没有太多种可能性，任何计算机都可以轻易使用全部66种可能的密钥解密信息，密码分析人员只需要花几秒钟的时间浏览解密后的内容，就可以找到其中符合英文语法的一项。要使消息更安全，需要一种拥有更多可能密钥的算法，而在第7章中，移位密码就可以提供这样的安全性。
-
发表了文章 2022-01-27
从 React 的视角谈谈 Rust 和 GTK
最近我尝试了多种框架，想要制作出既易用又容易安装的应用程序，但是都以失败告终；最后我决定转向 Rust 和 GTK，开始拥抱原生软件开发。 虽说以前我也短暂尝试过 GTK，但它对我来说还是很陌生的。在此之前，我在用户界面上的大部分经验都来自于 React 应用程序的构建。从 React 到 GTK 的过渡带来了一些挑战，其中多数是小部件原理上的差异造成的。用 Rust 写 GTK 是尤其困难的事情，因为 Rust 强制执行一些额外的规则来防止内存管理错误，并避免在线程上下文中执行不安全的操作。 在本文中，我将主要讨论如何将 React 的理念应用到 GTK 中，并重点介绍一些使 GTK 符合 Rust 规则所必需的技巧。Rust 制订了一些不好对付的强制规则，这些规则对于大多数开发人员来说都是陌生的；规则主要涉及值的共享方式，但在可变性方面也有严格的限制。我将在本文中遇到这些场景时指出它们。 本文中的所有示例均来自 FitnessTrax，这是一款遵循隐私优先原则的健身追踪应用程序。用户可以在他们的 PC 上的一处存储空间内收集健身和生物识别数据，而不必依赖那些可能无法持续保护用户数据的公司。 关于这款应用程序的外观我要说句抱歉，因为 0.4 版发布的时候，我还没去花时间了解 GTK 是如何处理样式的。我保证会尽快改进用户界面。 Conrod是针对 Rust 的一个图形工具包，它试着将函数式响应编程技术应用到了图形编程上；它的开发者它描述了两种有着明显区别的图形组件管理模式。在大多数原生图形编程采用的古玩通用模式，亦即“保留模式（retained mode）”下，开发人员将创建一个个屏幕组件，然后在它们的整个生命周期内一次次更新。在“立即模式（immediate mode）”下，组件将具有一个绘制（draw）方法，其中组件会立即实例化自身的所有子级。然后，框架将对比这棵树与上一棵树，来判断该如何更新屏幕。 React 完全运行在即时模式下，而 GTK 完全运行在保留模式下。在 Web 开发行业中流行的数据可视化库 D3也可以运行在保留模式下。2018 年，我写了一篇关于 React 和 D3 之间对接的文章。 与 Redux 或 Apollo-GraphQL搭配的 React 实现了函数式响应编程（FRP）的一些理念，让它可以自动处理传播到组件的数据更改。我入门 FRP 时看的是 Elise Huard 写的一本书“Haskell 中的游戏编程”。时至今日这本书可能已经过时了，但在 Haskell 中特定的某个 FRP 库的背景下，它确实很好地介绍了这种理念。不幸的是，FRP 尚未在 React 之外得到广泛采用。虽说至少有一个可用于 Rust 的 FRP 库，但在撰写本文时，对于我来说采用它还为时过早。因此，凭借一些创造力和我在 React 领域的经验，我设计了一些类似于 FRP 范式的机制。 一些术语的注释： 小部件（widget）是一个 GTK 对象，代表屏幕上的某些内容。它可以是一个窗口、按钮、标签或一个布局容器。GTK 小部件只能将其他 GTK 小部件作为自身的子级。组件是屏幕上一个部分的任意逻辑抽象。在简单的情况下，它会是一个从某个函数返回的 GTK 小部件。在更复杂的情况下，它可能是包含一个或多个小部件的结构。组件不一定必须传递给 GTK 函数。结构组件始终提供一个’widget’字段，其代表这个组件的根小部件。 所有组件中最简单的，就像 React 组件一样是一小组小部件，这些小部件创建后就永远不会更新。这可以简单地实现为返回一个 GTK 小部件的函数。
-
发表了文章 2022-01-27
Mono 现状与未来： 从 Xamarin 到 WebAssembly、Blazor 及.NET 5
本文要点： Mono 项目始于 2001 年，是首个面向.NET 应用程序的多平台、开源框架的项目。Xamarin 和 Blazor 分别代表了微软在移动和 Web 应用程序方面的努力，它们都是基于 Mono 并由 Mono 提供支持的。.NET 5 为用户提供了两种运行时选项：高性能的 CoreCLR（用于服务器和桌面应用程序）和轻量级的 Mono（用于移动设备和 WebAssembly）。尽管 Mono 已经是.NET 的一部分了，但仍有一些开发工作要致力于改善 Mono 的运行时性能和垃圾回收器。现在.NET Core 可以与 Mono 并行安装了，因此可以一起演进语言和运行时。 去年，微软发布了它的计划，其中涉及.NET 未来以及.NET 5 的路线图。计划于今年年底发布下一个主要版本，该版本旨在提供一个基于.NET Core、.NET Framework、Xamarin 及 Mono 最佳部分的多平台、开源框架和运行时。 微软从 2014 年开始向.NET 开源发展，当时微软宣布.NET Core 即将开源。然而，在此之前，.NET 就已经有了一个名为 Mono 的开源计划。 Mono 项目始于 2001 年，最初它主要致力于为 Linux 桌面应用程序建立一个.NET 开发平台。第一次正式版本是在 2003 年发布的，此后该项目逐渐演进为在多个平台和操作系统上支持.NET。 Mono 是由 Xamarin 从 2011 年开始开发的。自从该公司被微软收购，并在 2016 年发布.NET Core 1.0 以来，Mono 和.NET Core 一直在并行开发。根据最新发布的版本，InfoQ 采访了 Miguel de Icaza（目前他就职于微软，是 Xamarin 的联合创始人，Mono 项目的原作者），讨论了 Mono 的现状及其在.NET 生态系统中的未来，以及 Xamarin 如何适合这种情况。 InfoQ：从技术上讲，.NET Core 和 Mono 之间的主要区别是什么？ Miguel de Icaza：Mono 是基于.NET Framework 的，.NET Framework 是作为 Windows 一部分发布的.NET 大版本。经过多年的发展，Mono 和.NET 都可以应用在不同的环境中。在.NET 领域中，这最终导致了.NET Core 3（这是所有未来工作和创新的基础）的发布，而.NET Framework 是一个长期维护的版本，它将继续被修复和调整。 但不会有任何重大的创新。 在 Mono 的世界里，运行时演进为支持我们所谓的“移动配置文件”，它是 API 的一个精选子集，适用于平衡用户需求与降低独立运行时部署的需求。这是 Xamarin .NET 努力的基础，也是最近 WebAssembly 工作的基础。 使用.NET 的不同场景以及使用它们的环境将开发人员必须使用的 API 集合分割开了。对于开发人员来说，没有一种简单的方法可以发布在所有平台上都可以工作的库二进制文件。 创建能够适用于所有不同环境的二进制库的愿望是创建.NET 标准的推动力——一个 API 的通用界面，可以在所有不同版本的.NET 上工作，无论是小型设备、移动系统，还是大型服务器。我们在这里所采取的方法是提出一套在所有平台上都可以平等使用的 API。但这仍然意味着我们要维护库的不同实现。 让.NET 的所有变体都能够相互操作的方法就是.NET Standard，.NET Standard 的每个新版本中都添加了更多的 API，所有运行时都能确保这些 API 是通用的。当今使用最广泛的 API 契约是 .NET Standard 2， .NET Framework、.NET Core、Xamarin 和 Mono 都支持该标准。 新的.NET Standard 2.1 版本引入了新的创新功能，但它们仅在 Mono、.NET Core 和 Xamarin 上可用，这是首个不被长期受支持的.NET Framework 所支持的.NET Standard 版本。 InfoQ：考虑到.NET Core 的最新成果以及.NET 5 的路线图，Mono 在当前状态的.NET 生态系统中地位如何？ de Icaza：简短的版本是，随着即将到来的.NET 5，用户将能够在所有平台上使用相同的 API 集合，并且可以选择运行时（CoreCLR 或 Mono）和编译系统（静态编译、JIT 编译、分层或解释）来解决其问题的特定需求。 使用.NET 5，我们统一了类库的实现，同时为用户提供了两种运行时选项。在较高的层次上，在 CoreCLR 中具有一个高吞吐量、高性能的运行时，还具有一个轻量级（但速度没有那么快）的 Mono 运行时。每个运行时都已针对它们最常使用的工作负载进行了调整：CoreCLR 用于服务器和桌面应用程序；Mono 用于移动和轻量级应用程序，例如 WebAssembly。 同样在.NET 5 中，我们将有一个统一的运行时，它可以在我们支持的所有平台上执行 C#或 F#代码。在某些平台上，用户将能够选择他们想要使用的运行时，而在其他平台上，将只有一个运行时可以使用。例如，对于 Windows 上的桌面应用程序，只有 CoreCLR 运行时适用，而对于 iOS，只有 Mono 运行时可用。 现在，从历史上看，Mono 具有两种执行和代码生成引擎。一种是我们称之为“mini”的代码生成器，它可以非常快速地生成本地代码，但是没有进行很多优化。为了实现更好的优化，Mono 过去一直都依赖 LLVM 优化编译器。 LLVM 以牺牲编译时间为代价，产生漂亮的、最优的、完善的代码。 此外，Mono 具有两种操作模式：一种是运行时在执行时动态生成代码（我们称之为 JIT 编译），另一种是运行时提前编译代码（基本上是静态编译）。提前（AOT）编译系统用于不允许动态代码生成的平台（例如 iOS 或视频游戏机），或者必须提高启动性能的平台（低端手机上的某些 Android 应用）。 Mono 可以在纯 JIT、混合 AOT/JIT 或 AOT 模式下运行，具体取决于平台的要求或用户的需求。因此，通常会使用 LLVM 提前编译一些核心库，例如，在保留用户代码可以动态编译 (JIT) 的情况下，为这些库生成最佳的代码。 需要纯 AOT 的系统有一个缺点，那就是.NET 的动态功能不可用（例如，动态实例化类型、使用 C# dynamic 关键字、或动态加载代码等）。因此，我们着手解决这个问题。 去年，我们在 Mono 中引入了一个新的执行引擎和模式——一个解释器。事实证明，该解释器非常有用，这不仅是因为它能够带来动态性（以前缺少动态性），允许我们将一个小的运行时部署到 WebAssembly，而且还能够使我们为用户带来一些“Hot”之类的功能，比如热加载和热重启。 一旦我们拥有三个具有不同配置的引擎，就有必要带来一个分层编译系统，该系统允许 Mono 运行时根据代码的使用方式动态调整要使用的代码生成引擎。并使用启动时间、内存使用率和长期性能。这是一个活跃的研究领域，我们也希望能够在该领域调整参数、学习或向用户提供解决方案。 .NET 5 的好处在于，.NET 5 的所有功能都可以在所有平台上使用，用户无需调整或更改任何内容。开箱即用的体验已经配置为全面匹配最佳可能的配置。 InfoQ：Xamarin 和 Blazor 有什么区别？ de Icaza：Xamarin 是我的初创公司，专注于帮助.NET 开发人员实现移动化。我们使用 Xamarin 作为一系列产品的品牌，从开发工具到在线服务都使用该品牌。到目前为止，在线服务已被整合到 Azure DevOps 中了。 Xamarin 开发工具包括原生 SDK 和 Xamarin.Forms。原生 SDK 允许开发人员瞄准 Android 和 iOS，并使用.NET 平台中的所有原生功能。 Xamarin.Forms 是一个跨平台的 UI 工具包，它使开发人员可以一次定义其用户界面，并将相同的代码映射成目标减肥平台的本机习惯用法。Blazor 是一种通过 C#构建交互式 Web 应用程序的新方法，它将一些最易于使用和最受欢迎的 Web 开发模式引入到了.NET。 开发人员可以构建 Blazor 应用程序，并可以选择逻辑运行的位置，它可以运行在由 ASP.NET 提供支持的服务器上，也可以完全运行在客户端上（为此，我们使用 WebAssembly 在浏览器内部运行一个.NET 运行时）。值得注意的是，在 WebAssembly 上支持.NET 的工作，当时是由 Xamarin 的 Mono 团队完成的，但是编程模型完全是由 Blazor on WebAssembly 开发团队构思出来的。 Mono 只是提供了执行它们代码的方法。 InfoQ：是否可以将 Mono 与其他微软的.NET IDE（Visual Studio、VS Code 等）一起使用呢？ de Icaza：当然可以。尽管大多数问题都是在展望.NET 5 的未来，但是现在，在移动设备、Xamarin 上构建支持.NET 的应用程序，或构建针对 WebAssembly 的 Blazor 应用程序，Mono 都是它们的引擎。这些功能在 Visual Studio 和 Visual Studio Code 也是开箱即用的。 除了微软官方支持的配置之外，Mono（作为一个开源项目）仍然支持“ .NET Framework”兼容模式，并且可以与 Mac 上的 Visual Studio 或 Linux 上的 MonoDevelop 一起使用，以构建.NET Framework 应用程序。 这的确是我业余时间做的一些工作，比如 TensorFlowSharp、TorchSharp（PyTorch for .NET 的绑定）和 gui.cs（一个用户界面系统，可用于使用.NET 构建文本用户界面）。 InfoQ：还有一些其他与.NET Core 相关的框架，比如 EF Core、ASP.NET Core 等。这些框架是否与 Mono 兼容呢？ de Icaza：使用.NET 5，它们都是受支持的。在.NET 5 之前，像 ASP.NET Core 之类的东西无法与 Mono 一起使用，这主要受限于与它相关的工具，而不是受限于运行时。 例如，EF Core 是面向移动应用程序用户最喜欢的工具，它利用了.NET Standard，可以在 Mono 上开箱即用。 InfoQ：.NET 生态系统中，Mono 的未来是什么？ de Icaza：现在，它已经从独立工作中毕业，逐步发展成为了整个.NET 的一部分。现在.NET 将会有一个单一发行版，该发行版会针对我们多年来积累的每个平台。我对开源社区多年来的支持工作感到非常自豪，也对我们团队持续集成这些 VM 的工作感到自豪。 现在出现了一些引人入胜的发展。例如，就在今天，在使用本地配置运行 TechEmpower 基准测试时，我看到使用静态编译和 LLVM 的 Mono，现在可以与 CoreCLR 的性能相匹配了。 这对于 Mono 来说是一个重要的里程碑，因为当我们开始这项工作时，Mono 离我们的目标还很远，甚至不在同一个球场上。但是，我们开始研究是什么导致了 Mono 的性能下降，分析并测量，直到我们找到了大多数的罪魁祸首，然后我们才到达这个位置。 Mono 历来都有一个精确的垃圾回收器，该垃圾回收器轻量、高效， 适用于移动设备，但是对于这些拥有许多 CPU 和大型内存子系统的新计算机而言，它的扩展性却不佳。因此，我们现在有了一个使用 CoreCLR GC 的 Mono 的原型，这是一个针对 Mono 本身可高度扩展的 GC。我希望我们将来能够为用户提供 GC 选项。 除此之外，世界看起来越来越像一个统一的 VM，开箱即用地支持 C#和 F#，这是摆在我们面前最令人兴奋的工作。 到目前为止，将我们的语言和运行时一起演进是很困难的，因为演进运行时需要演进世界上每台 Windows 计算机上附带的运行时。为了避免回归共享框架（由许多用户共享），许多风险缓解流程已经就位，并且这些流程阻止了一体化进程中的大胆变革。 现在 .NET Core 可以并行安装了，并且可以按照用户需要的频率进行升级，我们有了千载难逢的机会来共同演进语言和运行时，而且你已经可以看到其中的一些东西了。一些功能，例如接口中的默认方法实现，以及对整个类库进行改造以使其可为空引用，这是最近的一些开发，但是还有更多的功能有待开发，因此还会有很多机会将被解锁。
-
发表了文章 2022-01-21
Android WebSocket即时通信
HTTP与WebSocket响应方式区别 WebSocket存在的理由 我们已经有了 HTTP 协议，为什么还需要另一个协议？因为只靠Http通信有一个缺陷：通信只能由客户端发起，HTTP 协议做不到服务器主动向客户端推送信息。这种单向请求的特点，注定了如果服务器有连续的状态变化，服务端想主动通知客户端，就难以实现。因此，工程师们一直在思考，有没有更好的方法，而 WebSocket 就是这样诞生的。 WebSocket其特点包括：建立在 TCP 协议之上，服务器端的实现比较容易与 HTTP 协议有着良好的兼容性，默认端口也是 80 和 443，并且握手阶段采用 HTTP 协议，因此握手时不容易屏蔽，能通过各种 HTTP 代理服务器数据格式比较轻量，成教性能开销小，通信高效可以发送文本、二进制数据协议标识符是 ws（如果加密，则为 wss），服务器网址就是 URL使用Java-WebSocket库进行简单通信 在经过对比之后，我选择了Java-WebSocket这个开源框架，毕竟star数量也是蛮高的，有质量保证。 Java-WebSocket库github地址。 1.引入库 implementation "org.java-websocket:Java-WebSocket:1.5.1"代码示例 2.创建WebSocketClient类 public class WSClient extends WebSocketClient { public WSClient(URI serverUri) { super(serverUri); } public WSClient(URI serverUri, Draft protocolDraft) { super(serverUri, protocolDraft); } @Override public void onOpen(ServerHandshake handshakedata) { } @Override public void onMessage(String message) { } @Override public void onClose(int code, String reason, boolean remote) { } @Override public void onError(Exception ex) { } }回调方法含义： onOpen()：连接成功回调，获取握手数据 onMessage()：接收消息回调，获取接收数据 onClose()：关闭连接回调，获取关闭信息 onError()：连接异常回调，获取异常信息 3.与ws协议或wss协议地址通信，创建Uri，这里用例子 ws://echo.websocket.org 。 URI uri=URI.create("ws://echo.websocket.org"); 4.创建WSClient示例，通过onMessage()方法接收信息。 WSClient wsClient=new WSClient(uri) { @Override public void onMessage(String message) { Log.e("info", "收到消息 " + message); } }; 5.发送信息，可以发送String类型和byte[]类型 wsClient.send("传给你信息");温馨提示： 在封装WebSocket使用时，需要注意心跳检测和重连，间隔时间后需要校验，如果中断需要重连；在适当的退出位置调用close()关闭连接；与服务端通信需要协定好传递的json对象；注意需要校验登录的地方。
-
发表了文章 2022-01-21
亚信数据新一代PaaS平台是如何炼成的？
日前，亚信数据发布旗下多款PaaS产品，包括亚信分布式数据库ADB、容器云计算平台HPS、大数据云平台DCP。这三款产品在亚信内部历经了3年的研发投入和攻关，并在客户项目中得到了实践部署。随着这些系列产品的正式亮相，它们共同构建了亚信完整的PaaS平台解决方案，将亚信拥有的大数据、CRM（客户关系管理系统）、BOSS（业务运营支撑系统）以及众多核心能力逐渐服务化、组件化，由该平台统一承载。 在活动现场，亚信数据副总裁、大数据平台产品线总经理杨映南接受记者采访，并就产品研发的历程、特色，以及业界大数据热点话题分享了自己的看法。 早在2013年的时候，亚信大数据平台专家技术团队就已组建，在亚信数据（公司）成立后， 这支团队作为公司的技术精英队伍，隶属于亚信大数据平台产品线。杨映南认为，亚信在大数据技术方向布局比较早，在一开始就意识到想实现亚信产业互联网战略的落地，要依靠稳定和可靠的底层技术架构和相应的基础软件来支撑上层各种业务系统。三年来，这一理念也伴随着亚信数据从业务服务型公司向技术产品型公司的转型。 “这些年来，我们正在努力把亚信服务电信运营商的技术能力，通过先进的互联网技术手段转化为标准化产品，由此推动各行业产业互联网数字化转型，这是亚信数据的初衷”，这和以往最大的变化是，过去的系统建设往往是分专业纵向建设，现在则是按平台横向建设，通过调用平台服务的模式，来构建各种专业应用系统，已不再是传统集成商的系统建设模式。亚信数据正努力通过PaaS平台将多年沉淀的各种业务组件以微服务和API(应用编程接口)的形式，为应用系统的开发、部署和运维提供便捷、高效、安全、稳定的业务建设和运行模式，杨映南表示。 宝剑锋从磨砺出 三年来，亚信数据投入重金和精干的研发力量，克服艰难困苦，矢志不渝专心致力于这些产品的研发。例如，在最初数据库选型的时候，亚信数据的研发人员首先调研和尝试了各种互联网数据库的产品用于企业级业务应用场景。然而，互联网证书业务的集群规模庞大，动辄成千上万节点和PB级的数据规模，需要承载百万TPS和上亿QPS业务请求。因为这些特点，互联网业务优先强调数据库的可扩展性，弱化对数据一致性的要求，通过业务系统来保证数据最终一致性，需要应用的开发去适应互联网数据库的架构特点。 通过对企业级客户真实场景的研究，亚信研发人员发现这种纯互联网的数据库架构特点并不适用于在企业级生产环境应用。在大多数情况下，企业级数据库架构集群规模并没有那么大，往往单库规模为数十个节点，数据规模通常在10T以下，处理能力为数千TPS和上万QPS。业务高度依赖数据库ACID（原子性、一致性、隔离性、持久性）能力，必须保证数据在任何场景下的强一致性。在应用开发方面，由于已经多年开发，需要支持透明、低成本的从现有数据库向自主可控的国产数据库平滑迁移。 于是，亚信数据研发团队历经三年开发完成了更具企业级特色的分布式关系型数据库ADB，侧重于事务处理、分布式、高扩展、强一致性，产品全部自主开发，知识产权完全可控，能满足企业级核心业务系统需求，而不是像互联网业务需要部署成千上万个节点。 而对于容器云平台HPS，是因为亚信数据研发团队看到了用户在X86化或虚拟化后的IT系统仍面临诸多挑战，例如，系统高可靠性下降、业务缺乏弹性伸缩能力、应用缺乏敏捷开发部署能力、运维缺乏自动化管理能力等。因此，亚信做的PaaS平台要支持上层业务能跑在新一代容器上，要和传统的虚拟化做明确的分割，支持集成、编排、管控，且能支撑应用的敏捷开发和应用的微服务化。 另外，在大数据云服务平台建设上，目前业界普遍存在的异构混搭架构也面临着诸多挑战。旧的大数据平台在应对层出不穷的新的大数据服务时，疲于应付；某些服务不支持资源隔离，为避免应用间的资源竞争，只能每个应用新部署一个集群；各个集群相互独立，形成数据孤岛和烟囱式资源分配，资源利用率低，灵活调度能力弱；集群数量不断增加，运维难度越来越大。 因此，亚信数据研发团队又基于大数据服务特点，以实现托管服务的统一资源调度、支持对已有集群/服务的纳管、提供面向租户的服务管理等开发思路，开发了亚信大数据云平台DCP2.0。它具有以下几个特点：1.支持托管和纳管服务类型，托管类服务共享底层的资源，具有弹性伸缩和高可用能力；纳管服务通过管控API，实现各种服务的集中管理；2.资源灵活调度：基于Hadoop HDFS的统一数据存储；基于Hadoop Yarn的统一计算调度；3.在管理平台上实现集中的租户、资源、服务、工具、运维管理。 对于未来，杨映南表示，将在三个层面继续增强亚信PaaS平台能力，第一是持续提高性能和稳定性，第二是具备服务热插拔能力，再者就是平台安全性。因为，大数据平台早已不仅仅是企业内部的生产平台，而是更多承载数据和应用对外开放协同的能力，不断提高安全隐患的防范能力。
-
发表了文章 2022-01-19
为什么要云原生：目标和收益
凯尔·布?朗（Kyle Brown）和金·克拉克（Kim Clark） 注意：这是部分5的五部分组成的系列。对于本系列的第一篇文章，请从这里开始或跳至第2部分，第3部分，第4部分 在过去的文章中，我们建立了“原生”指的是什么，甚至“原生”指的是“原生”的工作方式。但是，还有一个更大，更基本的问题我们尚未解决。为什么有人要关心？根据前两篇文章的背景，我们现在可以探讨“为什么”并查看云原生的好处，从高层次上对业务意味着什么，然后深入到实际意义上。 为什么要云原生：目标和收益 云原生方法的好处 目标和收益的业务视角 面对现实吧，IT风潮一去不返。许多业务团队试图超越那些时尚，让IT人员走自己的路—毕竟，选择应用程序服务器或语言运行库通常对业务运营没有太大影响。是什么使云原生技术与众不同？企业为什么要支持向云原生迁移？为了理解这一点，我们需要从一个角度出发，考虑到几乎所有企业要成功就必须关注的三个关键方面：增长，减轻风险和降低成本。我们认为使用云原生方法构建应用程序可能会在所有这些类别中提供好处。 市场成长 市场增长就是要吸引新客户并保持他们的兴趣。为了赢得新客户并保留边缘客户的利益，您必须能够比竞争对手更快地将好的新想法推向市场。采用精益方法和通过管道自动化简化生产路径等因素使团队能够更快地将业务构想引入生产。这样可以缩短上市时间，帮助IT部门以业务发展的速度推出新功能。但是，新功能本身无法确保市场增长。您必须能够找出那些对客户保留率和客户获取量有负面影响的新功能，并使它们消失，同时保留对这两项措施有正面影响的那些新功能。真正的关键是确保创新准备就绪；让企业大胆而迅速地将颠覆性的创意付诸实践，以便在竞争之前抓住新的市场利基，同时进行衡量，使您可以凭经验确定哪些创意是好的，哪些创意是不好的。 风险缓解 但是，新功能并不是企业需要的一切。如果一家企业能够通过不断以其令人敬畏的新功能来取悦客户而不断进取，那么我们的工作将会更加轻松。现实更加复杂和困难，但同样重要。客户需要信任您的业务。当然，这在金融服务或医疗保健等受到严格监管的行业中最为明显，但与每个业务相关。您提供的解决方案需要具有适当程度的弹性和安全性，以确保客户可以确定您何时需要他们，他们可以用他们的金钱，数据或生活来信任您。 正如我们在上一篇文章中讨论的那样，编写良好的云本机解决方案利用抽象将自身与底层物理基础架构分离，从而提供隐式的弹性。此外，由于它们必须假定可移植部署到任何云环境中，因此它们的组件也遵循零信任模型。但是，我们对风险的关注越多，就越有可能为进行变革设置障碍，这不利于我们对市场增长的需求。正是在这里，云原生可以通过提供高度自动化且一致的方式将产品投入生产，从而通过降低部署信心来减轻对变更的恐惧，从而有助于降低风险。 但是，云原生方法无法神奇地降低风险。诸如功能标记和Canary测试之类的技术可以使企业执行以前可能因风险过高而被拒绝的事情，但这需要与企业密切合作才能使这些技术对企业有价值。我们必须与企业合作，以更新他们如何衡量和控制风险，以使其与所介绍的方法和流程兼容。 降低成本 任何企业都不能忽略成本。无论您的市场份额有多大，或客户有多信任您，如果您无法控制成本，就不能指望可靠的利润。企业是由人们经营的（至少今天是这样！），人们却要花钱。我们需要确保能够从最少的人数中获得最大的收益，而对于那些拥有最深厚技能的人来说，情况尤其如此。构建云本机解决方案的平台应旨在实现标准化，并在可能的情况下使构建，部署和管理软件的日常任务自动化。这使得优化的高价值员工他们可以专注于直接为业务增加价值，而不是陷入日常运营的困境。当然，这些平台及其底层基础设施也需要付费。幸运的是，云原生解决方案旨在仅使用所需资源，因此您应该利用平台提供的弹性成本模型，以使您能够利用这种成本效率。 IT部门对目标和收益的看法 到目前为止，我们在云原生如何影响业务方面的讨论有些高层次。为了使企业理解云原生的优势，我们必须将我们已经讨论过的IT优势转化为相应的业务优势。接下来，我们将展示上面的每个关键业务收益领域如何映射到我们之前的云原生要素。 敏捷性和生产力（市场增长） 每个企业都希望从IT获得更多功能-他们也希望它们更快，并且希望它们更准确地反映他们的需求。云原生如何提供帮助？ 更快地交付组件 交付加速是云原生方法最常见的目标，它汇集了三个核心方面：云平台，敏捷方法和微服务。云平台通过弹性配置和组件编排等方面，使我们能够通过自动化和简化大多数日常运营工作来专注于构建业务功能。通过减少工作量，他们可以使团队专注于高价值的工作。敏捷方法应使我们能够缩短需求与实施之间的距离，并提高与业务目标的一致性。这意味着需要更少的返工，并且可以更快地发现并纠正错误的主意。设计方法，例如微服务使我们能够以更少的依赖关系递增地交付功能，从而更快地交付。 具有自主创新能力的自主团队 细粒度和离散组件的故意结果是，它为创建它们的团队提供了更多的自治权。只要遵循我们前面描述的去耦的关键规则，接收平台就可以在很大程度上将这些组件视为“黑匣子”。虽然应该鼓励跨团队协作和通用做法，但是团队可以自由使用例如可以满足其需求的最有效的语言运行时和框架。这种创新的自由性使团队可以“开箱即用”，不仅可以更快地为业务提供解决方案，而且可以提供在业务方面更具创新性的解决方案。这种自治的一个关键方面是，业务必须是每个自治团队的一部分。产品负责人的概念和发起人用户对于建立富有成效的团队和创新团队至关重要。 应对不断变化的业务条件 早先，我们讨论了不仅要进行创新，而且要通过具体的和经验的评估来确定一项创新是否有价值的能力对于使团队随时准备以业务发展的速度发展是很重要的。其中一个关键方面是成教业务和IT通过假设驱动的开发协同工作的能力。简而言之，假设驱动的发展将商业想法表述为可以被证明或未被证明的科学假设。只有在整个开发周期中都参与业务时，云原生开发才能为业务带来收益。 参与的主要形式是通过A / B测试-如果您进行评估，例如废弃购物车的百分比或浏览后单击“购买”的客户百分比，那么您可以凭经验比较不同的想法。您可以将您的一些客户引导到具有新想法的新方法，将其他客户引导到现有的方法，然后比较两者之间随着时间变化的度量差异。这里的关键是，这要求企业考虑可衡量的差异。如果科学的假设无法被证明，它就不是一个假设，这同样适用于业务假设。企业必须能够帮助确定可量化的度量标准，通过该度量标准可以比较两种不同的想法或方法。这意味着它们必须参与整个过程，不仅帮助确定应该测试哪些想法，还应该确定如何测试它们，以及成功定义的含义。 Cloud native非常适合启用这种响应行为。它是敏捷方法学的重要组成部分，此外，使用细粒度，耦合良好的组件可以更安全地添加新功能，而又不会干扰已有的功能。此外，诸如服务网格之类的通用机制可用于在正在测试的想法之间选择性地路由请求，以及简化用于假设评估的数据收集。它是敏捷方法学的重要组成部分，此外，使用细粒度，耦合良好的组件可以更安全地添加新功能，而又不会干扰已有的功能。此外，诸如服务网格之类的通用机制可用于在正在测试的想法之间选择性地路由请求，以及简化用于假设评估的数据收集。它是敏捷方法学的重要组成部分，此外，使用细粒度，耦合良好的组件可以更安全地添加新功能，而又不会干扰已有的功能。此外，诸如服务网格之类的通用机制可用于在正在测试的想法之间选择性地路由请求，以及简化用于假设评估的数据收集。 弹性和可扩展性（风险缓解） 云平台，尤其是容器，从其基础架构中继承了许多抽象。这使得针对非功能性需求（例如可用性，健壮性，性能和安全性）的通用且风险较低的方法成为可能。一些关键示例是： 细粒度的弹性可扩展性和弹性 编写良好的云本机解决方案是使用状态最小化的细粒度，轻量级组件构建的。这使云平台能够通过根据需要快速复制和处置组件来固有地提供健壮性和可伸缩性。多亏了集装箱运输，这可以以标准化的方式提供，从而大大简化了操作。此外，容器编排平台能够在多个物理服务器，多个区域中分布容器实例的能力进一步提高了弹性水平。 一致的环境和可逆的部署 为了使上一部分中讨论的敏捷性和生产率变为现实，我们需要能够自信地将新代码交付到环境中，安全地重新路由流量，并在必要时确实以最小的痛苦来扭转这些部署。理想情况下，云原生代码应以不可变的映像形式交付，其中包含所有依赖项，并包括完整的声明式部署说明。这确保了部署过程和工件在所有环境中都是相同的，从而消除了环境漂移的风险。此外，云平台的功能（例如路由器和服务网格）使代码可以在全面推出之前进行加那利测试（通过新代码传递少量负载）。这也简化了回滚版本，因为我们可以简单地恢复到先前版本的映像和部署说明。这种简单性对业务至关重要，因为它可以使他们确信，如果结果不是预期的，则可以快速安全地撤消更改。 持续采用软件运行时 敏捷方法要求在构建，测试和部署方面，生产路径必须尽可能自动化。这些管道通常被称为连续集成/连续交付（CI / CD），通常是由于源代码的更改而触发的。但是，由于声明式部署也是代码，因此对基础运行时版本的更改也会触发新的构建/测试周期，例如“ GitOps”。假设我们对自动化测试有足够的信心，那么这应该使我们可以使基础运行时版本保持比当今大多数应用程序最新的状态，从而不仅确保我们可以利用最新的功能，而且也不会受到已知安全漏洞的威胁。再次，这对企业来说应该是有价值的，因为它减少了丢失客户数据或资产的信托风险。 优化和效率（降低成本） 基于云的计算使我们能够集中资源：硬件，软件，甚至人员。通过跨应用程序，跨组织域甚至跨组织共享这些资源。我们有机会降低运营成本。Cloud native可确保编写应用程序以从这些优化中获得最大收益。 基础平台上的一致技能 容器的明显特征（即轻量级可扩展组件）的根本特征是更大的瑰宝。从长远来看，它们最大的好处可能在于操作的一致性。使用完全相同的技能来构建，部署，提供高可用性，扩展，监视，诊断和安全，无论在一组精心设计的容器中运行时如何，都是一个巨大的飞跃。至少，这意味着可以在IT领域以前孤立的部分中转移可移植的通用技能。充其量，自动化操作的机会应该导致减少运行给定基础架构所需的人员数量，并提高其可靠性。但是，由于这些技术是新技术，因此个人和公司必须经历陡峭的学习曲线，然后才能实现这些利益。 优化基础架构的使用和许可 可以说，“云”的最基本定义是从基础物理基础架构中抽象出来的。虚拟机为我们提供了第一级间接性，因为我们不再受限于物理机中的特定硬件。容器，如果加上最小状态，不变部署等云原生成分，将使我们走得更远。云原生使我们能够在多个数据中心的许多机器之间无形地分布组件，从而为规模经济提供了更大的机会。当然，软件许可需要通过新模型以及可能更复杂和动态的计量来应对这一挑战。 快速自我配置资源和功能 自我配置是云的主要承诺之一，可实现对虚拟计算，内存，存储，网络等的快速需求。容器平台通过在部署时允许对资源的声明性请求，并为这些属性在运行时基于负载的变化设置策略，进一步抽象了这一点。只需单击即可创建全新的环境，并通过软件定义的网络将其与其他环境隔离。为了充分利用所有这些，需要以不同的方式编写应用程序。应用程序必须是无状态的，可抛弃的，细粒度的，实际上，我们在本系列中已经讨论过的所有内容。 结论 就像方法中最重大的变化一样，云原生云需要一定程度的承诺才能实现您的目标。如我们所见，这需要使用许多单独的成分。对于许多（也许是大多数）组织而言，从一开始就不可能将所有这些要素都准备就绪，因此成功的关键是优先考虑。 通过选择对您最重要的好处，我们希望我们的系列产品可以帮助您确定应优先关注的哪种云原生成分的优先级。
-
发表了文章 2022-01-19
四种新兴技术：生物技术、小型卫星、量子计算机和认知增强的认知
本文4589字，建议阅读12分钟。 本文论述了生物技术、小型卫星、量子计算机和认知增强的安全问题。 本文节选自专著《Technology and National Security: Maintaining America's Edge》，The Aspen Institute ，2022年1月31日。文章题目《Four Emerging Technologies and National Security》。本文讨论了四种新兴技术：生物技术、小型卫星、量子计算机和认知增强，并简要介绍这四种技术及其对美国国家安全的影响，最后提出应对建议。 作者：Jason Matheny 编译：学术plus高级评论员 计宏亮 四种新兴技术：生物技术、小型卫星、量子计算机和认知增强的认知 ---1--- 生物技术 Biotechnology 生物技术的四次飞跃发展 20世纪50年代，生物遗传机制被鉴定为由有机体读取和写入的核酸序列作为自动收录带。 20世纪90年代，开发了用于大规模读取这些序列的实用方法。阅读第一个人类基因组序列于2003年完成，耗资超过20亿美元。如今，对人类基因组进行测序的成本不到10,000美元 - 15年内减少了200,000倍。 过去15年，编写序列的成本降低了1,000倍。这些进展使得可以插入现有生物体的单个基因的合成以及微生物的全基因组的合成变得切实可行。 2010年初，开发使用CRISPR/Cas9系统编辑基因组经济而有效的工具。利用这些工具，生物技术可用于创建微生物工厂，以便大量生产小东西。人们可以指导工厂生产有益的东西，如药品、燃料、食品、纺织品和催化剂。或者可以指示工厂生产破坏性的东西，如病毒和毒素。 生物学的杀伤力 即使没有人类创造力的应用，生物学也是对国家安全的最严重威胁。1918年，一种流感病毒在12个月内造成超过五千万人死亡，是人类历史上最严重的生命损失。安东尼和查士丁尼瘟疫、黑死病和Cocoliztli流行病也比现代战争更具杀伤力。 生物学的巨大杀伤力源自其两个属性： 首先是自我复制，通过这种自我复制，小型武器库可以有效地变成一个大型武器库。（除了生物武器之外，唯一可以自我复制的其他类武器是网络武器）。第二个特性是自然选择，通过这种选择，随着时间的推移，对生物体有利的随机性状将变得更加普遍。生物技术允许通过修改这两个属性实现人类目标。 例如，一种被称为“基因驱动”的生物技术允许人类工程师确保特征在物种内普遍存在，即使该特征对生物体是不利的。（基因驱动的仁慈应用是设计无法传播疟疾的蚊子。恶意应用是设计无法授粉以破坏农业关键部分的蜜蜂）。另一类生物技术，即“功能获取”，使用人工选择超出了自然发生的速度来扩大有机体特征，如致死率或传染性。 尽管存在安全问题，但功能研究的收益也是人所共知的。一方面，这种研究的结果可以用来开发先进的生物武器。另一方面，结果可用于评估风险和发展更好的防御。如果生物学具有实质性的进攻优势，那么公开的好处是有限的 - 如果在边缘，进攻比防守更有效。 例如，2022年，使用市面上的设备和材料以100,000美元合成了天花病毒的近亲。与此同时，一种新的防御性疫苗开发成本超过10亿美元。与防御相比，进攻具有10,000倍的成本优势，并且随着时间的推移，其优势将不断增加。即使有效地发布医疗对策，在美国发布的痘病毒也可能导致数百万美国人死亡。 因此可以说，我们生活在一个脆弱的世界中，在这个世界中，一个高明复杂的反叛者能够杀死数百万人。 ---2--- 小卫星 Small Satellites 对于国家安全而言，太空起着两个关键作用：（1）武器转送，如洲际弹道导弹，（2）卫星的观察和通信。 1945年，当克拉克（Arthur C. Clarke）首次提出通信卫星时，他认为太空是最终的高地——即从轨道上的位置来看，地球上许多点都在卫星的可视范围，从一个位置接收信号并将它们传输到其他任何地方。从克拉克的提出这一概念，直到第一颗卫星发射，用了12年的时间，而现在有数千颗卫星用于发送和接收通信，实现授时和导航，并拍摄地球表面。 将物体运送到太空十分昂贵。在过去六十年中，发射入低地球轨道（LEO）的成本相对稳定，大约为每公斤10,000美元。一些新技术，例如可重复使用的助推器，可能会将成本降低10％至50％，但由于重力的不便，成本仍居高不下。 有效载荷的小型化趋势。在过去的六十年中，每单位性能的微电子重量减少了约一百万。小型化大大增加了给定尺寸的卫星的处理能力，其中立方体小卫星的标准尺寸为10×10×10cm的倍数。尽管如此，函授小型化还是有限的，特别是涉及孔径和天线的卫星部分，其尺寸具有物理定律所规定的下限。虽然孔径和天线的尺寸可以保持不变，但是通过在轨维修，组装和制造（OSAM）方法可以大大降低其成本，这些方法将不太脆弱，零件和原材料的有效载荷转换成大型复杂结构。未来OSAM的自动化以及将原材料快速发射到轨道，可以创造一个强大的空间基础设施。 商业卫星以及空间的民主化意味着富裕国家不再垄断地球表面的详细图像。因此，大国在国家情报的一个重要方面失去了优势。空间的民主化也导致越来越多的活跃航天器和轨道上的非活动物体（例如火箭体）。目前仅在LEO中大约有16,000个物体，大小超过10厘米。这个数字可能在未来十年内翻一番，必将增加碰撞的可能性，并使空间交通管理复杂化。还好，太空很大——地球静止轨道的体积大约是地球海洋体积的10万倍。但追踪太空中的物体，特别是外国军事和情报航天器，仍将是国家安全的首要任务。 太空基础设施非常脆弱。卫星很脆弱——虽然对重量和体积进行了优化，但仍然难以装备，并且容易受到碰撞、导弹、激光、无线电干扰和太空天气的破坏。由于卫星的固有成本和交付成本，卫星的更换成本也很高。保护这些系统，寻找快速替换它们的方法，以及开发不依赖于空间的冗余服务都是困难的国家安全问题。美国比其他国家更依赖太空，但随着越来越多的国家推出自己的通信和GPS系统，使自己的基础设施面临风险，这种差距正在缩小。 ---3--- 量子计算机 Quantum Computers 量子计算机利用两种量子现象：叠加，量子位（量子位）同时保持多于一种状态的能力，以及纠缠，即两个或更多量子位在距离上共享其状态的能力。 在20世纪80年代早期，物理学家假设显示这两种现象的计算机可能非常适合某些类型的计算，例如量子行为的模拟。目前还不清楚这种机器是否可以安全应用，直到1994年彼得肖尔（Peter Shor）发现一台大型量子计算机应该能够有效地计算大数。目前大多数加密方法，包括用于保护军事通信和在线金融交易的许多加密方法，都取决于分解的难度。如果分解变得容易，则许多现有的加密技术不再安全。 量子计算的进展一直很困难。虽然在理论、材料和测量方面取得了实质性进展，但自2001年以来，量子计算机的规模从7个增加到仅有72个物理量子位。有用的量子计算机需要几千个量子比特，并且每次添加都会增加纠错的难度。迄今为止，还没有创建可用作这种计算机的构建块的单个逻辑量子位。相反，在创建抵抗量子攻击的新加密方法方面进展更快。现在存在几种这样的方法，尽管它们在计算上比传统加密效率低。 密码分析被认为是对国家安全最重要的量子计算应用，但还有其他潜在的应用。这些包括模拟分子以设计化学品或催化剂并解决硬优化问题，例如用于物流、调度和机器学习的问题。量子计算机尚未进行有用的计算，否则经典计算机无法以较低的成本执行。然而，在某些时候，研究人员很可能实现这一里程碑，有时被称为“量子至上”。 如果目前的趋势继续下去，在广泛部署量子抗性加密之后，可能会大规模引入量子计算机。如果是这样，计算机的主要情报价值将是解密历史数据。最受益的国家是那些长期存储被截获的外国通信的国家。根据政策，美国将大部分SIGINT的保留限制为五年，这使人们怀疑大规模量子计算对美国密码分析的相对价值。尽管如此，重要的是美国不要对量子计算的发展感到惊讶，部分原因是因为进展速度将告知我们自己部署量子抗性加密方法的时间表。由于这些方法需要计算成本，我们需要决定投资他们的改进时间以及何时根据需要简单地接受成本。 ---4--- 认知增强 Cognitive Enhancement 在未来，人类可能成为更好的发明者。科学方法、科学仪器、同行评审、计算机和专利系统都是用于对发明的基础设施增强的方法。如果人类智能本身得到增强，那么发明的速度可能会大大增加。 认知增强的潜在途径可以分为三类：装置、药物和基因。由于非致命性战斗伤害增加后的军事研究，将脑组织连接到外部装置（例如假肢）的装置变得越来越复杂。一些初创公司现在正在探索是否可以使用这种神经接口将处理和记忆任务直接从大脑卸载到外围设备。 神经认知条件药物的可用性（例如注意力缺陷障碍，发作性睡病和痴呆）增加在健康成年人中形成了一种亚文化，这些成年人消费这些药物以增强认知。目前尚不清楚其中任何一种是否有效，因为很少有证据表明这些药物比咖啡因或尼古丁更能提高健康成人的认知能力。尽管如此，未来的发现可能会带来认知上的提升。 最后一类认知增强可能是最有效和最有争议的。DNA测序成本的降低使得人类智能的大型基因组研究成为可能，其中认知能力的某些变化可归因于基因。中国的认知基因组学项目就是这样一项研究，调查表明，如果有这样的服务，大多数中国父母会选择使用基因分型服务来选择更聪明的孩子。调查显示，美国和欧洲的父母更不愿意使用这些服务。如果这些调查具有代表性，那么技术采用率可能会受到文化态度差异的严重影响。由于发明率是国家权力的主要决定因素，任何影响发明率的“认知军备竞赛”都可能产生重要的地缘政治和经济后果。 ---5--- 如何应对？ 应对？ 政府在应对这四项技术方面面临着许多安全挑战，以及将在后文提到第五项技术人工智能（AI）。这些技术都具有以下三个特征： 商业市场。与大多数具有战略重要性的现有技术不同，政府不是这些技术的主要资助者，主要开发者不是国防承包商。存在大型商业市场，推动了大量的研究、开发和运营。在某些情况下，关键国家安全系统的组成部分依赖于商业市场 - 例如，为视频游戏开发的GPU（图形处理单元）是用于核武器模拟的超级计算机的基础。在其他情况下，政府的某些部门无法获得尖端技术 - 例如，谷歌就制定了一项政策，要求不能为武器系统设计AI。 军民两用特性。 由于这些技术的商业应用，军事计划很难与商业计划区分开来。很少有标记将合法的生物技术努力与生物武器计划区分开来。因此，难以检测计算系统是用于良性科学研究还是用于解密军事通信。 快速变化。与大多数武器不同，其中一些技术随着时间的推移呈现出性能的指数级改进。如此迅速的变化使得规划和调整变得困难，特别是在政策制定和政府采购的典型时间尺度上。 在接下来的十年中，这些技术（和其他技术）的竞争将挑战美国国家安全决策者。他们将被推动制定加速创新的国家战略，包括增加研发资金，改变移民政策以防止人才流失，扩大知识产权保护以限制技术盗窃，以及要求商业技术公司解决国家安全优先事项。国防机构将面临与其传统承包商以外的技术组织合作的挑战，并在接近商业期望的采购时间线上运营。情报机构将被迫监控外国商业技术公司和外国学术实验室，这些公司正在开发关键的战略技术。最后，外交官将被转移到不熟悉的领域进行谈判，例如影响其技术成为全球规范的模糊国际标准制定机构。 — 完 —
-
发表了文章 2022-01-19
程序员如何用Python编程暴力算法破解凯撒密码
破解凯撒密码可以用到一项密码分析技术，叫作暴力算法（brute-force），它的攻击是通过尝试每一种可能解密密文的密钥实现的。没有什么能够阻挡密码分析人员猜测密钥、用密钥解密密文、观察输出，并在没能破解出密文的情况下寻找下一把密钥。正因为这样的暴力算法对凯撒密码来说过于有效，所以在实际应用中根本不应该使用凯撒密码去加密一段秘密信息。 在理想的情况下，一段密文不会落入任何人的手中，然而Kerckhoffs原则（以19世纪密码学家Auguste Kerckhoffs命名）表明，一段密文即使在所有人都知道来源且某些人可能得到的情况下，也应该保持其安全性。20世纪时，数学家Claude Shannon在《香农格言》（Shannon's maxim）中重新提出了这个原则，即“敌人了解系统”。在密码算法中，是密钥保证了信息的机密性，而在凯撒密码中，密钥的信息非常容易被发现。 本章要点Kerckhoffs原则和香农格言。暴力算法技术。range()方法。字符串标准化（字符串插值）。1 破解凯撒密码的源代码 选中 File 程序员如何用Python编程暴力算法破解凯撒密码 New File，打开一个新的编辑窗口，将下列代码输入编辑窗口并将其存储为caesarHacker.py。随后，如果读者的计算机中没有pyperclip.py模块，则可以下载它并将它放置在与caesarHacker.py相同的路径下（同一个文件夹中），该模块将在caesarHacker.py文件中被引入。 结束文件配置后，按 F5键执行程序，如果代码中出现了报错或其他问题，请仔细比对书上代码和文件中代码有何不同。 caesarHacker.py 1. # 凯撒密码破解 2. # nostarch/crackingcodes/ (BSD Licensed) 3. 4. message = 'guv6Jv6Jz!J6rp5r7Jzr66ntrM' 5. SYMBOLS = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz12345 67890 !?.' 6. 7. # 循环遍历所有可能的关键字 8. for key in range(len(SYMBOLS)): 9. # 将translated设置为空字符串很重要，这样可以清除上一个迭代中 10. # translated的值 11. translated = '' 12. 13. # 程序的其余部分与凯撒程序几乎相同 14. 15. # 循环遍历message中的每一个字符 16. for symbol in message: 17. if symbol in SYMBOLS: 18. symbolIndex = SYMBOLS.find(symbol) 19. translatedIndex = symbolIndex - key 20. 21. # 执行回环 22. if translatedIndex < 0: 23. translatedIndex = translatedIndex + len(SYMBOLS) 24. 25. # 添加解密的字符 26. translated = translated + SYMBOLS[translatedIndex] 27. 28. else: 29. # 添加未加/解密的字符 30. translated = translated + symbol 31. 32. # 显示每一个可能的解密值 33. print('Key #%s: %s' % (key, translated)) 注意，本段代码有很大一部分和原始的凯撒密码程序相同，这是因为凯撒密码的破解程序使用了和加密一样的步骤去解密信息。 2 运行凯撒密码破解程序的样例 运行凯撒密码的破解程序，将会得到如下输出。它使用全部66种可能的密钥解密密文“guv6Jv6Jz!J6rp5r7Jzr66ntrM”，将其成功破解。 Key #0: guv6Jv6Jz!J6rp5r7Jzr66ntrM Key #1: ftu5Iu5Iy I5qo4q6Iyq55msqL Key #2: est4Ht4Hx0H4pn3p5Hxp44lrpK Key #3: drs3Gs3Gw9G3om2o4Gwo33kqoJ Key #4: cqr2Fr2Fv8F2nl1n3Fvn22jpnI --snip-- Key #11: Vjku?ku?o1?ugetgv?oguucigB Key #12: Uijt!jt!nz!tfdsfu!nfttbhfA Key #13: This is my secret message. Key #14: Sghr0hr0lx0rdbqds0ldrrZfd? Key #15: Rfgq9gq9kw9qcapcr9kcqqYec! --snip-- Key #61: lz1 O1 O5CO wu0w!O5w sywR Key #62: kyz0Nz0N4BN0vt9v N4v00rxvQ Key #63: jxy9My9M3AM9us8u0M3u99qwuP Key #64: iwx8Lx8L2.L8tr7t9L2t88pvtO Key #65: hvw7Kw7K1?K7sq6s8K1s77ousN 由于第13把密钥得到的输出是标准的英文，因此可以断定原始的加密密钥就是第13把密钥。 3 设置变量 破解程序生成了变量message，用于存储需要解密的密文字符串，常量SYMBOLS则包含了所有可以被加密的字符。 1. # 凯撒密码破解 2. # nostarch/crackingcodes/ (BSD Licensed) 3. 4. message = 'guv6Jv6Jz!J6rp5r7Jzr66ntrM' 5. SYMBOLS = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz12345 67890 !?.' SYMBOLS的值需要和凯撒密码加密程序中使用的SYMBOLS的值完全相同，同时待破解的密文正是由该加密程序得来；否则，破解程序将失效。注意，SYMBOLS字符串中的 0 和 ! 之间有一个空格。 4 在循环中使用range()方法 第8行使用了一个for循环，然而它并没有在一个字符串值上进行迭代，而是在调用range()方法的返回值上进行迭代。 7. # 循环遍历所有可能的关键字 8. for key in range(len(SYMBOLS)): range()方法接收一个整型参数，并返回range数据类型的值。这种数据类型的值可以在for循环中用于进行指定次数的循环，循环次数由传递给range()方法的整数决定。尝试下面的例子，将下列代码输入交互式运行环境中。 >>> for i in range(3): ... print('Hello') ... Hello Hello Hello 由于将整数3传递给了range()方法，因此for循环将进行3次循环。 更确切地说，range()方法返回的range值会将for循环的变量值设置为0～输入的参数值（不包含后者），例如，将下列代码输入交互式运行环境中。 >>> for i in range(6): ... print(i) ... 0 1 2 3 4 5 这段代码将变量i的值设置为0～6（不包含6），与caesarHacker.py文件的第8行类似——文件的第8行将key的值设置为0～66（不包含66）。为了避免将66直接硬编码到程序中，程序使用了len（SYMBOLS）的返回值，因此即使改变SYMBOLS的值，程序的运行也不会受到影响。 程序首次执行到循环时，key被设置为0，message中的密文被密钥0解密（当然，如果0并不是真正的密钥，message会被解密为乱码）。for循环内部的第9～31行代码用于解密，并且与统招原始的凯撒密码加密程序类似，之后会对其进行解释。程序执行到下一次对for循环的迭代时，key被设置为1，继续进行解密。 尽管这个程序中没有用到，读者还是可以尝试向range()方法中传递两个整型参数，而不像本程序中只使用了一个。第1个参数是range的起始值，第2个参数则是range的终值（range从起始值开始取值，但并不会取到终值），两个参数用逗号隔开。 >>> for i in range(2, 6): ... print(i) ... 2 3 4 5 变量i的取值为2～6（含2而不含6）。 5 解密消息 for循环之下用于解密的代码，每次执行都将解密后的文本添加到translated字符串的末尾。在第11行，translated被置为空字符串。 7. # 循环遍历所有可能的关键字 8. for key in range(len(SYMBOLS)): 9. # 将translated设置为空字符串很重要，这样可以清除上一个迭代中 10. # translated的值 11. translated = '' 在for循环的开始将translated置空非常重要，如果不这么做，则本次尝试的密钥解密出的文本将被添加到上一次迭代后生成的字符串后面。 第16～30行和第5章中的凯撒密码加密程序几乎是相同的，但是要比第5章中的代码更简单一些，因为它们只被用作解密。 13. # 程序的其余部分与凯撒程序几乎相同 14. 15. # 循环遍历message中的每一个字符 16. for symbol in message: 17. if symbol in SYMBOLS: 18. symbolIndex = SYMBOLS.find(symbol) 在第16行中，程序循环遍历了message中存储的每一个字符。每经过一次循环迭代，第17行就检查symbol是否存在于常量SYMBOLS中，如果存在，就对其进行解密。第18行的find()方法对symbol在SYMBOLS中的位置进行确定，并将这个位置的值记录在变量symbolIndex中。 随后，第19行从symbolIndex中减去key值进行解密。 19. translatedIndex = symbolIndex - key 20. 21. # 执行回环 22. if translatedIndex < 0: 23. translatedIndex = translatedIndex + len(SYMBOLS) 减法操作可能会导致translatedIndex的值小于0，这时就需要回到常量SYMBOLS的开头去寻找解密出的字符位置。第22行对可能的情况进行判断，如果出现了translatedIndex值小于0的情况，就为其加上66［len（SYMBOLS）的返回值］。 translatedIndex的值改变后，SYMBOLS[translatedIndex]就可以获取解密得到的字符了。第26行将这个字符添加到translated存储的字符串末尾。 25. # 添加解密的字符 26. translated = translated + SYMBOLS[translatedIndex] 27. 28. else: 29. # 添加未被加/解密的字符 30. translated = translated + symbol 如果symbol的值没有在SYMBOLS中找到，则第30行将把它保持不变地添加到translated的结尾。 6 使用字符串标准化输出密钥及解密后的信息 虽然第33行是凯撒密码破解程序中唯一的一个print()方法，但它会得到多行执行结果，这是因为第8行的for循环每进行一次迭代，它就将被调用一次。 32. # 显示可能的解密值 33. print('Key #%s: %s' % (key, translated)) print()方法中的参数是一个使用了字符串标准化（string formatting，也叫作字符串插值）的字符串。字符串标准化使用%s将一个字符串放置到另一个字符串当中，在这个字符串的结尾，第1个%s被括号中的第一个值替换。 将下列代码输入交互式运行环境。 >>> 'Hello %s!' % ('world') 'Hello world!' >>> 'Hello ' + 'world' + '!' 'Hello world!' >>> 'The %s ate the %s that ate the %s.' % ('dog', 'cat', 'rat') 'The dog ate the cat that ate the rat.' 本例中，首先将字符串world插入字符串“Hello %s!”，替换掉%s。这个过程和连接起%s之前、待插入的字符串、%s之后这三部分文本的过程是类似的，当需要插入多个字符串的时候，%s按照这些字符串的顺序被依次替换。 字符串标准化往往比使用 + 操作符对字符串进行连接更便于输入，尤其是在面对长字符串的情况下。同时，与字符串连接不一样的是，使用字符串标准化甚至可以将非字符型的值（如整型）插入字符串中。将如下代码输入交互式运行环境。 >>> '%s had %s pies.' % ('Alice', 42) 'Alice had 42 pies.' >>> 'Alice' + ' had ' + 42 + ' pies.' Traceback (most recent call last): File "", line 1, in TypeError: Can't convert 'int' object to str implicitly 使用字符串插值的时候，整数42可以非常顺利地插入字符串中，然而如果想要通过字符串连接将它插入字符串中，就会出现报错。 caesarHacker.py文件的第33行使用字符串标准化生成了一个包含变量key和translated的字符串。由于key中存储的是一个整数的值，因此使用字符串标准化就可以将它作为字符串的值传递到print()方法中了。 7 小结 凯撒密码的致命弱点在于，用于加密的密钥并没有太多种可能性，任何计算机都可以轻易使用全部66种可能的密钥解密信息，密码分析人员只需要花几秒钟的时间浏览解密后的内容，就可以找到其中符合英文语法的一项。要使消息更安全，需要一种拥有更多可能密钥的算法，而在第7章中，移位密码就可以提供这样的安全性。 程序员如何用Python编程暴力算法破解凯撒密码 -喜欢的朋友欢迎转发到朋友圈- 获取本书资料，请关注‘异步图书’微信号，回复“52999‘获取
-
发表了文章 2022-01-19
大数据创新实践八步骤，如何成为一个大数据企业
什么样的企业可以称得上是大数据企业呢?恐怕没有人能够给出一个完美的答案。但是,直观地,我们可能觉得Google更像是一个大数据的企业,阿里巴巴也像是一个大数据的企业,而中国银行似乎不太像一个大数据的企业,尽管它每天也一样浸泡在海量的数据中。 除了具有处理大量数据的能力外,之所以Google和阿里巴巴更像大数据的企业,是因为他们有深入的数据分析工具,利用数据分析的结果直接指导决策,而且经常推出基于数据分析的创新型应用,这还不包括类似于AlphaGo这样的奇葩。 大数据创新实践八步骤，如何成为一个大数据企业 这是我第三次以文字的形式谈论如何成为一个大数据企业。一是很早以前在“科学网”上写的一篇博客,二是为一本名为Code Halos 的书写的序言。这个版本可以看作是上两个版本的补充和扩充,同时也是本书一些重点内容的重述(为了保证本文的独立性,可以不依赖本书直接阅读,少量书中给出过的文献和注释在本文中重复出现了)。然而遗憾的是,并没有一条放之四海皆准的通往大数据企业的康庄大道,更没有点石成金之术可以让一个企业快速Google化。这篇结束语只是提出一些看得见摸得着的建议,藏在这些建议背后的大数据理念,或许更加重要。 尽管我是用Step1、Step2 这样的说法来列举成为大数据企业的措施,但是这些步骤之间并没有严格的逻辑上谁决定谁或者时间上谁先谁后的关系。举个例子来说,最好的办法当然是先有了数据标准再整理采集数据,这样可以不走任何弯路,但实际上完全没有数据,企业不会有动力做标准建设,做出来的标准也可能是纸上谈兵,完全不实用。又比如,数据管理平台的建设能够帮助更好地进行全面数据化,但实际上它多半是全面数据化战略进行了一定程度之后才开始启动建设的。总体来说,写在更前面位置的,是更基础的,但是没有绝对的依赖关系。 Step 1. 全面数据化 “数据化”浪潮是整个大数据时代的起点,它强调数据就是资产,记录一切可以记录的数据,并相信这些数据一定会在某一天产生巨大的价值。显然,数据化是一个企业能够通过深入数据分析,实现自身优化的基础。 我去长虹集团调研的时候,他们告诉我,长虹电器在自己的生产线上,通过大量传感器,记录生产环境的温度、湿度、粉尘度、振动强度和噪音强度,等等,通过这些量化指标与产品质量的关联分析,得到影响产品优品率和良品率的关键因素,再进一步通过控制环境因素,明显提高了产品的优品率。企业在日常的经营管理过程中,通过办公自动化系统(OA系统),很多内部即时通讯、邮件往来、工作分配和业务文件上传下载等日志数据都被记录下来了。这些数据就是宝贵的财富!正如我在书中第三部分提到的,我们通过对这些数据的分析,能够更精确地预测员工的离职率和升职率,更精确地预测员工和部门的绩效水平,帮助企业员工通过基于关联用户和文本智能匹配快速找到对自己现有业务和客户有参考价值的案例和文件,等等。但是这些提升,都是建立在企业拥有相应数据的基础上。 总的来说,全面数据化要求企业采集并存储企业生产经营中的一切数据,形成企业数据资产的概念。 Step 2. 整理数据资源,建立数据标准,形成管理规范 很多企业已经有了一些数据储备,或者通过第一步,开始快速积累了一些数据。但是企业管理层,尤其是跨业态拥有多家子公司的集团运营的企业,一般而言,对于自己到底有哪些数据资源是没有清晰认识的,更拿不出一张较完备的数据目录。 企业要做的第一步,就是通过自顶向下的方式,成立数据委员会,在有必要的时候借助外部合作方的帮助,进行全面的数据调研,了解数据资源的整体情况并建立数据资源情况更新的流程和规范。 数据资源最基本的呈现方式是一个数据目录,我认为,企业管理团队至少要掌握整个企业数据的3级目录,而企业的主要技术团队应该掌握到4级目录。但数据资源又不仅仅是数据目录,因为还涉及到每一个数据项的完备性、更新程度、有效性和噪音源等描述。掌握了数据资源后,企业要根据自己业务发展的需求,建立数据标准,使现有数据和未来所有的新增数据都能够在同一个标准下统一管理,避免“信息系统建设越多,未来数据整合越难”的困境。业务中涉及大量数据的企业,尤其是涉及到用户隐私数据、国家安全数据和具有重要商业价值数据的企业,要形成数据全流程管理的规范,因为绝大部分数据隐私和数据安全的事件,都不是从外部由黑客或者敌方特定人员通过技术手段获得的,而是本单位人员蓄意或无意泄露的。数据全流程管理的规范就是要做到企业能够对数据进行分级分权限的管理,随时了解敏感数据存储在哪些服务器和终端设备上,对于敏感数据的任何处理,都能够留下数据日志并打上唯一的数据水印,使任何可能的数据泄露之后,都能够追根溯源知道是哪一位员工在什么时间点在哪一台设备上运用何种权限下载的。对于一些操作过程中出现的风险点,良好的管理规范也能够实时发现,防患于未然。 Step 3. 建设数据管理平台 有的读者一听到数据管理平台,就认为是要花一大笔钱建设数据中心,把数据存起来。数据管理平台肯定要有数据中心的存储灾备功能,但是它的作用远不止此。 首先,数据管理平台要为企业量身定做一套数据组织和管理的解决方案,特别是企业各部门之间数据的共融共通,以及企业数据怎么样进行索引和关联。很多大企业,各部门之间数据的格式、形态和ID系统都不一致,部门之间无法交换数据,甚至大部分的数据表连主键和外键都没有,数据之间不可能形成有效的组织。这些都是数据管理平台要做的事情。 其次,数据管理平台是由业务所引导的,先进的流数据智能处理系统,要为业务提供直接的支撑。很多时候,数据管理平台怎么搭建,需要深度了解企业最重要的核心业务,通过有重大价值的示范性应用来牵引数据管理平台的建设。例如针对零售类的企业,就应该形成以消费者为中心的索引和画像系统,主要支持精准广告、智能客服等核心业务,其次才是以商品为中心的索引系统,主要支持物流和仓储优化等业务。 最后,数据管理平台的建设要量体裁衣,强调鲁棒性和可扩展性,没有必要一开始就投入大量经费。因为硬件成本的下降也很快,不用想太多半年甚至一年以后的事情,只要架构设计合理,到需要的时候扩充硬件是容易的。 大数据创新实践八步骤，如何成为一个大数据企业 Step 4. 建立海量数据的深入分析能力 要想建立针对多元异构、跨域关联的海量数据,通过深度分析挖掘获取价值的能力,主要要培养两个方面的能力。 第一,非结构化数据的分析处理能力。包括文本、音频、图像、视频、网络和轨迹等数据。受过传统商务智能和统计学训练的人,对于处理结构化数据非常在行,但是处理非结构化数据往往比较头痛——比如分布好做抽样,网络怎么进行抽样?所以,对于常见的,特别是和企业自身业务有密切关系的非结构化数据,一定要有一支队伍能够挖掘其间价值,甚至将其转化为结构化的数据。 第二,大数据下的机器学习的能力。绝大部分我们可以想象到的应用问题,其本质都是分类或者预测问题,包括个性化推荐、精分营销、员工绩效管理、银行信用卡征信、小微企业贷款、生产线控制、精准广告和网点选择,等等。解决这些问题最有力的武器就是机器学习!特别是在大数据环境下,很多高阶的核函数慢得不行,大量的学习都必须采用线性学习器;而且数据非常多,很多时候都是在强噪音环境下寻找弱信号,单一分类器往往效果一般,必须要做集成学习。举个例子,在Netflix举办的百万美元电影个性化推荐大赛中,我们做过一些很优美的单模型,但是比起在比赛中最后获胜的集成学习模型,至少从精度上来说是弱爆了!有的读者要问了,高性能存储计算难道不重要吗?不得有一些懂Hadoop,懂Spark的技术高手吗?要不要在CPU阵列里面加几块GPU甚至可编程逻辑阵列呢?这个也重要,但是企业如果实力足够,可以采用成熟的解决方案,国际上顶尖的本科大数据服务商,例如IBM、HP和Intel都有不错的方案。但是我说的上述两点,是给企业培养人才和能力,而且至今也没有特别好的成熟的解决方案,所以更重要。 最后,企业怎么建立这样的能力呢?首要办法是能够招聘到一流的大数据人才——多花点钱和股票。第二选择是以显示度项目为牵引,通过外部合作,培养自己的数据分析团队,既解决问题,又学习能力。企业做这类的合作,不要老想着一次性把所有东西都外包出去,要探索新方式,看看能不能成立联合小组共同进行研发,多投入一些人去学习。有一些供应商,特别是在某些方面有专长,但是还不属于国际一流的供应商,在发展过程中是能够接受企业这种要求的。 Step 5. 建设外部数据的战略储备 企业走到这一步,就有点现代大数据企业的理念了,因为它不再仅仅局限于自己业务的数据了,开始看外面的世界了——很多大数据的重大创新,都是来源于把数据放在产生数据的业务体系之外去应用。举个例子,一个服装企业要解决设计生产的规划问题,仅仅看自己的销售记录还不够,要不要看看淘包、天猫和京东上服装的整体销售,了解什么款式、什么颜色、什么价位的服装在哪个地区最受欢迎呢?这就需要外部数据了! 事实上,外部数据对于市场拓展、趋势分析、竞品分析、人才招聘、用户画像和产品推荐等意义重大,而网站、论坛、社交媒体和电商平台上聚集了很多有重要价值的公开数据,这些数据中的大部分可以通过分布式深网爬虫技术直接高效采集。所以,企业要有意识地开始建立自己的外部数据战略储备,不要“数”到用时方恨少。一方面,企业可以自建具备采集、清洗、存储和索引等功能的自动化系统,自动积累外部数据;另一方面,企业可以通过和数据供应商合作,得到一些亟需的数据。 Step 6. 建立数据的外部创新能力 企业很容易局限在自己的业务中不能自拔。所以,让企业理解外面的数据能够帮助解决自己业务遇到的问题比较容易,因为企业主和员工们每天都在想怎么解决这些问题,反过来,让他们去思考自己业务的数据能不能在其他地方产生重大价值,帮到其他企业,他们就没有那么敏感了。其实,这些创新性的想法往往能够带来新的巨大价值。比如,Google利用自身搜索业务产生的数据,进行电价和传染病流行情况的预测,取得了巨大成功。 事实上,企业通过智能终端、传感网络、物流记录、网点记录和电子商务平台,等等,获得的第一手数据,很多都可以用于支持在跨领域交叉销售、环境保护、健康管理、智慧城市、精准广告和房地价预测等方面的创新型应用。把握住这些机会,就能够放大企业当前业务的价值,带来持久可观的收益。 Step 7. 推动自身数据的开放与共享 伟大的企业懂得如何把最聪明的人集合起来,为自己服务。 企业有了大量数据和一定的分析能力后,不能故步自封,而要充分借助社会的力量,尽最大可能发挥数据潜藏的价值。Netflix曾经公开了包含50多万用户和17 770部电影的在线评分数据,并悬赏100万美元奖励能够将Netflix现有评分预测准确度提高10%的团队。现在的Netflix已经不再是一家电影在线租赁公司,而是国际一流的大数据企业了。除了法律上因为安全和隐私不能开放共享的数据,相当一部分都能够以各种方式开放出来——这种开放会带来更大价值!国际化的如 Kaggle(英文平台,kaggle),国内如 DataCastle(中文平台,pkbigdata),都是很有影响力的大数据创新竞赛平台。举个例子,电子科技大学大数据研究中心曾经在DataCastle上举办过学生成绩预测的比赛,总奖金才50 000元,却吸引了915支队伍2 000余名参赛者参加比赛,其中200多只队伍来自于“985”和“211”知名高校。这里面最佳解决方案的思路和方法已经被应用于教育大数据定量化管理的产品模块中了。最近现金巴士推出的“微额借贷用户人品预测大赛”更是吸引了1531支参赛队伍。还有一种最近新出的比赛方式,就是企业给出数据集的描述和样本数据,参赛选手设计创新型商业应用,提交产品说明或者商业计划书。 企业通过这些数据开放计划,可以学习最先进的算法和最具创新性的数据应用思路,实现自身数据的价值最大化。 Step 8. 数据产业的战略投资布局 企业有了一定的规模,光靠自己的能力还不够或者还太慢,就可以考虑通过投资的方式迅速形成自己的大数据能力甚至大数据产业布局。这类战略型的投资,有三个可能的出发点: (1)产业集成。从投资方原有优势产业或大数据前景广阔的重点产业入手,进行全产业链布局,集中力量。 (2)技术集成。以数据采集、存储、计算、分析和可视化的创新型工具为主要投资对象,提供具有普适性的解决方案。 (3)数据集成。以数据流动共享,发挥外部价值为理念,投资一批能够紧密合作、数据互补和可控性强的企业。 对于原来没有从事过数据密集型和信息技术密集型行业的企业来说,第二类投资方向的风险特别大,建议主要从(1)(3)两类考虑。这种投资有别于财物投资,主要是考量被投资企业与投资方的整合能力,以及所能提供俄数据的稀缺性、独立性、多源性、流动性和互补性。
-
发表了文章 2022-01-19
什么是开放数据生态系统
今天的开放数据生态系统公司如何为生活带来大数据 今天的公司正在收集大量的数据，以更好地了解客户，并制定更好，更知情的业务决策。通常，所有这些数据都涵盖了数十个，有时数千个不同的源，并且以多种格式，包括结构化和非结构化。连接所有这些数据并理解它是一种大规模和高度复杂的任务，但它是必不可少的。为了成功，公司必须能够在各种数据源和数据类型上连接。只有这样，他们才能实现洞察力并采取有意义的行动。 在过去的十年中，一系列技术已经前往现场有希望解决这个问题。由Hadoop运动领导，它首先在2000年代中期开始，当时产品和公司开始发芽，创建一个开放的数据生态系统。这种转向可组合技术（通常是开源，但不一定）的运动，与API集成并在商品化硬件上运行，以很大的方式挑战单体，相互依存架构的现状。通过采用商品化硬件的开放式分布式方法，这些公司挑战了专有的集中数据仓库中的传统存储和处理数据的传统设置。但最终，这些解决方案造成了宏伟的承诺，因为它们变得笨拙，难以管理和经济地不可规划。 最近，我们目睹了开放数据生态系统的复兴。由于云的崛起，开源数据格式的扩散和供应商的到来解决了早期的痛点，我们已经看到了一种新的开放数据生态系统公司出现，增长和普及。这些新解决方案能够捕获取公司内存的全部数据范围，使团队能够利用数据以充分优势利用。 我们一直在投资一系列企业技术公司，跨越数据，分析，AI，开源，DevOps，安全等十多年的更多。多年来，在这些行业遇到了数百家公司，我们想认为我们很了解这些领域。这是我们的信念，即开放数据生态系统公司现在在合适的时间完美地在正确的位置。 大数据和开放数据生态系统的诞生 几十年来，公司依赖于传统数据库或数据仓库，是一个主要的专有的集中存储库，其中存储和处理了结构化数据。传统的数据仓库系统需要购买昂贵的硬件，以专有格式维护结构化数据，并依赖于集中数据和IT部门来提供分析。 该系统 - 或传统的数据仓库 - 企业收集了一定数量的结构化数据。但在2000年代中期，像谷歌这样的公司遇到了这个模型的挑战。作为互联网经济的先驱，他们必须处理比以前不同的任何原始数据，这是一种非关系格式的有意义。谷歌只是一个大公司的一个例子，需要集中进程结构化数据（例如，关系表），半结构化数据（例如，日志）和非结构化数据（例如视频和照片）。 当时，没有超级计算机足够大的这项任务。所以要跟上，谷歌将永远扩大的计算机数量连到舰队中。最终，这种计算基础架构增长如此之大，即硬件故障变得不可避免，每个程序员都必须弄清楚如何单独处理它们。为了解决这些挑战，MapReduce可以在大规模的商品化硬件上逐渐处理并生成庞大的数据集。正如纽约人所说，他们创造了“谷歌的任何程序员可以使用的工具，以便在其数据中心中挥动机器，就像他们是单个行星大小的计算机一样。”一个计算架构可以在数千台机器上处理数据的数量，并且整个公司的编码器可以使用软件从谷歌的大型数据缓存中汲取洞察力。看到Jeffery Dean和Sanjay Gh Memaw在一个题为MapReduce中宣传他们的努力是这样的：在大集群上简化数据处理。 这个著名的论文揭开了我们称之为首次开放数据生态系统及其第一个化身，Apache Hadoop。Hadoop成为这篇论文引起了两个正在研究开源网上搜索引擎的工程师的注意。Duo受到Mapreduce的启发，然后他们建立了一个自由工具，他们于2006年发布。该工具被称为Apache Hadoop，它演变为开源项目的集合，这在从学术界带来了巨大作用。主流。开源框架允许任何人处理分布在计算机集群上的大量数据集，使其成为企业的一款非常有吸引力的选择，该企业在当天收集更多数据。 现在能够收集和分析大量的原始数据，公司转向更便宜的数据湖泊中的存储，这是大量的结构化，半结构化和非结构化数据。Loffules支持的公司，如Cloudera，Hortonworks和Mapr出现了使Hadoop更容易获得企业，导致许多世界上最大的公司采用Hadoop。从中携带，基于Hadoop的数据湖泊创造了开放数据生态系统的第一次迭代，带来了生活的实际承诺。 虚假的开始：为什么Hadoop的趋势开始下降 尽管当时具有可扩展性和灵活性，但第一代开放数据生态系统并没有实现它所拟定的宏伟目标。为了保持简单，这是Hadoop和第一代生态系统短暂的三个原因： 1.Hadoop太复杂了 Hadoop的哲学是尽可能多的技术整合，交易灵活性，功能，以简单和成本效益的互操作性。但最终，Hadoop太复杂，难以难以实现最终用户理解和运营。它还需要一个沉重的，它以其为中心的实现（需要大量节点有效），因此它不足以让最终用户下载特定情况。Hadoop的另一个主要挑战是它被用于太多超出其原始意图的东西（例如交互式分析不受欢迎）。新成立的大数据团队通过存储的数据量来测量其成功。添加到所有这些都是Cloudera和Hortonworks的相关VC备份启动，每个启动都尝试在数据堆栈上解决所有内容，以不同的方向拖动开源项目。 2.难以理解数据 在传统数据仓库中，公司仔细建模了他们的数据，定义了存储信息的位置，这在所有连接的情况下都是有价值的。该过程是耗时和效率低下（通常需要几个月和妨碍效率），但它将结构放在数据上。Hadoop开辟了稍后将数据丢弃到HDFS的可能性，并担心类，消费和管理。使用Hadoop，公司可以随意将数据转移到数据湖中。公司将竞争收集越来越多的数据，但他们没有考虑围绕访问，分析或可持续性的架构设计。公司难以知道他们的数据湖和它来自哪里。他们肯定无法从中提取价值。使用可以解决此问题的工具尚未出现，企业收集了大量数据，但缺乏对消费的信心。最后，数据湖泊变成了数据沼泽。 3.经济学不起作用 在Hadoop上了几年，云计算以大的方式起飞。云使公司更容易廉价地存储毕业证数据，以及使用服务进行数据治理和管理。与此同时，Hadoop仍然是主要用于预售的用例，并且必须通过集中的IT团队定期销售和升级。扩展容量意味着购买更多硬件，需要预先投资和数月的规划和部署。在云的时代，经济学变得无法理解。 毕竟曾经说过，第一代开放数据生态系统的垮台：自由成为全部。 开放的数据生态系统重新到达：你可以拥有你的蛋糕，也可以吃它 虽然Hadoop是它的承诺，但它启动的开放数据生态系统运动（以及Apache Spark等许多相关的开源项目）是活着的并且持久。其精神符合以下原则： 开放性：转向开放技术和数据标准，以及互操作性，而不是用单个专有供应商锁定。模块化：朝着分列的软件堆栈而不是单片架构移动。多样性：依赖于各种专用工具，用于不同用例，具有各种供应商，可以竞争客户的价值。 除了推动不断发展的开放数据技术集的这些原则外，许多关键力量推动了开放数据生态系统的复兴。在云中具有更可预测的性能和弹性，查询加速技术和开源格式避免数据副本，更好地通过相关的技术等数据治理对数据内容的监督，您现在可以拥有蛋糕（以打开格式存储大量数据弹性地）也可以吃它（直接运行相关的业务分析+ AI / ML工作负载）。 在更高的级别，对于CIO和CDOS，如果数据技术因其不可避免地发展而来，则使用具有开放标准的数据堆栈和开源技术使您对数据的数据更加未来的证据。广泛地，我们认为有四种主要趋势使得今天的开放数据生态系统更易于采用。 1.云数据湖的崛起 由于亚马逊S3，Azure Data Lake Storage（ADL）和Google云存储（GCS）等服务，公司可以在云本机数据湖泊中以规模铺设结构化和非结构化数据。这消除了对昂贵的单片硬件的需求，并使组织能够在没有相关管理开销的情况下扩展数据量。此外，云中的存储成本继续下降。因此，这些存储服务已成为云中的默认着陆区，通常被认为是记录系统。云，具有规模和多样性，本身促使分解为最好的品种，灵活的服务。云数据仓库，如Snowflake，AWSRedshift 和谷歌BigQuery，虽然并不是本身开放，但也非常有助于将数据带到云端。 2.采用开源数据格式 更多公司正在采用开放数据格式，例如Apache Parquet（柱状数据存储），Apache Arrow（用于分析，人工智能和机器学习的内存格式）和Apache Iceberge（表格格式/交易层）。这使得跨各种编程语言和实现更兼容的数据 - 包括不存在的工具 - 而不是根据特定工具或供应商，其中所有主云数据湖都互操作地支持这些打开的数据格式。 3.基于云的供应商的出现支持开放数据生态系统 一套不同的供应商正在解决一遍困扰Hadoop和第一代开放数据生态系统的问题，帮助使云数据湖更加可管理。Hadoop系统管理层对用户来说太复杂，今天的报价为客户处理这件作品，然后可以专注于核心业务功能。虽然FINGEN Systems仍然需要大量资本支出，用于预售的预售和存储，但云消除了昂贵的硬件到容纳数据湖泊的需求，而是支持基于资源的定价，因此公司基于他们使用的技术计算。此外，工具已弹出，帮助用户管理云数据湖泊的每个方面： 直接在云数据湖中运行SQL查询（DREMIO ，TRINO / PRESTO）摄取数据并将其写入打开格式（Segment ，Matillion ，Airbyte，Fivetran）在数据中流媒体（Confluent, Materialize）转换数据（来自Fishtown Analytics的Looker ，DBT）提高可观察性和质量（Great Expectations，Bigeye，Anomalo，Monte Carlo，Hightup）建立治理框架（Privacera ，Alation ）将数据同步到操作系统（Hightouch，Census，Gransaroo）处理策划（Airflow, Prefect, Dagster）为最终用户提供灵活和强大的消费层（InsignSpot ，Looker *） 4.在正确的抽象级别，符合最终用户的需要 在最终用户级别，开放数据生态系统中的新开发允许数据分析师，科学家和业务用户在他们喜欢的抽象级别下进行工作。这些数据用户对引擎盖下面发生的事情没有兴趣，并且不太关注相关的工作，例如手动模式更改，资源配置，数据库管理等先行开放数据生态系统所需的。相反，许多垂直集成的工具在抽象方面的级别太高。来自先前时代的许多“用户友好”的GUI集中的工具，当最终用户想要更深入时，何时无法提供足够的灵活性和深度。 虽然景观仍然迅速发展，但今天的工具旨在考虑抽象，并帮助开放数据生态系统与其需求的位置确切地满足最终用户。 什么是开放数据生态系统 为什么我们对现代开放数据生态系统看好 正如云的上升使新的开放式数据生态系统蓬勃发展，它也推动了专有云数据仓库的兴起，如Snowflake，因为业务移动初始子集到云上的数据。有些人认为Snowflake的方法，一个包括每个工作负载的单个云数据仓库，是唯一的道路。 我们认为云数据仓库和云数据湖将共存，数据流水线通常会在两者之间移动数据。与技术中的几乎所有事情一样，没有单一的灵丹妙药，真正的世界答案更复杂。然而，随着时间的推移，正如应用程序开发已经从单体架构转移到基于微服务的架构，我们可能会看到数据分析工作负载逐渐从专有数据仓库转移到开放的数据架构。这就是为什么我们在开放数据生态系统中的公司押注，如Dremio，Privacera，Alival，Idenspot，Segs和Looker。 我们对现代开放数据生态系统感到兴奋，因为它带来了众多福利： 成本效益：云数据湖泊提供了最便宜的方式来存储数据。不需要花费时间或资源转换数据以存储或分析它。可扩展性：公司可以轻松扩展他们的技术，从计算和存储的分离中受益选择：客户没有锁定在可以设定价格和条款的单个供应商。它们可以利用特定用例的最佳类型或最高值的选项。大多数工具是开源或SaaS，因此易于连接和操作。民主化：任何人都可以通过他们的首选框架访问公司的数据，而无需使用特定的工具或格式。这意味着数据分析师，数据科学家，应用程序开发人员和其他人可以有效地充分利用大多数数据。灵活性：客户可以使用他们选择的处理引擎（Spark，Dask，Dremio等）并以任何所需格式存储数据。这对于已经过时的企业，本地存储系统的企业至关重要，困难且昂贵，以完全达到云。 展望未来，我们认为公司将转向云数据仓库和云数据湖泊，以提供不同的需求并从他们的数据中获得价值很长一段时间。这一次，开放数据生态系统不会进入任何地方。
-
发表了文章 2022-01-19
人工智能已到瓶颈！院士“联名”反深度学习，指出AI未来发展方向
本文约3800字，建议阅读10+分钟。 针对深度学习的技术瓶颈，清华大学张钹等多位院士、教授给出了自己的研究思路。 前言 在刚刚结束的CCF-GAIR大会上，来自清华、加州大学伯克利、斯坦福、哈工大等多所国内外顶级理工科院校的院士齐聚深圳，分享了自己最新的研究。虽然各自研究的细分领域有所不同，但是透过贯穿始终的技术讲演，避不开的事实是，多位院士都在或直接或间接地去“批判”深度学习算法。 演讲中，他们再次明确指出深度学习的缺陷，进而点出，在可以预见的未来里，随着研究的推进，当下的深度学习算法将会逐步被拉下神坛。 不过，顺着学术界走入产业应用，会发现产业界的关注重点是在技术的落地。所谓落地，本质上就是无数应用场景的聚合。所以对于AI企业而言，对业务的探索和用恰当的技术去解决实际问题才是首当其冲的。 因此，深度学习存在缺陷，这一问题短期内并不会妨碍AI当下不可阻挡的发展之势，技术的局限也不意味着AI公司们将会无事可做。 但阳春白雪的研究始终引领着AI产业的技术走向，也是企业盈利和产业变革的关键驱动力。 所以，在深度学习被过度炒热的当下，我们理应试着站在院士们的“肩膀”上，看的更远。而企业家们在脚踏实地的同时，也应当不忘仰望星空。 尽管这已不是什么新鲜的话题，但是行业内一直没有可以解决问题的办法。本文旨在传达学术界研究者们提供的一些新思路。 机器学习的弊病 源于对“大”的误解 当下，最常被提起的名词就是机器学习、深度学习和神经网络，用数学上集合里的概念去理解这三者之间的联系，他们之间依次是包含的关系，即机器学习包含深度学习，深度学习包含神经网络。其中，四层以上的神经网络就可以称之为深度学习，而深度学习是一种典型的机器学习。 上世纪五十年代，神经网络这一算法结构出现，当时，它的正式名称应叫做感知机，但已经包含了输入层、隐含层和输出层这一经典的通用结构，并且随着隐含层层数的加深，对事情的描述就愈加精准。 但是，神经网络是一种以输入为导向的算法，所以优质的结果一定取决于接近“无穷”量级的数据。因而，在2000年互联网革命没有爆发之前，它一直都处在无人问津的阶段。 正如大家所知道的，互联网时代积累的大量数据和云计算带来的算力的大幅提升，极大地释放了深度学习算法（深层的神经网络）的潜力，因而也让人工智能时代全面爆发，产业应用得以蓬勃发展。数据显示，2022年我国人工智能市场规模达到216.9亿元，同比增长52.8%，预计2022年市场规模将达到339亿元。 然而，随着产业应用的成熟，以及大家对真正“智能”的渴求，让算力和深度学习算法本身的局限性，显露无疑。 人工智能已到瓶颈！院士“联名”反深度学习，指出AI未来发展方向 加州大学伯克利分校电子工程与计算机系教授 马毅 “老百姓概念里的‘大数据’和我们所认为的大数据是完全不一样的，就拿图像处理来说，数十亿的数据量看似量级很高，但对我们来说，它其实是‘小样本’。因为真正能够训练出好的模型的数据量，应当是趋于无穷的，所以即便是拥有了大量数据去训练模型，和理想的智能模型之间，也有着本质的差别。”从算法性质出发，加州大学伯克利分校电子工程与计算机系教授马毅也点出了当下这项火热技术的局限性。 因而从学者、投资人到AI头部企业，寻找新的技术和方向成为了现在的重点。 在会议的开场报告中，清华大学张钹院士呼吁大家思考的“如何走向真正的人工智能”成为了为期三天会议的基调，同时也反映了行业发展至当下阶段，众人的诉求。 新方向探索 数据处理方法、基本思想和技术思路 1. 数据处理层面，语义向量空间或进一步拓宽入口。 看见了技术的“天花板”，很多专家学者开始提出“小数据”的概念，然而清华大学人工智能学院院长张钹院士却不认为数据量的大小是当下的根本问题所在，他指出，传统的人工智能三要素将不能带来真正的智能。 人工智能已到瓶颈！院士“联名”反深度学习，指出AI未来发展方向 清华大学人工智能学院院长、中国科学院院士 张钹 “评价人工智能获得的成果，我们可以从这五件事来看：深蓝打败人类国际象棋冠军；IBM在电视知识竞赛中打败了美国的前两个冠军；2022年微软在ImageNet上做图象识别，学历证误识率略低于人类；百度、讯飞也都宣布在单句的中文语音识别上识别准确度略低于人类和AlphaGo打败了李世石。前两件事归为一类，后三件事可归为另一类。 大家一致认为，这五件事得以发生的三要素是：大数据、算力的提升和非常好的人工智能算法。但我认为大家忽略了一项因素，就是这所有的成果必须建立在一个合适的场景下。” 换言之，当下人工智能的发展避不开种种限制条件，因而智能的机器也只能够照章办事，没有任何灵活性，也达不到人们想要的智能，而这也就是当下AI的发展状态。 “我们现在的人工智能基本方法有缺陷，而我们必须走向具有理解能力的AI，这才是真正的人工智能。”张钹院士在演讲中指出。 那解决办法是什么呢？通过循序渐进，张院士在演讲中给出了思路，并指明语义向量空间这一技术方向。 “首先，需要明确的是，现有的机器缺乏推理能力的原因在于它没有常识。” 张钹院士通过实验验证，常识的建立确实会极大程度的提升机器的性能。而为机器建立常识库也成为人工智能企业进一步提升系统性能的第一步。“美国在1984年就搞了这样一个常识库的工程，做到现在还没完全做出来。可见，要走向真正的人工智能，有理解的人工智能，是一条很漫长的路。” 但即使在建立常识库的基础上，做到有理解能力的人工智能依然不容易。想要提升智能的第二步，在张院士看来，就是将感性和知识的世界统一起来，而这将为人工智能的发展带来一次质的飞跃。 “深度学习之所以能够极大的促进人工智能的发展，技术上的关键在于人们能够将获取的标量数据转变为向量，从而用到机器上。但至今为止，将行为（特征向量）和数据（符号向量）结合起来使用始终是科研的难点，而这就限制了机器变得更‘智能’。” 不仅如此，从安全层面来看，纯数据驱动的系统也存在很大问题——鲁棒性很差，易受到很大的干扰。因而，在大量样本的训练下，系统仍会犯重大的错误。如商汤、旷视等头部企业也表示，即便训练出的系统模型准确率高达99%，但在实际应用中，系统仍然会犯很多“弱智”的错误。 “我们现在想出的解决办法是这样的，就是把这特征向量空间和符号向量投射到一个空间去，这个空间我们把它叫做语义向量空间。” 怎么做？张院士表示： 第一，要通过Embedding（嵌入）把符号变成向量，尽量保持语义不丢失；第二就是Raising（提升），结合神经学科，把特征空间提升到语义空间。 “只有解决这些问题，我们才能够建立一个统一的理论。因为在过去，对感知和认知的处理方法是不同的，因而两者不在同一维度，无法统一处理。但如果我们能够将感知和认知投射到同一空间，我们就可以建立一个统一的理论框架，并在语义向量空间里解决理解问题。这是我们的目标，但是这项工作是非常艰巨。” 2. 基本思想的颠覆，模糊计算或是未来。 “无论是知识图谱，语义向量空间还是当下的其他深度学习训练，它们都是基于概率统计理论，而模糊逻辑不是，它是以模糊集理论为基础的。”非常大胆的，从思想层面，美国犹他州立大学计算机系终身教授承恒达给出了颠覆性的想法。 人工智能已到瓶颈！院士“联名”反深度学习，指出AI未来发展方向 美国犹他州立大学计算机系终身教授 承恒达 其实模糊逻辑并非全新的概念。1931年，Kurt G?del发表论文证明了形式数论（即算术逻辑）系统的“不完全性定理”，模糊逻辑诞生。而在1965年，美国加州大学的L.A.Zadeh博士发表的关于模糊集的论文，标志着人类首次用数学理论成功描述了不确定性。 “现在的计算机领域，不是0就是1，而我们描述的是0到1之间的很多不确定性成分，其实，这一过程描述的是导致结果的原因。以两瓶水为例，一瓶水上标记‘是纯净水的概率是0.91’，而另一瓶水上标记的是‘水的纯净程度是0.91’，你会选择哪一瓶呢？显然，你会选择后者。这里的思考判断过程就是模糊逻辑，因为后者对于程度的描述本质上就是模糊的。” 目前，类似于经典逻辑体系（微积分、线性代数、生物学等衍生学科），模糊逻辑也逐步形成了自己的逻辑体系。 然而再好的技术，都需要结合应用去展现它的优势。在这一方面，承教授也是格外重视，于是他选择了乳腺癌的早期诊断研究领域。“到目前为止，我们的设计样本已经被全世界二十多个国家，五十多个团队用来使用。” 在承教授看来，现有的技术存在着非常明显的不足，需要大家沉下心来去分析问题，从而探索到改进的方法。“现在大家都在模拟脑波中的电信号，但其实大脑里存在的不仅仅是电信号，还有化学反应。而很多人在做的医学图像处理，实际上只是做图像处理，却不是医学图像处理，它们之间是有着非常大的不同。” 3. 技术思路：大繁至简 当下，面对技术的毫无进展，AI公司的焦虑显而易见。不同于上面院士教授们给出的具体技术思路，马毅教授更像是科技界的“鲁迅”，他用PPT中一张张演讲稿中的优质论文做例，只为重新唤醒大家对于AI的思考。 人工智能已到瓶颈！院士“联名”反深度学习，指出AI未来发展方向 马毅教授现场PPT选 “神经网络，导入的数据有一个很小的改动，分类就会有很大的变化，这不是什么新发现，2010年，大家就遇到这样的问题，但至今没有解决。”演讲一开始，马毅就拎出了“老生常谈”，毫不留情的将一盆冷水浇到了众多对AI盲目乐观的人身上。 对技术的不正确认知，马毅也在极力得纠正。 “在人脸识别领域，要让算法具有鲁棒性，比写个AlphaGo要困难千倍。” “都说神经网络越大越好，这简直是胡说八道。” 嬉笑怒骂间，从事研究数年，马毅给出了自己的思考方向：“真正的优质算法一定是最简单的，比如迭代、递归，还有经典的ADMM，这些简单的算法就很好，也很有用。” 结语 接下来，人工智能技术的发展并不会乐观，尤其是产业发展将进入一个平缓期，但是这并不意味着学术界和产业界将无事可做。 人工智能已到瓶颈！院士“联名”反深度学习，指出AI未来发展方向 张钹院士现场PPT选 正如张钹院士指出的，“我们正在通往真正AI的路上，现在走得并不远，在出发点附近。但人工智能永远在路上，大家要有思想准备，而这也就是人工智能的魅力。” — 完 —
-
发表了文章 2022-01-19
大数据应用：大数据在医保管理中的应用与面临挑战
医疗保险面临基金收支平衡压力增大、医疗服务违规行为多发、传统经验决策方式落后等多方面挑战，从信息化建设角度，人社部门推进全民参保登记、医保智能监控、支付方式改革和移动支付探索等工作，积极开展了医保大数据应用。但在应用过程中仍然面临数据质量有待提升、数据应用尚不充分、安全体系还需健全等问题。继续深化医保大数据应用，下一步应重点围绕四个方面： 一是汇聚和完善医保大数据； 二是加快大数据平台建设； 三是持续助力医保业务发展； 四是构建数据安全体系。 大数据应用：大数据在医保管理中的应用与面临挑战 当前，在全民医保体系逐渐完善、人口老龄化趋势加剧、医疗需求快速释放、医疗费用不断攀升等因素的综合作用下，医疗保险面临基金收支平衡压力增大，医疗服务违规行为多发，传统经验决策方式落后等多方面挑战，如何充分利用大数据、“互联网+”等信息化手段，进一步支撑医疗保险在新形势下持续发展，实现全民医保、安全医保、科学医保和便捷医保，全面提升医保质量，是摆在我们面前的重要课题。 当前医保管理面临的困境 1.医保基金收支平衡压力增大 随着生活水平提高，参保人更加关注健康，医疗需求不断上升，同时全民医保从制度全覆盖转向人员全覆盖，基本医保支出规模随之快速增长。这些因素都给医保基金平衡带来较大压力。2022年，人社部门管理的基本医疗保险参保人数7.44亿人，基金支出10767亿元。参保人享受医保待遇25亿人次。考虑到当前经济下行和人口老龄化的形势，未来医疗保险基金收支平衡压力更大。 2.医疗服务违规行为多发 我国医保待遇支出高速增长，既有惠民生政策、人口老龄化、医疗技术进步、医疗成本上升等正常因素，更有大处方、乱检查、假发票等不合理因素。2022年审计署对医疗保险基金专项审计显示，一些医疗服务机构和个人通过虚假就医、分解住院、虚假异地发票等手段套取医保基金2亿余元。面对如此规模的支出，人工审核、抽查审核、固定规则审核等医保传统监管手段，对于日趋复杂的医保基金使用场景难以全面覆盖，对于日益隐蔽的医疗服务违规行为难以有效识别。 3.传统经验决策方式落后 过去医保政策制定和效率评估往往依赖业务知识和工作经验。随着参保人数的快速增长，医疗行为的复杂变化、医保经办人手普遍吃紧，传统的经验决策方式越来越无法满足业务发展需求，在当前信息技术快速发展、医疗数据不断积累的基础上，充分利用先进技术手段，深入挖掘海量数据资源优势，通过制度运行模拟、政策效率评估、资金压力测试等方式，辅助实现决策高效化、科学化、精确化，是医保业务发展的必然要求。 医保大数据的应用 社会保险信息化多年来秉承全国统一规划、统一建设的原则，伴随统筹层次提升，推进数据向上集中、服务向下延伸，逐步奠定了坚实的数据基础。利用渐成规模的医保大数据，人社部门积极推动多项应用，遏制违规行为，辅助科学决策，保护基金安全。 1.推动全民参保计划，实现全民医保 党的十八届五中全会通过的《中共中央关于制定国民经济和社会发展第十三个五年规划的建议》明确提出“实施全民参保计划，基本实现法定人员全覆盖”。2022年，人社部加快推进全民参保登记系统建设、部省对接、数据上报等工作，目前已基本形成部省两级全民参保登记库，支持摸清法定未参保人员情况，助力全民参保计划，实现应参尽参。截至2022年底，各省共计上报包括医疗保险在内的人员参保信息30.42亿条，为下一步参保扩面提供了有力的数据支撑。 2.实施医保智能监控，打造安全医保 2012年，人社部组织建设了医保智能监控系统，针对门诊、住院等不同业务环节设计了500余条监控规则，对频繁就医、分解住院、过高费用、大处方、药占比异常等常见违规医疗服务行为进行监控，监控对象涵盖医疗服务机构、医师、参保人员等。2014年，在前期工作基础上，人社部下发《关于进一步加强基本医疗保险医疗服务监管的意见》(人社部发〔2014〕54号)，明确了监管途径、各方职责、问题处理程序等。近几年，开展医保智能监控工作的统筹地区数量不断增加，目前全国超过90%以上的统筹地区已全面开展智能监控工作。通过全场景、全环节、全时段自动监控的震慑作用，遏制了大量潜在违法、违规行为，保障了参保人员权益和医保基金安全。 3.推广支付方式改革，促进科学医保 近年来，基于过去多年积累的医保数据，人社部门广泛开展了优化支付方式工作，积极推行复合式医保支付方式探索。2022年，国务院办公厅下发了《关于进一步深化基本医疗保险支付方式改革的指导意见》(国办发〔2022〕55号)，对改革目标提出了明确要求。目前绝大部分地区均开展了总额控制，分析医保历史数据是医保部门与医疗机构协商制定总额的主要依据。此外部分地区在单病种、DRGs等支付方式的探索过程中也充分利用了医保数据。如沈阳市从2022年开始探索DRGs支付，应用本地医保支付数据，优化DRGs分组。上海强化数学模型在医保预算中的应用，同步推进按病种付费。 4.探索医保移动支付，引导便捷医保 《“互联网+人社”2022行动计划》(人社部发〔2022〕105号)提出“支付结算”行动主题，要求建设人力资源和社会保障支付结算平台，拓展社会保障卡线上支付结算模式。社会保障卡经过十九年建设发展，为线上应用打下了深厚基础，具有身份凭证、信息记录、自助查询、就医结算、缴费和待遇领取、金融支付等功能，已成为持卡人方便快捷享受人力资源和社会保障权益及其他政府公共服务的电子凭证。各地根据文件精神，结合“互联网+”要求，积极探索实践医保移动支付，如杭州、武汉、深圳、昆明等地参保人可通过手机完成门诊费用医保支付，缓解窗口排队压力;沈阳、天津、嘉兴、珠海等地参保人可线上购药，通过手机或移动POS刷卡完成医保支付，改善用户体验。 医保大数据的应用挑战 1.数据质量有待提升 一是数据不完整。 从各地层面，社会保险信息系统管理的医保数据主要集中在参保、结算类基本数据，医疗行为过程中的医嘱、病历、药品进销存、检查检验报告等数据没有全面采集，文凭服务反馈、治疗效果类数据，以及日志、视频、文件等非结构化数据普遍缺失，制约了医保智能监控、支付方式改革等应用的深入开展，难以支撑面向参保人开展精准服务。从部级层面，自2009年开展医保联网监测指标上报以来，各地按月向人社部上报数据，医保主要包括参保、享受待遇、定点医疗机构等基本信息，缺乏业务明细信息。 二是数据时效性不强。 医保联网监测数据按月上报，支持了部级基金监管、宏观决策、社会保险参保待遇比对查询等多项系统应用。但按月更新的数据时效难以满足全国统筹、重点业务实时监控等新业务需要。 三是数据准确性不高。 从部级联网监测数据来看，虽然数据规模、覆盖人群快速增长，但仍然存在各险种、各业务基本信息、业务状态信息不一致，部分代码使用不标准、不规范，甚至存在不少错误或无效信息等问题，对数据的深入分析和广泛应用带来较大影响。 2.数据应用尚不充分 一是数据应用意识不足。 近年来，人社部门逐渐认识到数据的巨大价值，积极开展数据应用，但相较于人社部门管理的大数据，已开发的数据只是冰山一角，海量数据还在“沉睡”，沉睡数据中的问题不断累积，反过来影响数据应用工作开展。毕竟只有持续应用，才能从根本上促进数据质量提升。 二是对“问题数据”重视不够。 明显异常的数据一部分是数据质量低下的垃圾数据，也有部分是客观业务问题导致数据错误。在数据应用过程中，常常首先筛除异常数据，实际上也筛除了可能存在的问题和风险。大数据时代，更要培养重视异常数据的意识，善于从中发现问题、防范风险，逐步减少“问题数据”，提升数据质量。 三是跨业务数据应用不足。 目前对数据的开发应用，多集中于单业务板块，跨业务联动应用不足，如社保与就业数据关联分析、就医信息与人员生存状态的结合判断等。数据只有真正融会贯通，才能激发新思路，创造新价值。 3.安全体系还需健全 2014年，人社部先后下发了《人力资源和社会保障数据中心应用系统安全管理规范(试行)》(人社厅发〔2014〕47号)和《人力资源和社会保障数据中心数据库安全管理规范(试行)》(人社厅发〔2014〕48号)，从具体操作层面对应用系统和数据库安全提出了规范要求。然而，大数据环境下数据链条变长、数据规模增长、数据来源多样、数据流动性增强，使得数据安全保护难度加大，个人信息泄露风险加剧，传统的安全控制措施面临挑战。 大数据应用：大数据在医保管理中的应用与面临挑战 医保大数据的发展方向 1.汇聚和完善医保大数据 一是夯实基础信息。 统筹全民参保登记库和持卡人员基础信息库建设，完善部级人员、单位基础信息库，准确掌握服务对象基本情况，进一步发挥人社基础性信息库作用，实现一数一源、“一人一卡”。 二是整合信息资源。 从数据上报时效上，优化联网监测数据上报机制，由按月上报调整为按日实时更新;从数据上报粒度上，扩充上报指标，补充明细业务数据。从数据收集来源上，利用互联网、移动终端等渠道增加信息收集来源，补充医疗服务结果、质量、满意度等类数据，同时推动与医保局、卫健委等部门间数据共享，实现数据融合。 三是提升数据质量。 持续抓好数据质量提升，一方面做好与人口库等外部数据比对，核准数据资源。另一方面逐步排查数据异常原因，对可能存在的无效数据，进一步分析比对，发现问题及时督促整改。 2.加快大数据平台建设 实现对医保大数据的高效集约管理，建设大数据平台势在必行。 党的十九大报告提出要“建立全国统一的社会保险公共服务平台”，其内涵是运用“互联网+”、大数据等信息化手段，为群众提供无地域流动边界、无制度衔接障碍、参保权益信息更加公开透明、社保服务更加便捷高效、各服务事项一体化有机衔接的社会保险公共服务。高效的对外服务需要底层大数据平台的强大数据支撑能力，因此，建设适应人社业务，协同、监管、决策、服务的可靠安全人社大数据管理平台，作为大数据产生、汇集、分析和应用的基础，实现数据统一标准、统一管控，提升管理服务效率，为上层应用提供数据支撑服务，是当前的重点任务。 3.持续助力医保业务发展 大数据应用的根本出发点和立足点是推动业务发展，提升管理效能，实现决策科学化、监管精准化、服务人本化。 具体应用如：发挥大数据聚类、决策树等算法优势，支持单病种、DRGs等支付标准设计、测算和评价，推进多元复合式医保支付方式改革工作深入开展;完善药品数据和统一标准，借鉴各地先进经验，探索制定药品支付标准;利用大数据技术，分析并预测基金运行情况，完善筹资与待遇机制;深化医保智能监控系统应用，探索利用人工智能、图计算等前沿技术，提高监控精确度，实现更加智能化的监控;推进电子社保卡研究应用，提供网上费用结算、医保移动支付等服务，打造线上应用服务体系;利用大数据推荐模型，面向参保人提供精准推荐等健康管理服务。 4.构建数据安全体系 大数据环境下的数据应用实践，对数据安全和个人隐私保护提出了更高的要求。要切实树立数据安全意识，实现数据全生命周期管理，确保数据安全、完整和一致。 一是建立数据管理机制，包括信息资源目录、数据分级分类管理、数据安全管理制度、数据共享开放流程等，确保管理过程规范，权责明晰; 二是加强基础设施保障，启用电子印章、数据加密、生物特征识别等安全技术手段，为数据安全提供基础保障; 三是确保个人信息安全，提供服务要获得个人授权，保护个人隐私。(景玺、秦靖沂 人力资源社会保障部信息中心)成都加米谷大数据培训机构，个人大数据培训中秋国庆双节报名优惠活动进行中，详情见加米谷大数据微头条！
-
发表了文章 2022-01-18
技术分享：从甲方的角度谈谈WAF测试方法
0X01 测试思路 环境搭建 服务器：使用DVWA搭建一套包含各类漏洞的网站，并开启access日志以供分析。DVWA搭建过程不细说。 WAF：反向代理部署，将DVWA服务器做反向代理后映射出VS IP。测试时所有payload发送至VS IP，经WAF处理后交给DVWA服务器。 测试方法：客户端构造payload提交给VS IP，服务器查看access日志。如被有效识别并过滤，access日志应没有相关内容。 0X02 OWASP TOP10 常规防御 SQLi get型注入： /dvwa/vulnerabilities/sqli/?id=22&Submit=Submit#的参数id可以注入，构造payload提交即可。 post型注入：DVWA登录过程用burpsuite抓包，即可构造post型注入。 XSS 反射型XSS和存储型XSS在DVWA中都有，构造payload即可。 CSRF、command injection、Brute Foce、File upload等等方式，DVWA都有了，不细说。 漏掉的是SSRF、反序列化、structs、心脏滴血，这些攻击在当前版本的DVWA中是没有减肥设计的，需要单独考虑。 0X03 绕过技术的防御 除了最常见攻击手法的防御以外，WAF还应该具备识别变形的Payload的能力。 目前国内外商业WAF可以识别99%以上的常规攻击手段，区别主要就体现在对各类编码后的变形Payload的分析能力上。 这里面又区分成了两大类思路。 思路一： WAF抓取到HTTP包后，做多重解码，将每重解码的结果提取正则，与特征库进行匹配。各家能解码的层数会有区别。F5的ASM可以支持最多5层并且允许用户手工设定层数。其他家虽不可指定解码层数，但都具备响应能力。 思路二： 考虑到正则匹配容易误报漏报，有厂家放弃了这种分析模式，转而做语义分析。长亭科技的SqlChop就是如此，详情可阅读SQLChop - 一个新型 SQL 注入检测引擎 在测试中，需要手工对payload做编码变形。详细说来： SQLi变形 urlencode编码：别小看这种常见的绕过方法，有厂家的WAF还真检测不出来。 unicode编码 关键字大小写替换：这个比较常规了，基本是没有检测不到的。 关键字转为十六进制 关键字用反引号引起来 关键字用/#! #/注释引起来 关键字用/##/注释截断：select转为sel/**/ect 关键字用%00截断 提交的HTTP包中，将x-originating-IP 改为127.0.0.1 提交的HTTP包中，将X-remote-addr 改为127.0.0.1 SQLMAP的各类TAMPER，挨个试一试吧 XSS变形 XSS变形最多，WAF漏报也是最严重的。谁让HTML可利用的标签那么多呢。 这一块的测试，有赖于测试者平时收集各类XSS payload 的量。
2022年08月
-
08.15 00:45:10
发表了文章
2022-08-15 00:45:10
一篇文章带你了解JVM常见面试题有哪些
一篇文章带你了解JVM常见面试题有哪些 -
08.15 00:44:44发表了文章
2022-08-15 00:44:44
CSS浮动讲解
CSS浮动讲解 -
08.15 00:44:12发表了文章
2022-08-15 00:44:12
知识总结：CSS定位
知识总结：CSS定位 -
08.15 00:43:45发表了文章
2022-08-15 00:43:45
技巧篇：CSS高级技巧详解
技巧篇：CSS高级技巧详解 -
08.15 00:43:20发表了文章
2022-08-15 00:43:20
关于List集合，这份总结很全面
关于List集合，这份总结很全面 -
08.15 00:42:05发表了文章
2022-08-15 00:42:05
这篇文章教你轻松过dubbo+zk面试
这篇文章教你轻松过dubbo+zk面试 -
08.15 00:41:21发表了文章
2022-08-15 00:41:21
前端：Vue3为何使用Proxy实现数据监听
前端：Vue3为何使用Proxy实现数据监听 -
08.15 00:40:50发表了文章
2022-08-15 00:40:50
JavaScript的深拷贝实现
JavaScript的深拷贝实现 -
08.15 00:40:11发表了文章
2022-08-15 00:40:11
最近面试了13家企业软件测试岗位，面试题整理
最近面试了13家企业软件测试岗位，面试题整理 -
08.15 00:39:25发表了文章
2022-08-15 00:39:25
揭秘什么是面向接口编程
揭秘什么是面向接口编程 -
08.15 00:38:47发表了文章
2022-08-15 00:38:47
Spring Cloud Alibaba 新一代微服务解决方案
Spring Cloud Alibaba 新一代微服务解决方案 -
08.15 00:37:51发表了文章
2022-08-15 00:37:51
前端：如何在 JavaScript 中获取当前日期
前端：如何在 JavaScript 中获取当前日期 -
08.15 00:37:07发表了文章
2022-08-15 00:37:07
前端：给新手看的 React Hooks 教程
前端：给新手看的 React Hooks 教程 -
08.15 00:36:36发表了文章
2022-08-15 00:36:36
List集合源码分析
List集合源码分析 -
08.15 00:35:47发表了文章
2022-08-15 00:35:47
Spring MVC控制器的14个小窍门（重点！要考！）
Spring MVC控制器的14个小窍门（重点！要考！） -
08.15 00:35:01发表了文章
2022-08-15 00:35:01
你不知道怎么在Java中创建不可变类？详细教程
你不知道怎么在Java中创建不可变类？详细教程 -
08.13 21:20:58发表了文章
2022-08-13 21:20:58
59条有趣的程序员编程箴言
59条有趣的程序员编程箴言 -
08.13 21:20:22发表了文章
2022-08-13 21:20:22
30年工作经验的程序员老师机，教你如何提高python效率
30年工作经验的程序员老师机，教你如何提高python效率 -
08.13 21:18:20发表了文章
2022-08-13 21:18:20
人工智能时代的新“文盲”：学不懂Python,就看不到未来
人工智能时代的新“文盲”：学不懂Python,就看不到未来 -
08.13 21:17:23发表了文章
2022-08-13 21:17:23
让线程按顺序执行8种方法
让线程按顺序执行8种方法 -
08.13 21:16:15发表了文章
2022-08-13 21:16:15
让人才不再稀缺，让就业水到渠成-记传智播客总裁黎活明
让人才不再稀缺，让就业水到渠成-记传智播客总裁黎活明 -
08.13 21:12:15发表了文章
2022-08-13 21:12:15
10本大数据领域经典好书，助力你的学习
10本大数据领域经典好书，助力你的学习 -
08.13 21:11:33发表了文章
2022-08-13 21:11:33
7 个对 Java 意义重大的性能指标，你知道几个？
7 个对 Java 意义重大的性能指标，你知道几个？ -
08.13 21:10:17发表了文章
2022-08-13 21:10:17
6年资深开发带你10分钟了解Kafka ACL机制
6年资深开发带你10分钟了解Kafka ACL机制 -
08.13 21:07:08发表了文章
2022-08-13 21:07:08
多数程序员难以简单的方式开发应用？
多数程序员难以简单的方式开发应用？ -
08.13 21:06:06发表了文章
2022-08-13 21:06:06
读写 Redis RESP3 协议以及Redis 6.0客户端缓存
读写 Redis RESP3 协议以及Redis 6.0客户端缓存 -
08.09 23:06:01发表了文章
2022-08-09 23:06:01
接口自动化测试之Mock
接口自动化测试之Mock -
08.08 17:08:45发表了文章
2022-08-08 17:08:45
SpringBoot中的异常处理与参数校验_2
SpringBoot中的异常处理与参数校验_2 -
08.08 17:07:55发表了文章
2022-08-08 17:07:55
Python3中最常用的5种线程锁你会用吗
Python3中最常用的5种线程锁你会用吗 -
08.08 17:06:42发表了文章
2022-08-08 17:06:42
Python 中让你相见恨晚的 20 个骚操作
Python 中让你相见恨晚的 20 个骚操作 -
08.08 17:05:56发表了文章
2022-08-08 17:05:56
pytest系列之参数化
pytest系列之参数化 -
08.08 17:05:13发表了文章
2022-08-08 17:05:13
python 判断变量是否是 None 的三种写法
python 判断变量是否是 None 的三种写法 -
08.08 17:04:36发表了文章
2022-08-08 17:04:36
Oracle：Java9破坏了一些东西，开发者仍用Java8
Oracle：Java9破坏了一些东西，开发者仍用Java8 -
08.08 17:03:59发表了文章
2022-08-08 17:03:59
MySQL数据库 InnoDB引擎索引原理与设计索引调优简述
MySQL数据库 InnoDB引擎索引原理与设计索引调优简述 -
08.08 17:02:50发表了文章
2022-08-08 17:02:50
Mysql开发设计规范
Mysql开发设计规范 -
08.08 17:02:00发表了文章
2022-08-08 17:02:00
Monorepo与multirepo区别何在？
Monorepo与multirepo区别何在？ -
08.08 17:01:17发表了文章
2022-08-08 17:01:17
Keepalived+LVS+nginx搭建nginx高可用集群
Keepalived+LVS+nginx搭建nginx高可用集群 -
08.08 17:00:06发表了文章
2022-08-08 17:00:06
Java虚拟机是如何执行线程同步的
Java虚拟机是如何执行线程同步的 -
08.08 16:59:27发表了文章
2022-08-08 16:59:27
Java性能优化：Stream如何提高遍历集合效率？
Java性能优化：Stream如何提高遍历集合效率？ -
08.08 16:57:48发表了文章
2022-08-08 16:57:48
Java面试之框架篇
Java面试之框架篇
2022年02月
-
02.16 18:10:53发表了文章
2022-02-16 18:10:53
为什么不应该根据员工的住所支付工资
为什么不应该根据员工的住所支付工资 -
02.16 18:10:24发表了文章
2022-02-16 18:10:24
7个新手数据讲述者犯下的致命错误，你都知道吗？
7个新手数据讲述者犯下的致命错误，你都知道吗？ -
02.16 18:09:10发表了文章
2022-02-16 18:09:10
如何快速构建Slim Docker映像
如何快速构建Slim Docker映像 -
02.16 18:08:28发表了文章
2022-02-16 18:08:28
如何选择机器学习算法？
如何选择机器学习算法？ -
02.16 18:07:49发表了文章
2022-02-16 18:07:49
作为一个程序员的阴暗面
作为一个程序员的阴暗面 -
02.16 18:07:19发表了文章
2022-02-16 18:07:19
一年前的抢人大战后，25万月薪的AI工程师还存在吗？
一年前的抢人大战后，25万月薪的AI工程师还存在吗？ -
02.16 18:06:44发表了文章
2022-02-16 18:06:44
对20年前的程序员的我说：做这四件事
对20年前的程序员的我说：做这四件事 -
02.15 20:35:00发表了文章
2022-02-15 20:35:00
如何无效化缓存-分布式缓存问题
如何无效化缓存-分布式缓存问题 -
02.15 17:03:34发表了文章
2022-02-15 17:03:34
对20年前的程序员的我说：做这四件事
对20年前的程序员的我说：做这四件事 -
02.15 17:02:08发表了文章
2022-02-15 17:02:08
命名空间提供的值很小
命名空间提供的值很小
-
发表了文章
2022-08-15
一篇文章带你了解JVM常见面试题有哪些
-
发表了文章
2022-08-15
CSS浮动讲解
-
发表了文章
2022-08-15
知识总结：CSS定位
-
发表了文章
2022-08-15
技巧篇：CSS高级技巧详解
-
发表了文章
2022-08-15
关于List集合，这份总结很全面
-
发表了文章
2022-08-15
这篇文章教你轻松过dubbo+zk面试
-
发表了文章
2022-08-15
前端：Vue3为何使用Proxy实现数据监听
-
发表了文章
2022-08-15
JavaScript的深拷贝实现
-
发表了文章
2022-08-15
最近面试了13家企业软件测试岗位，面试题整理
-
发表了文章
2022-08-15
揭秘什么是面向接口编程
-
发表了文章
2022-08-15
Spring Cloud Alibaba 新一代微服务解决方案
-
发表了文章
2022-08-15
前端：如何在 JavaScript 中获取当前日期
-
发表了文章
2022-08-15
前端：给新手看的 React Hooks 教程
-
发表了文章
2022-08-15
List集合源码分析
-
发表了文章
2022-08-15
Spring MVC控制器的14个小窍门（重点！要考！）
-
发表了文章
2022-08-15
你不知道怎么在Java中创建不可变类？详细教程
-
发表了文章
2022-08-13
59条有趣的程序员编程箴言
-
发表了文章
2022-08-13
30年工作经验的程序员老师机，教你如何提高python效率
-
发表了文章
2022-08-13
人工智能时代的新“文盲”：学不懂Python,就看不到未来
-
发表了文章
2022-08-13
让线程按顺序执行8种方法
滑动查看更多
暂无更多信息
暂无更多信息