- Java
- 容器
-
Java
初级
能力说明：
了解变量作用域、Java类的结构，能够创建带main方法可执行的java应用，从命令行运行java程序；能够使用Java基本数据类型、运算符和控制结构、数组、循环结构书写和运行简单的Java程序。
-
数据库
初级
能力说明：
具备数据库基础知识，了解数据库的分类，具备安装MySQL数据库的能力，掌握MySQL数据类型知识，基本了解常用SQL语句，对阿里云数据库产品有基本认知。
暂时未有相关云产品技术能力~
-
提交了问题
2023-01-16
百问求答（3）Flink专场！回答问题赢行李箱等好礼
-
发表了文章 2023-01-10
系列征文2｜后端领域主题征文开始啦！参与即有奖！
征稿主题：本次征文以“后端”为主题，围绕开发者们在后端学习、开发中的思考与感悟。后端征文细分领域可参考：系统开发、架构设计、服务器、数据库等。征文方向包括但不限于：主流技术：结合自身业务场景的后端技术文章。如：数据库、容器、嵌入式、架构、敏捷开发等。编程语言：分享你在后端开发中编程语言使用心得和实操技巧。如：Python、JAVA、C++、PHP、GO等。开发工具：介绍你在后端开发中的使用工具。如：IDEA、Eclipse、Navicat、Notepad++、GIT等。计算机体系架构：分享后端领域中的计算机基础知识等。如：数据存储、CPU架构与指令集、操作系统、编译原理、LINUX等。技术趋势：探讨后端领域的技术演进趋势。如：云原生、微服务、中台、Dubbo、DevOps等。欢迎前往社区分享创作的价值！投稿报名表单：https://survey.aliyun.com/apps/zhiliao/Q_Wkv_OXD活动奖励：1、笔耕不辍奖——1名针对一个问题/技术点进行深度解析，产出5篇以上的体系化优质内容。符合征文要求并质量最优（有评论有点赞）的用户，获得米家智能空气炸锅*1。2、写作达人奖——88名参与发表文章>3篇且符合征文要求的前88位用户，获得写作达人礼品——小米双肩背包*1。3、博主新人奖——不限在活动期间成功发文3篇即可成为阿里云开发者社区技术博主，可获得虚拟徽章+乘风者定制手机支架。注：如用户已经是阿里云开发者社区博主，不参评此奖项4、参与奖——不限在活动期间成功投稿1篇的用户，即可获得社区积分。所得积分可前往积分商城进行礼品兑换。投稿方式：1、直接进入社区官网：https://developer.aliyun.com/ ，登录之后，点击“发文章”按钮即可进行创作。如您还不是阿里云用户，会提醒您先注册成为阿里云用户，并完成实名认证。点击进行注册；注：已完成过注册或实名认证的用户可直接跳过此步骤。2.写完文章后点击发布，审核通过后即可在我的创作查看文章详情。3.填写投稿报名表单，表单链接：https://survey.aliyun.com/apps/zhiliao/Q_Wkv_OXD，审核成功后，即视为参与成功。活动规则：1、活动面向社区所有开发者进行征文，在阿里开发者社区成功发文1篇即视为参与征文活动。2、参与本活动的文章发布且通过审核时间需在2022年1月1日-1月31日之间。3、文章需为用户自发文，且符合社区审核规范。社区鼓励技术干货类内容，文章字数（不含代码串）500字及以上，且格式整齐规范，尽量图文并茂。4、活动中的“天”“工作日等均值改日的0点至24点（北京时间）5、阿里云可以根据活动的实际情况对活动规则进行变动调整，相关变动或调整将公布在活动页面上。并于公布时间即时生效；但不影响用户在活动规则调整前已经获得的权益。6、标题党、黑稿、通稿、包含违法违规、未被许可的商业推广、外站链接、非原创内容，有洗稿、营销软文、抄袭嫌疑的文章审核将不予通过，同时取消活动资格。7、本次征文活动投稿截止时间为2022年1月31日，开奖名单将于活动结束后7日内公布，奖品将于活动结束14日前寄出，如遇节假日则顺延。
-
发表了文章 2023-01-09
一文梳理Code Review方法论与实践总结
作为卓越工程文化的一部分，Code Review其实一直在进行中，只是各团队根据自身情况张驰有度，松紧可能也不一，这里简单梳理一下CR的方法和团队实践。一、为什么要CR提前发现缺陷在CodeReview阶段发现的逻辑错误、业务理解偏差、性能隐患等时有发生，CR可以提前发现问题。提高代码质量主要体现在代码健壮性、设计合理性、代码优雅性等方面，持续CodeReview可以提升团队整体代码质量。统一规范和风格集团编码规范自不必说，对于代码风格要不要统一，可能会有不同的看法，个人观点对于风格也不强求。但代码其实不是写给自己看的，是写给下一任看的，就像经常被调侃的“程序员不喜欢写注释，更不喜欢别人不写注释”，代码风格的统一更有助于代码的可读性及继任者的快速上手。防止架构腐烂架构的维护者是谁？仅靠架构师或应用Owner是远远不够的，需要所有成员的努力，所谓人人都是架构师。架构防腐最好前置在设计阶段，但CodeReview作为对最终产出代码的检查，也算是最后一道关键工序。知识分享每一次CodeReview，都是一次知识的分享，磨合一定时间后，团队成员间会你中有我、我中有你，集百家之所长，融百家之所思。同时，业务逻辑都在代码中，团队CodeReview也是一种新人业务细节学习的途径。团队共识通过多次讨论与交流，逐步达成团队共识，特别是对架构理解和设计原则的认知，在共识的基础上团队也会更有凝聚力，特别是在较多新人加入时尤为重要。二、他山之石2.1 某大厂A非常重视Code Review，基本上代码需要至少有两位以上Reviewer审核通过后，才会让你Check In。2.1.1 代码评审准则如果变更达到可以提升系统整体代码质量的程度，就可以让它们通过，即使它们可能还不完美。这是所有代码评审准则的最高原则。世界上没有“完美”的代码，只有更好的代码。评审者不应该要求代码提交者在每个细节都写得很完美。评审者应该做好修改时间与修改重要性之间的权衡。2.1.2 代码评审原则以客观的技术因素与数据为准，而非个人偏好。在代码样式上，遵从代码样式指南，所有代码都应与其保持一致，任何与代码样式指南不一致的观点都是个人偏好。但如果某项代码样式在指南中未提及，那就接受作者的样式。任务涉及软件设计的问题，都应取决于基本设计原则，而不应由个人喜好来决定。当同时有多种可行方案时，如果作者能证明（以数据或公认的软件工程原理为依据）这些方案基本差不多，那就接受作者的选项；否则，应由标准的软件设计原则为准。如果没有可用的规则，那么审核者应该让作者与当前代码库保持一致，至少不会恶化代码系统的质量。（一旦恶化代码质量，就会带来破窗效应，导致系统的代码质量逐渐下降）2.1.3 代码审核者应该看什么设计：代码是否设计良好？这种设计是否适合当前系统？功能：代码实现的行为与作者的期望是否相符？代码实现的交互界面是否对用户友好？复杂性：代码可以更简单吗？如果将来有其他开发者使用这段代码，他能很快理解吗？测试：这段代码是否有正确的、设计良好的自动化测试？命名：在为变量、类名、方法等命名时，开发者使用的名称是否清晰易懂？注释：所有的注释是否都一目了然？代码样式：所有的代码是否都遵循代码样式？文档：开发者是否同时更新了相关文档？2.2 某大厂B在开发流程上专门有这个环节，排期会明确排进日程，比如5天开发会排2天来做代码审核，分为代码自审、交叉审核、集中审核。有明确的量化指标，如8人时审核/每千行代码，8个以上非提示性有效问题/每千行代码。2.3 某大厂C推行Code Owner机制，每个代码变更必须有Code Owner审核通过才可以提交。所有的一线工程师，无论职级高低，最重要的工程输出原则是“show me the code”，而Code Review是最能够反应这个客观输出的。尽量让每个人的Code Review参与状况都公开透明，每个变更发送给项目合作者，及转发到小组内成员，小组内任何人都可以去Review其他人的代码。明确每个人的考评和Code Review表现相关，包括Code Review输出状况及提交代码的质量等。三、我们怎么做CR3.1 作为代码提交者发起时机：发起Code Review尽量提前，开发过程小步快跑代码行数：提交Code Review的代码行数最好在400行以下。根据数据分析发现，从代码行数来看，超过400行的CR，缺陷发现率会急剧下降；从CR速度来看，超过500行/小时后，Review质量也会大大降低，一个高质量的CR最好控制在一个小时以内。明确意图：编写语义明确的标题（必填）和描述（选填，可以包括背景、思路、改造点和影响面、风险等）善用工具：IDEA打开编码规约实时检测，减少代码样式、编码规约等基础性问题（阿里编码规约插件：https://github.com/alibaba/p3c/tree/master/idea-plugin）3.2 作为代码评审者3.2.1 评审范围主要从两方面来评审：代码逻辑功能完整：代码实现是否满足功能需求，实现上有没有需求的理解偏差，对用户是否友好；逻辑设计：是否考虑了全局设计和兼容现有业务细节，是否考虑边界条件和并发控制；安全隐患：是否存在数据安全隐患及敏感信息泄漏，如越权、SQL注入、CSRF、敏感信息未脱敏等；性能隐患：是否存在损害性能的隐患，如死锁、死循环、FullGC、慢SQL、缓存数据热点等；测试用例：单元测试用例的验证逻辑是否有效，测试用例的代码行覆盖率和分支覆盖率；代码质量编码规范：命名、注释、领域术语、架构分层、日志打印、代码样式等是否符合规范可读性：是否逻辑清晰、易理解，避免使用奇淫巧技，避免过度拆分简洁性：是否有重复可简化的复杂逻辑，代码复杂度是否过高，符合KISS和DRY原则可维护性：在可读性和简洁性基础上，是否分层清晰、模块化合理、高内聚低耦合、遵从基本设计原则可扩展性：是否仅仅是满足一次性需求的代码，是否有必要的前瞻性扩展设计可测试性：代码是否方便写单元测试及分支覆盖，是否便于自动化测试3.2.2 评审注意事项尽快完成评审避免过度追求完美明确评论是否要解决避免使用反问句来评价我们主要是通过交叉CR、集中CR相结合的方式，由应用Owner+SM+架构师+TL完成。四、CR怎么避免流于形式CR流于形式的因素很多，大概如下：不认同CodeReview评审者的姿态？有没有带来好处？有没有从中收获？这些都会直观影响团队成员的认可度每个Review建议的提出都是一次思想交流，评论要友好、中肯、具体，避免教条式及负面词汇，在遵守评审原则下，同时尊重个性展现团队集中CodeReview尽量不要太正式和严肃，轻松的气氛下更有助于互相理解，来点水果，聊聊业务聊聊代码在Review过程有时候会陷入谁对谁错的争论，只要是为了寻求真理辩证的去看问题，哪怕是讨论再激烈也是有收获的，注意只对事不对人。CodeReview后改动太大发布前发现问题多，改动太大，影响项目计划大项目要求编码前设计评审，小需求可以事先Review设计思路，避免最后的惊喜每次Review的代码行数最好控制在数百行以内评审者没有足够时间评审者在任务安排上尽量预留好时间尽快评审，代码在百行以内及时响应，在千行以内当日完结评审者不了解业务和代码代码提交人编写清晰的标题和描述有必要的情况下评审者需要了解PRD评审者需要提前了解系统和代码Review建议未修改这一点极为重要，需要对修改后的代码再次Review，确保理解一致，以及预防带问题上线应用可以设置Review建议需全部解决的卡点，同时对于非必需修改的建议可以进行打标或说明五、CR实践中发现的几个常见代码问题笔者对个人CR评论问题做了个大概统计，Bug发现数占比约4%（直接或潜在Bug），重复代码数占比约5%，其他还有规范、安全、性能、设计等问题。在CR代码质量时，可以参考《重构：改善既有代码的设计》，书中所列的22种坏味道在CR中基本都会遇到。而此处我们主要聚焦以下几个常见问题：5.1 DRYDRY是Don't Repeat Yourself的缩写，DRY是Andy Hunt 和 Dave Thomas's 在《 The Pragmatic Programmer 》一书中提出的核心原则。DRY 原则描述的重复是知识和意图的重复，包含代码重复、文档重复、数据重复、表征重复，我们这里重点讲讲代码重复。5.1.1 代码重复《重构》中对“Duplicated Code（重复代码）”的描述：坏味道行列中首当其冲的就是Duplicated Code。如果你在一个以上的地点看到相同的程序结构，那么可以肯定：设法将它们合而为一，程序会变得更好。最单纯的Duplicated Code就是“同一个类的两个函数含有相同的表达式”。这时候你需要做的就是采用Extract Method (110)提炼出重复的代码，然后让这两个地点都调用被提炼出来的那一段代码。另一种常见情况就是“两个互为兄弟的子类内含相同表达式”。要避免这种情况，只需对两个类都使用Extract Method (110)，然后再对被提炼出来的代码使用Pull Up Method (332)，将它推入超类内。如果代码之间只是类似，并非完全相同，那么就得运用Extract Method (110)将相似部分和差异部分割开，构成单独一个函数。然后你可能发现可以运用Form Template Method (345)获得一个Template Method设计模式。如果有些函数以不同的算法做相同的事，你可以选择其中较清晰的一个，并使用Substitute Algorithm (139)将其他函数的算法替换掉。如果两个毫不相关的类出现Duplicated Code，你应该考虑对其中一个使用Extract Class (149)，将重复代码提炼到一个独立类中，然后在另一个类内使用这个新类。但是，重复代码所在的函数也可能的确只应该属于某个类，另一个类只能调用它，抑或这个函数可能属于第三个类，而另两个类应该引用这第三个类。你必须决定这个函数放在哪儿最合适，并确保它被安置后就不会再在其他任何地方出现。代码重复的几种场景：一个类中重复代码抽象为一个方法两个子类间重复代码抽象到父类两个不相关类间重复代码抽象到第三个类CASE：private BillVO convertBillDTO2BillVO(BillDTO billDTO) { if (billDTO == null) { return null; } BillVO billVO = new BillVO(); Money cost = billDTO.getCost(); if (cost != null && cost.getAmount() != null) { billVO.setCostDisplayText(String.format("%s %s", cost.getCurrency(), cost.getAmount())); } Money sale = billDTO.getSale(); if (sale != null && sale.getAmount() != null) { billVO.setSaleDisplayText(String.format("%s %s", sale.getCurrency(), sale.getAmount())); } Money grossProfit = billDTO.getGrossProfit(); if (grossProfit != null && grossProfit.getAmount() != null) { billVO.setGrossProfitDisplayText(String.format("%s %s", grossProfit.getCurrency(), grossProfit.getAmount())); } return billVO; }正例private static final String MONEY_DISPLAY_TEXT_PATTERN = "%s %s"; private BillVO convertBillDTO2BillVO(BillDTO billDTO) { if (billDTO == null) { return null; } BillVO billVO = new BillVO(); billVO.setCostDisplayText(buildMoneyDisplayText(billDTO.getCost())); billVO.setSaleDisplayText(buildMoneyDisplayText(billDTO.getSale())); billVO.setGrossProfitDisplayText(buildMoneyDisplayText(billDTO.getGrossProfit())); return billVO; } private String buildMoneyDisplayText(Money money) { if (money == null || money.getAmount() == null) { return StringUtils.EMPTY; } return String.format(MONEY_DISPLAY_TEXT_PATTERN, money.getCurrency(), money.getAmount().toPlainString()); }5.1.2 DYR实践忠告：不要借用DRY之名，过度提前抽象，请遵循 Rule of three 原则。不要过度追求DRY，破坏了内聚性，实践中需要平衡复用与内聚。5.2 Primitive Obsession《重构》中对“Primitive Obsession（基本类型偏执）”的描述：大多数编程环境都有两种数据：结构类型允许你将数据组织成有意义的形式；基本类型则是构成结构类型的积木块。结构总是会带来一定的额外开销。它们可能代表着数据库中的表，如果只为做一两件事而创建结构类型也可能显得太麻烦。对象的一个极大的价值在于：它们模糊（甚至打破）了横亘于基本数据和体积较大的类之间的界限。你可以轻松编写出一些与语言内置（基本）类型无异的小型类。例如，Java就以基本类型表示数值，而以类表示字符串和日期——这两个类型在其他许多编程环境中都以基本类型表现。对象技术的新手通常不愿意在小任务上运用小对象——像是结合数值和币种的money类、由一个起始值和一个结束值组成的range类、电话号码或邮政编码（ZIP)等的特殊字符串。你可以运用Replace Data Valuewith Object (175)将原本单独存在的数据值替换为对象，从而走出传统的洞窟，进入炙手可热的对象世界。如果想要替换的数据值是类型码，而它并不影响行为，则可以运用Replace Type Code with Class (218)将它换掉。如果你有与类型码相关的条件表达式，可运用Replace Type Codewith Subclass (213)或Replace Type Code with State/Strategy (227)加以处理。如果你有一组应该总是被放在一起的字段，可运用Extract Class(149)。如果你在参数列中看到基本型数据，不妨试试IntroduceParameter Object (295)。如果你发现自己正从数组中挑选数据，可运用Replace Array with Object (186)。给我们的启示主要有两点：大部分业务场景和语言环境下，结构化类型导致的开销基本可以忽略结构化类型带来更清晰的语义和复用CASE：反例@Data public class XxxConfigDTO implements Serializable { private static final long serialVersionUID = 8018480763009740953L; /** * 租户ID */ private Long tenantId; /** * 工商税务企业类型 */ private String companyType; /** * 企业名称 */ private String companyName; /** * 企业纳税人识别号 */ private String companyTaxNo; /** * 审单员工工号 */ private String auditEmpNo; /** * 审单员工姓名 */ private String auditEmpName; /** * 跟单员工工号 */ private String trackEmpNo; /** * 跟单员工姓名 */ private String trackEmpName; }正例@Data public class XxxConfigDTO2 implements Serializable { private static final long serialVersionUID = 8018480763009740953L; /** * 租户ID */ private Long tenantId; /** * 企业信息 */ private Company company; /** * 审单员工信息 */ private Employee auditEmployee; /** * 跟单员工信息 */ private Employee trackEmployee; } @Data public class Company { /** * 工商税务企业类型 */ private String companyType; /** * 企业名称 */ private String companyName; /** * 企业纳税人识别号 */ private String companyTaxNo; } @Data public class Employee { /** * 员工工号 */ private String empNo; /** * 员工姓名 */ private String empName; }其实就是怎么去抽象，对于特定领域的对象可以参考DDD里面的Domain Primitive（DP）。5.3 分布式锁5.3.1 未处理锁失败private void process(String orderId) { // do validate try { boolean lockSuccess = lockService.tryLock(LockBizType.ORDER, orderId); if (!lockSuccess) { // TODO 此处需要处理锁失败，重试或抛出异常 return; } // do something } finally { lockService.unlock(LockBizType.ORDER, orderId); } }分布式锁的目的是为了防止并发冲突和保证数据一致性，锁失败时未处理直接返回，会带来非预期结果的影响，除非明确失败可放弃。5.3.2 手写解锁容易遗漏上面的加锁和解锁都是手动编写，而这两个动作一般是成对出现的，在手动编写时容易发生遗漏解锁而导致线上问题，推荐封装一个加解锁的方法来实现，会更加安全和便利。private void procoess(String orderId) { // do validate Boolean processSuccess = lockService.executeWithLock(LockBizType.ORDER, orderId, () -> doProcess(orderId)); // do something } private Boolean doProcess(String orderId) { // do something return Boolean.TRUE; } // LockService public <T> T executeWithLock(LockBizType bizType, String bizId, Supplier<T> supplier) { return executeWithLock(bizType, bizId, 60, 3, supplier); } public <T> T execteWithLock(LockBizType bizType, String bizId, int expireSeconds, int retryTimes, Supplier<T> supplier) { // 尝试加锁 int lockTimes = 1; boolean lock = tryLock(bizType, bizId, expireSeconds); while(lockTimes < retryTimes && !lock) { try { Thread.sleep(10); } catch (Exception e) { // do something } lock = tryLock(bizType, bizId, expireSeconds); lockTimes++; } // 锁失败抛异常 if (!lock) { throw new LockException("try lock fail"); } // 解锁 try { return supplier.get(); } finally { unlock(bizType, bizId); } }5.3.3 加锁KEY无效private void process(String orderId) { // do validate try { // 此处加锁类型与加锁KEY不匹配 boolean lockSuccess = lockService.tryLock(LockBizType.PRODUCT, orderId); if (!lockSuccess) { // TODO 重试或抛出异常 return; } // do something } finally { lockService.unlock(LockBizType.PRODUCT, orderId); } }注意加锁类型与加锁KEY在同一个维度，否则加锁会失效。5.4 分页查询5.4.1 完全没有分页反例private List<OrderDTO> queryOrderList(Long customerId) { if (customerId == null) { return Lists.newArrayList(); } List<OrderDO> orderDOList = orderMapper.list(customerId); return orderConverter.doList2dtoList(orderDOList); }正例private Page<OrderDTO> queryOrderList(OrderPageQuery query) { Preconditions.checkNotNull(query, "查询条件不能为空"); Preconditions.checkArgument(query.getPageSize() <= MAX_PAGE_SIZE, "分页size不能大于" + MAX_PAGE_SIZE); // 分页size一般由前端传入 // query.setPageSize(20); long cnt = orderMapper.count(query); if (cnt == 0) { return PageQueryUtil.buildPageData(query, null, cnt); } List<OrderDO> orderDOList = orderMapper.list(query); List<OrderDTO> orderDTOList = orderConverter.doList2dtoList(orderDOList); return PageQueryUtil.buildPageData(query, orderDTOList, cnt); }没有分页的列表查询对DB性能影响非常大，特别是在项目初期，因为数据量非常小问题不明显，而导致没有及时发现，会给未来留坑。5.4.2 分页size太大反例private Page<OrderDTO> queryOrderList2(OrderPageQuery query) { Preconditions.checkNotNull(query, "查询条件不能为空"); query.setPageSize(10000); long cnt = orderMapper.count(query); if (cnt == 0) { return PageQueryUtil.buildPageData(query, null, cnt); } List<OrderDO> orderDOList = orderMapper.list(query); List<OrderDTO> orderDTOList = orderConverter.doList2dtoList(orderDOList); return PageQueryUtil.buildPageData(query, orderDTOList, cnt); }分页size的大小并没有一个固定的标准，取决于业务需求、数据量及数据库等，但动辄几千上万的分页size，会带来性能瓶颈，而大量的慢SQL不但影响客户体验，对系统稳定性也是极大的隐患。5.4.3 超多分页慢SQL反例<!-- 分页查询订单列表 --> <select id="list" parameterType="com.xxx.OrderPageQuery" resultType="com.xxx.OrderDO"> SELECT <include refid="all_columns"/> FROM t_order <include refid="listConditions"/> ORDER BY id DESC LIMIT #{offset},#{pageSize} </select>正例 <!-- 分页查询订单列表 --> <select id="list" parameterType="com.xxx.OrderPageQuery" resultType="com.xxx.OrderDO"> SELECT <include refid="all_columns"/> FROM t_order a INNER JOIN ( SELECT id AS bid FROM t_order <include refid="listConditions"/> ORDER BY id DESC LIMIT #{offset},#{pageSize} ) b ON a.id = b.bid </select>以上 bad case 的SQL在超多页分页查询时性能极其低下，存在多次回表甚至Using Filesort的问题，在阿里巴巴编码规范中也有明确的规避方案，此处不展开。最后，我们工程师的智慧结晶都尽在代码之中，而Code Review可以促进结晶更加清莹通透、纯洁无瑕、精致完美，值得大家一起持续精进！
-
提交了问题
2023-01-09
【藏经阁一起读（43）】读《达摩院智能对话技术升级-更类人，更温暖》，你有哪些心得？
-
提交了问题
2023-01-06
社区有了这些新变化，邀你来反馈！
-
提交了问题
2023-01-05
是谁在帮助我们悄悄提高生产力？
-
提交了问题
2023-01-03
【藏经阁一起读（42）】读《必致（BizDevOps）白皮书2022》，你有哪些心得？
-
提交了问题
2022-12-30
乘风问答官1月排位赛开启！话题、问题双赛道，机械键盘等你赢！
-
发表了文章 2022-12-27
【讲讲训练营的故事】开始征集啦 参与就有奖 还有阿里云公仔等你来拿~
2022年，我们开办了百余期训练营，包括云产品训练营、企业实战训练营、技能认证训练营、开源产品训练营、求职就业训练营、高校训练营~亲爱的小伙伴们都参加了哪些训练营呢？快来和大家分享下学习上的收获吧，期待您将自己的学习经验录制成小视频分享给我们~活动时间：2022年12月27日-2023年1月8日活动方式：录制一段针对训练营的露脸视频 ，并同意授权我们使用(仅用于内外部的传播)。并截图分享您在社区学习训练营取得的成就。录制内容包括：我是谁，从事什么岗位等简要介绍我参与过什么训练营，训练营对我的帮助可以围绕对你帮助最大、学习感受最深、觉得体验最好的一个营详细举例说明 录制视角请参考下图，手机就可以，避免录制成大头照哦~ 活动奖品：参与奖：参与录制提交给小助手——钉钉搜索wangzehua9，即可获得无线充电器特等奖：被选中制作宣传视频的作品，可获得阿里云ET公仔注意事项：奖品将于活动结束30个工作日内发出，如有疫情则延长；活动相关问题可在钉钉咨询小助手——钉钉搜索wangzehua9。
-
提交了问题
2022-12-26
【藏经阁一起读（41）】读《阿里云云原生 Serverless 案例集》，你有哪些心得？
-
发表了文章 2022-12-26
2022藏经阁年度电子书榜单出炉！技术干货实战精华一手掌握！
今天，我们为大家准备了最受开发者欢迎的2022年度最热Top10书籍，本本优质，页页精华，更有藏经阁打卡阅读赢好礼活动，临近年关，呼朋唤友来阅读吧！藏经阁“月”读计划藏经阁活动升级，在APP上也能尽享技术干货！12月起藏经阁推出“月”读计划，每月根据不同主题精选相关电子书，内容涵盖编程语言、云原生、数据库、大数据、AI等热门技术领域，让开发者们能够掌上阅读优质内容。每周在APP内阅读推荐电子书，连续打卡7天就有机会获得社区精美礼品，快来一起“月”读吧！活动链接直达：https://developer.aliyun.com/qirixue/cangjinggeTop10书籍随着业务的发展和团队扩大，微服务架构成为了许多大规模开发团队的不二选择。本书着重分享如何借助于治理的能力，高效构建完整的微服务治理体系，提升开发效率和线上稳定性，为业务的又快又稳发展保驾护航。《4天实战轻松玩转docker》本书全面剖析了docker原理及在运维工作的地位和作用，运维工作进化论，docker、微服务、k8s的联系，devops和docker的关系，docker的前世今生等方面让大家轻松学习docker！《低代码引擎技术白皮书》低代码引擎是一款为低代码平台开发者提供的，具备强大定制扩展能力的低代码设计器研发框架。本书从应用、基础协议和原理三个方面对低代码引擎的技术进行了全面的介绍，对低代码产品研发有诉求的同学速来学习~《可视化架构运维实践》在云计算越来越趋于基础设施化的今天，大中小客户使用云时通常会遇到的一些挑战，来看看阿里云空中架构师是如可解决的吧！本书详解了阿里云空中架构师云速搭 CADT 为上云应用提供可视化自助式云架构管理，如何显著降低应用云上管理的难度和时间成本。《应用多活技术白皮书》目前，容灾成为企业上云和用云的基础要求，所有的上云企业都把容灾系统能力建设作为最基础目标来要求，并保证投入。本书帮助企业解决多活容灾的落地第一步问题为目的，通过应用多活技术，帮助企业的系统稳定性更上一层楼！《云原生架构白皮书2022年新版》拥抱云计算、拥抱云原生架构、用技术加速创新，实现企业数字化转型升级成功！本书全方位展示了云原生架构规划与实践全景，助力企业更好地理解与应用云原生架构，共同定义、共同迎接云原生时代。《剖析企业数字化的降“本”增效》在中国互联网行业高速发展的十年，驱动数字化企业发展的差异化竞争能力是数字化能力和技术创新能力。本书将由阿里技术专家刘伟光为你深度剖析企业数字化的降“本”增效，重新审视“降本增效”的“本” 到底是什么？《2021技术人的百宝黑皮书》阿里巴巴淘系技术2021一整年的精华技术内容合集，涵盖了大前端、音视频、推荐系统、 客户端架构、服务端架构、技术质量、以及3D&AI&AR类等多个技术领域。更有2021年度必看的技术&行业报告、开源项目、顶会 paper 等多⻆度知识与价值的输出！《Apache Flink 案例集（2022版）》本书汇聚大量真实行业实践，了解大量来自不同领域的公司在数据集成、数据分析、人工智能、云原生以及企业数字化转型等应用场景中使用 Apache Flink 解决实际生产问题的成功案例，用Apache Flink加速企业的实时化平台搭建和业务转型。《以架构视角解读和落实银行数字化转型的两份重磅》本书完整地解读了中国人民银行印发的《金融科技发展规划(2022—2025 年)》和银保监会印发的《关于银行业保险业数字化转型的指导意见》。这对在积极筹备数字化转型工作的各类银行而言，正是 2022 年开年布局的最好指导。2022年，阿里云开发者藏经阁收纳400+技术实战精华电子书，聚焦云原生、物联网、大数据、AI等30+技术领域。累计收获超200万的总下载量超200万、超8000万的曝光量。阅读量Top10、五大系列好书可在完整榜单中查看，更多丰富技术读物就在藏经阁，快来一键免费获取吧！点击链接查看完整榜单：https://developer.aliyun.com/topic/ebook2022点击下方链接，获取藏经阁海量免费书籍！https://developer.aliyun.com/ebook
-
提交了问题
2022-12-19
提升研发效能真的能实现降本增效吗？
-
发表了文章 2022-12-19
云栖精选第二弹：最全2022云栖大会内容大放送！为精彩技术打call！
云栖大会（Apsara Conference）以引领计算技术创新为宗旨，承载着计算技术的新思想、新实践、新突破。历经14载，见证了中国计算产业的萌发与革新。今年云栖大会共举办60+数字技术、产业与生态峰会/论坛，上千位院士、科学家、学者、行业领军者汇聚一堂，带来一场场科技与计算的碰撞之旅~阿里云开发者社区特为大家整理了各专场的精彩内容合集电子书，带领大家再次“云”回峰会现场，探讨数字产品，感受顶尖科技趋势~本期我们将走进龙蜥峰会、云原生数据库峰会、下一代互联网（IPv6）规模化部署论坛来走进云计算的魅力吧~云栖精选第一弹回顾戳👉链接一、《开放算力·云启未来》>>免费下载<<奋进谋发展，笃行创新业。截至目前，龙蜥操作系统下载量已经达到230万，装机量超过300万。龙蜥社区当前有21家理事单位和超250家生态合作伙伴，近50个SIG组，上百位Maintainer，上千名开发者。龙蜥社区在短时间内实现的跨越式发展，与社区坚持的平等、开放、协作、创新的准则息息相关。本书精选自云栖大会“龙蜥峰会”，围绕“开放算力·云启未来”的主题，打造了操作系统产业主论坛、 eBPF&Linux 稳定性专场、RISC-V 专场、云原生专场共 4 个会场，聚焦社区演进、 技术实践、生态发展和开发者培养四大维度，呈现一个繁荣的开源社区全貌。 二、《云时代的数据库技术趋势》>>免费下载<<阿里云数据库率先提出「云原生数据库 2.0」概念，通过打造云原生一站式的 数据管理与服务，旨在为用户提供：更快、更稳、更安全、更好用的数据库产品。 本书精选自“云栖大会云原生数据峰会”，邀请数据库学术界领军人物为您介绍云时代的数据库发展趋势；行业 权威人士就相关数据库行业标准进行深入解读；技术大咖带来 Serverless、云原生 HTAP 等前沿技术介绍；标杆客户与您分享云原生数据库的最佳实践；开源社区及高 校学术负责人与您共论数据库的开源生态建设与人才培养。 三、“下一代互联网（IPv6）规模化部署论坛”文章合集1.IPv6规模部署和创新实践2.开发IPv6潜能支撑算网协同发展3.云网融合时代IPv6相关技术发展探讨4.IPv6/G-SRv6技术创新及应用5.新华三IPv6创新及实践6.阿里巴巴应用IPv6规模化部署——面向云计算与互联网业务的IPv6技术研发及应用网络是互联网的水电煤，而IP 是网络基石。在全国大力推进IPv6规模部署和创新发展的背景下，本论坛由浙江省委网信办指导，阿里巴巴主办，邀请重量级嘉宾和专家介绍IPv6技术和产业发展趋势、IPv6最佳实践、IPv6示范创行应用。论坛还将举办浙江省IPv6规模部署和下一代互联网创新实验室挂牌和启动仪式。论坛实录电子书即将于下周和大家见面，敬请期待~更多精彩内容持续发布，社区藏经阁也将持续上新云栖内容集锦电子书，欢迎关注！我们下一期见！
-
发表了文章 2022-12-16
Flink+Hologres实时数仓在Lazada的建设及应用
阿里正在将国内成功的商业模式用于东南亚市场进行探索与尝试。上图为东南亚6个主要国家的商业调研数据，Lazada综合电商平台包含Marketplace、LazMall、跨境等多种商业模式，通过自建物流网络与推出LazPay不断升级东南亚电商的基础设施。大数据在国内经过淘系将近20年的打磨，已经非常成熟。Lazada数据体系与淘系数据体系非常相似，主要分为六个部分。最左侧为数据源，最右侧为数据应用，中间为数据集成、数据建模与计算、数据聚合与集市以及数据服务。数据集成主要依靠cdp和datahub系统，数据建模分为离线和实时两部分，其中离线模块基于 MaxCompute ，实时模块基于 Flink 平台实现了实时数仓。集市层，2020年后逐渐使用 Hologres统一替换了此前比较繁杂的数据结果层与数据计算层中间件。大促是电商常见且非常重要的场景，我们期望能够通过实时数据和实时技术赋能大促或改变整个业务形态。大促营销分为三个阶段，分别是促前、促中与促后。促前包括各种准备工作，比如招商、选品、会场页面搭建，是一些比较离线或长周期的动作；促中阶段需要预热蓄，为加购、流量分发以及动态调控做准备，此阶段多为实时决策与实时调控，需要实时数据作为支撑；促后需要进行业务复盘与数据分析、数据PR等。为了支撑业务侧的实时决策与实时调控，需要对原先的离线数据架构进行改造。因此，我们利用 Flink+ Hologres将数据链路全部进行实时化、体系化升级，利用 Hologres 的OLAP查询能力，能够在大促当天支持业务做实时分析，比如在极短时间内进行快速查询与分析，圈选优惠券发放的目标人群。大促发放优惠券讲究策略与节奏，比如需要圈选目标人，发完券之后用户是否领取了优惠券、领取之后有否使用等问题都会影响大促节奏的调控。我们需要基于实时数据，业务开发人员结合更多数据资产、用户本身的购买力、消费习惯做目标人群锁定，并在大促期间给出实时反馈。具体实现如下：从 DataHub 消息中间件消费用户的实时领取与使用数据。同时因为大促周期长，需要将用户历史状态数据也一并进行计算。因此还会将离线 odps 表作为初始化表，在 Flink 任务里进行实时与离线两种不同数据的 source 消费。消费完之后，一方面会将数据写进 DataHub 消息中间件，推送给下游营销系统直接消费与使用；另外会将数据存放到 Hologres，为业务人员提供实时 OLAP 分析的数据指标与数据标签。数据存入Hologres里既能够对用户购买力、消费习惯与偏好类目等基础性数据资产类数据做分析，同时也能与大促中的实时变化交易与权益变化数据做关联查询，快速锁定不同业务需要的目标人群。通过以上技术链路与方案，能够实现大促场景中动态调整运营策略与运营动作业务过程。该方案中，使用Flink计算引擎同时消费实时与离线两种不同数据源,实现了流批体实时计算；能够将用户历史累计权益数据结合实时变化权益数据进行实时计算，得到用户全状态的权益领用及实时数据。此外，架构里还实现了实时与离线混合 OLAP 分析，在 Hologres 计算引擎里存有离线数据，供一些较为复杂的离线方式计算，计算后同步到 Hologres，再将线上实时变化的状态类数据也同时写入 Hologres。因此，Hologres里会有全量状态与非常大范围用户的整体数据，除了能够观测到当前状态，也能够对历史行为与表现进行综合性的分析。通过该方案，营销活动系统从原先的离线化状态成功过渡到可调控、可决策、可落地的实时系统。Lazada LAB实验平台累计了万级的实验数量，实验数量排名处于 top 5 水平，支持百级子业务阈，千级月实验人数。LAB架构分为三个层次，从下至上分别是数据模块、系统模块和应用模块。数据模块层利用的数据存储引擎已经全部切换为 Hologres 。实验里通用的数据和业务指标会进行提前预计算，能够减轻Hologres 的计算压力。另外，会将明细层数据与轻度汇总层数据通过实时计算方式写到Hologres里，以支撑在AB 实验场景里自定义与灵活快速分析所需的能力。最后，将各种实验维度数据同步到 Hologres 进行自定义分析与查询使用。上图为LAB平台实验的数据流加工过程。数据源是常见的Binlog 数据，包括日志采集、搜推广日志数据等。离线数仓也会进行数据加工，然后写到离 Hologres。另外会通过Flink实时计算与操作，将实时的明细层与汇总层数据同步到 Hologres 。因此 Hologres 里建立了一套完整的实时数仓，有实时的 DWD明细层， ADS 层存有很多计算好的离线数据，还有DWS数据以及维度数据。其上还建设了大量逻辑视图与部分物化视图，因为实验场景中，查询条件或查询模式对于表的使用非常固定，可能需要通过逻辑视图与物化视图将经常使用的查询方式与指标固化，增加前端的实验性能。以上架构利用 Hologres 强大的查询与数据写入导出能力，提升了整个 LAB平台的实验速率与效率。关于Hologres的使用，存储方面，分布式数据的使用首先必须确保数据合理均匀地分布存储，另外，数据使用行存还是列存，需要依赖于业务场景和使用诉求。分区表选择时，一定要有分布键。TableGroup 与Shard分配时，需要做校验操作，有维表校验，也有事实表之间的校验。因此需要结合维表数据量与业务场景不断实践与摸索。计算方面，Hologres提供了主键的设计替代、近似计算、聚簇索引、时间分段索引、优化字典编码等存储引擎。阿里利用 MaxCompute 支撑与实现了离线数仓的基础体系建设。Flink 问世后，阿里数据体系从原先的离线系统彻底转化为实时数仓体系。随着 Hologres等云原生OLAP数据引擎的诞生，我们已经可以窥到湖仓一体可能的实现和使用方式，并以此支撑异构多元智能计算。我们期望能够利用 Hologres服务与分析一体化的能力，结合 AI 处理，在一个平台、一个组件上快速完成数据加工，将业务价值通过技术平台高效释放。牛顿说，站在巨人肩膀上能让我们看得更远。而我们也坚信，有阿里云这样一个巨人，我们能够将数据业务价值发挥得更加透彻、更加淋漓尽致。
-
发表了文章 2022-12-16
阿里云实时计算Flink版产品介绍
2016年，阿里集团首先使用 Flink +Hologres 构建了内部应用，比如大屏。 2019 年收购了 Flink 初创公司。 2020 年开始， Flink 逐渐发展成为实时计算的事实标准。2022 年，阿里云Flink成为中国唯一进入Forester象限的实时流计算产品，也是唯一全面通过中国信通院基础能力、性能、稳定性三款测评的分布式流处理平台产品。源于社区、兼容社区、超越社区是阿里云实时计算Flink的定位。企业版Flink基于社区版做了很多能力的增强，更适合企业使用。首先，它是一款全托管产品， serverless架构，无需关心资源、版本、运维等。性能上，企业版比开源版本优化提升2-3倍。它提供了企业级的丰富能力，比如上下游数据连接 connector 、作业自动调优、风控相关的能力、智能诊断以及全面告警监控等，也开放了被集成能力，可以与企业内部已有平台做完美整合。上图为客户案例。客户有基于YARN自建的集群，规模6400核，500多个作业，最大作业 200 核，集群资源水位70%以上，已无法进行扩容。最大痛点在于集群作业互相影响，高峰期间有抢占现象，造成流计算不稳定，运维相关人力投入较多，资源也难以管控与配置。客户要求成本不能高于自建，且迁移的同时还需完成调优，解决重点作业资源过多的问题。此外，不能改变现有架构，需要与现有企业内的其他系统融合。经过我们的优化后，该客户的规模由6400核降至3900 核，资源优化率达40%。Flink的企业级能力也得到了充分认可，从测试到迁移到调优，仅花费2个月。上图为一站式开发流程。开源Flink没有开发平台，只能使用命令行窗口。越来越多用户希望能够不再通过写 Java 代码进行开发，而是使用 SQL 进行开发，更加简单直观。希望能够在平台上很方便地实现数据源查看、数据结果展示、单步调试以及使用特殊 session 集群进行结果打印，在开发时能够享受更易用的界面。Flink企业版支持模拟数据生成connector，可以用于做压测，模拟真实业务场景。sessiong集群可以更好地进行作业启停、结果查看。Flink是一个纯计算引擎，没有中间结果，无法像数据库一样方便地查看，因此运维是一个大问题，对此，我们的平台提供了很多功能。首先，会给运行中的作业提供整体筛查条件，比如基于风险筛查，每分钟刷新状态。在每个作业级别均可设置重要行为告警，比如是否重启、是否 checkpoint 成功以及记录延迟情况并基于延迟告警。Flink作业的metrics 指标非常丰富，我们将所有指标发送至阿里云 ARMS ，提供基于指标做告警的能力。针对所有数据，平台提供了指标大盘并进行分类，用户可以非常直观地查看。资源调优也一直是很多用户的痛点。实时作业上线要用多少资源、是否存在浪费等，可以通过 metrics 指标查看 CPU 负载或空闲情况并进行调节。自建集群在业务高峰低谷时，需要手动启停作业、手动进行调整，过程复杂。而实时计算Flink支持了自动调优与定时调优两种策略。自动调优指用户无需关心资源，作业上线运行一段时间之后可以根据流量、指标情况自动对作业资源进行调节。可以设置一定的规则，比如两次调节时间间隔、资源限制等。定时调优适用于相对高阶的用户，对自己的作业足够了解，比如早上九点将资源配置为10个并发，晚上9点自动调整为 5 个并发。作业启动之后会遇到很多问题，比如启动时慢、停止时慢。实时计算Flink提供了基于阿里集团内部最佳实践的智能诊断。诊断项不是随着产品版本发布，而是定期更新，更新频率非常快。它会将常见问题放到诊断里面，目前已经覆盖十几种风险点，诊断结果会告知针对该情况应如何处理。Flink实时计算的运维覆盖了状态的全生命周期，对业务稳定性、连续性和灵活性起到了至关重要的作用。实时计算Flink可与企业内部的大数据平台做集成。后续还会推出与开发工具集成的能力，开发工具可以直接将作业提交到到平台上运行。上图为 9 月发布的重点新特性。① 状作业态集管理。将状态的管理与作业的启停解绑，不会再因为作业启停对状态造成影响；作业快照完成时间平均提升 5-10 倍，恢复时间平均提升 5 倍。② 作业资源定时调优。③ 作业健康分。为每个作业的健康度打分，作业的异常、重启或配置问题都会影响健康分。④ Open API 。产品均基于 OpenAPI 架构设计，因此在界面上看到的功能都可以集成到企业自己的平台上。⑤ Flink 1.15 支持。这是业界首次企业版 Flink 1.15 发布。⑥ 作业启动速度平均提升15%。上图为作业状态集管理界面。其中包括系统检查点和作业快照，系统检查点即checkpoint，作业快照即savepoint 了。用户可自定义策略，定时策略可以不同的时间粒度设置自动快照，重启时可从快照进行作业恢复。上图为作业资源定时调优页面。如图所示，可以根据实际需求将周一至周五的并发配置为10，周六周日并发配置为5。此外，时间粒度可以选择为月、周、天以及小时等。上图为资源分析界面。Flink 产品默认所有作业启动运行时都会开启资源分析功能。作业只要在平台上运行，就会持续分析资源状态是否健康，并给出调整建议。与 CDC 作业配合，比如从 Flink到Hologres 有从全量到增量写的过程，全量数据比较大，可以将配置改为自动调优，以多并发跑；增量时，数据量比较小，自动将并发下调。自动调优可以配置相关参数，可以设置规则，比如两次重启时间间隔、最大并发数、最小并发数等均可配置。如果购买了云上产品并选择后付费模式，作业资源自动调优能够极大节省成本。上图为作业健康分页面。比如显示健康分为46 分，因为作业近期持续重启。如果健康分为100，也会提供相关诊断结果，显示进行检测的项目。2022年3月和5月发布了很多其他重要功能。其中Flink CDC 是近一年以来推出的非常重要的企业级特性，主要包含以下几个方面：① MySQL和 PG connector 同步了社区 CDC 2.2版本，修复了一些 bug ，新增了参数。② 支持了Kafka catalog ，可以新建Kafka catalog ，解析Kafka里的特殊格式信息，支持解析JSON 格式消息获取Schema。JSON 格式发生变化时，写到结果表的结构也会根据 JSON 自动变化。③ 独有的CDAS语法实现了整库同步，支持分库分表和同步的能力，比如将 MySQL 整库数据、分库分表数据同步到下游 Hologres等产品。④ MySQL CDC connector 支持PolarDB-X和PolarDB Mysql数据源。⑤ 入湖方面，内置了企业级Hudiconnector，上游可以打通 CDC 链路，全量增量读取 MySQL 数据，下游可以自动同步到Hudi。上游 MySQL 的表结构变更也可自动同步到Hudi。集成了阿里云OSS和DLF等组件，完善数据在计算引擎之间的连通性。Flink CDC 是目前云上用户使用较多的场景，它可以替代已有的开源数据集成工具，它基于开源工具做了增强和修复，比如其全量、增量以及全增量一体的能力是其他开源数据集成工具所不具备的，Flink CDC 也可以支持更多上游以及 MySQL 相关的数据库，支持分库分表、表结构同步，支持元数据的管理比如无锁读取、断点续传等。下游同样支持很多开源、闭源产品。比如表结构变更场景，如果上游是 MySQL ，下游是Hologres，当上游表结构发生变更时，能够自动在 Hologres 里完成变更；比如分库分表合并，假设原先作业上游表是三个，分库分表后变为四个，过程中数据作业无需停止，数据可以一直写到下游。上图为Flink CDC+Hologres实时数仓能力总览。实时计算Flink能够实现海量数据实时入仓的价值在于：对于MySQl中的TPC-DS 1T数据集，使用阿里云Flink 64并发，只需5小时即可完全同步到Hologres，TPS约30万/秒。 Binlog同步阶段，同步性能最快可达 10 万条/秒。实时计算Flink能够实现双流Join构建DWD宽表。双流Join使用 Flink 还有一个节省成本的方案，主键关联的场景可以将Join的工作下沉到Hologres，通过Hologres的局部更新功能实现宽表merge，从而省去了Flink Join的状态维护成本。维表 Lookup 也是 Hologres 与Flink 的组合方案。Hologres 既可以做原表，也可以做结果表，还可以作为维表使用。上图为Flink CEP系统架构，将开发人员与测试人员进行解耦。规则保存在Hologres 或 RDS 里，可以实时查看规则并进行维护和修改。修改之后，Flink会自动完成规则更新，保证业务连续性。另外，该架构支持Flink SQL与Datastream API。Q&AQ：自动调优需要要设置资源的最大阈值吗？A：默认上限为64核，可以调小。Q：使用 Flink 需要提前购买CU，购买时是否要预留最大值？A：如果使用自动调优，则应该购买按量付费模式，而不是预留模式。Q：可以按项目设置不同付费模式吗？A：可以购买多个实例，比如某个实例按量付费，某个实例包月模式。刘一鸣：Flink X Hologres构建企业级一站式实时数仓一、实时数仓的技术需求大数据计算正从规模化走向实时化、在线化。大屏是传统大数据应用的常见场景，实时展示是它极其重要的功能。数据分析分为线上和线下两部分。线下部分偏对内分析，要求分析灵活度足够高，因此一般采用数仓技术。在线业务是典型的 QPS 远高于队列分析的场景，QPS通常为10 万+级别，延迟也从秒级变为毫秒级。因此，在线业务必须采用更复杂的架构。一般使用 lambda 架构，一部分数据放在 OLAP 系统，一部分放在在线系系统比如HBase、Redis ，架构相对更复杂。且在线业务引进了更多预计算，提高了计算效率。基于以上要求，大数据实时数仓体系变得极其纷繁芜杂。离线加工主要解决海量数据问题，实时加工将计算前置，在事件发生时即产生结果，多采用预计算 Flink 技术，将结果集存放至 HBase、Redis ，对外提供更快速的点查服务。中间还存在一些近实时场景，希望分析更灵活，而如果全部采用预计算会牺牲灵活性。因此我通常采用像zk 、join等，以明细方式提供分析能力，规模相比离线数仓较差，但灵活性比预计算更好。因此，同一份数据源会进入离线、在线以及近实时三条链路。用户希望访问数据时有一个统一的门户，无需做不同的授权或访问不同的接口。此外，联邦分析系统跨多数据源访问时，访问体验往往不可预期，取决于数据源的性能。因此，我不得不将大数据加工变为小数据，导入 Redis 做缓存，但这依旧没有解决灵活性问题。因为将数据聚合之后，无法查看明细。而随着业务的复杂度增加，问题定位也变得愈加困难。每个系统都需要运维，数据冗余、不一致等情况也愈发频繁。此前的架构下，处处都是数据孤岛，存在高成本、数据冗余、高维护代价、数据一致性无法保证等问题，多个系统带来了高昂的学习成本。分析数据的方式没有本质变化，但是我们不得不因为系统的 IO 效率问题，考虑将一份数据拆成不同方式、存在不同系统里，造成很多数据孤岛。业界对于实时数仓的要求大概分为三个阶段。第一阶段相对比较通用，接近于数据库的概念，能做查询、查询接口尽量标准（SQL），分析数据相对灵活。第二阶段在实时上场景做了很多优化，比如实时写入、高吞吐实时更新、实时查询及写入即可用，希望数据产生到消费中间端的间隔周期足够短。第三阶段为一站式实时数仓，能够实现端到端实时加工。过去的数仓更偏向于队列分析、经营分析报表，如今已经演变为在线系统。对接了在线业务系统之后，数据有加工业务，有队列经营分析业务，也有在线分析支撑在线系统业务，不同业务之间如何做隔离、如何减少互相干扰、如何做高可用变得格外重要，因此需要支持多负载隔离。同时，离线数仓的典型技术为基于批处理技术，不擅长处理海量数据加工任务。因此大量场景下，需要离线数仓和实时数仓互相补充，通过离线作业对数据进行修正、补充和丰富，然后通过在线业务将它导入实时系统，也称为实时离线一体化。Transaction 系统往往追求 TPS 足够高，采用行存、支持事务，但数据量上亿之后分析效率急剧下降。因为其存储结构面向行更新，而数据分析场景面向列、可以做压缩和过滤。OLAP系统专门用于做数据分析，采用列存、压缩、索引、并行化等一系列技术优化大范围数据扫描场景下的统计分析。在线Serving系统主要为将大数据加工好的数据导出到 Redis、HBase等供在线业务系统访问。此类系统往往 QPS要求很高，对延迟敏感，不允许抖动，但是其查询相方式相对简单，不会支持很复杂的 SQL 表达式，希望用更简单的方式来查询以及更新。每个系统都有自己的设计场景，导致我不得不在系统之间做很多数据传递。而HTAP系统既可以做 transaction 又可以做 OLAP ，但这类系统的并发能力受限于 transaction 。另外，OLTP 系统产生的数据往往不符合分析师的需求，分析师需要看语义层，是对表的封装和抽象。那么，是否可以创新一个系统，既可以做 OLAP 又可以做 serving？ 此类系统对数据分析有更高要求，但对事务没有明显要求。如果放弃分布式事务，则可能将系统性能、可靠性都做得更好。Hologres是经典的 OLAP 系统，基于 MPP 架构，包含了数据分片、分段、索引技术等，其查询效率与用户对系统的熟悉程度直接相关，从毫秒级到秒级不等。它与其他 OLAP 系统的差别在于其更新能力更好。因此 Hologres设计之初即希望能够提供标准的使用方式，使用户像使用单机数据库一样使用大数据。Hologres之所以能实现很高的 QPS，主要得益于它的约束：查询场景要基于主键点查，存储要设计为行存。基于主键查询可以支持很高的 QPS ，比如 Flink 做数据加工时与维表做关联可以做到 10w+ QPS 。另外，Hologres既有行存又有列存，两种存储方式的结合能扩展出更多可能性。传统 OLAP 系统为列存，基于主键查询使用行存。非主键点查的需求下，数据库系统的常见解决方案为做二级索引。Hologres也可以实现类似的方案，做行列共存，将列存作为二级索引，先进行过滤，再根据列存过滤之后的rowID 找到该行数据。湖仓一体的趋势下，仓计算能力能否与湖上数据做关联？以Hologres为例，它和阿里的 maxCompute、DLF、 OSS都可以做很好的关联，可以将外部数据定义成外表，再用 Hologres SQL语句访问外表。另外，它能够实现百万级每秒的数据同步，离线数仓的数据不导出也可加速分析，意味着很多数据更新场景将变得更灵活。Hologres对外提供基于开源 postgres 的兼容协议，兼容各类主流BI工具。存算分离架构能够实现灵活的扩缩容，使成本更加可控。 上图左侧为此前的旧方案，需要七八个组件，因为不同系统的性能需要作出很多折中与牺牲。而右侧是新方案，实时加工部分基于 Flink ，离线加工部分基于 maxCompute，结果及对外提供服务部分收拢在 Hologres，整个数仓架构简化成加工层和服务层。二、Flink+Hologres核心能力实时数仓的第一个要求为高性能实时写入与更新。上图左侧为标准的数据库执行 SQL 语句，需要做分发、汇聚、排序、扫描算子等，计算流程过多，因此性能不佳。右侧黑框为Hologres里的 fixplan ，它将一条 SQL 执行计划省略了物理执行计划、逻辑执行计划、优化等，从写入到端直接写存储层，将性能做到极致。Fixplan的吞吐足够高， 128 core规格、10个并发、 20 列的列存表，如果表里没有主键，可以实现每秒钟 200 万的写入；如果表里带了主键，写入大概缩减 10%-20%；如果有主键又频繁更新，Hologres提供了insert or update 能力，如果记录里没有该条数据则插入，如果有则替换或更新。上图为Hologres 128core实例下，TPCH 100G（亿级别）标准数据集下的测试结果，有多表查询、子查询、开窗操作等，大部分查询响应时间为秒和毫秒级别。这意味着有机会为用户以尽量明细的数据方式提供交互式分析，提升开发效率。上图为点查性能。25000QPS/s的查询，延迟大多在5ms以内，可用于HBase和 Redis 场景下。读写分离通常的实现方式为一个master 带多个 slave ，而Hologres与其他系统稍有不同。它的架构下，所有节点共享一份数据存储，根据不同业务场景分配不同的计算资源，不同实例可以根据业务对 QPS 和稳定性的要求随时调整。另外，物理资源互相隔离，任何实例下线都不会影响其他业务。Hologres 当前的设计思路为一主最多带四重。Hologres的每一张表都可以像数据库一样吐出Binlog 给 Flink 加工程序，实现端到端的实时加工。可以随时通过 SQL 语句检查数据状态并更正，查错、排错、修正问题的成本大幅下降。数仓数据要结构化，但是随着业务发展埋点数据越多，行为数据也越多。如果将每个数据打平拉宽，会到来极高的开发成本。Hologres将 JSON 数据作为一级数据类型支持。 JSON 是一种很灵活的数据结构，可以随时加字段、加子节点，但是它在分析效率上存在瓶颈，必须将整个 JSON 完整体解析出来后才可以读取。Hologres能将JSON 数据列存化，将 JSON 中的每个子节点内部虚拟成某个列存储下来，用户依然将 JSON 看作body 使用，但实际存储上将每个子节点都作为某个列使用。列上可以做索引、压缩、过滤， 使IO 访问效率得到本质的提升。具体示例如上。原始数据应用层展现的 JSON 树形结构，内部存储时它会变为不同表，但是用户无法看到。使用时，如果只过滤某个字段，则相当只解析一列数据。此前，只能通过调度方式或加 Flink 程序的方式实现聚合操作。而Hologres原生提供了实时物化视图，相当于一张事件表。事件表实时写入时，基于事件表制定聚合规则和聚合视图，结果实时更新，直接查询物化表即可。即使查询明细表，也会根据查询特征自动重写到聚合表，将此前查明细数据的复杂度降低到查聚合数据的复杂度，是O(n) 到 O(1) 的过程。三、Flink +Hologres企业级实时数仓实践实时数仓的开发方法论可以分为三个阶段。第一阶段：探索期。探索期是面向特定业务的烟囱式开发，从采集、加工到服务，端到端地加工报表，上线速度很快。缺点在于每次上业务时，都需要重新拉数据、写加工、存结果表。而业务之间有大量内容可以共享，并不需要一再重复建设。且数据逻辑或数据质量有变化时，所有脚本都需要调整，运维成本和资源消耗越来越高。第二阶段：规范期。规范期的核心思路为减少数据重复建设，将很多可以被共享的指标沉淀到数仓。此阶段与探索期的区别在于，加工环节分层，不再采用端到端的加工方式；另一方面，在存储层引进数仓，通过数仓将可以共享的指标进行沉淀。该架构的缺点在于，并发与延迟无法支撑在线业务系统，同时需要将一份数据存储至HBase系统，数据状态也没有收拢。同步不及会造成各种口径不一，会引发更大的麻烦。第三阶段：优化期。该阶段的核心变化在于数据服务层的抽象，加工层通过 Flink 收拢，服务层通过Hologres收拢，让架构更加简单，减少口径不一致。Hologres与 Flink 实现了很多联合创新。Flink从读取数据 source 表到关联数据维度表，再到管理员数据 catalog 表到写数据sink 表，每个环节都要与周边各种存储交互。Hologres 在每个环节都做了原生支持，支持全表读取、Binlog读取实现批流一体、维度表支持百万级以上 QPS 、对结果表支持宽表更新。 Flink +Hologres会将数据链路分为加工层和服务层。加工层分为两个部分，分别是明细加工和汇聚加工。明细加工偏数据质量整理，汇聚加工偏业务属性整理。数据服务层也为分明细数据服务和汇聚数据服务。有些业务系统希望数据更细致、更巨灵活性，可以将数据存为明细表，直接对外提供服务；有些业务场景下明细数据太多太大，比如埋点数据、点击流数据，因此必须聚合为某一个 session 的统计数据才能被分析使用。将数据变为聚合方式主要有三种方法：第一，数据经过简单加工落盘对外提供服务方式，适用于数据量不大、对数据明细要求比较高的场景。第二，简单分析之后落盘，在数仓里做加工。加工脚本灵活，数据可以随时修正。第三，全部预加工，适用于端到端延迟很敏感的场景，比如风控、推荐等。该方式将尽量多的任务通过事件驱动方式高度汇聚变为小结果并提供服务。实时数仓场景1：即席查询假设上图左侧为消息中间件Kafka，右侧为数仓。数仓会被分层，比如会物化成表或视图。假设写入的为明细数据，通过视图封装了很多业务逻辑，该场景下原始数据有任何变更，分析端看到的都为最新数据。但缺点为计算量会变得非常大，因为没有提前做聚合，因此每次分析是明细数据。更适用于高价值数据的分析。实时数仓场景2：分钟级准实时数仓里引入了调度，分层依旧存在，但是通过调度可以将之前通过视图封装的逻辑封装为表。数据访问时， IO 效率得到很大改善，并发提高很多倍。该方式与离线数仓的开发方式几乎一样，只是增加了调度方式提高了效率。实时数仓场景3：增量数据实时统计如果更多业务逻辑是通过实时方式——Flink+Kafka 驱动的方式做加工。该方式时效性非常好，但依然存在改进点。如果重消息状态都在Kafka，对数据状态的修正检查不友好。因此，该场景下，数据向下一层传递时要落盘。这意味着数据有问题时，可以通过数仓检查某一层数据状态是否正确，且可以在数仓里进行修正。而如果没有数仓原始状态，一旦数据出错，则必须从原始数据重新拉，修正成本非常高。场景1之下，数据落盘直接使用，适合开发阶段。因为开发阶段无法明确使用什么口径、什么数据，因此通过视图方式对其进行定义数仓开发阶段的常见方式，也符合时效性要求。场景2为微批方式，通常来说，人类做决策绝大部分情况下不需要以秒为间隔，以小时为间隔的决策频率已经足够。场景3为完全的事件驱动方式，推荐风控等机器决策的场景使用。更多采用计算前置的方式，计算场景可累加。实时数仓不是一种技术，也不是一种产品，而是不同技术和产品的组合方式，需要根据不同业务场景来选择不同技术。
-
发表了文章 2022-12-13
「我是开发者」1024技术创作挑战赛获奖名单
写作达人奖晓风瑟瑟：《基于网关服务治理的研究与实践》（理论类文章） Jack20：《路由与交换系列》（实践类文章）冷环渊Doomwatcher：《JUC系列》（理论+实践类）踊跃先锋奖游客qyqtqgybni43aAra~追着风跑程序员马称游客esyfp7tzbv2v2代码迷途杋木huc_逆天摩诃般若胡临任1758656035458831肥晨CodeShero海绵宝宝_0113石云升周杰伦本人浅羽技术这里的黎明清欢君nanana~~技能实验室陈志林矜辰所致白月光永恒纠结这个LonelySnowman飞云觅宙游客6a32vx3nbp5uw代码bug生产队miaoikxmdreamermoving游客jg66u5ccnvps4昆吾kw六月的雨在钉钉芥末拌饭署前街的少年跃@sirAI浩后端从入门到精通赵鼎共饮一杯无知心宝贝梦无矶小仔陈橘又青1713425613104781凌云Cloud兴化再见孙悟空_三掌柜666walkingCoder穿过生命散发芬芳芒果再努力小周sir云中LolitaAnnCamilleKing我是坚果Star时光像风一样8游客bffwyrxnx7ryy游客dp5ryojmr5hjo兑奖方式：1、写作达人奖奖品Airpods将由阿里云开发者社区于15个工作日内进行邮寄2、踊跃先锋奖奖品定制T恤自行前往开发者社区积分商城一积分兑换区进行兑换
-
回答了问题
2022-12-13
乘风问答官12月排位赛开启！机械键盘、行李箱等你拿！
问答排位赛参与地址：回答12月的问题即为报名哦https://developer.aliyun.com/ask/latestQuestions/#/?_k=oet35q 如果你还不是乘风问答官，可以点击链接申请https://developer.aliyun.com/ask/469377
-
发表了文章 2022-12-09
参与即有奖｜前端领域主题征文开始啦！
征稿主题：本次征文以“前端”为主题，围绕开发者们在前端学习、开发中的思考与感悟。前端征文细分领域可参考：Web端、客户端、语言框架、前端运维、算法学习、模式设计、前端可视化等。征文方向包括但不限于：主流技术：结合自身业务场景的前端技术文章。如：HTML、JavaScript、CSS、jquery、ES6等。语言框架：分享关于前端领域语言框架的使用心得和实操技巧。如：React、Next.js、Vue、Angular、Svelte、Remix、PyScript、Artus.js 等。开发工具：介绍你在前端开发中的使用工具。如：IDE、GIT、Webpack、Snipaste、接口调试工具Apifox等。算法学习：分享关于前端领域的算法学习的感悟和经验。如：数据结构、排序问题、二分查找、动态规划等。创新体验：交流前端领域创新体验在日常工作生活中的应用。如：虚拟场景、3D技术、服务器端渲染等。技术趋势：探讨前端领域的技术演进趋势。如：Web3.0、AI与图形化在前端的探索、跨平台多端复用方案、低代码等。欢迎前往社区分享创作的价值！活动奖励：1、笔耕不辍奖——1名针对一个问题/技术点进行深度解析，产出5篇以上的体系化优质内容。符合征文要求并质量最优（有评论有点赞）的用户，获得米家智能空气炸锅*1。2、写作达人奖——88名参与发表文章>3篇且符合征文要求的前88位用户，获得写作达人礼品——小米双肩背包*1。3、博主新人奖——不限在活动期间成功发文3篇即可成为阿里云开发者社区技术博主，可获得虚拟徽章+乘风者手机支架。注：如用户已经是阿里云开发者社区博主，不参评此奖4、参与奖——不限在活动期间成功投稿1篇的用户，即可获得社区积分。所得积分可前往积分商城进行礼品兑换。投稿方式：1、直接进入社区官网：https://developer.aliyun.com/ ，登录之后，点击“发文章”按钮即可进行创作。如您还不是阿里云用户，会提醒您先注册成为阿里云用户，并完成实名认证。点击进行注册；注：已完成过注册或实名认证的用户可直接跳过此步骤。2.写完文章后点击发布，审核通过后即可在我的创作查看文章详情。3.填写投稿报名表单，表单链接：https://survey.aliyun.com/apps/zhiliao/jlKL9nGhX，审核成功后，即视为参与成功。活动规则：1、活动面向社区所有开发者进行征文，在阿里开发者社区成功发文1篇即视为参与征文活动。2、参与本活动的文章发布且通过审核时间需在2022年12月1日-12月31日之间。3、文章需为用户自发文，且符合社区审核规范。社区鼓励技术干货类内容，文章字数（不含代码串）500字及以上，且格式整齐规范，尽量图文并茂。4、活动中的“天”“工作日等均值改日的0点至24点（北京时间）5、阿里云可以根据活动的实际情况对活动规则进行变动调整，相关变动或调整将公布在活动页面上。并于公布时间即时生效；但不影响用户在活动规则调整前已经获得的权益。6、标题党、黑稿、通稿、包含违法违规、未被许可的商业推广、外站链接、非原创内容，有洗稿、营销软文、抄袭嫌疑的文章审核将不予通过，同时取消活动资格。7、每人只能获得一个奖品，同时满足多个奖项，发放最高奖项奖品8、本次征文活动投稿截止时间为2022年12月31日，开奖名单将于活动结束后7日内公布，奖品将于活动结束14日前寄出，如遇节假日则顺延。
-
发表了文章 2022-12-09
2022云栖精选—打造世界级云原生数据库开源社区
一、数据库业界发展趋势：全面拥抱云原生数据库是非常经典的技术。早在上个世纪 70 年代，其基础理论已经相对成熟，80年代开始了商业化进程。此后每隔十年均有代表性产品出现，但是云计算的出现加速了数据库技术的发展。从能力上来看，数据库从承载在线业务逐步向一站式数据处理平台演进，从结构化数据模型逐步向非结构化、半结构化的全数据模型处理能力演进。云计算也推着数据库架构向着云原生演进，使得数据库系统在面对不同工作负载时能够降低数据移动，提升数据库的处理效率。同时，实现了资源池化与资源解耦，使得每个数据库都能满足高并发、高扩展与高性能方面的需求。数据库系统的分布式架构阶段有两个演进方向。其一，共享存储架构。该架构下，计算节点没有状态，扩展能力极强。同时，使用体验与单体数据库非常接近，对用户非常友好。但问题在于存储与网络存在上限，扩展存在理论瓶颈。其二，分布式架构。每个节点自带计算与分析资源，扩展能力在理论上没有上限。但局限性在于节点增加与删除均会引起数据重分布，扩展效率较低。同时，系统执行效率受限于数据分布规则与业务使用场景之间的适配程度，因此，使用门槛较高。而云原生时代，以上两种架构实现了相互融合。在资源结合的基础上，计算、内存、存储等各种资源扩展都不再是瓶颈。数据库的处理能力也在不断增长，融入了各式各样分布式处理模式，包括 BSP、MPP 等，这也决定了云原生数据库的应用范围会越来越广泛。因此，在开源社区的建设过程中，我们需要坚定地坚持开源技术方向，要始终坚持以云原生为指导。二、阿里云数据库整体开源策略开源的第一原则为兼容生态。数据库作为基础软件，下连基础设施，上连应用，无法脱离生态而存在。MySQL和PostgreSQL是当前数据库的两大生态，因此，我们的开源PolarDB 也会坚定地拥抱这两大生态。开源的第二原则为遵循全面的开源模式。数据库作为一个重要软件，其稳定性和可靠性是用户最关心的因素。而我们将云产品直接开源，在于希望为用户提供一款具备企业级特性、成熟稳重的产品。另外我们也希望将阿里多年在数据库上的积累回馈给社区，让越来越多用户与开发者参与到云原生数据库的共建中。三、PolarDB云原生开源产品系列PolarDB-X兼容了MySQL生态，PolarDB for PostgreSQL兼容了PG 生态。PolarDB-X由四个部分组成。上面部分是元数据服务，负责元数据维护，提供全局授时服务等。下面部分分别为存储节点集群、计算节点集群以及全局日志节点。计算与存储完全分离，计算集群无状态，同时，计算集群主要承担SQL执行、分析事务等工作。存储节点集群的主要特点是通过 Paxos保证数据的强一致性，特别适用于对数据强一制性、安全性有要求的场景。日志集群最主要的特点在于与MySQL的Binlog 100%兼容，能够方便地接入现有的MySQL数据链路，平顺地为下游系统提供业务数据。PolarDB for PG是基于共享存储的架构，采用一写多读的模式。PG是一款非常优秀的数据库，拥有极强的SQL处理能力，因此被很多传统企业所选择。但互联网时代下，传统企业需要进行业务创新，因此也希望PG能够拥有应对互联网行业特性的能力，比如有足够的弹性应对洪峰流量。而PolarDB for PG很好地满足了该类需求。PolarDB for PG与PG实现了100% 兼容， PG 拥有的插件化能力，PolarDB for PG一样可以实现。可以通过PG插件支持高级能力，比如分布式能力、时序时空能力等。PolarDB-X与PolarDB for PG两款产品均原生接入K8S系统，这也意味着只要用户与开发者的基础生产环境里有K8S系统，即可很方便地通过K8S部署、管理、调度、运维开源PolarDB。同时，用户也可以基于K8S根据自己的需求开发平台。一年来，PolarDB发布了诸多企业级特性，包括查询的增强、安全加密、归档、容灾、审批等。未来，我们也会持续将云上产品的企业级特性不断增强，同时会坚定地坚持国产化和生态兼容。四、开源数据库社区运营及生态建设我们希望打造一个技术社区。因此社区的决策机构是技术委员会。在技术委员会的带领下，我们希望通过建立用户组的方式不断扩展PolarDB在垂直技术领域的深度应用。目前，社区已经成立了11个 SIG ，包括自然语言处理、异构硬件适配、查询加速等。我们希望通过SIG推动开源PolarDB与场景结合更加紧密，让越来越多人能够平顺地使用开源PolarDB。同时，社区会面向开发者与用户定制深度技术内容，帮助业务与开发者更好地了解PolarDB。我们会定期邀请PolarDB用户，为大家分享使用PolarDB过程中遇到的问题以及最佳实践。此外，我们希望打造全栈的伙伴体系，与重点行业的客户共同成立云原生数据库适配中心，并基于适配中心打造行业专属的开源数据库。比如，我们与韵达成立了数据中心，已经落地了数据中台的核心业务模块订单打单系统。后续，希望有越来越多的优秀企业与阿里云合作，共同打造行业专属的开源数据库。同时，我们也会通过社区帮助合作伙伴培养所需要的数据库人才。一年以来，我们已经打造了10+基础课程，学习人次超150万。上图展现了我们理想中未来PolarDB开源生态的全景，包括东南西北四个方向。其中，南向主要适配芯片、操作系统等；北向会与经典应用集成，对行业运营提供支撑；西向主要与伙伴、用户一起打造完善的人才培养体系；东向会与更多具有PaaS属性的软件实现适配，比如数据流入流出工具、数据管理工具、数据安全以及各种中间件。PolarDB用户已经非常多，涉及千行百业，对高性能、高扩展、复杂分析等极限类应用场景提供了非常好的支持。未来，希望有越来越多用户与开发者加入我们，贡献代码，贡献技术力量，一起打造属于中国人的、有世界级影响力的云原生开源数据库社区。
-
提交了问题
2022-12-08
云产品使用问题征集活动开启啦！提问题，赢社区周边等精美好礼！（获奖名单见文章末尾）
-
提交了问题
2022-12-08
社区问答2.0全新上线改版！有疑问找解答！
-
发表了文章 2022-12-08
云产品使用问题征集活动开启啦！提问题，赢社区周边等精美好礼！
社区问答全新升级，你可以直接向云产品提问啦！无论你是初次使用阿里云产品的新手用户还是非常熟悉产品的铁杆用户，在使用时是否遇到过无法解决的技术问题？现在，社区向你征集使用云产品过程中遇到的真实问题。在这里，你的提问不仅能通过社区进行广泛交流，还能收获云产品官方专业解答。在这里，你的每一次提问不仅能帮助更多的用户解决问题，还能帮助社区共筑友好交流氛围、共建云产品优化迭代。作为鼓励，社区还准备了按摩器、剃须刀等精美礼品。快来同我看看活动规则吧！一、活动规则本期活动面向云产品使用征集提问，你可以向以下云产品领域提问，包括但不限于：云服务器MySQL版、对象存储 OSS、容器服务Kubernetes版、云解析DNS、短信服务、CDN等40个产品，提问需要关联领域具体的云产品，关联方式如下：App端： 方式一：直接点击页面下方的“向云产品提问”按钮进行提问，输入你的问题标题和描述，并然后点击关联相应的并选择阿里云产品，如果你的标题中带有云产品关键字，将会自动触发云产品的关联，内容输入完毕后最后点击发布问题。PS：如有其他情况需要退出编辑，可选择保存草稿。 方式二：在云产品问答专区里提问，同样需要输入你的问题标题和描述，与方式1有所不同的是系统会自动关联阿里云产品，无需手动勾选。PC端： PC端提问页面同样进行了升级，可以选择关联相应的云产品。如您的问题不在40个云产品的范围内，仍可继续提问，但不计入本次活动。2.本次活动鼓励优质提问，云产品提问需为使用过程中遇到的真实问题，请尽可能详细地描述问题，以便回答用户更好地给出建议，可参考第二部分提问指南；所提问题需为原创，主题释意明确，且为本次活动开启后的新增提问。3.本次活动以问题质量第一、条数其次的原则进行审核，回答不易请认真提问。4.活动时间：2022.12.8—2022.12.305.参与对象：社区所有用户均可参与6.报名方式：活动时间内在社区提问，有效绑定问题所属云产品即算参与活动二、提问指南亲，为了让你的提问更快更有效地得到解答，不妨来参考下面的提问指南。请在提问之前仔细阅读。1、本次活动面向40款阿里云产品使用所遇问题，所以请确保提问与云产品使用相关。40款云产品的名单请见文末说明。2、提问标题需简洁具体，直入主题释意明确，请尽可能详细描述所遇情况。并绑定问 题所属领域标签，增加曝光几率。如需代码表述问题，请提供完整且可验证的代码，以 便获得针对性解答。如：【RDS】ECS通过内网连接RDS时提示“ip not in whitelist”，该怎么处理？3、如有疑问需要讨论，欢迎在评论区与开发者交流，除了提问外也欢迎你解答问题，提升自己的同时你还可以申请乘风问答官获取机械键盘等专属权益。三、评奖规则奖项奖品获奖条件 提问达人奖 1个 SKG颈椎按摩器*1 向指定云产品提问并完成关联，活动期间内所有提问获得有效回答数量第1名，并且活动期间有效提问数量≥10条最会提问奖3个松下剃须刀 *1 根据提问质量以及回答情况，活动主办发综合评定3条有心提问。 （优质质量维度参考：所遇问题环境、代码等相关信息描述清晰，有问题反馈截图等）热点追踪员 1个GERM 保温杯*1 向指定云产品提问并完成关联，活动期间内所有提问累计浏览量第1名，活动期间有效提问数量≥10条阳光普照奖社区50积分 向指定云产品提问并完成关联，活动期间有效提问数量≥5条四、注意事项每人只能获得一个奖品，同时满足多个奖项，发放最高奖项奖品。提问需为中文，英文不记录数据（代码除外）；提问发布后将进入审核状态，审核完成即可查看。标题党、黑稿、通稿、包含违法违规、未被许可的商业推广、外站链接、非原创内容、营销软文、抄袭嫌疑的文章审核将不予通过，同时取消参与活动资格。灌水、刷浏览量、问答量等行为将被取消活动参与资格，问题下无关回答将不计入有效回答数，包括但不限于同人账号在同一问题下多次回答等行为。获奖名单及奖品邮寄时间：奖名单将于活动结束后7个工作日内公布，奖品将于12个工作日内进行发放，节假日顺延。附：本次活动涉及的40款云产品清单： 云服务器 ECS,云数据库 MySQL 版,对象存储,容器服务Kubernetes版,负载均衡,云解析DNS,短信服务,CDN,云虚拟主机,实时计算 Flink版,云数据库 Redis 版,云原生关系型数据库 PolarDB,云原生大数据计算服务 MaxCompute,大数据开发治理平台 DataWorks,消息队列 MQ,无影云桌面,日志服务,Web应用防火墙,云安全中心（态势感知）,数字证书管理服务（原SSL证书）,数据传输,宜搭,专有网络VPC,云企业网,DDoS防护,云防火墙,云原生数据仓库AnalyticDB MySQL版,机器学习,物联网平台,视频点播,视频直播,音视频通信,云原生多模数据库Lindorm,全球加速,Serverless 应用引擎,函数计算,检索分析服务 Elasticsearch版,云监控,ocr,消息队列Kafka版
-
提交了问题
2022-12-08
横空出世的ChatGPT，究竟有什么魔力？
-
提交了问题
2022-12-08
D2终端大会你最看好哪个热点技术？
-
发表了文章 2022-12-07
使用魔搭开发自己的语音AI：从入门到精通
作者 | 袁斌、鄢志杰 阿里达摩院语音实验室来源 | 阿里开发者公众号语音AI是最早从实验室走向应用的AI技术，其发展史就是不断创新、解锁应用的历史，从1995年 Dragon Dictate的桌面孤立词语音识别，到2011年苹果的手机语音助手SIRI，再到当下百花齐放的各种智能语音应用。由于技术的快速进步，以及各大云计算厂商以API形式提供的语音AI能力，目前开发者已能便捷使用语音AI去搭建应用。但API也存在局限性，不少开发者希望获得更多、更底层的把控力，希望对API背后AI模型有更深入的了解；不只是开发应用，还可以开发模型；不只是调用API接口，还可以通过对模型的训练或微调（fine-tuning），以提升实际应用效果。为了让所有满怀创意的开发者实现更高水平的创新，在最近推出的魔搭社区ModelScope上，阿里达摩院首批开源开放了40多个语音AI模型，公有云上广受欢迎的付费模型这次也免费开放。模型背后，我们提供了训练或微调脚本工具链，含盖语音AI各个主要方向。下面，就让我们以语音合成、语音识别、语音信号处理为例，来展示如何玩转魔搭社区的语音AI模型。一、语音合成语音合成是将文字作为输入，让AI能够将文字转换为语音的原子能力。例如，我们希望AI朗读如下的一段文字：“最当初，他只是觉得赛伦看莫颖儿的眼光温柔得超过一般父女或是师徒的感情，在观察了一段时间过后，他才逐渐确定赛伦似乎很在乎这个少女。”在魔搭社区，可以有两种方式来进行语音合成模型的体验：第一种方式是使用模型详情页的“在线体验”功能，以最直观的方式对每个语音合成模型进行体验。这对模型的初步体验和把玩品鉴非常高效。接下来以“SambertHifigan语音合成-中文-多人预训练-16k”模型为例，介绍如何进行在线体验。模型链接查看文末[1]。第二种方式是使用编程，通过简单的几行代码，就可以实现自己的语音合成功能，并集成嵌入到具体的应用中去。这种方式适合选定喜欢的发音人后、进行深度的应用开发。魔搭社区提供了免费的CPU算力（不限额）和GPU算力（NVIDIA-V100-16G 限额100小时），供开发者进行使用，下面我们使用Notebook开发环境来简单演示如何实现使用代码进行语音合成。让我们选择CPU服务，稍等几分钟服务启动，我们点击“查看NoteBook”，进入开发环境，选择启动一个python脚本。这些语音AI模型都配备了代码示例，我们可以在模型详情页的代码示例中找到：将该代码进行复制并粘贴至notebook的python脚本当中，我们可以将代码中‘待合成文本’字符串替换成想要的合成本文，并执行程序，便可以下载生成的音频文件进行试听。这项语音合成技术背后是达摩院的显式韵律声学模型SAMBERT以及Hifi-GAN声码器的结合。在语音合成领域，目前以FastSpeech2类似的Non-Parallel模型为主流，它针对基频（pitch）、能量（energy）和时长（duration）三种韵律表征分别建模。但是，该类模型普遍存在一些效果和性能上的问题：独立建模时长、基频、能量，忽视了其内在联系；完全非自回归的网络结构，无法满足工业级实时合成需求；帧级别基频和能量预测不稳定...因此达摩院设计了SAMBERT，一种基于Non-Parallel结构的改良版TTS模型，它具有以下优点：建立时长与基频、能量的依赖关系，并使用自回归结构的时长预测模块，提升预测韵律的自然度和多样性;Decoder使用PNCA自回归结构，降低带宽要求，支持CPU实时合成;音素级别建模基频、能量，提高容错率;以预训练BERT语言模型为编码器，在小规模数据上效果更好。二、语音识别在魔搭社区上，达摩院语音实验室开放了核心的语音识别模型“Paraformer语音识别-中文-通用-16k-离线”，这是即将大规模商业部署的下一代模型，其训练数据规模达到5万小时以上，通过对非自回归语音识别模型技术的改进，不仅达到当前类Transformer自回归模型的语音识别准确率，而且在推理效率上有10倍的加速比提升。模型链接参考文末[2]。在魔搭社区中，语音识别模型与语音合成一样，提供Demo和Notebook两种方式进行效果体验，操作方法请参见上文，不再赘述。除了开放最先进的Paraformer模型之外，语音实验室还免费开放了当红的语音识别模型UniASR，它在公有云上提供商业化的服务，广受欢迎。UniASR模型含盖了中、英、日、俄等语种，支持8k/16k采样率，可以满足开发者不同场景的开发需求。模型链接参考文末[3]。三、语音信号处理信号处理也是语音处理的一个重要的技术组成分支，达摩院开源了基于深度学习的回声残余抑制算法。模型名：DFSMN回声消除-单麦单参考-16k模型链接参考文末[4]。从用户体验角度，一个理想的回声消除算法要达到以下效果：远端单讲(far end single talk)时零回声泄露；近端单讲(near end single talk)时语音无损；双端同时讲话时可以互相听清，也即双讲(double talk)通透。目前在开源的信号处理算法当中，双讲时的效果都比较差强人意。这是因为目前的开源信号处理算法无法有效区分录音信号中的回声信号和近端语音信号，而且真实通话中双讲出现的时间一般较短、时间占比也很低，所以从策略上为了确保零回声泄露，只好牺牲双讲时的效果。达摩院这个模型能够进一步提升双讲通话效果，满足用户对语音通信时的音质要求，已在阿里内部音视频项目上完成了工业化部署。大家如果现在使用钉钉视频会议，会发现了多一个较为方便的对讲功能。这次模型开源，希望能对从事webRTC的研究者与开发者有所帮助，欢迎大家基于这个模型进行应用开发，在NoteBook中只需要5行代码就可以得到回声消除结果。该模型的技术创新点在于借鉴了智能降噪的解决思路：数据模拟->模型优化->模型推理。具体而言，我们结合回声残余抑制的任务特点，在输入特征上，拼接了线性滤波器的输出信号和时延对齐的回采信号，并提取FBank进行均值方差归一化。在输出目标上，选择了相位感知的掩蔽值(Phase-Sensitive Mask, PSM)。在模型推理阶段，对PSM与线性输出的信号频谱逐点相乘后再进行IFFT (inverse Fast Fourier Transform)获得近端语音。四、写在最后在过去的语音 AI 探索当中，达摩院完整实现了从研到发，从模型创新到提供API的全链条。但是随着近年来语音AI的飞速发展，开发者角色变得多元化、各方面需求也变得越来越丰富，传统的“包打天下”的模式已不再合适。面向未来，我们希望通过魔搭这样的开放、开源的社区来推进语音AI的研究和应用，促进语音AI生态的活跃和繁荣。魔搭社区官网：https://modelscope.cn/home参考链接：[1]https://modelscope.cn/models/speech_tts/speech_sambert-hifigan_tts_zh-cn_multisp_pretrain_16k/summary[2]https://modelscope.cn/models/damo/speech_paraformer_asr_nat-zh-cn-16k-common-vocab8358-tensorflow1/summary[3]https://modelscope.cn/models/damo/speech_UniASR-large_asr_2pass-zh-cn-16k-common-vocab8358-tensorflow1-offline/summary[4]https://modelscope.cn/models/damo/speech_dfsmn_aec_psm_16k/summary
-
发表了文章 2022-12-07
云栖精选第一弹：最全2022云栖大会内容大放送！为精彩技术打call！
云栖大会（Apsara Conference）以引领计算技术创新为宗旨，承载着计算技术的新思想、新实践、新突破。历经14载，见证了中国计算产业的萌发与革新。今年云栖大会共举办60+数字技术、产业与生态峰会/论坛，上千位院士、科学家、学者、行业领军者汇聚一堂，带来一场场科技与计算的碰撞之旅~一睹过现场峰会的卓越风采，想必大家对其精彩内容更想深入研读吧！阿里云开发者社区特为大家整理了各专场的精彩内容合集电子书，带领大家再次“云”回峰会现场，探讨数字产品，感受顶尖科技趋势~本期我们将走进边缘云计算创新论坛、倚天专场、图计算及其应用专场、云上新型电力系统峰会，快来一睹为快吧！一、《云上新势力 CLOUD IMAGINE》>>免费下载<<视频化时代，未来80%的数据和计算将发生在边缘，边缘云靠近终端与数据源头，推动端侧算力赋能，助力万物业态革新。 本电子书精选了云栖大会"边缘云与视频云"的系列内容，从战略与产业发展、技术与创新应用、场景实践与生态合作等维度，全方位演绎边缘云与视频云创新融合的极致进化。 通过本书，你可以浏览到云栖大会演讲合集和云栖大会精选文章，更有《边缘云技术演进与发展白皮书》内容透出，全面梳理边缘云技术发展演进路线！二、《倚天开启云原生算力新时代》>>免费下载<<2021年云栖大会上，阿里云发布自研的基于Arm v9架构的倚天710芯片，这是一款云原生处理器，无超线程概念，用户可以享受物理核的极致性能体验。随后，阿里云推出了采用倚天710芯片的倚天云服务器，在阿里巴巴集团内部及外部客户的试用效果都非常好。本书内容整理自云栖大会"倚天专场"，全方位展示倚天云服务器在云原生时代的性能表现。6位技术大咖精彩演讲，全方位展示倚天云服务器在云原生时代的性能表现。倚天“利剑出鞘”，破晓来袭，关于“倚天 ECS 云服务器”更多内容，都在《倚天开启云原生算力新时代》！ 三、《图计算及其应用》>>免费下载<<近年来，基于图数据的计算（图计算）得到了学术界和工业界越来越多的关注，被认为是人工智能发展的一个重要方向。本书内容整理自云栖大会"图计算及其应用"，围绕图计算系统、应用及前沿学术研究问题，介绍阿里巴巴开源的一站式图计算系统 GraphScope的设计思想、基础能力以及未来发展方向；还有学术界和工业界的大咖最前沿的学术和技术热点分享；更有业务中应用图计算技术的客户实操分享，分享图计算在真实业务场景中的应用案例及效果。四、《云上新型电力系统—“电”亮数智生活》>>免费下载<<近年来，以国家电网、南方电网、国家电投为代表的电力央企纷纷建设了自己的云平台。新时期，电力行业数字化转型，将从“选云上云”全面迈向“云上创新”，构建新型电力系统是党中央的重大决策部署，因此，构建绿色、安全、高效的“云上新型电力系统”恰逢其时。本书内容整理自云栖大会“云上新型电力系统峰会” ,由阿里云与中国电力发展促进会联合举办，聚焦云上新型电力系统建设，围绕发电、电网和用电等环节，分享前沿洞察、数智创新实践案例，为推动构建新型电力系统贡献力量。五、“达摩院在企业人工智能中的探索”ppt合集魔搭社区产品生态介绍魔搭・平台工程框架介绍大模型驱动的自然语言开放生态ModelScope助力语音AI模型创新与应用达摩院通义视觉生成大模型视觉AI能力的开放现状及ModelScope实战通用多模态AI构建”达摩院在企业人工智能中的探索“论坛主要介绍阿里巴巴达摩院在下一代企业AI技术上的研究和探索，借助先进的视觉AI、语音AI、语义AI等多模态能力，通过集成数据和自动化流程，全方面赋能企业员工，提高工作效率和质量。同时，邀请深度合作伙伴，结合业内最新动态、理论发展以及在工程界的最佳实践案例，一起共创更普惠的AI应用技术。论坛实录电子书正在制作中，讲师内容搭配PPT效果更佳哦，敬请期待~更多精彩内容持续发布，社区藏经阁也将持续上新云栖内容集锦电子书，欢迎关注！我们下一期见！
-
提交了问题
2022-12-06
拥有数字藏品是种怎样的体验？
-
提交了问题
2022-12-05
【藏经阁一起读（40）】读《Java应用提速（速度与激情）》，你有哪些心得？
-
发表了文章 2022-12-02
2022云栖精选—云数据库RDS重磅功能发布与最佳实践
一、整体介绍阿里云RDS伴随着阿里云的成长而成长，经历了不同的发展阶段，从最初的脚本化运营方式发展到平台化、商业化。在产品能力上逐步支持了 OpenAPI 、PostgreSQL、SQLServer等多种引擎。阿里云RDS在过去几年中经历了智能化演进，比如通过DAS的机器学习能力支撑智能决策，通过性能参数调优、MySQL治理等来提升引擎产品的能力。2021年，阿里云RDS进行了架构升级，全向云原生演进，充分将阿里云底层的IaaS资源服务能力通过PaaS服务的进行透传。并在此基础上进行了创新，包括Serverless、ECS等。阿里云RDS从过去基于物理机隔离的架构逐步朝着All On Ecs的方向演进，将PaaS的产品能力构建在IaaS资源服务能力上，再基于 ECS 以及ESSD实现存算分离架构进行资源解耦，为产品能力带来了极大的提升，比如可基于快照秒级恢复以及计算和存储独立扩容和缩容的能力。在计算存储分离架构的基础之上，构建了基于K8s的集群调度系统，将引擎产品容器化部署到ECS服务器上。在分层管控架构之上，我们构建了自己的Serverless产品能力。使用统一的管控架构支撑了四款不同产品，包括 MySQL、PostgreSQL、MariaDB以及SQL Server。除了硬核技术以外，我们也通过多种产品能力帮助开发人员提高开发效率。二、产品趋势及技术解读数据库在传统的RDS阶段，计算节点和存储容量都需要预设，比如通过运维人员根据业务需求进行手动配置，计算规格有限，严重限制了业务开发人员的开发效率以及 DBA 的运维效率。云原生 RDS 能够利用DAS产品进行智能化调度，智能化预测产品或用户业务需要多少资源量，可以自动进行伸缩。而RDS Serverless1.0和2.0阶段希望客户无需关心资源，计算规格和存储容量都能够随着业务量的发展进行扩缩容。传统 RDS 架构下，运维人员需要根据业务的波峰波谷进行手动扩缩容，难以精准预计，极易出现资源浪费或资源储备不够的情况。同时，传统 RDS 架构下，资源伸缩的范围有限，无法完全满足业务需求。而在Serverless架构下，计算规格和存储容量能够随着业务波峰和波谷进行弹升弹降，极大提升了运维人员的工作效率。同时，可以对资源进行更精细化、更准确的配置，节约了大量成本。RDS Servereless产品为业务带来了以下核心竞争优势：第一，资源配置可随着业务负载实现秒级弹性伸缩。第二，按需使用，按量计费。第三，构建在内核功能的创新之上，实现了内核BP Online Resize优化，弹得更稳。第四，支持 RESTful API 访问机制。只需一个endpoint即可通过RestAPI 、HTTP 协议进行访问和操作，配置数据库资源。我们实现了RDS On倚天ECS，包括底层 CPU 架构、ECS 机器，到上层数据库的全栈资源，并实现了软硬协同优化，使得RDS On倚天ECS的性能、稳定性等各个方技术指标看齐并超越最新一代的X86机型。平均性能提升10%，性价比提升25%，并实现了0成本的应用适配。从过去的RDS迁移到ECS架构后，存在大量稳定性问题，需要持续不断地创新、深度优化才能使新架构的产品竞争力看齐过去物理机形态的能力。我们对Binlog体系进行了改造，实现了Binlog In Redo模式，将原先事务提交commit的两次IO操作降为一次，大幅提升写操作的吞吐。同时，对Binlog的写模式也进行了深入调整。RTO 是众多数据库使用者最关心的核心指标。 RDS产品过去在RTO上做了大量优化。比如大事务Recovery优化，从过去的需要小时级降至秒级；同时，对Buffer Pool进行了并行初始化优化，提升了RTO指标，对Reo的核心组件进行了深度优化，提升了产品能力。三、产品功能发布我们一直在思考，能否有这样一种产品形态，既能够兼顾实例的整体可用性，同时又能够最大范围实现降本增效。因此，阿里云推出了RDS MySQL的新形态——RDS MySQL集群版。集群版相比于之前的高可能架构存在两点颇为明显的变化。第一，集群版支持同时挂载多个从节点，这意味着会有多个备库，同时所有备库将开放给业务访问，以实现资源的最大化利用，降低成本。第二，集群版不仅提供了最高4个9的全球最高等级SLA服务保障，同时还通过内置的MySQL主复制技术结合内置的Paxos分布式协议算法，确保数据多点性，确保数据永不丢失。以最小成本实现数据库服务的可用性以及数据可靠性最高级别的保障，是 RDS MySQL集群版的最大竞争力。RDS通过一系列产品功能的矩阵，实现了整体业务的降本增效。在计算节点上，支持了基础版的只读实例，针对有明显使用时间的业务，在业务停用之后可以同步暂停RDS实例，实例暂停期间不收取任何计算节点费用，需要时又可以快速将它拉起用于生产业务。存储节点部分也进行了核心优化。依赖云盘能力，支持了从PL0到PL3全等级的云盘矩阵，同时可以根据线上业务的吞吐需求，在PL0到PL3之间随时进行无损的在线变化。存储流量层，通过数据库内部的核心技术实现了云盘缩容能力，可以根据业务数据量的变化实现云盘存储空间分配以及降本。不论是计算节点实例暂停还是存储节点的可升可降，我们始终希望业务的不同阶段都可以在RDS上获得最优的资源成本与解决方案。 RDS与数据库备份产品DBS深度集成之后推出了新特性：急速备份及恢复能力。数据库物理的备份中，往往会涉及到跨存储介质的数据传输以及恢复，耗时耗力。而通过RDS极速备份及恢复能力，可以实现对全量及增量的物理备份和文件实时自动合成快照备份。进行数据恢复时，可以通过快照秒级挂载实现数据的快速恢复，大幅度缩短数据恢复时长。此前恢复1T数据大约需要4小时，而现在仅需30分钟，数据效率恢复提升达88%。同时，也支持了针对单库单表级别的恢复能力，该能力可大范围应用在诸如游戏等多租户，需要单库单表回档的场景，让线上业务以最快速度回档到正确状态。RDS的可观测性体验也得到了增强。首先提升了更多资源监控指标，客户可以针对RDS实例进行更全面的掌控。其次支持了全局视角的自定义监控大盘，可以根据多实例、多时间点、多监控进行数据的聚集、展示以及对比分析。针对最为常用的指标比如资源、空间、链接、慢SQL 等，支持定期的常态化自动巡检，会定期给出报告，发布告警，用户可对全局运行状态实现全面掌控。PostgreSQL被誉为全球最先进的开源数据库，而RDS PostgreSQL通过插件的能力扩展了其使用场景。我们发布了Ganos时空引擎插件，可应用在高新地图、路径规划等场景；发布了全加密数据库插件，可以实现从内存到磁盘全链路最高等级的加密；发布了PASE高维项目插件，可应用于图像识别、 AI 机器人等场景；发布了Babelfish插件，可以实现对SQL Server数据库的兼容以及对商业数据库的替换。以上插件能力的加持使得RDS在AI、时空、加密等场景上具备了更好地为业务提供服务的基础能力。四、最佳实践从线上真实数据可以看到，Serverless已经广泛应用于资源波动、具备不确定性负载的场景中，比如运维及开发环境、IDC到云上容灾环境、音视频不定时转码、多人在线协同办公系统等。以上场景均具备一个共同特征：业务间断不连续，但在业务高峰期对数据库性能有着极高要求。 RDS Serverless通过秒极弹升、按需付费的能力，可以很好地满足此类场景的需求。在业务低峰期，可以保持在较低水位线运行，而在业务高峰到来时，又可以快速弹升以应对业务流量。大幅降低了资源成本，最高降本70%，真正实现了增效并且降本。Babelfish具备了SQL Server商业引擎语法的兼容能力。在RDS上启用Babelfish插件之后，即可通过SQL Server语法以及 PG 语法同时对数据库进行访问，以开源数据库引擎的能力以及成本实现商户数据库引擎的能力，进而将商业数据SQL Server替换，使得数据库采购成本下降 60%-70% 。RDS砥砺前行，经历了十年发展之后，无论是从最底层的软硬协同一体化，还是数据库最核心的内核优化，亦或是最上层集群MySQL形态的推出，始终致力于让每一个客户获得更快、更稳、更安全、更好用的数据库使用体验。
-
发表了文章 2022-12-01
2022云栖内容精选—AI助力新型电力系统建设
一、“双碳”目标下的新型电力系统与挑战 如上图所示，根据清华大学气候变化与可持续发展研究院的研究报告显示，预计2025年中国发电量构成，将以新能源为主导。 为了解决负荷与新能源功率预测技术难点，阿里云主要采取了三种有效措施。第一，引进先进新颖的大规模深度学习技术；第二，针对高温/寒潮/覆冰等极端天气的负荷预测与功率预测算法；第三，模型自学习自更新技术；第四，预测可信可解释性技术； 由于电网的预测结果会应用在很多下游任务，所以结果的准确性、可理解性、可信任度非常重要。 预测可解释性分析和复盘功能，能够帮助业务人员预测上报和复盘分析。精准的预测结果，可以提升预测人员自身的业务水平。目前，AI预测场景主要依赖可解释性技术，主要对未来预测和复盘归因进行解释。 在未来预测方面，通过解释历史，参照日负荷功率、功率与未来负荷、以及功率之间的差异，为工作人员提供可靠的预测。 在复盘归因方面，AI系统主要通过解释过去预测负荷、功率值与过去实际负荷、以及功率值之间的差异，为工作人员提供可靠的归因解释。 以山东省电网公司负荷预测项目为例，分布式光伏装机量大且增长快，分布式光伏直接并网，给母线负荷预测工作带来巨大挑战，日常人工预测效率低，给电网安全带来挑战。通过AI预测技术，该市母线预测平均准确率达到98%。在高温负荷期间，准确率达到97.7%。预测结果的可解释性分析，通过联同Al预测，减少了预测人员上报工作耗时，从1个多小时缩减到几分钟。除此之外，系统可以每日根据最新数据能够自动建模学习分析并部署，始终保持较高准确率。 另外，某新能源发电企业面临集中式光伏场站预测准确率低，场站被电网考核成本居高不下的问题，间接影响电力调度和电网安全。集中式光伏功率预测准确率平均提升2.7%，考核电量降低53%，可有效提升场站经济效益；每日根据最新数据自动建模学习分析并部署，始终保持较高准确率； 二、电力优化与强化学习决策平台MindGrid概览 接下来，介绍一下电力优化与强化学习决策平台MindGrid。MindGrid基于阿里云弹性伸缩、分布式计算以及分布式训练能力，能够支撑每日五省电网近4000+节点、1000+机组的千万次训练，突破训练时间瓶颈。在框架方面，MindGrid提供强化学习与数学规划结合框架，具备秒级安全调度决策能力。在模拟仿真环境方面，MindGrid兼容各类潮流计算BPA、DSP，能够精准推演实际电网运行。在底层优化能力方面，阿里云为电力定制的线性规划以及混合整数规划技术，在世界领先。 在业务能力验证上，云上Al实时调度智能体将强化学习与数学规划技术融合具备秒级决策能力；在平台能力验证上，MindGrid支撑第四届Al调度大赛，支撑 22 支队伍共计 110 人在 2 周内完成智能体的开发、训练、在线部属，降低了强化学习在电力调度应用门槛。 上图展示了云上实时电力调度智能体，在电网规模达到4000+拓扑节点、1000+机组能够单次强化在线推理平均小于等于0.015、训练2-3个小时收敛。阿里云通过强化+优化结合的方案，调度能力平均小于等于0.1s，完全具备秒级调度决策能力。 2022的第四届电力调度AI应用大赛中，MindGrid以平台能力支撑22支队伍共计110人在2周内完成智能体的开发、训练、在线部属。通过强化学习与数学规划结合，解决了新型电力系统调度难题。 以上是MindGrid的4大特点，分别是高性能分布式计算、优化与强化结合框架、高精度模拟仿真环境、在线与离线开发环境、平台部署与训练能力。 用基于数学能力的决策智能，让虚拟电厂不仅成为试点，而是形成可复制的商业模式，为新型电力系统贡献实际价值。 达摩院虚拟电厂智慧运营解决方案，基于MindOpt优化求解器和建模平台，集合运筹优化与强化学习能力，利用先进算法搭建应对虚拟电厂运营核心问题的决策模型，为虚拟电厂提供集运营智能决策模型的设计、构建、运行、实验、求解于一体的智能决策中枢、作为整个虚拟电厂智慧运营的决策模型工厂，标准化模型生产底座、输入输出数据接口、定制化场景仿真模型、统一化模型运行指标、最优化模型求解能力。在云平台强化数据沉淀的基础之上，再赋予方案模型沉淀的能力，更大程度上提升方案的可复制性，可解释性。使得虚拟电厂可以获得更加长足的发展、产生更加深远的意义。 阿里达摩院以“云端数学”能力为邀，以期赋能具备“边端物理”建模，以及“前端应用”能力的伙伴共建虚拟电厂运营平台！ 达摩院的竞标决策技术和经济调度技术能够有效解决虚拟电厂的典型问题。在竞标决策技术方面，系统能够通过“时序+XAI”，形成可解释、自学习的不同周期负荷和功率预测能力；通过“仿真+AI”，能够实现考虑机理博弈与AI的分时价格，现货价格预测；通过优化强化结合方案，能够充分考虑市场的不确定性、考虑多种交易品种、多报价出清方式，实现虚拟电厂主体参与市场的竞价决策，以及考虑机会成本以及资源利益诉求的优化调度和内部协同决策。 在虚拟电厂调度国际竞赛中，达摩院凭借自研求解器MindOpt优化能力，成功破解虚拟电厂调度难题，将能源运营成本降低29%，风险降低39%，最终获得GECCO2022国际竞赛第一名。 达摩院虚拟电厂运营技术，促进了新能源电力交易。它不但能够低成本构建即刻执行的交易辅助决策应用。通过效果归因评测，相同预估特征数据对比基准方案，辅助决策模型稳定提升21%，辅助决策度电收入可达最优策略度电收入87%。 达摩院希望开放的能力包括可解释AI、时序预测能力、数学规划求解能力、强化学习能力、以及电网仿真推演能力。 在此之上，达摩院希望和合作伙伴一起构建，预测调度和交易能力，让每一度电更绿色。 上图展示了电力调度智能决策平台的基础架构，“新型调度Al认知服务平台”和“新型调度强化优化决策平台”，构成了电力调度智能决策平台，二者协同支撑电力调度生产数字化、智能化升级，实现电网稳定、绿色、高效的智慧化运行。 让每一度电更绿色是决策智能实验室的使命，围绕新型电力系统建设，决策智能在调度决策、新能源预测、电力交易等领域均取得了一定技术突破，并通过一些落地案例验证了业务价值。达摩院将整合以上三方面的能力，打造面向新型电力系统的优化决策平台，并开放给行业伙伴，期待携手各方共同在发、输、配、用各个环节发挥人工智能的作用，促进新能源消纳，降低社会用电成本。印卧涛号召“行业+数学+机器学习+云计算”各个领域的同仁携起手来，共赴新型电力系统技术挑战的星辰大海。
-
提交了问题
2022-11-30
乘风问答官12月排位赛开启！机械键盘、行李箱等你拿！
-
发表了文章 2022-11-30
乘风问答官12月排位赛开启！机械键盘、行李箱等你拿！
恭喜各位成为乘风问答官，问答官专属每周积分活动、每月排位赛开启啦！本期我们为大家准备了非常丰厚的礼品，先一睹为快！ 面向对象所有乘风问答官 （如果你还不是乘风官，可通过https://developer.aliyun.com/ask/469377查看申请）每周积分活动每天回答3个问题，连续3天给30积分，连续5天再给30积分，连续7天再给90积分（每周可获得最高150积分）注：1.回答的问题需要是为当月的问题2.周的计算：12月1号~7号为第一周，8~14号为第二周，15~21号为第三周，22~31为第4周3.每周积分名单将在乘风问答官群中公布每周排位赛注释：首答指的在12月新增的问题中，你作为问答官给予了首个切合题意的解答活动时间12月1日至12月31日24:00 报名方式回答12月问题即视为报名（一定是12月份的问题哦） 获奖名单及奖品邮寄时间奖名单将于活动结束后7个工作日内公布，奖品将于12个工作日内进行发放，节假日顺延。 注意事项： 首答：按照回复时间统计，第一条切合题意的回答为首答。严禁先用111等无关词语站位，后续重新编辑，如有发现，取消活动资格并取消乘风问答官资格； 每人只能获得一个奖品，同时满足多个奖项，发放最高奖项奖品； 回答的问题必须是活动当月提出的问题； 话题活动回答不记录总条数； 同一问题，如已有回答，若你有其他解决方案也可作答，可作计数；若回答雷同，将不计数； 回答请解答能力范围之内的问题进行，充数回答将不计数； 回答需为中文，英文不记录数据（代码除外）； 回答发布后将进入审核状态，审核完成即可查看； 标题党、黑稿、通稿、包含违法违规、未被许可的商业推广、外站链接、非原创内容、营销软文、抄袭嫌疑的文章审核将不予通过，同时取消乘风问答官资格。
-
提交了问题
2022-11-28
【藏经阁一起读（39）】读《中国开发者画像洞察报告2022》，你有哪些心得？
-
提交了问题
2022-11-25
你怎么看足球盛宴中的黑科技？
-
发表了文章 2022-11-25
谈谈过度设计：因噎废食的陷阱
作者 | 杜沁园(悬衡)来源 | 阿里开发者公众号引言写软件和造楼房一样需要设计，但是和建筑行业严谨客观的设计规范不同，软件设计常常很主观，且容易引发争论。设计模式被认为是软件设计的“规范”，但是在互联网快速发展的过程中，也暴露了一些问题。相比过程式代码的简单与易于修改，设计模式常常导致代码复杂，增加理解与修改的成本，我们称之为 “过度设计”。因而很多人认为，设计模式只是一种炫技，对系统没有实质作用，甚至有很大的挖坑风险。这个观点容易让人因噎废食，放弃日常编码中的设计。本文将深入探索如下问题：为什么长期来看，设计模式相比过程式代码是更好的？什么情况下设计模式是有益的，而什么情况下会成为累赘？如何利用设计模式的益处，防止其腐化？设计模式的缺陷“过度设计” 这个词也不是空穴来风，首先，互联网软件的迭代比传统软件快很多，传统软件，比如银行系统，可能一年只有两个迭代，而网站的后台可能每周都在发布更新，所以互联网非常注重软件修改的便捷性。其次，设计模式的 “分模块”，“开闭原则” 等主张，天然地易于拓展而不利于修改，和互联网软件频繁迭代产生了一定的冲突。开闭原则的缺陷开闭原则：软件中对象应该对扩展开放，对修改关闭。基于开闭原则，诞生了很多中台系统。应用通过插件的方式，可以在满足自身定制业务需求的同时，复用中台的能力。当业务需求满足中台的主体流程和规范时，一切看上去都很顺利。一旦需求发生变更，不再符合中台的规范了，往往需要中台进行伤筋动骨的改造，之前看到一篇文章吐嘈 “本来业务上一周就能搞定的需求，提给中台需要8个月”。所以基于中台无法进行深度的创新，深度创新在软件上必然也会有深度的修改，而中台所满足的开闭原则是不利于修改的。最小知识原则的缺陷最小知识原则：一个对象对于其他对象的了解越少越好。最小知识原则又称为 “迪米特法则”，基于迪米特法则，我们会把软件设计成一个个 “模块”，然后对每个 “模块” 只传递需要的参数。在过程式编码中，代码片段是拥有上下文的全部信息的，比如下面的薪资计算代码：// 绩效 int performance = 4; // 职级 int level = 2; String job = "engineer"; switch (job) { case "engineer": // 虽然计算薪资时只使用了 绩效 作为参数, 但是从上下文中都是很容易获取的 return 100 + 200 * performance; case "pm": // .... 其余代码省略 }而如果我们将代码改造成策略模式，为了满足迪米特法则，我们只传递需要的参数：// 绩效 int performance = 4; // 职级 int level = 2; String job = "engineer"; // 只传递了需要 performance 参数 Context context = new Context(); context.setPerformance(performance); strategyMap.get(job).eval(context);需求一旦变成 “根据绩效和职级计算薪资”，过程式代码只需要直接取用上下文的参数，而策略模式中需要分三步，首先在 Context 中增加该参数，然后在策略入口处设置参数，最后才能在业务代码中使用增加的参数。这个例子尚且比较简单，互联网的快速迭代会让现实情况更加复杂化，比如多个串联在一起模块，每个模块都需要增加参数，修改成本成倍增加。可理解性的缺陷设计模式一般都会应用比较高级的语言特性：策略模式在内的几乎所有设计模式都使用了多态访问者模式需要理解动态分派和静态分派...这些大大增加了设计模式代码的理解成本。而过程式编码只需要会基本语法就可以写了，不需要理解这么多高级特性。小结这三点缺陷造成了设计模式和互联网快速迭代之间的冲突，这也是应用设计模式时难以避免的成本。过程式编码相比设计模式，虽然有着简单，易于修改的优点，但是却有永远无法回避的本质缺陷。过程式编码的本质缺陷上文中分析，过程式编码的优点就是 “简单，好理解，易于修改”。这些有点乍看之下挺对的，但是仔细想想都很值得怀疑：“简单”：业务逻辑不会因为过程式编码而变得更加简单，相反，越是大型的代码库越会大量使用设计模式（比如拥有 2400w 行代码的 Chromium）；“好理解”：过程式编码只是短期比较好理解，因为没有设计模式的学习成本，但是长期来看，因为它没有固定的模式，理解成本是更高的；“易于修改”：这一点我相信是对的，但是设计模式同样也可以是易于修改的，下一节将会进行论述，本节主要论述前两点。软件复杂度软件工程著作 《人月神话》 中认为软件复杂度包括本质复杂度和偶然复杂度。本质复杂度是指业务本身的复杂度，而偶然复杂度一般是因为方法不对或者技术原因引入的复杂度，比如拆分服务导致的分布式事务问题，就是偶然复杂度。如果一段业务逻辑本来就很复杂，即本质复杂度很高，相关模块的代码必然是复杂难以理解的，无论是采用设计模式还是过程式编码。“用过程式编码就会更简单” 的想法在这种情况下显然是荒谬的，相反，根据经验，很多一直在采用过程式编码的复杂模块，最后都会变得逻辑混乱，缺乏测试用例，想重构时已经积重难返。那么设计模式会增加偶然复杂度吗？阅读有设计模式的代码，除了要理解业务外，还要理解设计模式，看起来是增加了偶然复杂度，但是下文中我们会讨论，从长期的角度来看，这不完全正确。理解单一问题 vs 理解一类问题开头提到，设计模式是软件设计的“规范”，和建筑业的设计规范类似，规范能够帮助不同背景的人们理解工程师的设计，比如，当工人们看到三角形的结构时，就知道这是建筑师设计的支撑框架。过程式代码一般都是针对当前问题的某个特殊解决方法，不包含任何的 “模式”，虽然表面上减少了 “模式”的学习成本，但是每个维护者/调用者都要去理解一遍这段代码的特殊写法，特殊调用方式，无形中反而增加了成本。以数据结构的遍历为例，如果全部采用过程式编码，比如二叉树打印的代码是：public void printTree(TreeNode root) { if (root != null) { System.out.println(root.getVal()); preOrderTraverse1(root.getLeft()); preOrderTraverse1(root.getRight); } }图的节点计数代码是：public int countNode(GraphNode root) { int sum = 0; Queue<Node> queue = new LinkedList<>(); queue.offer(root); root.setMarked(true); while(!queue.isEmpty()){ Node o = queue.poll(); sum++; List<Node> list = g.getAdj(o); for (Node n : list) { if (!n.isMarked()) { queue.add(n); n.setMarked(true); } } } return sum; }这些代码本质上都是在做数据结构的遍历，但是每次读到这样的代码片段时，你都要将它读到底才发现它其实就是一个遍历逻辑。幸好这里的业务逻辑还比较简单，就是一个打印或者计数，在实际工作中往往和更复杂的业务逻辑耦合在一起，更难发现其中的遍历逻辑。而如果我们使用迭代器模式，二叉树的打印代码就变成：public void printTree(TreeNode root) { Iterator<TreeNode> iterator = root.iterator(); while (iterator.hasNext()) { TreeNode node = iterator.next(); System.out.println(node); } }图的节点计数代码变成：public int countNode(GraphNode root) { int sum = 0; Iterator<TreeNode> iterator = root.iterator(); while (iterator.hasNext()) { iterator.next(); sum++; } return sum; }这两段代码虽然有区别，但是它们满足一样的 ”模式“，即 “迭代器模式”，看到 Iterator 我们就知道是在进行遍历，甚至都不需要关心不同数据结构具体实现上的区别，这是所有遍历统一的解决方案。虽然在第一次阅读这个模式的代码时需要付出点成本学习 Iterator，但是之后类似代码的理解成本却会大幅度降低。设计模式中类似上面的例子还有很多：看到 XxxObserver，XxxSubject 就知道这个模块是用的是观察者模式，其功能大概率是通过注册观察者实现的看到 XxxStrategy 策略模式，就知道这个模块会按照某种规则将业务路由到不同的策略看到 XxxVisitor 访问者模式 就知道这个模块解决的是嵌套结构访问的问题...是面对具体问题 case by case 的学习，还是掌握一个通用原理理解一类问题？肯定是学习后者更有效率。“过程式代码更加好理解”往往只是针对某个代码片段的，当我们将范围扩大到一个模块，甚至整个系统时，其中会包含大量的代码片段，如果这些代码片段全部是无模式的过程代码，理解成本会成倍增加，相似的模式则能大大降低理解成本，越大的代码库从中的收益也就越大。新人学习过程式编码和设计模式的学习曲线如下图：过程式编码虽然刚开始时没有任何学习压力，但是不会有任何积累。设计模式虽然刚开始时很难懂，但是随着学习和应用，理解会越来越深刻。设计模式防腐前文中提到，互联网软件非常注重修改的便捷性，而这是过程式编码的长处，设计模式天然是不利于修改的。但是过程式编码又有着很多致命的问题，不宜大规模使用。我们如何才能在发挥设计模式长处的同时，扬长补短，跟上业务的快速演进呢？腐败的设计模式有一条恶龙，每年要求村庄献祭一个少女，每年这个村庄都会有一个少年英雄去与恶龙搏斗，但无人生还。又一个英雄出发时，有人悄悄尾随，龙穴铺满金银财宝，英雄用剑刺死恶龙。然后英雄坐在尸身上，看着闪烁的珠宝，慢慢地长出鳞片、尾巴和触角，最终变成恶龙。以上是缅甸著名的 “屠龙少年变成恶龙” 的传说。见过很多系统，最初引入设计模式是为了提高可维护性，当时或许实现了这个目标，但是随着时间推移，变成了系统中没人敢修改，“不可维护” 的部分，最终成为一个 “过度设计”，主要原因有以下两点：无法调试： 新的维护者无法通过调试快速学习模块中的 “模式”，或者说因为学习成本太高，人们常在没有弄清楚“模式”的情况下就着手改代码，越改越离谱，最终覆水难收没有演进： 系统中的设计模式也是要跟随业务不断演进的。但是现实中很多系统发展了好几年，只在刚开始创建的时候进行过一次设计，后来因为时间紧或者懒惰等其他原因，再也没有人改过模式，最终自然跟不上业务，变成系统中的累赘。可调试的模块“模块” 是软件调试的基本单位，一个模块中可能会应用多种 “设计模式” 来辅助设计。设计模式相比过程式编码，逻辑不是线性的，无法通过逐行阅读来确认逻辑，调试就是后来人学习理解设计的重要途径。在理解的基础上，后人才能进行正确的模式演进。“模块” 在软件工程中的概念比较含糊:模块可以是一个独立的系统。由多个微服务构成的一个系统，每个微服务可以认为是一个 “模块”；在同一个应用中 和一个功能相关的对象集合也可以认为是一个模块。随着微服务概念的兴起，很多人误认为只有将代码拆成单独的系统，才能叫 “模块”，其实不然，我们应该先在同一个应用中将模块拆分开来，然后再演化成另一个单独的应用，如果一上来就强行拆的话，只会得到两个像量子纠缠一样耦合在一起的应用。关于软件调试。有的人倾向于每做一点修改就从应用的入口处（点击图形界面或者调用 http 接口）进行测试，对他来说应用内部的分模块就是一种负担，因为一旦测试不通过，他需要理解模块之间复杂的交互，然后确认传入被修改模块的参数是什么。对他来说，肯定是全部使用过程式编码更好理解一些，然后抱怨系统 ”过度设计“，虽然可能设计并没有过度。有经验的工程师在修改完代码后，会先测试被修改模块的正确性，没有问题后，应用入口处的测试只是走个流程，大多可以一遍通过。但是如果一个模块没有办法独立调试的话，那么它所有人来说都是一个累赘。对于独立系统的模块，它的接口应该在脱离整个应用后也明确的含义的，接口参数也应该尽量简单且容易构造。对于同一应用中的代码模块，它还应该具备完善的单元测试，维护者通过单元测试就可以理解模块的特性和限制，通过本地 debug 就可以理解模块的整体设计。John Ousterhout 教授（Raft 的发明者）的著作 《软件设计哲学》中提到 深模块 的概念，给我们设计模块提供了非常好的指导。深模块是指接口简单，但是实现复杂的模块，就像我们的电脑，它看上去只是一块简单的板，却隐藏了内部复杂的功能实现。John 认为设计良好的模块都应该是深的，设计良好的应用应该由深模块组成。从软件调试的角度来说，接口简单意味着它易于调试和理解，实现复杂意味着它能够帮助我们屏蔽掉很多的业务复杂性，分模块的代价是值得的。上面的论述可能比较偏向于思想认知层面，关于是实践层面可以参考我的另一篇文章 代码重构：面向单元测试。可调试的模块能够让我们修改设计模式的心理压力大大降低，因为有任何问题我们都可以很快发现。有了这个基础，我们才能跟着业务去演进我们的模式。模式演进互联网应用更新迭代频繁，因为设计模式不易于修改，外加模块不好调试，很多团队就懒得对模式进行演进，而是各种绕过的 “黑科技”。很多应用都已经发展了好几年，用的还是系统刚创建时的模式，怎么可能还跟得上业务发展，于是就变成了人们眼中的 “过度设计”。设计模式也是需要跟着业务演进的。当对未来的业务进行规划，也要同时对系统模式进行思考，系统的模式是否还能跟上未来业务的规划？在迭代中不断探索最符合业务的设计模式。Java8 引入的很多新特性可以帮助我们降低业务频繁演进时，模式的迁移成本。当我们对是否要应用某个模式犹豫不绝的时候，可以考虑使用 函数式设计模式，以策略模式为例，在面向对象中，策略模式必须采用如下编码：interface Strategy { void doSomething(); } class AStrategy implements Strategy { //... 代码省略 } class BStrategy implements Strategy { //... 代码省略 } 及 // 业务代码 class AService { private Map<String, Strategy> strategyMap; public void doSomething(String strategy) { strategyMap.get(strategy).doSomething(); } }我们新建了好多类，一旦日后反悔，迁移的成本非常高。而使用函数式策略模式，我们可以将他们暂且全部写在一起：class AService { private Map<String, Runnable> strategyMap; static { strategyMap.put("a", this::aStrategy); strategyMap.put("b", this::bStrategy); } public void doSomething(String strategy) { strategyMap.get(strategy).run(); } private void aStrategy() { //... } private void bStrategy() { //... } }可以看到设计模式的函数式版本，相比面向对象版本，在隔离和封装上相对差些，但是便捷性好一些。所以我们可以在业务不稳定的初期先使用函数式设计模式，利用它的便捷性快速演进，等到业务逐渐成熟，模式确定之后，再改成封装性更好的面向对象设计模式。更多的函数式设计模式可以参考《Java8 实战》中的 函数式设计模式 相关章节。小结“设计模式” 作为对抗 “软件复杂度” 恶龙的少年，可能业务发展，缺乏演进等原因，最终自己腐坏成了新的 “恶龙”。为了对抗设计模式的腐坏：构造可调试的模块，保证后来的维护者能够通过调试快速理解设计。在业务发展中不断探索最合适的模式。开发效率与系统的成长性在思考业务的同时，还要思考模式的演进，开发效率似乎变低了。但是这额外的时间并没有被浪费，在设计过程也是对业务的重新思考，进一步加深对业务的理解，编码和业务之间必然是存在巨大的鸿沟，设计模式能够帮助我们弥补这条鸿沟，演进出和业务更加贴合的模块，从而提升长期的效率。复杂软件是需要长期成长演化的。JetBrains 花了十几年时间才让 Idea 形成优势，清扫免费 IDE 占据的市场; 米哈游也用了接近十年的时间才形成足够的技术优势，在市场上碾压了同时期的竞争对手。而设计模式就是在帮助我们对业务进行合理的抽象，尽可能地复用，这样系统可以从每个模块地成长中收益，而不是像过程式编码，每次都重头开始，重复解决那些已经解决过的问题。举一个我工作中的例子，钉钉审批的表单有着复杂的嵌套结构，它由控件和明细组成，而明细中又子控件（有的控件中还有子控件，甚至还有关联其他表单的控件，总之很复杂就对了），最初我们采用过程式编码，每当需要处理控件时，就手写一遍遍历：// 统计 a 控件的总数 public int countComponentAB(Form form) { int sum = 0; for (Component c: form.getComponents()) { if (c.getType() == "A") { sum++; } else if (c.getType == "Table") { // 明细控件含有子控件 for (Component d: c.getChildren()) { if (d.getType() == "A") { sum++; } } } } return sum; }// 返回表单中所有的 A 控件和 B 控件 public List<Component> getComponentAB(Form form) { List<Component> result = new ArrayList<>(); getComponentABInner(result, form.getItems()); return result; } private getComponentABInner(List<Component> result, List<Component> items) { for (Component c: items) { if (c.getType() == "A" || c.getType() == "B") { result.add(c); } else if (!c.getChildren().isEmtpy()) { // 递归访问子控件 getComponentABInner(result, c.getChildren()); } } }这两段代码各自有点 “小 bug”：第一段代码只展开了一层子控件，但是审批表单是支持多层子控件的第二段代码虽然用递归支持了多层子控件，但是并不是所有的子控件都属于当前表单（前面提到过，审批支持关联其他比表单的控件）两段代码风格都不一样，因此只能分别在上面修修补补，新同学来大概率还会犯相同的错误，此时，系统也就谈不上 “成长”。但是 Visitor 模式可以帮助我们将嵌套结构的遍历逻辑统一抽象出来，使用 Visitor 模式重新编码后的两段代码看起来如下：// 统计 a 控件的总数 class CountAVisitor extends Visitor { public int sum; @Override public void visitA(ComponentA a) { sum++; } } public int countComponentAB(Form form) { CountAVisitor aVisitor = new CountAVisitor(); // 遍历逻辑统一到了 accept 中 form.accept(aVisitor); return aVisitor.sum; }// 返回表单中所有的 A 控件和 B 控件 class GetComponentABVisitor extends Visitor { public List<Component> result; @Override public void visitA(ComponentA a) { result.add(a); } @Override public void visitB(ComponentB b) { result.add(b); } } public List<Component> getComponentAB(Form form) { GetComponentABVisitor abVisitor = new GetComponentABVisitor(); form.accept(abVisitor); return abVisitor.result; }关于 Visitor 模式的细节，可以参考我的另一篇文章 重新认识访问者模式。对于使用者来说，虽然第一次看到这种写法时，需要花点时间学习模式，和理解其中的特性，但是一旦理解之后，不仅可以快速理解所有类似代码，还可以利用这个模块解决所有遍历问题，而且这个模块是经过验证，能够健壮地解决问题。相比之下，过程式编码，尽管都是遍历逻辑，每一段风格都不一样，每一次都要重新理解，每一段都有不一样的特性和 bug，明明知道逻辑就在那里，但是却无法复用，每一任维护者只能继续踩前人踩过的坑，重复地解决问题。对于系统的长期成长是不利的。幸福的家庭都是类似的，不幸的家庭各有各的不幸。因噎废食的陷阱软件工程师的成长在工程师成长的路上，有很多坎坷，“不要过度设计” 就是其中无比甜蜜的陷阱，因为它给我们偷懒一个很好的理由，让我们可以安然地停在五十步，反而去嘲笑已经跑了一百步的人。如果有两位工程师，前者因为过度设计而犯错; 后者则是不进行设计，安于系统现状，认为 “代码无错就是优”[引用5]。我认为前者更有成长性，因为他至少是有代码和技术上的追求的，只要有正确的指导，迟早会成为一名优秀的工程师。最怕的是团队没有人指导，任由其自由发展，或者批评阻碍其发展。这正是 CR 以及评审机制的意义。互联网精耕细作的新时代设计模式能够帮助我们大幅度提升复杂软件的开发与维护效率，也本文围绕的主要命题。但是人们总是能找出反例，“很多公司工程做得很糟糕，业务也十分成功”。之前看红学会的直播，对抗软件复杂度的战争，也有人问了晓斌类似的问题，晓斌的回答是 “如果你有一片田，种啥长啥，那么你不需要耕作，只要撒种子就可以了”。在互联网野蛮发展时期，大量的人才和热钱涌入，软件快速上线比一切都重要，开发效率的问题，只要招聘更多的人就能解决，哪怕在一个公司开发好几套功能一样的系统。但是随着互联网人口红利的消失，不再有充足的资源去承接业务，我们就不得不做好精耕细作的准备，扎实地累积自己的产品和技术优势，继续创造下一个十年的辉煌。本文的边界情况真理是有条件的。本文并非走极端地认为所有代码都应该应用模式。至少在以下情况下，是不适合用模式的：一次性脚本，没有多次阅读和修改的可能。我自己在写工具类脚本时也不会去应用模式，但是我相信阿里巴巴的应用代码，100% 都是要被反复阅读和修改的。真的很简单的模块。前文提到过 ”模块应该是深“，如果这个模块真的很简单，它或许抽象不足，我们应该将它和其他模块整合一下，变得更加丰满。如果应用中抽不出复杂模块，那可能不是事实，只是我们的实现方式太简单了（比如全是过程式编码），反过来又对外宣称 ”我们的业务很复杂“。团队内都是喜欢攀比代码设计的疯子，需要告诫警醒一下。真的有团队达到这个程度了吗？如果到了这个程度，才可以 “反对设计”。参考：[1]《人月神话》[2]《软件设计哲学》[3]《Java 8 实战》[4]《设计模式 - 可复用的面向对象软件元素》[5]《大话设计模式》[6] 代码重构：面向单元测试[7] 重新认识访问者模式[8] 对抗软件复杂度的战争
-
发表了文章 2022-11-24
2022云栖精选—TapTap算法平台的 Serverless 探索之路
Serverless 在构建应用上为我们节省了大量的运维与开发人力，在基本没投入基建人力的情况下，直接把我们非常原始的基建，或者说是资源管理水平拉到了业界相对前沿的标准。最直观的数据是，我们组仅投入了个位数的人力，就可以为TapTap整个搜广推相关的所有业务提供全套AI和大数据方面的支持。————陈欣昊 心动介绍 心动创立于 2003年，是一家全球游戏开发和发行商，拥有丰富的研发、发行和代理运营经验。截至 2022 年中，心动运营 38 款免费和付费游戏，在全世界拥有 5,000 万月活跃用户，主要分布在大中华地区、东南亚、北美和南美。2016 年，心动推出手机游戏社区和应用商店 TapTap，玩家可以通过官方渠道免费或付费购买下载手机游戏，亦可在社区中与其他玩家交流，截至2022年6月，TapTap 在全球已拥有超过5,000万月活跃用户。 业务背景 TapTap不同于传统的应用商店的分成模式，至今一直坚持做渠道零分成，这也决定了，TapTap目前的商业化，主要由广告驱动。TapTap的广告属于站内的原生广告，与其他非商业化在内容上形态保持高度一致，给用户更好的体验。比如首页的游戏推荐，发现页的内容推荐，搜索引导页的底纹词，以及搜索输入时会出现的搜索建议词，还有搜索最后的落地页等等，广告的部分就穿插在这些战略内容之间。 我们的serverless实践也是基于这几个业务场景的实际需求来进行推进的。例如，目前搜广推都依赖的深度学习模型自动化更新/部署，以及组内算法同学都需要依赖的模型实验记录平台，还有站内新内容的一些NLP分析处理等。 早期，我们绝大部分的后端服务都是部署在ECS，通过Rundeck来进行管理和部署，在效率和管理上并不是那么理想。在基建升级方案的需求上，我总结了4点：能大幅提升开发运维效率以较低的人力成本来满足业务需求服务足够可靠，能够具备良好的性能因为我们工程目前主要是以Go语言为主，所以在后续基建升级上需要对Go有良好的支持。 方案对比 我们考虑了两种主流的方案架构，一个是云主机+自建K8s全套的解决方案， 还有一种就是Serverless架构，使用 Serveless 应用引擎（SAE）和函数计算 FC。 经过对比后，我们选择了后者。一方面是 Serverless 可以免去机器的购买流程，不需要提前购买 ECS。而且本身也自带了一些可选的默认环境，如果没有特殊需求的话，可以基本免去环境搭建的繁琐；另一方面是 Serverless 已经集成了很多基础组件，基本上可以说是做到免运维直接上线的程度。 然后在后续维护上，Serverless 产品在计费精度上相比ECS 有更高的精度，可以做到分钟级，甚至秒级的计费，做到真正业务使用资源时才进行付费，相比K8s+ECS的模式，在早期开发和后续运维上, 都能节省较大的人力成本。 从我们自己实际实验的体验来理解Serverless的两个产品的话。 函数计算 FC 把业务的调度和触发逻辑与业务逻辑本身解耦，开发、算法同学可以先在函数计算控制台控制整个业务逻辑的触发与调度逻辑，就不需要再额外地开发，可以更加专注业务逻辑本身的设计，这也决定了函数计算更加适用于有业务驱动的场景，在事件真正发生时去申请资源进行业务逻辑的运行。 而 Serverless 应用引擎 SAE 在我们看来类似于功能更丰富的、提供了全套微服务能力的增强版K8s，可以极大降低维护成本，并做到真正的开箱即用。这个就比较适合做微服务改造，把原先在ECS 上的旧服务直接迁移上来，可以在不投入运维人力的情况下获得一套完整的容器化运维方案。 基本上通过两者结合，可以覆盖掉我们绝大多数的业务场景，实现所有应用服务All On Serverless。 业务实践 函数计算 FC 1）通过 OSS 触发的全自动模型部署/小时级更新服务。 我们有一个通过 OSS 触发的模型自动部署与更新服务，实现模型导出及部署。算法同学在训练完自己的模型，无论是TensorFlow还是PyTorch以及其他格式的机器学习模型，只需要导出到指定的OSS B存储空间ucket，就会触发模型的更新与部署服务，实现完整的导出即部署。这样算法同学哪怕在不依赖其他工程人力的情况下也能自行进行模型的部署、更新以及后续的弹性缩扩容。 2）通过 HTTP 触发的模型实验管理平台（WEB 服务） 算法同学通过HTTP触发器实现的内部模型实验管理与参数平台提交模型训练任务之后，我们会自动地将它训练的参数以及日志地址、日志实例记录下来，实现所有的实验可追溯、可管理，这本身是一个Web服务，它是有前端的，但又是一个对内的服务，对QPS和性能要求不是很高，于是就放到函数计算上，在管理成本上相当有优势，尤其是近期函数计算有免费额度，所以基本没花钱。 3）通过 Kafka 触发新内容 NLP 处理/解析服务 当我们站内的用户发了一个新的帖子，我们会通过Kafka推送到NLP分析服务商进行NLP的处理与解析，存下来用于之后的搜索，这可以实现用户发一条内容调一次服务，精确地控制成本。 4）每周/每日定时统计资源消费 每周/每日定时触发的 MaxCompute、EAS 资源消费统计，我们会自动拉取阿里云后台的非结构化消费账单，然后将它聚合到每一位同学，每个任务以及每个模型上，推送给组内的同学，协助组内同学提升自己的成本意识，也帮助各个业务线更好地做成本管理。Serverless 应用引擎 SAE 在 SAE 的落地上，我们选择了组内的预估服务，这个服务本身整合了搜索、推荐、广告都需要的模型推理、特征开发以及样本回传的能力，本身是一个中台型微服务，所有业务线都可以非常低成本的接入目前组内最成熟的线上预估服务。例如现在的搜索页的推荐词的点击率预估，国际版的游戏点击率预估等。 通过SAE，我们的服务快速具备了 Serverless 的能力，因为 SAE 本身屏蔽了很多资源管理、环境管理以及基础运维组件管理工作，使得我们可以快速地为国内国外的新场景、新业务上线一套独立的预估服务。 与此同时，我们也集成了 SAE 的告警平台，事件中心以及日志服务，我们通过钉钉告警就可以实时感知线上业务的状态，例如是否发生了 OOM 还是重启、错误日志之类的。 另外，本身这个服务也是接入了 Dubbo Go 框架使服务直接具备了服务注册发现，IP直连，优雅上下线等微服务能力。相比之前使用 ECS 的模式，这套方案在运维管理以及开发上线和后续的成本管控上都有较大的优势，基本可以覆盖从开发上线后续运维的全流程，大大节省的组内的开发成本。 业务价值 简单运维，省心省力：开发可以轻松搞定应用开发、部署、管理全流程，让自己更专注于业务，也大大节省了运维的投入和成本。 不停机发布 +分钟级上线：SAE支持灰度发布、滚动发布的能力，还提供了较为完善的Open API，可以集成到Git中快速部署，使我们的服务具备了分钟级发版的能力，这个对于新业务尤其具有吸引力。 秒级弹性缩扩容：SAE支持配置像CPU、内存、QPS、RT、定时等不同维度指标的扩缩策略，可以帮助提升资源利用率。尤其是业务规模大了之后，通过配置更加精细的弹性策略，可以显著降低机器成本。 多语言微服务能力：SAE提供了PHP、Python、GO等多种运行时，并且基于K8s Service多语言服务注册发现，实现了Go 语言低成本微服务化
-
发表了文章 2022-11-23
2022云栖精选—容器服务助力企业精益用云 Lean Computing on Cloud wITh Container Service 以增效促降本，容器服务全面进入智能化时代
容器技术已经跨越鸿沟，广泛应用于金融、通讯、制造、交通等千行百业。Kubernetes支撑的工作负载也从早期单一的互联网应用发展到数据库、AI、大数据等等，并覆盖了公共云、专有云、边缘云等多样化、动态的云环境。 11月5日，2022杭州 · 云栖大会上，阿里巴巴研究员、阿里云智能云原生应用平台容器技术负责人易立在云原生峰会上发表主题演讲，发布阿里云容器服务全面智能化升级，帮助企业精益用云，以增效促降本，实现IT架构在云上的高质量发展。 容器服务助力企业数字化创新 经过7年的发展，阿里云容器服务产品线已经成为企业的云原生操作系统。基于阿里云容器平台，阿里集团实现了100%业务云原生上云。 2021 年，阿里云发布了 ACK Anywhere，进一步拓展产品的宽度，覆盖从公共云、边缘云、到本地数据中心的各个场景。让所有需要云能力的地方，都能基于统一的容器基础设施之上。 得益于阿里集团和阿里云的大规模容器应用实践，阿里云容器产品能力得到了业界的广泛认可。2022年1季度，在权威咨询机构Forrester 发布的全球公共云容器平台分析师报告中，ACK稳居全球领导者象限，这也是中国科技公司首次进入该象限；2022年2季度，在 Omida 发布的全球容器管理解决方案报告中，由于在公共云、专有云、混合云等环境完善的产品体系，ACK成为全球领导者，产品能力与规模国内领先；2022年8月，在CSDN 2022中国开发者调查报告中，有52%的国内开发者选择阿里云容器云平台。 过去几年，降本增效成为了众多企业IT管理者关注的重要问题。企业已经到了精益用云的时代，提升资源效率、研发效率，IT管理效率成为关键。 四大全新升级，阿里云容器服务迈入智能化时代 智能化是容器平台发展的必然趋势。今天，阿里云基于过去10年的大规模容器实战经验，通过数据化手段和智能化算法，推动容器服务ACK面向基础设施层、容器编排层、应用架构层和运营治理领域 4 大维度全面升级，迈入智能化新阶段。 升级1：新算力 在基础设施层，利用面向云原生优化的新算力，提升计算效率。 2021 年，阿里云发布了新一代云原生CPU，倚天710，基于ARMv9架构，已经在电商、阿里云内部规模化应用，实现了卓越性价比。 相比 X86 芯片，典型 Web 应用性价比高50%，视频编解码应用性价比高 80%。倚天芯片面向云原生优化，vCPU 采用独立物理核，没有超线程架构中的性能争抢。可以提供更加确定性的性能。 ACK 通过对芯片微架构的拓扑感知调度优化，相比开源K8s实现，帮助 Web 应用吞吐提升20%。 为了更好支持 AI、HPC等I/O密集型应用。ACK 正式提供了对eRDMA高性能容器网络支持。通过软硬一体优化的网络实现，可以提供更高的带宽与更低的延迟。应用在AI训练加速20%，微服务吞吐提升10%； ACK 支持多容器高效复用eRDMA设备，满足了容器应用部署密度的需求。 为了更好支持有状态应用容器化，阿里云发布新一代容器网络文件系统 CNFS 2.0，它采用全链路加速技术，可以实现： 容器应用对后端存储系统的访问并行化，提升网络带宽的利用率。对远程NAS存储的吞吐可以提升100%，满足高性能AI训练和基因计算的需求。利用元数据缓存和独有的lease机制，使得远程文件存储的元数据访问性能，提升了18倍，非常适合Web应用和CI/CD等需要对海量小文件进行访问的场景。支持文件的透明生命周期管理，可以自动将低频访问的冷数据放置在低成本的NAS低频介质或OSS中，降低存储成本50%以上。它支持对NAS/CPFS/OSS全链路可观测，帮助开发者更好诊断和优化I/O性能问题。 企业与个人对数据隐私保护日益关切，机密计算技术应运而生。其中一个重要的技术是通过芯片的可信执行环境（TEE）实现数据保护。在TEE内执行的应用，不用担心来自其他应用、其他租户或者平台方的威胁。 为了进一步推动机密计算的普及，阿里、蚂蚁团队在Kata Container社区与红帽、Intel等公司进行合作，将容器计算与可信执行环境相结合，推出机密容器Confidential Container 项目，同时为 Intel® SGX、Intel® TDX等不同的TEE实现，提供了一致的容器界面。 基于新一代的机密容器架构，开发者可以确保应用是通过可信软件供应链进行构建和分发的；容器应用运行在可信执行环境中，具备更小的攻击面，而且所有内存中数据是加密的并受完整性保护；应用对数据的访问是基于加密的可信数据存储服务。 机密容器可以在需要隐私数据处理的场景中，如金融风控、医疗健康等，提供高效的隐私增强型算力。 升级2：新平台 在容器编排层，通过智能化、云边端一体的新平台，提升资源利用率和运维效率。 K8s目前已经成为云时代的操作系统。希望充分利用多种应用负载之间的削峰填谷，提升K8s集群资源利用率。这也是大家常说的“混部”能力。 阿里巴巴早在 2016 年就启动了云原生混部技术研发，历经多轮技术架构升级和双11锤炼，目前已实现全业务规模超千万核的云原生混部，日常CPU利用率在 50% 左右。 阿里云今年开源了云原生混部项目 Koordinator，它包含三大核心能力： 差异化 SLO 保障：在 Kubernetes 之上提供面向QoS 的资源调度机制，比如延迟敏感型的在线类任务，和可抢占的计算任务。通过对不同QoS应用的合理调度，可以在保障应用的稳定性的同时，提升资源利用率。QoS 感知调度：包括 CPU、GPU 拓扑感知、资源画像、热点打散等精细调度能力，帮助应用优化运行时性能效率，提升稳定性。任务调度：提供了大数据与 AI 相关的任务调度，比如批量调度、优先级抢占以及弹性 Quota等，可以更高效地支持计算任务Koordinator 项目完全兼容标准的 K8s，无需做任何侵入式修改。ACK也内建了Koordinator产品化支持： 通过混部调度，在典型场景可以提升资源利用率100%；通过差异化SLO保障，在提升资源利用率的同时，让低优先级的任务对延迟敏感型任务的影响 < 5%。 Kubernetes的复杂性是阻碍很多客户采用的一个重要因素。为此，ACK发布AIOps套件，通过智能化手段实现故障预防与快速定位。 基于阿里团队10年大规模容器运维经验沉淀，通过专家系统和AI算法相结合的方式，提供了全栈巡检、升级检查，智能诊断等三大功能。 智能诊断目前包含200+诊断项，覆盖90%的常见问题场景。以容器网络问题诊断为例，排查链路长，复杂度高，非常耗时耗力。 在得物的业务场景中，利用智能诊断，可以快速定位由于网络栈异常导致的偶发性抖动问题；再如e签宝，利用智能诊断，可以在分钟级完成对Ingress、容器网络、应用和OS的全链路问题排查。 ACK One 是面向多地域多集群的分布式容器平台，可以统一管理中心云、本地云、边缘云和客户IDC的K8s集群。今年阿里云在ACK One基础上，发布如下功能： 提供托管的ArgoCD服务，开发者可以通过GitOps方式来实现应用的跨地域自动化交付；通过弹性感知的调度器实现，为混合云场景提供灵活的弹性算力；支持对多集群安全策略的统一管理，保障企业系统统一安全基线来看一个具体案例，在智联招聘的业务高峰期，借助ACK One弹性调度策略可以在数分钟内弹出数万核ECS和ECI等计算资源补充到IDC的在线服务集群，有效应对流量洪峰。ACK@Edge 是面向云边端一体协同的容器应用平台，基于阿里云开源的OpenYurt项目，今年对ACK@Edge 进行全新升级： 在云边协同场景，阿里云推出了增强型网络边缘节点池，实现安全、稳定的云边网络互联方案。国内知名游戏企业，莉莉丝，利用增强型边缘网络节点池，让海外多地域服务器与云上 VPC 安全互通。相比专线网络资源成本降低 30%。 在云端协同场景，阿里云推出了轻量化接入功能，可以通过K8s管理资源受限的设备上的容器应用。元戎启行是一个自动驾驶Startup公司，通过ACK@Edge管理车载设备应用，接入资源开销占用降低 50 %，发布运维效率提升 60% 以上。 升级3：新架构 在应用架构层，利用服务网格等新架构，提升应用的敏捷性、弹性与韧性。 服务网格已经成为云原生应用的网络基础设施。阿里云服务网格服务ASM在4个维度进行了全新的升级： 支持多种服务治理框架，可以实现Spring Cloud, Apache Dobbo等微服务应用与服务网格应用的互联互通和平滑迁移；为应用服务提供统一的身份定义, 简化零信任策略的构建与实施；提供开箱即用的Envoy插件市场, 可以拓宽服务网格的应用场景, 包括身份认证、AI Serving等场景；可以基于服务SLA指标，实现更加精准的弹性扩缩容震坤行工业超市是一家数字化的工业用品服务平台，为众多企业复工复产保驾护航。借助于ASM服务网格, 提升了平台的性能。基于ASM的软硬一体优化技术，提升TLS握手性能 75%，以及QPS 30+%。关于相关技术细节，可以参阅Intel和阿里云一起编写的技术白皮书（点击阅读原文即可下载）。 专注餐饮行业数字化的合阔智云, 其业务中台的核心生产系统100%全部切换到服务网格ASM，提升应用发布效率70%，降低异常排错成本80%。 升级4：新实践 在运营治理领域，将通过一系列最佳实践的产品沉淀，提升企业IT在成本管理、安全治理等方面的管理效率。为了帮助企业上好云、用好云、管好云，阿里云本次发布了云原生landing zone，为企业云原生上云提供最佳实践。它包含架构规划、安全管理、财务管理、自动化运维等等8大模块。 通过云原生landing zone最佳实践，已经帮助众多国内外企业客户构建了上云架构，满足企业对安全、稳定性和成本等多方面的业务诉求。 围绕LandingZone 中财务管理部分，阿里云结合业财一体化实践和 FinOps 理念，推出 ACK FinOps 套件。通过数字化手段和智能化方法，帮助企业实现成本可视化、可优化、可控制。 中华保险作为国内互联网金融行业的领导者，通过ACK FinOps套件，将企业 IT 成本治理周期从季度缩短到天级别，资源闲置率从 30% 降低到 10% 以内。 识货团队通过应用混部和弹性等技术优化，将集群的资源利用率提升10%；整体降低计算成本20%以上。 围绕 LandingZone 中安全防护部分，ACK 与 ACR 提供完备的DevSecOps的产品能力，为企业提供安全可信的软件供应链。 今年，阿里云推出了集群容器安全概览，可以帮助安全管理员对集群安全水位有更好地感知，可以对集群配置、应用镜像、容器运行时的安全风险，及时发现与处置。 全球领先的SaaS厂商Salesforce，在阿里云上提供先进的CRM服务应用。基于云原生 DevSecOps 能力，半年内实现 数 千次风险镜像拦截阻断， 1 万次工作负载部署策略阻断。基于全自动化软件供应链安全流程，应用安全交付效率提升 3倍。 未来，希望更多的企业能和阿里云一起，利用云原生技术精益用云、增效降本，在云端进行业务创新。
-
发表了文章 2022-11-22
2022云栖精选—智能汽车产业峰会 以空间计算定义新汽车
六年前，斑马智行发布了第一辆互联网汽车。2022年11月4日，阿里巴巴集团副总裁、斑马智行联席CEO张春晖再次来到杭州云栖小镇，在2022云栖大会的智能汽车产业峰会上做了“以空间计算定义新汽车”的分享。据张春晖介绍，斑马智行聚焦于智能汽车操作系统，打造空间智能，与行业伙伴开放合作，共同构建新生态。。 从智能在线，到空间智能 经过六年的发展，汽车已经从移动在线演变到空间智能。注意是空间智能，不是智能空间，正如杭州首位购买智己L7的用户所说，“喜欢它的空间舒适程度，不止是空间大小，还有空间智能程度”。 营造第二空间 有人说家是第一空间，公司是第二空间，车是第三空间，其实智能汽车至少应该是第二空间，我们需要以空间计算重塑面向场景的空间体验，实现对传统空间的价值替代和体验超越。从平面到空间，设计师们的想象也在智能汽车里被释放了，甚至是时空穿梭了，当然这背后需要巨大的算力和操作系统的支持。下面是几个具体场景:胶囊酒店 Motel基于座舱用户睡眠曲线和体态位置计算的智能空调体验。 新汽车影院AR眼镜巨幕，7.1.4空间音频全景声，5D座舱联动，与好友一起看。 以人为中心，会带来完全不一样的视听体验和享受。这个时候，车的社交属性也进来了，体验属性也进来了。当然这些需要操作系统和引擎的强力支撑。 街机 Arcade基于实时游戏内容计算的空间音频和多维度座舱联动体验。 当用户在汽车里面玩游戏的时候，会发现体验完全不一样了，游戏内容会实时计算，甚至用户会成为游戏中的主角。 斑马草原 斑马草原是新汽车的元宇宙入口，为用户提供生活、娱乐与社交新体验。 现在大家都在讲元宇宙，如果将来存在这样一个元宇宙的话，那汽车肯定是元宇宙的很好的入口。汽车内有各种各样的空间，如影音空间、办公空间、休闲空间，这个“百变空间”背后是场景引擎的支撑。如果在这个空间的基础上再向前走一步，就会穿梭到达一个线上空间，这就是我们将打造 的斑马草原。在斑马草原里面，可以用新的用户喜欢的方式，为生活、娱乐、社交打开想象空间。 邀请“原住民”与蚂蚁森林共建斑马草原 斑马草原原住民计划目前是正在进行时，邀请“原住民”与蚂蚁森林等合作伙伴和开发者共建斑马草原。其中服务包括： 车服务类：能源站，洗车房，维修中心等；本地生活类：衣食住行、旅行、保险、金融等；互娱体验类：游戏、音乐、视频、社交等； 斑马草原为OEM打造专属“部落”，为汽车品牌提供私域运营阵地 除了合作伙伴还有客户，斑马草原为OEM客户打造专属的部落，在这里可以进行各种各样的运营。 探索元宇宙入口 智能汽车是元宇宙入口，以空间计算探索虚实结合的元宇宙体验，助力车企定制虚拟社区、丰富用户元宇宙生活。让开发者一起来共建，是我们新生态的一部分。 从“你好，斑马”到“Hello，智己” 在六年前，斑马智行发布第一辆互联网汽车的时候，一句“你好，斑马”，给大家带来了一个新的体验，开创了“语音是第一交互方式”、“地图即桌面”等，引领行业发展。如今，用户与斑马语音交互累计超过20亿次，斑马已经从直接服务用户到使用更加生态化的方法来服务用户，赋能合作伙伴，提升底层能力。 用生态方法做生态我们要用生态方法做生态，和大家一起共建。斑马会把操作系统基础设施做好，将很难的事情做好，同时联合合作伙伴，把生态发展起来。 聚焦六大空间智能新生态 我们总结了空间计算的六个能力，包括感知、连接、计算、异构、分布、实时。这也是我们一直在追求的操作系统的六大核心能力。 未来，斑马将从用户视角出发，聚焦于六大方向进行投入和探索。 1. 数字人。数字人在车里面是一个非常重要的场景，开车的时候会有一个数字人，需要的时候就出现，非常懂你。2. 城市桌面。从地图桌面演进到城市桌面，城市桌面是用户的视窗，用户可以真实地探视这个城市，它将虚拟和真实结合起来提供服务，城市桌面也将和未来的无人驾驶结合起来。3. 百变空间。车可以变成用户的各种空间，比如后排一坐就可以打开“电脑”，比如有很多新的设备可以上车，包括眼镜等，可以把用户从屏幕的约束中解放出来。4. 新汽车影院。汽车影院是一种现象或者一种生活方式，智能汽车可能会带来新的产业链，包括新媒体的互动等。5. 梦工厂。IP等内容服务一定会上车，想象空间巨大。6. 元宇宙入口。这是虚实结合非常好的切入点。 斑马智行聚焦于智能汽车操作系统，开放合作，与广大合作伙伴、开发者一起，共建新生态。
-
发表了文章 2022-11-21
百问求答（2）大数据专场来啦！写回答赢大奖！
活动已结束获奖名单如下，请获奖同学前往积分商城兑换奖品百问求答第1期活动获得了众多用户的参与与支持，为了让更多人的困惑得到解答，第二期大数据专场来啦！参与回答，赢取大奖！还有机会成为“乘风问答官”，享受问答最高荣誉与权益。奖项设置奖项奖品获奖条件参与奖50积分切合题意的回答数量≥10条二等奖小米米家蓝牙温湿度计+乘风问答官名额切合题意的回答数量≥30条一等奖小米有品映趣剃须刀+乘风问答官名额切题题意的回答数量≥50条，且200字以上图文结合的回答超过3条 注：问题已有解答，但你有其他解决方案也可作答，将记录在内；若回答雷同，将不计数。活动流程：回答文末中任一的问题，即视为参与本次活动；钉钉扫码入群，第一时间获取活动进度及获奖名单。活动时间2022年11月21日至11月30日24：00获奖名单公布及奖品邮寄时间获奖名单将于活动结束后3个工作日公布，奖品将于7个工作日内进行发放，节假日顺延。活动规则1、 回答仅限下文链接中的问题，其他回答不计数；2、 请回答能力范围内的问题，充数回答或与问题无关的答案将不计算在内；3、 回答需为中文，英文不记录数据（代码除外）；4、 回答发布后将进入审核状态，审核完成即可查看；5、 标题党、黑稿、通稿、包含违法违规、未被许可的商业推广、外站链接、非原创内容、营销软文、抄袭嫌疑的文章审核将不予通过，同时取消参赛资格。待回答的问题链接flink有一个问题 flink cdc 使用sql 进行group by 录入的时候，长时间会造成内存溢出吗为什么2.3的flink cdc 抽的binlog的时间是0？flink SQL能获取到op字段在select里面查出来吗？问一下FlinkSQL有什么可视化工具吗？各位有个问题请教一下，我部署的是flink on yarn session ,3台机器，启动时候-n各位大佬，oracle cdc使用的时候因为数据变化量比较大导致在flink同步的时候，整个oracle被拖的非常慢，这个有什么比较好的解决方案吗？oracle cdc是不是本身就不是很健全，要做oracle的实时同步有什么比较好方式吗请教下各位，不知道flink cdc同步mysql数据库的数据跟datahub、dataworks或者是hologres的关系。我现在想利用flinkcdc和hologres做实时数仓。flink cdc到holo 的方法不是很清楚。若果可以的话能否提供些demo或者资料，感谢，打扰了。请教下，我之前将数据通过DataHub再到DataWorks做离线数仓。现在想用flink cdc和Hologres做一个试试数仓。 在搭建实时数仓的时候从flink cdc 同步的数据是先到datahub还是直接到hologres呢？关于这个问题我还没想好。 从flink cdc 来的数据是原数据，在进holo之前还想有个清理的过程。有flink cdc 取mysql数据直接到holo的方法么？请教个问题，用flink读本地文件可以得到输出结果，但是提交到flink单机模式服务器上执行jar包就看不到输出结果，任务2秒就结束了，也没有报错日志，有大神知道是什么原因吗各位大佬，请教一下，如果在flink cdc sql客户端 使用SQL查询表，怎么能记录原系统的数据是变更还是删除操作状态及时间呢？flink sql 创建后，源库删除，目标不删除，这个操作有好的解决方法没呀？取消 flink 作业后 ，发现 flink 所在的 taskmanage 挂掉了。上面的 flink job 没有自动迁移到别的机器，一直重启中，这是什么原因呢 taskmanage 挂掉， job 应该会自动迁移到别的机器吧？flink cdc 抽MySQL数据，一开始抽一张表，checkpoint成功了，后面加了一张表，然后用一张表的时候的checkpoint路径启动，发现抽不了数，也不报错，什么原因？各位大佬，请教个问题，使用flink cdc读取数据时，如果配置一个表，数据过滤是发生在server端，即只读取一个表，发送一个表的数据；还是读取整个库的数据，发送到client端，然后在client端过滤出配置的表？我使用flink cdc StartupOptions.latest() 采最新的日志。要是程序挂了，这个是继续上次的偏移量进行采集。还是从最新的开始啊？我现在flink服务启动之后，占用的cpu有点多，20%-30%。服务器是64核的。这样正常吗？flink cdc 怎么做断点续传啊flink sql 可不可以实现 过滤某种操作事件请教下有flink cdc 对接mysql5.6的demo么？我这边显示各种包错误请问大家，flink CDC说是支持clickhouse，但是我使用jdbc connector报错，在flink官网也没找到clickhouse connector。 这是需要自己开发么？大佬们，flink cdc如何限制拉取的数量？flink内存不多我们公司有最近有这个需求，把oracle数据抽取到clickhouse，在技术选型上看到flinkcdc跟chunjun，感觉都能做，不知道有哪些不一样的地方大家有测试过 一个脚本采用flink cdc 同步mysql 能同时同步多少表吗 ?大佬们，flink这个ck一直在这个状态，可能是什么原因？各位，Flink 的离线计算的数据是怎么存放的？是存在 HDFS（或Hive）上的吗？jdbc_2.12-1.14.4 sink支持回撤流吗？似乎flink sql中-D的数据并不能执行有人知道，这个在任务提交到flink集群的时候怎么做么？提交flink任务的机器上是时间是UTC时间 为啥提交jar包之后 在flink web ui 显示的是北京时间呢？有大佬能说下原因吗？有大佬知道flink监控的这块数据的源码实现是在哪里的吗？大佬们，我在用flink cdc 采集mysql表时，表里面有一个字段是 `signed_pdf`有Flink cdc Oracle 商用的嘛？有谁知道flink cdc连接后，读不到归档日志是什么问题？在别的环境好好的，换个环境里不行，代码也不报错请教一个小白的问题，我看官网上flink cdc 2.2.* 版本 支持 flink 1.13., 1.14. ，1.15 及以后的flink版本不能用cdc吗？flink 1.15.2 sql cli 创建catalog报错这个flink cdc 2.0 是分片机制，全量同步，怎么保障顺序同步？状态需要顺序的flink 15版本cdc connector同步mysql的数据，本地能拉取到数据，打jar包之后提交就拉取不到变更数据了，而且看不到错误日志？有人遇到过这个情况吗？flink采集mysql的数据，设置的StartupOptions.initial() ，理论上应该是读取完快照数据后，切换为读取binlog数据，但是现在不读了各位, 请问: flink cdc, 用 flink sql 的方式 sink 到 kafka 可以指定输出 schema 信息嘛? 看到好像只有 api 中可以指定 .deserializer(new JsonDebeziumDeserializationSchema(true)). flink sql 没办法嘛?Flink CDC支持计算列吗？请问flink cdc oracle 可以实现从oracle 19c的备库(data guard)，实时同步数据吗？Flink On Yarn模式，有办法可以固定jobmanager.rpc.port端口吗？我使用的cdc是2.2.0版本，flink是1.14.3版本，自己编译的jar包。但是我允许github上的官方样例代码报错flink cdc读取oracle数据，需要的最小权限列表是什么，DBA反馈给的权限过大，不同意这么flink cdc内置了kafka 监听binlog文件的时候 是把所有监听的数据写入kafka的请问有人知道在flink cdc读取oracle的数据表或视图时，这个oracle用户需要具备哪些权限呢？目前我测试单表只读权限的用户提示权限不足。datawork请问下，我的业务场景是有个字段是身份证号，我需要用正则表达式控制这个字段的质量，dataworks的功能支持吗？请问dataworks迁移助手在3.12版本有没有dataworks的临时查询里面我建表，也提示成功了，怎么不找建好的表呢Dataworks 的ip 在哪里看？新增数据源的时候要，添加到数据库的白名单这边使用dataworks离线同步时，源端es，对端也是es出现了上述脏数据是为什么datawork这个地方的错误信息我要看到全部 怎么看啊？datawork数据集成的时候想把数据库中除某个字段外其他的值更新了，怎么写啊 bi连接dataworks数据源 问一下生产环境 这块咋开启呀 我现在有表的权限都授予了 但是还是无法同步datawork请问执行sql时报错quota not enough,请问是什么问题datawork这个同步任务为什么会空指针啊datawork要删掉一个数据集成，但是这个数据集成里面也找不到这个数据集成，里面生成的表已经被删掉了，然后生产环境里面找不到这个数据集成，但是大数据局那边有这个数据集成说是失败，那这个数据集成要怎么彻底从生产环境删掉呢dataworks有可以在工作空间设置全局变量的地方吗？dataworks动态阈值监控规则是15天才能触发嘛？dataworks中导入本地数据的时候预览都正常，正式导入报这个错是为什么？dataworks中数据源配置备库，并且数据集成使用独享资源组，为什么还会走主库？hologresholo查询耗时突然增加了是怎么回事？问下jdbc写入holo 有什么方式能提高写入效率吗？holo的向量化执行这块都在哪些地方使用了simd指令了啊，这个有文档介绍吗其他请问一下数据集成elasticsearch数据配置时间过滤，读取不到数据，是我配置的哪里有问题吗，配置条件过滤是可以读取出数据的pyodps报错，怎么回事呀实时同步数据到odps后，当天的分区数据只能第二天看到？ 如何同步opds 表数据 同步到 阿里elasticsearch请问如果我同步的hive表是分区表，分区字段是insert date，在配置离线同步界面应该怎么弄呀？这样好像不太对quick BI链接数据源能查看所有的表，是什么原因呢 datahub往maxcompute用Connector同步数据 为啥自动生成了一个rowkey得列odps同步到mysql脏数据报错，因为底层数据包含表情符号，但mysql的库表字段字符集都改成utf8mb4了，现在要怎么操作呢请问一下集群id和emr实例id怎么获取到？？？怎么编写任务 有demo吗？简单模式，授权给用户开发角色后，这个用户删除表报权限不足，该如何处理通过向导模式配置离线同步任务和通过向导模式配置离线同步任务2.0看哪个？数据集成连接达梦数据库，但数据集成不支持向导模式，哪位大佬帮我看看这个josn是啥意思有一个问题咨询一下 是不是行式存储 一般都建议用clustering key ，这个可以用2列字段如果我还有第三个字段要设置索引，这个时候你建议怎么做？请问这是什么原因？？问下我一次性任务会出现调度呢？我想用insert_date字段作为我的分区信息，这样配置对吗？之前配置一个实时同步数据库到Kafka的任务，开发和生产都会同步，为什么改了？数据保护伞中，数据发现界面，查询条件中如何添加其他项目空间执行补数据任务空跑是什么原因业务分类下面是可以关联数据域和数据集市的，创建数据集市的时候可以选择关联的业务分类。而创建数据域的时候无法选择关联的业务分类是啥原因啊？请问大家，天ds，小时hh，周和月分区是如何命名的？我使用数据实时同步的时候发现有个字段在库里有值但是拉取后就没有了请问这个是什么情况呀？数据集成界面怎么又变动变为了这种形式我可以自定义格式化吗脚本中有个变量的，，现在单独放在资源组里面，赋值节点调用的时候能传参进去吗为啥返回Null?用keyvalue函数请问API怎么实现不通单位获取数据的权限控制啊打算一个项目一个项目切，新项目划出CU了 但是必须把老项目都换个资源组吗？ 麻烦问下rowdata怎么转成string或者json
-
提交了问题
2022-11-21
【藏经阁一起读（38）】读《阿里云存储产品手册》，你有哪些心得？
-
提交了问题
2022-11-18
乘风问答官工作及权益细则介绍
-
提交了问题
2022-11-18
问答最高荣誉，乘风问答官招募中！每周积分活动、每月排位赛等权益专享！
-
发表了文章 2022-11-16
话费兑换券指南
话费兑换券使用说明：1、持16位券码在兑换中心进行兑换。兑换中心地址：https://kaquanmall.fulu.com/?codeid=A8jLQmjf2、兑换步骤：输入验证兑换码-输入充值账号（仅限手机号），点击“立即兑换”进行充值。3、到账时间：1-60分钟。4、到账查询：各大运营商APP或直接拨打各运营商客服电话进行查询。5、特殊说明：(1)请注意填写正确的号码进行充值，一经充值成功无法退换。(2)各地区运营商维护过程中可能会导致充值失败，届时请保存好券码，在其他时间段进行兑换。(3)空号、携号转网、虚拟号、运营商后付、铁通、小灵通和特殊号段(191、166、167、170、171、175、179、188等）无法充值。(4)手机号被运营商标为异常状态无法充值。(5)如遇超过30分钟充值未到账等特殊情况，可联系客服进行处理。有效期至2023年10月31日，请在有效期内兑换使用。
-
提交了问题
2022-11-16
我们需要怎样的人工智能？
-
发表了文章 2022-11-15
一次中稿10篇EMNLP22，达摩院对话智能团队在研究什么
作者 | 郁博文、戴音培、郎皓、蔡泽枫、高畅、傅浩敏、张业勤、赵英秀、刘澈、惠彬原、林廷恩、马文涛、曹荣禹、余海洋、黄非、李永彬来源 | 阿里开发者公众号近日，自然语言处理领域的国际顶级会议EMNLP 2022录用结果出炉，达摩院Conversational AI团队10篇论文被EMNLP 2022录用，围绕着任务型对话、表格型对话、文档型对话、多模态对话、以及对话终身学习和对话表示学习等前沿方向全面开花。本文对这10篇论文的内容进行系统介绍，以此来总结达摩院Conversational AI团队面向对话智能前沿研究的思考和进展。一、任务型对话任务型对话主要指为满足用户某一目标需求而产生的多轮对话，面向垂直领域，帮助用户完成预定任务或动作， 例如预定机票、查询公积金等。当前任务型对话领域的研究缺乏面向真实人机对话系统的评测数据集，并且大多数研究工作在在封闭世界的假设下开展，在实际应用中并不成立。针对这两个问题，我们从更真实的数据集，和Out-of-Domain检测两个角度展开研究。A Large-Scale Benchmark for Chinese Goal-oriented Dialog EvaluationYinpei Dai, Wanwei He, Bowen Li, Yuchuan Wu, Zheng Cao, Zhongqi An, Jian Sun and Yongbin Li真实的人机对话系统面临着多样化的知识来源（如实体知识、预定义任务流和QA语料库等）和带噪的用户问题（用户语音提问在转话为文本过程中存在噪声）等挑战，然而目前的任务型对话数据集未能全面考虑这些问题。因此我们提出了首个大规模的中文任务型对话评估数据集CGoDial (Chinese Goal-Oriented Dialog)。CGoDial共计包含了96,763个对话，574,949轮次的对话内容，覆盖了以下3种主流的任务型对话类型：1. 填槽式对话（Slot-based Dialog, SBD)，即系统一般通过多轮交互获得实体属性并将合适实体告知给用户。我们在已有中文数据集RiSAWOZ的基础上进行改造，引入了基于QA pairs的外部知识、Out-of-scope的用户表述以及口语化噪音来从而得到SBD数据集； 2. 流程式对话（Flow-based Dialog, FBD)，即系统一般根据一个树形结构的对话流来引导用户完成目标任务。我们构建了首个中文基于Flow的对话数据集，包含住保、交管、政务和高速收费4种场景37个domain，共计6786个对话2.6万轮次； 3. 检索式对话(Retrieval-based Dialog, RBD)， 即系统根据用户问题在一个QA语料库中检索出对应回复。我们基于已有的淘宝电商对话数据集E-commerce Dilaog Corpus进行筛选和口语化特征改造，构建了RBD数据集； 上述三类数据集示例如下：在基线模型上，我们除了基于Chinese-T5，CDial-GPT等中文预训练模型提供了基线效果，还基于UniLM架构和1亿的论坛对话语料预训练了一个预训练对话模型，提供了更具有竞争力的基线。相关的数据集和代码均会在近期开源，以推进中文领域任务对话技术的发展。Estimating Soft Labels for Out-of-Domain Intent DetectionHao Lang,Yinhe Zheng,Jian Sun,Fei Huang,Luo Si,Yongbin Li意图识别(intent detection)是任务型对话系统的重要能力。目前，大多数方法在封闭世界的假设下(closed-world assumption)都取得了较好的效果，即数据是静态的，且只考虑一个固定的意图集合。然而，这样的假设在实际应用中并不成立。我们通常会面对一个开放的世界(open-world)，即未经过训练的未知意图可能在测试阶段出现。因此，我们需要赋予对话系统Out-of-Domain(OOD) 检测的能力，使之既可以正确分类出已知In-Domain(ID)的意图，又可以检测出未知OOD意图。OOD检测的一个主要技术挑战是缺点足够的OOD样本。在大多数应用中，在训练阶段从测试分布(test distribution)采样并标注OOD样本都是非常困难的。针对该问题，研究者提出了在训练阶段生成伪OOD样本的各种方法。主流的方法包括：1）Phrase Distortion，即对ID样本中的短语做选择性的扰动和替换；2）Feature mixup，即通过对ID样本的特征做混合生成OOD特征样本；3）Latent generation，即从ID样本的低密度空间(low-density area)采样OOD样本。这些方法的一个共同缺陷是都赋予生成的伪OOD样本one-hot硬标签，即完全属于OOD未知意图类别。然后，对于模型训练最有价值的OOD样本是一些“难”的OOD样本，即与ID样本分布最接近的一些OOD样本。我们注意到“难”OOD样本可能含有已知ID意图。因此，one-hot硬标签的设定会导致伪OOD样本与ID样本有交叉，导致训练效果下降。我们认为伪OOD样本的理想标签应该是软标签(soft labels)，即赋予所有的意图类别都是非零概率(non-zero probabilities)。基于平滑假设(smoothness assumption)，即空间中相邻的样本拥有相似的标签，我们计算伪OOD样本的软标签。具体地，我们先基于图平滑(graph-based smoothing)算法得到初始软标签，然后基于co-training优化算法进一步优化它们的软标签。实验表明，基于软标签的伪OOD生成算法在三个标准数据集都取得了新SOTA结果。二、表格型对话表格（Table）被广泛应用于存储和展示结构化数据。而表格的语义解析技术（Text-To-SQL）近些年来得到了学术界和工业界的广泛关注，其目的是在多轮交互（对话）中，围绕表格 / 数据库等二维结构化知识，自动地将用户的自然语言问句转换为 SQL 语句，执行后得到目标信息，从而大幅提升与数据库交互的效率和体验。Text-To-SQL模型需要一方面具备对用户提出的自然语言问句的精准理解，另一方面具备在结构化表格中根据需求查找答案的精准推理。然而在实际应用场景中，Text-To-SQL模型会遇到多种多样的用户问句，需要模型具有较强的的泛化能力和鲁棒性。面向这一挑战，我们从模型预训练和模型微调策略两方面展开研究STAR: SQL Guided Pre-Training for Context-dependent Text-to-SQL ParsingZefeng Cai, Xiangyu Li, Binyuan Hui, Min Yang, Bowen Li, Binhua Li, Zheng Cao, Weijie Li, Fei Huang, Luo Si and Yongbin Li预训练模型最近几年在 NLP 的各种任务上大放异彩，但由于表格和自然语言之间内在的差异性，普通的预训练语言模型 （PLM，e.g. BERT) 在该任务上无法达到最优的性能 ，所以面向对话式语义解析的预训练表格模型（TaLM）应运而生。预训练表格模型（TaLM）需要处理两个核心问题，包括如何利用上下文 query 复杂依赖（指代、意图偏移）及如何有效利用历史生成的 SQL 结果。对此，我们提出了两个预训练目标: (1) 对于上下文 query 利用，提出了基于 SQL 相似度的对比学习任务 UDT (Utterance Dependency Tracking），我们的关键动机在于，类似的 SQL 对应的 query 在语义上更具相关性，因为 SQL 可以看作用户意图的高度结构化表示；(2) 对于上下文 SQL 问题，直接将 SQL 拼接到模型的输入容易引发长度、非语言等性问题，我们借助 SQL 定义 schema 在每一轮的具体状态（扮演什么样的关键词角色），提出了 SST (Schema State Tracking) 任务，最终利用类似状态追踪的想法进行训练。这两个任务都依赖 SQL 的引导，共同完成上下文的复杂建模，所以我们将最终的模型命名为 STAR: SQL Guided Pre-Training for Context-dependent Text-to-SQL Parsing。我们在对话式语义解析的权威 benchmark SParC 和 CoSQL 上进行了评估，在公平的下游模型对比下，STAR 相比之前最好的预训练表格模型 SCoRe，SParC 数据集 QM / IM 提升 4.6 / 3.3%，CoSQL 数据集 IM 显著提升 7.4% / 8.5%，而 CoSQL 相比 SParC 数据集，拥有更多的上下文变化，验证了我们提出的预训练任务的有效性。截至目前，STAR 仍然是两个榜单的 rank 1。Towards Generalizable and Robust Text-to-SQL ParsingChang Gao, Bowen Li, Wenxuan Zhang, Wai Lam, Binhua Li, Fei Huang, Luo Si and Yongbin Li除了模型预训练，我们还希望在模型微调阶段增强模型的鲁棒性。为此，我们提出一种让模型学习从简单到复杂的范式，称为TKK框架，它主要包含三个阶段：任务拆解、知识获取和知识组合（Task decomposition & Knowledge acquisition & Knowledge composition），这模仿了人类学习处理Text-To-SQL任务的过程。模型框架如图所示。在任务分解阶段，TKK将原始任务分解为多个子任务。每个子任务对应于将自然语言问题映射到SQL查询的一个或多个子句，这些任务包括SELECT、FROM、WHERE等子任务。之后，TKK采用基于提示词的学习策略，分别获取子任务的知识，并利用所学知识处理主要任务，即生成整个SQL查询。在知识获取阶段，TKK以多任务学习方式训练包含所有子任务的模型；在知识组合阶段，TKK模型在主任务上进行微调，以组合获得的子任务知识并学习它们之间的依赖关系。通过将Text-To-SQL的学习过程拆解成多个阶段，我们的框架提升了模型获取通用SQL知识的能力，而不是仅仅学习简单的模式，从而使得模型具有更强的泛化能力和鲁棒性。为了验证我们提出的TKK模型的泛化能力，我们在公开的三个Text-To-SQL数据集，Spider、SparC和CoSQL上进行实验，均获得了当时的SOTA结果，分别为75.6、66.6和58.3。另一方面，为了验证TKK模型的鲁棒性，我们在增加噪音的Spider-Syn和Spider-Realistic数据集上进行实验，相比于T5-3B模型，TKK模型分别提升2.6（59.4->63.0）和5.3（63.2->68.5）个百分点。总而言之，我们为了提升Text-To-SQL模型的泛化能力和鲁棒性，提出了一种包括任务拆解、知识获取和知识组合的三阶段框架，并且通过实验验证了该框架的有效性。三、文档型对话现代企业与组织在其日常经营活动中会产生大量的文档数据，它们通常都有着巨大的价值。当前，多数企业与组织仍在利用搜索引擎从这些文档中获取信息，这不仅要求用户给出较为精确的检索关键字而且很难处理某些复杂而抽象的信息查询请求。于是，越来越多的研究开始面向文档对话系统（document-grounded dialog system），它期望通过对话的方式来交互式的从文档中获取知识。Towards Generalized Open Information ExtractionBowen Yu, Zhenyu Zhang, Jingyang Li, Haiyang Yu, Tingwen Liu, Jian Sun, Yongbin Li, Bin Wang开放信息抽取（OpenIE）希望从任意领域的文本中抽取不限定关系类型的三元组类知识，采用原始文本中的片段作为头实体、关系短语和尾实体，这样的开放知识能够在文档问答等知识问答任务中发挥重要价值。然而，当前OpenIE领域的工作往往采用独立同分布的评测方式，即训练集和测试集来源于分布类似的领域，这无疑违背了OpenIE希望从任意领域进行有效抽取的初衷。为此，我们首先人工标注了一个大规模多领域的OpenIE测试集 GLOBE，包含来自保险、教育、医疗等6个领域的两万多个句子，采用和当前最大的人工标注OpenIE数据集SAOKE相同的标注规范。在此基础上，我们构建了一个更贴近真实的OpenIE评测范式：在SAOKE上训练，在GLOBE上测试。先期实验发现，当前的SOTA OpenIE模型在新的评测范式下会出现高达70%的性能损失。进一步分析发现，SOTA模型需要构建包含O(n^2)条连边的图来表示包含n个片段的开放知识，任何一条连边错误都会导致错误的抽取结果，所以在领域变化导致抽取能力下降时不鲁棒。因此我们提出了一个图上最简的OpenIE表达形式：将开放知识表达成为有向无环图，复杂度由O(n^2)降低到了O(n)。实验结果表明，在原始的独立同分布评测范式下，本文提出的方法取得了3.6pt的性能提升。在新的out-of-domain评测范式下，性能提升进一步增加到了6.0pt，并且仅用10%的训练数据就可以获得和之前SOTA模型类似的效果。Doc2Bot: Accessing Heterogeneous Documents via Conversational BotsHaomin Fu, Yeqin Zhang, Haiyang Yu, Jian Sun, Fei Huang, Luo Si, Yongbin Li, Cam Tu Nguyen现有的文档对话数据集主要关注文档中包含的纯文本内容，而忽略了文档中常见的标题，序号和表格等结构信息对于机器理解文档内容的重要性。因此，本文提出了一个中文大规模多领域文档对话数据集Doc2Bot。该数据集包括保险，医疗和科技等五个领域的10余万轮对话和与这些对话相对应的1500余份文档。该数据集不仅标注了每轮对话相应的对话状态和对话动作，还给出了结构化表示的文档数据。因此Doc2Bot数据集能够为对话状态追踪、对话策略学习以及回复生成提供全链路数据支持。针对以上三个任务，本文以常用的大规模预训练模型为基础，在Doc2Bot数据集上开展了若干实验。实验结果表明，对话状态信息和结构信息能够为对话策略学习任务分别带来约 8.5pt 和 10.3pt 的性能提升。同时，对话动作信息则能为回复生成任务带来约 1.3pt 的性能提升。这一结果说明了文档中存在的结构信息与对话状态信息一样，都对文档对话系统有着不容忽视的重要作用。上图提供了一个文档对话数据示例。左侧为包含异质结构的文档，右侧为对话内容，其中U和A分别代表用户发言和系统发言。该对话可被自上而下地分为四个分段（以不同颜色标明），每个分段的对话分别对应了左侧 N1-4 的四个文档分段。四、多模态对话人们在日常对话的过程中，不仅依赖文字本身，还需要依赖人类的视觉信息和听觉信息，帮助理解对方的情绪、状态以及真实想要表达的意图，通过同时捕捉语言(文本)与非语言(声学, 视觉)等不同输入模态的特征，使得机器能够做出更准确的预测。多模态情感分析（MSA）与对话情绪识别（ERC）是多模态对话中的重要课题。然而，现有工作将情感与情绪分开研究，忽略了两者间的相似性和互补性。从心理学的角度来看：（1）情感与情绪有相似的表达形式，例如情感-积极与情绪-高兴；（2）情感与情绪是互补的，情绪是一个人在短期内的感受或感觉的表达，而情感通常是经过长期所形成的。基于上述动机，我们提出了多模态情感知识共享框架 UniMSE，通过生成模型将 MSA 和 ERC 任务从模型架构、输入特征、到输出标签进行了统一。我们在句法和语义层面进行模态融合，并在模态和样本之间引入对比学习，以更好地捕捉情感和情绪之间的一致性和差异性。我们在多模态情感分析 MOSI、MOSEI 和对话情绪识别 MELD、IEMOCAP 等四个多模态数据集上进行实验；结果表明，我们所提出的 UniMSE 方法在四个数据集上皆取得了当前的最佳效果，与最先进方法相比取得了一致性的提升，证明了所提出方法的有效性，也为多模态情感研究开拓了新的研究方向。五、对话系统的终身学习前面介绍的对话系统都是在数据分布保持不变的假设下开发的。然而，当实际应用中部署的对话系统需要根据用户需求支持新的功能并提供更多服务时，重新训练整个系统会消耗过多的时间和计算资源。因而，构建具有终身学习能力的对话系统至关重要，即模型能够保留之前学习过的知识的同时不断地获取新知识。当模型序列化地学习具有不同数据分布的多个任务时，会遭受较为严重的灾难性遗忘问题，即模型无法维持旧任务的性能（遗忘了旧任务学到的知识）。面向这一问题，我们从改善生成重放方法，和更充分地利用无标数据两个角度展开研究。Prompt Conditioned VAE: Enhancing Generative Replay for Lifelong Learning in Task-Oriented DialogueYingxiu Zhao, Yinhe Zheng, Zhiliang Tian, Chang Gao, Bowen Yu, Haiyang Yu, Yongbin Li, Jian Sun and Nevin L. Zhang生成重放方法是终身学习中解决灾难性遗忘问题的经典方法。在此方法中，模型通过生成旧任务的伪样本来近似旧任务的数据分布，并将生成的伪样本跟新任务的样本混合训练来避免遗忘。然而，大多数现有的生成重放方法仅使用单个任务特定的标记来控制其模型生成。然而由于这种标记中包含的信息不足，该方案通常不足以约束模型来生成质量高的伪样本。为此，我们设计了“基于提示的条件变分自编码器”，结合不同任务的统计信息来增强生成重放。具体来说，模型是用条件变分自动编码器捕获任务特定的分布，以自然语言提示为条件来指导伪样本生成。此外，它利用知识蒸馏来减轻伪样本中的噪声，从而进一步巩固过去的知识。我们在对话系统的自然语言理解任务（意图检测，槽值填充）进行了充分的实验验证，结果表明我们所提出的方法生成了更高质量的伪样本，并有效缓解了灾难性遗忘的问题。Semi-Supervised Lifelong Language LearningYingxiu Zhao, Yinhe Zheng, Bowen Yu, Zhiliang Tian, Dongkyu Lee, Haiyang Yu, Jian Sun, Yongbin Li and Nevin L. Zhang现有的自然语言领域的终身学习方法只关注于有监督的学习环境，而在现实世界的场景中，有标数据通常是昂贵且耗时的，无标数据却数量众多，容易收集，并携带着丰富的语义信息。在本文中，我们探索了一种新的设定，即半监督终身语言学习，其中每个顺序到达的语言任务都带有少量的标记数据和大量的无标数据。我们提出了一种无标数据增强的终身学习者来探索此设定。具体来说，我们为每个任务分配特定的参数来避免模型学习新任务时对旧任务所学过的参数造成干扰，从而缓解灾难性遗忘的问题。除此之外，该设定下存在两个挑战：(1)如何充分利用无标数据来提升每个到来的语言任务？(2) 如何利用无标数据来鼓励知识迁移到以前学习过的任务？我们设计了两个模块来应对：（1）我们在老师-学生框架上构建了用虚拟监督信号来增强的任务求解器，以挖掘每个任务无标数据中的潜在知识；(2) 我们建立了后向增强的学习器以鼓励知识从新到达任务的无标数据迁移到之前学习过的任务中。在此半监督持续学习的设定下，我们开展了的两种维度的实验(任务属于同一类别但是不同领域和不同类别的多个任务)，实验结果和详尽的分析充分证明了我们的模型有效性和优越性。六、对话表示学习在实际上线的对话系统中，不仅需要各类的对话服务，还需要以对话为中心的辅助功能，比如面向海量无标注对话的检索、聚类等，而这样的功能实现离不开对话语义理解。dial2vec: Self-Guided Contrastive Learning of Unsupervised Dialogue Embeddings Che Liu, Rui Wang, Junfeng Jiang, Yongbin Li and Fei Huang对话嵌入（dialogue embedding）任务的目标是将一段完整的对话映射为一个高维度的语义向量，对于对话级的语义理解至关重要，但相关研究甚少。我们首次提出无监督对话嵌入任务。首先收集了包括BiTod、Doc2dial、MetalWOZ、MultiWoz、SGD、Self-dialogue在内的6个具有代表性的对话数据集，并利用它们数据集本身所提供的对话标签（如类别标签）来为每个数据集分别构建了聚类、对话检索、对话语义相似性排序三个评估任务。紧接着，我们评测了多种可以应用于无监督对话嵌入的方法，如非深度学习方法（LDA）、向量池化方法（GloVe、Doc2Vec、SimCSE、DialogueCSE）、预训练语言模型（BERT、RoBERTa、T5）和对话式预训练语言模型（TOD-BERT、PLATO、BLENDER）。结果表明，由于这些方法或多或少忽略了发言者级别之间的语义交互，因此导致它们提供的对话向量的表现不够理想。因此，我们进一步提出dial2vec模型，来充分挖掘对话中蕴含的发言者级别的语义交互信息。dial2vec将一通对话视为一次发言者之间的信息交互过程，通过捕获发言者之间的语义交互模式，dial2vec以自我引导式的方式分别优化每个发言者的语义表示，最终将所有发言者的语义信息聚合后得到整通对话的嵌入表示。作为一种dialogue embedding的框架，dial2vec可以以任何预训练语言模型或对话式预训练语言模型作为底座来实现，且均能够取得显著的效果提升。在我们的实验中，我们发现使用PLATO作为底座能够取得最好的表现。这种设置下，dial2vec在聚类、对话检索、对话语义相似性三个任务的purity、Spearman's correlation、MAP指标上分别取得相比最强基线9.4pp、10.6pp和16.1pp的提升。进一步实验证明，在会话交互信息的指导下，dial2vec为每个发言者都学习到了信息丰富和具有区分度的对话语义表示。我们也研究了多发言者之间的语义融合策略，并提出了发言者级池化（interlocutor-level pooling）策略。这种策略能够进一步平衡各发言者的语义信息比例，并使得多发言者语义信息融合时取得超过直接进行平均池化的效果。总结总的来说，在数据资源方面，Conversational AI团队在这次EMNLP会议中贡献了首个大规模的中文任务型对话评估数据集、首个多领域开放信息抽取泛化性评估数据集、首个带有文档结构信息的文档型对话数据集；在模型设计方面，Conversational AI团队重点关注对话模型的鲁棒性和持续学习能力，希望增强线上业务模型的效果，并在任务型对话、表格型对话、文档型对话等任务中展开了探索；此外，Conversational AI团队还积极探索了智能对话中的新任务，如多模态情感分析与对话情绪识别，和自监督对话表示学习，扩展了智能对话的研究领域。达摩院Conversational AI团队负责人李永彬表示，一方面研究要有长期主义精神，该团队从2014年开始做人机对话的研究和落地，已经在这个方向上深耕了8年多时间；另一方面研究要从业务中来再到业务中去，作为创始算法团队，打造了目前国内智能客服市场份额第一的阿里云智能客服。面向未来，团队将继续致力于打造有智商、有情商、可持续、多模态的类人对话系统，实现文本、音频、图像、视频多模态的全场景对话，并能在业务落地中持续进化。
-
发表了文章 2022-11-15
第2期乘风伯乐奖--寻找百位乘风者伯乐，邀请新博主入驻即可获奖
什么是乘风伯乐奖？善于发现、挖掘并推荐优秀博主的乘风者们，都是社区的乘风者伯乐！如果你身边有技术大神、写作达人以及乐于分享的人，请重点关注本次活动！只要你是已入驻阿里云开发者社区的乘风者，即日起邀请身边的朋友、同事一起加入乘风者计划并成为阿里云开发者社区的新入驻博主，邀请人数前100位即可获得乘风者伯乐奖！参与活动能获得什么？1、伯乐礼遇：本期活动面向阿里云开发者社区寻找100位乘风者伯乐，邀请人数前100名的伯乐根据受邀入驻成功的用户数量领取相对应的礼品。礼品领取规则如下：邀请人数礼品样图1-4人无绳跳绳5-14人电脑支架15及以上小米椅背靠垫月度TOP者（需邀请人数大于30人）cherry机械键盘MX3.0s+荣誉证书*奖品不可叠加获得。*表中“邀请人数”为领取对应奖励的最低邀请人数，如邀请人数为15人及以上可领取小米椅背靠垫。2、受邀入驻博主的乘风者权益：未入驻乘风者计划的用户在收到邀请后，需在阿里云开发者社区发布3篇原创技术文章或1个视频创作后填写技术博主入驻申请表，成为社区乘风者新入驻博主。根据乘风者计划解锁不同等级，可获取对应奖品和权益，收获更多福利！具体权益如下：技术博主：虚拟徽章+乘风者定制手机支架+云产品权益 星级博主：虚拟勋章+阿里云限量版云小宝手办+云产品权益 专家博主：专家博主证书+阿里云定制保温杯+云产品升级版权益+个人影响力打造详细信息请点击了解“乘风者计划”:https://developer.aliyun.com/topic/bloggers如何参与活动？Step 1：邀请您身边拥有原创技术内容的人（非乘风者计划博主）加入阿里云开发者社区乘风者计划。Step 2：邀请受邀人员在社区发文3篇或创作视频1个，并提交乘风者计划入驻申请表单，满足乘风者入驻条件（即发文量达到标准），则视为邀请成功。乘风者计划技术博主入驻申请表：https://survey.aliyun.com/apps/zhiliao/LFF0Fd3tXStep 3：邀请成功后填写“乘风伯乐奖申请表”，用于邀请人数统计与核对。https://survey.aliyun.com/apps/zhiliao/VwrpFdC-k❗❗❗活动说明：1、“乘风伯乐奖”活动面向阿里云开发者社区已入驻博主（技术/星级/专家）；受邀用户加入乘风者计划后视为邀请成功。所有新邀约用户提交乘风者入驻申请表的时间需在2022年11月1日-12月31日之间。2、本活动以表单提交的形式进行申请，伯乐所邀请的人数可按表单提交累加。邀请用户数以技术博主为单位计算，其中1位星级博主=3位技术博主；1位专家博主=6位技术博主。受邀用户等级以活动结束时状态进行统一核算。3、每位新人只可受邀1次，如有邀请同一人的情况，则按照表单提交先后顺序为准。开发者小助手在评论区公布每周参与情况。受邀用户成功入驻后，同等拥有成为“伯乐”的资格。4、若受邀用户发布文章位抄袭或者水文，将取消推荐博主活动资格。5、活动中的”天”、”工作日“等均指该日的0点至24点（北京时间）。6、阿里云可以根据活动的实际情况度该活动规则进行变动调整，相关变动或调整建公布在活动页面上。并于公布之日即时生效，但不影响用户在活动规则调整前已获得的权益。7、请加入乘风者计划3群：1925002766，了解更多信息。🥇邀请人数月度TOP者（需大于30人）可获得“乘风者伯乐TOP 1”荣誉证书以及cherry机械键盘一个，快快邀请身边的朋友加入阿里开发者社区乘风者计划吧！如有疑问可钉钉扫码进群交流沟通并了解活动实时进度！
-
发表了文章 2022-11-15
重磅报告发布，从102个开源大数据项目深度研究开源大数据技术发展！
开源大数据热力值是什么？热力变迁反应了哪些技术趋势？如何提升开源项目热力？ 11 月 5 日，在云栖大会一体化大数据智能峰会上，由开放原子开源基金会、X-lab 开放实验室和阿里巴巴开源委员会联合出品的《2022开源大数据热力报告》重磅发布！ 报告在线阅读：https://developer.aliyun.com/ebook/7816 《2022年开源大数据热力报告》由开放原子开源基金会、X-lab开放实验室和阿里巴巴开源委员会联合出品。报告基于公开数据研究最活跃的102个开源大数据项目，为读者们带来热力“摩尔定律”、热力图谱和三大热力趋势解读，让大家深入走进开源大数据热力的现在与未来。一张开源大数据热力图谱将多元化、一体化、云原生三大热力趋势可视化概括，热力跃迁逻辑研究、四大核心观点超全囊括，探寻出开源大数据技术发展背后的“摩尔定律”。 看完报告想进一步了解报告背后的开源项目？别急！11月17日19：00-20：00，锁定“阿里云开发者社区”。大数据专家为你直播详细解读 《2022年开源大数据热力报告》，讨论应如何提高开源开发者活跃度，提升开源项目热力。 本次直播特邀：赵生宇（X-lab开放实验室核心成员、开源社成员、同济大学计算机在读博士生、OpenDigger开源项目发起人）燕青（Apache Kyuubi PPMC、Apache Spark Committer、Apache Submarine Committer、网易技术专家）、赵恒（StarRocks PMC、StarRocks产品负责人）徐榜江（Flink CDC Maintainer、Apache Flink Committer、阿里云技术专家）、徐昱（StarRocks Active Contributor，Apache Hudi Contributor，华米科技高级大数据工程师 ） 五位技术专家将以热力值及报告结果为切入点，为开源开发者解读热力变迁的最新技术趋势，就热力跃迁逻辑研究结果深入探讨“如何提升开源项目热力”“开源社区该打造怎样的运作模式”等问题。相信通过本次直播，开源开发者能够对《2022年开源大数据热力报告》有更深入的理解，也能为开源项目做热力增速，把握未来。 直播链接在线观看：https://developer.aliyun.com/live/250672 快来抢先预约，一起探寻2022年开源大数据的技术世界！
-
提交了问题
2022-11-14
【藏经阁一起读（40）】读《PolarDB for PostgreSQL开源必读手册》，你有哪些心得
-
发表了文章 2022-11-14
《开发者评测局》之文档智能Document Mind评测征集令
📃文档智能：让每一份文档，都插上智慧的翅膀！🔗立即参与：https://developer.aliyun.com/mission/review/documentmind一、产品介绍文档智能（Document Mind），基于多年技术积累打造的多模态文档识别与理解引擎，为用户提供各类文档的结构化信息抽取和智能化文档处理。支持通用场景、行业场景和自定义场景下的多样化文档处理需求。目前已上线文档理解（文档智能解析、表格智能解析、文档抽取）以及文档格式转换（PDF转Word、图片转Word、PDF转Excel、图片转Excel、PDF转图片、图片转PDF）等多种能力。您可以在产品控制台可视化页面上传文档进行试用，也可以通过API接口进行调用。二、评测要求如果您在产品体验中有任何疑问，请进答疑钉群：448542171、活动时间：2022年11月11日-12月31日（获奖名单将于1月初公布）2、评测内容：通过使用文档智能（Document Mind）产品进行体验，您的测评可以选择以下三大主题中的一个或者多个进行创作：1、文档智能产品最佳实践测评，可以包括但不限于以下内容：（1）结合相关文档智能服务，对你实际使用的文档处理场景（如国际物流单证、销售合同、财务报表、业务表单、产品说明书、招标公告、金融文档、法律文书、采购订单等）进行落地实践。（2）文档智能服务在应用场景支撑和业务流程接入等方面，跟其他实现方案的比较（比如使用人工处理、采用传统OCR技术或者其他智能文档处理服务）。（3）文档智能服务作为数字化生产力工具，您或公司希望用来解决什么方面问题？2、文档智能产品体验评测，可以包括但不限于以下内容：（1）在体验过程中是否得到足的产品内引导以及文档帮助？如果没有，还欠缺什么部分？（2）产品功能是否满足预期？（接入便捷性、查询性能、看板创建门槛、其他功能等方面）（3）针对业务场景，您觉得该产品还有哪些可以改进的地方，或更多希望完善的功能？（4）您认为文档智能产品是否有与其他产品联动组合的可能？（列举其他产品）3、文档智能产品对比测评，可以包括但不限于以下内容：（1）是否有用过其他智能文档处理工具（商业或开源）？你觉得使用文档智能在满足业务需求时，不限于功能性能、算法效果、场景覆盖等方面，好的地方是什么，有待改进的地方是什么？三、活动奖品：1、活动期间，发布有效字数在100字以上测评且审核通过的原创用户，均可获得50积分奖励，每人最多可获得150积分奖励2、活动期间，前30位发布有效字数100字以上且审核通过的原创用户，可获得达摩院纪念折扇+文档智能新品优先试用权益。3、活动期间，前10位发布有效字数500字以上且审核通过的原创用户，可获得达摩院手机支架+文档智能新品优先试用权益。4、活动结束时，主办方将从投稿文章中选出1篇最优评测（评选要求：字数500字以上，图文结合，内容充实、有新意），送出一个AirPods 2。注意事项：文档智能官网或者是帮助文档复制内容为无效测评内容，我们真诚地期待您的反馈！活动入口：https://developer.aliyun.com/mission/review/documentmind快来试用文档智能，写下你的使用感受，就有机会获得🎧AirPods 2、手机支架、纪念折扇、文档智能新品优先试用权益等多重好礼！
-
发表了文章 2022-11-14
2022年语言和框架我们值得关注什么？
作者 | 蒲松洋-秦粤来源 | 阿里开发者公众号大家好，我是秦粤。最近我其实收到了很多朋友的疑问，面对层出不穷、不断个性的语言和框架，到底应该关注什么？恰好今年我又是第十七届 D2 大会「语言与框架专场」的出品人，想和大家聊下这个问题。我在做出品人之前，特别好奇 D2 每年那些对技术发展的预判是怎么做出来的？例如 React，Vue，Serverless 等等话题。不知道你会不会也好奇，D2 每年的内容是如何产生的？筛选机制是什么？这背后，也反映着着行业的变革和技术的趋势......大家在关注什么？我是 2019 年第一次做 D2 的出品人，D2 的前身「前端技术论坛」已经举办了 16 届，相信有很多前端同学对它已经非常了解了。2022 年，结合阿里巴巴的前端和客户端融合的趋势，D2 今年也升级为了终端技术大会。而今年 D2 也是我第三次做语言与框架出品人。过去两届 D2 我从会后在知乎和一些前端同学笔记中，可以看到不少同学还是能 get 到我的用意的：语言与框架专场上，主要在引入函数式编程和数据驱动，此外也是想让前端开发者对我们前端依赖的基础设施--浏览器和 JavaScript 生态有所感知。这是因为我所接触的大多数前端工程师，都以业务需求和应用开发为主。大多数时候都是在卷前端开发效能，不停的在应用层研究提速轮子。我就在想有没有另外的一些可能：例如像 Rescript 那样创建一门前端语言，从语言层面改变前端开发的生态，或者 RxJS 那样的函数式开发框架，通过函数式编程解决前端开发引入的“副作用”？今年 D2 转变到终端 D2 的大会，加入了客户端的同学，“客户端”在我映象中最近几年好像并没有特别新的技术，至少我的认知还在 Swift 和 Kotlin 上面。当我跟几个阿里的客户端同学沟通了一下，发现大家的认知是一致的，因为 Swift 和 Kotlin 都远远还没有到普及的地步。我也在想，我们今年 D2 是不是可以多讲一些成熟的语言和框架，讲讲 Product Ready 的技术。我在做 D2 的话题选择或每年的技术推衍时，经常会参考 2 个资料：Gartner 的《技术成熟度曲线》和 ThoughtWorks 的《技术雷达》。技术成熟度曲线实际上，的确很多新兴技术没有到普及就被抛弃了，Gartner 每年都在做的技术成熟度曲线(需付费咨询)，预言了每门技术的发展规律：诞生的促动期，期望膨胀峰值期，泡沫破灭谷底期，稳步爬升光明期，实质生产的高原期。新兴技术前期在任何一个时期都可能夭折消失，而只有生态健壮的和市场认可的技术才能一直走到高原期，持续推进延续它的生命。thoughtworks 的技术雷达(免费下载链接见文末)，也会圈出每年新晋的技术和移入移出的技术。技术雷达是通过推荐你是否采纳到生产环境的维度考虑的。因此今年终端 D2，除了那些新兴的促动期，还在全栈疯狂 hype 的技术，我们也会引入一些日趋成熟（稳定高原期）的技术。2022年语言和框架我们值得关注什么？今年我们最大的感受就是寒气逼人，不过越是低谷期，越应该调整心态，通过积极学习去积攒实力。做技术的优势就是确定性比较高，即使市场再动荡，但是底层的很多基础是不变的。想起我 2020 年前端艺术家沙龙的一张 PPT，大家共勉。2022 年在前端开源社区依旧活跃。除了 QuickJS 外，还有前段时间充满争论的 bun.js，最近还有横空出世的 turbopack。跟前端生态不同的是，我所接触的客户端开发者，则普遍有种悲观情绪，感觉移动互联网的风潮已经过了，上升通道正在关闭。这点也是我们做终端人才融合一个初衷：客户端和前端工程师不应该是技术隔离的，而融合后应该是根据业务分层的：应用开发终端工程师和基础架构开发终端工程师。“T 字”型的结构：应用开发跟贴近业务，专注业务领域建模；基础架构开发贴近技术规范演进，用技术推进业务发展。所以今年我们 D2 语言与框架，准备引入的应用层 Product Ready 的内容有：Java 的函数式编程 Kotlin 和苹果的 Swift 最佳实践。Swift 和 Kotlin 发展到今天也已经是前后端通用的语言了，有各自的开发生态。对于客户端的同学也可以通过这些语言切换到后端服务开发。我一直秉持在云原生发展到今天，后端的服务架构早就已经与开发语言无关了，我们完全可以用自己熟悉的各种语言去做后端开发。掌握着 2 门语言的开发者也可以体验一波客户端 + 后端的全栈了，全栈工程师虽然近些年提的少了，但是全栈的视角更加通透，对于无论业务侧的问题和基础侧的问题，都有更多的解法和认知。基础架构层的课题有：NoSlate 框架和 turbopack。NoSlate 是新生代轻量化 Javascript 容器方案，由阿里 Midway 团队出品，让你单台服务器也可以秒变 Serverless。turbopack 比较出名了，最近 vercel 的 CEO 亲自案例，号称比 vite 快 10x，还引来的 evan 的讨论。终端可以看看 Rust 改造的又一案例，何如？当然以上这些内容还没有最终定稿，还在投票筛选中。同学们你如果有好的话题也欢迎投稿给我们。也可以对自己感兴趣，想听的上面内容进行留言投票。结尾听说寒气已经传递到大洋彼岸的硅谷了，这个时候更加适合调整好自己的心态，多多学习，积攒实力，抱团取暖。2022 年 D2 终端技术大会准备了 Node.js、Swift/Kotlin、前端工程、Flutter、JS/WASM 引擎、网络、AR/VR/3D、云渲染等前端 & 移动话题，如果你也想进一步了解或者更多的交流，点击这里报名D2，希望能与你在 D2 相遇。but anyway 都希望寒冬早点过去。我还是喜欢"盎格鲁•迅"那句：终端技术要发展，社区生态靠大家。thoughtworks 的技术雷达(免费下载)：https://www.thoughtworks.com/zh-cn/radar
2023年01月
-
01.18 17:41:19
发表了文章
2023-01-18 17:41:19
第3期乘风伯乐奖--寻找百位乘风者伯乐，邀请新博主入驻即可获奖
乘风伯乐奖，面向阿里云开发者社区已入驻乘风者计划的博主（技术/星级/专家），邀请用户入驻乘风者计划即可获得乘风者定制周边等实物奖励。本期面向阿里云开发者社区寻找100位乘风伯乐，邀请人数月度TOP者（大于30人）可获得Redmi Note 11 5G手机
-
01.18 14:34:52发表了文章
2023-01-18 14:34:52
系列征文3｜算法领域主题征文开始啦！
阿里云开发者社区推出“算法技术征文挑战赛”。现面向社区所有开发者征集算法领域技术文章，可以是对算法思想的剖析，也可以是前沿算法的探索，只要你有干货，那就分享出来！在活动规定时间内前往阿里云开发者社区发文，就有机会获得空气炸锅、社区积分等丰富奖励，参与即可获奖，快来参加吧！
-
01.18 10:58:11发表了文章
2023-01-18 10:58:11
创业之路的故事｜如何设计一个用户系统
创业之路的故事｜如何设计一个用户系统 -
01.16 11:03:12提交了问题
2023-01-16 11:03:12
-
01.16 10:27:57发表了文章
2023-01-16 10:27:57
参与智能语音交互产品评测，赢神秘好礼🎁
写下你的使用体验，就有机会获得Redmi小米投影仪、价值超万元的【听悟免费试用】权益、阿里云开发者社区定制冲锋衣、语音资源包0.1折权益、阿里云定制抱枕等多重好礼！
-
01.12 16:59:19发布了视频
2023-01-12 16:59:19
一秒变身！一键生成N次元虚拟卡通形象！
一秒变身！一键生成N次元虚拟卡通形象！
-
01.12 16:56:04发布了视频
2023-01-12 16:56:04
告别PS，一键抠图不是梦
告别PS，一键抠图不是梦
-
01.11 16:59:05发表了文章
2023-01-11 16:59:05
天猫超市·享淘卡兑换指南
天猫超市·享淘卡兑换指南 -
01.11 10:49:30发表了文章
2023-01-11 10:49:30
参与事件总线 EventBridge产品评测，赢神秘好礼🎁
写下你的使用体验，就有机会获得猫王复古音箱、520元云原生通用代金券、云小宝帆布包、30元猫超卡等多重好礼！
-
01.10 14:58:11发表了文章
2023-01-10 14:58:11
系列征文2｜后端领域主题征文开始啦！参与即有奖！
阿里云开发者社区推出“后端技术征文挑战赛”。现面向社区所有开发者征集后端领域技术文章，可以是语言框架的使用技巧，也可以是技术领域的趋势探讨，只要你有干货，那就分享出来！在活动规定时间内前往阿里云开发者社区发文，就有机会获得空气炸锅、社区积分等丰富奖励，参与即可获奖，快来参加吧！
-
01.09 17:10:58发表了文章
2023-01-09 17:10:58
一文梳理Code Review方法论与实践总结
作为卓越工程文化的一部分，Code Review其实一直在进行中，只是各团队根据自身情况张驰有度，松紧可能也不一，这里简单梳理一下CR的方法和团队实践。
-
01.09 16:03:03提交了问题
2023-01-09 16:03:03
-
01.09 10:34:47发表了文章
2023-01-09 10:34:47
【开发者7日学】求职达人训练营上线啦~快来打卡赢好礼
阿里云培训中心联合开发者社区推出求职达人训练营7天学习活动，由阿里师兄们围绕行业介绍、职业选择、职场经验等内容进行分享，帮助大学生快速了解真实职场环境、提升实用求职技巧、培养必备职业素养等。
-
01.06 21:37:33发表了文章
2023-01-06 21:37:33
开发者5日学【消息队列全家桶产品训练营】上线 快来 APP打卡赢积分
开发者社区上线开发者五日学活动，大家可以在阿里云APP上参与活动，5日学习每天都有积分奖励，快来参与吧~
-
01.06 17:42:46提交了问题
2023-01-06 17:42:46
-
01.06 16:51:51发表了文章
2023-01-06 16:51:51
【第二期乘风伯乐奖】获奖名单出炉，快来看看本期谁是社区伯乐！
第二期乘风伯乐奖名单出来啦！ -
01.06 16:51:13发表了文章
2023-01-06 16:51:13
前端领域主题征文获奖名单
前端领域主题征文获奖名单来啦 -
01.06 15:33:11发表了文章
2023-01-06 15:33:11
开发者社区每月重点内容推荐（2022-12）
开发者社区每月重点内容推荐（2022-12），涵盖本月技术动态、内容创新、干货书籍等内容，一文速览社区当月动态。
-
01.05 17:58:44发布了视频
2023-01-05 17:58:44
三分钟视频教你一键修复老照片 找回曾经的美好记忆
三分钟视频教你一键修复老照片 找回曾经的美好记忆
-
01.05 17:38:15发布了视频
2023-01-05 17:38:15
多模态问答模型带你实现高阶人机交流
多模态问答模型带你实现高阶人机交流
-
01.05 17:28:00发布了视频
2023-01-05 17:28:00
万物识别：教你一行代码通识万物
万物识别：教你一行代码通识万物
-
01.05 11:29:54提交了问题
2023-01-05 11:29:54
-
01.03 15:28:52提交了问题
2023-01-03 15:28:52
2022年12月
-
12.30 16:35:18提交了问题
2022-12-30 16:35:18
-
12.30 16:23:35提交了问题
2022-12-30 16:23:35
-
12.27 21:55:36发表了文章
2022-12-27 21:55:36
【讲讲训练营的故事】开始征集啦 参与就有奖 还有阿里云公仔等你来拿~
2022年，我们开办了百余期训练营，包括云产品训练营、企业实战训练营、技能认证训练营、开源产品训练营、求职就业训练营、高校训练营~
-
12.26 15:11:01提交了问题
2022-12-26 15:11:01
-
12.26 14:56:19发表了文章
2022-12-26 14:56:19
问答打赏详细规则
打赏是开发者社区在问答频道全新上线的功能，如果你认可他人的回复，可以给他人社区的积分作为鼓励获或认可哦。 -
12.26 10:34:11发表了文章
2022-12-26 10:34:11
2022藏经阁年度电子书榜单出炉！技术干货实战精华一手掌握！
阿里云开发者社区藏经阁，汇聚阿里工程师精华实战，累计上线400余本电子书，近8000份技术资料。上架至今，已有近200万次下载，1000万次阅读，20万人评论。点击直达https://developer.aliyun.com/ebook/
-
12.19 18:40:29提交了问题
2022-12-19 18:40:29
-
发表了文章
2023-01-18
第3期乘风伯乐奖--寻找百位乘风者伯乐，邀请新博主入驻即可获奖
-
发表了文章
2023-01-18
系列征文3｜算法领域主题征文开始啦！
-
发表了文章
2023-01-18
创业之路的故事｜如何设计一个用户系统
-
发表了文章
2023-01-16
参与智能语音交互产品评测，赢神秘好礼🎁
-
发表了文章
2023-01-11
天猫超市·享淘卡兑换指南
-
发表了文章
2023-01-11
参与事件总线 EventBridge产品评测，赢神秘好礼🎁
-
发表了文章
2023-01-10
系列征文2｜后端领域主题征文开始啦！参与即有奖！
-
发表了文章
2023-01-09
一文梳理Code Review方法论与实践总结
-
发表了文章
2023-01-09
【开发者7日学】求职达人训练营上线啦~快来打卡赢好礼
-
发表了文章
2023-01-06
开发者5日学【消息队列全家桶产品训练营】上线 快来 APP打卡赢积分
-
发表了文章
2023-01-06
【第二期乘风伯乐奖】获奖名单出炉，快来看看本期谁是社区伯乐！
-
发表了文章
2023-01-06
前端领域主题征文获奖名单
-
发表了文章
2023-01-06
开发者社区每月重点内容推荐（2022-12）
-
发表了文章
2022-12-27
【讲讲训练营的故事】开始征集啦 参与就有奖 还有阿里云公仔等你来拿~
-
发表了文章
2022-12-26
问答打赏详细规则
-
发表了文章
2022-12-26
2022藏经阁年度电子书榜单出炉！技术干货实战精华一手掌握！
-
发表了文章
2022-12-19
云栖精选第二弹：最全2022云栖大会内容大放送！为精彩技术打call！
-
发表了文章
2022-12-16
Flink+Hologres实时数仓在Lazada的建设及应用
-
发表了文章
2022-12-16
阿里云实时计算Flink版产品介绍
-
发表了文章
2022-12-16
从ELK到EFK 结合Flink 和 Elasticsearch新特性重构全观测方案
-
回答了问题
2023-01-18
社区有了这些新变化，邀你来反馈！
感谢各位开发者的悉心建议，本期活动恭喜穿过生命散发芬芳获得社区定制月相小夜灯；恭喜Carl_奕然、小周sir、不太对味、六月的雨在钉钉、刘天棋获得手机支架。 小夜灯将由社区助手进行发放；手机支架已通过话题打赏功能进行发放。请各位用户领取，逾期将视为主动放弃哦～
赞0 踩0 评论1 -
提交了问题
2023-01-16
百问求答（3）Flink专场！回答问题赢行李箱等好礼
-
回答了问题
2023-01-10
【新人帖】新人关于 PolarDB for PostgreSQL 备份恢复 的问题
亲您好，PolarDB产研团队近期正在更新和您提问相关的文档，产研团队整理好文档后会在此问题下回复亲，亲可以关注哦~
赞3 踩0 评论1 -
回答了问题
2023-01-09
【藏经阁一起读（43）】读《达摩院智能对话技术升级-更类人，更温暖》，你有哪些心得？
赞0 踩0 评论0 -
提交了问题
2023-01-09
【藏经阁一起读（43）】读《达摩院智能对话技术升级-更类人，更温暖》，你有哪些心得？
-
提交了问题
2023-01-06
社区有了这些新变化，邀你来反馈！
-
提交了问题
2023-01-05
是谁在帮助我们悄悄提高生产力？
-
回答了问题
2023-01-03
-
提交了问题
2023-01-03
【藏经阁一起读（42）】读《必致（BizDevOps）白皮书2022》，你有哪些心得？
-
提交了问题
2022-12-30
APP话题功能上线，发表你的观点，赢取积分及实物奖品！
-
提交了问题
2022-12-30
乘风问答官1月排位赛开启！话题、问题双赛道，机械键盘等你赢！
-
回答了问题
2022-12-29
提升研发效能真的能实现降本增效吗？
请符合获奖规则的用户于2023年1月5日前填写https://survey.aliyun.com/apps/zhiliao/1ltI5f9NV 用于奖品邮寄。本话题下所有超过120字的有效回答均可获奖！
赞0 踩0 评论0 -
回答了问题
2022-12-26
【藏经阁一起读（41）】读《阿里云云原生 Serverless 案例集》，你有哪些心得？
上期活动获奖名单： 六月暴雪飞梨花、游客m6wkac6syoeno、想做厨师的猴子
请以上用户入群私聊群主收获信息
赞0 踩0 评论0 -
提交了问题
2022-12-26
【藏经阁一起读（41）】读《阿里云云原生 Serverless 案例集》，你有哪些心得？
-
回答了问题
2022-12-21
D2终端大会你最看好哪个热点技术？
本期话题获奖名单： 讨论价值奖：摩诃般若、有路有乔-六月、felix@、晨光永不消逝、三掌柜666、2lqiyelhkdocw、Object、跃@sir、sunyalei。 互动幸运奖：麻烦少女、喜欢猪猪、huc_逆天 、小周sir、Java时光。 请以上获奖用户于12月28日前填写收件信息https://survey.aliyun.com/apps/zhiliao/1ltI5f9NV，用于邮寄奖品，逾期将视为主动放弃哦。近期物流较慢请见谅！
赞0 踩0 评论1 -
回答了问题
2022-12-21
横空出世的ChatGPT，究竟有什么魔力？
本期话题获奖名单： 技术剖析奖：huc_逆天， 畅聊无限奖：三掌柜666， 创意提问奖：不太对味， 前各位用户前往积分商城采用1积分兑换礼品，请于12月28日前兑换，逾期将视为主动放弃哦～
赞1 踩0 评论1 -
提交了问题
2022-12-19
提升研发效能真的能实现降本增效吗？
-
回答了问题
2022-12-15
拥有数字藏品是种怎样的体验？
第10期活动，截止12月13日24:00，收到79个回答，按照奖励规则中奖楼层百分比为1%，10%，30%，60%，90%的有效留言用户可获得互动幸运奖。 幸运奖中奖楼层为：1楼、8楼、24楼、48楼、72楼（不符合互动主题），自动顺延至73楼。
中奖名单： 飞云觅宙、游客33f2fg2im67z4、huc_逆天、五百万的大西瓜、游客qaw3qi5vsi5nk
请以上用户于12月22日前前往积分商城进行奖品的1积分兑换，逾期将视为主动放弃哦～
赞0 踩0 评论0 -
回答了问题
2022-12-13
云产品使用问题征集活动开启啦！提问题，赢社区周边等精美好礼！（获奖名单见文章末尾）
亲们快来积极参与，提问时记得关联产品标签哦
赞3 踩0 评论0 -
回答了问题
2022-12-13
乘风问答官12月排位赛开启！机械键盘、行李箱等你拿！
问答排位赛参与地址：回答12月的问题即为报名哦https://developer.aliyun.com/ask/latestQuestions/#/?_k=oet35q 如果你还不是乘风问答官，可以点击链接申请https://developer.aliyun.com/ask/469377
赞5 踩0 评论0
-
一秒变身！一键生成N次元虚拟卡通形象！发布时间：2023-01-12 16:59:20 视频时长：2分14秒 播放量：55692【场景应用】头像/通用图片的卡通化特效生成，广泛用于智能AI创作、社交娱乐、人物隐私保护等场景【数据集链接】数据集：https://modelscope.cn/datasets/modelscope/human_face_portrait_compound_dataset/summary模型文件：https://modelscope.cn/models/damo/cv_unet_person-image-cartoon_compound-models/files
-
告别PS，一键抠图不是梦发布时间：2023-01-12 16:56:04 视频时长：3分18秒 播放量：137【场景应用】方便设计师抠图，不需要使用photoshop等工具，实现一键全自动抠图；可以帮助用户换背景，实现多样化玩法。 【数据集链接】数据集：https://modelscope.cn/datasets/liujl09/Human_matting_testing_dataset/summary模型文件：https://modelscope.cn/models/damo/cv_unet_image-matting/files
-
三分钟视频教你一键修复老照片 找回曾经的美好记忆发布时间：2023-01-05 17:58:44 视频时长：1分41秒 播放量：47500【场景应用】可以应用于老照片、手机图片、老视频等素材的修复。【数据集链接】数据集：https://www.modelscope.cn/datasets/baiguan18/image-portrait-enhancement-dataset/summary模型文件：https://www.modelscope.cn/models/damo/cv_gpen_image-portrait-enhancement/summary
-
多模态问答模型带你实现高阶人机交流发布时间：2023-01-05 17:38:16 视频时长：2分54秒 播放量：355【场景应用】能够和机器自动进行各种类型的多模态问答，可以应用到各种人机交互的场景【数据集链接】数据集：https://modelscope.cn/datasets/modelscope/vqa_trial/summary模型文件：https://modelscope.cn/models/damo/mplug_visual-question-answering_coco_large_en/files
-
万物识别：教你一行代码通识万物发布时间：2023-01-05 17:28:01 视频时长：2分17秒 播放量：31660通用模型介绍模型文件https://modelscope.cn/models/damo/cv_resnest101_general_recognition/files
-
【创作者Open Talk】一场跨越时代的技术人对话发布时间：2022-11-11 15:00:50 视频时长：90分55秒 播放量：44042大咖云集！阿里云开发者社区创作者Open Talk精彩放送！这是一场跨越时代的技术人对话，一次关于“创作和分享”的同频共振。 -
快速教你搭建一个会说方言的播报音箱发布时间：2022-09-08 17:32:06 视频时长：13分3秒 播放量：61230首届“云上应用开发”大赛爆款视频来啦！来看开发者喜欢的视频什么样！ -
5分钟让线下售卖机实现自助售卖发布时间：2022-08-30 19:06:37 视频时长：8分24秒 播放量：502865分钟让线下售卖机实现自助售卖，点击视频了解更多~ -
手把手教你如何用云模组快速实现端侧设备上云发布时间：2022-08-29 21:44:21 视频时长：5分14秒 播放量：50469手把手教你如何用云模组快速实现端侧设备上云,点击视频了解更多内容。 -
开源人说第二期——《从开源中来，到开源中去》先导预告发布时间：2022-07-27 15:24:13 视频时长：1分0秒 播放量：41781《开源人说》为阿里云开发者社区与InfoQ 联合出品的一档精品开源视频栏目。栏目围绕四大开源领域：云原生、操作系统、数据库、大数据&AI，介绍优秀的开源软件背后的故事，记录传播技术人追求极致和开放共享的精神。第二期主题《从开源中来，到开源中去》，围绕龙蜥操作系统开源故事，以及开放、丰富、多元、健壮的社区生态，讲述龙蜥是如何从Linux开源而来，CentOS替换出发，捐赠开放原子基金会，到开源中去，最后落地千行百业中去产生实际价值的故事。我们希望有更多人了解到开源人背后的故事和付出，也希望可以影响更多人参与到开源的事业中。专题地址：https://developer.aliyun.com/topic/opensourcefolkstalk -
组织互联网时代，敏捷组织可以向上连接到消费互联网发布时间：2022-06-17 13:41:54 视频时长：1分12秒 播放量：1094组织互联网时代，敏捷组织可以向上连接到消费互联网 -
在组织互联网下企业的运作会有更大变化发布时间：2022-06-17 13:41:13 视频时长：1分31秒 播放量：650在组织互联网下企业的运作会有更大变化 -
在组织互联网领域超级APP成为一个趋势发布时间：2022-06-17 13:40:27 视频时长：1分47秒 播放量：914在组织互联网领域超级APP成为一个趋势 -
未来不同的企业可以像一家企业一样进行管理发布时间：2022-06-17 13:39:39 视频时长：1分27秒 播放量：876未来不同的企业可以像一家企业一样进行管理 -
什么样的形态才是敏捷组织发布时间：2022-06-17 13:38:29 视频时长：1分43秒 播放量：763什么样的形态才是敏捷组织 -
数智化转型核心要点发布时间：2022-06-17 13:33:16 视频时长：3分1秒 播放量：588数智化转型核心要点 -
周黑鸭如何做“顾客第一”发布时间：2022-06-17 13:32:09 视频时长：2分57秒 播放量：470周黑鸭如何做“顾客第一” -
周黑鸭如何通过数智化抓住年轻人的胃发布时间：2022-06-17 13:25:40 视频时长：3分51秒 播放量：410周黑鸭如何通过数智化抓住年轻人的胃 -
不做出改变，你的企业将再一次错过浪潮发布时间：2022-06-17 13:23:48 视频时长：2分12秒 播放量：146不做出改变，你的企业将再一次错过浪潮 -
组织如何构建面向未来的新引擎（三）发布时间：2022-06-16 15:17:15 视频时长：2分3秒 播放量：417组织如何构建面向未来的新引擎（三）