解析阿里云大数据服务
我的图书馆
解析阿里云大数据服务
阿里云有许多很好的技术，比如负载均衡SLB，关系型数据库RDS，云服务器ECS，开放存储服务OSS等。如今又增加了一款重磅云服务产品：基于飞天的，提供数据仓库、数据挖掘和其他数据应用等功能。7月14日，阿里云计算公司总裁及阿里巴巴集团副总裁王文彬（花名菲青）为之站场，并称之为“中国进入大数据时代的里程碑”。阿里云总裁王文彬（花名菲青）为ODPS站场对内统一：ODPS是阿里集团唯一的大数据处理平台从确定自主开发，到2014年1月，阿里云正式发布ODPS服务，整整五年。阿里云工程师们写下250万行代码，不断试错，不断优化，不断打磨。如今，对内：阿里小微金服（支付宝、小贷、保险、基金）已经全线迁入，数据魔方，阿里妈妈广告联盟，广告搜索，点击预测模型训练，淘宝指数，阿里无线，高德，中信21cn等业务都在其上，对外：药品电子监管系统、华大基因也已采用了ODPS。ODPS是阿里集团30多个事业部唯一的大数据处理平台更有意思的是，4月，为了更好地对ODPS平台上进行算法的调试、测试，阿里巴巴举办了基于ODPS的天池算法竞赛（“天池”平台基于阿里云ODPS的大数据开放平台，向学术界免费提供科研数据和数据处理服务，第一期开放三类科研数据集，包括用户购买成交记录、商品购买评论记录、商品浏览日志记录等，数据经过脱敏处理，所有数据均可由平台应用者使用）。竞赛的题目是：天猫推荐算法大赛开放竞赛数据：在天猫，每天都会有数千万的用户通过品牌发现自己喜欢的商品，品牌是联接消费者与商品最重要的纽带。本届赛题的任务就是根据用户在天猫的行为日志，建立用户的品牌偏好，并预测他们在将来对品牌下商品的购买行为。各大高校的参赛者在ODPS平台上进行算法的调试、测试。几个月下来，成绩斐然。阿里云相关负责人对CSDN云计算表示：最优秀的算法比天猫本身数据预测算法效率还高10%！正是有了这些真实落地的效果，王文彬才更有信心：“ODPS会是阿里集团30多个事业部唯一的大数据平台。这其中既包含已经完全迁入的小微金服，也包含电子商务（淘宝、天猫、聚划算、、、AliExpress）、智能物流骨干网（菜鸟物流）在内。涉及到几亿用户的数据，工作量极大，需要慢慢来做。但这一时间点，我相信很快。”这一计划被阿里内部称之为“登月计划”。其中还有一些小故事。接近阿里云的都知道：阿里云的云梯1，是基于Hadoop的；而云梯2才是自主开发的。阿里内部对于二者的技术争论由来已久。而大家不知道的是，2013年10月，为了融合阿里小贷和支付宝的数据，支付宝希望ODPS团队协助他们搬家，将支付宝数仓业务从Hadoop机群搬到ODPS上，这就是“登月1号项目”。2014年5月，登月1号项目成功，小微金服的全部数据业务开始基于ODPS发展。也正是阿里内部对于“稳定性，安全性，服务能力要求最高”的小微成功迁入，才有了后续覆盖搜索、广告、物流等多个BU的数据统一的计划，才有了“ODPS将成为承载阿里集团全部数据的统一处理平台”的实施。阿里内部对ODPS评价颇高。“从Oracle到Hadoop，我们解决了海量数据如何存储和分析的问题，阿里的数据业务不再受制于规模的瓶颈；从Hadoop到ODPS，更是一次质的飞跃，为后续大数据业务的开展扫清了障碍。登月计划共计划了20多个项目，涉及阿里巴巴和小微金服所有的事业部，覆盖集团全部数据人员，其牵扯人员、资源之多，在集团内部罕见。登月计划的全面启动，标志着阿里集团自研的飞天+ODPS平台，从功能和性能上已经渐渐超越了Hadoop，阿里云的技术走在了世界前列。”对外拓展：主攻结构化数据和半结构化数据，未来支持更多框架在阿里云的产品规划中，基于飞天，有多类服务：离线的结构化数据存储和计算服务平台——ODPS （Open Data Processing Service），半结构化数据的实时随机读写服务——OTS（Open Table Service），实时流数据处理服务——OSPS（Open Stream Processing Service）等。ODPS的产品、用户和生态谈到ODPS能够处理什么类型的大数据，阿里云产品经理汤子楠表示：“ODPS最擅长处理结构化数据，比较擅长处理半结构数据，不能处理非结构数据（当然，最后这点会通过与开源技术合作及其他技术开发来拓展）。”具体来看ODPS的产品、用户和生态：产品：SQL、MapReduce、BSP、算法包；安全控制、分享机制用户：大企业——存储计算能力服务化，专注数据和业于务；生态：海量计算、准实时计算、流式计算；个人，大数据平民化，数据创新；数据生产者，数据消费者（广告、推荐、客满改进、模式创新），数据加工者（行业专家、咨询公司等）和服务与应用供应商（数据应用、BI等）其产品优势可以概括为5点：海量运算触手可得：用户不必关心数据规模增长带来的存储困难、运算时间延长等烦恼，ODPS可以根据用户的数据规模自动扩展机群的存储和计算能力，使用户专心于数据分析和挖掘，最大化发挥数据的价值。服务“开箱即用”：用户不必关心机群的搭建、配置和运维工作，仅需简单的几步操作，就可以在ODPS中上传数据、分析数据并得到分析结果。数据存储安全可靠：ODPS采用三重备份、读写请求鉴权、应用沙箱、系统沙箱等多层次数据存储和访问安全机制保护用户的数据：不丢失、不泄露、不被窃取。多用户协作：通过配置不同的数据访问策略，用户可以让组织中的多名数据分析师协同工作，并且每人仅能访问自己权限许可内的数据，在保障数据安全的前提下最大化工作效率。按量付费：ODPS根据用户实际的存储和计算消耗收费，最大化的降低用户的数据使用成本。汤子楠表示：“ODPS所有的功能是以RESTful API的形式对外提供，目前仅支持SQL，其他服务将后续逐一对外开放。而由于ODPS设计之初就是为了对外开放，做基于互联网的多租户的公共数据处理服务，安全性在ODPS的设计和实现中具有优先级很高。未来，ODPS还将开放更底层的逻辑计算单元，支持用户基于ODPS开发Spark、Pig、准实时、流处理等，真正成为在ODPS统一平台可以实现多种框架的大数据运算的乐趣。彻底解决现在数据要从不同集群中导来导入，且没有统一布局，数据处理和维护都的麻烦。”对于ODPS，阿里云的定位显然不仅是内部的数据统一平台，而且在外部，也将通过合作共建生态，为更多企业提供大数据服务。汤子楠分享了一个用户案例：药品电子监管平台，收集中国境内每盒药从生产、批发、零售环节的所有流通信息，每盒药都印刷了一个条形码“中国药品电子监管码”。药监部门利用这些流通信息追踪到中国市场上每批药品流向，追溯到零售环节任何一盒药品的来源。而伴随药品数量的急剧攀升和分析等新需求，原有的Oracle系统无法满足需要。新的数据平台基于OTS+ODPS两款产品，关键业务处理的平均延时降低100倍以上，成本大幅降低。除此以外，还有华大基因，其已经在ODPS上做了基因测序，耗时不到传统方式的十分之一。最后，ODPS的峰值是100PB数据处理6小时完成。按照使用量付费，存储1GB的数据，ODPS每个月大概是0.5元左右。技术：ODPS与BigQuery、Redshift+EMR、HPC的比较从技术上看，对ODPS还有两个疑问。阿里云的回复很到位。1.ODPS与Google BigQuery、Amazon有Redshift和EMR的比较？阿里云：Google的BigQuery，Amazon的Redshift和EMR，可以认为是ODPS的类似产品。在国内，ODPS是首款大数据存储和计算开放服务。ODPS和BigQuery的产品形态比较类似，比如都支持海量数据的存储和计算，都支持SQL语法等。两者的主要区别在于：1）底层技术实现不同。BigQuery基于Google自研的Dremel引擎，而ODPS则基于阿里云自研的飞天系统，两者在存储、任务调度、任务优化上有很多细节都不一样。2）BigQuery的主要应用场景是交互式BI分析，而ODPS的适用场景则广的多：目前已经开放的SQL功能主要用于数据仓库和日志分析；后续还将开放UDF和Map Reduce，支持用户编程的离线计算；ODPS准实时，支持交互式BI分析；ODPS流处理，支持实时计算等。同时，ODPS的数据授权体系功能更加丰富，使用更加灵活，可以同时满足数据拥有者、数据消费者和数据分析者的需要，ODPS未来可以成长为一个基于数据的生态系统的底层平台。3）BigQuery仅是一款产品，而ODPS则是阿里云产品线的一部分。除了ODPS之外，阿里云还有SLS、OTS等一系列大数据服务，组成一个综合的大数据解决方案，满足用户在大数据领域的多项需求。2.&ODPS与各个超算中心提供能力的区别？阿里云：1)超级计算机更适合计算密集型作业，如果是用MPI算核物理、天体物理、蛋白质折叠、求解普通PC上需要几千万年的迭代方程，用超级计算机可能更快。反过来，分布式集群Mapreduce适合IO密集型的作业，加上成本低，可以把集群规模搞得很大，因此最适合扫描过滤海量的数据，例如互联网行业的经典应用：为搜索引擎创建全网Web页面的索引。2)超级计算机造价更昂贵，维护成本也高，甚至每小时电费就得上万元。云计算是建立在低成本硬件+牛B的分布式操作系统设计上，在计算灵活性和多任务处理上远超超级计算机，可以更广泛的应用于商业领域，例如阿里云去年和国内的动画公司合作渲染出来的《昆塔》，计算量是《阿凡达》的四倍。随着国内经济的升级，很多造船、石油、材料、生物、天体物理、军事领域的计算需求都很强烈，这一类计算密集型任务，也可以通过云计算完成。ODPS是可以支撑科学运算的，阿里正在举办的大数据竞赛就依托于ODPS平台。参赛选手大量使用逻辑回归、随机森林这一类的数据挖掘算法。进一步简单解释一下，基于飞天系统，ODPS实现了Mapreduce（以及更高级的多阶段DAG）、Graph、MPI等编程模型在同一个计算集群上统一调度。因此除了
IO密集型的计算，还能支持计算密集型的迭代计算，例如随机梯度下降。不过目前阿里云ODPS只对外开放商用了SQL编程接口，更多接口例如Mapreduce、Graph等等还没有进入公测阶段，不过很快就会对外了。大数据技术生态中，ODPS所代表的的只是其中重要的一环，后续更为重要的是，强化伙伴能力，迅速在更多行业和应用中扎根。期待基于ODPS的扶植计划！
本文为CSDN原创文章，未经允许不得转载，如需转载请联系market#csdn.net(#换成@)
TA的最新馆藏
喜欢该文的人也喜欢阿里云数据库，破解大型网站架构设计中的数据存储难题
阿里云数据库，破解大型网站架构设计中的数据存储难题
互联网变化快
更多深度文章，请关注云计算频道：/cloud摘要：3月10日，2017阿里云网站行业热点问题和解决方案线下研讨会在上海举行。在本次研讨会上，阿里云数据库团队产品专家王义成（花名挚尤）针对于大型网站的数据库架构设计以及阿里云ApsaraDB所提供的服务管理和解决方案进行了深入介绍。分享者简介：王义成（花名挚尤），阿里云数据库团队产品专家，负责阿里云NoSQL数据库的产品规划。加入阿里巴巴近5年的时间，参与过多种云数据库的产品设计工作。目前主要负责阿里云的MongoDB、Redis以及MemCache产品，旨在为广大客户提供安全可靠的数据库解决方案。以下内容根据演讲视频以及PPT整理而成。最近一年整个数据库行业可以说是风生水起，同时也发生了包括MongoDB黑天事件以及最近的GitLab删库误操作事件在内的很多事件，这些事件导致了各自的业务都遭受了巨大损失。而很有意思的一件事情就是在MongoDB黑天事件发生之后，使用阿里云MongoDB服务的实例数开始出现暴涨，这其实是因为大家都抱着亡羊补牢的心态，开始使用云数据库。今天就为通过以下四个主题为大家简单剖析为什么做大型网站需要使用云数据库：一、通用数据库架构二、ApsaraDB.概要介绍三、ApsaraDB.服务管理四、ApsaraDB.解决方案本次分享中首先会介绍大多数互联网行业的数据库通用架构设计、自建数据库的一些常见问题以及面对的困难，之后将介绍ApsaraDB基于什么样的考量为用户设计出了什么样的产品以及ApsaraDB所提供的服务管理能力，最后还将介绍ApsaraDB为阿里云整体提供了什么样的数据库解决方案。1.电商高并发，高性能场景在第一部分将介绍互联网企业中常用的五个场景。第一个场景就是电商高并发，高性能场景。在电商高并发的场景下，很多架构采用了MySQL，也有一些架构采用了PostgreSQL，并且目前大量的电商行业也开始使用MongoDB数据库。而且对于新兴的电商企业而言，由于数据相对比较灵活，所以基本上都会选择使用MongoDB构建线上应用，还有一部分电商使用Redis做持久化存储，将用户信息类的数据直接使用Redis存储到数据库中。这类场景对于数据库的要求关键字就是高性能和数据安全。那么如何保证数据库具有较高的性能并且保障数据安全，并且电商的核心交易往往存储在MySQL数据库中，该如何从网络层面来保护数据安全，又如何防止SQL注入，这些问题都是应用DBA或者开发同学需要考虑的事情。如果使用自建的数据库时就需要考虑应该采用什么样的手段来保障数据库的高性能和安全，应该采用一主多从策略还是采用水平分区策略，这些问题都需要进行考虑。2.金融：安全交易类场景第二个场景就是安全交易金融类的场景。在金融类场景下，数据库往往需要支持海量的数据存储，可以从上图中看到，可以结合前面的分布式Proxy和后面MySQL以及MongoDB数据库实现分布式数据库的架构。目前MySQL和MongoDB数据库是可以实现分布式数据库设计的，包括阿里云的DRDS以及开源的TADL等都可以用于构建自己的数据库系统。而在自建数据库时就需要去考量如何进行数据库的横向扩展以及如何保证分布式数据库能够平稳地运行，并且保证网络安全和数据安全。除此之外，金融类场景中的一个核心要求就是保证业务高度可靠，当单节点无法满足需求时需要使用双机热备，而当使用双机热备的时候如何保证在主机宕机的情况下备机不会丢失数据、某一个机房挂掉之后业务能够瞬间恢复、缓存数据宕掉之后能够避免对于后台整体业务的冲击过大以及在缓存宕掉之后能够迅速地拉起等问题，都是在自建数据库时需要仔细考虑的，而这些也正是处理中的难点。3.网站：高性价比场景第三类场景针对的是比较通用的网站类，也就是要求高性价比的场景。在这个场景下的数据存储可能会使用到缓存层以及后台的数据库层，数据库可能会使用MySQL、PG或者MongoDB，在缓存部分可能会使用到Redis或MemCache。这个场景下对于缓存的要求就是成本足够低并且性能足够高，这些也是在自建数据库时需要保证的，而对于后台存储数据库而言，则要求具有较高的性价比。因此如果使用一主一备的策略可能无法满足高性价比的需求，所以需要使用读写分离以及一主多从的策略。虽然MySQL、PG以及MongoDB都提供了原生的一主多从的策略模式，但是如何处理这样的模式以及读写分离策略，都是需要应用程序开发人员以及DBA进行联合考量的，所以在自建数据库时就将会耗费大量的人力、物力和财力。4.游戏：行业高可用场景第四类场景是游戏类通用的数据库场景，该场景的核心特点就是ECS和数据库具有分服的概念，也就是在游戏中会分出多个区。所以对于游戏数据库而言，需要保证其高稳定并且防止对于数据的误操作。对于一些游戏产品而言，往往发展非常迅速，可能一到两周就会更新一个版本，如果开发和测试不完善就可能因为误操作导致数据错误。那么DBA如何保证在发生误操作时，能够瞬间恢复到误操作发生之前的时间节点的数据状态，这也是整体维护上的难点。而且在游戏行业往往需要秒开数据库，可能一天开多个区，会有大量用户进来，那么如何保证整体的前端服务、CDN以及底层的数据库在一两分钟之内就能够将业务全部开启，这也是对于数据库的一个考验。5.通用：大数据分析第五个场景是大数据分析场景，在这个场景下的底层可能是一个Hadoop集群在晚上换算各种数据，白天就能够将数据展示给老板看。比如整个网站的交易量数据都需要经过一夜的运算存储到前端的MySQL或者Redis数据库中，快速方便地供业务内部人员审核。在这个场景下，对于数据库要求就是需要一个能够将Hadoop中的数据一键式地导入到MySQL中的工具，还需要增加易用性，使得各个业务方都能够方便地查看数据，并且需要低成本地应用MySQL和MongoDB数据库来满足内部查询需求。所以在大数据分析场景下数据库的关键词就是易用，需要数据库服务能够提供数据通道，保证在异构的数据引擎之间进行数据快速传输，并满足数据库层面的低成本诉求。以上就是互联网应用中的五种通用的数据库架构，总结而言自建数据库的难点就在于以下四个方面：1.稳定性，首先就是宕机怎么办？如果搭建了一主一备的数据库策略，就需要保证主机宕机之后服务能够快速恢复起来，并且机房宕机之后也要保证服务能够快速起来。如果发生了地域的灾难性事件之后需要能够在一天或者几个小时之内迅速恢复服务，而如果数据量非常大时就难以保证数据库服务能够在一天之内恢复，这些都是自建数据库的难点。另外如果数据丢失了怎么办？可能业务是正常的，但是被黑客黑掉了，发生了像MongoDB黑天这样的事件或者被SQL注入攻击了，在这样的情况下业务如何才能快速地恢复起来，还有白名单策略是否足够好，以及在SQL注入将数据删除之后是否能够迅速恢复SQL注入之前的数据库状态，并且判断出是谁对发起的SQL注入或者攻击，这些都是在自建数据库时需要考虑的难点。除此之外，还需要保证发生误操作时数据库的稳定性，虽然MySQL有比较合理的权限管理机制，但是像新兴的MongoDB以及Redis等数据库对于权限管理的处理还是比较粗放的，而在权限管理不合理的情况下，如果触发了误操作将可能修改了整个数据库，此时DBA如何才能够快速地将数据恢复以及恢复后会丢失多少数据都是需要考量的难点。2.扩展性，当业务快速发展的时候，数据库如何纵向地升级也需要在自建数据库时考虑。大家在ECS上可以自由调配资源，如果没有使用云服务而是使用的自建机房，当进行活动宣传时可能出现平时业务的十倍增长量，这使得数据库的压力也会急剧增加，纵向的数据库如何调度也将会成为难点。对于自建机房而言，服务器的采购周期也会很漫长，而搭建在ECS上就能够解决这个问题。但还存在一个问题就是数据库的纵向升级也是存在瓶颈的，即便是ECS也是有固定的配置，当单个ECS已经无法承担业务压力的时候，数据库又应该如何横向升级也需要在自建数据库时考虑。举个简单的例子，大家都知道Redis是单线程的，ECS配置再高也只能增加内存的数量，QPS的极限也就是十万，当业务迅速上来，纵向升级已经达到极限的时候，如何将Redis直接横向扩展为集群的实例，以及扩展成为集群之后如何进行维护，这些也都是DBA需要面对的巨大挑战。除此之外如何实现异构数据库之间的数据互通，如何将MySQL中的数据定向地导入到MongoDB或者Hadoop中，或者将Hadoop中的数据导入到MySQL中，这些都是需要耗费很多开发力量并且需要很多DBA的运维工作的。3.安全性，如果能够预防SQL注入以及网络攻击，如何在遭受攻击的时候终止攻击，也就是在判断出这是一个SQL注入时，如何将其进行拦截也是在自建数据库时需要考虑的。还有如何亡羊补牢，在遭受攻击被脱库或者删库之后，在最短的时间内将数据找回并且将业务恢复起来，对于DBA而言也是难点。另外就是在遭受攻击之后，需要追查出攻击者到底是内鬼还是外部黑客，如果在管理比较混乱时，查出数据库是如何被删掉的以及到底是谁攻击的，都是自建数据库的难点所在。4.优化和人力，SQL慢了该如何进行优化，在前期数据库管理时如果优化了数据库的性能就能够提升网站的整体性能。另外架构演练如何进行升级，比如从原本的只有MySQL的数据库架构演化成为前端+缓存并且使用更加合理的数据库的架构，这些都是优化中的难点。其实除此之外，关系型数据库的DBA还是容易招募到的，但是招NoSQL领域的DBA还是相对比较困难的。那么在整体运维层面比较困难的情况下，如何最大地发挥数据库的价值就是阿里云推出的数据库服务的目标。围绕着在自建数据库中遇到的难点，就能够衬托出阿里云数据库产品的使命。之前分享了在自建数据库中遇到的难点和需要解决的问题，接下来介绍一下阿里云的ApsaraDB数据库在做什么以及能够帮助用户解决什么样的问题。飞天技术栈下图是阿里云的飞天技术栈。最下层是阿里云的数据中心，其上层是阿里云的操作系统和文件系统，再上一层就是服务部署和资源调度，再上面一层就是任务系统、安全管理以及集群监控。在飞天技术栈最上面的这一层就是用户可见的云服务，这一层大致分为了七大板块：计算、存储、网络、数据库、内容分发、大数据以及中间件。目前阿里云数据库团队的产品有关系型数据库RDS、包括Redis、MongoDB、MemCached在内的NoSQL类的数据库以及金融类的数据库OceanBase、针对大数据的EMR和Greenplum以及自研集成了OLTP以及OLAP的数据库PetaData。阿里云数据库-ApsaraDB产品家族下图是阿里云数据库团队目前支持的几款产品，开源类的产品包括MySQL、PostgreSQL、MongoDB、Redis、MemCached、Greenplum以及Hadoop。而在商业化数据库体系里则支持SQLServer的两个版本，以及PostgreSQL的高级版，可以兼容95%的Oracle协议的PPAS，其可以作为Oracle用户上云的临时替代方案，另外对于Oracle这部分，存在ApsaraDB的合作伙伴能够帮助用户去维护和构建云上Oracle，另外还有HAVA，也就是ApsaraDB的合作伙伴SAP上线的HANA1，在未来不久就可以在阿里云上售卖HANA的版本。流量组件下图是阿里云上的几个大的流量组件。1.VPC+SLB，在安全性上，阿里云提供VPC+SLB的模式，这其中的SLB是购买RDS服务或者Redis、MongoDB自带，这个SLB其实是内部直接包在RDS中的，其主要帮助做四层的负载均衡。VPC的虚拟路由器和虚拟交换机保证在公有云之上该网络只有自己的专有网络内的用户能够连接，保障与其他网络用户的天然隔离，并且在整个数据库层面之前会绑定一层针对DDOS攻击的防御措施。2.Proxy，Proxy也是阿里云数据库团队自研的组件，其主要作用是帮助用户实现七层的负载均衡。像分布式事务和读写分离这些都是在应用场景中帮助用户解决性价比问题的，当一个请求过来之后，可以直接通过Proxy判断该请求是读还是写，并根据策略分发到读或者写节点，不需要应用程序再进行解析和判断。SQL解析一方面就是将请求分析出来并且分配到相应的读或者写节点，另外就是及时地终止攻击，这个层面的SQL解析还处于研发阶段，未来希望通过SQL解析来判断请求中的语句是否存在SQL注入的嫌疑，如果用户选择让阿里云帮助进行判断，如果发现的确是SQL注入就会在应用程序上直接进行拦截，避免对于数据库造成灾难性的损失。还有一点就是连接保持，比如想要对于MySQL进行内核修复时，升级版本对于前端而言是非常痛苦的，应用程序就需要全部重连。而在主备进行切换或者主数据库进行内核升级的时候，如何保证业务不受影响，都需要依靠Proxy帮助进行连接的保持，而这则会免去对于运维干扰。3.DBEngine，这里有多种数据复制方式保证RPO和RTO在相应的结合模式上进行处理，当对于数据可靠性要求比较高时，可能会选择双节点+半同步的模式；而当对RPO要求比较高时可能会选用异步复制的模式，这样就可以通过DBEngine来适配多种数据复制模式来解决不同用户的需求。另外DBEngine提供了插件式引擎，阿里云数据库团队提供了大的中台来支撑用户的服务能力，目前也已经实现了插件式引擎方式，比如在新建数据库时只需要一两个月的时间就可以实现产品的公测和商业化，能够快速地满足用户对于数据库的需求。除此之外还提供了源码级定制，数据库团队在开源领域吸收了中国顶尖的内核级开发人员来维护源码级的版本，目前使用的MySQL版本也都是去年开源的AliSQL的版本，其相比于原生MySQL内核性能提升了70%，而像MongoDB和Redis也都能够从内核层面帮助用户解决性能问题。4.HA，用户使用数据库一个核心的需求就是稳定，而稳定性需要强大的HA系统来支撑。阿里云数据库团队的HA能够帮助用户进行健康检查、流量切换以及SLA计算。原生的流量切换只会检测程序的安全性，当内存hang住或者IO出现问题时，原生无法切换过来，而阿里云的HA策略是尝试真实地写磁盘IO，保证在受到影响之后HA都可以切换过来。流量路径下图是数据库架构的流量路径，这里介绍了用户购买阿里云数据库服务之后的数据流向。下图存在双节点，其实双节点的设计也会存在问题，比如某一机房断电或者网络出现故障，数据中心也就会瘫痪了，而阿里云的MySQL和Redis都提供了跨可用区的复制，也就是数据库实例存在多个可用区，当一个可用区出现故障之后可以直接将流量切换到备用机房，保障业务不受影响。下图展现的大致流程就是流量到来之后，数据将通过Proxy路由到DBEngine层，DBEngine层通过阿里云内网专线将数据复制到远端的跨可用区的数据库节点上，也就是如下图所示的左边是主节点，右边是备用节点，只不过备用节点平时不会承担流量，数据正常进行复制。如果发现主节点宕机之后就可以直接将流量全部一键切换到备用节点上，免除了用户自己维护稳定性的困难，也同时保障了服务的高可用。连接优化下图展现的则是Proxy的连接保持优势，其实在数据库层面往往需要两个节点，对于大型的云服务而言，某一台主机坏掉是很正常的情况，那么在宕机或者在数据库内核更新时如何才能不影响用户业务，其实背后都是依靠Proxy体系支撑的。内部的SLB直接连到为用户提供的Proxy上，Proxy连接DBEngine，当主机需要升级或者宕机的时候，可以把主机的链接断掉，直接将Proxy连接到备用节点，而在恢复时连接其实并没有断掉，在切换时可能会有一两秒的卡顿，但是对于却免去了业务重连的处理。总之，整个云服务就可以依靠Proxy实现连接保持。复制方式目前阿里云数据库服务一共提供了以下四种复制方式：RPO+RTO模式，该模式实现了瞬间恢复以及恢复后能够找到时间点，在默认的双节点情况下进行半同步复制，也就是数据必须要到达备端之后才能返回，所以当主节点宕机之后，备节点能够快速地运行起来，但是这样性能就会有相应的损耗，因为需要将数据传输到备端，如果选用了双可用区本身还会有3到5毫秒的延迟。RTO+Performance模式，这个模式下能够保证在数据宕机之后能够快速起来，这对于RTO不是很高的要求，可能起来之后数据会丢失一些，但是要求性能足够高，这种模式使用双节点+异步复制。RPO+Performance模式，这种模式下数据宕掉之后可能恢复时间会长一些，可能需要1到5分钟，但其RPO是没有问题的，其底层使用了共享存储并且性能足够高，并且使用的是单节点。RPO+RTO+Performance模式，它使用了多节点、强同步复制以及最终一致性，目前MongoDB的三节点都是复用的这种模式。之前概要性地介绍了ApsaraDB，接下来从服务管理层面为大家介绍与自建数据库相比，ApsaraDB的优势所在。首先，对于服务可用性而言，阿里云的数据库提供主备架构、同城容灾和异地容灾模式，可以在半天之内将流量切换到备节点，并且不影响业务，还支持直接在控制台上点击主备切换来演习故障发生时的情况。如果自建数据库，则需要在自己的ECS上去考虑如何处理服务可用性以及在宕机时如何进行切流量的问题。对于数据可靠性而言，阿里云提供的数据库通过本地RAID5实现了在线存储冗余，而ECS采用的是高效云盘+SSD云盘，所以在本地存储方面两种方案是差不多的。在离线长效备份方面，阿里云ApsaraDB支持一键式将文件存储到OSS上并且可以存储延长至两年，而ECS自建数据库时则需要自己写OSS脚本来上传数据。第三方面就是按时间点恢复，就是当出现开发的误操作或者删除了一个表格之后，需要将数据恢复到误操作前一秒的状态，其实ApsaraDB支持将增量日志和AOF日志等全部存储到OSS上。在控制台发起操作之后，后台就会将备份文件以及增量日志在一个新的时序上恢复起来，数据就能够直接回滚回来。在数据复制方面，ApsaraDB支持异步+半复制的方式，则使用ECS自建数据库则需要自己进行配置。在数据安全性部分，目前ApsaraDB支持白名单分组，而ECS则是支持安全组，在未来四、五月份的时候数据库团队就会将白名单分组取消，并将其和ECS安全组融合起来，解决目前客户在使用时的体验较差的问题。在审计日志方面，ApsaraDB会依靠内部的系统将SQL的审计日志收集起来并且存储到远端的存储中，用户可以定期地将SQL审计日志拉到本地进行查看，而且这个系统对于整体的性能损耗并不大，但是可以实现有踪可查，当发生问题的时候，就可以知道到底是谁发动了攻击，以及时间点、所使用的IP以及进行的操作。在网络加密和存储加密方面，阿里云数据库也处于比较领先的位置，ApsaraDB经过数据库的的等级认证，目前已经支持了SSL网络加密以及TDE存储加密。如果选择了TDE存储加密，即使数据被拖走对方在没有密匙的情况下也无法解析自己的数据，这部分在金融行业里也是要求非常严格的。在监控与报警部分，阿里云数据库支持资源类的监控，也就是对于实例的CPU、内存、磁盘等的资源进行监控，还有就是引擎层面的监控，对于MySQL、Redis以及MongoDB等引擎层面的监控。在数据库引擎层面存在很多可以监控的指标，这些都可以通过图形化的方式展现给用户。在秒级监控部分，ApsaraDB支持300s和60s的监控模式，后续还可能对于像缓存等业务实现更细的粒度。并且ApsaraDB支持云监控的报警，对于数据库的监控指标而言，当发现这些指标出现异常时可以通过云监控直接向运维人员的手机或者邮箱发送报警信息。在参数管理部分，ApsaraDB可以在数据库运维层面为用户提供参数模板和修改历史以及开销的分析。在性能优化部分，阿里云数据库会为用户提供一套系统来帮助用户审查所有的SQL日志，并对于日志进行相应的去重分析来判断对于SQL应该加什么样的索引以及对于某张表应该如何处理给出相应的建议。而一站式服务就是对于阿里云数据库整体的生态提供的工具。阿里云数据库提供了数据管理的工具，大家使用MySQL可能知道有Navicat等，在ECS上自建数据库时可以装上这样的工具，但是对于像MongoDB以及Redis这样的数据库，可视化的数据库管理工具却是很少的，现在的DMS可视化操作工具已经和阿里云数据库完全结合，可以支持SQLServer、PG、MySQL、MemCache、Redis以及MongoDB等所有的引擎，购买了阿里云的这些数据库之后就可以直接以图形化的方式进行管理了。而对于数据同步方面，对于如何轻松地将Hadoop中的数据同步到MongoDB中，或者对于两个同构的数据库如何进行数据同步以及如何实现增量同步的同时不影响业务而言，阿里云的整个数据同步工具是非常健全的，首先对于云上云下的同构的数据库同步来说，阿里云数据库都是支持全量+增量的，比如用户在ECS上有MySQL和MongoDB数据库，就可以直接选择DPS实现全量和增量的数据同步，目前对于异构数据库而言也是支持Oracle到PPAS的。数据同步这部分也是在迅速地发展，后续也会加更多的引擎进来，将会实现更多的数据库的异构同步来打通数据库的整体生态。数据安全下图展现了阿里云数据库可以从几个维度帮助用户构建事前、事中和事后的安全防范措施。在事前阿里云数据库会使用VPC专有网络形成隔离的网络环境，另外还会要求用户设置精细粒度的白名单，而且所有的数据库都是要求强密码认证的。在比如像MongoDB的黑天事件中，其实根源在于用户将自己的MongoDB的IP地址暴露于公网之上，直接导致黑客有了入侵的机会，所以阿里云对于NoSQL的数据库都需要强制用户设置强密码，并且不会暴露公网IP供外网调用，保证数据库处于一个相对比较安全的网络环境内。在事中还会使用SSL的网络加密以及TDE的数据加密。在事后的防范中还使用了一整套详细的审计日志，当真正发生了问题之后可以将审计日志调出来查看谁在什么时间点对于数据库进行了什么操作。除此之外，最后还有一套克隆实例保证数据库能够实现数据秒级恢复。监控报警下图介绍的是阿里云数据库的监控报警能力，目前阿里云RDS正在打造一套整体中台，也就是内部的“天象”的指挥端的系统，这个系统能够帮助用户将流量从ECS上直接打通到RDS上去的所有网络延迟监控下来并展现给用户，使得用户能够了解RDS或者MongoDB在一定时间内的压力负载究竟在哪，知道QPS反应比较慢的时候究竟卡在哪个链路上，到底是ECS出网口的问题、ECS到RDS链路的问题还是RDS引擎层面的问题，这些都会通过链路的监控图展示给用户。性能优化对于阿里云数据库的性能优化部分，可以分为如下图所示的资源分析、引擎分析、SQL分析以及专家系统这四大部分。异地容灾解决方案第一个是在云上实现异地容灾的解决方案，比如在金融行业会需要考虑的一个可用区出现问题的场景下衍生出的服务就是异地容灾，可能数据库的主可用区在上海，而备可用区在深圳，当上海这个主可用区出现两个机房都瘫痪或者城市发生了电力故障不能提供服务的时候，都可以通过一定容灾模式保证服务的。而异地容灾的架构是需要所有的阿里云产品进行配合的，但其中最难做并且最重要的还是数据库。其实没有数据的部分是很好做容灾的，但是一旦涉及到数据就会很难实现。如上图中的解决方案所示，其支持的是两地四中心的概念，两个节点在不同的可用区之内，两个节点之间通过原生复制的方式实现数据同步，而自己搭建数据库时异地复制就会出现困难，如何保证数据能够追上并且RPO和PTO处于合理范围之内都是难点。混合云解决方案对于混合云的解决方案而言，其实实现混合云架构的难点还是在数据库，只要在有数据的地方实现多中心的同步都会比较困难。如上图的架构中左边所示就是如何将云下机房和云上机房进行数据互通和同步，而右边则是如何将阿里云上的数据同步到云下，这个场景都是真实存在于很多的金融场景中的，金融行业可能以云上作为备份、云下为主，还有一些新兴的金融行业因为其业务是依靠云发展起来的，而又因为需要合规所以需要将数据备份到云下，所以采用了云上做主、云下做备的方式。这套混合云解决方案还是依赖于整体的同步机制，云下到云上的的同步可以直接拽一个backup上去存储到对端之后，再通过增量数据将两部分数据一直挂同步和同载实现云上和云下的同步。而云上到云下的同步就是会将MySQL的Binlog或者MongoDB的OPlog直接开放权限给DTS服务，将数据通过通道传输到远端的自建数据库中，从而完成混合云的架构。快速部署解决方案上图展现的是一个快速部署的场景。快速恢复的功能支持整体的克隆实例，可以基于备份文件将数据整体克隆出来，并进行快速部署。而Flashback功能是阿里云数据库团队的彭立勋开发的，目前已经整合到MariaDB版本中并成为了其中核心的功能，这个功能主要就是抓起Binlog文件。因为平时做数据恢复时需要保证一个全量的备份，而Flashback的开发直接将Binlog的数据收集到里面，保证在很短的时间之内能够将数据恢复出来。对于Flashback功能感兴趣的同学可以到网上进行详细了解。实时计算解决方案最后的场景展现的实时计算的解决方案，目前很多业务都要求LTP和LAP两套机制。本身的一套数据库系统可能是实现LTP的，也就是正常的增删改查，还有一套系统需要将数据拉回来做LAP和分析，常规都是有一套LAP的数据库每天定时将LTP的数据直接同步到LAP中，而这个同步也是非常痛苦的。实时计算的解决方案希望在一套架构中为用户解决LAP和LTP的问题。阿里云的PetaData产品目前正处于邀测阶段，预期会在三月底进行商业化，PetaData能够通过一套存储机制帮助用户解决LAP和LTP的问题，大家有兴趣可以关注一下。
本文仅代表作者观点，不代表百度立场。系作者授权百家号发表，未经许可不得转载。
互联网变化快
百家号 最近更新：
简介: 全球军事形势高峰军事关注
作者最新文章