关于数据存储:如何选择-Web-的数据存储方式看我就够了

1. 前言为了最大限度地保障同一浏览器同一域名下各个网页的用户对立,Web JS SDK 须要及时地将用户标识存入到 Cookie; 为了最大限度地缩小敞开页面导致的数据失落,Web JS SDK 将采集的数据存入到 localStorage 里进行批量发送,敞开页面未发送完的数据下次关上页面再次发送; 为了最大限度地保障可视化全埋点和网页热力求窗口关上的正确性,Web JS SDK 将相干的标识存入到 sessionStorage 里。 由此可见,存储数据是 Web JS SDK 的外围性能,上面逐个给大家介绍这三种存储形式。 2. 存储形式2.1. CookieCookie 实际上是一小段的文本信息(key-value 格局)。客户端向服务端发动申请,如果服务端须要记录该用户的状态,就应用 response 向客户端浏览器颁发一个 Cookie。如图 2-1 所示: 图 2-1 服务端应用 response 向客户端浏览器颁发一个 Cookie 客户端浏览器会把 Cookie 保存起来,当浏览器再次申请该网站时,浏览器把申请的网址连同 Cookie 一起提交给服务端。服务端查看该 Cookie,以此来识别用户状态。如图 2-2 所示: 图 2-2 浏览器把 Cookie 提交给服务端 Web JS SDK 中应用 Cookie 性能次要是用来存储前端变量。每当同一台设施通过浏览器申请集成 Web JS SDK 的页面时,就会读取曾经保留的 Cookie 值。 2.2. localStoragelocalStorage 用于长久化的本地存储,没有过期工夫。除非被动删除数据,否则数据是永远不会过期的。 ...

October 15, 2021 · 5 min · jiezi

关于数据存储:OceanBase时序数据库CeresDB正式商用-为用户提供安全可靠的数据存储管理服务

简介: OceanBase实现OLAP和OLTP双重能力并行后,向数据管理畛域多模方向迈出第一步。 近日,在数据库OceanBase3.0峰会上,OceanBase CEO杨冰发表首个时序数据库产品CeresDB正式商用。该数据库将为用户提供安全可靠的数据查问和存储管理服务,解决监控运维、物联网等场景中,工夫序列数据的高吞吐、横向扩大等难题。 这是OceanBase实现OLAP和OLTP双重能力并行后,向数据管理畛域多模方向迈出的第一步。 时序数据库全称为工夫序列数据库,次要用于治理和存储工夫序列数据(反映事物随工夫变动而变动的过程),其中物联网、工业物联网、监控运维等是时序数据常见的利用场景。而时序数据库可能解决这些物联网设施数据的高吞吐、高频次的写入存储需要。 此次公布的OceanBase 时序数据库(CeresDB),是基于 OceanBase 分布式存储引擎底座的时序数据库产品,用来治理和存储工夫序列数据,提供高性能读写、低成本存储、丰盛的多维查问和剖析能力等性能。无效解决海量规模时序数据的存储老本高,读写效率低的问题,同时具备程度扩大和异地容灾的能力,实用于物联网 IoT、运维监控、金融剖析等行业场景。 此外,CeresDB 在时序数据上采纳业界当先的时序压缩算法,做到了对实时数据靠近10倍的压缩率(无损压缩),并通过设计创新性的多层存储计划,别离实现了纯内存、非易失内存、磁盘以及近程存储的多级存储架构,为客户提供灵便的、高度可伸缩的部署架构计划。 “时序数据库CeresDB具备有限程度扩大和异地容灾的能力” OceanBase CEO杨冰示意,“将来,咱们将朝着时序HTAP交融以及schema less的方向继续演进,并提供更加丰盛的行业专属算子和算法能力,并联结生态搭档提供对应的行业解决方案,帮忙企业打造具备极致性能和丰盛多样的行业时序数据管理解决方案。” 据悉,OceanBase是蚂蚁自主研发的分布式数据库,经验过阿里超大规模业务场景、支付宝金融级场景以及双11等战斗的历练,并于2017年开始对外输入。目前该产品已在多家机构落地利用,包含中国工商银行、山东挪动、福建挪动、数字江西、中国石化、中华财险、人保衰弱、浙商证券、天津银行、西安银行、常熟农商行、东莞银行等。 11年倒退,OceanBase曾经成为世界领先的数据库产品。2019年和2020年间断刷新事务处理工作(TPC-C)基准测试世界纪录。 原文链接本文为阿里云原创内容,未经容许不得转载。

June 29, 2021 · 1 min · jiezi

关于数据存储:COSBrowser文件编辑-随时随地在线编辑

本文介绍如何通过 COSBrowser 文件在线编辑性能更不便的应用云上存储的数据。 痛点剖析日常工作和生存中,咱们须要把记录的文档、编写的文案、音视频文件保留治理好,又放心设施损坏、文件失落或是更换设施后没有备份,几年前咱们会将文件存入 U 盘,现在上云轻而易举,咱们会把文件上传至云端保留。 尽管曾经解决了很多问题,咱们的文件得以在云上备份,但仍然有不不便的时候。 1. 文档更新 有些文档须要更新,这时候要从网盘下载下来,本地批改完之后将新的文件上传笼罩。若是没有同步性能,还得每次批改完手动上传--麻烦。 2. 版本治理 经验过写毕业论文的咱们都晓得版本治理的痛,咱们认为的最终版.doc 通过导师的点评最终都会变成最终版_1.doc、最终版_1.1.doc 等,有些时候版本治理没有做好,想回退时却不晓得从何做起--苦楚。 当初,COSBrowser 能够给你另一种抉择,无需下载,随时随地,云端文件在线编辑,让你做到"save once,run anywhere"。 性能介绍COSBrowser文件在线编辑反对 txt、html、css、js、ts、c、c++、md 等等超20种常见语言类型;反对 UTF-8、GBK 等罕用编码格局的关上与转换;主动版本治理。性能入口首先抉择存储桶,进入文件列表页,而后有以下两种形式进入编辑(PC 和 web 入口雷同)。 1)双击文件所在行的非按钮区域; 2)右键文件-编辑; 性能操作如下: 历史版本治理 COSBrowser-PC 端历史版本存在本地硬盘,能够间接关上查看。 COSBrowser-web 版历史版本存在远端,须要下载查看。 入门玩法在线更新文档 记录本人的日常工作总结、记录工作中遇到的问题、知识点、踩过的坑,通过不定期的更新,一方面能够欠缺成本人的知识库,当前遇到问题能够拿进去翻阅;另一方面搭配 COSBrowser 分享性能,能够将积淀的文档拿进去与身边共事分享。 举个例子,将平时工作中遇到的问题或是解决问题的过程记录下来,定期回顾。 能够不断更新,写完之后 Ctrl+s 键保留--难受,无论什么时候从 COSBrowser 关上,都是最新批改的版本。 进阶操作构建动态网站或博客 应用 COSBrowser 编辑器模式疾速构建动态网站或博客,目前只反对网页版。 新建一个存储桶,为了做动态网站用,拜访权限抉择私有读公有写;进入存储桶内,从上方菜单栏进入编辑器模式;在文件列表页或间接在编辑器模式中右键新建index.html;编辑 index.html 内容,Ctrl+s 键保留;从右上角开启动态网站;拜访动态网站节点即可查看成果;增加少许布局和适量 css 款式,一个动态网站就初步造成了;PS:为了贴合开发者习惯,编辑器模式中的文件列表以目录树模式展现。 欢送体验COSBrowser 客户端COSBrowser 网页版结语COSBrowser 文件编辑虽远不如 sublime text、vscode 等编辑器那么业余,但罕用文档格局的反对也会带来一丝便当;不用放心云端批改会造成凌乱,编辑历史会在本地/远端留存;当初应用 web 技术配合 COSBrowser 能够更快更不便地构建起动态网站。 ...

June 25, 2021 · 1 min · jiezi

关于数据存储:物联网海量时序数据存储有哪些挑战

简介: 随着 IoT 技术的疾速倒退,物联网设施产生的数据呈爆炸式增长,数据的总量(Volume)、数据类型越来越多(Variety)、访问速度要求越来越快(Velocity)、对数据价值(Value)的开掘越来越器重。物联网产生的数据通常都具备工夫序列特色,时序数据库是以后针对物联网 IoT、工业互联网 IIoT、利用性能监控 APM 场景等垂直畛域定制的数据库解决方案,本文次要剖析物联网场景海量时序数据存储与解决的关键技术挑战及解决方案。 作者 | 林青起源 | 阿里技术公众号 随着 IoT 技术的疾速倒退,物联网设施产生的数据呈爆炸式增长,数据的总量(Volume)、数据类型越来越多(Variety)、访问速度要求越来越快(Velocity)、对数据价值(Value)的开掘越来越器重。物联网产生的数据通常都具备工夫序列特色,时序数据库是以后针对物联网 IoT、工业互联网 IIoT、利用性能监控 APM 场景等垂直畛域定制的数据库解决方案,本文次要剖析物联网场景海量时序数据存储与解决的关键技术挑战及解决方案。 一 时序数据存储挑战1 典型时序利用场景随着 5G/IoT 技术的倒退,数据呈爆炸式增长,其中物联网 (IoT) 与利用性能监控 (APM) 等是时序数据最典型的应用领域,覆盖物联网、车联网、智能家居、工业互联网、利用性能监控等常见的利用场景,海量的设施继续产生运行时指标数据,对数据的读写、存储管理都提出了很大的挑战。 2 时序数据的特色在典型的物联网、APM 时序数据场景里,数据的产生、拜访都有比拟显著的法则,有很多独特的特色,相比以后互联网典型的利用特色有比拟大的区别。 数据按工夫程序产生,肯定带有工夫戳,海量的物联网设施或者被监控到应用程序,按固定的周期或特定条件触发,继续一直的产生新的时序数据。数据是绝对结构化的,一个设施或利用,产生的指标个别以数值类型(绝大部分)、字符类型为主,并且在运行过程中,指标的数量绝对固定,只有模型变更、业务降级时才会新增/缩小/变更指标。写多读少,极少有更新操作,无需事务能力反对,在互联网利用场景里,数据写入后,往往会被屡次拜访,比方典型的社交、电商场景都是如此;而在物联网、APM 场景,数据产生存储后,往往在须要做数据经营剖析、监控报表、问题排查时才会去读取拜访。按时间段批量拜访数据,用户次要关注同一个或同一类类设施在一段时间内的拜访趋势,比方某个智能空调在过来1小时的平均温度,某个集群所有实例总的拜访 QPS 等,须要反对对间断的时间段数据进行罕用的计算,比方求和、计数、最大值、最小值、平均值等其余数学函数计算。近期数据的拜访远高于历史数据,拜访法则显著,历史数据的价值随工夫一直升高,为节省成本,通常只须要保留最近一段时间如三个月、半年的数据,须要反对高效的数据 TTL 机制,能主动批量删除历史数据,最小化对失常写入的影响。数据存储量大,冷热特色显著,因而对存储老本要求比拟高,须要有针对性的存储解决方案。联合时序的特色,要满足大规模时序数据存储需要,至多面临如下的几个外围挑战: 高并发的写入吞吐:在一些大规模的利用性能监控、物联网场景,海量的设施继续产生时序数据,例如某省域电网用电测量数据,9000万的电表设施,原来每个月采集一次,后续业务降级后15分钟采集一次,每秒的时序数据点数达到数百万甚至千万工夫点,须要数十到上百台机器的集群规模来撑持全量的业务写入;时序数据存储须要解决大规模集群的横向扩大,高性能安稳写入的需要。高效的时序数据查问剖析:在典型的监控场景,通常须要对长周期的数据进行查问剖析,比方针对某些指标最近1天、3天、7天、1个月的趋势剖析、报表等;而在物联网场景,有一类比拟典型的断面查问需要,例如查问某个省指定工夫所有电表的用电量量明细数据,查问某个品牌空调的某个工夫的均匀运行温度;这些查问都须要扫描大量的集群数据能力拿到后果,同时查问的后果集也可能十分大;时序数据存储须要反对多维工夫线检索、并具备流式解决、预计算等能力,能力满足大规模 APM、IoT 业务场景的典型查问需要,并且针对时序大查问要最小化对写入的影响。低成本的时序数据存储:某典型的车联网场景,仅20000辆车每小时就产生近百GB的车辆指标数据,如果要保留一年的运行数据就须要PB级的数据存储规模;因为数据规模微小,对存储的低成本要求很高,另外时序数据的冷热特色显著。时序数据存储须要充分利用好时序数据量大、冷热拜访特色显著、做好计算、存储资源的解耦,通过低成本存储介质、压缩编码、冷热拆散、高效 TTL、Servereless 等技术将数据存储老本升高到极致。简略便捷的生态协同:在物联网、工业互联网等场景,时序数据通常有进一步做经营剖析解决的需要,在很多状况下时序数据只是业务数据的一部分,须要与其余类型的数据组合来实现查问剖析;时序数据存储须要能与生态 BI 剖析工具、大数据处理、流式剖析零碎等做好对接,与周边生态造成协同来发明业务价值。 为了应答海量时序数据的存储与解决的挑战,从2014年开始,陆续有针对时序数据存储设计的数据库诞生,并且时序数据库的增长趋势继续当先,时序数据库联合时序数据的特色,尝试解决时序数据存储在高写入吞吐、横向扩大、低成本存储、数据批量过期、高效检索、简略拜访与时序数据计算等方面面临的挑战。 3 业界时序数据库倒退时序数据库通过近些年的倒退,大抵经验了几个阶段: 第一阶段,以解决监控类业务需要为主,采纳工夫程序组织数据,不便对数据按工夫周期存储及检索,解决关系型数据库存储时序数据的局部痛点,典型的代表包含 RDDTool、Wishper(Graphite)等,这类零碎解决的数据模型比拟繁多,单机容量受限,并且通常内嵌于监控告警解决方案。第二阶段,随同大数据和Hadoop生态的倒退,时序数据量开始迅速增长,业务对于时序数据存储解决扩展性方面提出更高的要求。基于通用可扩大的分布式存储专门构建的工夫序列数据库开始呈现,典型的代表包含 OpenTSDB(底层应用 HBase)、KairosDB(底层应用 Cassandra)等,利用底层分布式存储可扩大的劣势,在 KV 模型上构建定制的时序模型,反对海量时序的倒排检索与存储能力。这类数据库的数据存储实质依然是通用的 KV 存储,在时序数据的检索、存储压缩效率上都无奈做到极致,在时序数据的解决反对上也绝对较弱。第三阶段,随着 Docker、Kubernetes、微服务、IoT 等技术的倒退,工夫序列数据成为增长最快的数据类型之一,针对时序数据高性能、低成本的存储需要日益旺盛,针对时序数据定制存储的数据库开始呈现,典型的以InfluxDB 为代表,InfluxDB 的 TSM 存储引擎针对时序数据定制,反对海量工夫线的检索能力,同时针对时序数据进行压缩升高存储老本,并反对大量面向时序的窗口计算函数,InfluxDB 目前也是 DB Engine Rank 排名第一的时序数据库。InfluxDB 仅开源了单机版本,高可用集群版仅在企业版和云服务的版本里提供。第四阶段,随着云计算的高速倒退,云上时序数据库服务逐渐诞生,阿里云早在2017年就推出了 TSDB 云服务,随后 Amazon、Azure 推出 Amazon TimeStream、Azure Timeseires Insight 服务,InfluxData 也逐渐往云上转型,推出 InfluxDB 云服务;时序数据库云服务能够与云上其余的基础设施造成更好的协同,云数据库已是不可逆的发展趋势。二 Lindorm TSDB 背地的技术思考1 Lindorm 云原生多模数据库为了迎接 5g/IoT 时代的数据存储挑战,阿里云推出云原生多模数据库 Lindorm ,致力于解决海量多类型低成本存储与解决问题,让海量数据存得起、看得见。 ...

May 17, 2021 · 2 min · jiezi

关于数据存储:数据湖已成为海量数据存储与分析的重要承载方式

简介: 在云计算和大数据时代,基于数据发展生产、经营、决策成为常态,依据Gartner报道,2019年数据基建方面的洽购费用飙升到660亿美元,占据基础架构类软件费用的24%。数据的存储及利用体系是企业生态运行的中枢神经,数据湖曾经成为海量数据存储与剖析的重要承载形式。 在汹涌而至的信息化浪潮下,大数据技术不断更新迭代,数据管理工具失去飞速发展,相干概念也随之而生。数据湖(Data Lake)概念自2011年被推出后,其概念定位、架构设计和相干技术都失去了飞速发展和泛滥实际,数据湖也从繁多数据存储池概念演进为撑持高效、平安、稳固企业级数据利用的下一代根底数据平台。 此次公布的《数据湖利用实际白皮书》涵盖了数据湖的定义与架构、数据湖外围组件与计划介绍、数据湖构建计划、利用实际等内容,心愿为用户提供新的洞察。 通过浏览本书,包含开发者、IT运维人员、企业数字化管理者等能够全面理解阿里云基于云原生技术的企业级数据湖解决方案和相干产品,也能清晰传统数据仓库和数据湖的差别。  在云计算和大数据时代,基于数据发展生产、经营、决策成为常态,依据Gartner报道,2019年数据基建方面的洽购费用飙升到660亿美元,占据基础架构类软件费用的24%。数据的存储及利用体系是企业生态运行的中枢神经,数据湖曾经成为海量数据存储与剖析的重要承载形式。 市场调研机构Research and Markets公布的报告显示,2020年,寰球数据湖市场的价值为37.4亿美元,预计到2026年将达到176亿美元,在2021年至2026年的预测期间的复合年增长率为29.9%。 云原生时代的到来,引领数据湖进入了“云湖共生”新的阶段。在此背景下,阿里云推出基于云原生技术的企业级数据湖解决方案,该计划采纳了存储计算拆散架构,存储层基于阿里云对象存储OSS构建,并与阿里云数据湖剖析(Data Lake Analytics 简称 DLA)、数据湖构建(Data Lake Formation简称 DLF)、E-MapReduce(简称EMR)、DataWorks(简称DW)等计算引擎无缝对接,且兼容丰盛的开源计算引擎生态。 十年形迹十年心,联合先进的数据迷信与机器学习技术,数据湖还能为企业提供预测剖析,帮忙企业构建、优化训练模型等。心愿这本白皮书能够为企业和组织的数字化转型实际提供指引,为相干畛域的业务决策者与实践者提供面向行业利用场景的重要参考。 原文链接本文为阿里云原创内容,未经容许不得转载。

March 26, 2021 · 1 min · jiezi

关于数据存储:在线公开课-在数据爆炸的当下教你设计一个能实现9个9数据可靠性的存储系统

据 IDC 公布的《数据时代 2025》白皮书预测:在 2025 年,寰球数据量将达到前所未有的 163ZB。随着网络倒退速度越来越快,数据的产生量正在呈指数级回升,企业面临的数据压力也在一直减少,数据可靠性差、存储的容量和性能有余等数据问题层出不穷。如何在管制老本的状况下将数据可靠性最大化?有什么工具能解决存储的容量和性能有余的问题呢?基于此,在 9 月 9 日,京东智联云和英特尔联结举办了「高牢靠存储系统的设计实际」线上公开课,来自京东智联云云产品研发部资深架构师崔灿,和来自英特尔中国区资深存储架构师宫兴斌,别离介绍了京东的高牢靠存储系统的设计与英特尔傲腾如何助力京东智联云缓解数据压力的。以下内容整顿自两位老师的分享。 维持数据高牢靠面临的挑战与应答数据可靠性,是数据存储系统底线个别的存在,不同于数据可用性的可修复,数据一旦失去可靠性便代表着数据的永久性失落,且无奈以任何模式找回。所以放弃数据系统的高可靠性也是各大企业正在钻研的课题。然而要维持数据高可靠性也面临着很多挑战,对此崔灿老师示意,次要挑战有两个,其中首当其冲的就是正本问题,蕴含数据正本数量的管制,即保障需要的状况下,容忍故障的正本数量管制,以及正本数据损坏率。而导致正本数据损坏的起因次要有三个: 硬件故障导致数据损坏,即磁盘、磁头和网络传输等问题导致的损坏;程序 Bug,即数据的写入和存储程序 bug 导致数据谬误或者失落;运维操作,即用户或者运维人员的操作失误,导致数据被误删。除了正本问题之外,磁盘的故障是不可避免的。此时,就须要能及时地检测出故障并且用其余的失常副原本修复受损的正本数据,然而磁盘的理论故障工夫和被检测进去的工夫是存在时间差的。当时间差过长时,就可能会呈现正本数据全副损坏,数据齐全失落的状况。所以缩短时间差也是保证数据可靠性必不可少的路径。这些问题该如何解决呢?先说正本问题,在此之前先引入一个概念—冗余,冗余常见的模式分为两种: 第一种是复制,如 RAID、三正本、EC 等其本质都是复制,它和咱们在线的业务零碎是绑定在一起的,其特点为复制的数据能够实现在线实时的进行写入和读取;第二种是备份,它是和生产的零碎是隔离的,与复制不同的是备份会把所有的操作、所有的数据全副记录下来,在数据恢复时能够复原到任何一个工夫点的状态。通过备份的模式能够缩小因为操作失误带来的损失。不过备份也存在一个问题,就是其读取和复原速度都特地慢,动辄就好几个小时,工夫老本较高。所以在面对正本问题时,能够依据状况进行多正本的复制或者备份来缩小因为运维操作、硬件故障等正本问题导致的可靠性升高的状况。当然,通过备份和多正本形式能解决的问题还是无限的,所以升高探测和修复故障的工夫,是维持高牢靠的另外一种形式。在检测时间的升高方面,个别有两个措施: 通过 CRC 的校验来检测数据是否故障:数据从客户端,到网络和磁盘,都可能是蕴含同一个 CRC 的,所以在网络或者磁盘呈现故障时,就能通过 CRC 就能疾速的去发现这个故障。定期的对数据做校验:包含本地数据或者是多个正本之间数据的一致性校验。除此之外还须要对数据进行正确性的抽查,因为数据存在磁盘上,忽然坏掉的概率是绝对比拟低的,然而新写入的数据,呈现故障的概率是比拟高的,通过抽查能够防止新写入数据的故障。检测之后就波及到修复,修复个别波及到两个方面: 疾速复原,次要针对在零碎上的故障,这就须要更多的磁盘和带宽去修复它。软删除,针对一些运维或者其他人的误操作以及咱们零碎之间的 bug 导致的数据故障,通过软删除机制来找回数据,当遇到数据误删操作时,零碎会把数据放在回收站,须要的时候能够间接进行数据拉回。如上所说的都是理论知识,从实践上来看,减少可靠性其实是非常简单的一件事件。进步冗余、用大磁盘和高带宽进行磁盘修复、买更好的磁盘缩小磁盘故障率,都能减少可靠性,然而这些都有老本,自觉的通过购买晋升可靠性,会导致可靠性的老本不可控,那么如何去找到这个平衡点呢?这就是接下来要和大家探讨的事件。 京东高牢靠存储系统设计解析 1、分类存储数据,定制化高牢靠计划面对如何找到平衡点这个问题,崔灿示意外围办法是针对不同的数据类型,不同的业务类型去为它定制正当的一个可靠性的计划,通过这样来达到可靠性和老本的均衡,先来说数据的分类: 一般来说,可靠性都具备一个特点,即数据更新的越频繁,保障可靠性,须要花的代价就越大,所以京东会将数据进行分类,如上图所示第一类是低频更新的数据,如对象存储的数据,这些数据个别具备数量大,更新少的特点。 第二类数据是一些绝对更新比拟频繁的数据,如云硬盘的热数据。这些数据量绝对少,且对性能的要求比拟高,所以针对这些数据,老本曾经不是最外围的点了。 第三类数据是元数据,元数据的特点是十分重要,然而个别它的量相对来说比拟小,所以此时须要尽最大的可能性保障它可靠性,而不去管老本。在对元数据时,会用一些类多正本、备份以及上述所说的一些机制来保障可靠性。 2、对不同数据的存储架构设计以及优化措施 针对不同的数据京东的解决逻辑,如图能够看到京东智联云存储的架构,整体是分成三层,最上层为 Blob 存储,来存储京东的绝大部分数据,也是老本产生最多的中央,其所有数据都是三正本或者是 EC 的模式。在两头的为元数据的存储,数量少然而十分重要。在这两类数据之上,就是业务数据,目前京东智联云的存储业务有对象存储、文件存储,块存储等。下文会重点介绍 Blob 存储,也是京东智联云解决可靠性问题的外围。Blob 存储的设计指标,首先是在反对超大的容量的同时,放弃超低的老本。其次是反对高可用和高牢靠。它有几个设计要点,第一,应用 AppendOnly 零碎,不存在批改,数据存在即可判断正确;第二,由后端抉择写入地位,保障复制组不会有提早大的正本;第三,做大的集群规模。 接下来从数据的复制和检测修复这两方面介绍京东智联云的优化策略。先看数据的复制,整个零碎的数据复制采纳三正本的模式,是在管制老本的状况下,能满足可靠性的最低要求,且在数据写入时,设置两正本写入即胜利。因为在一个大的集群中,局部结点会遇到重启,或者是保护之类的状况,会导致它的写入失败。在复制组的抉择上,会抉择大小在 50 到 100GB 的复制组,范畴的制订的下限是取决于修复工夫,其上限是取决于集群做大的策略。在下限制订上,一个 100 个 GB 的复制组,如果是以 60MB 的速度修复,大略半个小时就能修复完了,而过大的复制组会导致修复工夫变长,影响业务。复制组的上限如何计算呢,以理论为例,单盘大略 20T 一个集群,如果是 16000 块盘,就是一个常见的 320P 的物理空间,100P 逻辑空间的一个集群,如果整个集群中有 5% 的盘提供修复,相当于 800 块盘提供修复,每一个正本的修复须要两个盘撑持,通过这个计算能并行修复的正本的数量。个别并行修复的正本数量,应该和单机正本和单盘的正本数量是统一的,这也是达到一个最高的修复,依据这个算法,针对京东智联云一个有 20T 的盘,100P 的集群的零碎,它的复制组应该是在 50G。再说修复工夫优化,京东智联云做了三个措施,首先,也是最重要的,即让零碎能容忍两个正本故障,怎么做到的呢?首先其写入是靠服务端来抉择,通过这样的形式保障所有的复制组基本上都是三正本且不会有 delay,而规范的写入是做不到这些的。并且在写入的地位的抉择上,会思考到三个正本之间的提早,能够躲避有 delay 的复制组,保障两正本数据的周期很短。其次,京东智联云用到了 60MB 的 IO 来做修复,让参加修复的磁盘能够占用大量 IO,使其在能够容忍局部盘慢的状况,保障整体速度,并在数据读取和写入方面进行了优化。最初在整个零碎的设计中,通过拆分复制组的治理,将治理放到一系列的 Allotter 的服务里,能够实现复制组的数量能够不受限的往上减少。上文全面介绍了多机的复制修复,接下来简略说下针对单机修复的措施,次要有三点:第一,DataNode 外部 CRC 校验,当实践上数据和 CRC 实践上不统一时,意味着磁盘上呈现了一些故障;第二,例行后盾一致性校验,疾速发现数据损坏和导致数据损坏的 Bug;第三,业务上的统一的校验,如 Block 的数据和 Block 元数据之间的一致性的校验。以上就是京东智联云在 Blob 零碎中做的一些扭转、优化措施,这也是京东智联云高牢靠存储系统的外围局部,接下来简略的解说下 Meta 可靠性计划和云硬盘的可靠性计划。 ...

October 10, 2020 · 1 min · jiezi

关于数据存储:企业云盘高效办公

Yotta企业云盘数据存储的新体验。 在网络设施不断完善的推动下,各行各业的企业对高效办公的需要变得更加迫切。 例如,在兼顾便利性和安全性的同时,如何无效地利用扩散的文件和材料来实现高效的集中式存储和治理合作,这就是如何在企业外部实现无纸化办公并迎接新时代的挑战。 平安的区块链存储环境:应用程序和存储在整个过程中都通过加密,以确保用户数据的私密性和安全性。 同时,该零碎基于“零信赖”准则进行设计,以确保即便购买了后端管理员之类的所有人,用户数据依然放弃平安。 无效整合零散信息资源:对立存储和治理零散终端的存储数据,并提供残缺的文件搜寻性能。 应用涣散耦合的目录构造和组织构造,以防止不必要的单位/组织占用空间。 不便易用的体验:提供Web,PC,ios,Android和其余拜访办法,以适应各种办公场景。 反对在线文件预览和编辑,以确保您能够随时随地查看文件或搜寻文档的历史版本,还能够通过内部链接共享文档。 低成本,高度牢靠的服务能力:应用扩散的区块链存储办法能够提供高度牢靠和可扩大的服务。 同时,自主研发的加密反复数据删除技术可将存储空间占用缩小5-10倍,开释反复占用的空间,升高企业的存储老本。 Yotta Enterprise Cloud Disk企业文件合作和治理收据的云存储提供企业级数据存储,治理和业务合作解决方案,以帮忙企业实现有限文件存储,集中管理,高效共享和平安合作,不便的挪动办公以及大型改良工作 效率。

August 27, 2020 · 1 min · jiezi

618-Tech-Talk400存储容量增长背后的成长之路

云妹导读: 2020 年的京东 618 大促期间,京东智联云对象存储容量新增同比增长400%,流量同比上涨200%,对象存储服务稳定,完美完成了大促重保任务,为此次京东 618 大促累计下单金额超2692亿元的新纪录提供了坚实的保障。“我的系统现在运行的挺好的,迁移到云上需要花费一定的人力还会带来一定的风险,我为什么要迁移到云上面呢?” 这是京东在推动集团各个业务“上云”时总会被问到的一个问题。相信,这也是很多企业在选择业务迁移“上云”时不断问自己的一个问题。 经过17年的发展,京东618不断跨上一个个新的台阶,而海量用户的浏览和海量订单的产生和交付,对后端的支撑系统提出了极高的要求。京东智联云作为作为支撑京东618的重要技术中台,要面临数百亿访问流量、每秒数百万次的高并发请求,以及数十亿的实时消息推送,保证全天核心服务不降级、无重大事故,这一切都对京东智联云带来了极大的挑战。 对象存储作为京东智联云重要的产品之一,在这次618中也起到了及其重要的作用。作为在线服务,京东智联云对象存储不仅为视频、直播等重要数据等存储和下载提供服务支持,同时也为离线计算平台提供存储支持,可以说是京东618大促的核心依赖,对象存储的稳定性极大的影响了顾客618“买买买”的体验,必须保证万无一失。 01 资源弹性伸缩弹性伸缩的核心需求是在资源池里面有足够的资源来满足业务的增长,在传统IDC时代,客户都会规划好业务的最大增量,留下足够的buffer资源来应对它,三倍的业务增长至少需要预留200%的buffer。 云上的对象存储是一个多租户系统,弹性伸缩本质上做的事情就是把多个用户的buffer统一的管理起来,然后按需分配给需要的客户。 在传统的IDC时代,京东视频存储在内部的分布式存储系统中,每次大促都需要提前两个多月开始备战。 下面是一个使用传统IDC时代618前夕准备的Checklist: 但在使用对象存储之后,基于对象存储弹性扩展到特性,整个备战过程变得非常简单: 02 成本降低很多企业在把本地到存储迁移到云上之后,都会感叹一件事情,在排除运维相关的人力成本之外,使用云还是比自己维护一套存储系统成本更低。接下来我们来看看为什么使用云上对象存储时客户的成本会降低? 架构优化提高资源利用率 首先,在使用云对象存储系统之前,很多用户使用类似Ceph之类的系统来存储自己的数据,这类系统有一个问题就是,如果整体使用率超过了80%可能会导致部分的写入失败或者写入性能降低,在实际维护的过程中,需要维护较低的水位线。 云对象存储系统基于自研存储系统,在整体使用率接近95%的时候还能保证写入的可用性和性能。 更合理的机型降低物理存储成本 在传统的IDC时代,业务自己维护自己的存储系统,由于本身存储需求相对不大,存储成本在整体成本中占比较小,一般不大会有太大的动力去优化存储的成本,以下几个情况会非常常见: 使用低密度服务器,由于存储规模不足,为了保证可靠性,必须使用更多的节点,这样每个节点的存储量就会很低使用老旧的服务器,同样由于规模的原因,很长时间都没有扩容的需求,也就无需采购新的服务器,导致整体物理成本偏高由于规模的原因,没有动力去使用新技术/新硬件和私有的存储不同,对象存储是一个快速发展的,大规模的存储系统,5%的成本降低就能带来非常可观的收益,因此我们做了很多工作来降低成本。比如采用更合理的存储机类型,根据客户自己业务的特点,定制更合理的机型。 较低的闲置率 在使用云对象存储系统之前,为了应对一些日常的促销等,私有的存储系统必须要维持足够的Buffer,要应对一倍的流量突增必须维护一倍的Buffer,这决定了整个集群的空闲率超过50%。 云上的对象存储是一个多租户的系统,多个租户会共用一个资源池子,由于多个租户涉及到不同的行业,业务高峰冲突的概率较小,对象存储系统不需要为每个用户留足够的Buffer,假设最多10%的业务在同一时间流量业务增长一倍,对象存储系统只需要维护10%的buffer就可以满足需求,较大的降低了闲置率。 IO资源复用 IO资源更细的划分的话,会包括存储/IOPS/带宽三个维度,每块磁盘的存储/IOPS/带宽都是相对确定的,但是单个业务很难说同时把三种资源全部用掉。 对象存储是一个多租户的系统,通过后台的调度,把不同类型的业务的混合的调度到磁盘上,保证这三个维度的IO资源能尽量的被使用。 京东有一个大数据分析的系统,本身只有数百TB的数据,但是在峰值会产生数百Gb的读写带宽,在迁移到对象存储之前,需要大量的机器来抗着数百Gb的峰值带宽,导致存储资源被大量浪费。在迁移到对象存储后,由于对象存储上有大量的相对较冷的数据,通过合理的调度,大数据分析系统复用了这些数据所对应的带宽,节省了大量的成本。 运维成本降低 存储系统本身是一个很复杂的系统,需要专业的运维人员来维护,而使用云对象存储之后,运维人员主要精力集中在业务上,可以极大的降低运维的人力 03 高可用性保证尽管在过去两年多里面,京东零售和京东智联云有过多次成功的合作经验,但是在商场视频把本地数据删除使用云作为唯一的数据之前,还是有一定的担心,对象存储现在是足够高可用么?对象存储在未来一直是高可用的么?接下来让我们一起来探讨下对象存储在可用性保障上走的一些工作。 对象存储架构图 整体来说,对象存储包括业务层(绿色部分),数据存储(黄色部分),元数据存储(蓝色部分)三个部分组成,其中业务层是多节点无状态服务,保证高可用。 数据存储和元数据存储都是有状态服务,其中数据存储存储对象数据的切片,元数据存储存储对象名字到数据切片ID之间的映射。 对象存储高可用核心思路如下: 基于Raft构建高可用的数据存储和元数据存储集群,部署上都跨多个AZ部署基于多个高可用数据/元数据集群构建更高可用的Data/Meta服务,集群级别故障对用户影响可控数据和元数据能写入到任何一个可用的物理集群,保证写永远可用数据/元数据都不会修改,确保数据只要存在就能读到正确的数据,提高读读可用性多个集群做蓝绿部署,降低程序/人工操作的影响范围下面我们一一来揭秘对象存储在各种异常情况下是如何保证高可用性。 Q 硬件故障 1、如果磁盘/机器/交换机故障怎么办 2、如果机房停电怎么办 A 对象存储的数据和元数据都是三副本存储,并且三副本放在三个不同的机房,确保以下: 1、如果有单节点(磁盘/机器/交换机/机房)故障,不会有任何影响 2、如果有两个节点故障,可能会导致部分复制组不可写入,对象存储会通过多集群的机制来解决这个问题,写入会写到其他的可用的集群,不影响客户端写入 3、如果有超过三个节点故障,可能会导致部分数据暂时不可访问,不影响用户写入 Q 网络故障 1、对象的数据是放在多个机房,如果机房之间的光纤被挖断了怎么办 2、如果某个机房和其他机房之间的网络断了,形成了孤岛怎么办 3、对象存储提供公网访问,如果部分公网IP被攻击/封禁怎么办 A 1、对象存储数据和元数据都分布在三个机房,如果有一个机房不可访问,其他两个机房可用形成多数派依旧可以提供服务 2、对于单机房和其他节点失联,形成数据孤岛的情况 已经写入的数据在孤岛机房内部有副本,可以读取孤岛内部写入 i. 数据会写入到WriteCache中,保证写入成功 ii. 元数据会写入到孤岛内部Backup Meta集群中,元数据最终需要和孤岛外部元数据合并3、公网故障,通过域名解析把流量导到其他区域,走内网访问 ...

June 23, 2020 · 1 min · jiezi

如何确保我们的数字遗产不会消失在未来

Forbidding Blocks. Concept: Mike Brill; Drawing: SafdarAbidi; Image courtesy of BOSTI. 怎样才可以记录或写下那些可以被10000年后的人们阅读和解释的指令呢? 1992年,一个多学科研究小组坐下来回答了这个问题,他们努力创造出经得起时间考验的针对放射性污染的警告标志。这项研究凸显了我们在长期信息检索中都面临的一个十分基础的挑战——互联网架构师Vint Cerf将这种现象称为“比特腐烂”(bit rot)。 1979年,美国国会授权在新墨西哥州卡尔斯巴德镇外几英里处建造废物隔离试验工厂(WIPP)。WIPP旨在将防御相关的放射性废物储存在该地区的地质稳定盐矿床中。但在该项目面临的众多挑战中,如何将埋藏废物的危险传达给后代是最为棘手的。 由于所处理材料的放射性,该团队的任务是创建警告“标记”,这些标记不仅要经受住1万年时间的考验,而且从现在开始产生它们的1万年后,当语言甚至是人类交流的手段可能是难以想象的不同时,还要保证人类能明白它所要传达的信息。 设计这些标记是WIPP研究团队面临的一个至关重要且艰难的任务。首先,标记需要耐用。按照团队的说法,他们需要承受“人类破坏建筑物的倾向。”他们需要向未来传递当下的,可能不会在未来出现的设计语言,亦或者向表现出截然不同的文化规范和期望的社会传递内容。他们需要传达有关埋藏材料危险性的高度复杂的信息。 Landscape of Thorns. Concept: Mike Brill; Drawing: Safdar Abidi; Image courtesy of BOSTI. 换句话说,一个简单的“危险:请勿入内”的标志根本不足以来传达该项目涉及的危险信号。加之,根本就没办法用打印文档、数字文件或“Googleable”来让未来的人类了解更多信息。 因此,包括概念艺术家迈克·布里尔在内的团队开发了一系列优雅的标记概念,旨在可以超越时间、语言和文化,并在千百年后仍旧能发出一个明确无误的信息:这是一个危险的地方,一个要避免投入使用的地方。他们总结说,石头、地球和艺术比我们目前所依赖的短暂的信息存储媒介更耐用 - 考古学家和历史学家都非常清楚这一点。 Spike Field. Concept: Mike Brill; Drawing: Safdar Abidi; Image Courtesy of BOSTI. 在21世纪,WIPP标记似乎离我们的生活很遥远,但它清醒地提醒我们,在当今数据爆炸的世界里,我们生活在“信息长寿”和“可恢复”的幻觉之下。凭借我们以指数级加速生成和存储数据的能力,很容易认为互联网上的内容就是保留在网上的。然而,无论情况是否如此——我个人认为,事实并非如此——真正重要的是我们阅读和利用这些信息的能力。 这就好像互联网上存在的信息将永远存在变成了一种集体无意识。这就是Vint Cerf所说的“比特腐烂”。在2008年对Esquire的采访中,他声称,“在一百或一千年的时间里,保持软件连续性以解释旧东西的可能性是接近于零的。现在你还会找得到8mm胶片的投影仪吗?如果新软件无法实现向下兼容,那我们其实就丢失了这部分信息内容了。我称这为比特腐烂(bit rot)。这是一个很严肃的问题。”他在接下来的几年里努力推动这一意识在当今社会中的觉醒,以及“ 数字牛皮纸 ”(digital vellum) 的概念,这是一种作为确保数字信息可以在数百年后被解释的方法。 可21世纪的当下,无论是“数字腐烂”还是“数字牛皮纸”都没有太大的吸引力。就好像我们已经默认互联网上传播的知识将永远存在一样。然而,现在正是因为我们能够如此轻易地找到的想要的信息,所以仿佛从此我们就不会介意未来数百或数千年的问题了。 这对我们日常生产的所有信息在未来的可访问性产生了严重影响。同时它也带来了另一个问题:我们将如何被后代,甚至在我们自己的一生中所看到和理解。当重建某人的生活的唯一方法是通过数字足迹,是在谷歌、微软等科技巨头的规则允许的情况下产生的信息,那是谁在决定我们后代对我们的看法?甚至我们是否真的出现过?在未来深度虚构与虚拟现实越来越普遍的情况下,如果这种现实被“数字腐烂”,我们将如何建立真实现实的基石呢? 最近我收到了一个意外的包裹,它提醒了我,我们的数字足迹的保存在这个世纪是一件多么困难和迫切的事情。这个包裹里有许多几年前与我在同一研究室工作过的同事留下的便条和笔记。同时,它还包括一张旧CD-ROM。 CD-ROM与Paper Archives。图片由Andrew Maynard提供。 CD-ROM是我在办公室清理出的旧档案之一。1999年12月,当我离开英国到美国工作时,我把它烧掉了,它包含了我在20世纪90年代的研究文件。 作为一名Mac用户,我早就不再使用像CD-ROM驱动器那样过时的电脑了。但我设法拼凑了一些东西,并发现了一些20多年前的职业生涯中的新惊喜。 第一个好消息是我仍然可以访问曾经的一些数据-CD-ROM还没有完全地过时。也就是说,我不得不承认,几年前,当我意识到自己拼凑出某种读法的机会几乎为零后,我从80年代开始就把我的软盘扔掉了——但如果我在最近的一次文件存储中使用的是光盘,不论是3.5英寸的软盘,或是5.5英寸的软盘的话,那我的信息早就消失在了数字世界中。 ...

September 9, 2019 · 1 min · jiezi

如何将Elasticsearch的快照备份至OSS

前言Elasticsearch 是一个开源的分布式 RESTful 搜索和分析引擎。它可以在近实时条件下,存储,查询和分析海量的数据。它还支持将快照备份至HDFS/S3上面,而阿里云OSS兼容S3的API,本文将介绍如何使用ES的Repository-S3插件将快照备份至OSS。 部署与配置首先,我们需要安装repository-s3,可以参考官方文档:https://www.elastic.co/guide/en/elasticsearch/plugins/7.2/repository-s3.html 启动ES,我们可以从log中看到,ES已经load了这个plugin: [2019-07-15T14:12:09,225][INFO ][o.e.p.PluginsService ] [master] loaded module [aggs-matrix-stats][2019-07-15T14:12:09,225][INFO ][o.e.p.PluginsService ] [master] loaded module [analysis-common][2019-07-15T14:12:09,225][INFO ][o.e.p.PluginsService ] [master] loaded module [ingest-common][2019-07-15T14:12:09,226][INFO ][o.e.p.PluginsService ] [master] loaded module [ingest-geoip][2019-07-15T14:12:09,226][INFO ][o.e.p.PluginsService ] [master] loaded module [ingest-user-agent][2019-07-15T14:12:09,226][INFO ][o.e.p.PluginsService ] [master] loaded module [lang-expression][2019-07-15T14:12:09,226][INFO ][o.e.p.PluginsService ] [master] loaded module [lang-mustache][2019-07-15T14:12:09,227][INFO ][o.e.p.PluginsService ] [master] loaded module [lang-painless][2019-07-15T14:12:09,227][INFO ][o.e.p.PluginsService ] [master] loaded module [mapper-extras][2019-07-15T14:12:09,227][INFO ][o.e.p.PluginsService ] [master] loaded module [parent-join][2019-07-15T14:12:09,227][INFO ][o.e.p.PluginsService ] [master] loaded module [percolator][2019-07-15T14:12:09,227][INFO ][o.e.p.PluginsService ] [master] loaded module [rank-eval][2019-07-15T14:12:09,228][INFO ][o.e.p.PluginsService ] [master] loaded module [reindex][2019-07-15T14:12:09,228][INFO ][o.e.p.PluginsService ] [master] loaded module [repository-url][2019-07-15T14:12:09,228][INFO ][o.e.p.PluginsService ] [master] loaded module [transport-netty4][2019-07-15T14:12:09,228][INFO ][o.e.p.PluginsService ] [master] loaded plugin [repository-s3][2019-07-15T14:12:12,375][INFO ][o.e.d.DiscoveryModule ] [master] using discovery type [zen] and seed hosts providers [settings][2019-07-15T14:12:12,801][INFO ][o.e.n.Node ] [master] initialized[2019-07-15T14:12:12,802][INFO ][o.e.n.Node ] [master] starting ...然后,我们需要将OSS使用的Access Key和Secret Key配置到ES去,分别执行下面的命令: ...

July 16, 2019 · 2 min · jiezi

AnalyticDB-for-MySQL-30基础版重磅发布

随着大数据技术的迅速发展以及对数据价值的认识逐渐加深,大数据已经融合到各行各业。据可靠权威数据显示,超过39.6%的企业正在应用数据并从中获益,超过89.6%的企业已经成立或计划成立相关的大数据分析部,超过六成的企业在扩大数据的投入力度度。在这样的大数据行业背景下AnalyticDB for MySQL3.0基础版发布了。AnalyticDB for MySQL3.0(以下简称ADB for MySQL3.0)基础版是在总结ADB for MySQL2.0产品研发与应用经验的基础上,匠心打磨推出的新一代分析型数据库,目前正在火热公测中。 ADB for MySQL3.0基础版融合了分布式、弹性计算与云计算的优势,对规模性、易用性、可靠性和安全性等方面进行了大规模的改进,充分满足不同场景数据仓库的需求。支持更大规模的并发访问、更快读写能力以及更智能的混合查询负载管理等,实现更精细化的资源利用和更低成本的投入,让用户能更加专注于业务发展,专注于数据价值。 相比于ADB for MySQL 2.0版本,3.0版本具有以下核心价值: 核心价值简单易用 好用是数据库价值真正的体现,ADB for MySQL3.0基础版高度兼容MySQL,更好的MySQL协议兼容以及完整的SQL和语法支持,大多数场景无需修改代码即可用ADB for MySQL3.0版平滑替换MySQL,迁移使用成本极低。对于MySQL社区周边工具也可以无缝接入。 更高性价比 支持按量付费和包年包月,除了灵活的计费模式外还支持单独磁盘扩容。磁盘灵活扩缩对用户而言最直接红利是进一步降低了成本。新购时根据实际使用量购买相应磁盘空间,无需为固定的多余空间买单;当用户磁盘达到瓶颈时降低了由于翻倍扩容来带的额外成本。 除了支持磁盘灵活扩缩外,ADB for MySQL 3.0版本售价也大幅度降低。以C8规格为例,其售卖价格比2.0版本同等规格便宜最多21%。 云原生 OSS分层存储,冷热数据分离存储,历史数据无限保留;无缝对接云端海量算力(PolarDB和DLA等)。 更大规模和更快读写能力 基于强一致raft协议的副本同步机制以及轻量的索引构建方式,具有承载更大吞吐数据实时写入和读取能力。优化分布式混合计算引擎和优化器以达到更高的复杂计算能力。3.0版本写入性能是2.0版本同等规格的1.5倍,查询TPC-H (100g)是2.0版本的1.4倍。 更高可用/可靠性 服务秒级恢复,AZ内/跨AZ部署,可用性高于99.95%,自动故障检测、摘除和副本重搭。数据三副本存储、定时全量和增量备份,提供金融级别的数据可靠性保证。 更高安全 相比2.0版本,具有更完善和细化的权限体系模型,白名单和集群级别RAM控制,回收站730天超长保存,审计与合规记录所有SQL操作。 AnalyticDB for MySQL典型应用场景场景一 数据仓库场景 ADB for MySQL给MySQL技术栈公司带来福音,是业界唯一一款完全兼容MySQL协议的数据仓库产品。通过ADB for MySQL企业客户可以低成本且快速搭建大数据平台,其实时特性又可以助力企业快速发展。 相比离线数仓方案,成本降低55%。相比ADB for MySQL2.0方案,成本降低约15%;相比离线数仓方案,报表数据延时从天级别缩短至秒级。相比ADB for MySQL2.0方案,数据延时更短; 场景二 实时运营场景 在互联网行业精益化运营的背景下,数据分析已成为运营的标配,大家都希望通过精细的分析来提高运营的效率。拿移动App行业为例,移动App行业面临以下两个主要问题: 营销推广困难移动APP推 困难, 户下载少,留存率低。如何提高下载量及留存率成为每个移动应用开发企业关注的核心问题缺少运营分析能 终端种类多,适配量大。综合性能和户体验等问题是移动APP产品从开发到上线需要一直关注并迭代改进。ADB for MySQL的实时和海量大数据高并发复杂查询特性,最适合做精细化运营。具体到App行业,ADB for MySQL的写入和数据实时特性可以很好的解决移动App行业面临的问题。 海量埋点以及指标数据实时写入,ADB for MySQL3.0写入更快,单表最大4PB;实时洞察用户行为、App终端各种指标透视分析; 场景三 实时计算清洗回流 在实时计算的某些场景下,客户通常会将流计算清洗结果数据回流至MySQL等单机数据库,作为报表库来查询使用。当单机数据量或者单表数据量非常大时,传统的关系型数据库会出现报表查询卡顿的问题。ADB for MySQL能够很好地解决卡顿的问题,支持实时计算单表数据数千亿条,快速查询分析PB级别的实时报表,无需分库分表。 ...

July 11, 2019 · 1 min · jiezi

Tableau-BI工具对接-AnalyticDB-for-PostgreSQL数据源

AnalyticDB for PostgreSQL(原HybridDB for PostgreSQL)作为高性能分析型数据库,可以支持用户对其业务数据进行实时分析,能够让企业敏锐感知市场动态,做出必要决策。Tableau是一款数据分析与可视化工具,它支持连接本地或云端数据,不管是电子表格,还是数据库数据,都能进行无缝连接。本文介绍Tableau以AnalyticDB for PostgreSQL作为数据源,如何进行有效的数据分析。 使用AnalyticDB for PostgreSQLAnalyticDB for PostgreSQL基于Greenplum,所以在选择连接器的时候选择Greenplum连接器: 点开出现登录页面,填上DB的连接信息完成登录。 登录后页面: 根据指导操作,可以将任意表进行统计分析,并进行报表展示。 例如使用TPCH数据中的lineitem,点开一张工作表可以进行任意维度的数据展示了: 每从度量或者维度中选择一个字段,放到工作表区时,Tableau都会发送一个query到AnalyticDB for PostgreSQL进行数据查询,例如上述图表发送的query: BEGIN;declare "SQL_CUR0x7fdabf04ca00" cursor with hold for SELECT "lineitem"."l_linestatus" AS "l_linestatus", "lineitem"."l_shipmode" AS "l_shipmode", SUM("lineitem"."l_orderkey") AS "sum_l_orderkey_ok", ((CAST("lineitem"."l_shipdate" AS DATE) + CAST(TRUNC((-1 * (EXTRACT(DAY FROM "lineitem"."l_shipdate") - 1))) AS INTEGER) * INTERVAL '1 DAY') + CAST(TRUNC((-1 * (EXTRACT(MONTH FROM "lineitem"."l_shipdate") - 1))) AS INTEGER) * INTERVAL '1 MONTH') AS "tyr_l_shipdate_ok" FROM "public"."lineitem" "lineitem" GROUP BY 1, 2, 4;fetch 10000 in "SQL_CUR0x7fdabf04ca00一些注意事项关掉cursor默认情况下Tableau使用cursor模式从AnalyticDB for PostgreSQL拉取数据: ...

June 26, 2019 · 1 min · jiezi

MongoDB-42-新特性解读

云数据库 MongoDB 版 基于飞天分布式系统和高性能存储,提供三节点副本集的高可用架构,容灾切换,故障迁移完全透明化。并提供专业的数据库在线扩容、备份回滚、性能优化等解决方案。 了解更多 MongoDB World 2019 上发布新版本 MongoDB 4.2 Beta,包含多项数据库新特性,本文尝试从技术角度解读。 Full Text SearchMongoDB 4.2 之前,全文搜索(Full Text Search)的能力是靠 Text Index 来支持的,在 MongoDB-4.2 里,MongoDB 直接与 Lucene 等引擎整合,在 Atlas 服务里提供全文建索的能力。 MongoDB FTS 原理用户可以在 Atlas 上,对集合开启全文索引,后台会开起 Lucene 索引引擎(索引引擎、查询引擎均可配置),对存量数据建立索引。对于开启全文建索的集合,新写入到 MongoDB 的数据, 后台的服务会通过 Change Stream 的方式订阅,并更新到 Lucene 索引引擎里。索引的查询直接以 MongoDB Query 的方式提供,Mongod 收到请求会把请求转发到 Lucene 引擎,收到建索结果后回复给客户端。Full Text Search 示例下面是一个 Full Text Search 使用的简单示例,整个使用体验非常简单,除了需要在 Atlas 控制台上建索引,其他跟正常使用 MongoDB 毫无差别,随着这块能力的完善,能覆盖很多 Elastic Search 的场景。 Step1: 准备数据 ...

June 24, 2019 · 3 min · jiezi

HSFDubbo序列化时的LocalDateTime-Instant的性能问题

来源在对Dubbo新版本做性能压测时,无意中发现对用例中某个TO(Transfer Object)类的一属性字段稍作修改,由Date变成LocalDateTime,结果是吞吐量由近5w变成了2w,RT由9ms升指90ms。 在线的系统,拼的从来不仅仅是吞吐量,而是在保证一定的RT基础上,再去做其他文章的, 也就是说应用的RT是我们服务能力的基石所在, 拿压测来说, 我们能出的qps/tps容量, 必须是应用能接受的RT下的容量,而不是纯理论的数据,在集团云化的过程中计算过,底层服务的RT每增加0.1ms,在应用层就会被放大,整体的成本就会上升10%以上。 要走向异地,首先要面对的阿喀琉斯之踵:延时,长距离来说每一百公里延时差不多在1ms左右,杭州和上海来回的延迟就在5ms以上,上海到深圳的延迟无疑会更大,延时带来的直接影响也是响应RT变大,用户体验下降,成本直线上升。 如果一个请求在不同单元对同一行记录进行修改, 即使假定我们能做到一致性和完整性, 那么为此付出的代价也是非常高的,想象一下如果一次请求需要访问10 次以上的异地 HSF 服务或 10 次以上的异地 DB调用, 服务再被服务调用,延时就形成雪球,越滚越大了。 普遍性关于时间的处理应该是无处不在,可以说离开了时间属性,99.99%的业务应用都无法支持其意义,特别是像监控类的系统中更是面向时间做针对性的定制处理。 在JDK8以前,基本是通过java.util.Date来描述日期和时刻,java.util.Calendar来做时间相关的计算处理。JDK8引入了更加方便的时间类,包括Instant,LocalDateTime、OffsetDateTime、ZonedDateTime等等,总的说来,时间处理因为这些类的引入而更加直接方便。 Instant存的是UTC的时间戳,提供面向机器时间视图,适合用于数据库存储、业务逻辑、数据交换、序列化。LocalDateTime、OffsetDateTime、ZonedDateTime等类结合了时区或时令信息,提供了面向人类的时间视图,用于向用户输入输出,同一个时间面向不同用户时,其值是不同的。比如说订单的支付、发货时间买卖双方都用本地时区显示。可以把这3个类看作是一个面向外部的工具类,而不是应用程序内部的工作部分。简单说来,Instant适用于后端服务和数据库存储,而LocalDateTime等等适用于前台门面系统和前端展示,二者可以自由转换。这方面,国际化业务的同学有相当多的体感和经验。 在HSF/Dubbo的服务集成中,无论是Date属性还是Instant属性肯定是普遍的一种场景。 问题复现Instant等类的性能优势以常见的格式化场景举例 @Benchmark @BenchmarkMode(Mode.Throughput) public String date_format() { Date date = new Date(); return new SimpleDateFormat("yyyyMMddhhmmss").format(date); } @Benchmark @BenchmarkMode(Mode.Throughput) public String instant_format() { return Instant.now().atZone(ZoneId.systemDefault()).format(DateTimeFormatter.ofPattern( "yyyyMMddhhmmss")); }在本地通过4个线程来并发运行30秒做压测,结果如下。 Benchmark Mode Cnt Score Error UnitsDateBenchmark.date_format thrpt 4101298.589 ops/sDateBenchmark.instant_format thrpt 6816922.578 ops/s可见,Instant在format时性能方面是有优势的,事实上在其他操作方面(包括日期时间相加减等)都是有性能优势,大家可以自行搜索或写代码测试来求解。 Instant等类在序列化时的陷阱针对Java自带,Hessian(淘宝优化版本)两种序列化方案,压测序列化和反序列化的处理性能。 Hessian是集团内应用的HSF2.2和开源的Dubbo中默认的序列化方案。 @Benchmark @BenchmarkMode(Mode.Throughput) public Date date_Hessian() throws Exception { Date date = new Date(); byte[] bytes = dateSerializer.serialize(date); return dateSerializer.deserialize(bytes); } @Benchmark @BenchmarkMode(Mode.Throughput) public Instant instant_Hessian() throws Exception { Instant instant = Instant.now(); byte[] bytes = instantSerializer.serialize(instant); return instantSerializer.deserialize(bytes); } @Benchmark @BenchmarkMode(Mode.Throughput) public LocalDateTime localDate_Hessian() throws Exception { LocalDateTime date = LocalDateTime.now(); byte[] bytes = localDateTimeSerializer.serialize(date); return localDateTimeSerializer.deserialize(bytes); }结果如下。可以看出,在Hessian方案下,无论还是Instant还是LocalDateTime,吞吐量相比较Date,都出现“大跌眼镜”的下滑,相差100多倍;通过通过分析,每一次把Date序列化为字节流是6个字节,而LocalDateTime则是256个字节,这个放到网络带宽中的传输代价也是会被放大。 在Java内置的序列化方案下,有稍微下滑,但没有本质区别。 ...

June 18, 2019 · 1 min · jiezi

基础数据结构及js数据存储

        因为以前前端开发跟数据存储打交道比较少,javascript又具有自动垃圾回收机制。数据结构以及存储相关的概念,其实是很容易被前端er忽略的。但是因为现在大前端的趋势,其实慢慢地,这些概念对于一个前端er来说也成了必须要掌握的技巧。        了解这些概念,对于我们去理解基本数据类型,引用数据类型,闭包,原型,原型链,事件循环等都有很好的促进作用。        接下来,我们先了解堆(heap),栈(stack),队列(queue)这三种数据结构,再来分析js数据存储相关的概念。        1 数据结构         1.1 栈 栈是一种先进后出的数据结构。        数据进入栈中之后,会被压到栈底。类似于我们平常用的羽毛球球管的概念,第一个进去的是在球管的管低,第一个出来的是位于球管管顶的最后一个进去的羽毛球。 这个概念会在我们之后需要讲到的执行上下文中用到。                 1.2 堆 是一种树状的数据结构,跟书架类似。        我们在书架取书的时候是不需要知道书的内容的,只需要知道书名就知道需要取的是哪本书了。         1.3 队列 是一种先进先出(FIFO)的数据结构。        就像我们过安检,谁排第一个谁就第一个接受安检。这块的概念主要是在事件循环机制中用到,可以更好的帮我们理解事件循环机制。         好啦,介绍完我们的基本数据结构,接下来就要详细介绍js中的数据存储方式了。         2 js数据存储         2.1 基础数据类型及变量对象         我们都知道js中基础数据类型包括undefined,null,boolean,string,number。这些数据类型都是存储在变量对象中的,我们都是按值访问,可以直接操作保存在变量中的值。 ...

June 15, 2019 · 1 min · jiezi

消息点击率翻倍的背后闲鱼无侵入可扩展IFTTT系统

一、面临问题在闲鱼生态里,用户之间会有很多种关系。其中大部分关系是由买家触发,联系到卖家,比如买家通过搜索、收藏、聊天等动作与卖家产生联系;另外一部分是平台与用户之间的关系。对这些关系分析之后我们发现这些关系中存在两个问题: 用户产生关系的层次不够丰富;现有系统只维护了一部分用户关系,包括收藏、点赞等,用户关系的层次还不够丰富。用户之间关系是单向且不够实时;在现有的玩法中,买家可以通过多种行为与卖家产生联系,但卖家不能主动与买家发生关系和互动;而且平台计算的关系都是离线的,对用户的吸引力不足。上面提到的场景经过抽象归纳之后都是同一个范式:当某个条件被满足之后,就会触发相对应的动作。这个范式是IFTTT的基本理念,而闲鱼IFTTT就是对这些问题的解决方案。 二、IFTTT概念IFTTT是一个被称为 “网络自动化神器” 的创新型互联网服务理念,它很实用而且概念很简单。IFTTT全称是 If this then that ,意思是如果满足“this”条件,则触发执行“that”动作。IFTTT由三部分构成,分别为Trigger、Action和Recipe。 可以看出IFTTT本身概念并不复杂,它的真正魔力在于“由简单组成的复杂”,也就是由众多简单的IFTTT流程相互衔接成跨越整个互联网、跨越多平台、跨越多设备的状态机。 2.1、闲鱼IFTTT闲鱼IFTTT是基于闲鱼的业务场景与IFTTT理念结合后产生的,提供IFTTT标准协议封装,对业务无侵入可扩展的服务编排系统。 闲鱼IFTTT的两个特性对应上述两个问题,分别是: 多维用户关系感知多维指的是覆盖面,闲鱼IFTTT通过更多维度的挖掘,抽象并维护了更丰富的用户关系。基于用户关系数据,我们可以产出用户画像,并通过更有效的方式触达用户。 实时用户双向互动闲鱼IFTTT底层具有对用户关系大数据的高效存储和处理能力,以支持上层业务中用户关系实时处理;闲鱼IFTTT不仅支持买家到卖家关系,而且通过设计天生支持卖家到买家关系。 闲鱼IFTTT把之前平台与用户的互动、买家到卖家的联系,切换称闲鱼用户之间天然的关系互动,对用户骚扰更少且激活拉回的效果更好,我们基于这个场景设计闲鱼IFTTT的技术方案。 三、技术方案 首先按照IFTTT规范对业务进行建模,分为Channel、Trigger和Action层,其中Channel层是数据底层,将Trigger和Action关联后组成标准Recipe。 ChannelChannel层在闲鱼IFTTT的作用是保存和管理用户关系数据,Channel层定义了用户关系的元数据结构,包括关系类型、源账户和目标账户。Channel层是闲鱼IFTTT的基石,Trigger和Action均基于用户关系数据进一步抽象业务逻辑。TriggerTrigger是业务上自定义的触发事件,与业务息息相关,可能是关注的人上新、浏览宝贝降价或者是参加的百币夺宝活动开奖等。当Trigger触发后,闲鱼IFTTT会根据Trigger类型和配置的关系类型计算用户名单,并调用Action层进行处理。ActionAction层处理对象是Trigger触发后计算的用户名单,可以给名单里的用户发Push,发权益或者其他定制逻辑。Action本身是标准化、可插拔的组件,业务上可以利用Action组件对用户名单做AB测试,快速实验不同Action策略。接下来我们说一下闲鱼IFTTT详细技术方案,方案如下: 整体技术方案按照业务建模的结构图细化,补充依赖的技术组件。整体流程不再细述,针对流程中重点模块详细说明。 3.1、场景快速接入设计场景快速接入的目的是让业务对接入闲鱼IFTTT无感知,因为在最开始的设计中,场景接入是准备通过在业务逻辑里增加AOP切面,将业务数据和场景上报。但因为这种方式对业务本身有一定侵入,增加业务执行的RT而且不够灵活,最终被否决。 而现在的场景快速接入方案解决了这些问题,通过SLS接入所有应用的海量网络请求日志,记录请求的URL、参数和响应;将SLS作为Blink流计算任务的数据源;根据diamond动态下发的规则实时筛选网络请求URL和参数,把数据按照指定格式组装后上报给Channel层。 场景快速接入方案将业务逻辑与场景接入解耦,支持快速接入,灵活变更且延迟低,是针对大数据场景接入的高性能解决方案。 3.2、计算用户名单计算用户名单模块采用责任链模式设计,因为在不同Trigger场景中,业务对用户名单的计算和筛选逻辑都是不同的。通过责任链模式,将主流程与业务筛选逻辑解耦,并支持各业务灵活定制筛选逻辑,互不干扰。 3.3、PushActionAction层是闲鱼IFTTT中最重要的一环,会直接触达到用户,Action的逻辑会直接影响用户对平台的直观感受和活跃率。消息Push是Action中最常见的逻辑,更要防止用户被骚扰,PushAction逻辑如下: 敏感人群过滤;疲劳度校验;对发送人群进行AB实验;组装消息;将Action各节点日志同步到SLS,方便检索和排查问题;统计消息发送数据及点击数据,为业务后续决策提供依据;3.3.1、疲劳度疲劳度是防止用户被骚扰的关键,我们针对疲劳度进行了分层设计,分为三层,第一层为用户级别疲劳度,控制一个用户在一个周期内收到消息数量;第二层是业务维度,控制用户在一个周期内收到某个业务的消息数量;第三层是目标级别,控制用户在一个周期内收到同一个发送者消息数量。 在业务维度层面,支持灵活控制多个业务联合疲劳度,保证用户不会被消息过度骚扰。 3.4、用户关系存储用户关系数据是闲鱼IFTTT的基石,它的特点是存储量级大,达到TB级别;而且对存储和查询的性能要求高,TPS和QPS的峰值都在一万以上。经过调研,我们发现集团内部开发的Lindorm可以满足需求。 Lindorm是阿里内部基于Hbase自研的高性能KV存储数据库,对Hbase的性能和稳定性均有一定优化。闲鱼IFTTT采用Lindorm作为用户关系数据存储,经性能测试验证数据读取QPS达到7万,数据存储TPS在10万以上。Lindorm本身性能优异,为闲鱼IFTTT高性能奠定基础。 四、效果验证闲鱼IFTTT自上线以来,已支持关注上新、浏览宝贝降价和租房小区上新等多个业务场景,提供买卖双方实时双向互动能力,平均每天处理关系数据数亿条,处理Trigger量达到上千万,处理Action量达到亿级别,消息点击率较离线push提高1倍以上。 闲鱼IFTTT目前支持的是用户互动场景,后续我们将结合闲鱼自身业务特点,对IFTTT进行更高维度抽象,封装标准Recipe接口,将闲鱼IFTTT打造成提供流程编排、管理能力的服务平台。 在我看来,IFTTT从2010年推出以来,在国外有很大的热度,在互联网和物联网领域都有专门的公司和团队在研发,IFTTT的概念虽然简单,却通过标准化协议满足用户的强需求-让各种互联网产品为用户服务。这其实也给我们互联网从业者一些思考:在新机遇面前,究竟是快速投入比较重要还是抽象标准协议解决一类问题更加有效? 五、名词注解SLS:https://cn.aliyun.com/product/slsDiamond:阿里内部研发的持久配置管理中间件;Blink:https://data.aliyun.com/product/sc?spm=5176.10695662.1131226.1.bf495006EWuVABMetaQ:阿里内部研发的分布式、队列模型的消息中间件;Lindorm:阿里内部基于HBase研发的新一代分布式NoSQL数据库,阿里云类似产品:https://www.aliyun.com/product/ots?spm=a2c4g.11174283.cwnn_jpze.59.2f5a15c3NH30me;Tair:阿里内部研发的高性能、分布式、可扩展、高可靠的Key-Value结构存储系统; 本文作者:闲鱼技术-剑辛原文链接 本文为云栖社区原创内容,未经允许不得转载。

June 14, 2019 · 1 min · jiezi

优酷背后的大数据秘密

在本文中优酷数据中台的数据技术专家门德亮分享了优酷从Hadoop迁移到阿里云MaxCompute后对业务及平台的价值。 本文内容根据演讲视频以及PPT整理而成。 大家好,我是门德亮,现在在优酷数据中台做数据相关的事情。很荣幸,我正好见证了优酷从没有MaxCompute到有的这样一个历程,因为刚刚好我就是入职优酷差不多5年的时间,我们正好是在快到5年的时候,去做了从Hadoop到MaxCompute的这样一个升级。这个是2016年5月到2019年现在的5月优酷的发展历程,上面是计算资源,下面是储存资源。大家可以看到整个用户数,还有表的数据,实际上是在呈一个指数式增长的。但是在2017年5月,当优酷完成了整个Hadoop迁移MaxCompute后,优酷的计算消耗,还有储存的消耗实际上是呈下降趋势的,整个迁移得到了一个非常大的收益。 下面说一下优酷的业务特点。 第一个特点从大数据平台整个的用户复杂度上面,不止是数据的同学和技术的同学在使用,还会包括一些BI同学,测试同学,甚至产品运营都可能去使用这个大数据的平台。 第二个特点就是业务复杂,优酷是一个视频网站,它有非常复杂的业务场景,从日志分类上,除了像页面浏览,还会有一些播放相关的数据、性能相关的数据。从整个的业务模式上,有直播、有会员、有广告、有大屏等这样一些非常不一样的场景。 第三个特点,就是数据量是非常巨大的,一天的日志量会达到千亿级别,这是一个非常旁大的数据量,而且会做非常复杂的计算。 第四个是比较有意思的,不管是小公司、大公司,对成本的意识是非常高的。优酷也是有非常严格的预算,包括在阿里集团内是有非常严格的预算系统的,但是我们也经常会去做一些重要的战役,像双十一战役,像我们暑期的世界杯战役,还有春节也会搞各种战役。这样的话,其实对计算资源的弹性要求是非常高的。 基于上面的优酷的业务特点,我整理了MaxCompute可以完美的支持我们业务的几个特点。 第一个,简单易用。第二个,完善的生态。第三个,性能非常强悍。第四个,资源使用非常弹性。 第一个特点,简单易用。MaxCompute有一个非常完整的链路,不管是从数据开发,还是数据运维,包括数据集成,数据质量的管控,还有整个数据地图,数据安全。当年优酷从Hadoop迁到MaxCompute之后,我们最大的体会是自己不用半夜经常起来去维护集群了,不用去跑任务了,写一个任务,别人之前提一个需求过来,我可能要给他排几周,而现在我可以告诉他,我给你马上跑一下,就可以出来了。包括之前像分析师BI还要登录客户端,写脚本,自己写调度,经常会说我的数今天为什么没出来?包括高层看的数,可能要到12点钟才能出来。而现在基本上所有重要的数据都会在7点钟产出,包括一些基本的业务需求,其实分析师或者产品,他们自己都可以实现了,不需要所有需求都提到数据这边。 第二个特点,完整的生态。优酷在2017年之前是完全基于Hadoop的生态,迁到MaxCompute之后,是基于阿里云提供的Serverless大数据服务的生态。大家可以在开源上看到的组件,在整个的MaxCompute上都是有的,而且比开源的要更好用、更简单。从架构图上可以看到,我们中间是MaxCompute,左侧依赖的Mysql、Hbase、ES、Redis这些都是由同步中心去做一个双向的同步。右侧会有资源管理、资源监控、数据监控,包括数据资产,还有一些数据规范。我们下层的数据输入,包括一些集团的采集工具,再往上边,有提供给开发人员用的DataWorks,包括一些命令行的工具;有提供给BI人员用的QuickBI及数据服务。 第三个特点,强悍的性能,MaxCompute支撑了优酷EB级的数据存储,千亿级的数据样本分析,包括千亿级的数据报表,10W级实例的并发、任务。这些在之前维护Hadoop的时候,是想都不敢想的。 第四个特点,资源使用的弹性。我们在2016年迁移之前,其实优酷的Hadoop集群规模已经达到了一千多台,这个当时还是一个比较大的规模。当时我们遇到了很多问题,包括像NameNode 这种内存的问题,机房没有办法再扩容的问题,当时是非常痛苦的,包括一些运维管理上面的问题。我们不断的去问运维要资源,运维告诉说,说你们已经花了多少多少资源,花了多少多少钱。我们面临的问题是计算资源如何按需使用,夜里的时候作业很多,到了下午之后,我的整个集群都空下来了,没有人用,造成了浪费。其实MaxCompute完美的解决了这个问题。 第一个,它是按用量计费的,不是说给你多少台机器,然后就收你多少钱的,真的是你用了多少资源收多少钱的,这个在成本上来说,比自己去维护集群,可能是一个砍半(降50%)这样的收益。 第二个,实际上MaxCompue计算资源是可以分时的,比如说生产队列,凌晨的时候会调高一些,保证报表能够尽快出来。到白天时候,让开发的计算资源高一些,可以让分析师、开发去临时跑一些数据,会更顺畅一些。 第三个,MaxCompute快速的扩容能力,比如说突然有一个比较强的业务需求,发现数据跑不动了,计算资源不够,所有的队列都堵死了,这个时候其实可以直接跟运维说一声,帮忙一键扩容,他两秒钟敲一个命令就搞定了。这样的话,所有的资源可以迅速的消化下去。 上面是优酷为什么采用MaxCompute,下面是在优酷的业务场景下,我们一些典型的方案、应用。这张图实际上是优酷,包括可能现在阿里集团内部一些非常典型的技术架构图。中间可以看到,MaxCompute在中间核心的位置,左侧主要是一个输入,右侧是一个输出的趋向,绿色的线是一个实时的链路,包括现在我们从整个的数据源上,比如DB也好或者服务器的本地日志Log也好,我们通过TT&Datahub存储到MaxCompute上面做分析。当然现在非常火的Flink实时计算,其实是作为一个实时处理的链路。 包括DB的同步,除了实时的链路,DB也会去通过按天/按小时,把数据同步到MaxCompute,数据计算结果也可以同步到Hbase、Mysql这种DB上面。再通过统一的服务层对应用提供服务。下面这个是机器学习Pai做的一些算法训练,再把训练的结果通过OSS传到一个算法的应用上面去。 这张图可能也是业界比较流行的一个数仓分层的图,因为我们这边是数据中台,所有的数据都是统一从ods层cdm层,然后ads层,去一层一层的往上去做精细,再到最上面,通过接口服务、文件服务、SQL服务,去提供多样化的服务。再往上面,提供对内的一些数据产品,对高管、对小二,可能还有一些对外的,比如说像优酷的播放数,包括热度这些对应用的数据。 这张图其实就是我们从Hadoop迁到MaxCompute平台上以来,两个非常经典的案例。我们通过数据中台对不同场景的用户打通,来去赋能到两个不同的场景,提升业务价值。 第二个,可能是内部的,我们通过优酷,还有集团内部的一些BU去做换量,我们通过统一的标签去做样本放大,把优酷的量导给其它的BU,把其它BU的量导给优酷,这样去达到一个共赢的效果。 这张图大部分互联网公司不太会涉及到,就是关于反作弊的问题。这个是我们在MaxCompute做的一个反作弊的架构,通过原始的数据去提取它的特征,然后再通过算法模型,包括机器学习、深度学习、图模型去支持流量反作弊、渠道反作弊等等。再通过业务场景上反作弊的监控工具,把监控到的作弊信息去打一个黑白样本,再把这个黑白样本跟特征一起来不断的迭代优化算法模型。同时针对算法模型,做一个模型的评价,不断来完善反作弊体系。 最后一点,其实还是跟成本相关,在日常使用中,一定是有小白用户或者一些新来的用户去错误的使用或者不在乎的使用一些资源,比如经常会有一些实习生或者是非技术的同学,如分析师,一个SQL消费比较高,这个其实是非常浪费资源,而且可能他一个任务,让其他所有人的任务都在这儿等着排队,实际上我们会去对整个的资源做一个治理。 从节点的粒度上,通过大数据来治理大数据,我们可以算出哪些表产出来之后,多少天没有被读取的,包括它的访问跨度可能没有那么大的,我们会去做下线或者去做治理,有一些业务场景可能并不是非常的重要或者它的时间要求没有那么高,比如一些算法训练,可以去做一些错峰的调度,保证水位不要太高。从MaxCompute任务的角度,可以算出哪些任务有数据倾斜、哪些数据可能会有相似计算,哪些任务需要去做MapJoin,哪些任务需要去做一些裁剪,然后来节省它的IO。还有哪些任务会去做暴力扫描,扫一个月、扫一年的数据,哪些数据可能会有这样一个数据膨胀,比如说它做了CUBE之类的这种复杂计算,一些算法模型的迭代;我们通过数据计算出来的这些迹象,去反推用户,来去提高它的这样一个数据的质量分,来去达到我们降低整个计算资源的目的。 在计算平台的角度,我们也持续的在使用MaxCompute推出的一些非常高级的用法,比如我们这边的HBO、Hash Cluster、Aliorc,HBO就是我们基于一个历史的优化,这样避免了用户不知道怎么调参,我可能为了自己任务快一点,就调一个特别大的参数,这样的话,对集成的资源是非常浪费的。通过这个功能,用户就不用去调参数,集群自动调好,用户就写好自己业务逻辑就好了。 第二块,可能就是最近两年推出的Hash Cluster,当时在使用Hadoop的时候经常会出现,两个大表Join的时候计算不出来,这个Hash Cluster其实是一个优化的利器。大表跟小表Join,可以做一些分发,做一些优化。大表跟大表就涉及到一个排序的问题。这个Hash Cluster,实际上就是提前把数据排好,中间省掉很多计算环节,来达到效率提升的目的。 第三个,Aliorc,在一些固定的场景上面,可以稳定的提升20%的计算效率。 第四个,Session。对一些比较小的数据,直接就放到SSD或缓存里面,一个节点下游有100个叶子场景,是非常友好的,因为低延迟秒出结果。同时,优酷也在使用Lightning解决计算加速,这个是在一个计算架构方案上的优化,它是一个MPP的架构。 最后一页是存储的优化,因为像一些关键的原始数据或者是需要审计的数据是不能删的,永久不能删的。实际上就会造成我们数据存储的趋势是一直往上不减的,计算会在某一个时间点达到一个平衡。当前用这么多的计算资源,再往后,其实应该也不会再大涨了,比如说旧的业务逻辑下掉了,会换新的业务逻辑,这样会保持在一个相对平稳的波动上面。但是储存,因为它有一些历史的数据是永远不能删的,可能会出现一直在增长,而且是指数级的。所以我们也会持续关注存储的情况,我们主要有四个手段。 第一个,还是通过大数据来治大数据,去看哪些表它的访问不够或者它的访问跨度不够。就是对一些生命周期的优化,来去控制它的增速。包括下面的,刚才提到的Aliorc,实际上是做压缩的,我们会去做一些大字段的拆分,来提高压缩的比例。 OK,这个是优酷在MaxCompute中的一些应用场景,感谢大家的聆听。 本文作者:隐林阅读原文 本文为云栖社区原创内容,未经允许不得转载。

June 12, 2019 · 1 min · jiezi

ECS最佳实践基于多块云盘构建LVM逻辑卷

一、LVM简介LVM是逻辑盘卷管理(Logical Volume Manager)的简称,它是Linux环境下对磁盘分区进行管理的一种机制,LVM是建立在硬盘和分区之上的一个逻辑层,来提高磁盘分区管理的灵活性。 LVM最大的特点就是可以对磁盘进行动态管理。因为逻辑卷的大小是可以动态调整的,而且不会丢失现有的数据。如果我们新增加了硬盘,其也不会改变现有上层的逻辑卷。作为一个动态磁盘管理机制,逻辑卷技术大大提高了磁盘管理的灵活性。如果期望扩容云盘的IO能力,则可以通过将多块容量相同的云盘做RAID0。 二、创建LVM卷2.1步骤一 创建物理卷PV 如下以5块云盘通过LVM创建弹性可扩展逻辑卷为例。 root@lvs06:~# lsblkNAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTvda 252:0 0 40G 0 disk└─vda1 252:1 0 40G 0 part /vdb 252:16 0 1T 0 diskvdc 252:32 0 1T 0 diskvdd 252:48 0 1T 0 diskvde 252:64 0 1T 0 diskvdf 252:80 0 1T 0 diskstep1: 以root账号登录云服务器step2:执行以下命令,为云盘创建PV卷pvcreate <磁盘路径1> ... <磁盘路径N>说明:此处需要填写云盘的设备名称,如果需要添加多个云盘,则可以添加多云盘设备名称,中间以空格间隔。如下以/dev/vdb, /dev/vdc,/dev/vdd,/dev/vde,/dev/vdf为例,执行结果如下: root@lvs06:~# pvcreate /dev/vdb /dev/vdc /dev/vdd /dev/vde /dev/vdf Physical volume "/dev/vdb" successfully created. Physical volume "/dev/vdc" successfully created. Physical volume "/dev/vdd" successfully created. Physical volume "/dev/vde" successfully created. Physical volume "/dev/vdf" successfully created.step3:执行以下命令,查看该服务器上物理卷(PV)信息:lvmdiskscan | grep LVM执行结果如下: ...

June 10, 2019 · 3 min · jiezi

BigData-NoSQL-ApsaraDB-HBase数据存储与分析平台概览

一、引言时间到了2019年,数据库也发展到了一个新的拐点,有三个明显的趋势: 越来越多的数据库会做云原生(CloudNative),会不断利用新的硬件及云本身的优势打造CloudNative数据库,国内以阿里云的Cloud HBase、POLARDB为代表,此块文章会有一定的引述,但不是本文的重点。NoSQL正在解决BigData领域的问题。根据Forrester NoSQL的报告,BigData NoSQL是提供 存储、计算处理、支持水平扩展、Schemaless以及灵活的数据模型,特别提到需要支持复杂计算,一般通过集成Spark或者实现单独的计算引擎实现。Cassandra商业化公司Datastax提供的产品是直接在Cassandra之上集成了Spark,另外ScyllaDB公司首页的宣传语就是The Real-Time Big Data Database。大数据的5V特性,包括 Volume:数据量大,包括采集、存储和计算的量都非常大;Variety:种类和来源多样化,包括结构化、半结构化和非结构化数据;Value:数据价值密度相对较低,或者说是浪里淘沙却又弥足珍贵;Velocity:数据增长速度快,处理速度也快,时效性要求高;Veracity:数据的准确性和可信赖度,即数据的质量需要高。5V特性可以使用BigData NoSQL数据库很好的满足,且又能满足实时的写入,分析及展现。越来越多的公司或者产品都是融合多个能力,Strapdata公司把Cassandra及ElasticSearch的能力融合在一起;Datastax直接在Cassandra之上集成了Spark;SQLServer也是融合了Spark,打造Native Spark满足DB计算能力外延的商业诉求。阿里云HBase经过公共云两年(单独的HBase在阿里内部已经发展快9年)的发展,融合开源Apache HBase、Apache Phoenix、Apache Spark、Apache Solr等开源项目,再加上一系列自研特性,满足 【一体化数据处理平台,提供一站式能力】 , 基本架构如下: 我们是站在Apache巨人的肩膀上,自研了 ApsaraDB Filesystem、HBase冷热分离、SearchIndex、SparkOnX、BDS等模块,优化了HBase、Phoenix、Spark等内核一些patch,并反馈到社区,维护打造了多模服务、数据工作台等一些列的平台能力。自研部分是我们平台核心的核心竞争力,每一层每一个组件都是我们精心打造,满足客户数据驱动业务的实际需求。为了降低客户的准入门槛,我们在Github上提供了Demo支持:aliyun-apsaradb-hbase-demo,欢迎大家关注,并贡献代码。接下来笔者会介绍各层,力求简单通俗,文中有大量的链接以衍生阅读。 二、业务视角及数据流作为一个存储计算平台,价值在满足不同的业务需求。见下图:此图描述了数据的来源、通道到沉淀到云HBase平台,再通过平台提供的Spark引擎去挖掘价值反馈给业务系统。此类似一个循环系统,在阿里内部形象称为【业务数据化,再数据业务化】。 结合架构图及业务图,此平台融合了 存储(包括实时存储及离线存储)、计算、检索等技术。整个系统都打造在ApsaraDB Filesystem统一文件层之上,把检索通过Phoenix的SearchIndex包装以降低易用性,打造领域引擎满足领域的需求,内置BDS(数据通道)实时归档数据到列存,再通过Spark引擎挖掘价值。详细参考:【选择阿里云数据库HBase版十大理由】 三、统一文件访问层ApsaraDB Filesystem(简称ADB FS)以Hadoop FileSystem API为基础构建了云HBase生态文件层底座。面向HBase生态提供了无感知的混合存储能力,极大简化了HBase生态接入云端多存储形态的复杂环境。支持OSS、阿里云HDFS、基于云盘或者本地盘构建的HDFS以及基于共享云盘构建的系统。每种分布式文件系统所用的硬件不同、成本不同、延迟不同、吞吐量不同(这里不展开)。我们可以不断扩展,只要添加一个实现xxxFileSystem即可。基于OSS直接实现的FS是无法具备原子性的元数据管理能力的,实现方案是在HDFS的namenode存元数据,实际的存储存放在OSS之上。对Rename操作只需要移动元数据,所以非常轻量。 四、HBase KV层HBase是基于Bigtable在hadoop社区的开源实现,提供了如:稀疏宽表、TTL、动态列等特性。HBase在阿里已经发展9年,已经有数位PMC及Committer,可以说在国内阿里在HBase的影响力还是数一数二的。社区也有不少的Patch也是阿里贡献。在18年,云HBase首家商业化了HBase2.0,并贡献了数十个BugFix给社区。有不少客户单独使用HBase API满足业务需求,也有不少客户使用Phoenix NewSQL层,NewSQL层提升易用性及提供了很多好用的功能。在HBase层面,除了修复社区的Bug以外,也做了几个较大的特性。在对比关系型数据方面,HBase也有天然的优势,参考:对比MySQL,一文看透HBase的能力及使用场景 冷热分离冷热分离可以降低存储成本66%左右。广泛应用于车联网、冷日志等场景下。我们把冷数据存放到OSS之上,且用户还可以使用HBase的API访问。基本原理是:把Hlog存在HDFS之上,再把冷的HFile存放在OSS之上。 GC优化GC一直是Java应用中讨论的一个热门话题,尤其在像HBase这样的大型在线存储系统中,大堆下(百GB)的GC停顿延迟产生的在线实时影响,成为内核和应用开发者的一大痛点。平台实现了CCSMap新的内存存储结构,结合offheap及新的ZenGC等一列的优化,在生产环境young GC时间从120ms减少到15ms,在实验室进一步降低到5ms左右。可以参考文章:如何降低90%Java垃圾回收时间?以阿里HBase的GC优化实践为例五、检索层HBase底层基于LSM,擅长前缀匹配和范围查找,数据模型上属于行存,大范围扫描数据对系统影响很大。我们知道,用户的需求往往是各式各样,不断变化的。对于要求高TPS,高并发,查询业务比较固定且简单的场景,HBase可以很好满足。更复杂一些,当用户对同一张表的查询条件组合有固定多个时,可以通过二级索引的方式来解决,但是二级索引有写放大问题,索引数量不能太多,一般建议不超过10个。当面对更复杂的查询模式,比如自由条件组合,模糊查询,全文查询等,用当前的索引技术是无法满足的,需要寻求新的解决方案。我们容易想到,搜索引擎,比如Lucene、Solr以及ElasticSearch,是专门面向复杂查询场景的。为了应对各种复杂的查询需求,搜索引擎运用到了大量跟LSM Tree十分不同的索引技术,比如倒排、分词、BKD Tree做数值类型索引、roaring bitmap实现联合索引、DocValues增强聚合和排序等。使用搜索引擎的技术来增强HBase的查询能力是一个十分值得深入探索的技术方向。 当前用户要想实现,复杂查询,只能重新购买新的搜索集群,通过导数据的方式将数据导入到新的搜索服务中。这种方式存在很多这样那样的问题:维护成本比较高,需要购买在线数据库,分析数据库和数据传输服务;学习门槛高,需要同时熟悉至少上诉三种服务;无法保证实时性,在线库入库和检索库入库效率不匹配;数据冗余存储,在线库索引数据和结果数据设计的所有数据都需要导入;数据一致性难保证,数据乱序问题十分常见,特别是对于分布式在线库更是如此。云HBase引入Solr,并在产品和内核上做了一系列工作,将其打造成统一的产品体验,一揽子解决了前述所有问题。用户在控制台上一键可以开通检索服务,参考文章:云HBase发布全文索引服务,轻松应对复杂查询。 检索服务的架构如上图所示,最底层是分布式文件系统的统一抽象,HBase的数据和Solr中的数据都会存储在分布式文件系统中。最上层是分布式协调服务Zookeeper,HBase、Indexer、Solr都是基于其实现分布式功能。Indexer实现了存量HBase数据的批量导入功能,有针对性地实现了数据批量导入的分布式作业机制。Indexer服务也实现了实时数据的异步同步功能,利用HBase的后台Replication机制,Indexer实现了Fake HBase功能,接收到HBase的数据后,将其转换为Solr的document,并写入solr。针对HBase写入速度比Solr快的问题,我们设计并实现了反压机制,可以将Solr中数据的延迟控制在用户设定的时间范围内,该机制同时也避免了HLog消费速度过慢的堆积问题。实时同步和批量导入可以同时运行,我们通过保序的时间戳保证了数据的最终一致性。为了提高产品的易用性,我们还基于Phoenix 实现了检索服务的SQL封装,并在存储查询等方面做了一系列优化升级,该部分在下个章节将会介绍。 六、NewSQL PhoenixPhoenix是HBase之上的SQL层,Phoenix让HBase平台从NoSQL直接进化到了NewSQL。在HBase的基础之上,再支持了Schema、Secondary Indexes、View 、Bulk Loading(离线大规模load数据)、Atomic upsert、Salted Tables、Dynamic Columns、Skip Scan等特性。目前云上最大客户有200T左右,且50%+的客户都开通了Phoenix SQL服务。我们修复了社区数十个Bug及提了不少新特性,团队也拥有1位Committer及数位contributor。在18年我们在充分测试的基础上,先于社区正式商业化了Phoenix5.0,并支持了QueryServer,支持轻量的JDBC访问。同时,社区的5.0.1也将由我们推动发布。 Phoenix本身我们做了一系列稳定性,性能等方面的优化升级,主要有:客户端优化MetaCache机制,大数据量简单查询性能提升一个数量级;索引表回查主表,使用lookupjoin的方式优化,性能提升5到7倍;轻客户端优化batch commit,性能提升2到3倍;解决Phoenix时区问题,提高易用性,降低数据一致性问题概率;禁用DESC,扫全表等有风险功能;实现大批量数据导入的Bulkload功能;等等。这些稳定性和性能方面的提升,在用户侧得到了很好的反馈。 Phoenix目前基本的架构如图所示,我们让Phoenix支持了HBase和Solr双引擎,用户可以使用SQL实现对HBase和Solr数据的管理和查询,大大提高了系统的易用性。Solr和HBase之间的同步机制可以参考上节。在支持复杂查询方面,我们设计并实现了一种新的索引:Search Index,使用方式跟Phoenix的Global Index类似,主要区别在于Search Index的索引数据存储在Solr里面,而Global Index的索引数据是一张单独的HBase表。直接通过SQL管理Search Index的生命周期、数据同步和状态,自动映射数据字段类型,并通过SQL支持复杂查询,这极大降低了用户的使用门槛。Search Index可以统一根据HBase和Solr的特性做优化,由于原表在HBase中可以通过RowKey高效查询,Solr中只需要存储作为查询条件的字段的索引数据,查询字段的原数据不需要存储在Solr中,表中的非查询字段则完全不需要存储到Solr中。相对于用户单独购买检索产品,并同步数据的方案,Search Index可以大大降低存储空间。同时,根据索引特性,Phoenix在做执行计划优化时,可以动态选择最优的索引方案。 ...

May 22, 2019 · 1 min · jiezi

etcd-在超大规模数据场景下的性能优化

作者 | 阿里云智能事业部高级开发工程师 陈星宇(宇慕)概述etcd是一个开源的分布式的kv存储系统, 最近刚被cncf列为沙箱孵化项目。etcd的应用场景很广,很多地方都用到了它,例如kubernetes就用它作为集群内部存储元信息的账本。本篇文章首先介绍我们优化的背景,为什么我们要进行优化, 之后介绍etcd内部存储系统的工作方式,之后介绍本次具体的实现方式及最后的优化效果。 优化背景由于阿里巴巴内部集群规模大,所以对etcd的数据存储容量有特殊需求,之前的etcd支持的存储大小无法满足要求, 因此我们开发了基于etcd proxy的解决方案,将数据转储到了tair中(可类比redis))。这种方案虽然解决了数据存储容量的问题,但是弊端也是比较明显的,由于proxy需要将数据进行搬移,因此操作的延时比原生存储大了很多。除此之外,由于多了tair这个组件,运维和管理成本较高。因此我们就想到底是什么原因限制了etcd的存储容量,我们是否可以通过技术手段优化解决呢? 提出了如上问题后我们首先进行了压力测试不停地像etcd中注入数据,当etcd存储数据量超过40GB后,经过一次compact(compact是etcd将不需要的历史版本数据删除的操作)后发现put操作的延时激增,很多操作还出现了超时。监控发现boltdb内部spill操作(具体定义见下文)耗时显著增加(从一般的1ms左右激增到了8s)。之后经过反复多次压测都是如此,每次发生compact后,就像世界发生了停止,所有etcd读写操作延时比正常值高了几百倍,根本无法使用。 etcd内部存储工作原理etcd存储层可以看成由两部分组成,一层在内存中的基于btree的索引层,一层基于boltdb的磁盘存储层。这里我们重点介绍底层boltdb层,因为和本次优化相关,其他可参考上文。 etcd中使用boltdb作为最底层持久化kv数据库,boltdb的介绍如下: Bolt was originally a port of LMDB so it is architecturally similar. Both use a B+tree, have ACID semantics with fully serializable transactions, and support lock-free MVCC using a single writer and multiple readers.Bolt is a relatively small code base (<3KLOC) for an embedded, serializable, transactional key/value database so it can be a good starting point for people interested in how databases work。如上介绍,它短小精悍,可以内嵌到其他软件内部,作为数据库使用,例如etcd就内嵌了boltdb作为内部存储k/v数据的引擎。boltdb的内部使用B+ tree作为存储数据的数据结构,叶子节点存放具体的真实存储键值。它将所有数据存放在单个文件中,使用mmap将其映射到内存,进行读取,对数据的修改利用write写入文件。数据存放的基本单位是一个page, 大小默认为4K. 当发生数据删除时,boltdb不直接将删掉的磁盘空间还给系统,而是内部将他先暂时保存,构成一个已经释放的page池,供后续使用,这个所谓的池在boltdb内叫freelist。例子如下: ...

May 15, 2019 · 2 min · jiezi

阿里靠什么支撑 EB 级计算力?

阿里妹导读:MaxCompute 是阿里EB级计算平台,经过十年磨砺,它成为阿里巴巴集团数据中台的计算核心和阿里云大数据的基础服务。去年MaxCompute 做了哪些工作,这些工作背后的原因是什么?大数据市场进入普惠+红海的新阶段,如何与生态发展共赢?人工智能进入井喷阶段,如何支持与借力?本文从过去一年的总结,核心技术概览,以及每条技术线路未来展望等几个方面做一个概述。BigData 概念在上世纪90年代被提出,随 Google 的3篇经典论文(GFS,BigTable,MapReduce)奠基,已经发展了超过10年。这10年中,诞生了包括Google 大数据体系,微软 Cosmos 体系,开源 Hadoop 体系等优秀的系统,这其中也包括阿里云的飞天系统。这些系统一步一步推动业界进入“数字化“和之后的“ AI 化”的时代。同时,与其他老牌系统相比(如,Linux 等操作系统体系,数据库系统、中间件,很多有超过30年的历史),大数据系统又非常年轻,随着云计算的普惠,正在大规模被应用。海量的需求和迭代推动系统快速发展,有蓬勃的生机。(技术体系的发展,可以通过如下 Hype-Cycle 概述,作者认为,大数据系统的发展进入技术复兴期/Slope of Enlightenment,并开始大规模应用 Plateau of Productivity。)如果说,0到1上线标志一个系统的诞生,在集团内大规模部署标志一个系统的成长,在云上对外大规模服务标志一个系统的成熟。MaxCompute 这10年已经走向成熟,经过多次升级换代,功能、性能、服务、稳定性已经有一个体系化的基础,成为阿里巴巴集团数据中台的计算核心和阿里云大数据的基础服务。1. MaxCompute(ODPS)概述1.1 背景信息:十年之后,回头看什么是大数据"Big data represents the information assets characterized by such a high volume, velocity and variety torequire specific technology and analytical methods for its transformation intovalue. “用5个“V”来描述大数据的特点:Volume (数据量):数据量非线性增长,包括采集、存储和计算的量都非常大,且增速很快。Variety (数据类型):包括结构化和非结构化的数据,特别是最近随音视图兴起,非结构化数据增速更快。Velocity(数据存储和计算的增长速度):数据增长速度快,处理速度快,时效性要求高。Veracity(信噪比):数据量越大,噪声越多,需要深入挖掘数据来得到结果。Value(价值):数据作为一种资产,有 1+1>2 的特点。1.3 竞品对比与分析大数据发展到今天,数据仓库市场潜力仍然巨大,更多客户开始选择云数据仓库,CDW仍处于高速增长期。当前互联网公司和传统数仓厂家都有进入领导者地位,竞争激烈,阿里巴巴CDW在全球权威咨询与服务机构Forrester发布的《The Forrester WaveTM: CloudData Warehouse, Q4 2018》报告中位列中国第一,全球第七。在 CDW 的领导者中,AWS Redshift 高度商业化、商业客户部署规模领先整个市场,GoogleBigQuery 以高性能、高度弹性伸缩获得领先,Oracle 云数仓服务以自动化数仓技术获得领先。MaxCompute 当前的定位是市场竞争者,目标是成为客户大数据的“航母”级计算引擎,解决客户在物联网、日志分析、人工智能等场景下日益增长的数据规模与计算性能下降、成本上升、复杂度上升、数据安全风险加大之间的矛盾。在此目标定位下,对 MaxCompute 在智能数仓、高可靠性、高自动化、数据安全等方面的能力提出了更高的要求。2. 2018年MaxCompute技术发展概述过去的一个财年,MaxCompute 在技术发展上坚持在核心引擎、开放平台、技术新领域等方向的深耕,在业务上继续匠心打造产品,扩大业界影响力。效率提升2018年9月云栖大会发布,MaxCompute 在标准测试集 TPC-BB 100TB整体指标较2017年提升一倍以上。得益于整体效率的提升,在集团内部 MaxCompute 以20%的硬件增长支撑了超过70%的业务增长。系统开放性和与生态融合联合计算平台 Cupid 逐步成熟,性能与 EMR Spark Benchmark 持平,支持K8S 接口,支持完整的框架安全体系,Spark On MaxCompute 已开始支持云上业务。Python 分布式项目 MARS 正式发布,开源两周内收获1200+ Star,填补了国内在 Python 生态上支持大规模分布式科学计算的空白,是竞品 Dask 性能的3倍。探索新领域MaxCompute 持续在前沿技术领域投入,保持技术先进性。在下一代引擎方向,如:AdaptiveOperatorsOperator FusionClusteredTable智能数仓 Auto Datawarehouse 方向上的调研都取得了不错的进展。在渐进计算、Advanced FailChecking and Recovery 、基于 ML的分布式计算平台优化、超大数据量 Query 子图匹配等多个方向上的调研也在进行中。深度参与和推动全球大数据领域标准化建设2018年11月,MaxCompute 与 DataWorks/AnalyticDB一起代表阿里云入选 Forrester Wave™ Q4 2018云数据仓库研究报告,在产品能力综合得分上力压微软,排名全球第七,中国第一。2019年3月,MaxCompute 正式代表 Alibaba 加入了 TPC 委员会推动融入和建立标准。MaxCompute 持续在开源社区投入。成为全球两大热门计算存储标准化开源体系 ORC 社区的 PMC,MaxCompute 成为近两年贡献代码量最多的贡献者,引导存储标准化;在全球最热门优化器项目 Calcite,拥有一个专委席位,成为国内前两家具备该领域影响力的公司,推动数十个贡献。3. 核心技术栈大数据市场进入普惠+红海的新阶段,如何借力井喷阶段中的人工智能,如何与生态发展共赢?基于横向架构上的核心引擎和系统平台,MaxCompute 在计算力、生态化、智能化3个纵向上着力发展差异化的竞争力。3.1 计算力首先我们从计算力这个角度出发,介绍一下 MaxCompute 的技术架构。a.核心引擎支撑 MaxCompute 的计算力的核心模块之一是其 SQL 引擎:在 MaxCompute 的作业中,有90%以上的作业是 SQL 作业,SQL 引擎的能力是 MaxCompute 的核心竞争力之一。在 MaxCompute 产品框架中,SQL 引擎将用户的 SQL 语句转换成对应的分布式执行计划来执行。SQL 引擎由3个主要模块构成:编译器 Compiler:对 SQL 标准有友好支持,支持100% TPC-DS 语法;并具备强大都错误恢复能力,支持 MaxCompute Studio 等先进应用。运行时 Runtime:基于LLVM优化代码生产,支持列式处理与丰富的关系算符;基于 CPP 的运行时具有更高效率。优化器 Optimizer:支持HBO和基于 Calcite 的 CBO, 通过多种优化手段不断提升 MaxCompute 性能。MaxComputeSQL 引擎当前的发展,以提升用户体验为核心目标,在 SQL 语言能力、引擎优化等多个方向上兼顾发力,建立技术优势,在 SQL 语言能力方面, 新一代大数据语言 NewSQL 做到了 Declarative 语言和 Imperative 语言的融合,进一步提升语言兼容性,目前已100% 支持 TPC-DS 语法。过去一年中,MaxCompute 新增了对 GroupingSets,If-Else 分支语句,动态类型函数,等方面的支持。b.存储MaxCompute 不仅仅是一个计算平台,也承担着大数据的存储。阿里巴巴集团99%的大数据存储都基于 MaxCompute,提高数据存储效率、稳定性、可用性,也是MaxCompute一直努力的目标。MaxCompute 存储层处于 MaxCompute Tasks 和底层盘古分布式文件系统之间,提供一个统一的逻辑数据模型给各种各样的计算任务。MaxCompute 的存储格式演化,从最早的行存格式 CFile1,到第一个列存储格式 CFile2,到第三代存储格式。支持更复杂的编码方式,异步预读等功能,进一步提升效能。在存储和计算2个方面都带来了效能的提升。存储成本方面,在阿里巴巴集团内通过 新一代的列存格式节省约8%存储空间,直接降低约1亿成本;在计算效率上,过去的一个财年中发布的每个版本之间都实现了20%的提升。目前在集团内大规模落地的过程中。在归档以及压缩方面,MaxCompute 支持 ZSTD 压缩格式,以及压缩策略,用户可以在 Normal,High 和 Extreme 三种 Stategy 里面选择。更高的压缩级别,带来更高效的存储,但也意味着更高的读写 CPU 代价。2018年, MaxCompute 陆续推出了 Hash Clustering 和 Range Clustering 支持富结构化数据,并持续的进行了深度的优化,例如增加了 ShuffleRemove,Clustering Pruning 等优化。从线上试用数据,以及大量的 ATA 用户实践案例也可以看出,Clustering 的收益也获得了用户的认可。c.系统框架资源与任务管理:MaxCompute 框架为 ODPS 上面各种类型的计算引擎提供稳定便捷的作业接入管理接口,管理着 ODPS 各种类型 Task 的生命周期。过去一年对短作业查询的持续优化,缩短 e2e 时间,加强对异常作业(OOM)的自动检测与隔离处理,全面打开服务级别流控,限制作业异常提交流量,为服务整体稳定性保驾护航。MaxCompute 存储着海量的数据,也产生了丰富的数据元数据。在离线元仓统计T+1的情况下,用户至少需要一天后才能做事后的数据风险审计,现实场景下用户希望更早风险控制,将数据访问事件和项目空间授权事件通过 CUPID 平台实时推送到用户 DataHub 订阅,用户可以通过消费 DataHub 实时获取项目空间表、volume数据被谁访问等。元数据管理:元数据服务支撑了 MaxCompute 各个计算引擎及框架的运行。每天运行在 MaxCompute 的作业,都依赖元数据服务完成 DDL,DML 以及授权及鉴权的操作。元数据服务保障了作业的稳定性和吞吐率,保障了数据的完整性和数据访问的安全性。元数据服务包含了三个核心模块:Catalog :完成DDL,DML及DCL(权限管理)的业务逻辑,Catalog保障MaxCompute作业的ACID特性。MetaServer:完成元数据的高可用存储和查询能力。AuthServer:是高性能和高QPS的鉴权服务,完成对 MaxCompute 的所有请求的鉴权,保障数据访问安全。元数据服务经过了模块化和服务化后,对核心事务管理引擎做了多次技术升级,通过数据目录多版本,元数据存储重构等改造升级,保障了数据操作的原子性和强一致,并提高了作业提交的隔离能力,并保障了线上作业的稳定性。在数据安全越来越重要的今天,元数据服务和阿里巴巴集团安全部合作,权限系统升级到了2.0。核心改进包括:MAC(强制安全控制)及安全策略管理:让项目空间管理员能更加灵活地控制用户对列级别敏感数据的访问,强制访问控制机制(MAC)独立于自主访问控制机制(DAC)。数据分类分级:新增数据的标签能力,支持对数据做隐私类数据打标。精细权限管理:将ACL的管控能力拓展到了 Package 内的表和资源,实现字段级的权限的精细化管理。系统安全:系统安全方面,MaxCompute 通过综合运用计算虚拟化和网络虚拟化技术,为云上多租户各自的用户自定义代码逻辑提供了安全而且完善的计算和网络隔离环境。SQL UDF(python udf 和 java udf),CUPID联合计算平台(Sparks/Mars等),PAI tensorflow 等计算形态都基于这套统一的基础隔离系统构建上层计算引擎。MaxCompute 还通过提供原生的存储加密能力,抵御非授权访问存储设备的数据泄露风险。MaxCompute 内置的存储加密能力,可以基于KMS云服务支持用户自定义秘钥(BYOK)以及AES256加密算法,并计划提供符合国密合规要求的SM系列加密算法支持。结合MaxCompute元仓(MetaData)提供的安全审计能力和元数据管理(MetaService)提供的安全授权鉴权能力,以及数据安全生态中安全卫士和数据保护伞等安全产品,就构成了 MaxCompute安全栈完整大图。3.2 生态化作为一个大规模数据计算平台,MaxCompute 拥有来自各类场景的EB级数据,需要快速满足各类业务发展的需要。在真实的用户场景中,很少有用户只用到一套系统:用户会有多份数据,或者使用多种引擎。联合计算融合不同的数据,丰富 MaxCompute 的数据处理生态,打破数据孤岛, 打通阿里云核心计算平台与阿里云各个重要存储服务之间的数据链路。联合计算也融合不同的引擎,提供多种计算模式,支持开源生态。开源能带来丰富和灵活的技术以赋能业务,通过兼容开源API对接开源生态。另一方面,在开源过程中我们需要解决最小化引入开源技术成本及打通数据、适配开源接口等问题。a.Cupid 联合计算平台联合计算平台 Cupid 使一个平台能够支持 Spark、Flink、Tensorflow、Numpy、ElasticSearch 等多种异构引擎, 在一份数据上做计算。在数据统一、资源统一的基础上,提供标准化的接口,将不同的引擎融合在一起做联合计算。Cupid 的工作原理是通过将 MaxCompute 所依赖的 Fuxi 、Pangu 等飞天组间接口适配成开源领域常见的 Yarn、HDFS 接口,使得开源引擎可以顺利执行。现在,Cupid 新增支持了 Kubernetes 接口,使得联合计算平台更加开放。案例:Spark OnMaxComputeSpark 是联合计算平台第一个支持的开源引擎。基于 Cupid 的 Spark on MaxCompute 实现了与 MaxCompute 数据/元数据的完美集成;遵循 MaxCompute 多租户权限及安全体系;与Dataworks、PAI平台集成;支持 Spark Streaming,Mllib, GraphX,Spark SQL,交互式等完整 Spark生态;支持动态资源伸缩等。b.多源异构数据的互联互通随着大数据业务的不断扩展,新的数据使用场景在不断产生,用户也期望把所有数据放到一起计算,从而能取得 1+1 > 2 这样更好的结果。MaxCompute 提出了联合计算,将计算下推,联动其他系统:将一个作业在多套系统联动,利用起各个系统可行的优化,做最优的决策,实现数据之间的联动和打通。MaxCompute 通过异构数据支持来提供与各种数据的联通,这里的“各种数据”是两个维度上的:多样的数据存储介质(外部数据源),插件式的框架可以对接多种数据存储介质。当前支持的外部数据源有:OSSTableStore(OTS)TDDLVolume多样的数据存储格式:开源的数据格式支持,如 ORC、Parquet 等;半结构化数据,如包括 CSV、Json等隐含一定schema 的文本文件;完全无结构数据,如对OSS上的文本,音频、图像及其他开源格式的数据进行计算。基于MaxCompute 异构数据支持,用户通过一条简单的 DDL 语句即可在 MaxCompute 上创建一张EXTERNAL TABLE(外表),建立 MaxCompute 表与外部数据源的关联,提供各种数据的接入和输出能力。创建好的外表在大部分场景中可以像普通的 MaxCompute 表一样使用,充分利用 MaxCompute 的强大计算力和数据集成、作业调度等功能。MaxCompute 外表支持不同数据源之间的 Join,支持数据融合分析,从而帮助您获得通过查询独立的数据孤岛无法获得的独特见解。从而MaxCompute 可以把数据查询从数据仓库扩展到EB级的数据湖(如OSS),快速分析任何规模的数据,没有MaxCompute存储成本,无需加载或 ETL。异构数据支持是MaxCompute 2.0升级中的一项重大更新,意在丰富 MaxCompute 的数据处理生态,打破数据孤岛,打通阿里云核心计算平台与阿里云各个重要存储服务之间的数据链路。c.Python 生态和 MARS科学计算引擎MaxCompute 的开源生态体系中,对 Python 的支持主要包括 PyODPS、Python UDF、和MARS。PyODPS 一方面是 MaxCompute 的 PythonSDK,同时也提供 DataFrame 框架,提供类似 pandas 的语法,能利用 MaxCompute 强大的处理能力来处理超大规模数据。基于 MaxCompute 丰富的用户自定义函数(UDF)支持,用户可以在 ODPS SQL 中编写 Python UDF 来扩展 ODPS SQL。 MARS 则是为了赋能 MaxCompute 科学计算,全新开发的基于矩阵的统一计算框架。使用 Mars 进行科学计算,不仅能大幅度减少分布式科学计算代码编写难度,在性能上也有大幅提升。3.3 智能化随着大数据的发展,我们在几年前就开始面对数据/作业爆发式增长的趋势。面对百万计的作业和表,如何做管理呢?MaxCompute 通过对历史作业特征的学习、基于对数据和作业的深刻理解,让 MaxCompute 上的业务一定程度实现自适应调整,让算法和系统帮助用户自动、透明、高效地进行数仓管理和重构优化工作,实现更好地理解数据,实现数据智能排布和作业全球调度,做到大数据处理领域的“自动驾驶”,也就是我们所说的Auto DataWarehousing。Auto Data Warehousing 在线上真实的业务中,到底能做什么呢?我们以Hash Clustering 的自动推荐来小试牛刀。Hash Clustering 经过一年多的发展,功能不断完善,但对用户来说,最难的问题仍然在于,给哪些表建立怎样的 Clustering 策略是最佳的方案?MaxCompute 基于 Auto Data Warehousing,来实现为用户推荐如何使用 HashClustering,回答如何选择 Table、如何设置Cluteringkey 和分桶数等问题,让用户在海量数据、海量作业、快速变化的业务场景下,充分利用平台功能。4. 商业化历程从2009年云梯到 ODPS,再到 MaxCompute,MaxCompute(ODPS) 这个大数据平台已经发展了十年。回顾 MaxCompute 的发展,首先从云梯到完成登月,成为了一个统一的大数据平台。2014年,MaxCompute 开始商业化的历程,走出集团、向公共云和专有云输出,直面中国、乃至全球的用户。面对挑战,MaxCompute 坚持产品核心能力的增强,以及差异化能力的打造, 赢得了客户的选择。回顾上云历程,公共云的第一个节点华东2上海在2014(13年)年7月开服,经过4年多发展,MaxCompute 已在全球部署18个Region,为云上过万家用户提供大数据计算服务,客户已覆盖了新零售、传媒、社交、互联网金融、健康、教育等多个行业。专有云的起点则从2014年8月第一套POC环境部署开始,发展至今专有云总机器规模已超过10000台;输出项目150+套,客户涵盖城市大脑,大安全,税务,等多个重点行业。今天,MaxCompute 在全球有超过十万的服务器,通过统一的作业调度系统和统一的元数据管理,这十万多台服务器就像一台计算机,为全球用户提供提供包括批计算、流计算、内存计算、机器学习、迭代等一系列计算能力。这一整套计算平台成为了阿里巴巴经济体,以及阿里云背后计算力的强有力支撑。MaxCompute 作为一个完整的大数据平台,将不断以技术驱动平台和产品化发展,让企业和社会能够拥有充沛的计算能力,持续快速进化,驱动数字中国。本文作者: 观涛阅读原文本文来自云栖社区合作伙伴“ 阿里技术”,如需转载请联系原作者。 ...

April 18, 2019 · 2 min · jiezi

阿里小二的日常工作要被TA们“接管”了!

昨天有人偷偷告诉我说阿里巴巴其实是一家科技公司!我想了整整一夜究竟是谁走漏了风声那么重点来了,阿里到底是如何在内部的办公、生活中,玩转“黑科技”的呢?AI取名:给你专属的“武侠”花名花名是阿里巴巴独特的文化,也是阿里员工独一无二的“身份”。在2018年云栖大会企业智能的展台上,每个参观者都拥有了一个自己的花名。特别的是,这个花名是AI机器人帮你取的。AI机器人会根据使用人的姓名、性别、偏好习惯,以及古诗词与武侠小说的典故等,生成一个花名。据说现在有超过一半的阿里新人在入职时就用的是AI推荐的花名。智慧法务:AI识别、审核法务文书阿里员工自研的文书智能审查系统,平均准确率达到94%以上。它不仅能自动提取合同、协议中的关键信息,还能在1秒内对上述文书内容、形式进行审查,发现问题并给出修改意见。在阿里,目前已经运用到法务同学的日常工作中。此外,法律文书AI 智能识别系统,还能在20秒内完成文书的识别和解析。目前80%非手写文书结构化识别率达到90%以上。机器人工厂:1分钟搭建机器人创建机器人听上去离普通人很遥远,但在阿里却是件很简单的事。在阿里自研的机器人配置平台“机器人工厂”中,不需要具备工程和算法知识,通过界面上简单的输入,即可配出自己的专属机器人。ALIBABANLP:语言分析了解一下机器是如何学习语言的?正在演示句法分析的ALIBABANLP,构建了阿里巴巴自然语言基础技术体系,提供包括分词、词性、实体、语言模型等多个算法模块。不同于以往语言技术服务一对一和完全定制化的低效开发方式,ALIBABANLP实现了业务、平台、算法三者的轻耦合及各自的专注发展。目前在搜索推荐、广告、金融、客服、娱乐、安全等国内及国际300多种业务场景广泛使用,每天9000+亿次API调用。MaxCompute:双11背后的数据核武器提供大数据计算服务的MaxCompute,支持着阿里集团几乎99%的数据存储以及95%的计算,是历年双11背后的核武器。2018年双11,MaxCompute单日处理超过600PB,平稳支撑电商混布单元在线流量洪峰12万笔/s交易,稳定承载45%导购流量,为双11交易峰值提供了有力保障和平滑支撑。为云上各行业客户提供快速、完全托管的,从GB到EB级的数据仓库解决方案,帮助企业快速、经济高效地分析处理海量数据。在阿里巴巴,所有的运营小二、数据科学家、数据工程师的工作都离不开它;Dataworks:所见即所得的数据开发Dataworks是“所见即所得”的一站式数据智能云研发平台,它以all in one box的方式,提供数据开发、算法开发、数据服务、数据治理、数据应用等全链路数据研发服务,支持千万级任务流批配合全局调度,核心通路自动识别监控,任意数据一键集成和全面系统的权限监控隔离。经过集团内9年发展,公共云5年锤炼,DataWorks目前已面向全球16个国家和地区提供服务。宜搭:轻松搭建应用不用写代码,低成本就可以“开发”一款应用?通过宜搭只需要通过简单的组件拖拽与配置,就能完成业务应用的搭建。同时,搭建的应用数据可以直接生成可供分析的数据集,方便团队或个人随时进行数据管理、分析及共享。Alibaba ICS Design:共同设计协作so easyAlibaba ICS Design 为心怀梦想的团队提供智能、创意、无缝衔接的设计协作平台。在这里,设计文件不仅能实时存储与共享,文件上还可以进行标注与投屏,方便不同分工的同学能快速协作。*看过了这么多高科技产品是不是对这家公司更感兴趣了呢?想要了解更多阿里办公黑科技记得关注我们“阿里企业智能”哦~本文作者:隐林阅读原文本文为云栖社区原创内容,未经允许不得转载。

April 1, 2019 · 1 min · jiezi

使用split_size优化的ODPS SQL的场景

使用split_size优化的ODPS SQL的场景首先有两个大背景需要说明如下:说明1:split_size,设定一个map的最大数据输入量,单位M,默认256M。用户可以通过控制这个变量,从而达到对map端输入的控制。设置语句:set odps.sql.mapper.split.size=256。一般在调整这个设置时,往往是发现一个map instance处理的数据行数太多。说明2:小文件越多,需要instance资源也越多,MaxCompute对单个Instance可以处理的小文件数限制为120个,如此造成浪费资源,影响整体的执行性能(文件的大小小于块Block 64M的文件)。场景一:单记录数据存储太少原始Logview Detail:可以发现Job只调起一个Map Instance,供处理了156M的数据,但这些数据共有5千多万的记录(单记录平均3个byte),花费了25分钟。此外,从TimeLine看可以发现,整个Job耗费43分钟,map占用了超过60%的时间。故可对map进行优化。优化手段:调小split_size为16M优化之后的logview:优化后,可以发现,Job调起了7个Map Instance,耗时4分钟;某一个Map处理了27M的数据,6百万记录。(这里可以看出set split_size只是向Job提出申请,单不会严格生效,Job还是会根据现有的资源情况等来调度Instance)因为Map的变多,Join和Reduce的instance也有增加。整个Job的执行时间也下降到7分钟。场景二:用MapJoin实现笛卡尔积原始logview:可以发现,Job调起了4个Map,花费了3个小时没有跑完;查看详细Log,某一个Map因为笛卡尔的缘故,生成的数据量暴涨。综合考虑,因为该语句使用Mapjoin生成笛卡尔积,再筛选符合条件的记录,两件事情都由map一次性完成,故对map进行优化。策略调低split_size优化后的logview:优化后,可以看到,Job调度了38个map,单一map的生成数据量下降了,整体map阶段耗时也下降到37分钟。回头追朔这个问题的根源,主要是因为使用mapjoin笛卡尔积的方式来实现udf条件关联的join,导致数据量暴涨。故使用这种方式来优化,看起来并不能从根本解决问题,故我们需要考虑更好的方式来实现类似逻辑。本文作者:祎休阅读原文本文为云栖社区原创内容,未经允许不得转载。

March 20, 2019 · 1 min · jiezi

MySQL中update修改数据与原数据相同会再次执行吗

背景本文主要测试MySQL执行update语句时,针对与原数据(即未修改)相同的update语句会在MySQL内部重新执行吗?测试环境MySQL5.7.25Centos 7.4binlog_format为ROW参数root@localhost : (none) 04:53:15> show variables like ‘binlog_row_image’;+——————+——-+| Variable_name | Value |+——————+——-+| binlog_row_image | FULL |+——————+——-+1 row in set (0.00 sec)root@localhost : (none) 04:53:49> show variables like ‘binlog_format’; +—————+——-+| Variable_name | Value |+—————+——-+| binlog_format | ROW |+—————+——-+1 row in set (0.00 sec)root@localhost : test 05:15:14> show variables like ’transaction_isolation’;+———————–+—————–+| Variable_name | Value |+———————–+—————–+| transaction_isolation | REPEATABLE-READ |+———————–+—————–+1 row in set (0.00 sec)测试步骤session1root@localhost : test 04:49:48> begin;Query OK, 0 rows affected (0.00 sec)root@localhost : test 04:49:52> select * from test where id =1;+—-+——+——+——+| id | sid | mid | name |+—-+——+——+——+| 1 | 999 | 871 | NW |+—-+——+——+——+1 row in set (0.00 sec)root@localhost : (none) 04:54:03> show engine innodb status\Gshow master status\G…—LOG—Log sequence number 12090390Log flushed up to 12090390Pages flushed up to 12090390Last checkpoint at 120903810 pending log flushes, 0 pending chkp writes33 log i/o’s done, 0.00 log i/o’s/second*************************** 1. row *************************** File: mysql-bin.000001 Position: 154 Binlog_Do_DB: Binlog_Ignore_DB: Executed_Gtid_Set: 1 row in set (0.00 sec)session2root@localhost : test 04:47:45> update test set sid=55 where id =1;Query OK, 1 row affected (0.01 sec)Rows matched: 1 Changed: 1 Warnings: 0root@localhost : (none) 04:54:03> show engine innodb status\Gshow master status\G…—LOG—Log sequence number 12091486Log flushed up to 12091486Pages flushed up to 12091486Last checkpoint at 120914770 pending log flushes, 0 pending chkp writes39 log i/o’s done, 0.00 log i/o’s/second*************************** 1. row *************************** File: mysql-bin.000001 Position: 500 Binlog_Do_DB: Binlog_Ignore_DB: Executed_Gtid_Set: 8392d215-4928-11e9-a751-0242ac110002:11 row in set (0.00 sec)session1root@localhost : test 04:49:57> update test set sid=55 where id =1; Query OK, 0 rows affected (0.00 sec)Rows matched: 1 Changed: 0 Warnings: 0root@localhost : (none) 04:54:03> show engine innodb status\Gshow master status\G…—LOG—Log sequence number 12091486Log flushed up to 12091486Pages flushed up to 12091486Last checkpoint at 120914770 pending log flushes, 0 pending chkp writes39 log i/o’s done, 0.00 log i/o’s/second*************************** 1. row *************************** File: mysql-bin.000001 Position: 500 Binlog_Do_DB: Binlog_Ignore_DB: Executed_Gtid_Set: 8392d215-4928-11e9-a751-0242ac110002:11 row in set (0.00 sec)root@localhost : test 04:52:05> select * from test where id =1;+—-+——+——+——+| id | sid | mid | name |+—-+——+——+——+| 1 | 999 | 871 | NW |+—-+——+——+——+1 row in set (0.00 sec)root@localhost : test 04:52:42> commit;Query OK, 0 rows affected (0.00 sec)root@localhost : test 04:52:52> select * from test where id =1;+—-+——+——+——+| id | sid | mid | name |+—-+——+——+——+| 1 | 55 | 871 | NW |+—-+——+——+——+1 row in set (0.00 sec)总结在binlog_format=row和binlog_row_image=FULL时,由于MySQL 需要在 binlog 里面记录所有的字段,所以在读数据的时候就会把所有数据都读出来,那么重复数据的update不会执行。即MySQL 调用了 InnoDB 引擎提供的“修改为 (1,55)”这个接口,但是引擎发现值与原来相同,不更新,直接返回binlog_format为STATEMENT参数root@localhost : (none) 04:53:15> show variables like ‘binlog_row_image’;+——————+——-+| Variable_name | Value |+——————+——-+| binlog_row_image | FULL |+——————+——-+1 row in set (0.00 sec)root@localhost : (none) 05:16:08> show variables like ‘binlog_format’;+—————+———–+| Variable_name | Value |+—————+———–+| binlog_format | STATEMENT |+—————+———–+1 row in set (0.00 sec)root@localhost : test 05:15:14> show variables like ’transaction_isolation’;+———————–+—————–+| Variable_name | Value |+———————–+—————–+| transaction_isolation | REPEATABLE-READ |+———————–+—————–+1 row in set (0.00 sec)测试步骤session1root@localhost : test 05:16:42> begin;Query OK, 0 rows affected (0.00 sec)root@localhost : test 05:16:44> select * from test where id =1;+—-+——+——+——+| id | sid | mid | name |+—-+——+——+——+| 1 | 111 | 871 | NW |+—-+——+——+——+1 row in set (0.00 sec)root@localhost : (none) 05:16:51> show engine innodb status\Gshow master status\G…—LOG—Log sequence number 12092582Log flushed up to 12092582Pages flushed up to 12092582Last checkpoint at 120925730 pending log flushes, 0 pending chkp writes45 log i/o’s done, 0.00 log i/o’s/second*************************** 1. row *************************** File: mysql-bin.000001 Position: 154 Binlog_Do_DB: Binlog_Ignore_DB: Executed_Gtid_Set: 1 row in set (0.00 sec)session2root@localhost : test 05:18:30> update test set sid=999 where id =1;Query OK, 1 row affected (0.00 sec)Rows matched: 1 Changed: 1 Warnings: 0root@localhost : (none) 05:18:47> show engine innodb status\Gshow master status\G…—LOG—Log sequence number 12093678Log flushed up to 12093678Pages flushed up to 12093678Last checkpoint at 120936690 pending log flushes, 0 pending chkp writes51 log i/o’s done, 0.14 log i/o’s/second*************************** 1. row *************************** File: mysql-bin.000001 Position: 438 Binlog_Do_DB: Binlog_Ignore_DB: Executed_Gtid_Set: 8392d215-4928-11e9-a751-0242ac110002:11 row in set (0.00 sec)session1root@localhost : test 05:16:47> update test set sid=999 where id =1;Query OK, 0 rows affected (0.00 sec)Rows matched: 1 Changed: 0 Warnings: 0root@localhost : (none) 05:20:03> show engine innodb status\Gshow master status\G…—LOG—Log sequence number 12094504Log flushed up to 12094504Pages flushed up to 12094504Last checkpoint at 120944950 pending log flushes, 0 pending chkp writes56 log i/o’s done, 0.00 log i/o’s/second*************************** 1. row *************************** File: mysql-bin.000001 Position: 438 Binlog_Do_DB: Binlog_Ignore_DB: Executed_Gtid_Set: 8392d215-4928-11e9-a751-0242ac110002:11 row in set (0.00 sec)root@localhost : test 05:19:33> select * from test where id =1; +—-+——+——+——+| id | sid | mid | name |+—-+——+——+——+| 1 | 999 | 871 | NW |+—-+——+——+——+1 row in set (0.00 sec)root@localhost : test 05:20:44> commit;Query OK, 0 rows affected (0.01 sec)root@localhost : test 05:20:57> select * from test where id =1;+—-+——+——+——+| id | sid | mid | name |+—-+——+——+——+| 1 | 999 | 871 | NW |+—-+——+——+——+1 row in set (0.00 sec)总结在binlog_format=statement和binlog_row_image=FULL时,InnoDB内部认真执行了update语句,即“把这个值修改成 (1,999)“这个操作,该加锁的加锁,该更新的更新。一站式开发者服务,海量学习资源0元起!阿里热门开源项目、机器学习干货、开发者课程/工具、小微项目、移动研发等海量资源;更有开发者福利Kindle、技术图书幸运抽奖,100%中–》https://www.aliyun.com/acts/product-section-2019/developer?utm_content=g_1000047140本文作者:powdba阅读原文本文为云栖社区原创内容,未经允许不得转载。 ...

March 19, 2019 · 4 min · jiezi

分布式系统:一致性模型

分布式系统中一个重要的问题就是数据复制,数据复制一般是为了增强系统的可用性或提高性能。而实现数据复制的一个主要难题就是保持各个副本的一致性。本文首先讨论数据复制的场景中一致性模型如此重要的原因,然后讨论一致性模型的含义,最后分析常用的一致性模型。为什么需要一致性模型数据复制主要的目的有两个:可用性和性能。首先数据复制可以提高系统的可用性。在保持多副本的情况,有一个副本不可用,系统切换到其他副本就会恢复。常用的 MySQL 主备同步方案就是一个典型的例子。另一方面,数据复制能够提供系统的性能。当分布式系统需要在服务器数量和地理区域上进行扩展时,数据复制是一个相当重要的手段。有了多个数据副本,就能将请求分流;在多个区域提供服务时,也能通过就近原则提高客户端访问数据的效率。常用的 CDN 技术就是一个典型的例子。但是数据复制是要付出代价的。数据复制带来了多副本数据一致性的问题。一个副本的数据更新之后,其他副本必须要保持同步,否则数据不一致就可能导致业务出现问题。因此,每次更新数据对所有副本进行修改的时间以及方式决定了复制代价的大小。全局同步与性能实际上是矛盾的,而为了提高性能,往往会采用放宽一致性要求的方法。因此,我们需要用一致性模型来理解和推理在分布式系统中数据复制需要考虑的问题和基本假设。什么是一致性模型首先我们要定义一下一致性模型的术语:1. 数据存储:在分布式系统中指分布式共享数据库、分布式文件系统等。2. 读写操作:更改数据的操作称为写操作(包括新增、修改、删除),其他操作称为读操作。下面是一致性模型的定义:一致性模型本质上是进程与数据存储的约定:如果进程遵循某些规则,那么进程对数据的读写操作都是可预期的。上面的定义可能比较抽象,我们用常见的强一致性模型来通俗的解释一下:在线性一致性模型中,进程对一个数据项的读操作,它期待数据存储返回的是该数据在最后一次写操作之后的结果。这在单机系统里面很容易实现,在 MySQL 中只要使用加锁读的方式就能保证读取到数据在最后一次写操作之后的结果。但在分布式系统中,因为没有全局时钟,导致要精确定义哪次写操作是最后一次写操作是非常困难的事情,因此产生了一系列的一致性模型。每种模型都有效限制了在对一个数据项执行读操作所应该返回的值。举个例子:假设记录值 X 在节点 M 和 N 上都有副本,当客户端 A 修改了副本 M 上 X 的值,一段时间之后,客户端 B 从 N 上读取 X 的值,此时一致性模型会决定客户端 B 是否能够读取到 A 写入的值。一致性模型主要可以分为两类:能够保证所有进程对数据的读写顺序都保持一致的一致性模型称为强一致性模型,而不能保证的一致性模型称为弱一致性模型。强一致性模型线性一致性(Linearizable Consistency)线性一致性也叫严格一致性(Strict Consistency)或者原子一致性(Atomic Consistency),它的条件是:1. 任何一次读都能读取到某个数据最近的一次写的数据。2. 所有进程看到的操作顺序都跟全局时钟下的顺序一致。线性一致性是对一致性要求最高的一致性模型,就现有技术是不可能实现的。因为它要求所有操作都实时同步,在分布式系统中要做到全局完全一致时钟现有技术是做不到的。首先通信是必然有延迟的,一旦有延迟,时钟的同步就没法做到一致。当然不排除以后新的技术能够做到,但目前而言线性一致性是无法实现的。顺序一致性(Sequential Consistency)顺序一致性是 Lamport(1979)在解决多处理器系统共享存储器时首次提出来的。参考我之前写的文章《分布式系统:Lamport 逻辑时钟》。它的条件是:任何一次读写操作都是按照某种特定的顺序。所有进程看到的读写操作顺序都保持一致。首先我们先来分析一下线性一致性和顺序一致性的相同点在哪里。他们都能够保证所有进程对数据的读写顺序保持一致。线性一致性的实现很简单,就按照全局时钟(可以简单理解为物理时钟)为参考系,所有进程都按照全局时钟的时间戳来区分事件的先后,那么必然所有进程看到的数据读写操作顺序一定是一样的,因为它们的参考系是一样的。而顺序一致性使用的是逻辑时钟来作为分布式系统中的全局时钟,进而所有进程也有了一个统一的参考系对读写操作进行排序,因此所有进程看到的数据读写操作顺序也是一样的。那么线性一致性和顺序一致性的区别在哪里呢?通过上面的分析可以发现,顺序一致性虽然通过逻辑时钟保证所有进程保持一致的读写操作顺序,但这些读写操作的顺序跟实际上发生的顺序并不一定一致。而线性一致性是严格保证跟实际发生的顺序一致的。弱一致性模型因果一致性(Causal Consistency)因果一致性是一种弱化的顺序一致性模型,因为它将具有潜在因果关系的事件和没有因果关系的事件区分开了。那么什么是因果关系?如果事件 B 是由事件 A 引起的或者受事件 A 的影响,那么这两个事件就具有因果关系。举个分布式数据库的示例,假设进程 P1 对数据项 x 进行了写操作,然后进程 P2 先读取了 x,然后对 y 进行了写操作,那么对 x 的读操作和对 y 的写操作就具有潜在的因果关系,因为 y 的计算可能依赖于 P2 读取到 x 的值(也就是 P1 写的值)。另一方面,如果两个进程同时对两个不同的数据项进行写操作,那么这两个事件就不具备因果关系。无因果关系的操作称为并发操作。这里只是简单陈述了一下,深入的分析见我之前写的文章《分布式系统:向量时钟》。因果一致性的条件包括:1. 所有进程必须以相同的顺序看到具有因果关系的读写操作。2. 不同进程可以以不同的顺序看到并发的读写操作。下面我们来分析一下为什么说因果一致性是一种弱化的顺序一致性模型。顺序一致性虽然不保证事件发生的顺序跟实际发生的保持一致,但是它能够保证所有进程看到的读写操作顺序是一样的。而因果一致性更进一步弱化了顺序一致性中对读写操作顺序的约束,仅保证有因果关系的读写操作有序,没有因果关系的读写操作(并发事件)则不做保证。也就是说如果是无因果关系的数据操作不同进程看到的值是有可能是不一样,而有因果关系的数据操作不同进程看到的值保证是一样的。最终一致性(Eventual Consistency)最终一致性是更加弱化的一致性模型,因果一致性起码还保证了有因果关系的数据不同进程读取到的值保证是一样的,而最终一致性只保证所有副本的数据最终在某个时刻会保持一致。从某种意义上讲,最终一致性保证的数据在某个时刻会最终保持一致就像是在说:“人总有一天会死”一样。实际上我们更加关心的是:1. “最终”到底是多久?通常来说,实际运行的系统需要能够保证提供一个有下限的时间范围。2. 多副本之间对数据更新采用什么样的策略?一段时间内可能数据可能多次更新,到底以哪个数据为准?一个常用的数据更新策略就是以时间戳最新的数据为准。由于最终一致性对数据一致性的要求比较低,在对性能要求高的场景中是经常使用的一致性模型。以客户端为中心的一致性(Client-centric Consistency)前面我们讨论的一致性模型都是针对数据存储的多副本之间如何做到一致性,考虑这么一种场景:在最终一致性的模型中,如果客户端在数据不同步的时间窗口内访问不同的副本的同一个数据,会出现读取同一个数据却得到不同的值的情况。为了解决这个问题,有人提出了以客户端为中心的一致性模型。以客户端为中心的一致性为单一客户端提供一致性保证,保证该客户端对数据存储的访问的一致性,但是它不为不同客户端的并发访问提供任何一致性保证。举个例子:客户端 A 在副本 M 上读取 x 的最新值为 1,假设副本 M 挂了,客户端 A 连接到副本 N 上,此时副本 N 上面的 x 值为旧版本的 0,那么一致性模型会保证客户端 A 读取到的 x 的值为 1,而不是旧版本的 0。一种可行的方案就是给数据 x 加版本标记,同时客户端 A 会缓存 x 的值,通过比较版本来识别数据的新旧,保证客户端不会读取到旧的值。以客户端为中心的一致性包含了四种子模型:1. 单调读一致性(Monotonic-read Consistency):如果一个进程读取数据项 x 的值,那么该进程对于 x 后续的所有读操作要么读取到第一次读取的值要么读取到更新的值。即保证客户端不会读取到旧值。2. 单调写一致性(Monotonic-write Consistency):一个进程对数据项 x 的写操作必须在该进程对 x 执行任何后续写操作之前完成。即保证客户端的写操作是串行的。3. 读写一致性(Read-your-writes Consistency):一个进程对数据项 x 执行一次写操作的结果总是会被该进程对 x 执行的后续读操作看见。即保证客户端能读到自己最新写入的值。4. 写读一致性(Writes-follow-reads Consistency):同一个进程对数据项 x 执行的读操作之后的写操作,保证发生在与 x 读取值相同或比之更新的值上。即保证客户端对一个数据项的写操作是基于该客户端最新读取的值。总结数据复制导致了一致性的问题,为了保持副本的一致性可能会严重地影响性能,唯一的解决办法就是放松一致性的要求。通过一致性模型我们可以理解和推理在分布式系统中数据复制需要考虑的问题和基本假设,便于结合具体的业务场景做权衡。每种模型都有效地限制了对一个数据项执行度操作应返回的值。通常来说限制越少的模型越容易应用,但一致性的保证就越弱。参考资料《分布式系统原理与范型》Distributed systems for fun and profitConsistency_model本文作者:肖汉松阅读原文本文为云栖社区原创内容,未经允许不得转载。 ...

March 13, 2019 · 1 min · jiezi

TableStore:爬虫数据存储和查询利器

TableStore是阿里云自研的在线数据平台,提供高可靠的存储,实时和丰富的查询功能,适用于结构化、半结构化的海量数据存储以及各种查询、分析。爬虫数据特点在众多大数据场景中,爬虫类型的数据非常适合存储在TableStore。主要是因为爬虫类型数据的一些特征和TableStore和匹配:数据量大爬虫数据一般都是抓取的互联网上的某个行业或领域的数据,数据规模和这个行业的数据规模有关,比如资讯类,每时每刻都在产生大量新闻报道,这个数据规模可能在10 TB到100 TB级别,如果考虑到历史存量数据,那么规模可能会更大。这么大量的数据存储已经不适合用单机的关系型数据库了,也不适合分库分表了,而需要一款分布式NoSQL数据库,这样可以将数据按一定的路由规则分布到不同机器上,实现自动的水平扩展,非常适合存储海量数据,尤其是爬虫类。宽行和稀疏列爬虫的数据一般来源于多个数据源,比如资讯数据可以来自人民网、新浪或者腾讯,每个数据源的数据特征不可能完全一样,每家有每家的特殊性,这样就会出现每一行数据的属性列有差异,虽然可以归一化处理后,可以将通用的属性列统一,但是不同数据源还是会存在一定差异性。如果为每个数据源建立一张表,那么工作量就会非常大,也不适合。这时候,就需要用到宽行和稀疏列功能,既能保证列数无上限,也能保证不同行不同列,还可以不额外增加存储成本和运维成本。查询类型多样爬虫数据的存储后,一般有两个出口,一个是数据处理程序,数据处理程序会读取最新的爬虫数据,然后按照自定义的处理逻辑做数据加工,处理完后会新数据写入原表或新表。数据处理完之后,数据可以提供给下游企业客户或终端用户使用了,场景的查询需求有下列几种:多种属性列组合查询。比如全网简历信息里面,通过年龄、学历、专长查询,且每个人查询的条件可能都完全不一样,需要多种属性列的自由组合查询。分词查询。不管是咨询类,还是简历类,都有大量的文本描述,这部分内容都需要支持分词后再查询。排序能力。比如资讯类数据中,查询某个新闻后,需要按时间逆序返回,越新的数据价值越大。随机读能力。如果是用来做全局数据分析或处理,那么随机读是一种必须要有的能力。轻量级统计分析。比如资讯类,想查看某个热点新闻的传播时间段和趋势,就需要统计每个时间段的此类新闻出现次数。这些查询能力,在传统的关系型数据库或者开源NoSQL中都无法提供。开源解决方案爬虫数据存储的方案已经演进了将近二十年了,千奇百怪的各种方案都有,主要的差异来源于两点:当前能获取到的存储系统能力。自身对系统可靠性、可用性的要求高低。我们下面以当前业界流行的开源系统为材料,打造一个爬虫数据存储的系统。当前业内的开源存储系统有两大类,一类是开源的关系型数据库,比如MySQL等,一类是NoSQL,比如HBase等。这两类数据存储系统都不能支持分词查询,那么还需要一个全文检索的系统,当前可选的有solr和Elasticsearch。基于上述的素材,我们就可以搭建一个存储爬虫的系统了:首先,选择存储系统,MySQL和HBase都可以,如果使用MySQL,则需要分库分表,两者架构图差不多,这里我们就选择HBase。再次,选择查询系统,可选的solr和Elasticsearch,虽然是同一类型系统,但是Elasticsearch的目前更流行,那我们也选择Elasticsearch。这样,架构图大致如下:大概解释下:流程:爬虫系统将抓取的数据写入HBase离线集群,然后数据处理系统周期性或流式的处理新到的数据,将处理后的结果写入HBase在线集群。HBase在线集群存储所有属性列的值,然后将需要查询的列通过co-processor发送给消息队列,最后再将消息队列中的数据被Elasticsearch消费,生成索引。最后,用户通过索引查询到PK,然后通过proxy到HBase在线集群读取这一行完整数据,最后返回给用户。数据存储集群有两个,一个是在线集群,一个是离线集群,原因是为了避免减少离线集群对在线查询的影响,因为离线系统重吞吐,而在线系统重延迟,所以,这里会分成两个集群,目的是挺高系统可用性。消息队列的目的是削峰填谷,减少对下游系统:Elasticsearch的压力,同时当Elasticsearch写入慢或者出故障后,不至于影响上游系统,目的也是为了提高系统可用性,避免单点故障导致整个系统雪崩。Proxy的目的是减轻客户端工作量,提高易用性的工具,原因是爬虫数据是系数列,这些列不可能全部都在Elasticsearch中创建索引,只有部分需要查询、分析的属性列才会在Elasticsearch中建立索引,但是查询的时候也需要未建立索引的字段,这样就需要一个系统做反查和合并,就是先查Elasticsearch获取到PK,然后通过PK到HBase在线集群查询这一行完整数据。这个系统中,需要运维6个不同开源系统,运维压力比较大。TableStore云解决方案最开始,我们说TableStore很适合存储爬虫数据,在介绍了开源系统的解决方案后,我们再来看一下TableStore的解决方案,以及相对于开源系统,可以为客户带来的收益。也先看一下架构图:大概解释下:爬虫系统抓取的数据写入TableStore的离线表,然后经过TunnelService的流式通道,数据进入数据处理系统做处理加工,再将加工后的数据写入在线表,用户直接查询在线表即可。将离线表和在线表同时放在TableStore服务中,会不会出现离线表干扰在线表的情况?这个不会的,TableStore服务内部有自动的负载均衡和隔离系统,会自动处理这些问题。所有的查询都可以直接查询在线表及其索引,提供了多字段组合查询、分词查询、排序和统计分析等功能,完全可以满足用户对查询的需求。数据处理部分一般有两种处理方式,一种是离线全量处理,这种可以使用阿里云的MaxCompute系统,MaxCompute可以直读TableStore的数据做计算,不需要额外把数据导过去。另一种是流式实时处理,TableStore提供了TunnelService系统,可以获取到实时的Table中的数据更新记录,然后将更新记录发送到函数计算、流式计算系统,或者自己的应用、flink等系统处理。这个架构中,用户只需要运维2个系统即可。示例我们接下来举一个简历类爬虫数据存储和查询的示例,帮忙读者快速理解。简历一般是一个PDF文档或者doc文档,是一个文件,但是我们可以从这些文件中抽取出结构化的信息,比如姓名、电话号码、身份证、邮箱、毕业学校、学历、专业领域、项目经验、兴趣、期望薪水和工作年限等。首先,我们设计TableStore中主表结构:主键列属性列属性列属性列属性列属性列属性列属性列属性列属性列身份证姓名电话号码邮箱毕业学校学历专业领域项目经验兴趣期望薪水工作年限StringStringStringStringStringStringStringStringStringLongDouble61xxx5王一152xxx7aa@xx.comMIT硕士[数据库,MySQL]1.数据库binlog优化。[足球]200003.5大概解释下:主键列需要一个唯一值,用来唯一确定某个人,这里我们用了身份证,有些场景获取不到身份证,那可以用手机号或其他ID。后面几个全部是属性列,包括姓名,电话号码等。期望薪水因为都是整数,所以可以选择Long类型,工作年限由于有小数,所以可以是Double类型。通过这张表,我们可以通过身份证,查询到该用户的详细信息。但是无法通过属性列查询,如果需要通过属性列查询,则需要创建多元索引。然后,我们再创建多元索引,多元索引的结构如下:属性列属性列属性列属性列属性列属性列属性列属性列属性列姓名电话号码毕业学校学历专业领域项目经验兴趣期望薪水工作年限Text:单字分词KeywordKeywordKeywordKeyword ArrayText:多层语义Keyword ArrayLongDouble解释下:上面的多元索引结构中包括9列,比Table中少了2列,是因为不需要通过“邮箱”和“身份证”两个属性列查询,所以,在建立index的时候就不需要为这两列创建index了。但是如果业务中确实需要通过邮箱查询,那么多元索引创建时加上邮箱即可。姓名的类型是Text:单字分词,意思是类型是Text,分词是单子分词,这样好处就是我可以通过搜索“小刚”搜索到“王小刚”、“冯小刚”等。电话号码、毕业院校、学历都是Keyword类型(对应Table中的String),因为这些都字符串都比较短,且查询方式是直接完全匹配或者前缀查询,那么用String就可以了。专业领域和项目经验两个属性列是Keyword Array的,因为是这两个属性列中会包括多个值,查询的时候只要有一个满足就可以返回,比如某个人的专业领域是:数据库、MySQL,那么我们查询“数据库”的时候,希望这个人返回。期望薪水和工作年限是数字类型的Long和Double,这样这两个属性列就可以支持范围查找,比如查找工作年限大于2年,小于5年,且期望薪水小于2万的简历。至此,我们就把简历库的table和index都建好了,用户就可以往Table中开始写数据,数据写入后会异步同步到Index中,这样就可以通过Index查询了。总结使用TableStore解决方案后,相对于开源解决方案,可以带来不少的收益:减少运维负担使用开源系统的架构中,需要运维6个系统,包括了3个开源系统:HBase、Kafka和Elasticsearch,为了运维这三个开源系统,需要有人对这三个系统比较熟悉,否则很难运维好。就算比较熟悉,也很难处理线上遇到的所有的问题,总会碰到无法解决的棘手问题而影响生产环境。如果使用了TableStore云解决方案,那么就不需要运维任何开源系统,只需要运维自己开发的两个系统,同时关注TableStore中的两个表就可以了,这两张表的运维全部是TableStore服务负责,且提供SLA保障,绝对比自己运维开源系统的可用性要高。同时,采用TableStore方案后,由于TableStore支持实时自动扩容,客户不再需要提前规划水位和集群容量,也不用担心高水位和突发流量对系统的冲击,将这些工作都交给了更擅长的云服务处理。这样,不仅降低了运维的工作量和压力,同时也降低了系统风险,提高了系统整体的可用性。减少时间成本TableStore云架构方案相对于开源方案,系统更少,从零开始到上线需要的开发时间更少,同时,TableStore是serverless的云服务,全球多个区域即开即用,可以大大降低客户的开发上线的时间,提前将产品推出,抢先争取市场领先优势。同时,TableStore支持按量付费,用户完全可以根据真实使用量付费,不再需要担心低峰期系统资源的浪费了,一定程度上,也能降低使用成本。最后目前,已经有不少行业的客户在使用TableStore存储爬虫数据,比如资讯类、生活类、文章类等等,也有部分用户在小数据量级时使用MySQL等关系型数据库,等数据规模大了后被迫迁移到TableStore存储。同时欢迎更多的客户开始使用TableStore存储你们的爬虫数据。本文作者:少强阅读原文本文为云栖社区原创内容,未经允许不得转载。

March 5, 2019 · 1 min · jiezi

阿里云发布时间序列数据库TSDB,关于时序你了解多少?

摘要: 阿里云发布时间序列数据库TSDB,专家帮你解答时序那些事。概要介绍时间序列数据是一种表示物理设备,系统、应用过程或行为随时间变化的数据,广泛应用于物联网,工业物联网,基础运维系统等场景。阿里云TSDB 时间序列数据库可以解决大规模时序数据的可靠写入,降低数据存储成本,实时灵活的完成业务数据聚合分析。什么是时序数据我们来看感受一下平时自己特别熟悉的场景,就会发现时序和每个人都存在非常紧密的关系:电商系统获取每笔订单交易金额和支付金额数据以及商品库存和物流数据;智能电表,会实时记录每个小时的用电量数据,比给出账单数据;高山上的风车的获取实时转速,风速数据,发电量数据。应用服务调用量有没有异常,服务器的负载和资源使用率如何?这些应用程序均依赖一种衡量事物随时间的变化的数据形式,每一个数据源定期发送新的读数,创建一系列随时间推移收集到的测量结果,这就是时序数据,时序数据数据集主要有以下三个特点:新入库数据几乎总是作为新条目被记录数据通常按照产生时间顺序入库所有的数据都自带时间戳,因此,我们这样定义时间序列数据:统一表示系统、过程或行为随时间变化的数据时序数据的价值相较域非时序数据,核心区别在于时序数据能够反映“变化”本身。当你为某个物联网设备收集新数据时,是覆盖以往的读数,还是在新的一行创建全新的读数?尽管这两种方法都能为你提供系统的当前状态,但只有第二种方法才能跟踪系统的所有状态。所以时序数据的价值在于将系统的每个变化都记录为新的一行,从而可以去衡量变化,分析过去的变化,监测现在的变化,以及预测未来将如何变化。时序数据库TSDB 的价值为什么不能用常规数据库来管理时序数据呢,为什么需要时序数据库呢?事实上答案是你可以使用非时间序列数据库,如同你可以为航天飞行器配备一个普通的汽车发动机,虽然也可以飞起来,但是终究不能实现航天飞行的“梦想”。而更多业务场景选择择时序数据库而非通用数据库技术也是类似的原因归结起来就是两个核心点:规模和可用性。(1)规模:时间序列数据累计速度非常快。例如,一辆联网汽车每小时产生几百GB 的数据。关系型数据库处理大数据集的效果非常糟糕;NoSQ数据库可以很好地处理规模数据,但是仍然比不上一个针对时间序列数据微调过的数据库。相比之下,时间序列数据库将时间作为最高优先级来处理,通过提高区间数据实时查询效率来处理这种大规模数据,并带来性能的提升,包括:每秒写入速度,能够支撑的设备指标量,读取数据效率和非常高的存储压缩比。而时间序列数据在技术领域的关注度也日益提升。数据来源:DBengine 2018.9月报告(2)可用性:TSDB通常还包括一些共通的对时间序列数据分析的功能和操作:数据保留策略、连续查询、灵活的时间聚合等。以及很好的扩展性。比如常见的时序降精度和聚合计算,而非时序数据库都不具备这个能力。这就是为什么企业开发人员越来越多地采用时间序列数据库,并将它们用于各种使用场景。使用阿里云TSDB 的理由阿里巴巴业务覆盖面广,诸如 电商交易跟踪, 容器指标监控, 服务监控,物流配送跟踪,智慧园区的智能设备监控等对时序数据库存在强烈的需求,选择阿里云 TSDB 是因为具备如下的优势:高性能TSDB具有高效的吞吐能力,实际压测对比,TSDB 的读取效率比开源的OpenTSDB 和InfluxDB 读取效率要高出一个数量级,实际业务上过用TSDB 来代替传统的基于Hbase的方案,整体机器成本缩减了50%以上。数据存储成本更低 时序数据都是持续写入的,任何一个数据的变化都会记录到时序数据库,所以相比较OLTP类的数据库,对于数据库的容量要求是PB级别。TSDB 可以做到最高10:1的无损压缩效率。大大降低了业务的存储成本。分析能力强 时序最核心的能力在于数据分析能力,TSDB 提供专业全面的时序数据计算函数,支持降采样、数据插值和空间聚合计算,能满足各种复杂的业务数据查询场景。百万级别数据点聚合分析秒级完成。功能完备时序数据库支持丰富的计算能力,如降精度和聚合计算。降精度我们看一个降精度例子, 园区管理员要把园区所有的照明灯的用电量数据采集起来,进行统一的监控分析,达到节能管控的目的。如果管理员要查看最近24小时耗电量的时候,那么可以直接从TSDB里获取原始数据查看用电量趋势。 而管理员要查看最近3年的用电量趋势的时候,管理员可以随机按照“天”,“周”,“月”这些比较粗粒度的时间精度来进行数据计算,所有降精度的数据通过原始小时数据按照时序提供的函数(如平均求和,最大值,最小值等)计算出来,而所有的计算过程由时序数据库“包办”,应用可以直接获取计算结果。聚合计算如果管理员要查看某个具体楼层的用电量的时候,那么只需把楼层信息请求到TSDB,就可以实时获取所需楼层所有灯的用电量。 那么如果管理员查看飞利浦品牌的耗电量的时候,只需传递品牌值到TSDB即可,按照园区名称也可以统计。所以时序聚合提供了强大非常灵活的能力,完全可以随机定义查询聚合的纬度,实时的获取不同分析纬度的查询结果。而不要用户主动创建任何索引信息。时空分析随着车联网以及智能交通和新零售配送相关行业发展,地理位置信息类型的数据存储和分析场景也日渐显现,技术领域称为“时空分析”。车联网的管理人员需要清楚的知道在当天有多少车辆在运营区域内行使,有多少车辆驶出了运营区域,每个车辆的行使轨迹是怎样的,进行全局的车辆管理。政府的管理人员需要清楚当天城区内人员流动的热力分布趋势,以提升城市管理的效率。新零售的配送管理员需要知道配送员是否按照规定在区域内配送,配送员的配送轨迹如何,以便于做管理和配送路径的优化。这些都依赖时空分析能力。TSDB 即将发布时空分析功能,提供地理位置信息类型数据的存储和分析。满足轨迹追踪,空间位置统计分析的业务需求。时序洞察数据可视化是呈现数据分析结果的重要一环,TSDB 提供了基础的可视化功能时序洞察,可以实时的提供给用户交互式的数据分析过程。用户无需开发任何的代码,就可以完成数据查询和分析,同时直观的看到数据的趋势效果。快速体验阿里云TSDBTSDB 新发布的时序洞察,能够通过demo 数据的导入,只需三个步骤,就可以快速体验交互式的时序数据分析能力:第一步,创建TSDB 实例第二步,进行demo数据导入第三步,创建时序洞察, 进行数据分析了解更多时序洞察,万物互联>>立即报名直播>>本文作者:lyrewu阅读原文本文为云栖社区原创内容,未经允许不得转载。

February 26, 2019 · 1 min · jiezi

一致性协议浅析:从逻辑时钟到Raft

前言春节在家闲着没事看了几篇论文,把一致性协议的几篇论文都过了一遍。在看这些论文之前,我一直有一些疑惑,比如同样是有Leader和两阶段提交,Zookeeper的ZAB协议和Raft有什么不同,Paxos协议到底要怎样才能用在实际工程中,这些问题我都在这些论文中找到了答案。接下来,我将尝试以自己的语言给大家讲讲这些协议,使大家能够理解这些算法。同时,我自己也有些疑问,我会在我的阐述中提出,也欢迎大家一起讨论。水平有限,文中难免会有一些纰漏门也欢迎大家指出。逻辑时钟逻辑时钟其实算不上是一个一致性协议,它是Lamport大神在1987年就提出来的一个想法,用来解决分布式系统中,不同的机器时钟不一致可能带来的问题。在单机系统中,我们用机器的时间来标识事件,就可以非常清晰地知道两个不同事件的发生次序。但是在分布式系统中,由于每台机器的时间可能存在误差,无法通过物理时钟来准确分辨两个事件发生的先后顺序。但实际上,在分布式系统中,只有两个发生关联的事件,我们才会去关心两者的先来后到关系。比如说两个事务,一个修改了rowa,一个修改了rowb,他们两个谁先发生,谁后发生,其实我们并不关心。那所谓逻辑时钟,就是用来定义两个关联事件的发生次序,即‘happens before’。而对于不关联的事件,逻辑时钟并不能决定其先后,所以说这种‘happens before’的关系,是一种偏序关系。图和例子来自于这篇博客此图中,箭头表示进程间通讯,ABC分别代表分布式系统中的三个进程。逻辑时钟的算法其实很简单:每个事件对应一个Lamport时间戳,初始值为0如果事件在节点内发生,时间戳加1如果事件属于发送事件,时间戳加1并在消息中带上该时间戳如果事件属于接收事件,时间戳 = Max(本地时间戳,消息中的时间戳) + 1这样,所有关联的发送接收事件,我们都能保证发送事件的时间戳小于接收事件。如果两个事件之间没有关联,比如说A3和B5,他们的逻辑时间一样。正是由于他们没有关系,我们可以随意约定他们之间的发生顺序。比如说我们规定,当Lamport时间戳一样时,A进程的事件发生早于B进程早于C进程,这样我们可以得出A3 ‘happens before’ B5。而实际在物理世界中,明显B5是要早于A3发生的,但这都没有关系。逻辑时钟貌似目前并没有被广泛的应用,除了DynamoDB使用了vector clock来解决多版本的先后问题(如果有其他实际应用的话请指出,可能是我孤陋寡闻了),Google的Spanner 也是采用物理的原子时钟来解决时钟问题。但是从Larmport大师的逻辑时钟算法上,已经可以看到一些一致性协议的影子。Replicated State Machine说到一致性协议,我们通常就会讲到复制状态机。因为通常我们会用复制状态机加上一致性协议算法来解决分布式系统中的高可用和容错。许多分布式系统,都是采用复制状态机来进行副本之间的数据同步,比如HDFS,Chubby和Zookeeper。所谓复制状态机,就是在分布式系统的每一个实例副本中,都维持一个持久化的日志,然后用一定的一致性协议算法,保证每个实例的这个log都完全保持一致,这样,实例内部的状态机按照日志的顺序回放日志中的每一条命令,这样客户端来读时,在每个副本上都能读到一样的数据。复制状态机的核心就是图中 的Consensus模块,即今天我们要讨论的Paxos,ZAB,Raft等一致性协议算法。PaxosPaxos是Lamport大神在90年代提出的一致性协议算法,大家一直都觉得难懂,所以Lamport在2001又发表了一篇新的论文《Paxos made simple》,在文中他自己说Paxos是世界上最简单的一致性算法,非常容易懂……但是业界还是一致认为Paxos比较难以理解。在我看过Lamport大神的论文后,我觉得,除去复杂的正确性论证过程,Paxos协议本身还是比较好理解的。但是,Paxos协议还是过于理论,离具体的工程实践还有太远的距离。我一开始看Paxos协议的时候也是一头雾水,看来看去发现Paxos协议只是为了单次事件答成一致,而且答成一致后的值无法再被修改,怎么用Paxos去实现复制状态机呢?另外,Paxos协议答成一致的值只有Propose和部分follower知道,这协议到底怎么用……但是,如果你只是把Paxos协议当做一个理论去看,而不是考虑实际工程上会遇到什么问题的话,会容易理解的多。Lamport的论文中对StateMachine的应用只有一个大概的想法,并没有具体的实现逻辑,想要直接把Paxos放到复制状态机里使用是不可能的,得在Paxos上补充很多的东西。这些是为什么Paxos有这么多的变种。Basic-PaxosBasic-Paxos即Lamport最初提出的Paxos算法,其实很简单,用三言两语就可以讲完,下面我尝试着用我自己的语言描述下Paxos协议,然后会举出一个例子。要理解Paxos,只要记住一点就好了,Paxos只能为一个值形成共识,一旦Propose被确定,之后值永远不会变,也就是说整个Paxos Group只会接受一个提案(或者说接受多个提案,但这些提案的值都一样)。至于怎么才能接受多个值来形成复制状态机,大家可以看下一节Multi-Paxos.Paxos协议中是没有Leader这个概念的,除去Learner(只是学习Propose的结果,我们可以不去讨论这个角色),只有Proposer和Acceptor。Paxos并且允许多个Proposer同时提案。Proposer要提出一个值让所有Acceptor答成一个共识。首先是Prepare阶段,Proposer会给出一个ProposeID n(注意,此阶段Proposer不会把值传给Acceptor)给每个Acceptor,如果某个Acceptor发现自己从来没有接收过大于等于n的Proposer,则会回复Proposer,同时承诺不再接收ProposeID小于等于n的提议的Prepare。如果这个Acceptor已经承诺过比n更大的propose,则不会回复Proposer。如果Acceptor之前已经Accept了(完成了第二个阶段)一个小于n的Propose,则会把这个Propose的值返回给Propose,否则会返回一个null值。当Proposer收到大于半数的Acceptor的回复后,就可以开始第二阶段accept阶段。但是这个阶段Propose能够提出的值是受限的,只有它收到的回复中不含有之前Propose的值,他才能自由提出一个新的value,否则只能是用回复中Propose最大的值做为提议的值。Proposer用这个值和ProposeID n对每个Acceptor发起Accept请求。也就是说就算Proposer之前已经得到过acceptor的承诺,但是在accept发起之前,Acceptor可能给了proposeID更高的Propose承诺,导致accept失败。也就是说由于有多个Proposer的存在,虽然第一阶段成功,第二阶段仍然可能会被拒绝掉。下面我举一个例子,这个例子来源于这篇博客假设有Server1,Server2, Server3三个服务器,他们都想通过Paxos协议,让所有人答成一致他们是leader,这些Server都是Proposer角色,他们的提案的值就是他们自己server的名字。他们要获取Acceptor1~3这三个成员同意。首先Server2发起一个提案【1】,也就是说ProposeID为1,接下来Server1发起来一个提案【2】,Server3发起一个提案【3】.首先是Prepare阶段:假设这时Server1发送的消息先到达acceptor1和acceptor2,它们都没有接收过请求,所以接收该请求并返回【2,null】给Server1,同时承诺不再接受编号小于2的请求; 紧接着,Server2的消息到达acceptor2和acceptor3,acceptor3没有接受过请求,所以返回proposer2 【1,null】,并承诺不再接受编号小于1的消息。而acceptor2已经接受Server1的请求并承诺不再接收编号小于2的请求,所以acceptor2拒绝Server2的请求; 最后,Server3的消息到达acceptor2和acceptor3,它们都接受过提议,但编号3的消息大于acceptor2已接受的2和acceptor3已接受的1,所以他们都接受该提议,并返回Server3 【3,null】; 此时,Server2没有收到过半的回复,所以重新取得编号4,并发送给acceptor2和acceptor3,此时编号4大于它们已接受的提案编号3,所以接受该提案,并返回Server2 【4,null】。接下来进入Accept阶段,Server3收到半数以上(2个)的回复,并且返回的value为null,所以,Server3提交了【3,server3】的提案。 Server1在Prepare阶段也收到过半回复,返回的value为null,所以Server1提交了【2,server1】的提案。 Server2也收到过半回复,返回的value为null,所以Server2提交了【4,server2】的提案。 Acceptor1和acceptor2接收到Server1的提案【2,server1】,acceptor1通过该请求,acceptor2承诺不再接受编号小于4的提案,所以拒绝; Acceptor2和acceptor3接收到Server2的提案【4,server2】,都通过该提案; Acceptor2和acceptor3接收到Server3的提案【3,server3】,它们都承诺不再接受编号小于4的提案,所以都拒绝。 此时,过半的acceptor(acceptor2和acceptor3)都接受了提案【4,server2】,learner感知到提案的通过,learner开始学习提案,所以server2成为最终的leader。Multi-Paxos刚才我讲了,Paxos还过于理论,无法直接用到复制状态机中,总的来说,有以下几个原因Paxos只能确定一个值,无法用做Log的连续复制由于有多个Proposer,可能会出现活锁,如我在上面举的例子中,Server2的一共提了两次Propose才最终让提案通过,极端情况下,次数可能会更多提案的最终结果可能只有部分Acceptor知晓,没法达到复制状态机每个instance都必须有完全一致log的需求。那么其实Multi-Paxos,其实就是为了解决上述三个问题,使Paxos协议能够实际使用在状态机中。解决第一个问题其实很简单。为Log Entry每个index的值都是用一个独立的Paxos instance。解决第二个问题也很简答,让一个Paxos group中不要有多个Proposer,在写入时先用Paxos协议选出一个leader(如我上面的例子),然后之后只由这个leader做写入,就可以避免活锁问题。并且,有了单一的leader之后,我们还可以省略掉大部分的prepare过程。只需要在leader当选后做一次prepare,所有Acceptor都没有接受过其他Leader的prepare请求,那每次写入,都可以直接进行Accept,除非有Acceptor拒绝,这说明有新的leader在写入。为了解决第三个问题,Multi-Paxos给每个Server引入了一个firstUnchosenIndex,让leader能够向向每个Acceptor同步被选中的值。解决这些问题之后Paxos就可以用于实际工程了。Paxos到目前已经有了很多的补充和变种,实际上,之后我要讨论的ZAB也好,Raft也好,都可以看做是对Paxos的修改和变种,另外还有一句流传甚广的话,“世上只有一种一致性算法,那就是Paxos”。ZABZAB即Zookeeper Atomic BoardCast,是Zookeeper中使用的一致性协议。ZAB是Zookeeper的专用协议,与Zookeeper强绑定,并没有抽离成独立的库,因此它的应用也不是很广泛,仅限于Zookeeper。但ZAB协议的论文中对ZAB协议进行了详细的证明,证明ZAB协议是能够严格满足一致性要求的。ZAB随着Zookeeper诞生于2007年,此时Raft协议还没有发明,根据ZAB的论文,之所以Zookeeper没有直接使用Paxos而是自己造轮子,是因为他们认为Paxos并不能满足他们的要求。比如Paxos允许多个proposer,可能会造成客户端提交的多个命令没法按照FIFO次序执行。同时在恢复过程中,有一些follower的数据不全。这些断论都是基于最原始的Paxos协议的,实际上后来一些Paxos的变种,比如Multi-Paxos已经解决了这些问题。当然我们只能站在历史的角度去看待这个问题,由于当时的Paxos并不能很好的解决这些问题,因此Zookeeper的开发者创造了一个新的一致性协议ZAB。ZAB其实和后来的Raft非常像,有选主过程,有恢复过程,写入也是两阶段提交,先从leader发起一轮投票,获得超过半数同意后,再发起一次commit。ZAB中每个主的epoch number其实就相当于我接下来要讲的Raft中的term。只不过ZAB中把这个epoch number和transition number组成了一个zxid存在了每个entry中。ZAB在做log复制时,两阶段提交时,一个阶段是投票阶段,只要收到过半数的同意票就可以,这个阶段并不会真正把数据传输给follower,实际作用是保证当时有超过半数的机器是没有挂掉,或者在同一个网络分区里的。第二个阶段commit,才会把数据传输给每个follower,每个follower(包括leader)再把数据追加到log里,这次写操作就算完成。如果第一个阶段投票成功,第二个阶段有follower挂掉,也没有关系,重启后leader也会保证follower数据和leader对其。如果commit阶段leader挂掉,如果这次写操作已经在至少一个follower上commit了,那这个follower一定会被选为leader,因为他的zxid是最大的,那么他选为leader后,会让所有follower都commit这条消息。如果leader挂时没有follower commit这条消息,那么这个写入就当做没写完。由于只有在commit的时候才需要追加写日志,因此ZAB的log,只需要append-only的能力,就可以了。另外,ZAB支持在从replica里做stale read,如果要做强一致的读,可以用sync read,原理也是先发起一次虚拟的写操作,到不做任何写入,等这个操作完成后,本地也commit了这次sync操作,再在本地replica上读,能够保证读到sync这个时间点前所有的正确数据,而Raft所有的读和写都是经过主节点的RaftRaft是斯坦福大学在2014年提出的一种新的一致性协议。作者表示之所以要设计一种全新的一致性协议,是因为Paxos实在太难理解,而且Paxos只是一个理论,离实际的工程实现还有很远的路。因此作者狠狠地吐槽了Paxos一把:Paxos协议中,是不需要Leader的,每个Proposer都可以提出一个propose。相比Raft这种一开始设计时就把选主和协议达成一致分开相比,Paxos等于是把选主和propose阶段杂糅在了一起,造成Paxos比较难以理解。最原始的Paxos协议只是对单一的一次事件答成一致,一旦这个值被确定,就无法被更改,而在我们的现实生活中,包括我们数据库的一致性,都需要连续地对log entry的值答成一致,所以单单理解Paxos协议本身是不够的,我们还需要对Paxos协议进行改进和补充,才能真正把Paxos协议应用到工程中。而对Paxos协议的补充本身又非常复杂,而且虽然Paxos协议被Lamport证明过,而添加了这些补充后,这些基于Paxos的改进算法,如Multi-Paxos,又是未经证明的。第三个槽点是Paxos协议只提供了一个非常粗略的描述,导致后续每一个对Paxos的改进,以及使用Paxos的工程,如Google的Chubby,都是自己实现了一套工程来解决Paxos中的一些具体问题。而像Chubby的实现细节其实并没有公开。也就是说要想在自己的工程中使用Paxos,基本上每个人都需要自己定制和实现一套适合自己的Paxos协议。因此,Raft的作者在设计Raft的时候,有一个非常明确的目标,就是让这个协议能够更好的理解,在设计Raft的过程中,如果遇到有多种方案可以选择的,就选择更加容易理解的那个。作者举了一个例子。在Raft的选主阶段,本来可以给每个server附上一个id,大家都去投id最大的那个server做leader,会更快地达成一致(类似ZAB协议),但这个方案又增加了一个serverid的概念,同时在高id的server挂掉时,低id的server要想成为主必须有一个等待时间,影响可用性。因此Raft的选主使用了一个非常简单的方案:每个server都随机sleep一段时间,最早醒过来的server来发起一次投票,获取了大多数投票即可为主。在通常的网络环境下,最早发起投票的server也会最早收到其他server的赞成票,因此基本上只需要一轮投票就可以决出leader。整个选主过程非常简单明了。除了选主,整个Raft协议的设计都非常简单。leader和follower之间的交互(如果不考虑snapshot和改变成员数量)一共只有2个RPC call。其中一个还是选主时才需要的RequestVote。也就是说所有的数据交互,都只由AppendEntries 这一个RPC完成。理解Raft算法,首先要理解Term这个概念。每个leader都有自己的Term,而且这个term会带到log的每个entry中去,来代表这个entry是哪个leader term时期写入的。另外Term相当于一个lease。如果在规定的时间内leader没有发送心跳(心跳也是AppendEntries这个RPC call),Follower就会认为leader已经挂掉,会把自己收到过的最高的Term加上1做为新的term去发起一轮选举。如果参选人的term还没自己的高的话,follower会投反对票,保证选出来的新leader的term是最高的。如果在time out周期内没人获得足够的选票(这是有可能的),则follower会在term上再加上1去做新的投票请求,直到选出leader为止。最初的raft是用c语言实现的,这个timeout时间可以设置的非常短,通常在几十ms,因此在raft协议中,leader挂掉之后基本在几十ms就能够被检测发现,故障恢复时间可以做到非常短。而像用Java实现的Raft库,如Ratis,考虑到GC时间,我估计这个超时时间没法设置这么短。在Leader做写入时也是一个两阶段提交的过程。首先leader会把在自己的log中找到第一个空位index写入,并通过AppendEntries这个RPC把这个entry的值发给每个follower,如果收到半数以上的follower(包括自己)回复true,则再下一个AppendEntries中,leader会把committedIndex加1,代表写入的这个entry已经被提交。如在下图中,leader将x=4写入index=8的这个entry中,并把他发送给了所有follower,在收到第一台(自己),第三台,第五台(图中没有画index=8的entry,但因为这台服务器之前所有的entry都和leader保持了一致,因此它一定会投同意),那么leader就获得了多数票,再下一个rpc中,会将Committed index往前挪一位,代表index<=8的所有entry都已经提交。至于第二台和第四台服务器,log内容已经明显落后,这要么是因为前几次rpc没有成功。leader会无限重试直到这些follower和leader的日志追平。另外一个可能是这两台服务器重启过,处于恢复状态。那么这两台服务器在收到写入index=8的RPC时,follower也会把上一个entry的term和index发给他们。也就是说prevLogIndex=7,prevLogTerm=3这个信息会发给第二台服务器,那么对于第二台服务器,index=7的entry是空的,也就是log和leader不一致,他会返回一个false给leader,leader会不停地从后往前遍历,直到找到一个entry与第二台服务器一致的,从这个点开始重新把leader的log内容发送给该follower,即可完成恢复。raft协议保证了所有成员的replicated log中每个index位置,如果他们的term一致,内容也一定一致。如果不一致,leader一定会把这个index的内容改写成和leader一致。其实经过刚才我的一些描述,基本上就已经把Raft的选主,写入流程和恢复基本上都讲完了。从这里,我们可以看出Raft一些非常有意思的地方。第一个有意思的地方是Raft的log的entry是可能被修改的,比如一个follower接收了一个leader的prepare请求,把值写入了一个index,而这个leader挂掉,新选出的leader可能会重新使用这个index,那么这个follower的相应index的内容,会被改写成新的内容。这样就造成了两个问题,首先第一个,raft的log无法在append-only的文件或者文件系统上去实现,而像ZAB,Paxos协议,log只会追加,只要求文件系统有append的能力即可,不需要随机访问修改能力。第二个有意思的地方是,为了简单,Raft中只维护了一个Committed index,也就是任何小于等于这个committedIndex的entry,都是被认为是commit过的。这样就会造成在写入过程中,在leader获得大多数选票之前挂掉(或者leader在写完自己的log之后还没来得及通知到任何follower就挂掉),重启后如果这个server继续被选为leader,这个值仍然会被commit永久生效。因为leader的log中有这个值,leader一定会保证所有的follower的log都和自己保持一致。而后续的写入在增长committedIndex后,这个值也默认被commit了。举例来说,现在有5台服务器,其中S2为leader,但是当他在为index=1的entry执行写入时,先写到了自己的log中,还没来得及通知其他server append entry就宕机了。 当S2重启后,任然有可能被重新当选leader,当S2重新当选leader后,仍然会把index=1的这个entry复制给每台服务器(但是不会往前移动Committed index)此时S2又发生一次写入,这次写入完成后,会把Committed index移动到2的位置,因此index=1的entry也被认为已经commit了。这个行为有点奇怪,因为这样等于raft会让一个没有获得大多数人同意的值最终commit。这个行为取决于leader,如果上面的例子中S2重启后没有被选为leader,index=1的entry内容会被新leader的内容覆盖,从而不会提交未经过表决的内容。虽然说这个行为是有点奇怪,但是不会造成任何问题,因为leader和follower还是会保持一致,而且在写入过程中leader挂掉,对客户端来说是本来就是一个未决语义,raft论文中也指出,如果用户想要exactly once的语义,可以在写入的时候加入一个类似uuid的东西,在写入之前leader查下这个uuid是否已经写入。那么在一定程度上,可以保证exactly once的语义。Raft的论文中也比较了ZAB的算法,文中说ZAB协议的一个缺点是在恢复阶段需要leader和follower来回交换数据,这里我没太明白,据我理解,ZAB在重新选主的过程中,会选择Zxid最大的那个从成为主,而其他follower会从leader这里补全数据,并不会出现leader从follower节点补数据这一说。后话目前,经过改进的Paxos协议已经用在了许多分布式产品中,比如说Chubby,PaxosStore,阿里云的X-DB,以及蚂蚁的OceanBase,都选用了Paxos协议,但他们都多多少少做了一些补充和改进。而像Raft协议,普遍认为Raft协议只能顺序commit entry,性能没有Paxos好,但是TiKV中使用了Raft,其公开的文章宣传对Raft做了非常多的优化,使Raft的性能变的非常可观。阿里的另外一个数据库PolarDB,也是使用了改进版的Parallel-Raft,使Raft实现了并行提交的能力。相信未来会有更多的基于Paxos/Raft的产品会面世,同时也对Raft/Paxos也会有更多的改进。参考文献《Time, clocks, and the ordering of events in a distributed system》《Implementing fault-tolerant services using the state machine approach- A tutorial》《Paxos Made Simple》《Paxos made live- An engineering perspective》《Multi-Paxos》(Standford大学的一个ppt)《Zab- High-performance broadcast for primary-backup systems》《In search of an understandable consensus algorithm》(raft)本文作者:正研阅读原文本文为云栖社区原创内容,未经允许不得转载。 ...

February 19, 2019 · 1 min · jiezi

react-native-storage文档介绍

中文doc:仅供参考import Storage from ‘react-native-storage’;import {AsyncStorage} from ‘react-native’;var storage = new Storage({ // 最大容量,默认值1000条数据循环存储 size: 1000, // 存储引擎:对于RN使用AsyncStorage,对于web使用window.localStorage // 如果不指定则数据只会保存在内存中,重启后即丢失 storageBackend: AsyncStorage, // 数据过期时间,默认一整天(1000 * 3600 * 24 毫秒),设为null则永不过期 defaultExpires: 1000 * 3600 * 24, // 读写时在内存中缓存数据。默认启用。 enableCache: true, // 如果storage中没有相应数据,或数据已过期, // 则会调用相应的sync方法,无缝返回最新数据。 // sync方法的具体说明会在后文提到 // 你可以在构造函数这里就写好sync的方法 // 或是在任何时候,直接对storage.sync进行赋值修改 // 或是写到另一个文件里,这里require引入 // sync: require(‘你可以另外写一个文件专门处理sync’)})// 最好在全局范围内创建一个(且只有一个)storage实例,方便直接调用// 对于web// window.storage = storage;// 对于react native// global.storage = storage;// 这样,在此之后的任意位置即可以直接调用storage// 注意:全局变量一定是先声明,后使用// 如果你在某处调用storage报错未定义// 请检查global.storage = storage语句是否确实已经执行过了// 使用key来保存数据。这些数据一般是全局独有的,常常需要调用的。// 除非你手动移除,这些数据会被永久保存,而且默认不会过期。storage.save({ key: ’loginState’, // 注意:请不要在key中使用_下划线符号! data: { from: ‘some other site’, userid: ‘some userid’, token: ‘some token’ }, // 如果不指定过期时间,则会使用defaultExpires参数 // 如果设为null,则永不过期 expires: 1000 * 3600});// 读取storage.load({ key: ’loginState’, // autoSync(默认为true)意味着在没有找到数据或数据过期时自动调用相应的sync方法 autoSync: true, // syncInBackground(默认为true)意味着如果数据过期, // 在调用sync方法的同时先返回已经过期的数据。 // 设置为false的话,则等待sync方法提供的最新数据(当然会需要更多时间)。 syncInBackground: true, // 你还可以给sync方法传递额外的参数 syncParams: { extraFetchOptions: { // 各种参数 }, someFlag: true, },}).then(ret => { // 如果找到数据,则在then方法中返回 // 注意:这是异步返回的结果(不了解异步请自行搜索学习) // 你只能在then这个方法内继续处理ret数据 // 而不能在then以外处理 // 也没有办法“变成”同步返回 // 你也可以使用“看似”同步的async/await语法 console.log(ret.userid); this.setState({user: ret});}).catch(err => { //如果没有找到数据且没有sync方法, //或者有其他异常,则在catch中返回 console.warn(err.message); switch (err.name) { case ‘NotFoundError’: // TODO; break; case ‘ExpiredError’: // TODO break; }})// 使用key和id来保存数据,一般是保存同类别(key)的大量数据。// 所有这些"key-id"数据共有一个保存上限(无论是否相同key)// 即在初始化storage时传入的size参数。// 在默认上限参数下,第1001个数据会覆盖第1个数据。// 覆盖之后,再读取第1个数据,会返回catch或是相应的sync方法。var userA = { name: ‘A’, age: 20, tags: [ ‘geek’, ’nerd’, ‘otaku’ ]};storage.save({ key: ‘user’, // 注意:请不要在key中使用_下划线符号! id: ‘1001’, // 注意:请不要在id中使用_下划线符号! data: userA, expires: 1000 * 60});//load 读取storage.load({ key: ‘user’, id: ‘1001’}).then(ret => { // 如果找到数据,则在then方法中返回 console.log(ret.userid);}).catch(err => { // 如果没有找到数据且没有sync方法, // 或者有其他异常,则在catch中返回 console.warn(err.message); switch (err.name) { case ‘NotFoundError’: // TODO; break; case ‘ExpiredError’: // TODO break; }})// ————————————————–// 获取某个key下的所有idstorage.getIdsForKey(‘user’).then(ids => { console.log(ids);});// 获取某个key下的所有数据storage.getAllDataForKey(‘user’).then(users => { console.log(users);});// !! 清除某个key下的所有数据storage.clearMapForKey(‘user’);// ————————————————–// 删除单个数据storage.remove({ key: ’lastPage’});storage.remove({ key: ‘user’, id: ‘1001’});// !! 清空map,移除所有"key-id"数据(但会保留只有key的数据)storage.clearMap();//同步远程数据(刷新)storage.sync = { // sync方法的名字必须和所存数据的key完全相同 // 方法接受的参数为一整个object,所有参数从object中解构取出 // 这里可以使用promise。或是使用普通回调函数,但需要调用resolve或reject。 user(params){ let {id, resolve, reject, syncParams: {extraFetchOptions, someFlag}} = params; fetch(‘user/’, { method: ‘GET’, body: ‘id=’ + id, …extraFetchOptions, }).then(response => { return response.json(); }).then(json => { //console.log(json); if (json && json.user) { storage.save({ key: ‘user’, id, data: json.user }); if (someFlag) { // 根据syncParams中的额外参数做对应处理 } // 成功则调用resolve resolve && resolve(json.user); } else { // 失败则调用reject reject && reject(new Error(‘data parse error’)); } }).catch(err => { console.warn(err); reject && reject(err); }); }}//有了上面这个sync方法,以后再调用storage.load时,如果本地并没有存储相应的user,那么会自动触发storage.sync.user去远程取回数据并无缝返回。storage.load({ key: ‘user’, id: ‘1002’}).then()//读取批量数据// 使用和load方法一样的参数读取批量数据,但是参数是以数组的方式提供。// 会在需要时分别调用相应的sync方法,最后统一返回一个有序数组。storage.getBatchData([ {key: ’loginState’}, {key: ‘checkPoint’, syncInBackground: false}, {key: ‘balance’}, {key: ‘user’, id: ‘1009’}]) .then(results => { results.forEach(result => { console.log(result); }) })//根据key和一个id数组来读取批量数据storage.getBatchDataWithIds({ key: ‘user’, ids: [‘1001’, ‘1002’, ‘1003’]}) .then()/* 这两个方法除了参数形式不同,还有个值得注意的差异。getBatchData会在数据缺失时挨个调用不同的sync方法(因为key不同)。 但是getBatchDataWithIds却会把缺失的数据统计起来,将它们的id收集到一个数组中,然后一次传递给对应的sync方法(避免挨个查询导致同时发起大量请求), 所以你需要在服务端实现通过数组来查询返回,还要注意对应的sync方法的参数处理(因为id参数可能是一个字符串,也可能是一个数组的字符串)。 */ ...

December 17, 2018 · 2 min · jiezi

阿里云HBase全新发布X-Pack 赋能轻量级大数据平台

一、八年双十一,造就国内最大最专业HBase技术团队阿里巴巴集团早在2010开始研究并把HBase投入生产环境使用,从最初的淘宝历史交易记录,到蚂蚁安全风控数据存储。持续8年的投入,历经8年双十一锻炼。4个PMC,6个committer,造就了国内最大最专业的HBase技术团队,其中HBase内核中超过200+重要的feature是阿里贡献。集团内部超过万台的规模,单集群超过千台,全球领先。二、HBase技术团队重磅发布X-Pack,重新赋能轻量级大数据平台阿里云自从17年8月提供HBase云服务以来,到18年12月累计服务了上千大B客户,已经有上千个在线的集群。是阿里云增长最为快速的数据库服务,也是大B客户比例最高的云服务之一。并于6月6日全球第一个推出HBase 2.0,是HBase领域当之无愧的排头兵。为了满足客户对数据库更丰富业务处理需求、更易用、强大功能的需求,我们重磅发布 X-Pack :支持SQL、时序、时空、图、全文检索能力、及复杂分析。阿里云HBase从KV为主大数据数据库成功进化成“轻量级全托管大数据平台”数据库。全部能力计划12月底全部上线。三、深度解读 “ 轻量级全托管大数据平台 ”,云HBase能力再上新台阶通常一个大企业里面,数据和业务存在天然的多样性。真正称得上平台级的数据库,要至少要满足客户不同三个及以上层次的诉求,才能称的上平台级。阿里云HBase从成本最优化、运维便利性、业务敏捷度三个方面将HBase的能力全面提升一个高度,成就轻量级全托管大数据平台,云HBase能力再上新台阶。3.1 轻量级,满足CXO成本最优化的诉求1)起步成本低,整体成本低,扩展性强。云HBase针对企业不同的使用环境,不同的SLA诉求,云HBase一共提供3个版本,分别满足开发环境,在线业务,以及金融级业务的诉求。单节点版本,低廉的价格用于开发测试场景,集群版本,99.9%可用,满足企业在线业务诉求,支持最高5000万的QPS和10P的数据。还有支持金融级高可用的双活版本。所有版本都支持11个9的数据可靠性,无需担心数据丢失。2)支持冷存储,助你不改代码,1/3成本轻松搞定冷数据处理大数据场景下,存储成本占比往往是大头,把存储成本降下来,整体成本才能下降。一般随着业务的发展,HBase中存储的数据量会逐渐变大。在这些数据中,业务最关心的,最常访问的,往往是某些特定范围的数据,比如说最近7天的数据,业务对这类数据访问频次高,延迟要求高,即所谓的热数据。而其他的数据,一般访问量极少,性能要求不高, 但这类数据往往数据量大,即冷数据。如果能把冷热数据分离开,把热数据存储在性能更好的介质中,而把庞大的冷数据放到成本更低的介质中,从而实现把更多优质资源用来提高热数据的读写性能,同时节省存储成本的目的。阿里云HBase针对冷数据存储的场景,提供一种新的冷存储介质,其存储成本仅为高效云盘的1/3,写入性能与云盘相当,并能保证数据随时可读。冷存储的使用非常简单,用户可以在购买云HBase实例时选择冷存储作为一个附加的存储空间,并通过建表语句指定将冷数据存放在冷存储介质上面,从而降低存储成本,基本不用改代码就获得了低成本存储能力,助力企业降低整体成本。3.2 全托管,全面解放运维,为业务稳定保驾护航大数据时代,数据是企业最宝贵的资产,业务是企业赖以生存的基础。因此高可用和高可靠是最基本诉求。云HBase提供的全托管服务相比其他的半托管服务以及自建存在天然的优势。依托持续8年在内核和管控平台的研究,以及大量配套的监控工具、跨可用区,跨域容灾多活方案,云HBase提供目前业界最高的4个9的可用性(双集群),11个9的可靠性的高SLA的支持,满足众多企业客户对平台高可用、稳定性的诉求。云HBase服务定位为全托管服务,后台自动代维和保持服务稳定性,极大的降低了客户使用门槛,让无论是SME,还是巨头都能享受到HBase技术红利。选择云HBase就是选择了高可用、高可靠服务!3.3 全面能力提升,源头解决业务敏捷度,真正释放数据和业务的价值1)100%兼容原生接口和能力,开发简单,容易上手。云HBase百分百兼容开源接口,并提供一系列配套开发,数据搬迁,监控工具,全面帮助用户提高开发和管理效率。2)独家跨Region/AZ双活阿里云是云HBase首家推出跨Region/AZ双活,在一个集群出现故障的时候,迅速地将业务切换至另外一个集群从而避免故障。HBase主备之间数据的同步基于异步链路实现,遵循最终一致性协议,典型的主备同步延迟在200ms左右。满足金融、社交、电商、人工智能等关键领域对高可用的诉求。3)备份恢复量级提升百倍以上,数据库领域最大我们经常会听到“某某某DBA误操作把整张表删了”,“某某磁盘故障,造成数据库的某个库的数据全部损坏了”。这种由于外在和内在的原因造成的数据不可靠,最终会给用户带来毁灭性的灾难。所以一个企业级数据库,全量备份、全量恢复、增量备份、增量恢复,是基础能力。传统数据库备份恢复的能力都是TB级别,这在交易等场景下面是足够的,但是面向大数据场景就捉襟见肘了。云HBase通过垂直整合高压缩、内核级优化,分布式处理等能力,将备份恢复的量级成功推高百倍以上,做到百TB级别甚至更高,让客户大数据量下面也无后顾之忧。4)支持融合多模型和融合多负载、提供开箱即用的能力云HBase在KV的基础上,同时支持时序、时空、图、文档等多种数据模型,内置丰富处理能力,让业务开发效率提升百倍。在线能力的基础上,融合流处理、批处理、OLAP,OLTP、高速对象存储,全文检索等能力,提供客户融合业务开箱即用的能力。四、展望未来,持续优化服务,不负重托,成就客户历经近8年的技术沉淀,阿里巴巴大数据NoSQL数据库处理技术的精华沉淀在HBase上,后者成功支撑了成功支撑了阿里经济体中最大的NoSQL业务体量,是阿里大数据处理技术的核心组成部分,当前将这项技术应用到广大企业中,助力企业发现数据价值。短短1年间,就覆盖了社交、金融、政企、车联网、交通、物流、零售、电商等数十个个行业,帮单用户顶住千万级QPS的业务压力,以及百PB级数据高效存储和处理。本文作者:所在jason阅读原文本文为云栖社区原创内容,未经允许不得转载。

December 6, 2018 · 1 min · jiezi

Data Lake Analytics + OSS数据文件格式处理大全

前言Data Lake Analytics是Serverless化的云上交互式查询分析服务。用户可以使用标准的SQL语句,对存储在OSS、TableStore上的数据无需移动,直接进行查询分析。目前该产品已经正式登陆阿里云,欢迎大家申请试用,体验更便捷的数据分析服务。请参考https://help.aliyun.com/document_detail/70386.html 进行产品开通服务申请。在上一篇教程中,我们介绍了如何分析CSV格式的TPC-H数据集。除了纯文本文件(例如,CSV,TSV等),用户存储在OSS上的其他格式的数据文件,也可以使用Data Lake Analytics进行查询分析,包括ORC, PARQUET, JSON, RCFILE, AVRO甚至ESRI规范的地理JSON数据,还可以用正则表达式匹配的文件等。本文详细介绍如何根据存储在OSS上的文件格式使用Data Lake Analytics (下文简称 DLA)进行分析。DLA内置了各种处理文件数据的SerDe(Serialize/Deserilize的简称,目的是用于序列化和反序列化)实现,用户无需自己编写程序,基本上能选用DLA中的一款或多款SerDe来匹配您OSS上的数据文件格式。如果还不能满足您特殊文件格式的处理需求,请联系我们,尽快为您实现。1. 存储格式与SerDe用户可以依据存储在OSS上的数据文件进行建表,通过STORED AS 指定数据文件的格式。例如,CREATE EXTERNAL TABLE nation ( N_NATIONKEY INT, N_NAME STRING, N_REGIONKEY INT, N_COMMENT STRING) ROW FORMAT DELIMITED FIELDS TERMINATED BY ‘|’ STORED AS TEXTFILE LOCATION ‘oss://test-bucket-julian-1/tpch_100m/nation’;建表成功后可以使用SHOW CREATE TABLE语句查看原始建表语句。mysql> show create table nation;+———————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————–+| Result |+———————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————–+| CREATE EXTERNAL TABLE nation( n_nationkey int, n_name string, n_regionkey int, n_comment string)ROW FORMAT DELIMITED FIELDS TERMINATED BY ‘|‘STORED AS TEXTFILELOCATION ‘oss://test-bucket-julian-1/tpch_100m/nation’|+———————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————–+1 row in set (1.81 sec)下表中列出了目前DLA已经支持的文件格式,当针对下列格式的文件建表时,可以直接使用STORED AS,DLA会选择合适的SERDE/INPUTFORMAT/OUTPUTFORMAT。在指定了STORED AS 的同时,还可以根据具体文件的特点,指定SerDe (用于解析数据文件并映射到DLA表),特殊的列分隔符等。后面的部分会做进一步的讲解。2. 示例2.1 CSV文件CSV文件,本质上还是纯文本文件,可以使用STORED AS TEXTFILE。列与列之间以逗号分隔,可以通过ROW FORMAT DELIMITED FIELDS TERMINATED BY ‘,’ 表示。普通CSV文件例如,数据文件oss://bucket-for-testing/oss/text/cities/city.csv的内容为Beijing,China,010ShangHai,China,021Tianjin,China,022建表语句可以为CREATE EXTERNAL TABLE city ( city STRING, country STRING, code INT) ROW FORMAT DELIMITED FIELDS TERMINATED BY ‘,’ STORED AS TEXTFILE LOCATION ‘oss://bucket-for-testing/oss/text/cities’;使用OpenCSVSerde__处理引号__引用的字段OpenCSVSerde在使用时需要注意以下几点:用户可以为行的字段指定字段分隔符、字段内容引用符号和转义字符,例如:WITH SERDEPROPERTIES (“separatorChar” = “,”, “quoteChar” = “`”, “escapeChar” = "" );不支持字段内嵌入的行分割符;所有字段定义STRING类型;其他数据类型的处理,可以在SQL中使用函数进行转换。例如,CREATE EXTERNAL TABLE test_csv_opencsvserde ( id STRING, name STRING, location STRING, create_date STRING, create_timestamp STRING, longitude STRING, latitude STRING) ROW FORMAT SERDE ‘org.apache.hadoop.hive.serde2.OpenCSVSerde’with serdeproperties(“separatorChar”=",",“quoteChar”=""",“escapeChar”="\")STORED AS TEXTFILE LOCATION ‘oss://test-bucket-julian-1/test_csv_serde_1’;自定义分隔符需要自定义列分隔符(FIELDS TERMINATED BY),转义字符(ESCAPED BY),行结束符(LINES TERMINATED BY)。需要在建表语句中指定ROW FORMAT DELIMITED FIELDS TERMINATED BY ‘\t’ ESCAPED BY ‘\’ LINES TERMINATED BY ‘\n’忽略CSV文件中的HEADER在csv文件中,有时会带有HEADER信息,需要在数据读取时忽略掉这些内容。这时需要在建表语句中定义skip.header.line.count。例如,数据文件oss://my-bucket/datasets/tpch/nation_csv/nation_header.tbl的内容如下:N_NATIONKEY|N_NAME|N_REGIONKEY|N_COMMENT0|ALGERIA|0| haggle. carefully final deposits detect slyly agai|1|ARGENTINA|1|al foxes promise slyly according to the regular accounts. bold requests alon|2|BRAZIL|1|y alongside of the pending deposits. carefully special packages are about the ironic forges. slyly special |3|CANADA|1|eas hang ironic, silent packages. slyly regular packages are furiously over the tithes. fluffily bold|4|EGYPT|4|y above the carefully unusual theodolites. final dugouts are quickly across the furiously regular d|5|ETHIOPIA|0|ven packages wake quickly. regu|相应的建表语句为:CREATE EXTERNAL TABLE nation_header ( N_NATIONKEY INT, N_NAME STRING, N_REGIONKEY INT, N_COMMENT STRING) ROW FORMAT DELIMITED FIELDS TERMINATED BY ‘|’ STORED AS TEXTFILE LOCATION ‘oss://my-bucket/datasets/tpch/nation_csv/nation_header.tbl’TBLPROPERTIES (“skip.header.line.count”=“1”);skip.header.line.count的取值x和数据文件的实际行数n有如下关系:当x<=0时,DLA在读取文件时,不会过滤掉任何信息,即全部读取;当0当x>=n时,DLA在读取文件时,会过滤掉所有的文件内容。2.2 TSV文件与CSV文件类似,TSV格式的文件也是纯文本文件,列与列之间的分隔符为Tab。例如,数据文件oss://bucket-for-testing/oss/text/cities/city.tsv的内容为Beijing China 010ShangHai China 021Tianjin China 022建表语句可以为CREATE EXTERNAL TABLE city ( city STRING, country STRING, code INT) ROW FORMAT DELIMITED FIELDS TERMINATED BY ‘\t’ STORED AS TEXTFILE LOCATION ‘oss://bucket-for-testing/oss/text/cities’;2.3 多字符数据字段分割符文件假设您的数据字段的分隔符包含多个字符,可采用如下示例建表语句,其中每行的数据字段分割符为“||”,可以替换为您具体的分割符字符串。ROW FORMAT SERDE ‘org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe’with serdeproperties(“field.delim”="||")示例:CREATE EXTERNAL TABLE test_csv_multidelimit ( id STRING, name STRING, location STRING, create_date STRING, create_timestamp STRING, longitude STRING, latitude STRING) ROW FORMAT SERDE ‘org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe’with serdeproperties(“field.delim”="||")STORED AS TEXTFILE LOCATION ‘oss://bucket-for-testing/oss/text/cities/’;2.4 JSON文件DLA可以处理的JSON文件通常以纯文本的格式存储,在建表时除了要指定STORED AS TEXTFILE, 还要定义SERDE。在JSON文件中,每行必须是一个完整的JSON对象。例如,下面的文件格式是不被接受的{“id”: 123, “name”: “jack”, “c3”: “2001-02-03 12:34:56”}{“id”: 456, “name”: “rose”, “c3”: “1906-04-18 05:12:00”}{“id”: 789, “name”: “tom”, “c3”: “2001-02-03 12:34:56”}{“id”: 234, “name”: “alice”, “c3”: “1906-04-18 05:12:00”}需要改写成:{“id”: 123, “name”: “jack”, “c3”: “2001-02-03 12:34:56”}{“id”: 456, “name”: “rose”, “c3”: “1906-04-18 05:12:00”}{“id”: 789, “name”: “tom”, “c3”: “2001-02-03 12:34:56”}{“id”: 234, “name”: “alice”, “c3”: “1906-04-18 05:12:00”}不含嵌套的JSON数据建表语句可以写CREATE EXTERNAL TABLE t1 (id int, name string, c3 timestamp)STORED AS JSONLOCATION ‘oss://path/to/t1/directory’;含有嵌套的JSON文件使用struct和array结构定义嵌套的JSON数据。例如,用户原始数据(注意:无论是否嵌套,一条完整的JSON数据都只能放在一行上,才能被Data Lake Analytics处理):{ “DocId”: “Alibaba”, “User_1”: { “Id”: 1234, “Username”: “bob1234”, “Name”: “Bob”, “ShippingAddress”: { “Address1”: “969 Wenyi West St.”, “Address2”: null, “City”: “Hangzhou”, “Province”: “Zhejiang” }, “Orders”: [{ “ItemId”: 6789, “OrderDate”: “11/11/2017” }, { “ItemId”: 4352, “OrderDate”: “12/12/2017” } ] } }使用在线JSON格式化工具格式化后,数据内容如下:{ “DocId”: “Alibaba”, “User_1”: { “Id”: 1234, “Username”: “bob1234”, “Name”: “Bob”, “ShippingAddress”: { “Address1”: “969 Wenyi West St.”, “Address2”: null, “City”: “Hangzhou”, “Province”: “Zhejiang” }, “Orders”: [ { “ItemId”: 6789, “OrderDate”: “11/11/2017” }, { “ItemId”: 4352, “OrderDate”: “12/12/2017” } ] }}则建表语句可以写成如下(注意:LOCATION中指定的路径必须是JSON数据文件所在的目录,该目录下的所有JSON文件都能被识别为该表的数据):CREATE EXTERNAL TABLE json_table_1 ( docid string, user_1 struct< id:INT, username:string, name:string, shippingaddress:struct< address1:string, address2:string, city:string, province:string >, orders:array< struct< itemid:INT, orderdate:string > > >)STORED AS JSONLOCATION ‘oss://xxx/test/json/hcatalog_serde/table_1/’;对该表进行查询:select * from json_table_1;+———+—————————————————————————————————————-+| docid | user_1 |+———+—————————————————————————————————————-+| Alibaba | [1234, bob1234, Bob, [969 Wenyi West St., null, Hangzhou, Zhejiang], [[6789, 11/11/2017], [4352, 12/12/2017]]] |+———+—————————————————————————————————————-+对于struct定义的嵌套结构,可以通过“.”进行层次对象引用,对于array定义的数组结构,可以通过“[数组下标]”(注意:数组下标从1开始)进行对象引用。select DocId, User_1.Id, User_1.ShippingAddress.Address1, User_1.Orders[1].ItemIdfrom json_table_1where User_1.Username = ‘bob1234’ and User_1.Orders[2].OrderDate = ‘12/12/2017’;+———+——+——————–+——-+| DocId | id | address1 | _col3 |+———+——+——————–+——-+| Alibaba | 1234 | 969 Wenyi West St. | 6789 |+———+——+——————–+——-+使用JSON函数处理数据例如,把“value_string”的嵌套JSON值作为字符串存储:{“data_key”:“com.taobao.vipserver.domains.meta.biz.alibaba.com”,“ts”:1524550275112,“value_string”:"{"appName":"","apps":[],"checksum":"50fa0540b430904ee78dff07c7350e1c","clusterMap":{"DEFAULT":{"defCkport":80,"defIPPort":80,"healthCheckTask":null,"healthChecker":{"checkCode":200,"curlHost":"","curlPath":"/status.taobao","type":"HTTP"},"name":"DEFAULT","nodegroup":"","sitegroup":"","submask":"0.0.0.0/0","syncConfig":{"appName":"trade-ma","nodegroup":"tradema","pubLevel":"publish","role":"","site":""},"useIPPort4Check":true}},"disabledSites":[],"enableArmoryUnit":false,"enableClientBeat":false,"enableHealthCheck":true,"enabled":true,"envAndSites":"","invalidThreshold":0.6,"ipDeleteTimeout":1800000,"lastModifiedMillis":1524550275107,"localSiteCall":true,"localSiteThreshold":0.8,"name":"biz.alibaba.com","nodegroup":"","owners":["junlan.zx","张三","李四","cui.yuanc"],"protectThreshold":0,"requireSameEnv":false,"resetWeight":false,"symmetricCallType":null,"symmetricType":"warehouse","tagName":"ipGroup","tenantId":"","tenants":[],"token":"1cf0ec0c771321bb4177182757a67fb0","useSpecifiedURL":false}"}使用在线JSON格式化工具格式化后,数据内容如下:{ “data_key”: “com.taobao.vipserver.domains.meta.biz.alibaba.com”, “ts”: 1524550275112, “value_string”: “{"appName":"","apps":[],"checksum":"50fa0540b430904ee78dff07c7350e1c","clusterMap":{"DEFAULT":{"defCkport":80,"defIPPort":80,"healthCheckTask":null,"healthChecker":{"checkCode":200,"curlHost":"","curlPath":"/status.taobao","type":"HTTP"},"name":"DEFAULT","nodegroup":"","sitegroup":"","submask":"0.0.0.0/0","syncConfig":{"appName":"trade-ma","nodegroup":"tradema","pubLevel":"publish","role":"","site":""},"useIPPort4Check":true}},"disabledSites":[],"enableArmoryUnit":false,"enableClientBeat":false,"enableHealthCheck":true,"enabled":true,"envAndSites":"","invalidThreshold":0.6,"ipDeleteTimeout":1800000,"lastModifiedMillis":1524550275107,"localSiteCall":true,"localSiteThreshold":0.8,"name":"biz.alibaba.com","nodegroup":"","owners":["junlan.zx","张三","李四","cui.yuanc"],"protectThreshold":0,"requireSameEnv":false,"resetWeight":false,"symmetricCallType":null,"symmetricType":"warehouse","tagName":"ipGroup","tenantId":"","tenants":[],"token":"1cf0ec0c771321bb4177182757a67fb0","useSpecifiedURL":false}"}建表语句为CREATE external TABLE json_table_2 ( data_key string, ts bigint, value_string string)STORED AS JSONLOCATION ‘oss://xxx/test/json/hcatalog_serde/table_2/’;表建好后,可进行查询:select * from json_table_2;+—————————————————+—————+————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————+| data_key | ts | value_string |+—————————————————+—————+————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————+| com.taobao.vipserver.domains.meta.biz.alibaba.com | 1524550275112 | {“appName”:”",“apps”:[],“checksum”:“50fa0540b430904ee78dff07c7350e1c”,“clusterMap”:{“DEFAULT”:{“defCkport”:80,“defIPPort”:80,“healthCheckTask”:null,“healthChecker”:{“checkCode”:200,“curlHost”:"",“curlPath”:"/status.taobao",“type”:“HTTP”},“name”:“DEFAULT”,“nodegroup”:"",“sitegroup”:"",“submask”:“0.0.0.0/0”,“syncConfig”:{“appName”:“trade-ma”,“nodegroup”:“tradema”,“pubLevel”:“publish”,“role”:"",“site”:""},“useIPPort4Check”:true}},“disabledSites”:[],“enableArmoryUnit”:false,“enableClientBeat”:false,“enableHealthCheck”:true,“enabled”:true,“envAndSites”:"",“invalidThreshold”:0.6,“ipDeleteTimeout”:1800000,“lastModifiedMillis”:1524550275107,“localSiteCall”:true,“localSiteThreshold”:0.8,“name”:“biz.alibaba.com”,“nodegroup”:"",“owners”:[“junlan.zx”,“张三”,“李四”,“cui.yuanc”],“protectThreshold”:0,“requireSameEnv”:false,“resetWeight”:false,“symmetricCallType”:null,“symmetricType”:“warehouse”,“tagName”:“ipGroup”,“tenantId”:"",“tenants”:[],“token”:“1cf0ec0c771321bb4177182757a67fb0”,“useSpecifiedURL”:false} |+—————————————————+—————+————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————+下面SQL示例json_parse,json_extract_scalar,json_extract等常用JSON函数的使用方式:mysql> select json_extract_scalar(json_parse(value), ‘$.owners[1]’) from json_table_2;+——–+| _col0 |+——–+| 张三 |+——–+mysql> select json_extract_scalar(json_obj.json_col, ‘$.DEFAULT.submask’) from ( select json_extract(json_parse(value), ‘$.clusterMap’) as json_col from json_table_2) json_objwhere json_extract_scalar(json_obj.json_col, ‘$.DEFAULT.healthChecker.curlPath’) = ‘/status.taobao’;+———–+| _col0 |+———–+| 0.0.0.0/0 |+———–+mysql> with json_obj as (select json_extract(json_parse(value), ‘$.clusterMap’) as json_col from json_table_2)select json_extract_scalar(json_obj.json_col, ‘$.DEFAULT.submask’)from json_obj where json_extract_scalar(json_obj.json_col, ‘$.DEFAULT.healthChecker.curlPath’) = ‘/status.taobao’;+———–+| _col0 |+———–+| 0.0.0.0/0 |+———–+2.5 ORC文件Optimized Row Columnar(ORC)是Apache开源项目Hive支持的一种优化的列存储文件格式。与CSV文件相比,不仅可以节省存储空间,还可以得到更好的查询性能。对于ORC文件,只需要在建表时指定 STORED AS ORC。例如,CREATE EXTERNAL TABLE orders_orc_date ( O_ORDERKEY INT, O_CUSTKEY INT, O_ORDERSTATUS STRING, O_TOTALPRICE DOUBLE, O_ORDERDATE DATE, O_ORDERPRIORITY STRING, O_CLERK STRING, O_SHIPPRIORITY INT, O_COMMENT STRING) STORED AS ORC LOCATION ‘oss://bucket-for-testing/datasets/tpch/1x/orc_date/orders_orc’;2.6 PARQUET文件Parquet是Apache开源项目Hadoop支持的一种列存储的文件格式。使用DLA建表时,需要指定STORED AS PARQUET即可。例如,CREATE EXTERNAL TABLE orders_parquet_date ( O_ORDERKEY INT, O_CUSTKEY INT, O_ORDERSTATUS STRING, O_TOTALPRICE DOUBLE, O_ORDERDATE DATE, O_ORDERPRIORITY STRING, O_CLERK STRING, O_SHIPPRIORITY INT, O_COMMENT STRING) STORED AS PARQUET LOCATION ‘oss://bucket-for-testing/datasets/tpch/1x/parquet_date/orders_parquet’;2.7 RCFILE文件Record Columnar File (RCFile), 列存储文件,可以有效地将关系型表结构存储在分布式系统中,并且可以被高效地读取和处理。DLA在建表时,需要指定STORED AS RCFILE。例如,CREATE EXTERNAL TABLE lineitem_rcfile_date ( L_ORDERKEY INT, L_PARTKEY INT, L_SUPPKEY INT, L_LINENUMBER INT, L_QUANTITY DOUBLE, L_EXTENDEDPRICE DOUBLE, L_DISCOUNT DOUBLE, L_TAX DOUBLE, L_RETURNFLAG STRING, L_LINESTATUS STRING, L_SHIPDATE DATE, L_COMMITDATE DATE, L_RECEIPTDATE DATE, L_SHIPINSTRUCT STRING, L_SHIPMODE STRING, L_COMMENT STRING) STORED AS RCFILELOCATION ‘oss://bucke-for-testing/datasets/tpch/1x/rcfile_date/lineitem_rcfile'2.8 AVRO文件DLA针对AVRO文件建表时,需要指定STORED AS AVRO,并且定义的字段需要符合AVRO文件的schema。如果不确定可以通过使用Avro提供的工具,获得schema,并根据schema建表。在Apache Avro官网下载avro-tools-.jar到本地,执行下面的命令获得Avro文件的schema:java -jar avro-tools-1.8.2.jar getschema /path/to/your/doctors.avro{ “type” : “record”, “name” : “doctors”, “namespace” : “testing.hive.avro.serde”, “fields” : [ { “name” : “number”, “type” : “int”, “doc” : “Order of playing the role” }, { “name” : “first_name”, “type” : “string”, “doc” : “first name of actor playing role” }, { “name” : “last_name”, “type” : “string”, “doc” : “last name of actor playing role” } ]}建表语句如下,其中fields中的name对应表中的列名,type需要参考本文档中的表格转成hive支持的类型CREATE EXTERNAL TABLE doctors(number int,first_name string,last_name string)STORED AS AVROLOCATION ‘oss://mybucket-for-testing/directory/to/doctors’;大多数情况下,Avro的类型可以直接转换成Hive中对应的类型。如果该类型在Hive不支持,则会转换成接近的类型。具体请参照下表:2.9 可以用正则表达式匹配的文件通常此类型的文件是以纯文本格式存储在OSS上的,每一行代表表中的一条记录,并且每行可以用正则表达式匹配。例如,Apache WebServer日志文件就是这种类型的文件。某日志文件的内容为:127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] “GET /apache_pb.gif HTTP/1.0” 200 2326127.0.0.1 - - [26/May/2009:00:00:00 +0000] “GET /someurl/?track=Blabla(Main) HTTP/1.1” 200 5864 - “Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/1.0.154.65 Safari/525.19"每行文件可以用下面的正则表达式表示,列之间使用空格分隔:([^ ]) ([^ ]) ([^ ]) (-|\[[^\]]\]) ([^ "]|"[^"]") (-|[0-9]) (-|[0-9])(?: ([^ "]|"[^"]") ([^ "]|"[^"]"))?针对上面的文件格式,建表语句可以表示为:CREATE EXTERNAL TABLE serde_regex( host STRING, identity STRING, userName STRING, time STRING, request STRING, status STRING, size INT, referer STRING, agent STRING)ROW FORMAT SERDE ‘org.apache.hadoop.hive.serde2.RegexSerDe’WITH SERDEPROPERTIES ( “input.regex” = “([^ ]) ([^ ]) ([^ ]) (-|\[[^\]]\]) ([^ "]|"[^"]") (-|[0-9]) (-|[0-9])(?: ([^ "]|"[^"]") ([^ "]|"[^"]"))?")STORED AS TEXTFILELOCATION ‘oss://bucket-for-testing/datasets/serde/regex’;查询结果mysql> select * from serde_regex;+———–+———-+——-+——————————+———————————————+——–+——+———+————————————————————————————————————————–+| host | identity | userName | time | request | status | size | referer | agent |+———–+———-+——-+——————————+———————————————+——–+——+———+————————————————————————————————————————–+| 127.0.0.1 | - | frank | [10/Oct/2000:13:55:36 -0700] | “GET /apache_pb.gif HTTP/1.0” | 200 | 2326 | NULL | NULL || 127.0.0.1 | - | - | [26/May/2009:00:00:00 +0000] | “GET /someurl/?track=Blabla(Main) HTTP/1.1” | 200 | 5864 | - | “Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/1.0.154.65 Safari/525.19” |+———–+———-+——-+——————————+———————————————+——–+——+———+————————————————————————————————————————–+2.10 Esri ArcGIS的地理JSON数据文件DLA支持Esri ArcGIS的地理JSON数据文件的SerDe处理,关于这种地理JSON数据格式说明,可以参考:https://github.com/Esri/spatial-framework-for-hadoop/wiki/JSON-Formats示例:CREATE EXTERNAL TABLE IF NOT EXISTS california_counties( Name string, BoundaryShape binary)ROW FORMAT SERDE ‘com.esri.hadoop.hive.serde.JsonSerde’STORED AS INPUTFORMAT ‘com.esri.json.hadoop.EnclosedJsonInputFormat’OUTPUTFORMAT ‘org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat’LOCATION ‘oss://test_bucket/datasets/geospatial/california-counties/‘3. 总结通过以上例子可以看出,DLA可以支持大部分开源存储格式的文件。对于同一份数据,使用不同的存储格式,在OSS中存储文件的大小,DLA的查询分析速度上会有较大的差别。推荐使用ORC格式进行文件的存储和查询。为了获得更快的查询速度,DLA还在不断的优化中,后续也会支持更多的数据源,为用户带来更好的大数据分析体验。本文作者:金络阅读原文本文为云栖社区原创内容,未经允许不得转载。

November 23, 2018 · 5 min · jiezi