• 关于

    无感测器控制怎么用

    的搜索结果

问题

【archsummit 回顾】阿里云章文嵩:构建大型云计算平台分布式技术的实践

云课堂 2019-12-01 21:03:36 14448 浏览量 回答数 9

问题

【精品问答】python技术1000问(2)

问问小秘 2019-12-01 22:03:02 3129 浏览量 回答数 1

回答

转自:阿飞的博客 一、数据库技术选型的思考维度 我们做选型的时候首先要问: 谁选型?是负责采购的同学、 DBA 还是业务研发? 如果选型的是采购的同学,他们更注重成本,包括存储方式、网络需求等。 如果选型的是 DBA 同学,他们关心的: ① 运维成本 首先是运维成本,包括监控告警是否完善、是否有备份恢复机制、升级和迁移的成本是否高、社区是否稳定、是否方便调优、排障是否简易等; ② 稳定性 其次,DBA会关注稳定性,包括是否支持数据多副本、服务高可用、多写多活等; ③ 性能 第三是性能,包括延迟、QPS 以及是否支持更高级的分级存储功能等; ④ 拓展性 第四是扩展性,如果业务的需求不确定,是否容易横向扩展和纵向扩容; ⑤ 安全 最后是安全,需要符合审计要求,不容易出现 SQL 注入或拖库情况。 ⑥ 其他 除了采购和 DBA之外,后台应用研发的同学同样会关注稳定性、性能、扩展性等问题,同时也非常关注数据库接口是否便于开发,是否便于修改数据库 schema 等问题。 接下来我们来看一下爱奇艺使用的数据库类型: MySQL,互联网业务必备系统; TiDB,爱奇艺的 TiDB 实践会有另外的具体介绍; Redis,KV 数据库,互联网公司标配; Couchbase,这个在爱奇艺用得比较多,但国内互联网公司用得比较少,接下来的部分会详细说明; 其他,比如 MongoDB、图数据库、自研 KV 数据库 HiKV 等; 大数据分析相关系统,比如 Hive、Impala 等等。 可以看到爱奇艺的数据库种类还是很多的,这会造成业务开发的同学可能不太清楚在他的业务场景下应该选用哪种数据库系统。 那么,我们先对这些数据库按照接口(SQL、NoSQL)和面向的业务场景(OLTP、OLAP)这两位维度进行一个简单非严谨的分类。 下图中,左上角是面向 OLTP、支持 SQL 的这样一类系统,例如 MySQL,一般支持事务不同的隔离级别, QPS 要求比较高,延时比较低,主要用于交易信息和关键数据的存储,比如订单、VIP 信息等。 左下角是 NoSQL 数据库,是一类针对特殊场景做优化的系统,schema 一般比较简单,吞吐量较高、延迟较低,一般用作缓存或者 KV 数据库。 整个右侧都是 OLAP 的大数据分析系统,包括 Clickhouse、Impala等,一般支持SQL、不支持事务,扩展性比较好,可以通过加机器增加数据的存储量,响应延迟较长。 还有一类数据库是比较中立的,在数据量比较小的时候性能比较好,在数据量较大或复杂查询的时候性能也不差,一般通过不同的存储引擎和查询引擎来满足不同的业务需求,我们把它叫做 HTAP,TiDB 就是这样一种数据库。 二、iQIYI对数据库的优化与完善 前面我们提到了很多种的数据库,那么接下来就和大家介绍一下在爱奇艺我们是怎么使用这些数据库的。 1、MySQL在爱奇艺的使用 ① MySQL 首先是 MySQL。MySQL 基本使用方式是 master-slave + 半同步,支持每周全备+每日增量备份。我们做了一些基本功能的增强,首先是增强了数据恢复工具 Xtrabackup 的性能。 之前遇到一个情况,我们有一个全量库是 300G 数据,增量库每天 70G 数据,总数据量 700G 左右。我们当时只需要恢复一个表的数据,但该工具不支持单表恢复,且整库恢复需要 5 个小时。 针对这个情况我们具体排查了原因,发现在数据恢复的过程中需要进行多次写盘的 IO 操作并且有很多串行操作,所以我们做了一些优化。例如删减过程中的一些写盘操作,减少落盘并将数据处理并行化,优化后整库恢复耗时减少到 100 分钟,而且可以直接恢复单表数据。 然后是适配 DDL 和 DML 工具到内部系统,gh-ostt 和 oak-online-alter-table 在数据量大的时候会造成 master-slave 延时,所以我们在使用工具的时候也增加了延时上的考虑,实时探测Master-Slave 库之间延时的情况,如果延时较大会暂停工具的使用,恢复到正常水平再继续。 ② MySQL高可用 第二是 MySQL 高可用。Master-slave 加上半同步这种高可用方式不太完善,所以我们参照了 MHA 并进行了改动,采用 master + agent 的方式。Agent 在每一个物理机上部署,可以监控这个物理机上的所有实例的状态,周期性地向 master 发送心跳,Master 会实时监测各个Agent的状态。 如果 MySQL故障,会启动 Binlog 补偿机制,并切换访问域名完成 failover。考虑到数据库跨机房跨地区部署的情况,MHA 的 master 我们也做了高可用设计,众多 master 会通过 raft 组成一个 raft group,类似 TiDB 的 PD 模块。目前 MySQL failover 策略支持三种方式:同机房、同地域跨机房以及跨地域。 ③ MySQL拓展能力 第三是提高MySQL扩展能力,以提供更大容量的数据存储。扩展方式有 SDK,例如开源的 ShardingSphere,在爱奇艺的使用也比较广泛。另外就是 Proxy,开源的就更多了。但是 SDK 和 Proxy 使用的问题是支持的 SQL 语句简单,扩容难度大,依赖较多且运维复杂,所以部分业务已经迁移至 TiDB。 ④ 审计 第四是审计。我们在 MySQL 上做了一个插件获取全量 SQL 操作,后端打到 Kafka,下游再接入包括 Clickhouse 等目标端进行 SQL 统计分析。除此之外还有安全策略,包括主动探索是否有 SQL 注入及是否存在拖库情况等,并触发对应的告警。 MySQL 审计插件最大的问题是如何降低对 MySQL 性能的影响,对此我们进行了一些测试,发现使用 General Log 对性能损耗较大,有 10%~20% 的降低。 于是我们通过接口来获取 MySQL 插件里的监控项,再把监控项放到 buffer 里边,用两级的 RingBuffer 来保证数据的写入不会有锁资源竞争。在这个插件里再启动一个线程,从 RingBuffer 里读取数据并把数据打包写到 FIFO 管道里。 我们在每台 MySQL 的物理机里再启动一个 Agent,从管道里阻塞地读取数据发至 Kafka。优化后我们再次进行压测,在每台机器上有 15 万的更新、删除或插入操作下不会丢失数据,性能损耗一般情况下小于 2%。 目前已经在公司内部的集群上线了一年时间,运行比较稳定,上线和下线对业务没有影响。 ⑤ 分级存储 第五是分级存储。MySQL 里会存一些过程性的数据,即只需要读写最近一段时间存入的数据,过段时间这些数据就不需要了,需要进行定时清理。 分级存储就是在 MySQL 之上又用了其他存储方式,例如 TiDB 或其他 TokuDB,两者之间可以进行数据自动搬迁和自动归档,同时前端通过 SDK + Proxy 来做统一的访问入口。这样一来,业务的开发同学只需要将数据存入 MySQL 里,读取时可能从后端接入的任意数据库读出。这种方式目前只是过渡使用,之后会根据 TiDB 的特性进行逐步迁移。 Redis在爱奇艺的使用 接下来是 Redis。Redis 也是使用 master - slave 这种方式,由于网络的复杂性我们对 Sentinel 的部署进行了一些特殊配置,在多机房的情况下每个机房配置一定数量 Sentinel 来避免脑裂。 备份恢复方面介绍一个我们的特殊场景,虽然 Redis 是一个缓存,但我们发现不少的业务同学会把它当做一个 KVDB 来使用,在某些情况下会造成数据的丢失。 所以我们做了一个 Redis 实时备份功能,启动一个进程伪装成 Redis 的 Slave 实时获取数据,再放到后端的 KV 存储里,例如 ScyllaDB,如果要恢复就可以从 ScyllaDB 里把数据拉出来。 我们在用 Redis 时最大的痛点就是它对网络的延迟或抖动非常敏感。如有抖动造成 Redis Master 超时,会由 Sentinel 重新选出一个新的节点成为 Master,再把该节点上的数据同步到所有 Slave 上,此过程中数据会放在 Master 节点的 Buffer 里,如果写入的 QPS 很高会造成 Buffer 满溢。如果 Buffer 满后 RDB 文件还没有拷贝过去,重建过程就会失败。 基于这种情况,我们对 Redis 告警做了自动化优化,如有大量 master - slave 重建失败,我们会动态调整一些参数,例如把 Buffer 临时调大等, 此外我们还做了 Redis 集群的自动扩缩容功能。 我们在做 Redis 开发时如果是 Java 语言都会用到 Jedis。用 Jedis 访问客户端分片的 Redis 集群,如果某个分片发生了故障或者 failover,Jedis 就会对所有后端的分片重建连接。如果某一分片发生问题,整个 Redis 的访问性能和 QPS 会大幅降低。针对这个情况我们优化了 Jedis,如果某个分片发生故障,就只针对这个分片进行重建。 在业务访问 Redis 时我们会对 Master 绑定一个读写域名,多个从库绑定读域名。但如果我们进行 Master failover,会将读写域名从某旧 Master 解绑,再绑定到新 Master 节点上。 DNS 本身有一个超时时间,所以数据库做完 failover 后业务程序里没有立刻获取到新的 Master 节点的 IP的话,有可能还会连到原来的机器上,造成访问失败。 我们的解决方法是把 DNS 的 TTL 缩短,但对 DNS 服务又会造成很大的压力,所以我们在 SDK 上提供 Redis 的名字服务 RNS,RNS 从 Sentinel 里获取集群的拓扑和拓扑的变化情况,如果集群 failover,Sentinel 会接到通知,客户端就可以通过 RNS 来获取新的 Master 节点的 IP 地址。我们去掉域名,通过 IP 地址来访问整个集群,屏蔽了 DNS 的超时,缩短了故障的恢复时间。 SDK 上还做了一些功能,例如 Load Balance 以及故障检测,比如某个节点延时较高的话会被临时熔断等。 客户端分片的方式会造成 Redis 的扩容非常痛苦,如果客户端已经进行了一定量的分片,之后再增加就会非常艰难。 Redis 在 3.0 版本后会提供 Redis Cluster,因为功能受限在爱奇艺应用的不是很多,例如不支持显示跨 DC 部署和访问,读写只在主库上等。 我们某些业务场景下会使用 Redis 集群,例如数据库访问只发生在本 DC,我们会在 DC 内部进行 Cluster 部署。 但有些业务在使用的过程中还是想做 failover,如果集群故障可以切换到其他集群。根据这种情况我们做了一个 Proxy,读写都通过它来进行。写入数据时 Proxy 会做一个旁路,把新增的数据写在 Kafka 里,后台启用同步程序再把 Kafka 里的数据同步到其他集群,但存在一些限制,比如我们没有做冲突检测,所以集群间数据需要业务的同学做单元化。线上环境的Redis Cluster 集群间场景跨 DC 同步 需要 50 毫秒左右的时间。 2、Couchbase在爱奇艺的使用 Redis 虽然提供 Cluster 这种部署方式,但存在一些问题。所以数据量较大的时候(经验是 160G),就不推荐 Redis 了,而是采用另一种存储方式 Couchbase。 Couchbase 在国内互联网公司用的比较少,一开始我们是把他当做一个 Memcached 来使用的,即纯粹的缓存系统。 但其实它性能还是比较强大的,是一个分布式高性能的 KV 系统,支持多种存储引擎 (bucket)。第一种是 Memcached bucket,使用方式和 Memcached 一样为 KV 存储,不支持数据持久化也没有数据副本,如果节点故障会丢失数据; 第二种是 Couchbase bucket,支持数据持久化,使用 Json 写入,有副本,我们一般会在线上配置两个副本,如果新加节点会对数据进行 rebalance,爱奇艺使用的一般是 Couchbase bucket 这种配置。 Couchbase 数据的分布如下图,数据写入时在客户端上会先进行一次哈希运算,运算完后会定位 Key 在哪一个 vBucket (相当于数据库里的某个分片)。之后客户端会根据 Cluster Map 发送信息至对应的服务端,客户端的 Cluster Map 保存的是 vBucket 和服务器的映射关系,在服务端数据迁移的过程中客户端的 Cluster Map 映射关系会动态更新,因此客户端对于服务端的 failover 操作不需要做特殊处理,但可能在 rebalance 过程中会有短暂的超时,导致的告警对业务影响不大。 Couchbase 在爱奇艺应用比较早,2012 年还没有 Redis Cluster 的时候就开始使用了。集群管理使用 erlang 语言开发,最大功能是进行集群间的复制,提供多种复制方式:单向、双向、星型、环式、链式等。 爱奇艺从最初的 1.8 版本使用到如今的 5.0 版本,正在调研的 6.0,中间也遇到了很多坑,例如 NTP 时间配置出错会导致崩溃,如果每个集群对外 XDCR 并发过高导致不稳定,同步方向变更会导致数据丢失等等,我们通过运维和一些外部工具来进行规避。 Couchbase 的集群是独立集群,集群间的数据同步通过 XDCR,我们一般配置为双向同步。对于业务来说,如果 Cluster 1 写入, Cluster 2 不写入,正常情况下客户端会写 Cluster 1。如果 Cluster 1 有故障,我们提供了一个 Java SDK,可以在配置中心把写入更改到 Cluster 2,把原来到 Cluster 1 的连接逐步断掉再与Cluster 2 新建连接。这种集群 failover 的过程对于客户端来说是相对透明和无感的。 3、爱奇艺自研数据库HiKV的使用 Couchbase 虽然性能非常高,并且数据的存储可以超过内存。但是,如果数据量超过内存 75% 这个阈值,性能就会下降地特别快。在爱奇艺,我们会把数据量控制在可用内存的范围之内,当做内存数据库使用。但是它的成本非常高,所以我们后面又开发了一个新的数据库—— HiKV。 开发 HiKV 的目的是为了把一些对性能要求没那么高的 Couchbase 应用迁移到 HiKV 上。HiKV 基于开源系统 ScyllaDB,主要使用了其分布式数据库的管理功能,增加了单机存储引擎 HiKV。 ScyllaDB 比较吸引人的是它宣称性能高于 Cassandra 十倍,又完全兼容 Cassandra 接口,设计基本一致,可以视为 C++ 版 Cassandra 系统。 ScyllaDB 性能的提升主要是使用了一些新的技术框架,例如 C++ 异步框架 seastar,主要原理是在j每台物理机的核上会 attach 一个应用线程,每个核上有自己独立的内存、网络、IO 资源,核与核之间没有数据共享但可以通信,其最大的好处是内存访问无锁,没有冲突过程。 当一个数据读或写到达 ScyllaDB 的 server 时,会按照哈希算法来判断请求的 Key 是否是该线程需要处理的,如果是则本线程处理,否则会转发到对应线程上去。 除此之外,它还支持多副本、多数据中心、多写多活,功能比较强大。 在爱奇艺,我们基于 SSD 做了一个 KV 存储引擎。Key 放在内存里,Value 放在盘上的文件里,我们在读和写文件时,只需要在内存索引里定位,再进行一次盘的 IO 开销就可以把数据读出来,相比 ScyllaDB 原本基于 LSM Tree 的存储引擎方式对 IO 的开销较少。 索引数据全部放在内存中,如果索引长度较长会限制单机可存储的数据量,于是我们通过开发定长的内存分布器,对于比较长的 Key 做摘要缩短长度至 20 字节,采用红黑树索引,限制每条记录在内存里的索引长度至为 64 字节。内存数据要定期做 checkpoint,客户端要做限流、熔断等。 HiKV 目前在爱奇艺应用范围比较大,截至目前已经替换了 30% 的 Couchbase,有效地降低了存储成本。 4、爱奇艺的数据库运维管理 爱奇艺数据库种类较多,如何高效地运维和管理这些数据库也是经历了不同的阶段。 最初我们通过 DBA 写脚本的方式管理,如果脚本出问题就找 DBA,导致了 DBA 特别忙碌。 第二个阶段我们考虑让大家自己去查问题的答案,于是在内部构建了一个私有云,通过 Web 的方式展示数据库运行状态,让业务的同学可以自己去申请集群,一些简单的操作也可以通过自服务平台实现,解放了 DBA。一些需要人工处理的大型运维操作经常会造成一些人为故障,敲错参数造成数据丢失等。 于是在第三个阶段我们把运维操作 Web 化,通过网页点击可以进行 90% 的操作。 第四个阶段让经验丰富的 DBA 把自身经验变成一些工具,比如有业务同学说 MySQL master-slave 延时了,DBA 会通过一系列操作排查问题。现在我们把这些操作串起来形成一套工具,出问题时业务的同学可以自己通过网页上的一键诊断工具去排查,自助进行处理。 除此之外我们还会定期做预警检查,对业务集群里潜在的问题进行预警报告;开发智能客服,回答问题;通过监控的数据对实例打标签,进行削峰填谷地智能调度,提高资源利用率。 三、不同场景下数据库选型建议 1、实用数据库选型树 最后来说一些具体数据库选型建议。这是 DBA 和业务一起,通过经验得出来的一些结论。 对于关系型数据库的选型来说,可以从数据量和扩展性两个维度考虑,再根据数据库有没有冷备、要不要使用 Toku 存储引擎,要不要使用 Proxy 等等进行抉择。 NoSQL 也是什么情况下使用 master-slave,什么情况下使用客户端分片、集群、Couchbase、HiKV 等,我们内部自服务平台上都有这个选型树信息。 2、一些思考 ① 需求 我们在选型时先思考需求,判断需求是否真实。 你可以从数据量、QPS、延时等方面考虑需求,但这些都是真实需求吗?是否可以通过其他方式把这个需求消耗掉,例如在数据量大的情况下可以先做数据编码或者压缩,数据量可能就降下来了。 不要把所有需求都推到数据库层面,它其实是一个兜底的系统。 ② 选择 第二个思考的点是对于某个数据库系统或是某个技术选型我们应该考虑什么?是因为热门吗?还是因为技术上比较先进?但是不是能真正地解决你的问题?如果你数据量不是很大的话就不需要选择可以存储大数据量的系统。 ③ 放弃 第三是放弃,当你放弃一个系统时真的是因为不好用吗?还是没有用好?放弃一个东西很难,但在放弃时最好有一个充分的理由,包括实测的结果。 ④ 自研 第四是自研,在需要自己开发数据库时可以参考和使用一些成熟的产品,但不要盲目自研。 ⑤ 开源 最后是开源,要有拥抱开源的态度。

茶什i 2019-12-27 14:17:56 0 浏览量 回答数 0

阿里云试用中心,为您提供0门槛上云实践机会!

0元试用32+款产品,最高免费12个月!拨打95187-1,咨询专业上云建议!

回答

【丁宁-清华大学-阿里达摩院自然语言技术实习体验】 作者简介:丁宁,清华大学计算机科学与技术系2年级博士生,研究方向为自然语言处理、信息抽取、语言表示学习等,在ACL、EMNLP、AAAI、IJCAI等发表多篇文章,作为研究型实习生在阿里达摩院实习半年+。 实习体会 很幸运能来到阿里巴巴进行实习!组里的氛围特别好,同事和师兄师姐都非常专业、友善、亲切。无论是科研上还是工作生活上的任 何问题,都能得到慷慨的帮助。在这里,我认识了一批学术和生活上的榜样(我的主管每天都吃健康餐,而我牛肉汤泡饼),结交了志同道合的朋友(排队喝牛肉汤回来写论文的日子),见识到了IT同学的认真负责(远程帮我调试打印机,周末修电脑),见过了马云老师,也亲身经历了一次双十一奋战。阿里的科研积淀和文化氛围都让我感到收获颇丰,感谢阿里巴巴提供研究型实习生这一高水平项目,也期待更多的同学可以加入研究型实习生的大家庭。 科研心得& 工作宣传 今年在阿里巴巴所做的跨领域分词工作被ACL 2020高分接收,其中meta review说“well-written, well-motivated with strong results, sure accept”。其实这句话可以很好地总结评判科研论文好坏的标准,实际上或许现阶段的科研也并没有什么秘密,动机明确、方法得当、实验充分,就可以形成一篇不错的科研论文。当然了,如果想做出让领域内眼前一亮的工作,可能就需要一些灵光一闪了。 具体到我们的工作上来,跨领域任务往往面临目标领域精标注数据缺失的问题,具体到分词任务上来说,这种数据缺失往往会导致OOV和词的分布差异问题。本文通过弱监督启发式算法来进行远程标注,并引入对抗学习来进行降噪。本文的实验中以newswire (新闻语料)作为源领域,在5个不同的目标领域数据上都取得了较好的效果。 这个工作或许有助于我们真正的往跨领域的两个通用问题上去设计了相关的解决办法。论文名字:《Coupling Distant Annotation and Adversarial Training for Cross-Domain Chinese Word Segmentation》,具体可以查看达摩院的官方宣传~:ACL 2020有哪些值得关注的论文? - 阿里巴巴达摩院的回答 - 知乎https://www.zhihu.com/question/385259014/answer/1190808208 另外,也宣传一下作为co-author的另一篇ACL 2020论文,是实习生同事周洁(上海交大研究生)的工作,瞄准多层级文本分类任务,设计层级敏感编码器将多层结构作为有向图建模,并且实现了一个串行和并行的版本,论文名字:Hierarchy-Aware Global Model for Hierarchical Text Classification。 还有另一个实习生同事张浩宇(国防科大博士生)在IJCAI 2020的工作,使用noisy learning的方法去进行远程监督entity typing降噪,方法非常优雅,论文名字:Learning with Noise: Improving Distantly-Supervised Fine-grained Entity Typing via Automatic Relabeling。 【杜志浩-哈尔滨工业大学-我在达摩院作实习研究僧的那些事儿】 经韩老师介绍,2019年7月,有幸进入阿里巴巴达摩院成为一名实习研究僧。如今也已半年有余,期间发生的事情仍然历历在目。从初出茅庐的不安,到积极融入的快乐,再到宠辱不惊的泰然,一路走来收获良多! 初出茅庐 其实,刚到达摩院语音算法组时,我的内心充满了不安。这种不安来自于初出茅庐的不自信,不知自己能否胜任这份工作,为公司带来效益。同时,也来自于环境转变的不适应,换了一个全新的环境,对公司内的工作方式、待人接物都不甚了解。 但是,在算法组师兄师姐的帮助下,我的这些不安很快就烟消云散了。为了能够使我尽快熟悉工作内容、了解工作方式,雷鸣师兄坚持每周四晚上为实习生开组会,拉着仕良哥、智颖等很多小伙伴一起讨论算法思路和实验中遇到的问题。我想他们应该都挺忙的吧,但还是牺牲自己休息的时间来参加组会。 刚来的那段时间,除了“雷老师,xxx麻烦审批通过一下”以外,我说的最多的恐怕就是“xx姐/哥,xxx在哪”。由于对很多事情都不了解,比如服务器怎么申请啊,oss怎么弄啊,我总是要麻烦逍北姐、遥仙哥等目之所及的小伙伴。他们一边在忙自己的工作一边还不厌其烦的告诉我,为我提供了莫大的帮助。 积极融入 在算法组这段时间,让我印象最为深刻的一句话就是“我们做事情都很直接,有什么问题,就带着方案提出来”。以前,总是被教育和鼓励发现问题,在阿里,找到问题只是完成了第一步,还需要再提出一个切实可行的解决方案。期间发生的一段小插曲让我现在依然记忆犹新。  为了准备910,语音测试组的小伙伴每天都在紧张的进行测试。其中一项是对语音实时转录及翻译软件的稳定性测试。由于已经进入应用阶段,不能在直接将数据送入到模型中,需要将语音播放出来,再由软件录音进行测试。播放的内容是马老师的演讲,对于坐在旁边的小伙伴来说既是一件好事,也是一件坏事。由于马老师的演讲实在太引人入胜了,每次他们进行测试时,我们都无法专心工作,最终只能……。 咳咳,我心想,这么下去也不是事儿啊,梦想要有,生活也得继续啊,得想想办法解决一下这个问题。我尝试了各种办法,但似乎都无法绕过功放这个问题。最终功夫不负有心人,找到了一款虚拟声卡的软件,能够将一个应用程序的音频输出直接作为另一个应用程序的输入。在熟悉过这个软件的使用方式后,我找到测试组的组长,向他提出了我现在的处境和解决方案。他告诉我,他也知道这样会打扰到周边的人,但是之前也没有太好的办法,感谢我提出的解决方案。 虽然这只是实习期间的一段小插曲,但是我依然印象深刻。通过这件事,我践行了带着方案提问题,这一阿里人所特有的工作方式,让我感觉自己正在逐渐融入到这个集体当中。 宠辱不惊 经过几个月“死去”又“活来”的做实验、写论文,我跟雷鸣师兄合作的语音增强相关工作投稿到了ICASSP 2020。这是语音信号处理领域的顶级会议,在来阿里之前,我也投稿过一次,但不幸被拒。为了准备这篇文章,雷鸣师兄跟我保持着很高互动,了解实验进度,适时的进行指导。此外,还有仕良哥帮助我进行语音畸变的评估。 2020年1月25日这一天,是我国的传统节日,春节,同时也是ICASSP出结果的日子。在得知结果前,我的内心非常忐忑。但当得知接收的喜讯时,我反而没有想象中那么兴奋,没有想象中那么高兴。我的第一反应是看看审稿人的意见,看看我专家们对我文章的看法,还有哪些不足和需要改进的地方。 我想宠辱不惊的心态应该是我在阿里的一个重要收获吧,不以物喜不以己悲。尽力做好自己该做的事儿,结果自然水到渠成。 再说两句 在阿里的这段实习使我受益匪浅。这里有乐于助人、善解人意的师兄师姐,也有认真负责、要求严格的主管Leader;有弹性自由的工作时间,也有肝到深夜的满腔热情;有最新最热的研究成果,也有成熟稳定的应用软件。这里不像实验室的象牙塔,关注技术的同时,也更关注技术如何落地、如何应用到生活中去,最终如何造福亿万用户。 韩鹏-KAUST-青春没有我之阿里巴巴天猫精灵争夺赛被迫写的研究心得 竞选宣言: 在阿里实习摸了几个月的鱼,最开心的就是又吃到了祖国的美食,虽然杭州的食物实在是太清淡了,但总比我在沙特每天吃水煮青菜不放盐要好很多。在阿里的这几个月,让我看淡了很多,发现生命里比较重要的就是长在自己脑袋上的头发,不能太年轻就失去他们。女网红我是感觉自己这辈子没机会了,毕竟流量明星也不是靠推荐算法能捧红的,也就希望能够得到这次500块钱的天猫精灵,请大家pick我。 研究心得: 多抱大腿 为了凑足300字的内心情感白描: 这个世界实在是太无聊了,尤其疫情导致的只能居家办公,我已经憋得快精神失常了,虽然平时也不是那么正常。希望这个世界早日恢复原来的美好,我还打算去越南胡志明市的日式KTV感受一下女仆装呢,希望疫情不会让这些服务业倒闭呢吧。 居然还不够300字,感觉生命浪费在写文字上要比大保健上还是好一些的,希望这些文字能够启发你,虽然我感觉也并没有什么意义,而人活着的意义又是什么呢? 【韩镕罄-南加州大学- 阿里研究型实习生体验】 简介: 经过两年研究时间,找到了学校的教职,也找到了老婆,感谢阿里~ 2018年八月来阿里做研究型实习生,本人在南加州大学商学院读Operations Management 的Ph.D. 块两年时间做了几篇 field experiment paper, 感觉阿里有太多好玩有趣的商业问题可以讨论直接研究。 通过和阿里的合作顺利找到UIUC 伊利诺伊大学香槟分校的常任轨教职。 更神奇的是,在实习期间,随便刷个阿里妹儿的相亲帖, 加个微信 聊一聊 发现和自己一天生日。 就是你了!现在已经结婚快半年! 三十而立,一切静好,感谢阿里! 【马腾-清华大学- 阿里巴巴RI项目心得】 我与阿里之缘 在2019年的夏天,后来成为我主管的文侑来到清华进行交流,当时的我刚刚完成了一个学术项目的研究,正在寻求于之后的研究方向。恰好在交流会上碰见了文侑,经过一番交流之后吗,了解到操作系统团队是阿里 RDMA 技术的先行者和推广者,这正是我计划之后想要研究的方向,于是便一拍即合。由于我之前所研究的领域刚好符合是阿里目前正在做的一些项目,所以文侑提供了一个可以在阿里实习的机会。 在通过了多轮面试之后,我终于成功的入职了操作系统内核组作为学术型实习生。从2018年九月初入职至今,将近两年的时间,我也逐渐地适应了在阿里的生活,松弛有度而又充满欢乐。在这里我也结识了许多要好的朋友,并且,通过公司组织的各种聚会和团建的活动,让我解释了许多有着共同语言爱好的伙伴,大家给与了我这个新人很多的帮助和照顾,使我也渐渐地融入了这个有爱的团队。 在阿里的学术成果 在阿里实习期间,在同事们的帮助下,我顺利地完成了两个与我所在实验室合作的学术项目,并且这两个项目也幸运的产出了两篇高质量的论文,分别发表在了不同领域的高水平会议当中。 其中,第一篇论文发表在第21届Cluster会议,与2019年在美国阿尔伯克基召开。Cluster 是高性能计算方向计算机系统领域的主要会议,这个工作提出并实现了统一高效的 RDMA 消息中间件,解决了 RDMA 在实际生产过程中的一些关键可靠性和可用性问题,例如:极简的接口抽象,必要的上层消息确认机制,中间件辅助流控配合 DCQCN,结合生产系统的诊断机制等等,目前该技术已经被广泛应用在阿里巴巴基础云产品中(包括:数据库,分布式存储等)。另外一个工作则发表在了第25届 ASPLOS会议。ASPLOS 是操作系统,体系结构和编程语言三个方向综合的计算机系统领域顶级会议。这篇论文是和我所在的清华高性能所合作完成的,文章中第一次提出了利用RDMA将数据中心的NVM做disaggregation, 实现了高效的框架,同时证明了这种新架构的可行性。 在阿里的感想 阿里巴巴操作系统团队是一直致力于建立和完善系统领域工业界和学术界的纽带,并且在持续实践工业界和学术界之间的问题分享和工作互动,他们希望通过这些分析和互动能够更好地促进中国在世界计算机系统领域的整体发展和创新。作为操作系统团队中的一员,我深切了解到了先进技术对于企业发展的重要性,在实习的过程中,同我所在的实验室进行合作,我更是深深感受到只有通过学术与工业相辅相成,才能够真正让企业发展先进技术。另外一方面,经过一段时间的实习,我对所在的操作系统团队和阿里技术部门的工作有了更深入的了解,我对自己也有了进一步的规划,计划在毕业之后能够入职阿里,通过我的努力,继续在追逐技术之路上奋斗着。 【亓家鑫-新加坡南洋理工大学- 阿里云实习心得】 非常荣幸我们的研究工作*《Two causal principles for improving visual dialog》*获得了同行的认可,并收录在CVPR 2020会议中。在此要特别感谢我的教授,MReaL实验室成员以及阿里城市大脑实验室师兄师姐一直以来的支持和帮助。比起论文本身的内容,我更希望跟大家分享一年来做研究的心得和感悟,虽然目前我仍然是一个萌新,不过我希望通过萌新的角度能带给大家一些研究上的启发。 开始一个研究之前,选择方向很重要。当然,每一个方向都有自己的优缺点,比如新的方向“容易”发文章,可能将其他领域原有的方法引入加一些调整就可以达到比较高的结果。不过如果没有坚实的创新,在同行评议时,可能会受到质疑。一旦没有通过,再转投时可能发现已经落后于其他人。“老“的方向可能会感觉灌水困难,不过因为我没有真正做过经典的方向,所以不太好发表评论。根据观察,在一堆全面而又坚实的研究中找到创新点,对萌新来说确实困难,不过一旦有所突破,肯定会对这个社区产生广泛的影响。作为一个萌新,可能不会自己选择方向或者领域,所以接受导师或者主管的安排成了唯一的选择,不过要相信自己的导师和主管,因为大家都是在帮助你,而且他们经验丰富。只有当自己走完一套研究的流程,并且真正找到自己感兴趣或者觉得可以有所突破的方向,那可能才是真正属于自己的研究的开始。 当选定了方向,开始做研究的时候,清楚的了解所有有关的方法是非常重要的,因为这样可以防止你的idea被存在的方法“抄袭“。其实对一个比较成熟的研究方向来说,简单思考得到的idea一般都会被提出过。不过研究完所有存在方法后,要跳出这些方法,因为阅读他们的方法可能不是来借鉴,更多的是防止撞车,想要真正有创新,在别人的方法上改动往往是不够的,这就要求我们重新审视这个任务甚至数据集的每一个样本。当然目前即使是学术界toy的数据集也有动辄几十万的数据量,看完是不可能的,不过根据自己的思路统计一些数据特征,有时候对研究会产生很大的帮助。当觉得自己已经掌握了这个数据集或者这个任务的时候,应该是跑一些baseline来练习了。 我作为萌新,没有从零开始写,而是找了一个现成的模型开始修改,这样难度会减少很多,不过毕竟是别人的代码,还是有很多不舒服的地方,所以等自己成熟了的时候,有空的时候,一定要从头写一遍。当然我也不知道什么时候有空。当我开始修改baseline的时候,此次的研究旅行就算是上路了,在接受导师的指引的同时也可以自己不断的尝试自己的想法,因为不知道什么是有用的。我作为萌新刚开始的感受是我觉得可能我想的都有用,那一定要去试一下,所以我也建议大家多试一下,说不定真的有用呢,反正电费不花自己的。当一个东西有用的时候,就可以来思考他为什么有用了,当你想好它为什么有用并且通过了广泛的测试,就到了跟大家分享成果的时候。 当然,一个有用的idea背后可能有无数个没用的idea,至于他们为什么没用,我觉得如果实在是有兴趣,可以研究一下,但是有时候会花大量的时间。举一个实际的例子,我在去年做visual dialog比赛,大概四月份就发现了一个有用的方法,之后也顺利的拿到了第一并且在此基础上进行探究和扩展发表了自己的成果。不过同时,当时有一个效果降低的操作一直困扰着我,直到六个月以后,当然这六个月中还做了其他的事情,我才发现了它真正的原因,并且最终变成了我文章中的一句话。举这个例子的目的是,研究没有效果的idea会对研究有所帮助,不过可能会收益较低。 研究成果的发表是一个很重要的过程,它可以给领域内的同行以启发,甚至可以影响本领域之外的人,所以有时候高度总结自己的思想是一件有用的事情。比如我所做的工作我认为进行高度总结之后可以得到一个启发是:对多模态任务来说不一定所有模态都是平等的,对模型来说所存在模态也不一定是影响结果的全部。除了对自己motivation的总结,应用细节以及结果展示也是非常重要的,因为我是萌新,怎样写出一篇文章的经验肯定是不足的,所以在此不再赘述。在发表完文章之后,“售后服务“也是非常重要的一点,这也是我的教授教我的很重要的理念。因为发表的内容不是刊登出来就结束了,而是你对社区贡献的开始,之后做研究可能会发现更好的实现,或者当时的理论没有讲清楚完善,这些都可以补充到自己的代码中,让大家更好的了解你的思路和工作,或许以后还能收获好评。 此外,实验室的成员就是自己研究道路上的引导者和伙伴,会对自己的研究产生各种各样至关重要的影响,大多时候大家都不会吝惜跟你讨论分享自己的观点,有时还会亲自帮助你解决问题,所以要记得经常参加团建和小集体聚会。不过也不能太依赖别人,每当遇到问题的时候,特别是技术性的问题,还是依靠自己解决的好,毕竟未来总会离开实验室,离开乐于帮助你的人。最后,保护好自己的头发,还是要早睡早起,调不出来的bug熬夜也调不出来,不work的idea可能真的不work,没有人保证炼出来的一定是金子,不要过分影响正常的作息,毕竟这不是百米赛跑,也不能算是马拉松,而是长久的起码好几年以上要坚持的事业。不过我作为萌新才刚刚起步,依然没有体会到最艰难的时刻,不过做好心理准备还是应该的,该来的总是会来的。最后的最后希望这些浅显的经验总结能够给大家带来一点儿帮助,谢谢大家的阅读。 【田冰川-南京大学- 在阿里网络团队实习两年是一种怎样的体验?】 简介: 大家好!我是田冰川,南京大学2016级直博生,导师为田臣老师,研究方向为计算机网络。2018年6月,我以研究型实习生的身份入职阿里巴巴基础设施事业部网络研究团队,实习期间主要从事网络验证相关的研究工作,即通过形式化方法与灰度测试,来降低网络变更中的潜在风险。 2018年既是网络研究团队刚刚组建的一年,也是研究型实习生在阿里刚刚起步的一年。这年春天,经我导师田臣老师介绍,我参加了研究型实习生面试,加入了网络研究团队。 来到团队后,我参加的第一个研究项目是“金睛”,用以保障复杂ACL变更的正确性。ACL即访问控制列表,网络中的ACL决定着流量的连通性。网络架构演化有时会伴随着对ACL的迁移,如何保证迁移前后网络连通性是等价的,是困扰架构与运营部门的一大难题,而金睛项目则是为该问题而生。项目落地以来,金睛系统多次在骨干网ACL迁移中对变更方案进行了验证,并逐渐扩展至对边缘网络的验证。相关论文发表于SIGCOMM 2019主会,我在会场进行了20余分钟的演讲,与我们团队的另一篇文章HPCC共同成为阿里集团在网络领域top1学术会议主会中的首次亮相。 时间总是过的很快。转眼间,我来阿里已经两年了,自金睛之后,又陆续参与了多个研究课题。在阿里的时间越久,就越能切身体会到学术界研究与工业界研究的不同。在阿里实习以来,我接触到的所有研究课题,都不是凭空“想”出来的空中楼阁,更不是靠别人论文“启发”出来的二手课题,而是源自于真实业务的现阶段瓶颈与下一阶段发展趋势——这一点是高校科研很难做到的。 这两年间,我对科研这件事的心态也发生了进一步的变化。2017年,来到阿里之前,我的论文达到了学校博士毕业的最低要求,相当于没有了毕业之忧,对科研的心态从“先拿到博士学位再说”,变成了“想要做出点什么,不想让自己的博士5年就这么水过去”;在来到阿里,接触到工业界的前沿课题之后,我对科研的心态再一次发生了转变,变成“因为认可一件事的价值,所以想要去做好”——这已经成为一种内在的驱动力,让我在认真工作的同时,享受研究带来的乐趣。 如果一切顺利的话,我将于2021年6月博士毕业。能在阿里巴巴度过专属实习生的“三年醇”,想必也是人生中的一大成就了! 【吴秉哲-北京大学- 吴师傅的博士研究课题:大数据时代的数据隐私研究方向初探】 加上本科的时间,不知不觉已经在燕园里面呆了八年了,明年不出意外应该就会离开学校去业界工作。准备最近以文章的形式梳理一下博士几年的研究以及生活的心路历程。由于内容比较分散,所以决定分为几个不同的部分。这次推送封面图片是16年骑行到加乌拉山口遥看喜马拉雅山脉的图片,而我在阿里的花名是风远,意为远处的风。希望多年之后,还有一颗少年的心,投入每天永不变。这次借着阿里内部一个活动的机会,写了今天的这篇稿子,为大家介绍一下我的thesis topic。 已经在蚂蚁实习了一年了,一年时光匆匆而过,而在蚂蚁金服度过的这段时光带给了我很多研究以及生活中的体验,这一年里学到的经验也将伴随着我之后的研究之路。 我本科四年是在数院度过,在研究生阶段决定转换方向到计算机系。博士的前两年一直在跌跌撞撞地寻找自己的研究方向,尝试过很多方向均以失败告终。终于在第三年的时候,误打误撞开始研究起机器学习的隐私保护问题并找到了很多灵感,开始沉淀了一些基本的研究工作。有一天我从一个朋友那里听到了她关于金服这边隐私保护机器学习的团队介绍,当时我就决定要到业界的前沿去看一看隐私保护的真实业界需求。在此之前,我已经在谷歌,IBM等公司有过多段实习的经历,但是在蚂蚁这一次实习经历,是与我自己研究方向最接近,也是时间最长的一次。借着这次约稿的机会,以此文简单总结一下自己过去两年在这一方向的研究。 隐私保护与共享学习 目前随着各种机器学习算法在集团的业务落地,许多隐私泄露与数据滥用的风险相继而来。 尤其是在蚂蚁金服这样一个拥有很多支付数据的企业,数据安全以及隐私保护的重要性更是不言而喻。站在商业合作的角度,如何实现不同公司或者部门之间的数据共享学习也是我所在的团队现在攻坚的一个问题。在这样一个研究背景下,我来到了蚂蚁金服的共享智能团队,开始和师兄师姐们从不同的维度对上述问题展开了深入的研究。 共享学习这样一个概念听起来很美好,但是实际落地起来却困难重重,需要考虑到上层软件算法的设计以及底层系统和硬件的优化,才有可能真正在实际的业务中兼顾效率和隐私保护强度。共享智能团队在这一方向上有着得天独厚的优势。一是领先的业务场景,在国际同行好多还停留在学术研究阶段时,我们团队已经和国内多家银行有了合作。另一个则是技术沉淀的领先。因为金服自身业务的特殊性,我们团队很早就开始了隐私保护机器学习和共享学习的布局,包括很多原始的技术沉淀,强大的工程团队以及学术预研团队。这些积累也使得我们能够很快地摸清最新的一些研究成果并能将其吸入到我们自己的系统当中。 我自己关于隐私保护机器学习的研究主要是围绕着三个层面展开,分别是理论,算法设计,以及系统和硬件优化。在理论层面,我主要针对现有的各种机器学习算法,建立相应的隐私泄露分析框架,比如我们在之前的工作中,针对一种常用的贝叶斯学习的算法根据雷尼差分隐私建立了隐私泄露的定量分析框架,我们进一步使用我们的框架和已有的一些泛化误差上界做了联系,从而能从多个角度去解释该算法的隐私泄露原因。在算法设计层面,我们针对各种已有的新兴算法以及场景,比如图神经网络,推荐系统建立了相应的共享学习算法,并利用我们的理论框架,对这些算法的隐私保护强度做了定量的评估。除开上层的理论和算法设计,底层的系统和硬件的优化同样是非常重要的一环。 在我们团队,我们主打基于硬件可信执行环境 (TEE)的机器学习serving系统,我针对我们当前这套服务系统,结合神经网络计算的一些特点,定制了该系统的一系列优化措施大大提升了整个系统的吞吐量。我也将其中一些措施注册了专利,并在前几天得到了内部的专利授权。除开上述介绍的学术研究方面的成果,我也参与了IEEE共享学习标准的制定会议,这也使得我从标准制定者的角度去更深地思考如何使用技术在未来社会中实现隐私与效率的兼顾。 总之,我自己很感谢能成为共享智能团队的一员,我在这里学到的最宝贵的经验就是详细地从上到下了解了这样一个大团队的合作与分工,学习他们是如何一步步从最初的需求分析,算法设计,到最后真正的业务落地。也很高兴和各位共享智能的同事度过自己博士生涯中很重要的一年。也非常感谢我的博士导师对我研究的无条件支持。回看博士这一路的艰辛,也是感慨万千。有点像自己之前高原骑行的经历,经历了爬到坡顶的缺氧与无力,终在转角处遇见了骑行途中最美的雪山风光。

游客bnlxddh3fwntw 2020-05-19 16:05:51 0 浏览量 回答数 0
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 企业信息查询 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站 阿里云双十一主会场 阿里云双十一新人会场 1024程序员加油包 阿里云双十一拼团会场 场景化解决方案 阿里云双十一直播大厅