迁移

数据库作为企业外围的数据存储引擎，在其提供服务的过程中，常常会因为各种各样的起因须要进行数据的迁徙。数据库迁徙作为一个古老的话题并不神秘，但因为迁徙数据的重要性，以及业务对数据库可用性的高要求，导致数据库迁徙的复杂度极高，个别都须要业余工具的帮助能力实现。以后 ，市面上也曾经提供了各种各样的数据库迁徙工具。本文将介绍数据库迁徙的步骤以及市面上常见的迁徙工具。 一、 为什么要做数据库迁徙数据库在提供服务的过程中，常常须要进行数据迁徙，常见的场景包含： 数据库上云迁徙，业务上云，要求数据库上云，此时波及数据库的迁徙；数据库跨云迁徙，业务须要跨云迁徙时，要求数据库跨云迁徙；数据库版本升级，例如数据库内核公布新版本，须要从旧版本迁徙到新版本；数据库扩容或缩容，例如数据库所在服务器资源有余，须要跨机器迁徙数据库以实现数据库扩容；异构数据库迁徙，数据库中的局部业务须要迁徙到另外一种更适宜的引擎时，波及的数据库迁徙工作。例如从单机数据库迁徙到分布式数据库；从关系型数据库迁徙到 NoSQL，或，从关系型数据库/ NoSQL 把数据迁徙到数据仓库、大数据或数据湖中进行数据分析。二、 数据库迁徙的步骤不同于利用搬迁，数据库在数据迁徙过程中，业务依然继续写入数据，数据始终处于动态变化的状态，整个迁徙过程绝对比较复杂。依据是否能反对数据迁徙过程中，数据库为业务继续提供读写服务，将迁徙计划分为：停机迁徙、零停机迁徙。为了满足业务服务的高可用及迁徙数据的完整性，举荐大家抉择可能反对“零停机迁徙”的工具产品。 停机迁徙，即迁徙之前须要进行数据库的写能力，即数据库下层业务不能有写申请，业务停服。而后，在数据库齐全动态的状况下，进行数据库迁徙。零停机迁徙，即在数据库迁徙的过程中，业务依然持续提供服务，业务不受影响。在数据库迁徙过程，零停机迁徙的迁徙步骤包含如下几步。而停机迁徙，只反对存量历史数据的搬迁。 存量历史数据的搬迁，存量历史数据搬迁次要进行构造定义及数据的迁徙。例如对于关系型数据库(例 MySQL、SQLServer 等)，构造迁徙会进行表构造、视图、存储过程、函数等的定义迁徙。增量更新数据，因为存量历史数据搬迁个别会继续数小时甚至入地，在这期间为了实现数据库可服务，数据库会持续承受业务写入申请。对于这部分新增的数据，也须要迁徙到指标数据库，以保障迁徙数据的完整性。当然市面上很多工具不提供这个能力，其要求业务齐全进行服务 ，放弃数据库的齐全动态后，再进行数据迁徙。迁徙数据比照，在实现数据迁徙后，个别都须要校验迁徙数据的一致性，防止因为软硬件或人为误操作等起因，呈现迁徙数据不统一导致业务受影响。 三、 常见的数据库迁徙办法以后市面上支流的数据库迁徙工具，次要分为如下几种计划： 备注：上述评测仅依据以后各个产品的状况得出的论断1、NineDataNineData 是玖章算术旗下的多云数据管理平台，它反对数十种常见数据源(例：MySQL、SQLServer、Clickhouse、Kafka等)之间的同异构数据迁徙。NineData 提供了数据的单向及双向复制。其提供的单向数据复制性能，包含了构造复制、全量数据复制及增量复制能力，基于这几个复制步骤，能够在业务零停机的状况下，实现数据库的无缝迁徙。 NineData 作为一个即开即用的SAAS服务，围绕数据迁徙性能，也提供了一系列欠缺的配套服务，包含告警监控、权限管控、迁徙限流及数据一致性比照等。其中，数据比照性能十分有特色，其反对所有对象的构造比照及数据比照，同时，为升高比照对数据库的压力影响，还提供了疾速比照、比照限流等能力，在比照实现后，其还会提供具体的不统一数据及勘误语句。 除了欠缺的性能外，NineData 的迁徙性能也很优良，用sysbench模型测试了下，它的全量迁徙速度高达130MB/s，增量复制速度能达到10万+TPS。 NineData 比拟有特色的是：可齐全自动化得实现数据库的零停机迁徙；提供高效、易用欠缺的数据一致性比照工具；对云数据库、云主机及IDC自建数据库的反对同样欠缺。 图一：配置工作的第一步骤，抉择迁徙的数据源及迁徙的步骤 图二、配置工作的第二步骤，抉择复制对象 图三：配置工作的第三步骤，配置映射关系及数据过滤条件 图四：配置工作的第四步骤，迁徙前的前置查看 图五：工作详情及运维界面 图六：复制工作的数据比照详情 果图七：复制工作的比照后果，不统一数据的详情 2、备份集复原个别各个数据库引擎都会提供备份复原工具，例如 MySQL 的 xtrabackup。借助备份集复原性能实现数据库迁徙的步骤个别如下图所示。整个复原过程纯依赖手动调度、手工执行。这种复原计划因依赖数据库自身工具，迁徙的残缺度很高。然而实现复杂度也比拟高，比拟容易出错。且复原工具不提供辅助的诊断运维能力，应用门槛比拟高，不是很举荐。 备份复原迁徙计划的特色为：纯手工操作复杂度高且容易出错，迁徙的完整性较高，但只适宜同网络环境下的同构同版本数据库之间的数据迁徙。 3、数据导出+数据导入个别各个数据库引擎都会提供导入导出的工具，例如 MySQL 的 mydumper + myloader。 同时，各大数据库开发工具也会提供数据导出+导入的性能，例如 navicat。这种工具只能反对历史存量数据的迁徙，不反对增量数据迁徙。所以，为了保障迁徙数据的完整性，要求业务停机后，再进行数据迁徙。 基于数据导出导入的迁徙计划的问题是：要求业务停机迁徙，业务影响大；只适宜小规模数据量状况下的数据迁徙。 4、云厂商数据库迁徙工具云厂商数据库迁徙工具，其中以阿里云数据传输 DTS 为代表。云厂商个别都会提供数据库迁徙工具，以撑持数据库上云迁徙。云厂商的数据库迁徙工具个别也反对构造复制、全量数据复制及增量数据服务，能够实现业务零停机状况下的数据库迁徙。同时，云厂商个别也会提供内置的数据校验工具，但个别只反对数据的校验，不提供构造校验能力。云厂商迁徙工具个别由数据库团队负责，所以其对云数据库的迁徙反对较好，然而对于云主机上自建数据库以及 IDC 自建数据库反对不好甚至不反对。例如，大部分云厂商迁徙工具都不反对自建数据库作为迁徙工具的指标数据源。 云厂商迁徙工具的特色是：可齐全自动化得实现数据库的零停机迁徙；对云数据库的反对较欠缺，根本不反对云主机及 IDC 自建数据库。 四、 小结总的来说，数据库作为外围业务撑持，其在数据库搬迁过程中的可用性及搬迁数据的完整性至关重要。为了满足服务高可用及迁徙数据的完整性，举荐大家抉择可能反对“业务零停机迁徙”的工具产品。同时，平台工具(例 NineData ) 的自动化体验及配套设施（例：数据校验工具、迁徙限流、监控告警等）个别较为欠缺，是比拟举荐的抉择。

一、背景基于公司发展硬性需求，生产VM服务器要统一迁移到ZStack 虚拟化服务器。检查自己项目使用的服务器，其中zookeeper集群中招，所以需要进行迁移。 二、迁移计划为了使迁移不对业务产生影响，所以最好是采用扩容 -> 缩容 的方式进行。 说明：1.原生产集群为VM-1,VM-2,VM-3组成一个3节点的ZK集群；2.对该集群扩容，增加至6节点（新增ZS-1,ZS-2,ZS-3），进行数据同步完成；3.进行缩容，下掉原先来的三个节点（VM-1,VM-2,VM-3）；4.替换nginx解析地址。OK! 目标很明确，过程也很清晰，然后开干。三、步骤 (过程已在测试环境验证无问题)：对新增的三台服务器进行zk环境配置，和老集群配置一样即可，最好使用同一版本（版主使用的是3.4.6）；对老节点的zoo.cfg 增加新集群的地址（逐一增加），然后对新增加节点逐一重启。 四、问题ZS-1 启动成功，zkServer.sh status 报错,用zkServer.sh status查看，反馈如下异常：[root@localhost bin]# ./zkServer.sh statusZooKeeper JMX enabled by defaultUsing config: /usr/zookeeper/zookeeper-3.4.6/bin/../conf/zoo.cfgError contacting service. It is probably not running.此时查看数据，数据同步正常ZS-1 数据同步正常，但是无法查看节点的状态信息；怀疑是因为老节点没有重启的原因；此时去查看原集群节点信息，发现原集群节点状态异常。经排查定位，原集群的状态一直处于异常状态。初步定位原因可能是原集群的选举存在异常，导致新节点无法正常纳入，继续排查。恢复集群初始状态，如果集群节点的状态一直没法正常查看。OK 继续定位...五、排查过程以下方法来自于网络： 可能有以下几个原因：第一、zoo.cfg文件配置：dataLogDir指定的目录未被创建。 1.zoo.cfg[root@SIA-215 conf]# cat zoo.cfg...dataDir=/app/zookeeperdata/datadataLogDir=/app/zookeeperdata/log...2.路径[root@SIA-215 conf]# cd /app/zookeeperdata/[root@SIA-215 zookeeperdata]# lltotal 8drwxr-xr-x 3 root root 4096 Apr 23 19:59 datadrwxr-xr-x 3 root root 4096 Aug 29 2015 log经排查 排除该因素。 第二、myid文件中的整数格式不对，或者与zoo.cfg中的server整数不对应。 [root@SIA-215 data]# cd /app/zookeeperdata/data[root@SIA-215 data]# cat myid 2[root@SIA-215 data]# 定位排查后排除不是该原因。 ...

机房流量划分：保证同一纬度查询写入尽量在一个机房 切流控制点：DNS：DNS缓存，切流量无法立刻生效 流量无法通过DNS完全切干净，有剩余流量（对应入网框架中，在httpdns中改，有一点点本地缓存，webapp无法用httpdns）LVS（无法根据业务需求流量划分的）ROUTEr（改nginx）。内部调用（inrouter同上、thrift本来就是service的ip直接服务发现时改，用同一份）业务代码选取router增加nginx 的dynamic_req_add key cityid $city_iddynamic_req $upstream_name default_liddc=xx upstreamm_name=xx port=xx; 机房下线：先DNS去掉，router配置去 数据同步。本质是双机房要保持全量数据mysql 主从redis 见https://segmentfault.com/a/11...为什么redis不能和mysql一样用主从集群分机房？mysql本身主从延时就大，不像redis这种本身作为缓存的东西，机房间链路不稳定，如果主从复制配置同步或者命令延时就拒绝写/集群夸机房影响稳定。同步全部异步，基本用mq，否则要加丢失数据补齐太复杂。mq。写入双写或消费双订阅。切换过程中，因为重试等会有点问题。无法做到的。。。 机房迁移，迁移过程中双活。或维持上期双活收敛配置，增加双机房配置机器ready功能验证。QA测性能验证。指定url压测数据同步代码里用小流量测试DNS改50DNS彻底改残余流量：旧route中IP配成新机房的VIP（不配为IP的原因是故障摘除方便，要一直持续发半年） 双活下机房迁移（有三活）如果数据同步支持三活，没问题。如果只支持双活，可以：验证C功能：A与B做双活，C读A的redis数据切C：A与B断双活，B与C做双活，A读C redis故障应对：C有问题后，流量切回A，A读Credis, C与B同步数据

摘要： 数据库的架构升级就好像是在给一个高速运行的飞机更换引擎。2019年1月4日，OceanBase迁移服务解决方案在ATEC城市峰会中正式发布。蚂蚁金服资深技术专家师文汇和技术专家韩谷悦共同分享了OceanBase迁移服务的重要特性和业务实践。蚂蚁数据库架构的三代升级史在过去的十多年时间里，蚂蚁在整个基础数据库架构上一共经历了三代升级。第一代数据架构是构建在IOE的基础之上——IBM的小型机、Oracle的商业数据库，还有EMC的共享存储。基于第一代IOE架构的运维成本是非常高的，同时稳定性的挑战也是非常大的。随着业务的快速发展，这套架构已经完全没有办法适应业务发展的增速。随之诞生的是第二代架构，第二代架构的主体是OE——也就是Oracle和EMC，加上蚂蚁自身的分布式中间件，解决了业务的水平和垂直的弹性能力。这一代架构其实伴随着蚂蚁走了很多年。随着4G、5G时代的到来和金融的普及化，人们的生活越来越离不开移动支付，业务井喷式的发展给底层的数据库提出了更高的要求。这些要求包括更高的稳定性，快速恢复能力和极致的弹性能力等。于是最终演进到了我们如今的第三代架构。第三代架构是由OceanBase为代表的金融级云数据库和分布式中间件所构成。数据库架构升级的挑战伴随着整个蚂蚁的发展，整个数据库的架构也仅仅演进了三代。这其中一个很重要的原因就是对于任何企业而言，整个数据库的架构升级都是一件非常有挑战的事情。蚂蚁金服资深技术专家师文汇说道，“用一个我们内部经常说的比喻，就是数据库的架构升级就好像是在给一个高速运行的飞机更换引擎。”更换引擎的目的是为了拥有更好的动力，做更多技术上的创新。但是横亘在眼前的问题是，如何才能做到稳妥创新，保证驾驶中的飞机平稳顺利的运行，这其实是有非常大的挑战。在过去三代架构的演进中我们可以看到，本质上每一代架构的迭代基本上都是以两到三年为周期，这其中会有非常高的人力投入和成本开销。第二个挑战就是从传统的商业数据库迁移到OceanBase数据库之上，我们如何保证迁移过程中以及迁移以后的稳定性。另外一个非常大的挑战就是数据质量，在金融企业里，数据承载的不仅只是钱，更承载了数以亿计用户的信任。所以数据一条不能丢，一条不能错，这是我们做数据库的底线。当然，包括兼容性问题和性能风险也给数据库的架构升级带来重重挑战。OceanBase迁移服务：向分布式架构升级的直接路径基于上述问题和挑战，同时经过蚂蚁十年数据库架构升级的先进经验，蚂蚁金服为客户打造了这款一站式数据迁移解决方案——OceanBase迁移服务（OceanBaseMigration Service，简称OMS）。OMS的发展演进OMS的演进是以业务为驱动，并且与OceanBase的架构升级和不断发展密不可分。早在2014-2015年期间，蚂蚁主站上的一些核心业务，包括大家熟知的交易业务，支付业务和会员业务等，需要从Oracle迁移到OceanBase上。当时的OMS还是以一个工具类、模块化的形态支撑着这些项目。所以在2015年我们开始对OMS的方案进行全面的调研，力求沉淀出通用的系统化的解决方案。在2016年，OMS已经有了平台化的架构，引入了大规模编排的思想，将整个迁移特别是切换过程中繁琐易错的环节全部集成到平台。这一时期，OceanBase也完成了从0.5版本到1.0版本的架构升级，这一年OMS还支撑了网商银行、印度PayTM以及主站的核心业务升级到OceanBase 1.0版本。到了2018年的时候，无论在基础功能层面还是任务编排层面，OMS都已经被打磨得日趋完善。今年OMS已经支持了蚂蚁森林，蚂蚁商户平台以及众多大量核心及非核心的业务从MySQL迁移到OceanBase之上。与此同时，在外部业务包括很多已经上线OceanBase的商业银行，也已经验证了使用OMS一键迁移到OceanBase的能力。OMS的方案优势OceanBase迁移服务其实主要解决了五个重要的问题。1.负载回放验证：其中第一个核心的问题就是负载回放验证，通过采集源端数据库的SQL流量，在目标库OceanBase上回放，可以验证其在OceanBase上的功能是否兼容、性能是否出现问题等。同时基于蚂蚁DBA十多年的经验沉淀，OMS会为客户提供性能等方面的调优建议。2.秒级数据校验：第二点就是数据校验，OMS有三层数据校验，可以做到秒级的延迟。举一个例子，比如说我们想把传统商业数据库替换成OceanBase，如果在迁移过程中任何一条数据出现了错误，在一秒钟内就可以快速发现。校验的延迟可以完全保证在一秒以内，根据蚂蚁线上的经验，大概在100-200毫秒之间。3.分钟级即时回滚：第三点也是最重要的一点，就是OMS有随时回滚的能力，而且回滚是无损的。这也是我们前面所强调的稳妥创新的基石。4.多种数据库类型支持：目前OMS支持源端数据库类型有Oracle、MySQL、OceanBase等等，支持全量迁移和增量数据同步。5.一键完成迁移：整个数据迁移链路和回滚机制的搭建基本上都是通过一键操作完成，使用简便。OMS的技术架构OMS的核心方案其实非常简单，我们把OceanBase变成Oracle/MySQL的一个备库。传统的商业数据库一般都是有主库和备库的：主库承担写的流量，如果主库出现问题，我们会把数据切到备库，然后通过OMS提供的一整套虚拟主备库的解决方案完成切换。比如原来Oracle有一个主库一个备库，然后OceanBase其实变成了一个虚拟的备库。整个数据库架构的升级也会变得异常简单，简单到只是做了一个主备切换。回滚也会变得非常简单，其实也是做了一次主备切换。从OMS的整体架构来看，其实一个非常关键的点就是，我们在传统的商业数据库和OceanBase之间建立了一套虚拟的主备链路，整个OMS里用到的所有组件，其实都是在蚂蚁和阿里有很多年技术沉淀的，也都是基于真实场景所产生的。OMS的迁移流程OceanBase迁移服务的整体迁移流程其实只有七步。1.评估：首先第一步是通过负载回放工具做兼容性分析;2.PoC：接下来OceanBase云平台可以帮助客户部署一套PoC集群;3.预迁移：然后OMS把线上的Oracle的数据预迁移到一个测试库里；4.验证：在这个测试库里用负载回放工具去回放这些SQL，然后找到SQL里不兼容，性能或者数据质量不满足预期的部分，并提供优化建议；5.正式迁移：前四步做完了以后，业务需要调整或者需要优化的SQL已经完成优化，然后就可以正式迁移了。首先把原有的全量数据迁过来，然后再把增量变化的那部分数据实时同步过来；6.校验：等到所有的数据准备好以后，然后我们继续完成三级校验；7.切换和回滚：等到所有的校验都完成以后，可以一键完成切换和回滚功能。通过这七步就可以轻松完成从传统商业数据库到分布式数据库的完整迁移。蚂蚁商户平台基于OMS的业务实践蚂蚁商户平台承载着商户档案数据信息，订购关系、签约信息的数据和相应的服务能力。其中一部分业务使用的是MySQL数据库，还有一部分核心业务使用的是Oracle数据库。随着商户的快速增长以及业务场景的不断丰富，商户平台数据增长迅速，数据规模相当庞大。尤其是MySQL的单表瓶颈日益明显，DDL变更、DML更新的性能与风险已经无法承担。蚂蚁金服技术专家韩谷悦介绍道，“OceanBase能够支持数据的无限扩展，满足商户业务的容量与性能需求。那么如果我们换一种数据库底盘，其实所要面对的性能、稳定性和数据质量的风险同样不可避免。”从蚂蚁商户平台的业务实践来看，使用OMS迁移与传统迁移进行对比，我们可以看到：业务评估和改造过去通常一个业务少则花费1-2个月的时间去做改造和适配；那么基于OMS自动化的SQL兼容性评估和负载回放的能力，蚂蚁商务平台业务的改造大概只用了一个星期的时间。数据迁移和校验客观来讲，迁移的总时长主要取决于业务数据模型，数据量和网络环境。在提高迁移效率方面，OMS目前增量迁移的延迟仅为毫秒级，跨城情况下最长只需要3秒。并且针对校验出的数据差异提供补齐的SQL和订正方案，使得迁移和校验的整体效率有了大幅度的提升。业务切换其实在切换之前，往往需要制定严密的切流方案和Failover方案，整个切换过程中需要检查与校验的细节非常繁琐，任何一步疏忽都有可能造成数据不一致的问题。那么OMS通过引入大规模编排的思想，把所有繁琐复杂的环节通通落到平台当中。所以从原来业务切换需要用时1-2周时间， 使用OMS后蚂蚁商户平台业务无论是切读还是切写的过程中都只用了几分钟的时间。业务回滚在过去，迁移之后的业务回滚要担负重大的决策风险，OMS使得业务回滚就像一次主备切换，可以瞬间完成并且不丢数据，所以让业务回滚不再成为难题。商户业务整体迁移的过程中也发生过业务抖动，使用OMS回滚的时候从登陆系统到完成回滚也只用了几分钟的时间。所以全程下来蚂蚁商户平台这个业务的迁移时间大概在三个多星期的时间完成，那么无论从人力成本还是时间成本上，OMS都极大地提升了数据库的整体迁移效率。最后，韩谷悦为大家展示了OMS一键迁移的demo演示。当前， 越来越多的企业已经认识到分布式架构在实现业务灵活扩展以及敏捷开发等方面的巨大价值。OceanBase不断通过产品端的革新，为传统企业输送“互联网基因”，帮助更多客户向分布式架构转型。同时OceanBase也在不断提高服务客户的深度和广度。深度意味着在同样的业务场景下，随着业务的发展和体量的壮大，帮助更多企业承担起业务所带来的极致压力。广度则针对的是随着新型技术形态和业务场景的出现，帮助更多企业快速响应，通过技术创新而适应变化所带来的新的市场契机。OceanBase致力于将蚂蚁自身业务多年沉淀下来的最浓缩，最经典和最普世的方法论输出给广大的企业客户，同时做到深度和广度并存，真正帮助客户实现稳妥创新。本文作者：平生栗子阅读原文本文为云栖社区原创内容，未经允许不得转载。

摘要： 图解，2018年自然语言处理领域最成功的方向！2018年是自然语言处理的转折点，能捕捉潜在意义和关系的方式表达单词和句子的概念性理解正在迅速发展。此外，NLP社区已经出现了非常强大的组件，你可以在自己的模型和管道中自由下载和使用（它被称为NLP的ImageNet时刻）。在这个时刻中，最新里程碑是发布的BERT，它被描述NLP一个新时代的开始。BERT是一个模型，它打破了前几个模型处理基于语言的任务的记录。该模型的论文发布后不久，团队还开放了该模型的代码，并提供了已经在大量数据集上预先训练过的模型的下载版本。这是一个重大的发展，因为它使任何人都可以构建一个涉及语言处理的机器学习模型，他们成功的将这个强大的工具变成了一个易于使用的组件，从而节省了训练NLP模型所需的时间，精力和资源。BERT是建立在最近NLP社区中涌现的一些聪明的想法之上，包括但不限于半监督序列学习（Andrew Dai和Quoc Le）、<u style=“box-sizing: border-box;">ELMo</u>（由Matthew Peters和来自AI2的研究人员和UW CSE），ULMFiT（由fast.ai创始人Jeremy Howard和Sebastian Ruder提供）和OpenAI转换器（由OpenAI研究人员Radford，Narasimhan，Salimans和Sutskever提供）和Transformer（Vaswani等人）。需要注意的一些概念才能完全了解BERT的内容。因此，让我们首先看一下在查看模型本身所涉及的概念之前可以使用BERT的场景。示例：句子分类BERT最擅长的是分类单个文本，这个模型看起来像这样：为了训练这样的模型，你必须训练分类器，在训练阶段BERT模型发生的变化很小。该过程称为微调，并且整个过程是源于半监督序列学习和ULMFiT。既然我们在讨论分类器，那么我们就处于机器学习的监督学习领域。这意味着我们需要一个标记的数据集来训练这样的模型。以垃圾邮件分类器示例，标记的数据集将是电子邮件和标签的列表（“垃圾邮件”或“非垃圾邮件”）。这种用例的其他示例包括：1、情绪分析输入：电影/产品评论。输出：评论是正面还是负面？示例数据集：SST2、事实查证输入：句子。输出：“索赔”或“不索赔”更夸张/前沿的例子：输入：是否进行索赔。输出：“真”或“假”Full Fact是一个为公众利益建立自动事实检查工具的组织。他们的部分管道其实是一个分类器，它可以读取新闻文章并检测声明（将文本分类为“声明”或“不声明”），以此进行事实验证。模型架构现在你已经了解了如何使用BERT的用例，接下来让我们仔细看看它是如何工作的。首先介绍BERT的两种型号：l BERT BASE：与OpenAI Transformer的尺寸相当，性价比很高；l BERT LARGE：一个非常庞大的模型，它的性能最好；BERT基本上是训练有素的转换器（Transformer）编码器堆栈。现在是你阅读The Illustrated Transformer的好时机，该文章解释了Transformer模型-BERT的基本概念以及我们接下来要讨论的概念。两种BERT模型都有大量的编码器层（本文称之为Transformer Blocks），其中Base版本为12个，Large版本为24个。它们还具有更大的前馈网络（分别为768和1024个隐藏单元）以及比初始论文中的转换器更多attention heads（分别为12和16）（初始论文的转换器中有6个编码器层，512个隐藏单元，和8个attention heads）。模型输入第一个接口输入提供了一个特殊的接口[CLS]，原因将在后面变得明显，CLS在这里代表分类。就像转换器的香草编码器一样，BERT采用一系列字作为输入。每一层都应用自我关注，并通过前馈网络传递其结果，然后将其交给下一个编码器。在架构方面，到目前为止，这与转换器完全相同。模型输出每个位置输出大小为hidden_size的矢量（BERT Base中的768）。对于我们上面看过的句子分类示例，我们只关注第一个位置的输出（我们将特殊的接口[CLS]标记传递到）。该向量现在可以用作我们选择的分类器的输入，通过使用单层神经网络作为分类器，这样效果就能达到我们想要的。如果你有更多标签（例如，如果你是使用“垃圾邮件”，“非垃圾邮件”，“社交”和“促销”标记电子邮件），你只需调整分类器网络以获得更多输出神经元即可，然后通过softmax。卷积网相似操作对于那些具有计算机视觉背景的人来说，这个矢量切换应该让人联想到VGGNet等网络的卷积部分与网络末端的完全连接的分类部分之间发生的事情。嵌入（Embedding）的新时代到目前为止，词嵌入一直是影响NLP模型处理语言的主要力量。Word2Vec和Glove等方法已被广泛用于此类任务。让我们回顾一下之前是如何使用它们的。Word嵌入是个啥？对于要由机器学习模型处理的词，它们需要以某种形式的数字表示，这样模型才可以在计算中使用。Word2Vec让我们可以使用一个向量（一个数字列表）以一种捕获语义相关关系的方式正确表示单词（例如，判断单词是相似的，判断还是在它们之间具有的关系，如“开罗”和“埃及”之间的关系）以及句法或基于语法的关系（例如“was”和“is”之间的关系）。该领域的研究者很快意识到，使用经过大量文本数据预训练的嵌入技术，而不将模型与经常是小型数据集的模型一起训练，这是一个好主意。因此，你可以下载Word2Vec或GloVe预训练生成的单词列表及其嵌入。ELMo：语境问题如果我们使用GloVe，那么“stick”这个词将由一个向量表示，无论上下文是什么。但是，许多NLP研究人员（Peters等人，2017年，McCann等人，2017年及Peters等人，2018年在ELMo论文中）发现“stick”有多个含义，这取决于它的使用位置。为什么不根据它所使用的上下文给它一个嵌入呢？这样既捕获该上下文中的单词含义以及其他上下文信息。因此，语境化嵌入词诞生了！语境化词嵌入可以根据它们在句子的上下文中携带的含义给出单词不同的嵌入ELMo不是对每个单词使用固定嵌入，而是在为其中的每个单词分配嵌入之前查看整个句子，它使用在特定任务上训练的双向LSTM来创建这些嵌入。ELMo在NLP背景下向预训练迈出了重要一步。ELMo LSTM将使用我们数据集语言中的大量数据集进行训练，然后我们可以将其用作需要处理语言的其他模型中的组件。ELMo的秘密是什么？ELMo通过训练来预测单词序列中的下一个单词，这是一项称为获得语言理解语言建模的任务。这很方便，因为我们拥有大量的文本数据，这样的模型可以在不需要标签的情况下学习。我们可以看到每个展开的LSTM步骤的隐藏状态都是从ELMo的头部后面突出。在完成预训练之后，这些在嵌入式proecss可以派上用场。ELMo实际上更进一步，因为双向LSTM，这意味着它的语言模型不仅具有下一个词的感觉，而且还有前一个词。ELMo通过以某种方式将隐藏状态（和初始嵌入）组合在一起来提出情境化嵌入（连接后加权求和）。ULM-FiT：在NLP中使用迁移学习ULM-FiT引入了有效利用模型在预训练期间学到的内容的方法，这不仅仅是嵌入，而且是上下文嵌入。ULM-FiT引入了语言模型和流程，从而有效地微调该语言模型以执行各种任务。NLP可能与计算机视觉一样,有了一种方法来进行转移学习。The Transformer：超越LSTMsTransformer论文和代码的发布，以及它在机器翻译等任务上取得的成果开始让一些人认为它们是LSTM的替代品。事实上Transformer比LSTM更好地处理长期依赖性。Transformer的编码器-解码器结构使其非常适合机器翻译。但是你如何将它用于句子分类？你如何使用它来预训练可以针对其他任务进行微调的语言模型（这些任务就是被该领域称为使用预训练模型或组件的监督学习任务）。OpenAI Transformer：预训练用于语言建模的Transformer解码器事实证明，我们不需要整个Transformer来为NLP任务采用转移学习和精细可调语言模型，我们可以只使用Transformer的解码器。解码器是一个很好的选择，因为它是语言建模（预测下一个单词）的必备选择，它是为掩盖未来的接口而构建的。该模型堆叠了十二个解码器层。由于在该设置中没有编码器，因此这些解码器层将不具有香草Transformer解码器层具有的编码器。然而，它仍然会有自我关注层。通过这种结构，我们可以继续在同一语言建模任务上训练模型：使用大量（未标记）数据集预测下一个单词。只是使用7000本书的文字，让它学习！书籍非常适合这类任务，因为它允许模型学习关联相关信息，即使它们被大量文本分开。例如，当你使用推文或文章进行训练时，你无法获得这些信息。现在，OpenAI Transformer已经准备好接受训练，预测由7,000本书组成的数据集上的下一个单词。将学习能力转移到下游任务既然OpenAI Transformer已经过预先训练，并且其层也经过调整以合理地处理语言，我们就可以开始将它用于下游任务。让我们首先看一下句子分类（将电子邮件分类为“垃圾邮件”或“非垃圾邮件”）：OpenAI论文概述了许多输入转换，以处理不同类型任务的输入。下图显示了模型的结构和输入转换，以执行不同的任务。BERT：从解码器到编码器openAI的Transformer为我们提供了基于Transformer的可调预训练模型。但是从LSTM到Transformer的过渡中缺少了一些东西，因为ELMo的语言模型是双向的，但openAI的Transformer只训练向前语言模型。我们能否建立一个基于Transformer的模型，其语言模型同时向前和向后？蒙面语言模型（NLM：Masked Language Model）“我们将使用Transformer编码器”，BERT说。“这很疯狂”，Ernie回答说，“每个人都知道双向调节会让每个词在多层次的背景下间接地审视自己。”“我们将使用蒙面工具”，BERT自信地说。找到正确的任务来训练Transformer堆栈的编码器是一个复杂的障碍，BERT通过采用早期文献中的“蒙面语言模型”概念（称为完成任务）来解决。除了掩盖15％的输入之外，BERT还混合了一些东西，以改善模型后来如何微调。有时它会随机用另一个单词替换一个单词，并要求模型预测该位置的正确单词。两个句子的任务（Two-sentence Tasks）如果你回顾一下OpenAI的Transformer处理不同任务的输入变换，你会注意到一些任务要求模型具有说出两个句子的能力（例如，它们是否只是对方的复述？给出一个维基百科条目作为输入，以及关于该条目作为另一个输入的问题。）。为了使BERT更好地处理多个句子之间的关系，预训练过程包括一个额外的任务：给定两个句子（A和B），B可能是跟随A的句子，或不是？特定任务-模型BERT论文展示了将BERT用于不同任务的多种方法。BERT用于特征提取微调不是使用BERT的唯一方法。就像ELMo一样，你可以使用预先训练的BERT来创建语境化词嵌入。然后，你可以将这些嵌入提供给现有模型-该过程论文已经证实可以产生结果，在命名实体识别等任务上应用微调BERT并不远。哪个向量最适合作为上下文嵌入？我认为这取决于任务。我们考察了六种选择（与微调模型相比，得分为96.4）：BERT延伸使用BERT的最佳方式是通过BERT FineTuning与Google Colab托管的Cloud TPU笔记本。如果你之前从未使用过云TPU，那么这也是尝试它们的良好起点，以及BERT代码也适用于TPU，CPU和GPU。下一步是查看BERT仓库中的代码：l 该模型在modeling.py（class BertModel）中构建，与vanilla Transformer编码器完全相同。l run_classifier.py是微调过程的一个示例。它还构建了监督模型的分类层，如果要构建自己的分类器，请查看create_model()该文件中的方法。l 可以下载几种预先训练的模型，它们跨越了BERT Base和BERT Large，以及英语，中文等语言，以及涵盖102种语言的多语言模型，这些语言在维基百科上进行了训练。l BERT不会将单词视为标记，相反，它注意者WordPieces。tokenization.py是将你的单词转换为适合BERT的wordPieces的标记器。l 你还可以查看BERT的PyTorch实现。该AllenNLP库使用此实现允许使用的嵌入BERT与任何模型。本文作者：【方向】阅读原文本文为云栖社区原创内容，未经允许不得转载。