您当前的位置:首页 > 新闻 > 科技

腾讯万亿级 Elasticsearch 技术解密

时间:2020-03-13 13:15:35  来源:  作者:

Elasticsearch(ES)作为开源首选的分布式搜索分析引擎,通过一套系统轻松满足用户的日志实时分析、全文检索、结构化数据分析等多种需求,大幅降低大数据时代挖掘数据价值的成本。腾讯在公司内部丰富的场景中大规模使用 ES,同时联合 Elastic 公司在腾讯云上提供内核增强版的 ES 云服务,大规模、丰富多样的的使用场景推动着腾讯对原生 ES 进行持续的高可用、高性能、低成本优化。今天给大家分享在 Elastic 中国开发者大会上的演讲内容:腾讯万亿级 Elasticsearch 技术解密。

一、ES 在腾讯的应用场景

腾讯万亿级 Elasticsearch 技术解密

 

本次分享的主要内容包含:首先介绍 ES 在腾讯的丰富应用场景及各种场景的典型特点;然后给出我们在大规模、高压力、丰富多样的使用场景下遇到的挑战;针对这些挑战,我们重点介绍腾讯在 ES 内核方面进行的高可用性、低成本、高性能等优化实践;最后简单分享我们在 ES 未来规划以及开源贡献方面的思考。

腾讯万亿级 Elasticsearch 技术解密

 

我们先来看下 ES 在腾讯的应用场景。最初我们使用 ES 于日志实时分析场景,典型日志如下:运营日志,比如慢日志、异常日志,用来定位业务问题;业务日志,比如用户的点击、访问日志,可以用来分析用户行为;审计日志,可以用于安全分析。ES 很完美的解决了日志实时分析的需求,它具有如下特点:

  • Elastic 生态提供了完整的日志解决方案,任何一个开发、运维同学使用成熟组件,通过简单部署,即可搭建起一个完整的日志实时分析服务。
  • 在 Elastic 生态中,日志从产生到可访问一般在 10s 级。相比于传统大数据解决方案的几十分钟、小时级,时效性非常高。
  • 由于支持倒排索引、列存储等数据结构,ES 提供非常灵活的搜索分析能力。
  • 支持交互式分析,即使在万亿级日志的情况下,ES 搜索响应时间也是秒级。

日志是互联网行业最基础、最广泛的数据形式,ES 非常完美的解决了日志实时分析场景,这也是近几年 ES 快速发展的一个重要原因。

腾讯万亿级 Elasticsearch 技术解密

 

第二类使用场景是搜索服务,典型场景包含:商品搜索,类似京东、淘宝拼多多中的商品搜索;App 搜索,支持应用商店里的应用搜索;站内搜索,支持论坛、在线文档等搜索功能。我们支持了大量搜索服务,它们主要有以下特点:

  • 高性能:单个服务最大达到 10w+ QPS,平响 20ms~,P95 延时小于 100ms。
  • 强相关:搜索体验主要取决于搜索结果是否高度匹配用户意图,需要通过正确率、召回率等指标进行评估。
  • 高可用:搜索场景通常要求 4 个 9 的可用性,支持单机房故障容灾。任何一个电商服务,如淘宝、京东、拼多多,只要故障一个小时就可以上头条。
腾讯万亿级 Elasticsearch 技术解密

 

第三类使用场景是时序数据分析,典型的时序数据包含:Metrics,即传统的服务器监控;APM,应用性能监控;物联网数据,智能硬件、工业物联网等产生的传感器数据。这类场景腾讯很早就开始探索,在这方面积累了非常丰富的经验。这类场景具有以下特点:

  • 高并发写入:线上单集群最大规模达到 600+节点、1000w/s 的写入吞吐。
  • 高查询性能:要求单条曲线 或者单个时间线的查询延时在 10ms~。
  • 多维分析:要求灵活、多维度的统计分析能力,比如我们在查看监控的时候,可以按照地域、业务模块等灵活的进行统计分析。

 

二、遇到的挑战

前面我们介绍了 ES 在腾讯内部的广泛应用,在如此大规模、高压力、丰富使用场景的背景下,我们遇到了很多挑战,总体可以划分为两类:搜索类和时序类。

腾讯万亿级 Elasticsearch 技术解密

 

首先,我们一起看看搜索类业务的挑战。以电商搜索、APP 搜索、站内搜索为代表,这类业务非常重视可用性,服务 SLA 达到 4 个 9 以上,需要容忍单机故障、单机房网络故障等;同时要求高性能、低毛刺,例如 20w QPS、平响 20ms、P95 延时 100ms。总之,在搜索类业务场景下,核心挑战点在于高可用、高性能。

腾讯万亿级 Elasticsearch 技术解密

 

另一类我们称之为时序类业务挑战,包含日志、Metrics、APM 等场景。相比于搜索类业务重点关注高可用、高性能,时序类业务会更注重成本、性能。比如时序场景用户通常要求高写入吞吐,部分场景可达 1000w/swps;在这样写入吞吐下,保留 30 天的数据,通常可达到 PB 级的存储量。而现实是日志、监控等场景的收益相对较低,很可能用户用于线上实际业务的机器数量才是 100 台,而监控、日志等需要 50 台,这对多数用户来说,基本是不可接受的。所以在时序类业务中,主要的挑战在于存储成本、计算成本等方面。

前面我们介绍了在搜索类、时序类业务场景下遇到的高可用、低成本、高性能等挑战,下面针对这些挑战,我们重点分享腾讯在 ES 内核方面的深入实践。

 

三、ES 优化实践

腾讯万亿级 Elasticsearch 技术解密

 

首先,我们来看看高可用优化,我们把高可用划分为三个维度:

  • 系统健壮性:是指 ES 内核自身的健壮性,也是分布式系统面临的共性难题。例如,在异常查询、压力过载下集群的容错能力;在高压力场景下,集群的可扩展性;在集群扩容、节点异常场景下,节点、多硬盘之间的数据均衡能力。
  • 容灾方案:如果通过管控系统建设,保障机房网络故障时快速恢复服务,自然灾害下防止数据丢失,误操作后快速恢复等。
  • 系统缺陷:这在任何系统发展过程中都会持续产生,比如说 Master 节点堵塞、分布式死锁、滚动重启缓慢等。
腾讯万亿级 Elasticsearch 技术解密

 

针对上述问题,下面来介绍我们在高可用方面的解决方案:

系统健壮性方面,我们通过服务限流,容忍机器网络故障、异常查询等导致的服务不稳定,后面展开介绍。通过优化集群元数据管控逻辑,提升集群扩展能力一个数量级,支持千级节点集群、百万分片,解决集群可扩展性问题;集群均衡方面,通过优化节点、多硬盘间的分片均衡,保证大规模集群的压力均衡。

容灾方案方面,我们通过扩展 ES 的插件机制支持备份回档,把 ES 的数据备份回档到廉价存储,保证数据的可恢复;支持跨可用区容灾,用户可以按需部署多个可用区,以容忍单机房故障。垃圾桶机制,保证用户在欠费、误操作等场景下,集群可快速恢复。

系统缺陷方面,我们修复了滚动重启、Master 阻塞、分布式死锁等一系列 Bug。其中滚动重启优化,可加速节点重启速度 5+倍,具体可参考 PR ES-46520(https://github.com/elastic/elasticsearch/pull/46520);Master 堵塞问题,我们在 ES 6.x 版本和官方一起做了优化。

腾讯万亿级 Elasticsearch 技术解密

 

这里我们展开介绍下服务限流部分。我们做了 4 个层级的限流工作:权限层级,我们支持 XPack 和自研权限来防止攻击、误操作;队列层级,通过优化任务执行速度、重复、优先级等问题,解决用户常遇到的 Master 任务队列堆积、任务饿死等问题;内存层级,我们从 ES 6.x 开始,支持在 HTTP 入口、协调节点、数据节点等全链路上进行内存限流,同时使用 JVM 内存、梯度统计等方式精准控制;多租户层级,我们使用 CVM/Cgroups 方案保证多租户间的资源隔离。

这里详细介绍下聚合场景限流问题,用户在使用 ES 进行聚合分析时,经常遇到因聚合分桶过多打爆内存的问题。官方在 ES 6.8 中提供 max_buckets 参数控制聚合的最大分桶数,但这个方式局限性非常强。在某些场景下,用户设置 20 万个分桶可以正常工作,但在另一些场景下,可能 10 万个分桶内存就已经打爆,这主要取决于单分桶的大小,用户并不能准确把握该参数设置为多少比较合适。我们在聚合分析的过程中,采用梯度算法进行优化,每分配 1000 个分桶检查一次 JVM 内存,当内存不足时及时中断请求,保证 ES 集群的高可用。具体可参考 PR ES-46751 (https://github.com/elastic/elasticsearch/pull/46751) / 47806 (https://github.com/elastic/elasticsearch/pull/47806)。

我们当前的限流方案,能够大幅提升在异常查询、压力过载、单节点故障、网络分区等场景下,ES 服务的稳定性问题。但还有少量场景没有覆盖完全,所以我们目前也在引入混沌测试,依赖混沌测试来覆盖更多异常场景。

腾讯万亿级 Elasticsearch 技术解密

 

前面我们介绍了高可用解决方案,下面我们来介绍成本方面的优化实践。成本方面的挑战,主要体现在以日志、监控为代表的时序场景对机器资源的消耗,我们对线上典型的日志、时序业务进行分析,总体来看,硬盘、内存、计算资源的成本比例接近 8:4:1,硬盘、内存是主要矛盾,其次是计算成本。

而对时序类场景进行分析,可以发现时序数据有很明显的访问特性。一是冷热特性,时序数据访问具有近多远少的特点,最近 7 天数据的访问量占比可达到 95%以上;历史数据访问较少,且通常都是访问统计类信息。

腾讯万亿级 Elasticsearch 技术解密

 

基于这些瓶颈分析和数据访问特性,我们来介绍成本优化的解决方案。

硬盘成本方面,由于数据具有明显的冷热特性,首先我们采用冷热分离架构,使用混合存储的方案来平衡成本、性能;其次,既然对历史数据通常都是访问统计信息,那么以通过预计算来换取存储和性能,后面会展开介绍;如果历史数据完全不使用,也可以备份到更廉价的存储系统;其他一些优化方式包含存储裁剪、生命周期管理等。

内存成本方面,很多用户在使用大存储机型时会发现,存储资源才用了百分之二十,内存已经不足。其实基于时序数据的访问特性,我们可以利用 Cache 进行优化,后面会展开介绍。

腾讯万亿级 Elasticsearch 技术解密

 

我们展开介绍下 Rollup 部分。官方从 ES 6.x 开始推出 Rollup,实际上腾讯在 5.x 已经开始这部分的实践。Rollup 类似于大数据场景下的 Cube、物化视图,它的核心思想是通过预计算提前生成统计信息,释放掉原始粒度数据,从而降低存储成本、提高查询性能,通常会有数据级的收益。这里举个简单的例子,比如在机器监控场景下,原始粒度的监控数据是 10 秒级的,而一个月之前的监控数据,一般只需要查看小时粒度,这即是一个 Rollup 应用场景。

在大数据领域,传统的方案是依赖外部离线计算系统,周期性的读取全量数据进行计算,这种方式计算开销、维护成本高。谷歌的广告指标系统 Mesa 采用持续生成方案,数据写入时系统给每个 Rollup 产生一份输入数据,并对数据进行排序,底层在 Compact/Merge 过程中通过多路归并完成 Rollup,这种方式的计算、维护成本相对较低。ES 从 6.x 开始支持数据排序,我们通过流式查询进行多路归并生成 Rollup,最终计算开销小于全量数据写入时 CPU 开销的 10%,内存使用小于 10MB。我们已反馈内核优化至开源社区,解决开源 Rollup 的计算、内存瓶颈,具体可参考 PR ES-48399 (https://github.com/elastic/elasticsearch/pull/48399)。

腾讯万亿级 Elasticsearch 技术解密

 

接下来,我们展开介绍内存优化部分。前面提到很多用户在使用大存储机型时,内存优先成为瓶颈、硬盘不能充分利用的问题,主要瓶颈在于索引占用大量内存。但是我们知道时序类场景对历史数据访问很少,部分场景下某些字段基本不使用,所我们可以通过引入 Cache 来提高内存利用效率。

在内存优化方面,业界的方案是什么样的呢?ES 社区从 7.x 后支持索引放于堆外,和 DocValue 一样按需加载。但这种方式不好的地方在于索引和数据的重要性完全不同,一个大查询很容易导致索引被淘汰,后续查询性能倍数级的衰减。Hbase 通过缓存 Cache 缓存索引、数据块,提升热数据访问性能,并且从 HBase 2.0 开始,重点介绍其 Off Heap 技术,重点在于堆外内存的访问性能可接近堆内。我们基于社区经验进行迭代,在 ES 中引入 LFU Cache 以提高内存的利用效率,把 Cache 放置在堆外以降低堆内存压力,同时通过 Weak Reference、减少堆内外拷贝等技术降低损耗。最终效果是内存利用率提升 80%,可以充分利用大存储机型,查询性能损耗不超过 2%,GC 开销降低 30%。

腾讯万亿级 Elasticsearch 技术解密

 

前面我们介绍了可用性、成本优化的解决方案,最后我们来介绍性能方面的优化实践。以日志、监控为代表的时序场景,对写入性能要求非常高,写入并发可达 1000w/s。然而我们发现在带主键写入时,ES 性能衰减 1+倍,部分压测场景下,CPU 无法充分利用。以搜索服务为代表的场景,对查询性的要求非常高,要求 20w QPS, 平响 20ms,而且尽量避免 GC、执行计划不优等造成的查询毛刺。

腾讯万亿级 Elasticsearch 技术解密

 

针对上述问题,我们介绍下腾讯在性能方面的优化实践:

写入方面,针对主键去重场景,通过利用索引进行裁剪,加速主键去重的过程,写入性能提升 45%,具体可参考 PR LUCENE-8980 (https://github.com/Apache/lucene-solr/pull/884)。对于部分压测场景下 CPU 不能充分利用的问题,通过优化 ES 刷新 Translog 时的资源抢占,提升性能提升 20%,具体可参考 PR ES-45765 (https://github.com/elastic/elasticsearch/pull/45765) /47790 (https://github.com/elastic/elasticsearch/pull/47790)。我们正在尝试通过向量化执行优化写入性能,通过减少分支跳转、指令 Miss,预期写入性能可提升 1 倍。

查询方面,我们通过优化 Merge 策略,提升查询性能,这部分稍后展开介绍。基于每个 Segment 记录的 min/max 索引,进行查询剪枝,提升查询性能 30%。通过 CBO 策略,避免查询 Cache 操作导致查询耗时 10+倍的毛刺,具体可参考 LUCENE-9002 (https://github.com/apache/lucene-solr/pull/940)。此外,我们也在尝试通过一些新硬件来优化性能,比如说英特尔的 AEP、Optane、QAT 等。

腾讯万亿级 Elasticsearch 技术解密

 

接下来我们展开介绍下 Merge 策略优化部分。ES 原生的 Merge 策略主要关注大小相似性和最大上限,大小相似性是指 Merge 时尽量选择大小相似的 Segments 进行 Merge,最大上限则考虑尽量把 Segment 拼凑到 5GB。那么有可能出现某个 Segment 中包含了 1 月整月、3 月 1 号的数据,当用户查询 3 月 1 号某小时的数据时,就必须扫描大量无用数据,性能损耗严重。

我们在 ES 中引入了时序 Merge,在选择 Segments 进行 Merge 时,重点考虑时间因素,这样时间相近的 Segments 被 Merge 到一起。当我们查询 3 月 1 号的数据时,只需要扫描个别较小的 Segments 就好,其他的 Segments 可以快速裁剪掉。

另外,ES 官方推荐搜索类用户在写入完成之后,进行一次 Force Merge,用意是把所有 Segments 合并为一个,以提高搜索性能。但这增加了用户的使用成本,且在时序场景下,不利于裁剪,需要扫描全部数据。我们在 ES 中引入了冷数据自动 Merge,对于非活跃的索引,底层 Segments 会自动 Merge 到接近 5GB,降低文件数量的同时,方便时序场景裁剪。对于搜索场景,用户可以调大目标 Segment 的大小,使得所有 Segments 最终 Merge 为一个。我们对 Merge 策略的优化,可以使得搜索场景性能提升 1 倍。

前面介绍完毕我们再 ES 内核方面的优化实践,最后我们来简单分享下我们在开源贡献及未来规划方面的思考。

 

四、未来规划及开源贡献

腾讯万亿级 Elasticsearch 技术解密

 

近半年我们向开源社区提交了 10+PR,涉及到写入、查询、集群管理等各个模块,部分优化是和官方开发同学一起来完成的,前面介绍过程中,已经给出相应的 PR 链接,方便大家参考。我们在公司内部也组建了开源协同的小组,来共建 Elastic 生态。

总体来说,开源的收益利大于弊,我们把相应收益反馈出来,希望更多同学参与到 Elastic 生态的开源贡献中:首先,开源可以降低分支维护成本,随着自研的功能越来越多,维护独立分支的成本越来越高,主要体现在与开源版本同步、快速引入开源新特性方面;其次,开源可以帮助研发同学更深入的把控内核,了解最新技术动态,因为在开源反馈的过程中,会涉及与官方开发人员持续的交互。此外,开源有利于建立大家在社区的技术影响力,获得开源社区的认可。最后 Elastic 生态的快速发展,有利于业务服务、个人技术的发展,希望大家一起参与进来,助力 Elastic 生态持续、快速的发展。

腾讯万亿级 Elasticsearch 技术解密

 

未来规划方面,这次分享我们重点介绍了腾讯在 ES 内核方面的优化实践,包含高可用、低成本、高性能等方面。此外,我们也提供了一套管控平台,支持线上集群自动化管控、运维,为腾讯云客户提供 ES 服务。但是从线上大量的运营经验分析,我们发现仍然有非常丰富、高价值的方向需要继续跟进,我们会持续继续加强对产品、内核的建设。

腾讯万亿级 Elasticsearch 技术解密

 

长期探索方面,我们结合大数据图谱来介绍。整个大数据领域,按照数据量、延时要求等特点,可以划分为三部分:第一部分是 Data Engineering,包含我们熟悉的批量计算、流式计算;第二部分是 Data Discovery,包含交互式分析、搜索等;第三个部分是 Data Apps,主要用于支撑在线服务。

虽然我们把 ES 放到搜索领域内,但是也有很多用户使用 ES 支持在线搜索、文档服务等;另外,我们了解到有不少成熟的 OLAP 系统,也是基于倒排索引、行列混存等技术栈,所以我们认为 ES 未来往这两个领域发展的可行性非常强,我们未来会在 OLAP 分析和在线服务等方向进行重点探索。



Tags:腾讯   点击:()  评论:()
声明:本站部分内容及图片来自互联网,转载是出于传递更多信息之目的,内容观点仅代表作者本人,如有任何标注错误或版权侵犯请与我们联系(Email:2595517585@qq.com),我们将及时更正、删除,谢谢。
▌相关推荐
阿里云和腾讯云都是非常好的云服务器平台,大多数用户完全不用纠结腾讯云还是阿里云,特别是微信开发用户,自然是首选腾讯云,其次是学生或个人以及财政紧张的小公司微型业务,腾讯云...【详细内容】
2021-12-14  Tags: 腾讯  点击:(14)  评论:(0)  加入收藏
中国音乐市场近年来的历史,是一部版权争夺史。随着版权价值显现,“独家授权”成了音乐平台开疆拓土的关键。仅仅数年,水涨船高的版权费令市场格局重组,玩家越来越少,资源向少数头...【详细内容】
2021-10-18  Tags: 腾讯  点击:(36)  评论:(0)  加入收藏
很长时间没有过对一个概念如此追捧的景象了。现在,这样的景象正在元宇宙的身上发生。除了资本市场对元宇宙推崇备至之外,我们看到的更多的是头部巨头们对元宇宙的深度布局。国...【详细内容】
2021-10-07  Tags: 腾讯  点击:(31)  评论:(0)  加入收藏
VPN英文全称是“Virtual Private Network”,也就是“虚拟专用网络”。虚拟专用网络就是一种虚拟出来的企业内部专用线路、这条隧道可以对数据进行几倍加密达到安全使用互联网...【详细内容】
2021-09-14  Tags: 腾讯  点击:(45)  评论:(0)  加入收藏
最近,美国联邦贸易委员会(FTC)重新发起对Facebook的反垄断起诉。FTC称,Facebook的用户数量和用户贡献内容的累积构成了垄断要件。Facebook的用户大,内容积累长,已经具有不可替代...【详细内容】
2021-08-24  Tags: 腾讯  点击:(165)  评论:(0)  加入收藏
1.腾讯将允许支付引入淘宝和天猫分享到微信 腾讯和阿里巴巴正在制定互通计划,腾讯将允许阿里系电商信息分享到微信,阿里巴巴会将腾讯的微信支付引入淘宝和天猫。值得一提的是,...【详细内容】
2021-08-10  Tags: 腾讯  点击:(67)  评论:(0)  加入收藏
作为普通人,我们经常会碰到想别人借点钱应急的情况。但在很多时候,大家的法律意识没那么强,加之借贷往往发生在熟人间。我们会发现,大多数这方面的问题,都在于丑话没说在前面”,华...【详细内容】
2021-07-29  Tags: 腾讯  点击:(153)  评论:(0)  加入收藏
近日,国家市场监管总局对音乐版权领域的垄断有了定论:责令腾讯控股有限公司解除网络音乐独家版权。酷我、酷狗、QQ音乐联合,虾米音乐被迫关停成为国内第一例反垄断回复市场竞争...【详细内容】
2021-07-27  Tags: 腾讯  点击:(81)  评论:(0)  加入收藏
版权问题越来越重视,音乐的版权也同样如此。 如今音乐软件作为日常手机软件的必备,我们在听歌的时候,可能会莫名其妙遇到自己最喜欢的歌曲,突然遭到下架无法正常播放。 所以为了...【详细内容】
2021-07-14  Tags: 腾讯  点击:(75)  评论:(0)  加入收藏
1.首先谷歌浏览器打开腾讯视频(网页版)2.其次,按下F12(开发者工具),选中Elements 3.按下 ctrl+F ,输入“watermark”,点击选择第二个 4.选中后右击delete 删除元素,看视频就没水印...【详细内容】
2021-07-14  Tags: 腾讯  点击:(344)  评论:(0)  加入收藏
▌简易百科推荐
非法购买公民信息、开发人脸认证规避技术……今年年初,广东省公安厅网安部门侦破全国首例破解“青少年防沉迷系统”的新型网络犯罪案件,抓获犯罪嫌疑人13名,查处非...【详细内容】
2021-12-28    人民日报客户端  Tags:数据安全步   点击:(5)  评论:(0)  加入收藏
就在今天,腾讯方面宣布将在2022年1月31日下架企业QQ和营销QQ,其实这一消息的降临并不让笔者意外,因为早在今年的10月28日20点之后,企业QQ和营销QQ就被停止了续费服务。相信很多...【详细内容】
2021-12-27  科技探险家    Tags:企业QQ   点击:(21)  评论:(0)  加入收藏
日前,上海交通大学发布《全球电竞之都评价报告》,对全球15个致力于发展电竞之都的城市进行评价,上海作为中国城市电竞发展的排头兵,其拥有众多优质电竞企业及完整产业集群,因此排...【详细内容】
2021-12-27  经济日报    Tags:电竞   点击:(3)  评论:(0)  加入收藏
为优化网络氛围环境,微博又开始整顿用户信息了。本月月初,微博官方发布公告,要求昵称中带有如“二货”“SB”“瘪三”“娘炮”等明显低俗或侮辱性词汇的用户尽快修改,否则将面临...【详细内容】
2021-12-24  运了个营    Tags:微博   点击:(10)  评论:(0)  加入收藏
昨日谷歌宣布,自2022年12月19日开始停止对OnHub的软件支持,OnHub路由器仍将提供Wi-Fi信号,但用户无法用谷歌Home应用程序管理它。无法更新Wi-Fi网络设置、添加额外的Wifi设备或...【详细内容】
2021-12-22  雷峰网    Tags:Google OnHub   点击:(5)  评论:(0)  加入收藏
IT之家 12 月 20 日消息,百度网盘青春版 iOS 客户端今日晚间率先开启内测,安卓客户端将在稍后内测。使用苹果 iPhone 的IT之家小伙伴可以点此下载内测版,需要先下载 TestFlight...【详细内容】
2021-12-21  IT之家    Tags:百度网盘   点击:(10)  评论:(0)  加入收藏
对于拼车单,是接还是不接,不少网约车司机表示很矛盾。接吧,钱少事多,常常跑了个寂寞,不接吧,车多客少,挑三拣四没饭吃。 在平台大力推广拼车单之下,不少司机迫于生活压力,最终还是打...【详细内容】
2021-12-17  网约车情报分享    Tags:滴滴   点击:(9)  评论:(0)  加入收藏
蓝鲸TMT频道12月16日讯,据饿了么官方微信公众号,近日,在圆桌会上,蓝骑士与平台交流了配送安全问题。饿了么表示,线上将技术手段融入安全防护;线下将持续进行安全培训,并试点智能头...【详细内容】
2021-12-17    金融界  Tags:饿了么   点击:(24)  评论:(0)  加入收藏
开源最前线(ID:OpenSourceTop) 猿妹编译项目地址: https://github.com/restic/restic全球知名代码托管平台 GitHub 今天就重磅发布了今年的年度报告——《2021 年度 O...【详细内容】
2021-12-17  Python部落    Tags:   点击:(9)  评论:(0)  加入收藏
新京报快讯 据中国网络视听节目服务协会网站消息,12月15日,中国网络视听节目服务协会发布了《网络短视频内容审核标准细则》(2021)。中国网络视听节目服务协会组织有关短视频平...【详细内容】
2021-12-16    新京报  Tags:短视频   点击:(11)  评论:(0)  加入收藏
最新更新
栏目热门
栏目头条