电子商务

这两年来，在抖音上开店的品牌、商家真的太多了，人人都想分「趣味生产」的蛋糕。 数据显示，抖音电商 2020 年全年 GMV 超过 5000 亿元，比2019年翻了 3 倍。现在，抖音电商业务全年 GMV 指标更是剑指万亿。 在各个品牌销量一直走高的同时，抖店的物流、售后服务等配套环节却因为不够智能高效，面临着各种各样的问题，突出体现在 2 点：  所有订单都需人工记录信息、解决，从发货到退 / 换货，效率低下还易出错。 物流征询铺天盖地，特地是当同一订单须要拆分成多个包裹时，容易造成客户误会，客诉率成倍上涨。 康师傅、欧迪芬等品牌用一招就轻松让客户投诉率降落 70%，客服人员每月缩小至多 60 小时的工作量，订单解决效率晋升 2 倍多——vika维格表和数环通联手推出的「抖店电商综合解决方案」。 有了它，告诉消费者订单拆分物流信息、退 / 换货主动等业务通通主动实现，省心又省力。 vika维格表 x 数环通，抖店业务全链条自动化团子是某电商团队的金牌售后，薪资待遇随着订单销量一样稳定增长，但最近她老是深夜 emo： 因商品与赠品没有同时到货，或者是不同地点仓库的商品到货工夫不一样，她好几次间接被顾客骂哭还受到差评退货。每月要解决大量的退 / 换货订单，光点击批准就有无数次，过程繁琐又心累，动作略微慢点，也会受到顾客投诉。 事实上，简直每一家经营抖店的品牌都会面临上述问题，就没有可行、成本低、落地快的解决办法吗？ 有的，团子和她所在的团队就用上了vika维格表 x 数环通的「抖店电商综合解决方案」。 2 个月过来了，当初简直没有客户会来被动询问物流信息了，退换货也不必操心，效率晋升 50%，复购率更是直逼 70%，间接治好了团子的精力内耗。 这套计划具体如何实现？无妨以康师傅和欧迪芬的理论利用场景来展示成果： 拆单分仓发货，主动短信物流揭示康师傅在抖店平台日均有几百到上千订单量，其中 80% 以上订单须要分仓发货（组合装）。当客户在收到第一个包裹时，容易误会是漏发或少发，而后去征询客服或者间接产生客诉，这既影响了店铺和商品评分，也占用大量客服资源回复解决。 再加上人工筛选数据时万一呈现脱漏，整顿时就容易呈现失误；万一跟进不及时，顾客还有可能间接退货。 而vika维格表 x 数环通打造的自动化流程，能够将拆单的多包裹信息主动发送到消费者手机上，大大降低了买家的物流征询量。 不仅如此，抖店订单列表、订单物流信息、当订单有拆单分仓发货状况等信息数据，以及短信发送状况，都能够主动写入vika维格表，不便进行下一步的整合与剖析。 落地此解决方案后，康师傅因拆单产生的物流征询量和客诉量降落了 70%，无论是饮料还是速食产品的复购率每个月都在翻新高。 主动解决退 / 换货订单欧迪芬的品牌负责人示意：「当买家发动退换货时，客服须要创立工单，之后须要重复与仓库进行核查。在该业务流程中，消耗了大量客服人力，简直占用客服 5 成的工作量。」 欧迪芬的客服每天须要解决几百张售后退货单，逐个查看退货物流状态，当仓库签收确认后，客服才能够二次确认退单；当未签收时，则须要等下次查看确认后再操作，过程繁琐费时费力。 这套「抖店电商综合解决方案」轻松解决上述退 / 换货流程中的问题，能够实现零碎主动解决退货单，每天开释客服 3-4 小时的人效。 ...

EDI 即 Electronic Data Interchange 电子数据交换，能够实现两个企业或企业业务零碎之间的数据交换。如，A公司能够通过电子数据交换平台，向B公司发送订单、查问库存、告诉发货等信息，帮忙企业整合供应链、降低库存、实现精益生产。So 说的这么业余，能不能用艰深的语言介绍下EDI呢？ 上面用一副简略的漫画给大家阐明咯，鼓掌~~

EDI是Electronic Data Interchange 的缩写，在大陆译为电子数据交换，有时也译为无纸贸易。香港直译为电子材料联通。国际标准化组织将EDI定义为一种电子传输办法，用这种办法，首先将商业或行政事务处理中的报文数据依照一个公认的规范，造成结构化的事务处理的报文数据格式，进而将这些结构化的报文数据经由网络，从计算机传输到计算机。 除了硬译的这个定义之外，咱们应该正确地了解一下EDI的含意。从译名上能够看出有许多不同的了解，例如，不少文献将它译为无纸贸易，在贸易畛域中来说，这一名称很形象地阐明了它的情况及成果。然而，从根本意义来说，电子数据交换的意思并不限于贸易流动，例如医院中的信息交换，当初也已采纳EDI的思维与办法，并已在国外一些中央理论应用。因而，严格地讲，无纸贸易是EDI在贸易畛域中的理论利用，EDI的概念该当更宽泛一些。当然，在事实的利用中，贸易畛域的利用是倒退最快，利用最多的方面，目前在这一方面的成绩，规范，软件也是最多的。有的同志正确地指出：EDI的本质在于“数据不落地”，用技术语言来说，那就是信息存储及传递的介质从纸张转为电磁设施。这样所谓EDI就该当包含以下三个根本方面： 1、须要进行信息替换的某一应用领域，即EDI的环境。例如：国际贸易，国内贸易，医院工作，图书馆工作，项目管理等等。它限定了有哪些信息须要传递，有哪些地点质检进行传递。 2、信息替换的流程及规定，即EDI的过程。它反映了理论畛域中的业务过程，以及与之相伴的信息流程。例如在贸易过程中，从询价，报价开始，直到付款，交货。两头波及供应者，购买者，银行，运输公司，保险公司等多种企业(或称角色)，先后几十种信息替换业务须要执行。在理论工作中，这种流程体现为一系列规定与规范。 3、信息交换的伎俩，括硬件设施，通信设施以及软件，即EDI的技术实现。从目前来看，计算机设备，通信设施曾经比拟广泛，EDI的利用也没有什么非凡的要求，一般来说不须要非凡的开发。例如，通信线路能够应用已有的各种形式解决，从最简略的电话线到租用卫星专线。须要的是软件的开发。 针对某一畛域的利用，听从某一特定的规范，就要有一套专门的软件。解决这一畛域的问题是技术方面的工作。 而目前在EDI软件方面做的好的专家，也就是国内外知名企业：知行软件。 https://www.kasoftware.com/ 总之，对于EDI，该当全面地去意识和了解，而不要只从技术，甚至只从硬件的角度去对待与解决EDI的工作。

互联网正在成为各种企业的重要销售和营销渠道。各种规模的企业都意识到“集体客户”的力量，并越来越多地关注集体客户。意识到保留现有客户比取得新客户更容易后，企业正在将他们的办法从CM（客户治理）转变为CRM（客户关系治理）。E-CRM（电子客户关系治理）帮忙公司施行政策和策略，以倒退与客户的在线关系。E-CRM 对于任何打算通过获取新客户和保留现有客户来实现盈利的企业来说都是至关重要的。简而言之，它寻求公司进步其营销销售和客户服务资源的生产力、效率和有效性。在大多数公司中，这些是独立的业务部门，为了独特的指标而独立工作。白码低代码开发平台能够定制CRM软件，如果你感兴趣，能够去白码的软件核心看看不同行业类型的企业经营治理系统软件，外面的零碎能够给你间接体验试用。 什么是电子CRM软件？客户关系治理(CRM)是一种辨认、获取和留住客户的形式——客户是企业最大的资产。通过提供治理和协调客户交互的伎俩，CRM帮忙公司最大化每次客户交互的价值，进而进步公司绩效。电子客户关系治理（E-CRM）是一种集成的在线销售、营销和服务策略，用于辨认、吸引和留住组织的客户。它形容了通过翻新技术创立和加强客户交互来改善和减少组织与其客户之间的沟通。电子CRM软件提供了组织与其客户的每次互动的详情和历史，使其成为所有中小型企业的重要工具。E-CRM还容许宽泛配置角色，以便您能够确保选定的成员只能拜访他们须要的信息。 电子CRM软件的性能用户治理：提供对所有客户信息的拜访，包含查问状态和通信。常识治理：解决和共享客户信息的集中式知识库。帐户治理：拜访客户信息和历史记录，让销售团队和客户服务团队高效运作。案例治理：捕捉查问、降级优先案例并告诉管理层未解决的问题。后端整合：通过相干的客户联络点（如网站和呼叫核心）与其余零碎（如计费、库存和物流）混合。报告和剖析：生成对于客户行为和业务规范的报告。 电子CRM软件的益处白码低代码开发平台能够定制CRM软件，如果你感兴趣，能够去白码的软件核心看看不同行业类型的企业经营治理系统软件，外面的零碎能够给你间接体验试用。服务水平改良：应用集成数据库提供统一且改良的客户响应。支出增长：通过专一于留住客户和应用交互式服务工具销售更多产品来降低成本。生产力：统一的销售和服务程序，以创立高效的工作流程。客户满意度：主动客户跟踪和检测将确保满足查问和治理问题。这将改善客户在与组织打交道时的整体体验。自动化： E-CRM 软件有助于自动化流动，包含电话营销、电话销售、直邮、潜在客户跟踪和响应、机会治理、报价和订单配置。 抉择应用电子CRM软件电子客户关系管理软件波及将 Web 渠道集成到整个企业 CRM 策略中，指标是在与销售、客户服务和反对 (CSS) 以及营销打算相干的所有渠道中放弃一致性。它能够反对无缝的客户体验，并最大限度地进步客户满意度、客户忠诚度和支出。白码能为您定制CRM软件，可分割客服征询。制订和施行电子CRM 解决方案的企业可能围绕技术调整其流程，以跨所有渠道无效地提供无缝、高质量的客户体验。客户能够通过按需提供的在线个性化服务来帮忙本人。互联网提供了一种简略而现实的媒介，客户能够在其中从网站获取信息、购买产品并应用常见问题解答局部、论坛或聊天室找到答案。

京东RPA：以企业数字化转型为驱动的机器人流程自动化解决方案专家京东RPA视频介绍：【点击观看】 什么是京东RPA？ 京东RPA（Robitic Process Automation）是通过模仿并加强人类与计算机交互的过程，解决反复有法则的 跨零碎、跨平台、耗时性、易出错 的工作流，提供疾速、非侵入式的解决方案，实现工作流程中的自动化。 京东RPA通过京东团体多年的外部验证，为各行业客户和合作伙伴提供场景化的RPA服务及能力，在批发、财务、物流等多行业深入浅出实际，晋升企业信息化、自动化解决程度，帮忙企业深度降本增效，同时放弃零碎稳固牢靠运行。 京东RPA次要有三局部组成： 机器人设计器，机器人控制台，和机器人运行客户端。 机器人设计器-机器人运行程序搭建， 实现人的操作模仿， 零碎断路串联；机器人服务端-机器人工作调配与监控、权限管控；机器人运行客户端-位于客户端运行 流程程序与业务 零碎进行间接交互软件机器人。 为什么抉择京东RPA？ 京东RPA应用外围自研技术，联合云属性，集成自研AI能力，提供全方位的一站式。 京东RPA能够做什么？ 京东RPA能够干什么？ 经典案例： 案例一 案例一视频：【点击观看】 RPA机器人可主动登录银行客户端、主动依据条件流水明细、主动下载银行流水明细，财务人员能够间接应用最新的银行流水进行流水报表、剖析等业务。相比拟传统的财务报表业务解决流程中，公司财务员工须要将大量的财务报表或人员信息手动录入到相应表格中， RPA打消了易出错，耗时等问题，同时大幅晋升的工作效率，从传统形式的4小时缩短到10分钟以内，效率晋升了20倍以上。 案例二 案例二视频：【点击观看】 RPA个税申报机器人可主动登录个税客户端、主动填报信息、主动比照数据正确性，实现了报税全流程的自动化，大幅晋升了个税申报的效率和准确率： 人工报税每月须要400+小时，RPA报税机器人将时长升高至20小时， 效率晋升了95%。 全程根本无人工参加， RPA解决准确率可达100% ，无效躲避了人工操作产生的谬误。 举荐浏览：漫画：什么是 “智能供应链” ？电商举荐零碎做到60分容易，做到80分、90分却很难当 RPA 遇见人工智能 京东 RPA 实现 500% 效率晋升欢送点击【京东智联云】，理解开发者社区 更多精彩技术实际与独家干货解析 欢送关注【京东智联云开发者】公众号

凌晨6时，在德国与波兰边陲小城斯武比采，MBB物流公司创始人高松经营的海内仓内曾经熙熙攘攘。这里的货物次要通过亚马逊、亿贝等电商平台销售，约70%的包裹发往德国，波兰、英国和法国也是重要市场。“欧洲新冠肺炎疫情暴发以来，先是口罩等防疫物资，而后是各种居家用品，订单嗖嗖往上涨。”高松回顾说。 新冠肺炎疫情给寰球实体零售业带来冲击，消费者局部线下生存和生产需要转移至线上，跨境电商业务逆势增长。“中国卖家对海内环境与消费者需要变动的疾速响应能力一直进步，可能疾速辨认寰球生产趋势走向并灵便调整选品策略，尽显柔性供应链劣势。”亚马逊8月公布的无关2020中国进口跨境电商趋势的报告如是说。 订单暴增——高品质防疫物资和生活必需品最热门“个别7、8月是销售旺季，每月也就20万个包裹左右，但往年同期发货量60多万个，超过今年最火爆的圣诞销售季。”高松说，因为时差关系，每天凌晨到午后是他与中国国内客户沟通的工夫，最近他经常忙到午饭都来不及吃。 今年此时雇员都能够休假，但往年订单暴增，须要加班能力实现。眼下最让高松头疼的是用工有余。“这几个月始终在招人。”他说。 在德国北威州施韦尔姆市，浙江商人陈建军的海内仓里叉车穿梭，热气腾腾。他的自营品牌主打家居园林用品，是亚马逊欧洲站排名第三十四位的卖家。“疫情一来，人们去商场的机会少了，居家的工夫多了，正好网购装璜屋子。”陈建军说，这段时间家居用品销售额均匀上涨50%，火爆到中国国内的供给一度跟不上，不得不限度网购流量。 德国联邦贸易与投资署数字经济专家约翰纳斯·费舍尔对本报记者说，从4月开始，德国电商业务止跌回升。无关剖析机构5月的报告显示，与疫情前相比，德国电子商务业务整体增长36%。德国第二大电商平台欧图统计，哑铃、办公椅、电动剪发器、桌面游戏等商品都创下了销售纪录。 “哑铃简直脱销。我的一位国内客户，以往一年也就卖一个柜(集装箱)，往年到当初曾经卖出5个柜。”高松说，“有的哑铃甚至是从中国间接用卡车拉过来的，开了6000多公里。” 除哑铃外，瑜伽垫、球拍、自行车等销量都大幅增长，电动理发器出货量更增长10倍。正如亚马逊报告所指出：疫情期间，中国卖家及时为寰球消费者提供了高品质的防疫物资和生活必需品。 疾速交付——为客户提供本地化服务和稳固供应链费舍尔示意，从2013年到2019年，德国电商市场增长85%，2020年，德国电商市场规模预计将超过800亿欧元。依据欧洲电子商务协会的数据，欧洲电商市场将在今年底达到7170亿欧元。 中国卖家的角色愈发重要。依据寰球出名互联网考察机构公布的报告，2019年，37%的德国消费者从国外电商卖家购买商品，其中大部分卖家来自中国。电子商务钻研机构市场脉动往年1月的数据显示，目前亚马逊前一万名的卖家中，中国卖家占到49%，比去年减少11个百分点，跻身榜首。 在费舍尔看来，疾速交付是博得客户的要害。德国位于欧洲核心地位，在当地设立海内仓，为客户提供本地化服务和稳固供应链，是决定性的竞争劣势。目前，阿里巴巴已在德国建设两个大型物流核心，其余中国公司也紧随其后。 “从海内仓发货，德国境内个别24小时内送达，欧盟范畴内个别不超过48小时。”高松说。 现在，MBB海内仓的面积超过5万平方米，好像一个缩微版的义乌市场：针头线脑、家居用品、电子产品、机械零件，一应俱全。十几万个库存量单位中，商品总数超过500万件——它们来自近300家中国电商搭档，背地更分割着数千家中国制作企业。陈建军的仓库也增长到6万平方米，服务国内1000多家供货商。 去年，MBB海内仓新建了机器人智能仓，波兰人罗西克被任命为经理，这让他颇为骄傲：在整个德波边陲，他是少有的治理相似仓库的经理。 “站在工位上，把货物拿进去扫码，再放到配送箱里。这样订单就解决完了。”在罗西克的领导下，记者尝试解决了一批订单。仓储机器人沿着布局路线来回穿梭。从搬来的货架上，记者取出12台手机，别离扫机盒和配送箱条形码，12个配送单主动生成，全程耗时不到一分钟。 智能仓的机器人驱动软件、仓库管理系统，全副由高松的国内团队自主研发。“以前工人一天要在仓库里走15至20公里，每小时拣170件左右。当初机器人能够做到一小时拣700件。”罗西克说。 科学管理——中国进口跨境电商逐渐转向精耕细作从传统外贸到智能仓库，高松亲历了行业的微小转型，但他始终记得上世纪90年代做塑料花贸易的经验：“中国产的塑料花运到鹿特丹，再分销到欧洲各地。过后分销商采购时只会模糊地说花是从荷兰运来的，以示品质低劣，大家都晓得荷兰是鲜花大国。”现在，无论是在电商平台上还是在海内仓里，“中国制作”早已司空见惯，这背地，是中国品牌价值的日益晋升。 “中国进口跨境电商逐渐转向精耕细作，卖家更关注业务的长期倒退，在产品开发、品牌注册和构建、品牌爱护等方面继续投入。”亚马逊中国副总裁戴竫斐示意，2017至2019年间，亚马逊上实现品牌注册的中国卖家数量增长高达10倍。 MBB智能仓的建设也与品牌无关：穿梭其间的机器人，运送最多的是一加手机。这一胜利跻身欧美中高端市场的中国品牌，近年来销售量迅速增长，MBB海内仓必须进步周转效率。 “每到新手机发售日，会有很多粉丝提前排队等待。”高松说。在代理其余品牌物流服务的同时，高松也注册了10多个日用品牌在网络平台销售。 “现在贴牌生产的利润空间越来越小，中国电商必须建设本人的品牌，扎根本地市场。”陈建军也有同感，在把自营品牌做到亚马逊顶级卖家后，他也在思考如何拓展新的空间。 在施韦尔姆仓库旁，一个簇新的品牌展示中心正在装修，陈建军打算在这里向德国客户展现样品，为更多中国中小品牌进入德国乃至欧洲电商市场提供集报关清关、仓储物流、市场推广、渠道拓展等于一体的综合服务。“目前德国电商业务仍在持续增长，期待中国公司的翻新倒退能进一步刺激德国的电商业务，特地是发明新的平台和解决方案。”费舍尔说。

糟糕的最后一公里最近在某东买了一个水龙头，顺带买了一个安装服务。服务介绍页面是这样的一切看上去很清楚，按流程就搞定。S90113-102938.pngS90113-102442.pngS90113-102928.png但是实际操作起来真的很糟心。收到水龙头的某天，接到一个陕西西安的手机电话，就是个人手机不是什么服务号码，说是帮忙安排安装，然后给了一个师傅的电话，让我联系这个师傅，跟师傅取得联系，师傅说下周一来安装，周一前2天联系师傅，师傅说不好意思啊，跟承包方有资金没结清，不来了，重新致电陕西西安的号码，说再安排下，等了一天没有消息，再次致电陕西西安的号码，说帮我安排，又没有消息，最后又致电这个号码，又回复说师傅嫌太远不来了，要不你在附近找个师傅，我去，我说我不装了退款吧，陕西西安说，只能退你50，另外10块被京东提成了。到这里，大概清楚了，这个所谓安装服务的运作模式，其实就是，平台负责包装，然后层层转包。每层扒一层皮，最后这一层的质量也没办法保证。突然想起自己买的一些理财产品，吓出一身冷汗。果断退款，60全退，自己在建材市场门口找了个师傅，业务又好，态度又好，留了电话方便售后，50块搞定，过程及其舒适。而且安装师傅还得到了更高的回报，如果按照之前安装服务层层砖包的模式，最后干活的师傅最多也就拿到40。其实我遇到的问题，就是典型的互联网商业落地最后一公里的问题，特别是这种服务行业，目前这种模式不能保证用户每次都能获得一致的好的体验，全凭运气，因为用户订购服务的平台自己都不知道给你服务的是谁。想到几个问题。1.这种模式即使有改进的空间，但是平台有没有动力去改进。2.平台其实就是信息枢纽。3.如果平台垄断了信息怎么办。4.幸好现在还没有垄断。5.未来手艺人，只能被信息平台剥削？信息去中心化能不能帮到这些人里的多数。6.未来普通用户，只能被信息平台绑架吗。

作者介绍刘春辉，Shopee DBA洪超，Shopee DBA一、业务场景Shopee（https://shopee.com/）是东南亚和台湾地区领先的电子商务平台，覆盖新加坡、马来西亚、菲律宾、印度尼西亚、泰国、越南和台湾等七个市场。Shopee 母公司 Sea（https://seagroup.com/）为首家在纽约证券交易所上市的东南亚互联网企业。2015 年底上线以来，Shopee 业务规模迅速扩张，逐步成长为区域内发展最为迅猛的电商平台之一：截止 2018 年第三季度 Shopee APP 总下载量达到 1.95 亿次，平台卖家数量超过 700 万。2018 年第一季度和第二季度 GMV 分别为 19 亿美金和 22 亿美金，2018 上半年的 GMV 已达到 2017 全年水平。2018 年第三季度 GMV 达到了创纪录的 27 亿美元, 较 2017 年同期年增长率为 153%。2018 年双 11 促销日，Shopee 单日订单超过 1100 万，是 2017 年双 11 的 4.5 倍；刚刚过去的双 12 促销日再创新高，实现单日 1200 万订单。<center>图 1 Shopee 电商平台展示图</center>我们从 2018 年初开始调研 TiDB，6 月份上线了第一个 TiDB 集群。到目前为止我们已经有两个集群、60 多个节点在线运行，主要用于以下 Shopee 业务领域：风控系统：风控日志数据库是我们最早上线的一个 TiDB 集群，稍后详细展开。审计日志系统：审计日志数据库存储每一个电商订单的支付和物流等状态变化日志。本文将重点展开风控日志数据库选型和上线的过程，后面也会约略提及上线后系统扩容和性能监控状况。二、选型：MySQL 分库分表 vs TiDB<center>图 2 风控日志收集和处理示意图</center>风控系统基于大量历史订单以及用户行为日志，以实时和离线两种方式识别平台上的异常行为和欺诈交易。它的重要数据源之一是各种用户行为日志数据。最初我们将其存储于 MySQL 数据库，并按照 USER_ID 把数据均分为 100 个表。随着 Shopee 用户活跃度见长，数据体积开始疯长，到 2017 年底磁盘空间显得十分捉襟见肘了。作为应急措施，我们启用了 InnoDB 表透明压缩将数据体积减半；同时，我们把 MySQL 服务器磁盘空间从 2.5TB 升级到了 6TB。这两个措施为后续迁移 MySQL 数据到 TiDB 多争取了几个月时间。关于水平扩容的实现方案，当时内部有两种意见：MySQL 分库分表和直接采用 TiDB。1. MySQL 分库分表基本思路：按照 USER_ID 重新均分数据（Re-sharding），从现有的 100 个表增加到1000 个甚至 10000 个表，然后将其分散到若干组 MySQL 数据库。优点：继续使用 MySQL 数据库 ，不论开发团队还是 DBA 团队都驾轻就熟。缺点：业务代码复杂度高。Shopee 内部若干个系统都在使用该数据库，同时我们还在使用 Golang 和 Python 两种编程语言，每一个系统都要改动代码以支持新的分库分表规则。2. 直接采用 TiDB基本思路：把数据从 MySQL 搬迁至 TiDB，把 100 个表合并为一个表。优点：数据库结构和业务逻辑都得以大幅简化。TiDB 会自动实现数据分片，无须客户端手动分表；支持弹性水平扩容，数据量变大之后可以通过添加新的 TiKV 节点实现水平扩展。理想状况下，我们可以把 TiDB 当做一个「无限大的 MySQL」来用，这一点对我们极具诱惑力。缺点：TiDB 作为新组件首次引入 Shopee 线上系统，我们要做好「踩坑」的准备。最后，我们决定采用 TiDB 方案，在 Shopee 内部做「第一个吃螃蟹的人」。风控日志数据库以服务离线系统为主，只有少许在线查询；这个特点使得它适合作为第一个迁移到 TiDB 的数据库。三、上线：先双写，后切换我们的上线步骤大致如下：应用程序开启双写：日志数据会同时写入 MySQL 和 TiDB。搬迁旧数据：把旧数据从 MySQL 搬到 TiDB，并完成校验确保新旧数据一致。迁移只读流量：应用程序把只读流量从 MySQL 逐步迁移至 TiDB（如图 3 所示）。停止双写：迁移过程至此结束。<center>图 3 迁移过程图：保持双写，逐步从读 MySQL 改为读 TiDB</center>双写方式使得我们可以把整个切换过程拖长至几个月时间。这期间开发团队和 DBA 团队有机会逐步熟悉新的 TiDB 集群，并充分对比新旧数据库的表现。理论上，在双写停掉之前，若新的 TiDB 集群遭遇短时间内无法修复的问题，则应用程序有可能快速回退到 MySQL。除此之外，采用双写方式也让我们有了重构数据库设计的机会。这一次我们就借机按照用户所属地区把风控日志数据分别存入了七个不同的逻辑数据库：rc_sg，rc_my，rc_ph，…，rc_tw。Shopee 用户分布于七个不同地区。迁移到 TiDB 之前，所有日志数据共存于同一个逻辑数据库。按照地区分别存储使得我们能够更为方便地为每个地区的日志定制不同的数据结构。四、硬件配置和水平扩容上线之初我们一共从 MySQL 迁移了大约 4TB 数据到 TiDB 上。当时 TiDB 由 14 个节点构成，包括 3 个 PD 节点，3 个 SQL 节点和 8 个 TiKV 节点。服务器硬件配置如下：TiKV 节点CPU: 2 * Intel(R) Xeon(R) CPU E5-2640 v4 @ 2.40GHz, 40 cores内存: 192GB磁盘: 4 * 960GB Read Intensive SAS SSD Raid 5网卡: 2 * 10gbps NIC BondingPD 节点和 SQL 节点CPU: 2 * Intel(R) Xeon(R) CPU E5-2640 v4 @ 2.40GHz, 40 cores内存: 64GB磁盘: 2 * 960GB Read Intensive SAS SSD Raid 1网卡: 2 * 10gbps NIC Bonding截至目前，系统已经平稳运行了六个多月，数据量增长至 35TB（如图 4 所示），经历了两次扩容后现在集群共包含 42 个节点。<center>图 4 风控日志 TiDB 数据库存储容量和使用状况</center>性能<center>图 5 风控日志 TiDB 数据库 QPS Total 曲线</center>风控日志数据库的日常 QPS（如图 5 所示）一般低于每秒 20K，在最近的双 12 促销日我们看到峰值一度攀升到了每秒 100K 以上。尽管数据量较之 6 个月前涨了 8 倍，目前整个集群的查询响应质量仍然良好，大部分时间 pct99 响应时间（如图 6 所示）都小于 60ms。对于以大型复杂 SQL 查询为主的风控系统而言，这个级别的响应时间已经足够好了。<center>图 6 风控日志 TiDB 数据库两天 pct99 查询响应时间曲线</center>五、问题和对策TiDB 的字符串匹配区分大小写（Case Sensitive）。目前尚不支持 Case Insensitive 方式。应用程序做了适配以实现 Case Insensitive 方式的字符串匹配。TiDB 对于 MySQL 用户授权 SQL 语法的兼容支持尚不完善。例如，目前不支持 SHOW CREATE USER 语法，有时候不得不读取系统表（mysql.user）来查看一个数据库账户的基本信息。添加 TiKV 节点后需要较长时间才能完成数据再平衡。据我们观察，1TB 数据大约需要 24 个小时才能完成拷贝。因此促销前我们会提前几天扩容和观察数据平衡状况。TiDB v1.x 版本以 region 数目为准在各个 TiKV 节点之间平衡数据。不过每个 region 的大小其实不太一致。这个问题导致不同 TiKV 节点的磁盘空间使用率存在明显差异。据说新的 TiDB v2.x 对此已经做了优化，我们未来会尝试在线验证一下。TiDB v1.x 版本需要定期手动执行 Analyze Table 以确保元信息准确。PingCAP 的同学告诉我们说：当 (Modify_count / Row_count) 大于 0.3 就要手动 Analyze Table 了。v2.x 版本已经支持自动更新元数据了。我们后续会考虑升级到新版本。mysql> show stats_meta where db_name = ‘aaa_db’ \G*************************** 1. row *************************** Db_name: aaa_db Table_name: xxx_tab Update_time: 2018-12-16 23:49:02Modify_count: 166545248 Row_count: 85685607081 row in set (0.00 sec)六、未来规划过去一年亲密接触之下，我们对 TiDB 的未来充满信心，相信 TiDB 会成为 Shopee 数据库未来实现弹性水平扩容和分布式事务的关键组件。当前我们正在努力让更多 Shopee 业务使用 TiDB。我们规划把 Shopee 数据从 MySQL 迁移到 TiDB 上的路线是「先 Non-transactional Data（非交易型数据），后 Transactional Data（交易型数据）」。目前线上运行的集群都属于 Non-transactional Data，他们的特点是数据量超大（TB 级别），写入过程中基本不牵涉数据库事务。接下来我们会探索如何把一些 Transactional Data 迁移到 TiDB 上。MySQL Replica 是另一个工作重点。MySQL Replica 指的是把 TiDB 作为 MySQL 的从库，实现从 MySQL 到 TiDB 实时复制数据。我们最近把订单数据从 MySQL 实时复制到 TiDB。后续来自 BI 系统以及部分对数据实时性要求不那么高的只读查询就可以尝试改为从 TiDB 读取数据了。这一类查询的特点是全表扫描或者扫描整个索引的现象较多，跑在 TiDB 可能比 MySQL 更快。当然，BI 系统也可以借助 TiSpark 绕过 SQL 层直接读取 TiKV 以提升性能。目前我们基于物理机运行 TiDB 集群，DBA 日常要耗费不少精力去照顾这些服务器的硬件、网络和 OS。我们有计划把 TiDB 搬到 Shopee 内部的容器平台上，并构建一套工具实现自助式资源申请和配置管理，以期把 DBA 从日常运维的琐碎中解放出来。七、致谢感谢 PingCAP 的同学一年来对我们的帮助和支持。每一次我们在微信群里提问，都能快速获得回应。官方架构师同学还不辞辛劳定期和我们跟进，详细了解项目进度和难点，总是能给出非常棒的建议。PingCAP 的文档非常棒，结构层次完整清晰，细节翔实，英文文档也非常扎实。一路跟着读下来，受益良多。TiDB 选择了 Golang 和 RocksDB，并坚信 SSD 会在数据库领域取代传统机械硬盘。这些也是 Shopee 技术团队的共识。过去几年间我们陆续把这些技术引入了公司的技术栈，在一线做开发和运维的同学相信都能真切体会到它们为 Shopee 带来的改变。 ...