华为云TaurusDB计算存储分离架构:让数据“身”分离,“心”凝聚

随着企业的不断发展,企业产生大量的数据,这些数据既要保存下来,又要它们产生相应的价值。事实上,如何将数据存储并产生价值是每个企业不容忽视的问题。而在数字化和云端数据库蓬勃发展的今天,数据上云成为了众多企业数据库的首选。

%title插图%num

在2019年HC大会上,华为重磅推出*新一代高扩展海量存储分布式数据库——TaurusDB,它拥有一个*大的特点就是将存储和计算以一种分离的架构形式运行。很多人就会问到,华为云为什么会设计这款产品?核心竞争力是什么?对比原生MySQL的优势有哪些?借此时机,CSDN记者有幸采访到了华为云TaurusDB数据库资深技术专家,现在就请他来为我们一一解答。

源起:TaurusDB数据库的设计初衷
当前,中国有近70% 新型企业的业务因数据挑战而受影响。现在随着互联网的飞速发展,所产生的数据量是以几何的模式在增长。数据量大、数据种类多对数据库的性能、可靠性等要求也越来越高。像金融行业,不仅需要高可靠的存储设备性能,更要保障数据的安全。

“传统的数据库及数据库上云模式,越来越不能满足客户业务的快速扩展和智能运维需求,客户需要的是一套能够灵活扩展、智能诊断、支持跨云融合的新一代云端原生数据库系统。与大数据相辅相成的云数据库,尤其是基于云场景架构设计的云原生分布式数据库,成为了企业的*佳选择。“华为云数据库专家在谈及TaurusDB设计初衷时讲到,分布式数据库现在是一个大的新趋势,而TaurusDB的定位是企业级分布式数据库,针对企业的高并发、海量吞吐等需求,有着非常优异的表现。

华为云数据库专家介绍到,TaurusDB是*个基于MySQL 8.0开发的高性能新一代企业级分布式数据库,设计目标是利用云原生设计解决传统的关系型数据库问题。它支持并行查询,DDL操作的原子性,异步写日志等优化。业界同类型的数据库都是基于MySQL 5.6、5.7开发的,而TaurusDB的设计研发充分发挥了华为公司的全栈优势,利用数据库软件与底层硬件、CPU、网络、存储芯片等垂直产品技术的整合,发挥出华为软硬件结合后的整体*大优势,并且使用了自研Hi1822芯片,以及下一代高性能DFV存储服务器、RDMA网络。

蝶变:左手计算,右手存储
TaurusDB 作为一个分布式集群架构,采用计算与存储分离、日志即数据的架构设计,支持1写15读的模式,性能可达到原生MySQL的7倍。此外,TaurusDB是构建在共享分布式存储上,存储空间*高达128T,能跨AZ部署。

%title插图%num

TaurusDB利用计算存储分离架构,可以把数据库逻辑下推到存储层进行计算,充分发挥存储层的分布式计算能力,进一步提升数据库的性能,减少网络开销。针对TaurusDB的架构优势,华为云数据库专家分别就计算和存储两个层面做了阐述:

计算层

在计算层,TaurusDB采用了无锁优化,异步提交,主备机同步不再使用Binlog的模式。这个模式的好处就是大大释放了主机的压力,主机只管做“自己”的事情,无需和备机进行交互。相比传统的MySQL数据库,TaurusDB只需要5分钟就可以增加一个备机,即使增加到15个备机也不会有任何影响,而MySQL*多可加到5个左右的备机。

华为云数据库专家在采访中举例,Binlog的缺点是需要同步给所有的备机,相当于有多少备机就要同步到多少台机器中,这样做的后果就是直接拉低了主机的正常工作性能。因此,传统架构*多可以增加到5台备机,再增加备机就会导致无法正常工作。

存储层

TaurusDB存储层实现数据分片存储,保证故障快速恢复。例如:一共有1TB数据,即使只有1个字节的内容损坏,也需要恢复1TB的数据,且恢复时间非常长。但是如果实现分片存储,我们只需要恢复被破坏数据所在的分片即可。比如1TB数据,TaurusDB把它分成100个10GB的数据分片,如果只是某个分片坏了,就只需要恢复这10GB的数据即可。

“存储池化带来的好处就是,用户不需要担心存储空间不够用,存储层会根据当前容量进行自动扩容。”专家表示,客户无需担心存储容量的问题,TaurusDB自动在后台进行扩容。“按需收费,自动扩容”为客户带来非常人性化的产品体验服务。

谈及数据,“安全”就是不得不提的一个话题。在安全方面,TaurusDB的安全性能比原生MySQL更高。首先,数据分布式存储,并且是跨可用区的多副本,确保数据0丢失。其次,存储层本身就有一套成熟的数据隔离和加密机制。再次,MySQL8.0相对比原生MySQL 5.6、MySQL 5.7,在安全性方面也做了很多的优化和提升。*后, TaurusDB通过与DBSS(数据库安全服务)的透明化集成,不用修改应用,只需在界面配置即可享受智能化的安全保障,可以防御各种网络攻击,防护数据泄露。当前,华为云数据库已通过可信云认证,可提供国际级的隐私和数据保护。

目前,关系型数据库的场景都可以使用TaurusDB,尤其像读写负载*高的场景,例如社交应用,大型网站等。这些系统的数据量很大,并且增长较快,数据库并发访问量很高。传统的做法是使用分库表中间件,但是中间件对应用的开发有较高的要求,而且有比较多的使用限制。而TaurusDB本身就支持128TB的容量,在使用上和MySQL也没有任何区别,不需要客户自己做分库分表。另外,对性能和数据可靠性上有较高要求的业务,TaurusDB也是一个很好的选择。

升华:探索技术高峰,赋能行业发展
现在的企业都在走向信息化、互联网化,既要保存海量数据,还要使用和分析这些海量数据,那么未来OLTP和OLAP的混合型数据库也是一个重要的发展趋势,客户能够在一个数据库上快速完成交易和分析业务。未来云上的分布式数据库,计算存储分离是一个大趋势,在此架构之下,可以做很多的优化和提供更多的新功能。

现在TaurusDB产品即将公测上线,明年正式对外商用。华为云数据库专家表示,在接下来的产品研发中,会结合华为硬件优势,软硬件结合,进一步优化和提升性能。同时基于计算存储分离的架构,在多写、HTAP、算子下推等方面做进一步的研发。

不仅如此,华为云也将同步更新社区,让用户同时享受商业级的技术服务和开源软件的生态红利。华为云数据库专家表示,现在的MySQL用户可以零门槛地切换到TaurusDB,只要对SQL有所了解,就能操作TaurusDB。华为云数据库团队还在今年组织了TaurusDB性能挑战赛,希望吸引更多开发者关注TaurusDB产品,使其能够在不同的场景下产生价值。
————————————————

原文链接:https://blog.csdn.net/sch881226/article/details/103324306

技术人的灵魂 3 问,阿里工程师如何解答?

%title插图%num

**导读:**在业务团队做事的工程师摸爬滚打了一段时间后,一定会有所疑问。团队同学在*初的一段时间都提出这样的疑惑:如何在业务中发现有技术价值的问题?发现问题后如何思考和发起再到解决?*后的技术结果跟业务结果如何衔接?很多时候我们听别人说“思考是不够的/要多思考”,其实都是在说这几点。接下来,阿里高级前端技术专家氐宿谈一谈遇到这三个问题时,他是如何解决的?

如何在业务中发现有技术价值的问题?
一位科学家一生可用于研究的时间*其有限,然而,世界上的研究主题却多得数不清。如果只因为稍微觉得有趣就选为研究主题,将在还没来得及做真正重要的事时,一生就结束了。
——利根川进

其实要解答这个问题之前,我们要理解一个概念,什么是有价值的问题?议题度高和解答质高的问题我理解就是有价值的问题,比较通俗的理解就是这个问题是否存在,当前要解决这个问题的必要性够不够,问题对应的解决方案可行性高不高。如果要在业务里发现这种问题,首先要理解业务战略、打法和定位。那如何才能把这个前置信息做好,对工程师来说是一个比较大的挑战。

首先工程师其实大多数都是从事一线开发,对业务理解可能仅限于自己在做的事情。很多信息都是别人过滤了五六手之后的信息,得到的可能就是一个任务和为什么做这个任务。相对比之下肯定不如制定战略的人懂得战略背后的意义,信息也是不对等的。所以首先我们要收集信息,然后整理归纳,*后分析问题。

1. 先来说说收集信息
其实有点像信息科学里的情报学。收集信息*好的方式就是参加所处业务老大的 KO 会,各种 KO 会会把战略上的拆解和背后的思考整体梳理之后宣讲传达给 BU 或部门的同学,虽然我们没有亲身参与到脑暴过程,但是也会对背后的思考有一定的理解,切记,一定要记得划重点记笔记。

获取*手信息之后,我们要经过简单梳理开始收集外部信息,整理整体的知识脉络,这里我经常用的就是阿里学习(业务宝库阿里学习,技术宝库 ATA,注:阿里内部两个学习平台),可以获取不少业务相关的分享,当然很多外部渠道也同样可以收集到。比如资料《飞猪“新旅行联盟”赋能商家能讲出什么新故事?》就是外部收集到的,可以得出几个关键词,数字技术赋能旅行行业、我们不是 OTA,这些都要整理到自己收集的信息池里。当然以上我提到的都是信息获取源的一种。具体收集信息的释义可以查一下百科,可以按照百科上的方法论学习一遍,以便找到适合自己的方法。总之这里我们要像产品经理一样去收集这些信息。这里也鼓励跟不同领域不同BU的同学多交流,不限于线下扯淡式的交流和线上问问题的方式(这里建议先看下知乎里这个回答关于学会问问题以及如何进行有效社交。

2. 分析问题
我们通过不同信息源获取到的信息是散落的,如何经过加工融入自己的思考体系呢?首先信息不能是简单的堆叠,我们要通过不同的入口理出头绪。可以使用 MECE 法则进行思考拆解,通过无遗漏无重复地分类来把握整体,列出脑图和逻辑树,*后将逻辑树的信息匹配需求场景,可以尝试通过 C 端和 B 端不同入口去还原需求场景。这中间可以结合一定的方法论(演绎推理和归纳推理),去把问题和挑战细化出来,帮助我们理解 BU 的战略,同时我们也能从自身出发把战略拆解到对应的项目。举例来说去年我个人分析飞猪在整个 C 端面临的主要问题之一还是流量格局过于单一,B 端供应链的成熟度不够导致无法给到商家更实质的体验服务,飞猪的类目交叉不够背后是各垂直业务存在业务隔离。

%title插图%num

发现问题到执行该如何衔接?
拿到这三个问题我们不能马上就开干,我们还要提炼这个问题带来的核心价值。否则很容易就会出现投入了巨大工作之后,*后的技术产出和业务结果衔接不上,所以说思考不要用蛮力,工作不只靠体力。要去看里面跟自己角色相关的工作在什么地方?

以端侧来说,有优势的一点是靠近产品侧靠近用户侧,所以基本展现模式都可以通过产品原型进行抽象,形成体系化。以流量体系建设举例我们要对用户进行分层,比较合理的方式可以用到几个经典模型RFM、AIPL、AARRR及其变种,以便沉淀出承接的技术平台或产品。如流量体系建设我们在思考分层过后,把用户按心智划分之后,又从所属域分为散落在阿里域外的用户和阿里域内的内部用户,从而针对性的设计出两个平台产品。
%title插图%num

1. 见龙在田,利见大人
作为项目发起者,我们要关注每一个环节。所以首先我们要找到对应的业务方去“售卖”我们的思考。要找到目标一致的人一起做事,这里首先需要知道的是你要清楚你的业务方都是谁?他们都负责什么?我的方法比较简单,直接看运营在职能上的划分,要清楚自己对的人负责的方向以及他所负责的 KPI。另外切记,一定要和对口 PD 一起去找,通常来说*直接的合作方是能帮你处理业务和技术衔接的那个人。

上下游的人都找到后,要开始准备 KO,理出需求排出优先级。因为在资源有限的情况下,我们究竟该先做哪些?不重要的要放在后面去做,优先考虑你产品*核心的功能。通常平台产品*优先的是运营使用的功能,所以要跟合作方确认哪些功能他们认为*重要。

2. 站在巨人的肩膀上做创新
阿里巴巴已经非常大了,我们相信每一个想法都会有人想过,所以尽量不要走重复的路踩同一个坑,同理小公司利用开源技术亦是如此。那么在项目开始做的时候,如果是平台,我们需要先拆出核心功能,这个核心功能要去看集团是否已经有人在做了或是有成熟方案,避免重复造轮子,同时也能*快*直接的解决你*紧急核心的问题。这其中*简单直接方法就是搜索 ATA(阿里内部技术论坛)和语雀(内部同学通常有知识记录的习惯),拆关键词找到做事情的关键人。你要相信你*不是*个想到该问题的人,一些通用问题一定在集团内已经有通用的服务提供出来,即使没有也会有比较成熟的方案。

如果集团内部就是没有成型方案,这个方向也属于工业界比较前沿的领域。遇到类似这种问题,可以先看看是否有绕开的可能性,如果确实绕不开可以试试找到适合解决该问题的基础团队一起合作和共建。外部是否有付费方案可以购买和借鉴,总之要保障业务先赢。因为业务工程师要思考的是你给业务能带来怎样的价值,你的核心价值不是处理非常复杂的技术问题,而是用你的技术能给业务带来怎样的价值增量。同样的利用某种技术或模型模式解决了非常复杂的业务问题,并且是具有普适价值的技术,这也是业务端工程师带给业务带来的价值。

3. 立足当下,放眼未来
知几,其神乎!

要看当下更要看未来,不光技术要看未来,行业也要看未来。站在当下思考能解决业务目前遇到的*大的问题,思考未来能为业务带来弯道超车的机会。比如飞猪如果在行业里要追赶同行业的竞品,在资源投入方面没办法跟对方的体量比较的情况下,我们做到*后,*好的结果可能也只是追平对手。所以我们亟须找到未来行业争胜的关键按钮,把时间和精力聚焦在关键节点,用全球Fun战略突围。所以飞猪也要为国际化做好准备,这个领域里同样有前人探寻的技术经验供我们借鉴。所以为了让我们能更聚焦业务,可以说去年的平台化是为业务做了非常好的铺垫。

*后的技术结果跟业务结果如何衔接?
其实这个小标题有点伪命题的意思,如果一开始我们就把业务理解的很清楚,执行没有偏离航道比较专注目标的话,不大可能会出现拿不到业务结果的情况,*后只剩下一个问题:拿到业务结果的同时技术价值如何体现?

从我自身出发,也常常有同学问我,在业务做开发,重复造轮子会被人挑战,但事情都有人干了我们的价值在哪?我之前一直都会回答,“搞基础技术的团队一直在基础工程/技术领域深耕,他们也需要关注从技术价值到业务价值的转变和衔接,本质上缺少业务场景,如果我们与他们合作就形成了互补,既拿到了业务结果同时也能从自身技术成长上得到一定历练”。

但之后我回想这段对话,是有很多问题在里面的。从业务工程师角度出发,我们要关注的核心就是保障业务先赢,如果没有达到这个目标就容易变成工程师自嗨。所以我们在业务端需要的是有技术视野能看到集团其他团队或者外部团队在做的事,能主动交流让这件事变成共赢,如果没有其他人在搞,我们去搞要有人站出来看这个投入产出比是否合理?也就是我们在开篇说的议题度和解答质都高的有价值的问题。这个问题在集团其他团队是否存在共性,我们解决了能否为他们带来价值?当然结合我们在前面讲到的在业务中发现有技术价值的问题,其实这里就有一个比较明确的答案,重中之重就是做之前把 Why 思考的清楚清晰,做*正确的事。只有做到这点,解决这个问题带来的业务价值就自然而然非常清晰的定位出来。所以说*好的工程师必须要懂产品。

也写给未来
小聊一下题外话,组里有同学会问我业务前端未来是否会被淘汰?因为我们在做的 lowcode/nocode 是在革自己的命。其实产生这种想法首先就是没有站在集团未来发展的角度去思考也就是常说的屁股太小,其次是没有站在整个前端领域去回顾前端发展历程导致的悲观和担忧。

从目前在做的方向上来说,还是要思考如何解决低质量代码建设和低效的重复工作占用工程师大部分精力,将工程师的能量解放出来提升集团整体的研发效能。另一层面从前端以往在系统分层里的位置一直都属于应用层,就是*上层的表象/展现/渲染,应用层在过去几十年间经过了不断的变化和演进,职业也从*早的 GUI 工程师演进到之后的 web 前端/客户端研发工程师,这中间也经历过 flash 工程师的时代,在此期间应用层/展现层一直都在变化,所以前端同学总觉得状态是一直在学习新知识。但这个发展历程其实是有规律可循的,所谓万变不离其宗,应用层虽然在不断变化但无非都是朝着两个大方向在发展,一个是工程效率提升(工程角度出发),一个是图形图像研究(用户角度出发)。这两个大方向上目前也有非常复杂庞大的树状知识体系,并且还在不断延伸。同时随着机器学习领域的兴起和硬件性能、网络带宽的提升以及人们在视觉呈现设备上的升级,带来的可能又是新一轮的技术洗牌,然后在两个方向上再来一次。所以从这个视角出发未来前端是不会消亡的可能只是会换一种形式存在,但是不学习的工程师是会消亡的。

*后
*后我想说的是来到一个新业务不要着急的去拿这两个结果(业务和技术),所谓“潜龙勿用”。要先去看业务在集团所处的位置,怎么和其他业务产生关联的,要去收集信息和问题,带着问题深入去做事情,通过跟其他人的信息交流补全业务痛点。先收集问题,边做边思考,先沉下心做业务项目。要有导弹型思维,就是不管三七二十一,先干起来再说。在行动中实现智能导航,锁定并跟踪目标,根据实际情况修正自身路径,直至击中目标。

其实写了比较多,也是对我做事情的方法论做了一遍梳理和总结,也是说*好不要让业务推着你走,而是*终要做到你带着业务走。这个“带”可能*初是理解业务打法之后的一种业务朝着你理解的方向去走的体感,但经过长期训练,这部分其实可以做实,*后真的是你通过技术创新引领行业变革*后驱动业务向前推进。当然这些是我来阿里三年的体会,虽然在来之前也已经工作了七八年,但在阿里成长的速度远远超过之前的成长,并且也才刚刚三年还是个“新人”,所以在这里也给自己个寄语,希望五年、十年之后我的思考又会升华到一个层次。同时也欢迎大家拍砖/评论, 原来我都是战战兢兢发文跟大家说轻拍,需要鼓励,但之后也是发现鼓励是*不容易发现问题,这会导致发现不了自身思考上的盲点和盲区,缺少成长路上的经验值,所以这里鼓励大家一起多交流。

*后的*后也给大家推荐相关的几本书,可能会对大家在上面几处没有展开来讲的去更详细的学习,希望有所帮助:《金字塔原理》、《麦肯锡教我的思考武器》、《思考,快与慢》、《影响力》、《自控力》、《敏捷性开发》。
————————————————

原文链接:https://blog.csdn.net/alisystemsoftware/article/details/107765100

漫画趣解——云计算的起源

云计算作为作为一个新兴的技术时尚名词,正受到计算机软件和互联网技能人员及商业模式研究人员的高度追捧,他们百折不回地认为云计算能把他们带出创新枯竭的互联网应用沙漠,并让他们跃升到同行中更高的岗位。

他们视其为救命稻草,他们计划抓住云计算这根看起来模含糊糊的稻草,正是如此,云计算文章铺天盖地,种种格局的研讨会此起彼伏,以致已经生长到以讹传讹、神乎其神、不能自拔的田地了。到底什么才是云计算呢?来看看下面这段对话吧!

*开始,人们使用算盘

后来,人们用电脑

再后来,人们有了网络

再后来,中国人口大爆炸,男女比例男的比女的多 3700 万,这三千多万人没事干,都去上网。于是服务器吃不消了。

于是人们就发明了牛逼的技术,用更好更多的服务器

再后来,人更多了,于是服务器也更多了

但事实上这样的效果并不好,过度繁重的结构加大了网站设计和构架的难度,而且越是复杂的系统越是不稳定。有可能一个出问题,这样一个完整的系统就彻底挂掉。如果考虑到系统的崩溃情况,那势必要引入一个更复杂的方案来保证不同的服务器可以做不同的支援。这是一个无解的循环,大量的计算资源被浪费在无限制的互相纠结中,很快到了瓶颈。

人们想,那我不用这么乱七八糟复杂的系统,我上个*其牛逼的服务器不就好了?可是,太贵了……而且*牛逼的也还没制造出来……

于是人们突然想到了一个好办法:把所有计算资源集结起来看成是一个整体(一朵云),通过并发使用资源完成操作请求。每个操作请求都可以按照一定的规则分割成小片段,分发给不同的机器同时运算,每个机器其实只要做很小的计算就可以,这是哪怕 286 机器都轻松完成的。*后将这些机器的计算结果整合,输出给用户。

对用户看来,他其实根本面对的不是许多机器,而是一个似乎真正存在的计算能力巨牛无比的单个服务器,比十台 System z10 大型主机揉一起,或是开创了 petaflop 新纪元的“拂晓”号与“红杉”号还要牛。事实上这个服务器是不存在的,但它拥有着成千上万台服务器的能力。

下面来看实例。

实际上过程没这么简单。哪怕是统计收集资料的过程也会占据可怕的处理时间。这就将云计算的任务进一步划分下去,哪个服务器的 CPU 干什么,处理哪个任务段。 这个其实可以由算法安排成自动分配的。

总之,压榨每一个步骤的潜力,让一个任务被服务器集群们一起上,自然能飞速达成。 别忘了,云计算不是弄个两三台质低价廉的服务器就可以达成的。每一朵云背后都有着一坨异构平台服务器,尤其是搭在企业防火墙里头的“私有云”。

因为企业的计算需求往往是复杂的,选择不同的平台应对不同的计算需求*划算,这跟农民伯伯拉什么或选什么车的道理一样。新鲜大白菜首选摩托车,保新鲜求快就用刀片;高级大白菜首选靠谱运输工具 Power 服务器;大量的高级大白菜选择大货车,正如I/O吞吐量大的数据适合使用大型主机 System z 一样,总比牛车一趟两趟要快吧?大型农场不会局限于某一种植物正如大型企业不会只有一种计算需求。于是便有了负责中枢管理、监控的软件 Tivoli,难不成用人脑统计?

*后,农民伯伯(很牛的 IT 客们)把这些车队集结起来就构成了一朵云背后比较硬的部分。很少 IT 大佬可以集齐全套车型,据我所知貌似只有 IBM 可以。 接下来解决比较软的问题:在已有的计算资源的基础不变的情况下,云计算把用户的任务请求做除法,一个请求进来,我们把它变成许多个小任务段,*后汇总出去给用户一个完整的结果。对用户来说,他根本感觉不到里面哪个 cpu 做了什么处理,哪部分是哪部分拼接起来的,他就感觉自己面对一台 5 亿内存 3 亿 GHZ 的巨无霸电脑一样。

用户对这样的计算莫名其妙,云里雾里的,于是他就把这个东西,叫做云计算。

如何将云原生工作负载映射到 Kubernetes 中的控制器

Kubernetes 不仅仅是一个容器管理工具。它是一个平台,旨在处理包装在任意数量的容器和组合中的各种工作负载。Kubernetes内置了多个控制器,可映射到云原生架构的各个层。

DevOps工程师可以将Kubernetes控制器视为指示团队运行的各种工作负载的基础架构需求的手段。他们可以通过声明方法定义所需的配置状态。例如,容器/pod作为ReplicationController的一部分部署保证始终可用。打包为DaemonSet的容器保证在集群的每个节点上运行。声明式的方法使DevOps团队能够利用代码控制基础架构。下面讨论的一些部署模式遵循不可变基础结构的原则,其中每个新的部署都会导致原子部署。

DevOps工程师可以通过声明方法定义所需的配置状态——每个工作负载映射到控制器。

了解云原生用例

Kubernetes的控制平面不断跟踪部署,以确保它们符合DevOps定义的所需配置状态。

Kubernetes的基本部署单位是一个pod。它是Kubernetes的基本构建块,是Kubernetes对象模型中*小和*简单的单元。pod表示集群上正在运行的进程。无论服务是有状态的还是无状态的,它总是打包并部署为pod。

控制器可以在集群中创建和管理多个pod,处理在集群范围内提供自我修复功能的副本。例如,如果节点发生故障,控制器可能会通过在不同节点上安排相同的pod用来自动替换该故障pod。

Kubernetes配有多个控制器,可以处理所需的pod状态。如ReplicationController、Deployment、DaemonSet和StatefulSet控制器。Kubernetes控制器使用提供的pod模板,来创建其负责pod的所需状态。与其他Kubernetes对象一样,Pod在YAML文件中定义并提交给控制平面。

在Kubernetes中运行云原生应用程序时,运维人员需要了解控制器解决的用例,以充分利用平台的特性。这有助于他们定义和维护应用程序的所需配置状态。

上一节中介绍的每种模式都映射到特定的Kubernetes控制器,这些控制器允许对Kubernetes的工作负载进行更精确,细粒度的控制,但是采用自动化方式。

Kubernetes的声明式配置鼓励不可变的基础架构。控制平面跟踪和管理部署,以确保在整个应用程序生命周期中维护所需的配置状态。与基于虚拟机的传统部署相比,DevOps工程师将花费更少的时间来维护工作负载。利用Kubernetes原语和部署模式的有效CI/CD策略使运营商无需执行繁琐的任务。

可扩展层:无状态工作负载

无状态工作负载在Kubernetes中打包并部署为ReplicaSet。ReplicationController构成ReplicaSet的基础,可确保在任何给定时间始终运行指定数量的pod副本。换句话说,ReplicationController确保一个pod或一组同类pod总是可用。

如果有太多pod,ReplicationController可能会终止额外的pod。如果太少,ReplicationController将继续启动其他pod。与手动创建的pod不同,ReplicationController维护的pod在失败,删除或终止时会自动替换。在诸如内核升级之类的破坏性维护之后,在节点上重新创建pod。因此,即使应用程序只需要一个pod,也建议使用ReplicationController。

一个简单的用例是创建一个ReplicationController对象,以无限期地可靠地运行pod的一个实例。更复杂的用例是运行横向扩展服务的几个相同副本,例如Web服务器。在Kubernetes中部署时,DevOps团队和运营商将无状态工作负载打包为ReplicationControllers。

在*近的Kubernetes版本中,ReplicaSets取代了ReplicationControllers。它们都针对相同的场景,但ReplicaSet使用基于 集合的标签选择器 ,这使得可以使用基于注释的复杂查询。此外,Kubernetes中的部署依赖于ReplicaSet。

Deployment是ReplicaSet的抽象。在Deployment对象中声明所需状态时,Deployment控制器会以受控速率将实际状态更改为所需状态。

强烈建议部署管理云原生应用程序的无状态服务。虽然服务可以部署为pod和ReplicaSet,但部署可以更轻松地升级和修补应用程序。DevOps团队可以使用部署来升级pod,而无法使用ReplicaSet完成。这样就可以在*短的停机时间内推出新版本的应用程序。部署为应用程序管理带来了类似于服务(PaaS)的功能。

持久层:有状态的工作量

状态工作负载可以分为两类:需要持久存储的服务(单实例)和需要以高可靠性和可用模式运行的服务(复制的多实例)。需要访问持久存储后端的pod与为关系数据库运行集群的一组pod非常不同。虽然前者需要长期持久的持久性,但后者需要高可用性的工作量。Kubernetes解决了这两种情况。

可以通过将底层存储暴露给服务的卷来支持单个pod。可以将卷映射到调度pod的任意节点。如果在集群的不同节点上调度多个pod并需要共享后端,则在部署应用程序之前手动配置分布式文件系统(如网络文件系统(NFS)或Gluster)。云原生态系统中提供的现代存储驱动程序提供容器本机存储,其中文件系统本身通过容器公开。当pod只需要持久性和持久性时,请使用此配置。

对于预计具有高可用性的场景,Kubernetes提供StatefulSets – 一组专门的pod,可确保pod的排序和唯一性。这在运行主要/辅助(以前称为主/从)数据库集群配置时尤其有用。

与部署类似,StatefulSet管理基于相同容器规范的pod。与Deployment不同,StatefulSet为其每个pod保留唯一标识。这些pod是根据相同的规范创建的,但不可互换:每个pod都有一个持久标识符,它可以在任何重新安排时保留。

StatefulSet对需要以下一项或多项的工作负载非常有用:

  • 稳定,独特的网络标识符。
  • 稳定,持久的存储。
  • 有序,优雅的部署和扩展。
  • 有序,优雅的删除和终止。
  • 有序的自动滚动更新。

Kubernetes对StatefulSets的处理方式与其他控制器不同。当正在使用N个副本调度StatefulSet的pod时,将按顺序创建它们,顺序从0到N-1。当删除StatefulSet的pod时,它们以相反的顺序终止,从N-1到0。在将一个扩展操作应用于pod之前,它的所有前驱必须正在运行并准备就绪。Kubernetes确保在终止pod之前,其所有后继者都完全关闭。

当服务需要运行Cassandra、MongoDB、MySQL、PostgreSQL集群或任何具有高可用性要求的数据库工作负载时,建议使用StatefulSet。

并非每个持久性工作负载都必须是StatefulSet。某些容器依赖于持久存储后端来存储数据。为了向这些类型的应用程序添加持久性,pod可能依赖于由基于主机的存储或容器本机存储后端支持的卷。

可并行化层:批处理

Kubernetes具有用于批处理的内置原语,这对于执行运行到完成作业或预定作业很有用。

运行到完成作业通常用于运行需要执行操作和退出的进程。在处理数据之前运行的大数据工作负载就是这种工作的一个例子。另一个示例是一个处理队列中每条消息的作业,直到队列变空。

作业是一个控制器,可以创建一个或多个pod并确保指定数量的pod成功终止。当pod成功完成后,Job会跟踪成功的完成情况。达到指定数量的成功完成后,作业本身就完成了。删除作业将清理它创建的pod。

Job还可以用于并行运行多个pod,这使其成为机器学习培训工作的理想选择。Job还支持并行处理一组独立但相关的工作项。

当Kubernetes在具有GPU的硬件上运行时,机器学习培训可以利用Job。诸如Kubeflow之类的新兴项目 – 一个致力于在Kubernetes上部署机器学习的简单,可移植和可扩展的项目 – 将把原始资料作为job包装到机器学习培训中。

除了运行并行化作业外,可能还需要运行预定作业。Kubernetes公开了CronJobs,它可以在指定的时间点运行一次,也可以在指定的时间点定期运行。Kubernetes中的CronJob对象类似于Unix中crontab(cron表)文件的一行。它以给定的时间表定期运行,以cron格式编写。

Cron作业对于安排定期作业(如数据库备份或发送电子邮件)特别有用。

事件驱动层:无服务器(Serverless)

无服务器计算(Serverless)是指构建和运行不需要服务器管理的应用程序的概念。它描述了一种更细粒度的部署模型,其中捆绑为一个或多个功能的应用程序上传到平台,然后执行,缩容和计费以响应当前所需的确切需求。

函数即服务(FaaS)在无服务器计算的环境中运行,以提供事件驱动的计算。开发人员使用由事件或HTTP请求触发的功能来运行和管理应用程序代码。开发人员将小型代码单元部署到FaaS,这些代码根据实际需要作为独立组件执行,无需管理服务器或任何其他底层基础架构即可进行扩展。

虽然Kubernetes没有集成的事件驱动原语来响应其他服务引发的警报和事件,但仍有努力引入事件驱动的功能。该云原生计算基金会 ,Kubernetes的托管者,一直专注于这些致力于无服务器的工作组。Apache OpenWhisk 、Fission 、Kubeless 、OpenFaaS 和 Oracle的Fn 等开源项目可以在Kubernetes集群中作为事件驱动的无服务器层运行。

在无服务器环境中部署的代码与打包为pod的代码根本不同。它由自治函数组成,可以连接到可能触发代码的一个或多个事件。

当事件驱动计算——无服务器计算成为Kubernetes不可或缺的一部分时,开发人员将能够部署响应Kubernetes控制平面生成的内部事件以及应用程序服务引发的自定义事件的函数。

遗留层:Headless Service

即使您的组织经常使用微服务架构构建和部署应用程序到云上的容器中,也可能有一些应用程序继续存在于Kubernetes之外。云原生应用程序和服务必须与那些传统的单一应用程序进行交互。

遗留层的存在是为了实现互操作性,以暴露一组指向单体应用程序的Headless Service。Headless Service允许开发人员通自由地以自己的方式进行服务发现来减少与Kubernetes系统的耦合。Kubernetes中的Headless Services与ClusterIP、NodePort和LoadBalancer类型的服务不同。它们没有分配给它们的Internet协议(IP)地址,但具有指向外部端点(如API Server、Web服务器和数据库)的域名系统(DNS)条目。遗留层是一个逻辑互操作性层,它将DNS记录维护到众所周知的外部端点。

微服务应用程序的每一层都可以映射到Kubernetes的一个控制器。根据希望部署的模式,DevOps团队可以进行相应的选择。在下一篇文章中,我们将讨论将云原生应用程序部署到Kubernetes的一些*佳实践。

关于作者

Janakiram MSV是Janakiram&Associates的首席分析师,也是国际信息技术学院的兼职教员。他还是Google认证云开发人员,亚马逊认证解决方案架构师,亚马逊认证开发人员,亚马逊认证SysOps管理员和Microsoft认证Azure专业人员。Janakiram是云原生计算基金会的大使,也是*早的认证Kubernetes管理员和认证Kubernetes应用程序开发人员之一。他之前的经历包括Microsoft、AWS、Gigaom Research和Alcatel-Lucent。

一个创业公司的API网关落地实践

HelloFresh是一家食品电商初创公司,用户根据选定的菜谱下单,HelloFresh把菜谱所需要的食材送至用户家中。来自HelloFresh的技术负责人Ítalo Lelis在博客上分享了HelloFresh的API网关落地实践,本文为该博文的译文,并已获得原网站的翻译授权。

HelloFresh的规模一直保持着增长的态势,我们的产品在持续改进,新的想法不断涌现出来,我们拥有完全自动化的供应链。持续的增长给我们带来了惊喜,同时也带来了技术方面的挑战。

在这篇文章里,我将会和大家分享我们的基础设施所经历的一次重大迁移,这次迁移保证了以后的路我们可以走得更快、更灵活,也更安全。

我们*近开发了一个API网关(github.com/hellofresh/janus),所以接下来需要在不停机的情况下对网关后面的主API(单体系统)进行迁移改造。升级之后,我们希望能够开发更多的微服务系统,并且无缝对接到目前我们的基础架构中。

API网关处在基础设施的*外层,它每天需要接收大量的请求,所以我们选择了Go语言来构建网关,因为Golang性能好、简单易用,而且提供了优雅的并发解决方案。我们手头已经有很多现成的工具,它们可以简化我们的迁移工作。

服务发现和客户端负载均衡

我们使用Consul作为服务发现工具,它和HAProxy配合起来使用可以帮我们解决微服务架构的两个主要问题:服务发现(新服务上线时会自动注册)和客户端负载均衡(把请求均衡地分发到各个服务器上)。

自动化

我们的工具箱里*有用的工具或许要数基础设施的自动化。我们使用Ansible在云端管理资源,包括单机、网络、DNS、运行持续集成工具的主机,等等。按照我们的惯例,开发一个新服务时,我们工程师的*件事情就是为这个服务创建Ansible脚本。

日志和监控

从某种程度上说,我们应该监控基础设施里的所有东西。在日志和监控应用方面,我们有一些*佳实践。

  • 办公室里有仪表盘(就是国内公司里的大电视屏,显示系统状态),我们在任何时候都可以查看系统的运行情况。
  • 我们使用ELK技术栈来收集日志,从而可以快速地分析服务的运行情况。
  • 我们使用Statsd和Grafana作为监控工具,这些工具总会给我们带来惊喜。

Grafana的仪表盘为性能度量指标提供了非常完美的视角。

 

理解当前的架构

尽管有了这些工具,我们仍然有一个棘手的问题需要解决:理清当前的架构,然后想清楚如何顺利地进行迁移。我们花了一些时间对遗留系统进行了重构,让它们支持新的网关,同时我们也加入了认证服务。在这个过程中,我们遇到了一些问题。

  • 虽然我们可以对移动应用进行更新,但也要考虑到有些用户可能不愿意升级,所以我们要保持向后兼容,比如DNS,我们要确保旧版本也能正常工作。
  • 我们需要整理出所有公开和私有的API端点,并让它们自动地注册到网关上。
  • 我们需要把认证工作从主API迁移到新的认证服务上。
  • 确保网关和微服务之间通信的安全性。

为了解决这些问题,我们写了一个Go脚本,这个脚本会读取OpenAPI规范(Swagger)文件并为API资源创建规则(比如速率限定、配额、CORS等)代理。

我们在staging环境搭建了整个基础设施,并在上面运行自动化测试,对服务间的通信进行了测试。不得不说,自动化staging测试在整个迁移过程中起到了很大的作用。我们有很多功能测试用例,这些用例保证了主API的功能是完好的。

在确保了staging环境一切正常之后,我们开始考虑如何将它们推到生产环境。

 

*次尝试

可以告诉大家的是,我们的*次尝试简直是灾难性的。尽管我们已经做足了计划,不过仍然不足以把它们推向生产环境。先来看看我们的初始计划。

  • 把*新的API网关部署到staging环境
  • 把主API的变更部署到staging环境
  • 在staging环境运行自动化功能测试
  • 通过网站和移动端进行staging环境的手动测试
  • 把*新的API网关部署到生产环境
  • 把主API的变更部署到生产环境
  • 在生产环境运行自动化功能测试
  • 通过网站和移动端进行生产环境的手动测试
  • 庆祝胜利

在staging环境一切进展得都很顺利,当我们准备进入生产环境时,问题出现了。

  • 认证服务的数据库过载:我们低估了请求的流量,造成数据库拒*连接
  • 错误的CORS配置:部分端点的CORS规则配置错误,造成请求无法获得资源

数据库被冲垮,我们不得不马上回滚。幸运的是,我们的监控系统捕获到了从认证服务获取令牌的问题。

第二次尝试

从*次失败中吸取了教训,我们知道我们还没有为进入生产环境做好准备,于是在回滚之后,立即对问题展开诊断。在再次尝试之前,我们做了一些改进。

  • 准备蓝绿(blue-green)部署过程。我们为生产环境创建了一个副本,包括已经部署好的网关,通过一些简单的配置变更就能让整个集群运行起来,如果需要回滚,也只需做一些简单的配置变更。
  • 从当前的系统收集更多的度量指标,这样可以帮助我们决定该使用多少机器来处理负载。我们利用*次尝试时所使用的数据作为探针,并使用Gatling来运行负载测试,确保我们可以应付预期的流量。
  • 再次进入生产环境之前,我们对认证服务的已知问题进行了修复,包括一个大小写问题、一个JWT签名的性能问题,并添加了更多的日志和监控。

我们花费了一个*拜来完成上述的工作,之后的部署进展得很顺利,中间没有停机。不过尽管部署进展得很顺利,我们仍然发现了一些在自动化测试中没有发现的个别问题,不过这些问题*终得到修复,并没有对系统造成太大影响。

*终结果

*终的架构如下图所示。

 

主API

  • 10多个主API部署在装配了高端CPU的主机上
  • 主从MySQL(3个副本)
  • 认证服务

4个应用服务器

  • 主从PostgreSQL(2个副本)
  • RabbitMQ用于异步地处理用户的更新操作
  • API网关

4个应用服务器

  • 主从MongoDB(4个副本)

其它

  • 使用Ansible批量管理远程服务器
  • 使用Amazon CloudFront作为CDN/WAF
  • 使用Consul和HAProxy作为服务发现和客户端负载均衡工具
  • 使用Stasd和Grafana收集系统度量指标并触发告警
  • 使用ELK技术栈从不同的服务收集日志
  • 使用Concourse CI作为持续集成工具

 

云原生技术_云原生技术如何克服云锁定

云原生技术

Murli Thirumale是Portworx的联合创始人兼首席执行官。

云原生计算是关于如何构建应用程序的, 而不是关于在何处构建它们的 。 这意味着全球企业可以在自己的数据中心以及公共云中运行云原生应用程序。 Kubernetes是该模型的关键基础技术之一,这说明了它在过去几年中的迅猛发展。

Kubernetes通过自动化低价值的操作任务,使全球IT团队可以更快地构建和运行应用程序,以便团队可以专注于增加业务价值。 Kubernetes核心增值的一部分是其可在任何地方(即,在任何数据中心或任何云中)运行的灵活性。

我*近读了一篇文章,描述了采用云原生IT策略危险 。 该文章主张“云原生意味着锁定”,并断言“您全都与特定的公共云提供商(这些云原生服务的单一提供商)保持联系,目标是从您的云计算中获得*大收益。投资。” 这与我与正在部署云原生技术的大型企业合作的经验不符,这些企业通常是开源技术(例如Kubernetes)。 实际上,我相信采用云原生实践是避免供应商锁定的唯一*佳方法。

这可能只是定义上的失调而不是结构上的分歧。 云原生计算基金会将云原生定义为“使组织能够在现代,动态环境(例如公共云,私有云和混合云)中构建和运行可扩展应用程序的技术”。 (另请参阅CNCF常见问题解答 。)构建可跨多个云环境部署的应用程序的能力是云原生主张的核心。 在设计可在任何环境中运行的应用程序时,您可以保护自己免受可能使用锁定提高价格和减少服务的供应商的侵害。

诸如在Kubernetes上运行的云原生应用程序很容易在多种环境中运行,原因有以下几个:

  • 云原生应用程序打包在Linux容器中,与其他打包技术(例如虚拟机)相比,它无需修改即可在多个环境中更轻松地运行。
  • 所有主要的云提供商都提供了Kubernetes服务,该服务使Kubernetes打包的应用程序几乎无需修改即可移动,从而为企业提供了在云之间轻松进行迁移的路径。
  • 由于社区在Kubernetes的开放存储接口方面的进步,现在可以直接在Kubernetes上运行数据服务,从而使数据像容器本身一样可移植,从而消除了重要的锁定来源。

*近来自客户拜访的轶事说明了这一点。 我正在与一家在公共云上进行大量投资的全球银行的IT员工的高级成员会面。 尽管公司的大部分工作负载都在单个云上运行,但该公司*近支付了300美元的开发人员在竞争的云上进行认证的费用,并且正大力投资以在Kubernetes上运行其应用程序-正是因为这些应用程序随后将能够跨多云。 她告诉我:“这就像是核缓速器。” “如果他们知道我们可以离开,他们将是更好的合作伙伴,如果我们留下,我们将获得更好的价格和服务。”

该银行正在以一种头脑平和,平衡的方式来实践云原生。 该公司了解公共云的价值,但它正在构建其应用程序,以便可以根据需要将其移动到其他云提供商。

我认为业内一些人将“原生云”等同于“特定于云的服务”,例如无服务器技术和托管数据服务。 我同意采用无服务器和托管数据服务会导致锁定。 被锁定为专有服务和数据格式将阻止应用程序在云之间轻松移动。 但是就企业使用Kubernetes等云原生技术来简化迁移的程度而言,我认为云原生是克服云锁定的*佳方法,而不是原因。

Murli Thirumale是Portworx的联合创始人兼首席执行官, PortworxKubernetes的云原生存储和数据管理解决方案提供商。

浅析云计算的六种架构

云计算要求基础设施具有良好的弹性、扩展性、自动化、数据移动、多租户、空间效率和对虚拟化的支持。那么,云计算环境下的数据中心基础设施各部分的架构应该是什么样的呢?

AD:

云计算要求基础设施具有良好的弹性、扩展性、自动化、数据移动、多租户、空间效率和对虚拟化的支持。那么,云计算环境下的数据中心基础设施各部分的架构应该是什么样的呢?

1、云计算数据中心总体架构

云计算架构分为服务和管理两大部分。在服务方面,主要以提供用户基于云的各种服务为主,共包含3个层次:基础设施即服务IaaS、平台即服务PaaS、软件即服务SaaS.在管理方面,主要以云的管理层为主,它的功能是确保整个云计算中心能够安全、稳定地运行,并且能够被有效管理。

2、云计算机房架构 

为满足云计算服务弹性的需要,云计算机房采用标准化、模块化的机房设计架构。模块化机房包括集装箱模块化机房和楼宇模块化机房。

集装箱模块化机房在室外无机房场景下应用,减轻了建设方在机房选址方面的压力,帮助建设方将原来半年的建设周期缩短到两个月,而能耗仅为传统机房的50%,可适应沙漠炎热干旱地区和*地严寒地区的*端恶劣环境。楼宇模块化机房采用冷热风道隔离、精确送风、室外冷源等*制冷技术,可适用于大中型数据中心的积木化建设和扩展。

3、云计算网络系统架构

网络系统总体结构规划应坚持区域化、层次化、模块化的设计理念,使网络层次更加清楚、功能更加明确。数据中心网络根据业务性质或网络设备的作用进行区域划分,可从以下几方面的内容进行规划。

1)按照传送数据业务性质和面向用户的不同,网络系统可以划分为内部核心网、远程业务专网、公众服务网等区域。

2)按照网络结构中设备作用的不同,网络系统可以划分为核心层、汇聚层、接入层。

3)从网络服务的数据应用业务的独立性、各业务的互访关系及业务的安全隔离需求综合考虑,网络系统在逻辑上可以划分为存储区、应用业务区、前置区、系统管理区、托管区、外联网络接入区、内部网络接入区等。

此外,还有一种Fabric的网络架构。在数据中心部署云计算之后,传统的网络结构有可能使网络延时问题成为一大瓶颈,这就使得低延迟的服务器间通信和更高的双向带宽需要变得更加迫切。这就需要网络架构向扁平化方向发展,*终的目标是在任意两点之间尽量减少网络架构的数目。

Fabric网络结构的关键之一就是消除网络层级的概念,Fabric网络架构可以利用阵列技术来扁平化网络,可以将传统的三层结构压缩为二层,并*终转变为一层,通过实现任意点之间的连接来消除复杂性和网络延迟。不过,Fabric这个新技术目前仍未有统一的标准,其推广应用还有待更多的实践。

4、云计算主机系统架构

云计算核心是计算力的集中和规模性突破,云计算中心对外提供的计算类型决定了云计算中心的硬件基础架构。从云端客户需求看,云计算中心通常需要规模化的提供以下几种类型的计算力,其服务器系统可采用三(多)层架构,一是高性能的、稳定可靠的高端计算,主要处理紧耦合计算任务,这类计算不仅包括对外的数据库、商务智能数据挖掘等关键服务,也包括自身账户、计费等核心系统,通常由企业级大型服务器提供;二是面向众多普通应用的通用型计算,用于提供低成本计算解决方案,这种计算对硬件要求较低,一般采用高密度、低成本的超密度集成服务器,以有效降低数据中心的运营成本和终端用户的使用成本;三是面向科学计算、生物工程等业务,提供百万亿、千万亿次计算能力的高性能计算,其硬件基础是高性能集群。

5、云计算存储系统架构 

云计算采用数据统一集中存储的模式,在云计算平台中,数据如何放置是一个非常重要的问题,在实际使用的过程中,需要将数据分配到多个节点的多个磁盘当中。而能够达到这一目的的存储技术趋势当前有两种方式,一种是使用类似于GoogleFileSystem的集群文件系统,另外一种是基于块设备的存储区域网络SAN系统。

GFS是由Google公司设计并实现的一种分布式文件系统,基于大量安装有Linux操作系统的普通PC构成的集群系统,整个集群系统由一台Master和若干台ChunkServer构成。在SAN连接方式上,可以有多种选择。一种选择是使用光纤网络,能够操作快速的光纤磁盘,适合于对性能与可靠性要求比较高的场所。另外一种选择是使用以太网,采取iSCSI协议,能够运行在普通的局域网环境下,从而降低成本。采用SAN结构,服务器到共享存储设备的大量数据传输是通过SAN网络进行的,局域网只承担各服务器之间的通信任务,这种分工使得存储设备、服务器和局域网资源得到更有效的利用,使存储系统的速度更快,扩展性和可靠性更好。

6、云计算应用平台架构

云计算应用平台采用面向服务架构SOA的方式,应用平台为部署和运行应用系统提供所需的基础设施资源应用基础设施,所以应用开发人员无需关心应用的底层硬件和应用基础设施,并且可以根据应用需求动态扩展应用系统需的资源。

“多云”不等于“混合云”

现如今,云计算可谓风靡一时,但是,你是否真正了解云?你对云的认知是否还停留在使用公有云和私有云上呢?

其实在真实的应用场景里,一种云很难用于多种情形,每个企业和行业的需求及目标各不相同,也没有固定的规律,所以真正意义上能够吃遍天下且持久有效的“一招鲜”根本就不存在,同样,也没有某种所谓的“万能”云战略;甚至在企业内部,他们也无法使用不变的云战略来支持每一种工作负载。

因此,“混合云” (Hybrid Cloud)和“多云”(Multi-Cloud)战略就应运而生了。企业在把原有的IT工作负载迁移到云之前,需要基于它们的特点和需求来为它们选出适合栖身的云平台。

选择多云还是混合云?先把概念弄清楚吧

有些人会把多云和混合云两个词互相替换使用,但它们其实有着明确的含义,两者互有利弊,且不能互相取代。

什么是多云

根据维基百科:

“多云是在单一异构结构中使用多个云计算服务。

即,多云是指使用超过一个公有云。当企业试图避免对单个公有云提供商的依赖时,当他们选择每个公有云的特定服务以获得*佳效果时,或者同时想要这两种好处的时候,这种模式就出现了。

多云在本质上是在单个传输层中使用多个云服务,一个常见的例子是使用多个公有云服务提供商的服务。

企业采用多云模式通常有以下三个原因:

1. 业务杠杆(Leverage)

企业IT组织通常是规避风险的,经常在风险和决策中进行抉择,其中就包括向云计算的迁移以及云服务提供商的选择,还担心被单个云服务提供商锁定。通过多云的方式,企业可以跨多个云服务提供商来对冲风险。这种方式的不利之处在于,需要对多个云服务加以整合,提高了组织技能和数据传输的复杂性。

2. *佳方案

企业通常采用多云战略的第二个原因是对*佳解决方案的需求,单一交付层并不是所有解决方案都提供相同的服务。企业可以选择使用一个云服务提供商的解决方案来实现特定功能,选择另一个云服务提供商的解决方案实现不同的功能。这种方法虽然在某些方面提供优秀的功能,但在其他方面带来了复杂性,包括功能整合、数据传输、组织技能和扩展。

3. 评估

企业采用多云战略的第三个原因是暂时的,是对业务进行评估。第三种方法是企业当中非常普遍的方法,本质上,它提供了一种首次开始时评估单一交付层中的不同云服务提供商的方法。然而,他们*终专注于单一提供商,并围绕单一提供商的解决方案建立专业知识。

*终我们发现企业选择上述三种方法之一的原因通常是通过其成熟度和对云的思考来加以选择,作出选择所要考虑的是业务杠杆等带来的优势能不能超过复杂性等缺陷。

什么是混合云

根据维基百科:

混合云是两个或多个云(私有云、社区云或公有云)的组合,它们仍然是不同的实体,但绑定在一起,提供多种部署模式的好处。混合云还可以指将配置、托管和/或专用服务连接到云资源的能力。

Gartner将混合云服务定义为一种由不同服务提供商提供的私有云、公有云和社区云服务组合而成的云计算服务。混合云服务跨越隔离和提供商界限,因此不能简单地将其放入私有、公有或社区云服务的类别中。它通过与另一个云服务进行聚合、集成或定制,使企业扩展其云服务的容量或功能。

云计算通常是一个向外扩展的商品服务器群集,可提供服务(计算,存储或两者兼有),其中工作负载或数据可以透明在节点之间或跨节点移动。混合云背后的理念是,组织的工作负载和数据可以在私有云和公有云提供商(包括多个提供商)之间透明地移动。

混合云允许组织在每个工作负载的基础上选择*有意义的位置。例如,组织可以决定在本地保留工作负载,因为它仅由内部用户使用,并且延迟或安全性也是一个令人关注的问题。这些也可能是更加传统的规模化工作负载,无法从横向扩展的计算服务中充分获益。

组织可能具有其他工作负载,这些工作负载仅在云端中经常从外部访问,或者是针对横向扩展计算服务而设计的。如果这些工作负载有时间上必须执行大规模处理(如视频呈现或分析处理),组织有能力提供这种工作负载,数以千计的处理器可以彻底改变数据的处理过程,将大大减少获得结果的时间。

大多数企业今天使用的都是混合云模式,混合云指云计算在多个不同的传输层中的垂直使用。通常情况下,企业使用的是基于SaaS的解决方案和公有云,有的企业还可能使用私有云。混合云不需要应用程序跨不同的传输层传输。

混合云不等于多云

混合云和多云之间的差异主要是在用户定位上,一个垂直地处理不同的连续服务,另一个侧重于水平方面的云服务。

 

简单地来说,多云就类似于Uber这类的打车软件——把不同的云上面加了抽取层,但是,混合云则完全不同,混合云完全是在用户看不见的情况之下发生的自然而然的资源共享。

借用两个例子来说明:

*,乘坐飞机,如果你希望找到*便宜的机票,可以先登陆各大航空公司的官网,逐一寻找;你还可以登陆携程这样的第三方应用,它会提供所有航空公司的票价——这就是通过一个价格API,从不同的航空公司的系统抽取过来——这是类似于多云的使用。

第二,iCloud可以共享相册是混合云的一个*好的例子,它的过程完全是无形,用户完全不必知道这一过程所发生的事。真正的混合云完全消除了私有云和公有云之间的界限。所有的能力都通过抽取的方式,通过应用,通过服务的方式来提供给用户,用户无需知道它在哪发生。

对企业来说,需要了解的是利用多云或者混合云的方式。大多数人都走入了术语的误区,而不是去考虑利用这些解决方案能够带来的好处。

多云和混合云是两种截然不同的云计算的采用方式,两种模式各有利弊,多云和混合云都能够推动业务转型,企业应该积*利用这两者的优势。

【总结】2020年*新算法工程师技术路线图

这是一份写给公司算法组同事们的技术路线图,其目的主要是为大家在技术路线的成长方面提供一些方向指引,配套一些自我考核项,可以带着实践进行学习,加深理解和掌握。

%title插图%num

工程师能力层级概览

对于不同级别的算法工程师技能要求,我们大致可以分成以下几个层级:

  • 初级:可以在一些指导和协助下独立完成开发任务。具体到算法方面,需要你对于工具框架,建模技术,业务特性等方面有一定的了解,可以独立实现一些算法项目上的需求。
  • 中级:可以基本独立完成一个项目的开发与交付。在初级工程师的基础上,对于深入了解技术原理的要求会更高,并且能够应对项目中各种复杂多变的挑战,对于已有技术和工具进行改造适配。在整体工程化交付方面,对于代码质量,架构设计,甚至项目管理方面的要求会开始显现。另外从业务出发来评估技术选型和方案也变得尤为重要。
  • 高级:可以独立负责一条产品线的运作。在中级工程师的基础上,需要更广阔的技术视野与开拓创新能力,定义整个产品线的前进方向。解决问题已经不是关键,更重要的是提出和定义问题,能够打造出在业界具有*性和差异性的产品,为公司创造更大的价值。

事实上对于不同层级的工程师,非技术部分的要求都有一定占比。本文主要聚焦在技术路线图上,对于其他方面的学习进阶路线不会做覆盖。

阅读建议

以下内容分工程基础,算法基础,算法工程交叉,工程深入方向,算法深入方向几个部分,在各个部分内部会进一步区分一些主题。在各个主题内部,也是有深入程度的区别的,不过限于篇幅没有进行详细的说明。建议学习路线可以先把两个基础部分与工作中较为相关的内容做一个整体基础的夯实,然后可以在后续交叉和深入方向的主题中选择感兴趣的进行深入了解和学习,过程中发现基础部分欠缺的,可以再回到基础部分查漏补缺,迭代前行。

工程基础

编程语言

Python

Python 是算法工程师日常工作中*常用的语言,应该作为必须掌握的一门技术。大致的学习路线如下:

  • 学习掌握 Python 的基本语法,可以通过各类入门教程来看,个人推荐《Learn Python the Hard Way》。
  • 自我考核:能够读懂大多数的内部项目及一些开源项目代码的基本模块,例如 pandas, sklearn 等。
  • 学习 Python 的编程风格,建议学习观远内部的 Python 代码规范。
  • 自我考核:编写的代码符合编码规范,能够通过各类 lint 检查。
  • Python 进阶,这方面有一本非常著名的书《Fluent Python》,深入介绍了 Python 内部的很多工作原理,读完之后对于各类疑难问题的理解排查,以及语言高级特性的应用方面会很有帮助。另外动态语言元编程这块,《Ruby 元编程》也是一本非常值得推荐的书。
  • 自我考核:能够读懂一些复杂的 Python 项目,例如 sqlalchemy 中就大量使用了元编程技巧。在实际工程项目中,能够找到一些应用高级技巧的点进行实践,例如基于 Cython 的性能优化等。
  • 领域应用,Python 的应用相当广泛,在各个领域深入下去都有很多可以学习的内容,比如 Web 开发,爬虫,运维工具,数据处理,机器学习等。这块主要就看大家各自的兴趣来做自由选择了,个人推荐熟悉了解一下 Python web 开发,测试开发相关的内容,开拓视野。
  • 自我考核:以 Web 开发和测试开发为例,尝试写一个简单的 model serving http 服务,并编写相应的自动化测试。

Scala/Java

Java 目前是企业级开发中*常用的软件,包括在大数据领域,也是应用*广泛的语言,例如当年的 Hadoop 生态基本都是基于 Java 开发的。Scala 由于其函数式编程的特性,在做数据处理方面提供了非常方便的 API,也因为 Spark 等项目的火热,形成了一定的流行度。在进行企业级的软件开发,高性能,大规模数据处理等方面,JVM 上的这两门语言有很大的实用价值,值得学习。

顺带一提,Scala 本身是一门非常有意思的语言,其中函数式编程的思想与设计模式又是非常大的一块内容,对于拓宽视野,陶冶情操都是挺不错的选择。

考虑到算法工程师的工作内容属性,这边给出一个 Scala 的学习路线:

  • 学习掌握 Scala 的基本语法,开发环境配置,项目编译运行等基础知识。这里推荐 Coursera 上 Martin Odersky 的课程,《快学 Scala》或《Programming in Scala》两本书也可以搭配着浏览参考。
  • 自我考核:能使用 Scala 来实现一些简单算法问题,例如 DFS/BFS。或者使用 Scala 来处理一些日常数据工作,例如读取日志文件,提取一些关键信息等。
  • 学习使用 Scala 来开发 Spark 应用,推荐 edX 上的《Big Data Analytics Using Spark》或者 Coursera 上的《Big Data Analytics with Scala and Spark》,另外有些相关书籍也可以参考,比如《Spark 快速大数据分析》等。
  • 自我考核:能够使用 Spark 的 Scala API 来进行大规模的数据分析及处理,完成 lag feature 之类的特征工程处理。
  • JVM 的原理学习,Scala/Java 都是 JVM 上运行的优秀语言,其背后是一个非常大的生态,包括在 Web,Android,数据基础架构等方面有广泛的应用。JVM 相比 Python 虚拟机,发展更加成熟,有一套非常完善的 JDK 工具链及衍生的各类项目,便于开发者 debug,调优应用。这方面推荐学习周志明的《深入理解 Java 虚拟机》。
  • 自我考核:理解 JVM GC 原理,能通过 JDK 中相关工具或者优秀的第三方工具如 arthas 等,排查分析 Spark 数据应用的资源使用情况,GC profiling,hot method profiling 等,进而进行参数优化。
  • 计算机语言理论。Programming Language 作为计算机科学的一个重要分支,包含了很多值得深入研究的主题,例如类型论,程序分析,泛型,元编程,DSL,编译原理等。这方面的很多话题,在机器学习方面也有很多实际应用,比如 TVM 这类工作,涉及到大量编译原理的应用,知乎大佬 “蓝色” 也作为这个领域的专家在从事深度学习框架相关的工作。llvm, clang 作者 Chris Lattner 也加入 Google 主导了 Swift for Tensorflow 等工作。Scala 作为一门学术范非常强的语言,拥有*佳的 FP,元编程等能力支持,强大的类型系统包括自动推理,泛型等等高级语言特性,相对来说是一门非常 “值得” 学习的新语言,也是一个进入 PL 领域深入学习的 “gateway drug” 🙂 对这个方面有兴趣的同学,可以考虑阅读《Scala 函数式编程》,《冒号课堂》,以及 Coursera 上《Programming Languages》也是一门非常好的课程。另外只想做科普级了解的同学,也可以读一读著名的《黑客与画家》感受一下。

C/C++/Rust

当前流行的算法框架,例如 TensorFlow, PyTorch, LightGBM 等,底层都是基于 C++ 为主要语言进行实现的。但是 C++ 本身过于复杂,使用场景也比较有限制,建议只需要达到能够读懂一些基础的 C++ 代码逻辑即可。在系统级开发领域,目前有一门新语言逐渐崛起,连续几年被 StackOverflow 投票评选为程序员*喜爱的语言:Rust。从设计理念和一些业界应用(例如 TiKV)来看还是非常不错的,但是我也没有深入学习了解过,就不做具体推荐了。这方面建议的学习内容包括经典的《The C Programming Language》以及 Rust 官方的:https://github.com/rust-lang/rustlings

  • 自我考核:能够读懂 LightGBM 里对于 tweedie loss 的相关定义代码。

操作系统

基本概念

我们所编写的算法应用,都是通过操作系统的环境运行在物理硬件之上的。在实际运作过程中,会碰到不少相关的问题,例如为什么程序报了资源不足的错误,为什么 notebook 在浏览器里打不开,为什么进程 hang 住了没有响应等等,都需要一些操作系统的知识来帮助理解和分析问题,*终排查解决。操作系统涵盖的内容比较多,建议一开始只需要了解一些主要概念(例如硬件结构,CPU 调度,进程,线程,内存管理,文件系统,IO,网络等),对于整体图景有一些感觉即可。后续碰到了实际问题,可以再在各个部分深入学习展开。优秀的学习资料也有很多,基本都是大部头,重点推荐《深入理解计算机系统》,《Operating Systems: Three Easy Pieces》,以及《现代操作系统》。

  • 自我考核:能够基本明确运行一个模型训练任务过程中,底层使用到的硬件,操作系统组件,及其交互运作的方式是如何的。

Linux 基础

平时工作中*常用的两个操作系统 CentOS 和 macOS,都是 Unix/Linux 系的,因此学习掌握相关的基础知识非常重要。一些必须掌握的知识点包括:Shell 与命令行工具,软件包管理,用户及权限,系统进程管理,文件系统基础等。这方面的入门学习资料推荐《鸟哥的 Linux 私房菜》,基本涵盖了 Linux 系统管理员需要掌握知识的方方面面。进阶可以阅读《Unix 环境高级编程》,对于各种系统调用的讲解非常深入,可以为后续性能调优等高级应用打下基础。

  • 自我考核:开发一个 shell 小工具,实现一些日常工作需求,例如定时自动清理数据文件夹中超过一定年龄的数据文件,自动清理内存占用较大且运行时间较久的 jupyter notebook 进程等。

深入应用

工作中碰到的疑难问题排查,性能分析与优化,系统运维及稳定性工程等方面,都需要较为深入的计算机体系和操作系统知识,感兴趣的同学可以针对性的进行深入学习。以性能优化为例,可以学习经典的《性能之巅》,了解其中的原理及高级工具链。像其中的系统调用追踪 (strace),动态追踪(systemtap, DTrace, perf, eBPF) 等技术,对于操作系统相关的问题排查都会很有帮助。

  • 自我考核:能够分析定位出 LightGBM 训练过程中的性能瓶颈,精确到函数调用甚至代码行号的级别。

软件工程

算法与数据结构

暂时先把这块放到软件工程模块下。这里指的算法是计算机科学中的经典算法,例如递归,排序,搜索,动态规划等,有别于我们常说的机器学习算法。这块的学习资料网上有非常多,个人当年是通过普林斯顿的算法课 (需要有 Java 基础) 入门,后来又上了斯坦福的算法分析与设计,开拓了一些视野。书籍方面推荐新手从《算法图解》入门,然后可以考虑阅读 Jeff Erickson 的《Algorithms》,或者选择上面提到的网课。另外像《编程珠玑》,《编程之美》等也可以参阅,里面有不少问题的巧妙解法。除了从书本中学习,还可以直接去 LeetCode 等网站进行实战操作进行练习提高。

  • 自我考核:能够设计相关的数据结构,实现一个类似 airflow 中点击任意节点向后运行的功能。

代码规范

从初级程序员到中高级程序员,其中比较大的一个差异就是代码编写习惯上,从一开始写计算机能理解,能够运行成功的代码,逐渐演化到写人能够理解,易于修改与维护的代码。在这条学习路径上,首先需要建立起这方面的意识,然后需要在实战中反复思考和打磨自己的代码,评判和学习其它优秀的项目代码,才能逐渐精进。推荐的学习书籍有《编写可读代码的艺术》,一本非常短小精悍的入门书籍,后续可以再慢慢阅读那些经典大部头,例如《Clean Code》,《Code Complete》,《The Pragmatic Programmer》等。这方面 Python 也有一本比较针对性的书籍《Effective Python》,值得一读。

  • 自我考核:审视自己写的项目代码,能发现并修正至少三处不符合*佳编码实践的问题。

设计模式

在代码架构方面,设计模式是一个重要的话题,对于日常工作中出现的许多典型场景,给出了一些解决方案的“套路”。这方面*著名的书当属 GoF 的《设计模式》,不过个人并不十分推荐,尤其是以 Python 作为主要工作语言的话,其中很大部分的设计模式可能并不需要。入门可以浏览一下这个网站掌握一些基本概念:https://refactoringguru.cn/design-patterns/python ,后续可以考虑阅读《Clean Architecture》,《重构》等相关数据,理解掌握在优化代码架构过程中思考的核心点,并加以运用。Python 相关的设计模式应用,还可以参考《Python in Practice》。

  • 自我考核:在项目中,找到一处可以应用设计模式的地方,进行重构改进。

质量保障

对于需要实际上线运行的软件工程,质量保障是非常重要的一个环节,能够确保整个产品按照期望的方式进行运作。在机器学习项目中,由于引入了数据这个因素,相比传统的软件测试会有更高的难度,也是业界还在摸索前进的方向。建议可以先阅读《单元测试的艺术》或《Google 软件测试之道》,大致理解软件测试的一些基本概念和运作方式,在此基础上可以进一步阅读 Martin Fowler 对于机器学习领域提出的 CD4ML 中相关的测试环节,学习 sklearn,LightGBM 等开源库的测试开发方式,掌握机器学习相关的质量保障技术能力。

  • 自我考核:在项目中,实现基础的数据输入测试,预测输出测试。

项目管理

软件工程推进过程中,项目管理相关的技能方法与工具运用也非常的关键。其中各种研发流程与规范,例如敏捷开发,设计评审,代码评审,版本管控,任务看板管理等,都是实际项目推进中非常重要的知识技能点。这方面推荐学习一本经典的软件工程教材《构建之法》,了解软件项目管理的方方面面。进一步来说广义的项目管理上的很多知识点也是后续深入学习的方向,可以参考*客时间上的课程《项目管理实战 20 讲》。

  • 自我考核:在某个负责项目中运用项目管理方法,完成一个实际的需求评估,项目规划,设计与评审,开发执行,项目上线,监控维护流程,并对整个过程做复盘总结。

高级话题

软件工程师在技能方向成长的一条路线就是成为软件架构师,在这个方向上对于技能点会有非常高的综合性要求,其中也有不少高级话题需要深入学习和了解,例如技术选型与系统架构设计,架构设计原则与模式,宽广的研发知识视野,高性能,高可用,可扩展性,安全性等等。有兴趣的同学可以了解一下*客时间的《从 0 开始学架构》这门课,逐渐培养这方面的视野与能力。另外如《微服务架构设计模式》还有领域驱动设计方面的一系列书籍也值得参考学习。

  • 自我考核:设计一个算法项目 Docker 镜像自动打包系统。

算法基础

数据分析

数学基础

在进行算法建模时,深入了解数据情况,做各类探索性分析,统计建模等工作非常重要,这方面对一些数学基础知识有一定的要求,例如概率论,统计学等。这方面除了经典的数学教材,也可以参考更程序员向的《统计思维》,《贝叶斯方法》,《程序员的数学 2》等书籍。

  • 自我考核:理解实际项目中的数据分布情况,并使用统计建模手段,推断预测值的置信区间。

可视化

在进行数据分析时,可视化是一个非常重要的手段,有助于我们快速理解数据情况,发掘数据规律,并排查异常点。对于各种不同类型的数据,会对应不同的可视化*佳实践,如选择不同的图表类型,板式设计,分析思路编排,人机交互方式等等。另一方面,可视化与数据报告也是我们与不同角色人群沟通数据 insights 的一个重要途径,需要从业务角度出发去思考可视化与沟通方式。这方面可以参考《Storytelling with Data》,《The Visual Display of Quantitative Information》等经典数据,同时也需要培养自己的商业背景 sense,提升沟通能力。

  • 自我考核:对内沟通方面,能使用可视化技术,分析模型的 bad case 情况,并确定优化改进方向。对外沟通方面,能独立完成项目的数据分析沟通报告。

误差分析与调优

在做算法模型调优改进中,需要从数据分析的基础上出发来决定实验方向,这么做有几个好处:

  • 从分析出发指导调优更有方向性,而不是凭经验加个特征,改个参数碰运气。哪怕是业务方提供的信息,也*好是有数据分析为前提再做尝试,而不是当成一个既定事实。
  • 由分析发现的根源问题,对于结果验证也更有帮助。尤其在预测的数据量*大情况下,加一个单一特征很可能总体只有千分位准确率的提升,无法确定是天然波动还是真实的提升。但如果有分析的前提,那么我们可以有针对性的看对于这个已知问题,我们的调优策略是否生效,而不是只看一个总体准确率。
  • 对于问题的彻底排查解决也更有帮助,有时候结果没有提升,不一定是特征没用,也可能是特征代码有 bug 之类的问题。带着数据分析的目标去看为什么这个特征没有效果,是模型没学到还是特征没有区分度等,有没有改进方案,对于我们评判调优尝试是否成功的原因也更能彻查到底。
  • 数据分析会帮助我们发现一些额外的问题点,比如销量数据清洗处理是不是有问题,是不是业务本身有异常,需要剔除数据等。

这方面在业界有一些关于误差分析的探索研究,不过大多数都是基于分类问题的,例如《Identifying Unknown Unknowns in the Open World》,《A Characterization of Prediction Errors》等。可以在了解这些研究的基础上,结合具体的业务情况,深入思考总结误差分析的思路与方法论。

  • 自我考核:在项目中形成一套可以重复使用的误差分析方案,能够快速从预测输出中定位到目前模型*重要的误差类别,并一定程度上寻找到根本原因。

机器学习基础

传统机器学习

这块大家应该都非常熟悉了,初阶的学习路线可以参考周志华老师的《机器学习》,涵盖了机器学习基础,常用机器学习方法,和一些进阶话题如学习理论,强化学习等。如果希望深化理论基础,可以参考经典的《PRML》,《ESL》和《统计学习方法》。在实战中,需要综合业务知识,算法原理,及数据分析等手段,逐渐积累形成建模调优的方法论,提高整体实验迭代的效率和成功率。

  • 自我考核:结合实际业务和机器学习理论知识,挖掘项目中算法表现不够好的问题,并通过算法改造进行提升或解决。

深度学习

近些年兴起的深度学习,已经成为机器学习领域一个非常重要的分支,在各个应用方向发挥了很大的作用。相对于传统机器学习,对于特征工程要求的降低成了其核心优势。另一方面,深度学习对于大数据量,大规模算力的应用能力很强,也一定程度上提升了整体的产出效果。由于理论方面的研究稍显落后,深度学习在实际应用中对于使用者的经验技能要求相对比较高,需要有大量的实战经验才能达到比较理想的效果。这方面的学习资料推荐 Keras 作者的《Deep Learning with Python》,以及《Hands-on Machine Learning with Scikit-Learn and TensorFlow》,而在理论方面推荐著名的“花书”《Deep Learning》。在学习理论原理的基础上,尤其要注意在实际算法应用中,能够通过观察各种指标与数据分析,找到提升模型的操作改进方向。

  • 自我考核:能够在实际项目中,使用深度学习模型,达到接近甚至超过传统 GBDT 模型的精确度效果,或者通过 ensemble,embedding 特征方式,提升已有模型的精度。

领域建模

目前我们的业务领域在时间序列预测,自然语言处理,推荐等方面,其它类似图像,搜索,广告等领域也都有各自的一些领域建模方法。在时间序列领域,包括了传统时序模型,如 ARIMA, Prophet,机器学习模型,如划动窗口特征构建方法结合 LightGBM,及深度学习模型,例如 LSTM,seq2seq,transformer 等。这方面可以参考 Kaggle 上相关比赛的方案分享,以及 Amazon,Uber,天猫等有类似业务场景公司的分享资料。其它领域也是类似,通过了解历史技术演进,相关比赛,业界的方案分享与开源项目,会议论文来逐渐掌握学习建模方法,结合实际业务进行实践尝试,积累起更加体系性的个人知识技能。

  • 自我考核:在项目中复现一个 Kaggle 获胜方案,检验其效果,分析模型表现背后的原因,并尝试进行改进。

算法框架

数据处理框架

在项目实施过程中,会需要各类复杂的数据处理操作,因此熟练掌握此类框架就显得尤为重要。目前行业的标准基本上会参照 Pandas DataFrame 的定义,在数据量较大的情况下,也有许多类似的框架,如 Spark,Dask,Modin,Mars 等支持分布式运行的 DataFrame,以及 cuDF,Vaex 等提升单机性能的改进实现。这方面经典的书籍可以参考 Wes McKinney 的《Python for Data Analysis》,在掌握基础数据操作的基础上,可以进而了解窗口函数,向量化性能优化等高级话题。另外 SQL 也可以做非常复杂的数据处理工作,有不少公司例如阿里会以 SQL 为主来构建数据处理流程,感兴趣的同学也可以学习一下 SQL 中各种高级计算的使用及优化方法。

  • 自我考核:在已有项目中,能把至少三个使用 apply 方法的 pandas 处理修改成向量化运行,并测试性能提升。使用 window function 或其它方案来实现 lag 特征,减少 join 次数。

机器学习框架

机器学习方面的新框架层出不穷,一方面我们需要掌握经典框架的使用方式,理解其模块构成,接口规范的设计,一定程度上来说其它新框架也都需要遵循这些业界标准框架的模块与接口定义。另一方面对于新框架或特定领域框架,我们需要掌握快速评估,上手使用,并且做一定改造适配的能力。一些比较经典的框架有:

  • 通用机器学习:scikit-learn,Spark ML,LightGBM
  • 通用深度学习:Keras/TensorFlow,PyTorch
  • 特征工程:tsfresh, Featuretools,Feast
  • AutoML:hyperopt,SMAC3,nni,autogluon
  • 可解释机器学习:shap,aix360,eli5,interpret
  • 异常检测:pyod,egads
  • 可视化:pyecharts,seaborn
  • 数据质量:cerberus,pandas_profiling,Deequ
  • 时间序列:fbprophet,sktime,pyts
  • 大规模机器学习:Horovod,BigDL,mmlspark
  • Pipeline:MLflow, metaflow,KubeFlow,Hopsworks

一般的学习路径主要是阅读这些框架的官方文档和 tutorial,在自己的项目中进行尝试使用。对于一些核心接口,也可以阅读一下相关的源代码,深入理解其背后的原理。

  • 自我考核:在 LightGBM 框架下,实现一个自定义的损失函数,并跑通训练与预测流程。

其它框架

其它比较常见且与算法工程师日常工作会有一些联系的有 Web 框架,爬虫框架等,*具有代表性的当属 Flask 和 scrapy。这两者背后各自又是很大一块领域,尤其 web 开发更是保罗万象。感兴趣的同学还可以了解一下一些新兴的基于 Python3 的框架,例如 FastAPI,其背后借鉴的许多现代框架的思想设计,包括数据验证,序列化,自动文档,异步高性能等,开拓一下知识面。

  • 自我考核:实现一个简单的 model serving http 服务。

算法工程交叉

大规模算法运行

分布式训练

在很多项目中,数据量达到十亿级以上的情况下,单机训练会难以支撑。因此分布式训练也是实际工程落地中非常重要的一个主题。分布式训练涉及到多机的通讯协同方式,优化算法的改造,数据及模型的并行与聚合,以及框架的选择和运维等话题,具体可以参考《分布式机器学习》。另外对于分布式系统,也可以参阅《数据密集型应用系统设计》这本神作,了解其背后原理。

  • 自我考核:能够在多机上进行亿级数据的 GBDT 模型训练与预测。

高性能计算

在做大规模的数据训练与推理时,近些年涌现出许多高性能计算优化的方法,例如从硬件方面,有各种超线程技术,向量化指令集,GPGPU,TPU 的应用等,从软件方面,有针对数值计算场景的 OpenBLAS,有自动并行化的 OpenMP,有各种 codegen,JIT 技术下的运行时优化等。这方面可以学习的方向也很多,从基础的并行编程,编译原理及优化的知识开始,到 CUDA,OpenMP 的应用(例如 Nvidia 的 cuDNN,还有 LightGBM 中也用到了 OpenMP),Codegen,JIT 等技术在 Spark,TVM 等项目中的使用等,建议有深度性能优化需求时可以往这些方向做调研和学习。

  • 自我考核:能够通过 LLVM JIT 来优化实现 Spark window function 的执行性能。

模型加速领域

这个方向分两个部分,一块是模型训练方面,能够做到加速,例如使用大 batch size,迁移学习,持续的在线 / 增量学习等手段,另一块在模型预测方面,也有很多加速需求,比如模型参数量优化,模型压缩,混合精度,知识蒸馏等技术手段,都是为了做到更高性能,更低资源消耗的模型预测推理。这方面业界有各个方向的文章和技术实现可以参考,比如经典的《Training ImageNet in 1 Hour》,MobileNet,TensorRT,二值网络等。

  • 自我考核:在典型的销量预测场景中实现增量训练与预测。

MLOps

编排调度

包含各类 pipeline 的编排与调度能力的支持,包括数据 pipeline,训练 pipeline 和 serving pipeline 等。这方面比较常用的框架工具有 Airflow,DolphinScheduler,Cadence 等,需要掌握其基本的工作原理和使用方式,并能够应用于离线实验与线上运行。

  • 自我考核:使用 Airflow 完成一个标准的项目 pipeline 搭建与运行。

数据集成

相对于传统的 DevOps,机器学习项目*大的区别在于数据方面的依赖会更加显著与重要。这方面的话题包括数据血缘,数据质量保障,数据版本控制等,有各类工具可以借鉴使用,例如数据版本管理方面的 DVC,数据质量方面的 TFX Data Validation,Cerberus,Deequ 等。在方法论层面,《The ML Test Score》中给出了不少数据相关的具体测试方法,值得参考学习。

  • 自我考核:在项目中实现输入数据的分布测试,特征工程测试及特征重要性准入测试。

实验管理

这部分也是 ML 项目的独特之处,在开发过程中有大量的实验及相应的结果输出需要记录,以指导后续调整优化的方向,并选择*优结果来进行上线部署。这方面可以参考的项目有 MLflow,fitlog,wandb 等。当然对于单独的项目来说,可能 online Excel 就能满足需求了 🙂

  • 自我考核:在实际项目中实行一套标准的实验记录手段,并能从中找出各类实验尝试带来的精度提升的 top 5 分别是哪些操作。

Serving

目前我们的 serving 大多数是离线 batch 预计算的形式,所以主要依赖的技术手段是各类离线 inference 的方法,例如直接使用 model predict 接口,使用 mmlspark 等做大规模并行 inference 等。如果涉及到在线 serving,情况会更加复杂,例如在线 pipeline 的运行,实时特征获取,low latency/high throughput 的 serving 服务等,可以参考 TF Serving,MLeap,H2O,PredictionIO,PMML/PFA/ONNX 等开发标准模型格式等。

  • 自我考核:部署一个实时预测服务,能够根据用户输入产生相应的预测结果。

CI/CD

软件工程中的持续集成,持续部署已经成为一种标准实践,在算法项目中,额外引入了数据这个维度的复杂性,带来了一些新的挑战。在这个方向上,几个主要话题包括自动化测试,pipeline 打包部署,持续监控运维等,可以参考 Martin Fowler 关于 CD4ML 的文章。工具系统层面,可以学习传统的 Jenkins,也有一些新选择例如 CircleCI,GoCD,VerCD(Uber)等。

  • 自我考核:通过 Jenkins 实现 pipeline 自动测试,打包,上线流程。

系统监控

在整个项目上线后,需要对系统的各个环节进行监控,并对各种异常情况作出响应。例如输入数据的监控,判别测试数据与训练数据的分布是否有偏移,整个运行 pipeline 的监控,判别是否有运行失败抛出异常的情况,对于预测输出的监控,确保没有异常的预测输出值,也包括对于系统计算资源等方面的监控,确保不会因为资源不足导致业务受到影响等。在监控信息收集,基础上,还需要配套一系列的自动告警通知,日志追踪排查等。这方面的工具框架包括 TF data validation 这类专门针对算法项目的新产品,也有 elasicsearch + kibana 这类传统产品。

  • 自我考核:将三个项目中做过的问题排查改造成常规监控手段,支持自动的问题发现,告警通知,如有可能,提供自动化或半自动化的问题排查解决方案。

MLOps 系统

MLOps 整体是一个比较大的话题,在这方面有很多产品和系统设计方面的实践可以参考学习。例如 Uber 的 Michelangelo 系列文章,Facebook 的 FBLearner,neptune.ai,dataiku,domino 等,虽然没有开源,但是其背后的很多设计理念,演进思考,白皮书等都非常值得我们学习。在开源界也有很多可以参考的项目,例如 MLflow,Kubeflow,Metaflow,TFX 等,可以学习他们的设计理念,Roadmap,以及实现细节等。

  • 自我考核:总结各个 MLOps 产品的功能模块矩阵对比,能够根据项目需求来进行产品选型与使用。

工程深入方向

数据库

数据库原理

在平时工作中,我们有大量的场景需要用到数据库。从客户数据的对接,数据集的管理和使用,到各种业务系统的数据表设计及优化等,都需要对数据库的运作原理,适用场景,运维使用,性能优化等方面有一定的了解。常见的需要掌握的概念有 OLTP vs OLAP,事务,索引,隔离级别,ACID 与 CAP 理论,数据同步,数据分片,SQL 语法,ORM 等。从底层原理看,会涉及到数据,索引,及日志等存储引擎方面,以及各种计算查询引擎,包括分布式系统的设计与实现。这方面推荐的学习资料有《数据库系统内幕》及《数据密集型应用系统设计》。

  • 自我考核:能够理解 SQL 执行计划,并能够根据执行计划来做索引或查询调优。

关系型数据库

目前常用的关系型数据库主要是 MySQL 和 PostgreSQL,主要需要掌握的是日常的一些 SQL 操作,例如 DML(增删改查),DDL(创建表,修改索引等),DCL(权限相关)。在此基础上还可以进一步了解一些如数据类型,高级计算,存储引擎,部署运维,范式概念与表结构设计等方面的话题。对于高级话题这块,推荐《高性能 MySQL》与《高可用 MySQL》。

  • 自我考核:在 MySQL 中设计相关表结构,存储实际项目中的一系列中间数据集。

NoSQL 数据库

常用的 NoSQL 数据库有几类,KV 存储(Redis),文档数据库(MongoDB),Wide-column 存储(Cassandra,HBase)以及图数据库(Neo4j)。在目前我们的算法项目中,比较有可能会用到的主要是 Redis 这类 KV 存储(也可能把 Cassandra 之类当泛 KV 来用),或者更新一点的类似 Delta Lake 的存储系统。建议学习了解一下这类 KV 存储,以及分布式数据库的常见操作方式,以及基础的运维排查,性能优化方法。

  • 自我考核:考虑一个线上模型服务的场景,用户输入作为基础特征,使用类似 Redis 的 KV 系统,实现实时获取其它特征,并进行模型预测。

云计算

基础架构

IT 系统总体的发展趋势在往云计算方向演进,即使是自建的基础设施,也会采用云计算的一套构建方式,让开发者不用过多的关注底层计算存储资源的部署运维。对于应用开发者来说,需要了解一些基础架构方面的知识,例如各类虚拟化及容器技术,配置管理,容器编排等,便于在日常工作中使用相关技术来管理和发布应用。从工具层面看,Docker 与 k8s 等技术发展速度较快,主要还是根据官方文档来学习为主。浙大之前出版的《Docker – 容器与容器云》一书中有一些更深入的话题的探讨,另外《Kubernetes in Action》中也值得一读。从方法论层面看,《Infrastructure as Code》和《Site Reiliability Engineering》是两本非常不错的学习资料。与算法应用结合的虚拟化,运维,持续集成等都是比较新的领域,需要我们探索出一条可行路线。

  • 自我考核:对于已有的算法项目,总结制定一套开发,测试,发布,运维的标准流程,且尽可能自动化执行。

分布式存储

前些年*流行的分布式存储是脱胎于 Google 经典的 GFS 论文实现的 HDFS,不过随着硬件技术的发展,计算存储分离思想的逐渐兴起,不但灵活性更高,成本更低,且各自架构的复杂度也大大降低了。因此目前更建议学习简单的 object store 形式的分布式存储,例如 s3,minio 等。在此基础上的一些存储系统,例如 Delta Lake,提供了事务,高效的 upsert,time travel 等功能,也值得关注与学习。原理方面,还是推荐《数据密集型应用设计》这本。

  • 自我考核:在项目中实现不同机器能够访问同一个 s3 路径的文件,并进行正常的数据读写,模型文件读写等功能。

分布式计算

大数据时代的分布式计算的鼻祖来自于 Google 经典的 MapReduce 论文,后续在 Hadoop 系统中做了开源实现,在前几年是非常火热的一项技术。目前业界的主流是 Spark 和 Flink,前者在批处理计算中处于霸者地位,后者是流处理领域的*者。目前我们的业务应用中,Spark 是比较常用的分布式计算引擎,其基本操作相关内容比较简单,参考官方文档或者《Spark 快速大数据分析》即可。后续的主要难点会有大数据量下的问题排查与性能调优,执行复杂计算或与 Python 相关 UDF 的交互配合方式等。这方面需要对 Spark 的系统架构,内部原理有一定了解,例如 master,worker,driver,executor 等之间的关系,lazy evaluation,DAG 的 lineage 与 stage 概念,shuffle 优化,wholestage codegen 等技术细节。这方面暂时没有找到比较好的资料,主要还是依赖实际问题解决的经验积累。

  • 自我考核:用 Spark 来实现项目中的特征工程,并在一定数据量情况下取得比单机 Pandas 更好的性能效果。

其它话题

其它云服务基础设施还包括分布式数据库,消息队列,zk/raft 分布式协作系统,虚拟网络,负载均衡等。这些话题离算法应用方面会比较远一些,基本上达到遇到需求时会使用的能力即可,在这里不做展开。

算法深入方向

AutoML

超参优化

自动化机器学习中比较传统的一块是超参数优化,进而可以推广到整个 pipeline 的超参优化,包括数据预处理,特征工程,特征选择,模型选择,模型调优,后处理等部分。目前业界应用比较广泛的技术手段主要是随机搜索,贝叶斯优化,进化算法,Hyperband/BOHB 等,在特征工程方面有 Featuretools,tsfresh,AutoCrossing 等自动化特征工程工具。学术界有一些进一步的探索研究,包括 multi-fidelity 优化,多任务优化,HPO 结合 ensemble learning,pipeline planning,data diff 自动数据分布探测等方面。可以参考 http://automl.org 上的各类参考资料与书籍进行学习了解。主要难点包括 automl 算法的泛化能力,scalability,整体 pipeline 组合的搜索与生成,针对不同学习算法的自动优化手段等。

  • 自我考核:了解超参优化的基础概念,能够在项目中应用框架工具来实现模型超参的贝叶斯优化流程。

元学习

Meta learning 是近年来非常活跃的一个新兴领域,其主要思路是希望能通过元学习模型方法,去积累建模调优的先验知识,跨任务推断模型效果并 warm start 新的训练任务,或者指导学习算法来进行更高效的具体任务的训练过程。这方面在工业界的主要应用基本上集中在建模调优先验知识的积累方面,比如通过一系列公开数据集搜索寻找出表现较好的起始参数,用于指导在新任务上做超参优化的起始搜索点。学术研究中除了 configuration space 的研究,还包括从 learning curve 中进行学习推断,元特征提取与建模,HTN planning 在 pipeline 构建中的应用,以及 MAML 等 few-shot learning 方向的探索。这方面推荐 Lilian Weng 的一系列文章(https://lilianweng.github.io/lil-log/2018/11/30/meta-learning.html),以及 http://automl.org 网站上的资料。

  • 自我考核:设计一系列 meta feature 与 meta learning 手段,实现对新任务的参数选择的初始化。

NAS

AutoML 领域比较火,但也是比较特别的一个方向,目前需要大量的计算资源投入才能做这方面的研究与尝试,因此主要建议了解一下这个方向的一些工作即可,不做深入探索学习。

AutoML 系统

自动化机器学习相关的框架工具也非常多,比较有代表性的框架有 auto-sklearn(来自 http://automl.org 团队),nni(microsoft),auto-gluon(amazon),H2O,ray tune 等,在工具级别也有如 hyperopt,SMAC3,featuretools 等。可以通过学习这些工具框架,了解 AutoML 系统的架构与实现方式,并应用到实际项目中。

  • 自我考核:使用一种 AutoML 系统来进行项目的模型自动优化,并与手工优化的结果进行比较,看是否有所提升,及寻找背后的原因。

模型解释

模型解释技术

主要有三个方面,一是模型本身的解释性,例如线性回归,决策树等,模型结构简单,根据其原理,可以直接对预测结果,特征使用等方面给出解释。另外一些复杂模型,例如 EBM,神经网络,Bayesian rule lists,SLIMs 等,也可以利用一些本身的特性给出一些解释,例如 GradCAM 方法等。二是模型无关的解释方法,包括经典的 PDP,ICE 等特征图,LIME 等 surrogate model 方法,以及基于博弈论的 Shapley 方法。三是基于 sample 的解释方法,例如 conterfactual explanations,adversarial examples,prototypes,influential instances,kNN 等,不过看起来这类方法对于计算的开销一般都会比较大,不太容易在工程中实现落地。这方面的资料可以学习《Interpretable Machine Learning》和《Explainable AI》(关于深度学习的内容会更多)。另外学术界也有很多前沿探索,比如针对模型解释的降维工作,自动的时间序列分析及报告生成,因果模型,模型公平性及社会影响等方面,可以保持关注。

  • 自我考核:理解 LIME,Shapley 的运作原理,并分析其局限性,尝试提出改进方案。

模型解释应用

从工具框架方面,有许多可以使用的开源项目,例如微软的 interpret,eli5,shap,AIX360 等。另外也有一些非传统意义上的模型解释,例如 manifold,tensorboard 这类模型 debugging 工具,自动化的误差分析与模型改进方案,因果模型框架,模型公平性评估与纠正工具等,都可以涵盖在广义的模型解释领域中。在工具基础上,如何结合业务领域知识,给出更有针对性的解释方案,也是值得思考深挖的方向。

  • 自我考核:使用 shap,eli5 等工具来进行模型解释,并在此基础上形成面向开发者的模型 debug,误差分析及改进方案,或形成面向业务的 what-if 分析看板。

总结

目前机器学习应用领域还在高速发展与演进过程中,除了上述提到的技能方向,后续很可能会不断有新的主题引入进来,需要练就快速学习并应用落地的能力。在掌握前面编程,软件工程,机器学习的基础上,后半部分的研究方向,大家可以根据个人兴趣,选择几个进行深入探索与实践。仅阅读相关书籍和文章,只能对知识内容有一个初步的认识,必须要通过深入的动手实践,反复试错思考和修正,才能逐渐内化为自己的技能,并构建起较为坚实的知识体系。

原文链接:https://zhuanlan.zhihu.com/p/192633890

图解云服务模型的演进

%title插图%num

一.表层模型
早在2008年,Microsoft等公司(在此之前还有Amazon、Google)就在探索云服务了。推出Azure时,Microsoft提出了这样的模型图:

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-r7dhmivq-1579522673130)(https://dachou.github.io/assets/20180928-cloud-service-models-20081119.png)]

用来解释PaaS模型与当时人们所熟知的本地部署(on-premises)、外包托管(outsourced hosting)之间的差异

具体的:

本地部署:需要拥有(购买)硬件并维护数据

外包托管:可以直接用主机托管或托管服务器

PaaS:使用云架构,不但资源托管还支持弹性扩展

实际上,这种基于订阅的收入模型可能会蚕食Microsoft当时已有的许多基于许可证的产品。但从宏观上看,规模经济(economies of scale)才是云服务模型*重要的价值

在微观经济学中,规模经济是指企业由于经营规模而获得的成本优势,单位产出成本随着规模的扩大而降低:

In microeconomics, economies of scale are the cost advantages that enterprises obtain due to their scale of operation (typically measured by amount of output produced), with cost per unit of output decreasing with increasing scale.

简单来讲,规模经济就是随着规模的扩大而更高效地做事:

The simple meaning of economies of scale is doing things more efficiently with increasing size.

在云计算中体现在资源集中管理(Resource pooling)上,从而产生规模效应:

云计算的规模经济体现在两个方面,一是使得用户终端成本降低,二是拥有更高的利用率,因而被认为可能产生良好经济效益。

一方面用户不需要购买存储器或服务器、而是通过购买服务来获得(相应功能),降低成本的投入和管理费用。另一方面云服务的提供实际上就是大量的用户在共享一个服务的资源,利用率更高。

由云服务供应商集中管理软硬件资源,并提供维护、按需计费、弹性扩展等服务,用户不再需要全权控制上上下下的N层资源栈,即可部署自己的应用程序(PaaS)

二.资源栈模型
上图仅从表层去描述了PaaS与外包托管和本地部署之间的主要差异,缺乏具象的对比,因此需要一种能够突出差异并传达其价值,同时还能说明差异程度的可视化模型:

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BZpuHfCP-1579522673137)(https://dachou.github.io/assets/20180928-cloud-service-models-20090526.png)]

先根据人们所熟知的本地IT环境抽象出9层资源栈,作为统一上下文,再将云服务模型映射到这个上下文中,并突出差异。之所以用层次结构来描述,是因为:

体现了某种程度的关注点分离

表现出栈中各层之间具有一些直接依赖关系和设计/操作抽象

具体的:

本地部署:正如我们所理解的那样,完全控制整个资源栈,拥有并管理这些资源

IaaS:不再全权控制所有资源,下5层托管给基础设施供应商

PaaS:除Application之外的层都交由供应商管理了,我们只需要关注自己的应用程序

三.类比模型
也有一些类比模型,例如披萨、汽车等,但都不如资源栈模型贴切,因为在做类比时会丢失一些上下文信息,比如层间依赖和关注点分离

以汽车模型为例:

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-WCzBSzAU-1579522673140)(https://dachou.github.io/assets/20180928-cloud-service-models-20090526-analogy.png)]

这种类比的关键点是:

本地部署:就像拥有自己的车,可以随时去任何想去的地方(完全控制)。车的型号、外观、颜色、装饰等都可以自选,但要自己负责维护

IaaS:像是租车服务,仍然可以随时想去哪就去哪。虽然在车的选择上有一些限制,但不必自己维护,拿到钥匙就能出发

PaaS:就像公共交通,可以根据发车时间表按既定路线去往已通车的地方,虽然存在这样一些限制,但易于使用,而且能按使用量付费(得益于规模经济)

从本质上来讲,这种类比所表达的还是*初控制与规模经济之间的权衡,但在视觉上更容易理解,而且有助于展开讨论和传播

四.资源栈模型扩展
9层资源栈模型出现之后,又对其视觉呈现做了一些修改(将3D的部分扁平化,减少颜色数量,去掉复杂形状),得到了:

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-V30uKvux-1579522673154)(https://dachou.github.io/assets/20180928-cloud-service-models-20091027.png)]

接着有人提出SaaS也应该加进来,于是有了:

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-SA22l5hA-1579522673158)(https://dachou.github.io/assets/20180928-cloud-service-models-20100115.png)]

为了让SaaS与PaaS的差异更明显(直接加的话,仅一层Application的区别),对资源栈本身做了一些调整:

Security & Integration层被删掉了,因为所有层都存在安全问题,作为单独一层没什么意义

在Applications层下面添上Data层

Databases, Servers, Server HardWare层分别改为Middleware、O/S和Server层

这样,云环境(IaaS、PaaS、SaaS)之间都是2层差异,云环境与本地环境之间有5层差异,表明云环境与本地环境间的差异更大

之后为了表意更准确,又做了一些修缮,

O/S改为Operating System

On-Premises改为Traditional IT,因为本地部署包括私有云环境,要区分开

对IaaS中的managed by线做了轻微调整(延伸出一部分到Operating System层),表示IaaS中的O/S层是共同维护的,云供应商提供基础了VM镜像,但用户还需要维护其补丁和更新
————————————————

原文链接:https://blog.csdn.net/ayqy_jiajie/article/details/104055930