DanceNN:字节自研千亿级规模文件元数据存储系统概述

发表于 2年以前  | 总阅读数:315 次

背景介绍

在一个典型的分布式文件系统中,目录文件元数据操作(包括创建目录或文件,重命名,修改权限等)在整个文件系统操作中占很大比例,因此元数据服务在整个文件系统中扮演着重要的角色,随着大规模机器学习、大数据分析和企业级数据湖等应用,分布式文件系统数据规模已经从 PB 级到 EB 级,当前多数分布式文件系统(如 HDFS 等)面临着元数据扩展性的挑战。

以 Google、Facebook 和 Microsoft 等为代表的公司基本实现了能够管理 EB 级数据规模的分布式文件系统,这些系统的共同架构特征是依赖于底层分布式数据库能力来实现元数据性能的水平扩展,如 Google Colossus 基于 BigTable,Facebook 基于 ZippyDB,Microsoft ADLSv2 基于 Table Storage,还有一些开源文件系统包括 CephFS 和 HopsFS 等也基本实现了水平扩展的能力。

这些文件系统实现由于对底层分布式数据库的依赖,对文件系统的语义支持程度也各有不同,如大多数基于分布式文件系统的计算分析框架依赖底层目录原子 Rename 操作来提供数据的原子更新,而 Tectonic 和 Colossus 因为底层数据库不支持跨分区事务所以不保证跨目录 Rename 的原子性,而 ADLSv2 支持对任意目录的原子 Rename。

DanceNN 是公司自研的一个目录树元信息存储系统,致力于解决所有分布式存储系统的目录树需求(包括不限于 HDFS,NAS 等),极大简化上层存储系统依赖的目录树操作复杂性,包括不限于原子 Rename、递归删除等。解决超大规模目录树存储场景下的扩展性、性能、异构系统间的全局统一命名空间等问题,打造全球领先的通用分布式目录树服务。

当前 DanceNN 已经为公司在线 ByteNAS,离线 HDFS 两大分布式文件系统提供目录树元数据服务。

(本篇主要介绍在离线大数据场景 HDFS 文件系统下 DanceNN 的应用,考虑篇幅,DanceNN 在 ByteNAS 的应用会在后续系列文章介绍,敬请期待)

元数据演进

字节 HDFS 元数据系统分三个阶段演进:

NameNode

最开始公司使用 HDFS 原生 NameNode,虽然进行了大量优化,依然面临下列问题:

  • 元数据(包括目录树,文件和 Block 副本等)全内存存储,单机承载能力有限
  • 基于 Java 语言实现,在大内存场景 GC 停顿时间比较长,严重影响 SLA
  • 使用全局一把读写锁,读写吞吐性能较差
  • 随着集群数据规模增加,重启恢复时间达到小时级别

DanceNN v1

DanceNN v1 的设计目标是为了解决上述 NameNode 遇到的问题。

主要设计点包括:

  • 重新实现 HDFS 协议层,将目录树文件相关元数据存储到 RocksDB 存储引擎,提供 10 倍元数据承载
  • 使用 C++ 实现,避免 GC 问题,同时使用高效数据结构组织内存 Block 信息,减少内存使用
  • 实现一套细粒度目录锁机制,极大提升不同目录文件操作间的并发
  • 请求路径全异步化,支持请求优先级处理
  • 重点优化块汇报和重启加载流程,降低不可用时间

DanceNNv1 最终在 2019 年完成全量上线,线上效果基本达到设计目标。

下面是一个十几亿文件数规模集群,切换后大致性能对比:

DanceNN v1 开发中遇到很多技术挑战,如为了保证上线过程对业务无感知,支持现有多种 HDFS 客户端访问,后端需要完全兼容原有的 Hadoop HDFS 协议。

Distributed DanceNN

一直以来 HDFS 都是使用 Federation 方式来管理目录树,将全局 Namespace 按 path 映射到多组元数据独立的 DanceNN v1 集群,单组 DanceNN v1 集群有单机瓶颈,能处理的吞吐和容量有限,随着公司业务数据的增长,单组 DanceNN v1 集群达到性能极限,就需要在两个集群之间频繁迁移数据,为了保证数据一致性需要在迁移过程中上层业务停写,对业务影响比较大,并且当数据量大的情况下迁移比较慢,这些问题给整个系统带来非常大的运维压力,降低服务的稳定性。

Distributed 版本主要设计目标:

  • 通用目录树服务,支持多协议包括 HDFS,POSIX 等
  • 单一全局 Namespace
  • 容量、吞吐支持水平扩展
  • 高可用,故障恢复时间在秒级内
  • 包括跨目录 Rename 等写操作支持事务
  • 高性能,基于 C++ 实现,依赖 Brpc 等高性能框架

Distributed DanceNN 目前已经在 HDFS 部分集群上线,正在进行存量集群的平滑迁移。

文件系统概览

分层架构

最新 HDFS 分布式文件系统实现采用分层架构,主要包括三层:

  • 数据层:用于存储文件内容, 处理 Block 级别的 IO 请求

  • 由 DataNode 节点提供服务

  • Namespace 层:负责目录树相关元数据,处理目录和文件创建、删除、Rename 和鉴权等请求

  • Distributed DanceNN 集群提供服务

  • 文件块层:负责文件相关的元数据、文件与 Block 的映射以及 Block 副本位置信息,处理文件创建删除,文件 Block 的添加等请求

  • 一个 BSGroup 负责管理集群部分文件块元数据,由多台的 DanceBS 组成提供高可用服务

  • 通过 BSGroup 动态扩容来适应集群负载,当某个 BSGroup 快达到性能极限后可以控制写入

DanceProxy

  • C++ 实现,基于高性能框架 Brpc 实现了 Hadoop RPC 协议,支持高吞吐,无缝对接现有 HDFS Client。
  • 主要负责对 HDFS Client 请求的解析,拆分处理后,将 Namespace 相关的请求发送到 DanceNN 集群,文件块相关的请求路由到对应的 BSGroup 处理,当所有后端请求回复后生成最终客户端的响应。
  • DanceProxy 通过一定的请求路由策略来实现多组 BSGroup 负载均衡。

DanceNN 接口

Distributed DanceNN 为文件系统提供主要接口如下:

class DanceNNClient {
 public:
  DanceNNClient() = default;
  virtual ~DanceNNClient() = default;

 // ...

 // Create directories recursively, eg: MkDir /home/tiger.
 ErrorCode MkDir(const MkDirReq& req);

  // Delete a directory, eg: RmDir /home/tiger.
 ErrorCode RmDir(const RmDirReq& req);

 // Change the name or location of a file or directory,
 // eg: Rename /tmp/foobar.txt /home/tiger/foobar.txt.
 ErrorCode Rename(const RenameReq& req);

 // Create a file, eg: Create /tmp/foobar.txt.
 ErrorCode Create(const CreateReq& req, CreateRsp* rsp);

 //  Delete a file, eg: Unlink /tmp/foobar.txt.
 ErrorCode Unlink(const UnlinkReq& req, UnlinkRsp* rsp);

 // Summarize a file or directory, eg: Du /home/tiger.
 ErrorCode Du(const DuReq& req, DuRsp* rsp);

 // Get status of a file or directory, eg: Stat /home/tiger/foobar.txt.
 ErrorCode Stat(const StatReq& req, StatRsp* rsp);

 // List directory contents, eg: Ls /home/tiger.
 ErrorCode Ls(const LsReq& req, LsRsp* rsp);

 // Create a symbolic link named link_path which contains the string target.
 // eg: Symlink /home/foo.txt /home/bar.txt
 ErrorCode Symlink(const SymlinkReq& req);

 // Read value of a symbolic link.
 ErrorCode ReadLink(const ReadLinkReq& req, ReadLinkRsp* rsp);

 // Change permissions of a file or directory.
 ErrorCode ChMod(const ChModReq& req);

 // Change ownership of a file or directory.
 ErrorCode ChOwn(const ChOwnReq& req);

 // Change file last access and modification times.
 ErrorCode UTimeNs(const UTimeNsReq& req, UTimeNsRsp* rsp);

 // Set an extended attribute value.
 ErrorCode SetXAttr(const SetXAttrReq& req, SetXAttrRsp* rsp);

//  List extended attribute names.
 ErrorCode GetXAttrs(const GetXAttrsReq& req, GetXAttrsRsp* rsp);

 // remove an extended attribute.
 ErrorCode RemoveXAttr(const RemoveXAttrReq& req,
                                RemoveXAttrRsp* rsp);
 // ...

};

DanceNN 架构

功能介绍

Distributed DanceNN 基于底层分布式事务 KV 存储来构建,实现容量和吞吐水平扩展,主要功能:

  • HDFS 等协议层的高效实现
  • 服务无状态化,支持高可用
  • 服务节点的快速扩缩容
  • 提供高性能低延迟的访问
  • 对 Namespace 进行子树划分,充分利用子树 Cache Locality
  • 集群根据负载均衡策略对子树进行调度

模块划分

SDK

缓存集群子树、NameServer 位置等信息,解析用户请求并路由到后端服务节点上,如果服务节点响应请求不合法,可能强制 SDK 刷新相应的集群缓存。

NameServer

  • 作为服务节点,无状态,支持横向扩展
  • HDFS/POSIX Protocol Layer:处理客户端请求,实现了 HDFS 等协议层语义,包括路径解析,权限校验,删除进入回收站等
  • Subtree Manager:管理分配给当前节点的子树,负责用户请求检查,子树迁移处理等
  • Heartbeater:进程启动后会自动注册到集群,定期向 NameMaster 更新心跳和负载信息等
  • DistributedLock Manager:基于 LockTable,对跨目录 Rename 请求进行并发控制
  • Latch Manager:对所有路径读写请求进行加锁处理,降低底层事务冲突,支持 Cache 的并发访问
  • Strong Consistent Cache:维护了当前节点子树的 dentry 和 inode 强一致 Cache
  • Data Acess Layer:对底层 KV 存储的访问接口的抽象,上层读写操作都会映射到底层 KV 存储请求

NameMaster

  • 作为管理节点,无状态,多台,通过选主实现,由主节点提供服务
  • AdminTask Scheduler:后台管理相关任务调度执行,包括子树切分,扩容等
  • Load Balancer:根据集群 NameServer 负载状态,通过自动子树迁移来完成负载均衡
  • NameServer Manager:监控 NameServer 健康状态,进行相应的宕机处理
  • Statistics:通过消费集群变更日志,实时收集统计信息并展示

Distributed Transactional KV Store

  • 数据存储层,使用自研的强一致 KV 存储系统 ByteKV
  • 提供水平伸缩能力
  • 支持分布式事务,提供 Snapshot 隔离级别
  • 支持多机房数据灾备

BinLog Store

  • BinLog 存储,使用自研的低延迟分布式日志系统 ByteJournal,支持 Exactly Once 语义
  • 从底层 KV 存储系统中实时抽取数据变更日志,主要用于 PITR 和其他组件的实时消费等

GC(Garbage collector)

  • 从 BinLog Store 实时消费变更日志,读到文件删除记录后,向文件块服务下发删除命令,及时清理用户数据

Quota

  • 对用户认领的目录,会周期性全量、实时增量的统计文件总数和空间总量,容量超限后限制用户写

关键设计

存储格式

一般基于分布式存储的元数据格式有两种方案:

方案一类似 Google Colossus,以全路径作为 key,元数据作为 value 存储,优点有:

  • 路径解析非常高效,直接通过用户请求的 path 从底层的 KV 存储读取对应 inode 的元数据即可
  • 扫描目录可以通过前缀对 KV 存储进行扫描

但是有下列缺点:

  • 跨目录 Rename 代价大,需要对目录下的所有文件和目录进行移动
  • Key 占用的空间相对比较大

另外一种类似 Facebook Tectonic 和开源的 HopsFS,以父目录 inode id + 目录或文件名作为 key,元数据作为 value 存储,这种优点有:

  • 跨目录 Rename 非常轻量,只需要修改源和目标节点以及它们的父节点
  • 扫描目录同样可以用父目录 inode id 作为前缀进行扫描

缺点有:

  • 路径解析网络延迟高,需要从 Root 依次递归读取相关节点元数据直到目标节点

  • 例如:MkDir /tmp/foo/bar.txt,有四次元数据网络访问://tmp/tmp/foo/tmp/foo/bar.txt

  • 层级越小,访问热点越明显,从而导致底层存储负载严重不均衡

  • 例如:每个请求都要读取一次根目录/的元数据

考虑到跨目录 Rename 请求在线上集群占比较高的比例,并且对于大目录 Rename 延迟不可控,DanceNN 主要采用第二种方案,方案二的两个缺点通过下面的子树分区来解决。

子树分区

DanceNN 通过将全局 Namespace 进行子树分区,子树被指定一个 NameServer 实例维护子树缓存。

子树缓存

  • 维护这个子树下所有目录和文件元数据的强一致缓存
  • 缓存项有一定淘汰策略包括 LRU,TTL 等
  • 所有请求路径在这个子树下的可以直接访问本地缓存,未命中需要从底层 KV 存储进行加载并填充缓存
  • 通过对缓存项添加版本的方法来指定某个目录下所有元数据的缓存过期,有利于子树快速迁移清理

利用子树本地缓存,路径解析和读请求基本能够命中缓存,降低整体延迟,也避免了靠近根节点访问的热点问题。

路径冻结

  • 在子树迁移、跨子树 Rename 等操作过程中,为了避免请求读取过期的子树缓存,需要将相关的路径进行冻结,冻结期间该路径下的所有操作会被阻塞,由 SDK 负责重试,整个流程在亚秒级内完成
  • 路径冻结后会将该目录下的所有缓存项设置为过期
  • 冻结的路径信息会被持久化到底层的 KV 存储,重启后会重新加载刷新

子树管理

子树管理主要由 NameMaster 负责:

  • 支持通过管理员命令进行手动子树分裂和子树迁移
  • 定期监控集群节点的负载状态,动态调整子树在集群分布
  • 定期统计子树的访问吞吐,提供子树分裂建议,未来支持启发式算法选择子树完成分裂

举个例子,如下图:

目录 / 调度到 NameServer #1,目录 /b 调度到 NameServer #2,目录 /b/d 调度到 NameServer #3

  • MkDir /a 请求发送到 NameServer #1,发送到其他 NameServer 会校验失败,返回重定向错误,让 SDK 刷新缓存重试
  • Stat /b/d 请求将会发送到 NameServer #3,直接读取本地缓存即可
  • ChMod /b 请求将会发送到 NameServer #2,更新 b 目录的权限信息并持久化,对 NameServer #2 和 NameServer #3 进行 Cache 刷新,最后回复客户端

并发控制

底层 KV 存储系统 ByteKV 支持单条记录的 Put、Delete 和 Get 语义,其中 Put 支持 CAS 语义,还提供多条记录的原子性写入接口 WriteBatch。

客户端写操作一般会涉及多个文件或目录的更新,例如 Create /tmp/foobar.txt 会更新 /tmp 的 mtime 记录、创建 foobar.txt 记录等,DanceNN 会将多条记录的更新转换成 ByteKV WriteBatch 请求,保证了整个操作的原子性。

分布式锁管理

虽然 ByteKV 提供事务的 ACID 属性且支持 Snapshot 隔离级别,但是对于多个并发写操作如果涉及底层数据变更之间没有 Overlap 的话,仍然会有 Write Skew 异常,这可能导致元数据完整性被破坏。

其中一个例子是并发 Rename 异常,如下图:

单个 Rename /a /b/d/e 操作或者单个 Rename /b/d /a/c 操作都符合预期,但是如果两者并发执行(且都能成功),可以导致目录 acde 的元数据出现环,破坏了目录树结构的完整性。

我们选择使用分布式锁机制来解决,对于可能导致异常的并发请求进行串行处理,基于底层 KV 存储设计了 Lock Table,支持对于元数据记录进行加锁,提供持久性、水平扩展、读写锁、锁超时清理和幂等功能。

Latch 管理

为了支持对子树内部缓存的并发访问和更新,维护缓存的强一致,会对操作涉及的缓存项进行加锁(Latch),例如:Create /home/tiger/foobar.txt,会先对 tigerfoobar.txt 对应的缓存项加写 Latch,再进行更新操作;Stat /home/tiger 会对 tiger 缓存项加读 Latch,再进行读取。

为了提升服务的整体性能做了非常多的优化,下面列两个重要优化:

  • 热点目录下大量创建和删除文件

例如:有些业务像大型 MapReduce 任务会在相同目录一下子创建几千个目录或文件。

一般来说根据文件系统语义创建文件或目录都会更新父目录相关的元数据(如 HDFS 协议更新父目录的 mtime,POSIX 要求更新父目录 mtime,nlink 等),这就导致同目录下创建文件操作对父目录元数据的更新产生严重的事务冲突,另外底层 KV 存储系统是多机房部署,机房延迟更高,进一步降低了这些操作的并发度。

DanceNN 对于热点目录下的创建删除等操作只加读 latch,之后放到一个 ExecutionQueue 中, 由一个的轻量 Bthread 协程进行后台异步串行处理,将这些请求组合成一定大小的 Batch 发送给底层的 KV 存储,这样避免了底层事务冲突,提升几十倍吞吐。

  • 请求间的相互阻塞

有些场景可能会导致目录的更新请求阻塞了这个目录下的其他请求,例如:

SetXAttr /home/tigerStat /home/tiger/foobar.txt 无法并发执行,因为第一个对 tiger 缓存项加写 Latch,后面请求读 tiger 元数据缓存项会被阻塞。

DanceNN 使用类似 Read-Write-Commit Lock 实现对 Latch 进行管理,每个 Latch 有 Read、Write 和 Commit 三种类型,其中 Read-Read、Read-Write 请求可以并发,Write-Write、Any-Commit 请求互斥。

基于这种实现,上述两个请求能够在保证数据一致性的情况下并发执行。

请求幂等

当客户端因为超时或网络故障而失败时,进行重试会导致同一个请求到达 Server 多次。有些请求如 Create 或者 Unlink 是非幂等的请求,对于这样的操作,需要在 Server 端识别以保证只处理一次。

在单机场景中,我们通常使用一个内存的 Hash 表来处理重试请求,Hash 表的 key 为 {ClientId, CallId},value 为 {State, Response},当请求 A 到来之后,我们会插入 {Inprocess State} 到 Hash 表;这之后,如果重试请求 B 到来,会直接阻塞住请求 B,等待第请求 A 执行成功后唤醒 B。当 A 执行成功之后,我们会将 {Finished State, Response} 写到 Hash 表并唤醒 B,B 会看到更新的 Finished 状态后响应客户端。

类似的 DanceNN 写请求会在底层的 WriteBatch 请求里加一条 Request 记录,这样可以保证后续的重试请求操作一定会在底层出现事务 CAS 失败,上层发现后会读取该 Request 记录直接响应客户端。另外,何时删除 Request 记录呢,我们会给记录设置一个相对较长时间的 TTL,可以保证该记录在 TTL 结束之后一定已经处理完成了。

性能测试

压测环境:

DanceNN 使用 1 台 NameServer,分布式 KV 存储系统使用 100+台数据节点,三机房五副本部署(2 + 2 + 1),跨机房延迟 2-3ms 左右,客户端通过 NNThroughputBenchmark 元数据压测脚本分别使用单线程和 6K 线程并发进行压测。

截取部分延迟和吞吐数据如下:

测试结果表明:

读吞吐:单台 NameServer 支持读请求 500K,随着 NameServer 数量的增加吞吐基本能够线性增长;

写吞吐:目前依赖底层 KV 存储的写事务性能,随着底层 KV 节点数据量的增加也能够实现线性增长。

参考资料

  1. Colossus under the hood: a peek into Google’s scalable storage system
  2. Facebook’s Tectonic Filesystem: Efficiency from Exascale
  3. HopsFS: Scaling Hierarchical File System Metadata Using NewSQL Databases
  4. Azure Data Lake Storage Gen2
  5. Ceph: A Scalable, High-Performance Distributed File System
  6. LocoFS: A Loosely-Coupled Metadata Service for Distributed File Systems
  7. https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/Benchmarking.html#NNThroughputBenchmark
  8. https://en.wikipedia.org/wiki/Snapshot_isolation
  9. https://github.com/apache/incubator-brpc
  10. [字节跳动自研强一致在线 KV &表格存储实践 - 上篇]

本文由哈喽比特于2年以前收录,如有侵权请联系我们。
文章来源:https://mp.weixin.qq.com/s/uJb6iplETFEaO2drL3YF_g

 相关推荐

刘强东夫妇:“移民美国”传言被驳斥

京东创始人刘强东和其妻子章泽天最近成为了互联网舆论关注的焦点。有关他们“移民美国”和在美国购买豪宅的传言在互联网上广泛传播。然而,京东官方通过微博发言人发布的消息澄清了这些传言,称这些言论纯属虚假信息和蓄意捏造。

发布于:1年以前  |  808次阅读  |  详细内容 »

博主曝三大运营商,将集体采购百万台华为Mate60系列

日前,据博主“@超能数码君老周”爆料,国内三大运营商中国移动、中国电信和中国联通预计将集体采购百万台规模的华为Mate60系列手机。

发布于:1年以前  |  770次阅读  |  详细内容 »

ASML CEO警告:出口管制不是可行做法,不要“逼迫中国大陆创新”

据报道,荷兰半导体设备公司ASML正看到美国对华遏制政策的负面影响。阿斯麦(ASML)CEO彼得·温宁克在一档电视节目中分享了他对中国大陆问题以及该公司面临的出口管制和保护主义的看法。彼得曾在多个场合表达了他对出口管制以及中荷经济关系的担忧。

发布于:1年以前  |  756次阅读  |  详细内容 »

抖音中长视频App青桃更名抖音精选,字节再发力对抗B站

今年早些时候,抖音悄然上线了一款名为“青桃”的 App,Slogan 为“看见你的热爱”,根据应用介绍可知,“青桃”是一个属于年轻人的兴趣知识视频平台,由抖音官方出品的中长视频关联版本,整体风格有些类似B站。

发布于:1年以前  |  648次阅读  |  详细内容 »

威马CDO:中国每百户家庭仅17户有车

日前,威马汽车首席数据官梅松林转发了一份“世界各国地区拥车率排行榜”,同时,他发文表示:中国汽车普及率低于非洲国家尼日利亚,每百户家庭仅17户有车。意大利世界排名第一,每十户中九户有车。

发布于:1年以前  |  589次阅读  |  详细内容 »

研究发现维生素 C 等抗氧化剂会刺激癌症生长和转移

近日,一项新的研究发现,维生素 C 和 E 等抗氧化剂会激活一种机制,刺激癌症肿瘤中新血管的生长,帮助它们生长和扩散。

发布于:1年以前  |  449次阅读  |  详细内容 »

苹果据称正引入3D打印技术,用以生产智能手表的钢质底盘

据媒体援引消息人士报道,苹果公司正在测试使用3D打印技术来生产其智能手表的钢质底盘。消息传出后,3D系统一度大涨超10%,不过截至周三收盘,该股涨幅回落至2%以内。

发布于:1年以前  |  446次阅读  |  详细内容 »

千万级抖音网红秀才账号被封禁

9月2日,坐拥千万粉丝的网红主播“秀才”账号被封禁,在社交媒体平台上引发热议。平台相关负责人表示,“秀才”账号违反平台相关规定,已封禁。据知情人士透露,秀才近期被举报存在违法行为,这可能是他被封禁的部分原因。据悉,“秀才”年龄39岁,是安徽省亳州市蒙城县人,抖音网红,粉丝数量超1200万。他曾被称为“中老年...

发布于:1年以前  |  445次阅读  |  详细内容 »

亚马逊股东起诉公司和贝索斯,称其在购买卫星发射服务时忽视了 SpaceX

9月3日消息,亚马逊的一些股东,包括持有该公司股票的一家养老基金,日前对亚马逊、其创始人贝索斯和其董事会提起诉讼,指控他们在为 Project Kuiper 卫星星座项目购买发射服务时“违反了信义义务”。

发布于:1年以前  |  444次阅读  |  详细内容 »

苹果上线AppsbyApple网站,以推广自家应用程序

据消息,为推广自家应用,苹果现推出了一个名为“Apps by Apple”的网站,展示了苹果为旗下产品(如 iPhone、iPad、Apple Watch、Mac 和 Apple TV)开发的各种应用程序。

发布于:1年以前  |  442次阅读  |  详细内容 »

特斯拉美国降价引发投资者不满:“这是短期麻醉剂”

特斯拉本周在美国大幅下调Model S和X售价,引发了该公司一些最坚定支持者的不满。知名特斯拉多头、未来基金(Future Fund)管理合伙人加里·布莱克发帖称,降价是一种“短期麻醉剂”,会让潜在客户等待进一步降价。

发布于:1年以前  |  441次阅读  |  详细内容 »

光刻机巨头阿斯麦:拿到许可,继续对华出口

据外媒9月2日报道,荷兰半导体设备制造商阿斯麦称,尽管荷兰政府颁布的半导体设备出口管制新规9月正式生效,但该公司已获得在2023年底以前向中国运送受限制芯片制造机器的许可。

发布于:1年以前  |  437次阅读  |  详细内容 »

马斯克与库克首次隔空合作:为苹果提供卫星服务

近日,根据美国证券交易委员会的文件显示,苹果卫星服务提供商 Globalstar 近期向马斯克旗下的 SpaceX 支付 6400 万美元(约 4.65 亿元人民币)。用于在 2023-2025 年期间,发射卫星,进一步扩展苹果 iPhone 系列的 SOS 卫星服务。

发布于:1年以前  |  430次阅读  |  详细内容 »

𝕏(推特)调整隐私政策,可拿用户发布的信息训练 AI 模型

据报道,马斯克旗下社交平台𝕏(推特)日前调整了隐私政策,允许 𝕏 使用用户发布的信息来训练其人工智能(AI)模型。新的隐私政策将于 9 月 29 日生效。新政策规定,𝕏可能会使用所收集到的平台信息和公开可用的信息,来帮助训练 𝕏 的机器学习或人工智能模型。

发布于:1年以前  |  428次阅读  |  详细内容 »

荣耀CEO谈华为手机回归:替老同事们高兴,对行业也是好事

9月2日,荣耀CEO赵明在采访中谈及华为手机回归时表示,替老同事们高兴,觉得手机行业,由于华为的回归,让竞争充满了更多的可能性和更多的魅力,对行业来说也是件好事。

发布于:1年以前  |  423次阅读  |  详细内容 »

AI操控无人机能力超越人类冠军

《自然》30日发表的一篇论文报道了一个名为Swift的人工智能(AI)系统,该系统驾驶无人机的能力可在真实世界中一对一冠军赛里战胜人类对手。

发布于:1年以前  |  423次阅读  |  详细内容 »

AI生成的蘑菇科普书存在可致命错误

近日,非营利组织纽约真菌学会(NYMS)发出警告,表示亚马逊为代表的电商平台上,充斥着各种AI生成的蘑菇觅食科普书籍,其中存在诸多错误。

发布于:1年以前  |  420次阅读  |  详细内容 »

社交媒体平台𝕏计划收集用户生物识别数据与工作教育经历

社交媒体平台𝕏(原推特)新隐私政策提到:“在您同意的情况下,我们可能出于安全、安保和身份识别目的收集和使用您的生物识别信息。”

发布于:1年以前  |  411次阅读  |  详细内容 »

国产扫地机器人热销欧洲,国产割草机器人抢占欧洲草坪

2023年德国柏林消费电子展上,各大企业都带来了最新的理念和产品,而高端化、本土化的中国产品正在不断吸引欧洲等国际市场的目光。

发布于:1年以前  |  406次阅读  |  详细内容 »

罗永浩吐槽iPhone15和14不会有区别,除了序列号变了

罗永浩日前在直播中吐槽苹果即将推出的 iPhone 新品,具体内容为:“以我对我‘子公司’的了解,我认为 iPhone 15 跟 iPhone 14 不会有什么区别的,除了序(列)号变了,这个‘不要脸’的东西,这个‘臭厨子’。

发布于:1年以前  |  398次阅读  |  详细内容 »
 相关文章
Android插件化方案 5年以前  |  237227次阅读
vscode超好用的代码书签插件Bookmarks 2年以前  |  8063次阅读
 目录