• 关于

    高并发云原生计算

    的搜索结果

回答

SOFAStack™(Scalable Open Financial Architecture Stack)包含构建金融级云原生架构所需的各个组件,也是在金融场景里锤炼出来的最佳实践。提供项目管理、微服务应用开发、部署发布、监控运维、容灾高可用等全栈式解决方案,并兼容 Dubbo、Spring Cloud 等微服务运行环境,助力客户各类应用轻松转型分布式架构。 金融分布式架构SOFAStack(Scalable Open Financial Architecture Stack)的名称来自蚂蚁内部发展十多年的金融级分布式中间件SOFA(Service Oriented Fabric Architecture),代表着从支付宝创立之初就开始在关键金融交易系统锤炼出来的分布式架构实践。 SOFAStack所有的产品技术都经过蚂蚁金服自身严苛金融场景验证,为金融交易技术在保证风险安全的同时,帮助业务需求敏捷迭代,同时满足异地容灾、低成本快速扩容的需求,解决传统集中式架构转型的困难,打造大规模高可用分布式系统架构,支撑金融业务创新。为满足金融业务发展和严苛场景考验,让云计算更懂金融,SOFAStack有三大核心价值主张:开放、金融级、云原生。 • 全栈开放、开源共建 —- 源自蚂蚁金服实践演进沉淀,金融交易技术完整领域开放。技术向下兼容,实现与经典架构的融合,开放技术标准,拥抱开源生态。技术栈全面开源共建、保存社区中立、兼容社区和开源生态,组件可插拔,与其它开源组件可相互集成或替换。更多详情,请见 SOFAStack 开源官网。 • 满足资金安全、无损容灾的金融级要求 —- 包含构建金融级云原生架构所需的各个组件,让用户更加专注于业务开发,满足用户场景的现状和未来需求,经历过大规模场景的锤炼,特别是严苛的金融场景,保证在分布式架构下承受高并发交易,在系统扩展、容灾恢复、更新发布时确保数据无损,服务可用。 • 以异地多活、无限扩展为目标构建云原生架构 —- 基于SOFAStack可快速搭建云原生微服务体系,快速开发更具可靠性和扩展性、更加易于维护的云原生应用。在宏观架构层面,提供单机房向同城双活、两地三中心、异地多活架构演进路线,使系统容量能在多个数据中心内任意扩展和调度,充分利用服务器资源,提供机房级容灾能力,保证业务连续性。

LiuWH 2020-03-24 22:18:07 0 浏览量 回答数 0

回答

像传统的数据库,让大家去排队,尽量利用性能,只能一定程度上缓解这个问题。业界上有2种操作,一个是采用云原生的架构,采用存储计算分离,像PolarDB可以做一写多读。现在PolarDB一个实例可以做一个大到接近100T的存储,上面可以做一写多读16个节点。按照当时并发的需求,尤其是对只读并发高的应用,就按量去弹出来的只读节点,一两分钟就弹出一个新的节点,峰值过去之后就可以释放了。 如果写的并发特别多可以采用PolarDB 2.0,所有的计算节点每一个计算节点都可以做写和读。 写和写的冲突问题可以在多写和多读的时候,就要想办法在共享状态这一层。 还有一种解决方法是用分布式,或者有些传统企业用的中间件分库分表或者分布式数据库。因为可以把并发并行的或者分布式放到多个节点上去。这里面也有挑战,挑战非常大,因为一旦对数据进行了分库以后,每个分区都非常容易被并行化。很多时候要做跨区域的查询,依赖两个或三个Partition或者Share上的数据,就需要做跨库的事务处理和查询,这个对系统性能影响非常非常大。但在很多应用场景上,可能并发是很高但做跨库的这种冲突事务的量可能不会太高。

问问小秘 2020-05-22 11:51:50 0 浏览量 回答数 0

回答

互联网金融中台 以强大的业务中台为支撑,支持产品快速组合创新。 基于蚂蚁金服中台战略及架构的最佳实践,将企业级公共能力进行抽象,形成以客户服务、运营服务、分布式架构为基础的业务中台体系,实现开放、可扩展、组件化、分布式的业务架构,支持业务快速、高效、低成本创新,满足互联网场景化快速多变的业务发展需求。 强大的业务支撑能力 将企业级公共能力进行抽象,形成各大能力中心,并沉淀到业务中台,以更强大的复用技术提升业务敏捷性,支持业务快速、高效、低成本创新。 快速迭代创新能力 实践大中台战略,基于能力中心与分布式金融核心套件,支持产品快速组合创新。以强大的业务中台为支撑,快速实现产品迭代,满足多变需求。 标准化和可扩展能力 中台屏蔽技术复杂性,使得业务无感知,使得中台参与者能以统一的标准进行协同和技术开发,降低协作成本。能够基于已有的系统能力进行定制扩展或配置,提升复用性同时又满足差异性的要求。 分布式技术能力 提供金融级分布式框架和金融级分布式数据库,支持多租户,支持海量用户的高业务并发场景。提供大数据和人工智能的中台能力建设,支持分布式金融核心系统的异地多活架构。 金融级云原生应用 满足金融业务发展和严苛场景考验,让云计算更懂金融。 蚂蚁金服自主研发的金融级分布式架构平台,专注为金融用户提供全栈式的基础架构能力,保证风险安全的同时帮助业务需求敏捷迭代,同时满足异地容灾、低成本快速扩容的需求 解决传统集中式架构转型的困难,打造大规模高可用分布式系统架构,支撑金融业务创新。 资损防控、无损容灾 保证在分布式架构下承受高并发交易,在系统扩展、容灾恢复、更新发布时确保数据无损,服务可用。 异地多活、无限扩展 使系统容量能在多个数据中心内任意扩展和调度,充分利用服务器资源,提供机房级容灾能力,保证业务连续性。 全栈开放、开源共建 技术栈全面开源共建、保存社区中立、兼容社区 兼容开源生态,组件可插拔, SOFAStack 组件与其它开源组件可相互集成或替换。 异构应用融合迁移 面向未来架构的微服务平台。 微服务平台通过 SOFA 微服务和 Service Mesh 微服务,提供了既支持 SOFA 框架又支持 Service Mesh 架构的微服务管理和治理能力,解决用户在技术转型期间与未改造的遗留系统相互之间打通和过渡问题,帮助金融机构平稳的从传统的集中式、微服务架构演进到云原生架构。 多协议兼容 既能借助蚂蚁金服久经考验的微服务框架 SOFA 在云上构建微服务应用,也可以支持原生 Dubbo 和 Spring Cloud 上云,无需构建 ZooKeeper,Eureka,Consul 等微服务依赖的自建服务,极大降低运维成本。 跨平台无侵入 业务应用系统通过 Service Mesh 技术架构轻量级接入,实现对应用无侵入的服务注册与服务治理方案,减少改造成本。同时,该方案支持容器平台、虚拟机平台,能够满足企业用户未容器化的场景对 Service Mesh 架构转型的需求。 简单易用易维护 微服务平台提供集中式图形化易操作的管理平台,满足企业级高级特性需求,简化分布式应用的服务管理、服务治理、可观察性、配置管理等能力,让用户便捷的对应用服务统一管理和治理。 异地多活单元化架构 “三地五中心”部署模式的技术创新。 该架构解决方案下,可以避免跨机房、跨城市访问的延迟,真正实现异地多活部署,不但消除了传统“两地三中心”架构中的单独冷备中心,并提升了灾备高可用能力,无论在成本还是在伸缩性、高可用方面,都带来了巨大的优势。 保证数据安全和业务连续性 消除了传统架构下启用灾备时可能数据受损或丢失,因而无法保障金融级的数据完整性和一致性这一致命缺点。 多机房、多地域无损容灾 真正实现异地多活部署的单元化架构,支撑更稳定、更高效、更低成本的金融级服务,并极大提升了灾备能力到异地无损容灾级别。 提升机房资源利用率 消除了传统“两地三中心”架构中诸如存在平时不提供服务的单独冷备中心等不足,极大降低了运行成本。

LiuWH 2020-03-24 22:20:15 0 浏览量 回答数 0

阿里云试用中心,为您提供0门槛上云实践机会!

0元试用32+款产品,最高免费12个月!拨打95187-1,咨询专业上云建议!

回答

前言 随着计算机技术和 Internet 的日新月异,视频点播技术因其良好的人机交互性和流媒体传输技术倍受教育、娱乐等行业青睐,而在当前, 云计算平台厂商的产品线不断成熟完善, 如果想要搭建视频点播类应用,告别刀耕火种, 直接上云会扫清硬件采购、 技术等各种障碍,以阿里云为例: image 这是一个非常典型的解决方案, 对象存储 OSS 可以支持海量视频存储,采集上传的视频被转码以适配各种终端,CDN 加速终端设备播放视频的速度。此外还有一些内容安全审查需求, 比如鉴黄、鉴恐等。 而在视频点播解决方案中, 视频转码是最消耗计算力的一个子系统,虽然您可以使用云上专门的转码服务,但在很多情况下,您会选择自己搭建转码服务。比如: 您已经在虚拟机/容器平台上基于 FFmpeg 部署了一套视频处理服务,能否在此基础上让它更弹性,更高的可用性? 您有并发处理大量视频的需求。 您有很多超大的视频需要批量快速处理完, 比如每周五定期产生几百个 4G 以上的 1080P 大视频, 但是希望当天几个小时后全部处理完。 您有更高级的自定义处理需求,比如视频转码完成后, 需要记录转码详情到数据库, 或者在转码完成后, 自动将热度很高的视频预热到 CDN 上, 从而缓解源站压力。 自定义视频处理流程中可能会有多种操作组合, 比如转码、加水印和生成视频首页 GIF。后续为视频处理系统增加新需求,比如调整转码参数,希望新功能发布上线对在线服务无影响。 您的需求只是简单的转码需求,或是一些极其轻量的需求,比如获取 OSS 上视频前几帧的 GIF、获取视频或者音频的时长,自己搭建成本更低。 各种格式的音频转换或者各种采样率自定义、音频降噪等功能 您的视频源文件存放在 NAS 或者 ECS 云盘上,自建服务可以直接读取源文件处理,而不需要将它们再迁移到 OSS 上。 如果您的视频处理系统有上述需求,或者您期望实现一个 弹性、高可用、低成本、免运维、灵活支持任意处理逻辑 的视频处理系统,那么本文则是您期待的最佳实践方案。 Serverless 自定义音视频处理 在介绍具体方案之前, 先介绍两款产品: 函数计算 :阿里云函数计算是事件驱动的全托管计算服务。通过函数计算,您无需管理服务器等基础设施,只需编写代码并上传。函数计算会为您准备好计算资源,以弹性、可靠的方式运行您的代码,并提供日志查询、性能监控、报警等功能。 函数工作流:函数工作流(Function Flow,以下简称 FnF)是一个用来协调多个分布式任务执行的全托管云服务。您可以用顺序,分支,并行等方式来编排分布式任务,FnF 会按照设定好的步骤可靠地协调任务执行,跟踪每个任务的状态转换,并在必要时执行用户定义的重试逻辑,以确保工作流顺利完成。 免费开通函数计算,按量付费,函数计算有很大的免费额度。 免费开通函数工作流,按量付费,函数工作流有很大的免费额度。 函数计算可靠的执行任意逻辑, 逻辑可以是利用 FFmpeg 对视频任何处理操作, 也可以更新视频 meta 数据到数据库等。函数工作流对相应的函数进行编排, 比如第一步的函数是转码, 第二步的函数是转码成功后,将相应 meta 数据库写入数据库等。 至此,您应该初步理解了函数计算的自定义处理能力 + 函数工作流编排能力几乎满足您任何自定义处理的需求,接下来,本文以一个具体的示例展示基于函数计算和函数工作流打造的一个弹性高可用的 Serverless 视频处理系统,并与传统方案进行性能、成本和工程效率的对比。 Simple 视频处理系统 假设您是对视频进行单纯的处理, 架构方案图如下: image 如上图所示, 用户上传一个视频到 OSS, OSS 触发器自动触发函数执行, 函数调用 FFmpeg 进行视频转码, 并且将转码后的视频保存回 OSS。 OSS 事件触发器, 阿里云对象存储和函数计算无缝集成。您可以为各种类型的事件设置处理函数,当 OSS 系统捕获到指定类型的事件后,会自动调用函数处理。例如,您可以设置函数来处理 PutObject 事件,当您调用 OSS PutObject API 上传视频到 OSS 后,相关联的函数会自动触发来处理该视频。 Simple 视频处理系统示例工程地址 强大的监控系统: 您可以直接基于示例工程部署您的 Simple 音视频处理系统服务, 但是当您想要处理超大视频(比如 test_huge.mov ) 或者对小视频进行多种组合操作的时候, 您会发现函数会执行失败,原因是函数计算的执行环境有最大执行时间为 10 分钟的限制,如果最大的 10 分钟不能满足您的需求, 您可以选择: 对视频进行分片 -> 转码 -> 合成处理, 详情参考:fc-fnf-video-processing, 下文会详细介绍; 联系函数计算团队(钉钉群号: 11721331) 或者提工单: 适当放宽执行时长限制; 申请使用更高的函数内存 12G(8vCPU) 为了突破函数计算执行环境的限制(或者说加快大视频的转码速度), 进行各种复杂的组合操作, 此时引入函数工作流 FnF 去编排函数实现一个功能强大的视频处理工作流系统是一个很好的方案。 视频处理工作流系统 image 如上图所示, 假设用户上传一个 mov 格式的视频到 OSS,OSS 触发器自动触发函数执行, 函数调用 FnF,会同时进行 1 种或者多种格式的转码(由您触发的函数环境变量DST_FORMATS 参数控制)。 所以您可以实现如下需求: 一个视频文件可以同时被转码成各种格式以及其他各种自定义处理,比如增加水印处理或者在 after-process 更新信息到数据库等。 当有多个文件同时上传到 OSS,函数计算会自动伸缩, 并行处理多个文件, 同时每次文件转码成多种格式也是并行。 结合 NAS + 视频切片, 可以解决超大视频(大于 3G )的转码, 对于每一个视频,先进行切片处理,然后并行转码切片,最后合成,通过设置合理的切片时间,可以大大加速较大视频的转码速度。 所谓的视频切片,是将视频流按指定的时间间隔,切分成一系列分片文件,并生成一个索引文件记录分片文件的信息 视频处理工作流系统示例工程地址 示例效果: gif 函数计算 + 函数工作流 Serverless 方案 VS 传统方案 卓越的工程效率 自建服务 函数计算 + 函数工作流 Serverless 基础设施 需要用户采购和管理 无 开发效率 除了必要的业务逻辑开发,需要自己建立相同线上运行环境, 包括相关软件的安装、服务配置、安全更新等一系列问题 只需要专注业务逻辑的开发, 配合 FUN 工具一键资源编排和部署 并行&分布式视频处理 需要很强的开发能力和完善的监控系统来保证稳定性 通过 FnF 资源编排即可实现多个视频的并行处理以及单个大视频的分布式处理,稳定性和监控交由云平台 学习上手成本 除了编程语言开发能力和熟悉 FFmpeg 以外,可能使用 K8S 或弹性伸缩( ESS ),需要了解更多的产品、名词和参数的意义 会编写对应的语言的函数代码和熟悉 FFmpeg 使用即可 项目上线周期 在具体业务逻辑外耗费大量的时间和人力成本,保守估计大约 30 人天,包括硬件采购、软件和环境配置、系统开发、测试、监控报警、灰度发布系统等 预计 3 人天, 开发调试(2人天)+ 压测观察(1 人天) 弹性伸缩免运维,性能优异 自建服务 函数计算 + 函数工作流 Serverless 弹性高可用 需要自建负载均衡 (SLB),弹性伸缩,扩容缩容速度较 FC 慢 FC系统固有毫秒级别弹性伸缩,快速实现底层扩容以应对峰值压力,免运维,视频处理工作流系统 (FnF + FC) 压测;性能优异, 详情见下面的转码性能表 监控报警查询 ECS 或者容器级别的 metrics 提供更细粒度的 FnF 流程执行以及函数执行情况, 同时可以查询每次函数执行的 latency 和日志等, 更加完善的报警监控机制 函数计算 + 函数工作流 Serverless 方案转码性能表 实验视频为是 89s 的 mov 文件 4K 视频: 4K.mov,云服务进行 mov -> mp4 普通转码需要消耗的时间为 188s, 将这个参考时间记为 T 视频切片时间 FC转码耗时 性能加速百分比 45s 160s 117.5% 25s 100s 188% 15s 70s 268.6% 10s 45s 417.8% 5s 35s 537.1% 性能加速百分比 = T / FC转码耗时 从上表可以看出,设置的视频切片时间越短, 视频转码时间越短, 函数计算可以自动瞬时调度出更多的计算资源来一起完成这个视频的转码, 转码性能优异。 更低的成本 具有明显波峰波谷的视频处理场景(比如只有部分时间段有视频处理请求,其他时间很少甚至没有视频处理请求),选择按需付费,只需为实际使用的计算资源付费。 没有明显波峰波谷的视频处理场景,可以使用预付费(包年包月),成本仍然具有竞争力。 函数计算成本优化最佳实践文档。 假设有一个基于 ECS 搭建的视频转码服务,由于是 CPU 密集型计算, 因此在这里将平均 CPU 利用率作为核心参考指标对评估成本,以一个月为周期,10 台 C5 ECS 的总计算力为例, 总的计算量约为 30% 场景下, 两个解决方案 CPU 资源利用率使用情况示意图大致如下: image 由上图预估出如下计费模型: 函数计算预付费 3CU 一个月: 246.27 元, 计算能力等价于 ECS 计算型 C5 ECS 计算型 C5 (2vCPU,4GB)+云盘: 包月219 元 函数计算按量付费占整个计算量的占比 <= 10%,费用约为 3×864×10% = 259.2 元,(3G 规格的函数满负载跑满一个月费用为:0.00011108×3×30×24×3600 = 863.8,详情查看计费) ITEM 平均CPU利用率 计算费用 总计 函数计算组合付费 >=80% 998(246.27×3+259.2) <= 998 按峰值预留ECS <=30% 2190(10*219) >=2190 在这个模型预估里面,可以看出 FC 方案具有很强的成本竞争力,在实际场景中, 基于 ECS 自建的视频转码服务 CPU 利用甚至很难达到 20%, 理由如下: 可能只有部分时间段有视频转码请求 为了用户体验,视频转码速度有一定的要求,可能一个视频转码就需要 10 台 ECS 并行处理来转码, 因此只能预备很多 ECS 因此,在实际场景中, FC 在视频处理上的成本竞争力远强于上述模型。 即使和云厂商视频转码服务单价 PK, 该方案仍有很强的成本竞争力 我们这边选用点播视频中最常用的两个格式(mp4、flv)之间进行相互转换,经实验验证, 函数内存设置为3G,基于该方案从 mp4 转码为 flv 的费用概览表: 实验视频为是 89s 的 mp4 和 flv 格式的文件视频, 测试视频地址: 480P.mp4 720P.mp4 1080P.mp4 4K.mp4 480P.flv 720P.flv 1080P.flv 4K.flv 测试命令: ffmpeg -i test.flv test.mp4 和 ffmpeg -i test.flv test.mp4 mp4 转 flv: 分辨率 bitrate 帧率 FC 转码耗费时间 FC 转码费用 某云视频处理费用 成本下降百分比 标清 640480 889 kb/s 24 11.2s 0.003732288 0.032 88.3% 高清 1280720 1963 kb/s 24 20.5s 0.00683142 0.065 89.5% 超清 19201080 3689 kb/s 24 40s 0.0133296 0.126 89.4% 4K 38402160 11185 kb/s 24 142s 0.04732008 0.556 91.5% flv 转 mp4: 分辨率 bitrate 帧率 FC 转码耗费时间 FC 转码费用 某云视频处理费用 成本下降百分比 标清 640480 712 kb/s 24 34.5s 0.01149678 0.032 64.1% 高清 1280720 1806 kb/s 24 100.3s 0.033424 0.065 48.6% 超清 19201080 3911 kb/s 24 226.4s 0.0754455 0.126 40.1% 4K 38402160 15109 kb/s 24 912s 0.30391488 0.556 45.3% 成本下降百分比 = (某云视频处理费用 - FC 转码费用)/ 云视频处理费用 某云视频处理,计费使用普通转码,转码时长不足一分钟,按照一分钟计算,这里计费采用的是 2 min,即使采用 1.5 min 计算, 成本下降百分比基本在10%以内浮动 从上表可以看出, 基于函数计算 + 函数工作流的方案在计算资源成本上对于计算复杂度较高的 flv 转 mp4 还是计算复杂度较低的 mp4 转 flv, 都具有很强的成本竞争力。 根据实际经验, 往往成本下降比上表列出来的更加明显, 理由如下: 测试视频的码率较高, 实际上很多场景绝大部分都是标清或者流畅视频的转码场景, 码率也比测试视频低,这个时候计算量变小, FC 执行时间短, 费用会降低, 但是通用的云转码服务计费是不变的. 很多视频分辨率在通用的云转码服务是计费是有很大损失的, 比如转码的视频是 856480 或者 1368768, 都会进入云转码服务的下一档计费单价, 比如856480 进入 1280720 高清转码计费档,1368768 进入 19201080 超清转码计费档, 单价基本是跨越式上升, 但是实际真正的计算量增加可能还不到30%, 而函数计算则是真正能做到按计算量付费. 操作部署 免费开通函数计算,按量付费,函数计算有很大的免费额度。 免费开通函数工作流,按量付费,函数工作流有很大的免费额度。 免费开通文件存储服务NAS, 按量付费 详情见各自示例工程的 README Simple 视频处理系统示例工程地址 视频处理工作流系统示例工程地址 总结 基于函数计算 FC 和函数工作流 FnF 的弹性高可用视频处理系统天然继承了这两个产品的优点: 无需采购和管理服务器等基础设施,只需专注视频处理业务逻辑的开发,大幅缩短项目交付时间和人力成本 提供日志查询、性能监控、报警等功能快速排查故障 以事件驱动的方式触发响应用户请求 免运维,毫秒级别弹性伸缩,快速实现底层扩容以应对峰值压力,性能优异 成本极具竞争力 相比于通用的转码处理服务: 超强自定义,对用户透明, 基于 FFmpeg 或者其他音视频处理工具命令快速开发相应的音视频处理逻辑 原有基于 FFmpeg 自建的音视频处理服务可以一键迁移 弹性更强, 可以保证有充足的计算资源为转码服务,比如每周五定期产生几百个 4G 以上的 1080P 大视频, 但是希望当天几个小时后全部处理完 各种格式的音频转换或者各种采样率自定义、音频降噪等功能, 比如专业音频处理工具 aacgain 和 mp3gain 可以和 serverless 工作流完成更加复杂、自定义的任务编排,比如视频转码完成后,记录转码详情到数据库,同时自动将热度很高的视频预热到 CDN 上, 从而缓解源站压力 更多的方式的事件驱动, 比如可以选择 OSS 自动触发(丰富的触发规则), 也可以根据业务选择 MNS 消息(支持 tag 过滤)触发 在大部分场景下具有很强的成本竞争力相比于其他自建服务: 毫秒级弹性伸缩,弹性能力超强,支持大规模资源调用,可弹性支持几万核.小时的计算力,比如 1 万节课半个小时完成转码 只需要专注业务逻辑代码即可,原生自带事件驱动模式,简化开发编程模型,同时可以达到消息(即音视频任务)处理的优先级,可大大提高开发运维效率 函数计算采用 3AZ 部署, 安全性高,计算资源也是多 AZ 获取, 能保证每个用户需要的算力峰值 开箱即用的监控系统, 如上面 gif 动图所示,可以多维度监控函数的执行情况,根据监控快速定位问题,同时给用户提供分析能力, 比如视频的格式分布, size 分布等 在大部分场景下具有很强的成本竞争力, 因为在函数计算是真正的按量付费(计费粒度在百毫秒), 可以理解为 CPU 的利用率为 100% 最后一一回答一下之前列出的问题: Q1: 您已经在虚拟机/容器平台上基于 FFmpeg 部署了一套视频处理服务,能否在此基础上让它更弹性,更高的可用性? A: 如工程示例所示,在虚拟机/容器平台上基于 FFmpeg 的服务可以轻松切换到函数计算, FFmpeg 相关命令可以直接移值到函数计算,改造成本较低, 同时天然继承了函数计算弹性高可用性特性。 Q2:您的需求只是简单的转码需求,或是一些极其轻量的需求,比如获取 OSS 上视频前几帧的 GIF 等。 自己搭建成本更低。 A: 函数计算天生就是解决这些自定义问题, 你的代码你做主, 代码中快速执行几个 FFmpeg 的命令即可完成需求。典型示例: fc-oss-ffmpeg Q3: 您有更高级的自定义处理需求,比如视频转码完成后, 需要记录转码详情到数据库, 或者在转码完成后, 自动将热度很高的视频预热到 CDN 上, 从而缓解源站压力。 A: 详情见视频处理工作流系统(函数计算 + 函数工作流方案),after-process 中可以做一些自定义的操作, 您还可以基于此流程再做一些额外处理等, 比如: 再增加后续流程 最开始增加 pre-process Q4: 您有并发同时处理大量视频的需求。 A: 详情见视频处理工作流系统(函数计算 + 函数工作流方案), 当有多个文件同时上传到 OSS, 函数计算会自动伸缩, 并行处理多个文件。详情可以参考 视频处理工作流系统 (FnF + FC) 压测 Q5:您有很多超大的视频需要批量快速处理完, 比如每周五定期产生几百个 4G 以上的 1080P 大视频, 但是希望当天几个小时后全部处理完。A: 详情可以参考视频处理工作流系统 (FnF + FC) 压测, 可以通过控制分片的大小, 可以使得每个大视频都有足够多的计算资源参与转码计算, 大大提高转码速度。 Q6: 自定义视频处理流程中可能会有多种操作组合, 比如转码、加水印和生成视频首页 GIF,后续为视频处理系统增加新需求,比如调整转码参数,希望新功能发布上线对在线服务无影响。 A: 详情见视频处理工作流系统(函数计算 + 函数工作流方案), FnF 只负责编排调用函数, 因此只需要更新相应的处理函数即可,同时函数有 version 和 alias 功能, 更好地控制灰度上线, 函数计算版本管理 Q7: 您的视频源文件存放在 NAS 或者 ECS 云盘上,自建服务可以直接读取源文件处理,而不需要将他们再迁移到 OSS 上。 A: 函数计算可以挂载 NAS, 直接对 NAS 中的文件进行处理

1934890530796658 2020-03-27 18:21:36 0 浏览量 回答数 0

回答

原版英文链接:点击这里 作者 | Md Kamaruzzaman 译者 | 无明 策划 | 小智 基础设施:条条道路通云端 对于云厂商来说,2019 年是硕果累累的一年。不仅初创公司在使用云计算,那些很注重安全的“保守派”公司(如政府机构、医疗保健机构、银行、保险公司,甚至是美国五角大楼)也在迁移到云端。这种趋势在 2020 年将会继续,大大小小的公司都将(或者至少有计划)迁移到云端。Gartner 公司最近发布了一个数字: 如果你是一个还在考虑要不要迁移到云端的决策者,不妨重新审视一下你的策略。如果你是一个独立开发者,并且还没使用过云基础设施,那么完全可以在 2020 年尝试一下。很多大型的云厂商(如亚马逊、微软、谷歌)都提供了免费的体验机会。谷歌在这方面做得特别大方,它提供了价值 300 美元的一年免费服务。 策划注:阿里、腾讯、华为等国内云厂商同样有免费云服务试用产品。 云平台:亚马逊领头,其他跟上 作为第一大云厂商,亚马逊在 2019 年可谓风生水起。凭借其丰富的产品组合,亚马逊将把它的优势延续到 2020 年。Canalys 发布的 2019 年第三季度报告指出,大型云厂商(AWS、Azure、GCP)占据 56% 的市场份额,其中 AWS 独享 32.6%。 其他云厂商也在努力缩短与 AWS 之间的差距。微软把主要目标转向了大型企业。最近,微软打败了亚马逊,从美国五角大楼拿到了一个 100 亿美元的大单子。这个单子将提升 Azure 的声誉,同时削弱 AWS 的士气。 谷歌一直在推动 CNCF,实现云计算运维的标准化。谷歌的长期目标是让云迁移变得更容易,方便企业从 AWS 迁移到 GCP。IBM 之前斥资 360 亿美元收购了 RedHat,也想要在云计算市场占有一席之地。 在亚太地区,阿里云市场规模超过了 AWS、Azure 的总和,全球排名第三。中国国内腾讯云等企业的增长势头也十分迅猛。 2020 年将出现更多的并购。当然,很多初创公司将会带来新的想法和创新,例如多云服务。因为竞争激烈,这些公司只能从降价和推出更多的创新产品来获取利润。 容器化:Kubernetes 将会更酷 在容器编排领域,虽然一度出现了“三足鼎立”(Kubernetes、Docker Swarm 和 Mesos),但 Kubernetes 最终脱颖而出,成为绝对的赢家。云是一个分布式系统,而 Kubernetes 是它的 OS(分布式的 Linux)。2019 年北美 KubeCon+CloudNativeCon 大会的参会者达到了 12000 名,比 2018 年增长了 50%。以下是过去 4 年参会人数的增长情况。 在 2020 年,Kubernetes 不仅不会后退,只会变得越来越强,你完全可以把赌注压在 Kubernetes 身上。另外值得一提的是,Migrantis 最近收购了 Docker Enterprise,不过收购数额不详。 几年前,人们张口闭口说的都是 Docker,而现在换成了 Kubernetes。Docker 在它的全盛时期未能盈利,反而在优势渐退几年之后才尝试变现。这再次说明,在现代技术世界,时机就是一切。 软件架构:微服务将成为主流 谷歌趋势表明,微服务架构范式在 2019 年持续增长了一整年。 随着软件行业整体逐步迁移到云端,微服务也将成为占主导地位的架构范式。微服务架构崛起的一个主要原因是它与云原生完美契合,可以实现快速的软件开发。我在之前的一篇博文中解释了微服务架构的基本原则及其优势和劣势。 https://towardsdatascience.com/microservice-architecture-a-brief-overview-and-why-you-should-use-it-in-your-next-project-a17b6e19adfd 我假设现在也存在一种回归到单体架构的趋势,因为在很多情况下,微服务架构有点过头了,而且做好微服务架构设计其实很难。微服务架构有哪些好的实践?在之前的另一篇博文中,我也给出了一些大概,希望对读者有用。 https://towardsdatascience.com/effective-microservices-10-best-practices-c6e4ba0c6ee2 编程语言(整体):Python 将吞噬世界 机器学习、数据分析、数据处理、Web 开发、企业软件开发,甚至是拼接黑洞照片,Python 的影子无处不在。 在著名的编程语言排行榜网站 TIOBE 上,Python 位居最流行编程语言第三位,仅次于 Java 和 C 语言。 更有意思的是,在 2019 年,Python 的流行度翻了一番(从 5% 到 10%)。 Python 的崛起将在 2020 年延续,并缩短与 Java 和 C 语言之间的差距。另一门无所不在的编程语言 JavaScript 正面临下行的风险。为什么 Python 的势头会如此强劲?因为它的入手门槛低,有一个优秀的社区在支持,并受到数据科学家和新生代开发者的喜爱。 编程语言(企业方面):Java 将占主导 之前的 TIOBE 网站截图显示,Java 仍然是一门占主导地位的编程语言,并将在 2020 年继续保持这种地位。JVM 是 Java 的基石,其他编程语言(如 Kotlin、Scala、Clojure、Groovy)也将 JVM 作为运行时。最近,Oracle 修改了 JVM 的许可协议。 新的许可协议意味着使用 Java、Kotlin、Scala 或其他 JVM 编程语言的公司需要向 Oracle 支付大额费用。所幸的是,OpenJDK 让 JVM 继续免费。另外,还有其他一些公司为 JVM 提供企业支持。 因为体积和速度方面的问题,基于 JVM 的编程语言并不适合用在今天的无服务器环境中。Oracle 正在推动 GraalVM 计划,旨在让 Java 变得更加敏捷和快速,让它更适合用在无服务器环境中。因为除了 Java,没有其他编程语言可以提供企业级的稳定性和可靠性,所以 Java 将在 2020 年继续占主导地位。 企业版 Java:Spring 继续发力 曾几何时,在企业开发领域,Spring 和 JavaEE 之间存在着白热化的竞争。但因为 Oracle 在 JavaEE 方面没有作为,在竞争中惨败,这导致了“MicroProfile”计划的形成,并最终促成了 JakartaEE。 虽然所有的政策和活动都是围绕 JavaEE 展开,但 Spring 事实上已经赢得了这场企业 JVM 之争。2020 年,Spring 将成为 JVM 生态系统的头牌。 有两个正在进展中的项目,它们旨在减小 Java 的体积,让它更适合用在无服务器环境中。 其中一个是 Micronaut(https://micronaut.io/)。 另一个是 Quarkus(https://quarkus.io/)。 这两个项目都使用了 GraalVM,它们在 2020 年将会得到 Java 社区更多的关注。 编程语言:后起之秀的突破 2000 年代,编程语言的发展出现了停滞。大多数人认为没有必要再去开发新的编程语言,Java、C 语言、C++、JavaScript 和 Python 已经可以满足所有的需求。但是,谷歌的 Go 语言为新编程语言大门打开了一扇大门。在过去十年出现了很多有趣的编程语言,比如 Rust、Swift、Kotlin、TypeScript。导致这种情况的一个主要原因是已有的编程语言无法充分利用硬件优势(例如多核、更快的网络、云)。另一个原因是现代编程语言更加关注开发者经济,即实现更快速更容易的开发。在 Stackoverflow 提供的一份开发者报告中,排名靠前的现代编程语言如下所示(Rust 连续 4 年名列第一)。 在之前的一篇博文中,我深入探讨了现代编程语言,对比 Rust 和 Go 语言,并说明了为什么现在是采用这些语言的好时机。 https://towardsdatascience.com/back-to-the-metal-top-3-programming-language-to-develop-big-data-frameworks-in-2019-69a44a36a842 最近,微软宣布他们在探索使用 Rust 来开发更安全的软件。 亚马逊最近也宣布要赞助 Rust。 谷歌宣布将 Kotlin 作为 Android 官方开发语言,所以,在 JVM 领域,Kotlin 成了 Java 的主要竞争对手。 Angular 使用 TypeScript 代替 JavaScript,将其作为主要的编程语言,其他 JavaScript 框架(如 React 和 Vue)也开始为 TypeScript 提供更多的支持。 这种趋势将在 2020 年延续下去,很多巨头公司将会深入了解新一代编程语言(如 Rust、Swift、TypeScript、Kotlin),它们会站出来公开表示支持。 Web:JavaScript 继续占主导地位 曾几何时,JavaScript 并不被认为是一门强大的编程语言。在当时,前端内容主要通过后端框架在服务器端进行渲染。2014 年,AngularJS 的出现改变了这种局面。从那个时候开始,更多的 JavaScript 框架开始涌现(Angular 2+、React、Vue、Meteor),JavaScript 已然成为主流的 Web 开发语言。随着 JavaScript 框架不断创新以及微服务架构的崛起,JavaScript 框架在 2020 年将继续主导前端开发。 JavaScript 框架:React 闪耀 虽然 React 是在 AngularJS 之后出现的,但在过去十年对 Web 开发产生了巨大的影响,这也让 Facebook 在与 Google+ 的竞争中打了一场胜战。React 为前端开发带来了一些新的想法,比如事件溯源、虚拟 DOM、单向数据绑定、基于组件的开发,等等。它对开发者社区产生了重大影响,以至于谷歌放弃了 AngularJS,并借鉴 React 的想法推出了彻底重写的 Angular 2+。React 是目前为止最为流行的 JavaScript 框架,下图显示了相关的 NPM 下载统计信息。 为了获得更好的并发和用户体验,Facebook 宣布完全重写 React 的核心算法,推出了 React-Fiber 项目。 2020 年,React 仍然是你开发新项目的首选 Web 框架。其他框架(如 Angular/Angular 2+ 或 Vue)呢?Angular 仍然是一个不错的 Web 开发框架,特别适合企业开发。我敢肯定谷歌在未来几年会在 Angular 上加大投入。Vue 是另一个非常流行的 Web 框架,由中国的巨头公司阿里巴巴提供支持。如果你已经在使用 Angular 或 Vue,就没必要再迁移到 React 了。 App 开发:原生应用 在移动 App 开发方面,有关混合应用开发的炒作有所消停。混合开发提供了更快的开发速度,因为只需要一个开发团队,而不是多个。但原生应用提供了更好的用户体验和性能。另外,混合应用需要经过调整才能使用一些高级特性。对于企业来说,原生应用仍然是首选的解决方案,这种趋势将在 2020 年延续。Airbnb 在一篇博文中非常详细地说明了为什么他们要放弃混合应用开发平台 React Native。 https://medium.com/airbnb-engineering/sunsetting-react-native-1868ba28e30a 尽管 Facebook 尝试改进 React Native,谷歌也非常努力地推动混合 App 开发平台 Flutter,但它们仍然只适合用于原型、POC、MVP 或轻量级应用的开发。所以,原生应用在 2020 年仍将继续占主导地位。 在原生应用开发方面,谷歌和苹果分别将 Kotlin 和 Swift 作为各自平台主要的编程语言。谷歌最近再次重申了对 Kotlin 的支持,这对于 Kotlin 用户来说无疑是个好消息。 混合应用开发:React Native 在很多情况下,混合应用是个不错的选择。在这方面也有很多选择:Xamarin、Inoic、React Native 和 Flutter。Facebook 基于成熟的 React 框架推出了 React Native。就像 React 在 Web 框架领域占据主导地位一样,React Native 在混合应用领域也占据着主导地位,如下图所示。 React Native 和 React 有共同的基因,都提供了高度的代码重用性以及“一次开发,到处运行”的能力。React Native 的另一个优势是 Facebook 本身也用它来开发移动应用。谷歌在这个领域起步较晚,但在去年,谷歌的混合应用开发框架 Flutter 获得了不少关注。Flutter 提供了更好的性能,但需要使用另一门不是那么流行的编程语言 Dart。React Native 在 2020 年将继续占主导地位。 API:REST 将占主导地位 REST 是 API 领域事实上的标准,被广泛用在基于 API 的服务间通信上。当然,除了 REST,我们还有其他选择,比如来自谷歌的 gRPC 和来自 Facebook 的 GraphQL。 它们提供了不同的能力。谷歌开发的 gRPC 作为远程过程调用(如 SOAP)的化身,使用 Protobuf 代替 JSON 作为消息格式。Facebook 开发的 GraphQL 作为一个集成层,避免频繁的 REST 调用。gRPC 和 GraphQL 都在各自的领域取得了成功。2020 年,REST 仍然是占主导地位的 API 技术,而 GraphQL 和 gRPC 将作为补充技术。 人工智能:Tensorflow 2.0 将占主导地位 谷歌和 Facebook 也是深度学习 / 神经网络领域的主要玩家。谷歌基于深度学习框架 Theano 推出了 TensorFlow,它很快就成为深度学习 / 神经网络的主要开发库。谷歌还推出了特别设计的 GPU(TPU)来加速 TensorFlow 的计算。 Facebook 在深度学习领域也不甘落后,他们拥有世界上最大的图像和视频数据集合。Facebook 基于另一个深度学习库 Torch 推出了深度学习库 PyTorch。TensorFlow 和 PyTorch 之间有一些区别,前者使用的是静态图进行计算,而 PyTorch 使用的是动态图。使用动态图的好处是可以在运行时纠正自己。另外,PyTorch 对 Python 支持更好,而 Python 是数据科学领域的一门主要编程语言。 随着 PyTorch 变得越来越流行,谷歌也赶紧在 2019 年 10 月推出了 TensorFlow 2.0,也使用了动态图,对 Python 的支持也更好。 2020 年,TensorFlow 2.0 和 PyTorch 将齐头并进。考虑到 TensorFlow 拥有更大的社区,我估计 TensorFlow 2.0 将成为占主导地位的深度学习库。 数据库:SQL是王者,分布式SQL是王后 在炒作 NoSQL 的日子里,人们嘲笑 SQL,还指出了 SQL 的种种不足。有很多文章说 NoSQL 有多么的好,并将要取代 SQL。但等到炒作的潮水褪去,人们很快就意识到,我们的世界不能没有 SQL。以下是最流行的数据库的排名。 可以看到,SQL 数据库占据了前四名。SQL 之所以占主导地位,是因为它提供了 ACID 事务保证,而 ACID 是业务系统最潜在的需求。NoSQL 数据库提供了横向伸缩能力,但代价是不提供 ACID 保证。 互联网公司一直在寻找“大师级数据库”,也就是既能提供 ACID 保证又能像 NoSQL 那样可横向伸缩的数据库。目前有两个解决方案可以部分满足对“大师级数据库”的要求,一个是亚马逊的 Aurora,一个是谷歌的 Spanner。Aurora 提供了几乎所有的 SQL 功能,但不支持横向写伸缩,而 Spanner 提供了横向写伸缩能力,但对 SQL 支持得不好。 2020 年,但愿这两个数据库能够越走越近,或者有人会带来一个“分布式 SQL”数据库。如果真有人做到了,那一定要给他颁发图灵奖。 数据湖:MinIO 将要崛起 现代数据平台非常的复杂。企业一般都会有支持 ACID 事务的 OLTP 数据库(SQL),也会有用于数据分析的 OLAP 数据库(NoSQL)。除此之外,它们还有其他各种数据存储系统,比如用于搜索的 Solr、ElasticSearch,用于计算的 Spark。企业基于数据库构建自己的数据平台,将 OLTP 数据库的数据拷贝到数据湖中。各种类型的数据应用程序(比如 OLAP、搜索)将数据湖作为它们的事实来源。 HDFS 原本是事实上的数据湖,直到亚马逊推出了对象存储 S3。S3 可伸缩,价格便宜,很快就成为很多公司事实上的数据湖。使用 S3 唯一的问题是数据平台被紧紧地绑定在亚马逊的 AWS 云平台上。虽然微软 Azure 推出了 Blob Storage,谷歌也有类似的对象存储,但都不是 S3 的对手。 对于很多公司来说,MinIO 或许是它们的救星。MinIO 是一个开源的对象存储,与 S3 兼容,提供了企业级的支持,并专门为云原生环境而构建,提供了与云无关的数据湖。 微软在 Azure Marketplace 是这么描述 MinIO 的:“为 Azure Blog Storage 服务提供与亚马逊 S3 API 兼容的数据访问”。如果谷歌 GCP 和其他云厂商也提供 MinIO,那么我们将会向多云迈出一大步。 大数据批处理:Spark 将继续闪耀 现如今,企业通常需要基于大规模数据执行计算,所以需要分布式的批处理作业。Hadoop 的 Map-Reduce 是第一个分布式批处理平台,后来 Spark 取代了 Hadoop 的地位,成为真正的批处理之王。Spark 是怎样提供了比 Hadoop 更好的性能的?我之前写了另一篇文章,对现代数据平台进行了深入分析。 https://towardsdatascience.com/programming-language-that-rules-the-data-intensive-big-data-fast-data-frameworks-6cd7d5f754b0 Spark 解决了 Hadoop Map-Reduce 的痛点,它将所有东西放在内存中,而不是在完成每一个昂贵的操作之后把数据保存在存储系统中。尽管 Spark 重度使用 CPU 和 JVM 来执行批处理作业,但这并不妨碍它成为 2020 年批处理框架之王。我希望有人能够使用 Rust 开发出一个更加高效的批处理框架,取代 Spark,并为企业省下大量的云资源费用。 大数据流式处理:Flink 是未来 几年前,实现实时的流式处理几乎是不可能的事情。一些微批次处理框架(比如 Spark Streaming)可以提供“几近”实时的流式处理能力。不过,Flink 改变了这一状况,它提供了实时的流式处理能力。 2019 年之前,Flink 未能得到足够的关注,因为它无法撼动 Spark。直到 2019 年 1 月份,中国巨头公司阿里巴巴收购了 Data Artisan(Flink 背后的公司)。 在 2020 年,企业如果想要进行实时流式处理,Flink 应该是不二之选。不过,跟 Spark 一样,Flink 同样重度依赖 CPU 和 JVM,并且需要使用大量的云资源。 字节码:WebAssembly将被广泛采用 我从 JavaScript 作者 Brandon Eich 的一次访谈中知道了 WebAssembly 这个东西。现代 JavaScript(ES5 之后的版本)是一门优秀的编程语言,但与其他编程语言一样,都有自己的局限性。最大的局限性是 JavaScript 引擎在执行 JavaScript 时需要读取、解析和处理“抽象语法树”。另一个问题是 JavaScript 的单线程模型无法充分利用现代硬件(如多核 CPU 或 GPU)。正因为这些原因,很多计算密集型的应用程序(如游戏、3D 图像)无法运行在浏览器中。 一些公司(由 Mozilla 带领)开发了 WebAssembly,一种底层字节码格式,让任何一门编程语言都可以在浏览器中运行。目前发布的 WebAssembly 版本可以支持 C++、Rust 等。 WebAssembly 让计算密集型应用程序(比如游戏和 AutoCAD)可以在浏览器中运行。不过,WebAssembly 的目标不仅限于此,它还要让应用程序可以在浏览器之外运行。WebAssembly 可以被用在以下这些“浏览器外”的场景中。 移动设备上的混合原生应用。没有冷启动问题的无服务器计算。在服务器端执行不受信任的代码。 我预测,2020 年将是 WebAssembly 取得突破的一年,很多巨头公司(包括云厂商)和社区将会拥抱 WebAssembly。 代码:低代码 / 无代码将更进一步 快速的数字化和工业 4.0 革命意味着软件开发者的供需缺口巨大。由于缺乏开发人员,很多企业无法实现它们的想法。为了降低进入软件开发的门槛,可以尝试无代码(No Code)或低代码(Low Code)软件开发,也就是所谓的 LCNC(Low-Code No-Code)。它已经在 2019 年取得了一些成功。 LCNC 的目标是让没有编程经验的人也能开发软件,只要他们想要实现自己的想法。 虽然我对在正式环境中使用 LCNC 框架仍然心存疑虑,但它为其他公司奠定了良好的基础,像亚马逊和谷歌这样的公司可以基于这个基础构建出有用的产品,就像 AWS Lambda 的蓬勃发展是以谷歌 App Engine 为基础。 2020 年,LCNC 将会获得更多关注。

茶什i 2019-12-26 11:57:03 0 浏览量 回答数 0

问题

学术界关于HBase在物联网/车联网/互联网/金融/高能物理等八大场景的理论研究

pandacats 2019-12-18 16:06:18 1 浏览量 回答数 0

回答

本文档介绍文件存储HDFS和对象存储OSS之间的数据迁移过程。您可以将文件存储HDFS数据迁移到对象存储OSS,也可以将对象存储OSS的数据迁移到文件存储HDFS上。 背景信息 阿里云文件存储HDFS是面向阿里云ECS实例及容器服务等计算资源的文件存储服务。文件存储HDFS允许您就像在Hadoop分布式文件系统中管理和访问数据,并对热数据提供高性能的数据访问能力。对象存储OSS是海量、安全、低成本、高可靠的云存储服务,并提供标准型、归档型等多种存储类型供选择。客户可以在文件存储HDFS和对象存储OSS之间实现数据迁移,从而实现热、温、冷数据的合理分层,在实现对热数据的高性能访问的同时,有效控制存储成本。 准备工作 挂载文件系统,详情请参见挂载文件系统。 验证文件系统和计算节点之间的连通性。 执行以下命令,在文件存储HDFS上创建目录(如:/dfs_links)。 hadoop fs -mkdir /dfs_links 执行以下命令,验证连通性。 hadoop fs -ls dfs://f-xxxxxxxxxxxxxxx.cn-xxxxxxx.dfs.aliyuncs.com:10290/dfs_links 其中f-xxxxxxxxxxxxxxx.cn-xxxxxxx.dfs.aliyuncs.com为文件存储HDFS挂载点域名,请根据实际情况进行修改。 如果命令正常执行无输出结果,则表示连通成功。如果连通失败,请参见创建文件系统实例后,为什么无法访问文件存储HDFS?进行排查。 准备迁移工具。 单击emr-tools下载迁移工具安装包。 将迁移工具安装包上传计算节点的本地目录。 说明 该计算节点必须运行着Hadoop的YARN服务,或者是YARN集群中可以提交作业的计算节点。因为emr-tools迁移工具需要借助Hadoop数据迁移工具DistCp实现数据的迁移。 执行以下命令,解压安装包。 tar jxf emr-tools.tar.bz2 将文件存储HDFS数据迁移到对象存储OSS 进入emr-tools工具安装包解压后所在的目录,使用hdfs2oss4emr.sh脚本将文件存储HDFS上的数据迁移到对象存储OSS上,具体命令如下所示。 cd emr-tools ./hdfs2oss4emr.sh dfs://f-xxxxxxxxxxxxxxx.cn-xxxxxxx.dfs.aliyuncs.com:10290/HDFS2OSS/data/data_1000g oss://accessKeyId:accessKeySecret@bucket-name.oss-cn-hangzhou.aliyuncs.com/HDFS2OSS/data/data_1000g 参数说明如下表所示。 参数 说明 accessKeyId 访问对象存储OSS API的密钥。获取方式请参见如何获取AccessKeyId和AccessKeySecret。 accessKeySecret bucket-name.oss-cn-hangzhou.aliyuncs.com 对象存储OSS的访问域名,包括bucket名称和endpoint地址。 执行以上命令后,系统将启动一个Hadoop MapReduce任务(DistCp)。 任务执行完成后,查看迁移结果。 如果回显包含如下类似信息,说明迁移成功。 19/03/27 08:48:58 INFO mapreduce.Job: Job job_1553599949635_0014 completed successfully 19/03/27 08:48:59 INFO mapreduce.Job: Counters: 38 File System Counters FILE: Number of bytes read=0 FILE: Number of bytes written=2462230 FILE: Number of read operations=0 FILE: Number of large read operations=0 FILE: Number of write operations=0 HDFS: Number of bytes read=1000001748624 HDFS: Number of bytes written=0 HDFS: Number of read operations=40124 HDFS: Number of large read operations=0 HDFS: Number of write operations=40 OSS: Number of bytes read=0 OSS: Number of bytes written=1000000000000 OSS: Number of read operations=0 OSS: Number of large read operations=0 OSS: Number of write operations=0 Job Counters Launched map tasks=20 Other local map tasks=20 Total time spent by all maps in occupied slots (ms)=65207738 Total time spent by all reduces in occupied slots (ms)=0 Total time spent by all map tasks (ms)=65207738 Total vcore-milliseconds taken by all map tasks=65207738 Total megabyte-milliseconds taken by all map tasks=66772723712 Map-Reduce Framework Map input records=10002 Map output records=0 Input split bytes=2740 Spilled Records=0 Failed Shuffles=0 Merged Map outputs=0 GC time elapsed (ms)=58169 CPU time spent (ms)=5960400 Physical memory (bytes) snapshot=4420333568 Virtual memory (bytes) snapshot=42971959296 Total committed heap usage (bytes)=2411724800 File Input Format Counters Bytes Read=1745884 File Output Format Counters Bytes Written=0 org.apache.hadoop.tools.mapred.CopyMapper$Counter BYTESCOPIED=1000000000000 BYTESEXPECTED=1000000000000 COPY=10002 copy from dfs://f-xxxxxxxxxxxxxxx.cn-xxxxxxx.dfs.aliyuncs.com:10290/path/on/dfs to oss://accessKeyId:accessKeySecret@bucket-name.oss-cn-hangzhou.aliyuncs.com/path/on/oss does succeed !!! 迁移完成后,您可以通过osscmd工具,执行以下命令查看对象存储OSS上的数据情况。 osscmd ls oss://bucket-name/HDFS2OSS/data/data_1000g 将对象存储OSS数据迁移到文件存储HDFS 进入emr-tools工具安装包解压后所在的目录,使用hdfs2oss4emr.sh脚本将对象存储OSS上的数据迁移到文件存储HDFS上,具体命令如下所示。 cd emr-tools ./hdfs2oss4emr.sh oss://accessKeyId:accessKeySecret@bucket-name.oss-cn-hangzhou.aliyuncs.com/OSS2HDFS/oss/1000g dfs://f-xxxxxxxxxxxxxxx.cn-xxxxxxx.dfs.aliyuncs.com:10290/OSS2HDFS/data/data_1000g 参数说明如下表所示。 参数 说明 accessKeyId 访问对象存储OSS API的密钥。获取方式请参见如何获取AccessKeyId和AccessKeySecret。 accessKeySecret bucket-name.oss-cn-hangzhou.aliyuncs.com 对象存储OSS的访问域名,包括bucket名称和endpoint地址。 执行以上命令后,系统将启动一个Hadoop MapReduce任务(DistCp)。 任务执行完成后,查看迁移结果。 如果回显包含如下类似信息,说明迁移成功。 19/03/23 21:59:23 INFO mapreduce.Job: Counters: 38 File System Counters DFS: Number of bytes read=2335687 DFS: Number of bytes written=999700000000 DFS: Number of read operations=60218 DFS: Number of large read operations=0 DFS: Number of write operations=20076 FILE: Number of bytes read=0 FILE: Number of bytes written=2575367 FILE: Number of read operations=0 FILE: Number of large read operations=0 FILE: Number of write operations=0 OSS: Number of bytes read=0 OSS: Number of bytes written=0 OSS: Number of read operations=0 OSS: Number of large read operations=0 OSS: Number of write operations=0 Job Counters Launched map tasks=21 Other local map tasks=21 Total time spent by all maps in occupied slots (ms)=36490484 Total time spent by all reduces in occupied slots (ms)=0 Total time spent by all map tasks (ms)=36490484 Total vcore-milliseconds taken by all map tasks=36490484 Total megabyte-milliseconds taken by all map tasks=37366255616 Map-Reduce Framework Map input records=10018 Map output records=0 Input split bytes=2856 Spilled Records=0 Failed Shuffles=0 Merged Map outputs=0 GC time elapsed (ms)=1064802 CPU time spent (ms)=10370840 Physical memory (bytes) snapshot=6452363264 Virtual memory (bytes) snapshot=45328142336 Total committed heap usage (bytes)=4169138176 File Input Format Counters Bytes Read=2332831 File Output Format Counters Bytes Written=0 org.apache.hadoop.tools.mapred.CopyMapper$Counter BYTESCOPIED=999700000000 BYTESEXPECTED=999700000000 COPY=10018 copy from oss://accessKeyId:accessKeySecret@bucket-name.oss-cn-hangzhou.aliyuncs.com/path/on/oss to dfs://f-xxxxxxxxxxxxxxx.cn-xxxxxxx.dfs.aliyuncs.com:10290/path/on/dfs does succeed !!! 迁移完成后,您可以执行以下命令查看文件存储HDFS上的数据情况。 hadoop fs -ls dfs://f-xxxxxxxxxxxxxxx.cn-xxxxxxx.dfs.aliyuncs.com:10290/OSS2HDFS/data/data_1000g 常见问题 迁移过程出现异常提示:Cannot obtain block length for LocatedBlock。 从原生HDFS往对象存储OSS/文件存储HDFS迁移数据时,可能会遇到这个问题。遇到该问题时,请执行hdfs fsck / –openforwrite命令,检查当前是否有文件处于写入状态尚未关闭。 如果有处于写入状态的文件时,需判断文件是否有效。 如果文件无效,则直接删除文件。 hdfs rm 如果文件有效,则不能直接删除,请考虑恢复问题文件租约。 hdfs debug recoverLease -path -retries 对于正在写入的文件,进行迁移时会遗漏掉最新写入的数据吗? Hadoop兼容文件系统提供单写者多读者并发语义,针对同一个文件,同一时刻可以有一个写者写入和多个读者读出。以文件存储HDFS到对象存储OSS的数据迁移为例,数据迁移任务打开文件存储HDFS的文件F,根据当前系统状态决定文件F的长度L,将L字节迁移到对象存储OSS。如果在数据迁移过程中,有并发的写者写入,文件F的长度将超过L,但是数据迁移任务无法感知到最新写入的数据。因此,建议您在做数据迁移时,避免往迁移的文件中写入数据。

1934890530796658 2020-03-31 02:35:12 0 浏览量 回答数 0

回答

你好,这里有208份资料,详情请参考:https://github.com/ty4z2008/Qix/blob/master/ds.md 《Reconfigurable Distributed Storage for Dynamic Networks》介绍:这是一篇介绍在动态网络里面实现分布式系统重构的paper.论文的作者(导师)是MIT读博的时候是做分布式系统的研究的,现在在NUS带学生,不仅仅是分布式系统,还有无线网络.如果感兴趣可以去他的主页了解. 《Distributed porgramming liboratory》介绍:分布式编程实验室,他们发表的很多的paper,其中不仅仅是学术研究,还有一些工业界应用的论文. 《MIT Theory of Distributed Systems》介绍:麻省理工的分布式系统理论主页,作者南希·林奇在2002年证明了CAP理论,并且著《分布式算法》一书. 《Notes on Distributed Systems for Young Bloods》介绍:分布式系统搭建初期的一些建议 《Principles of Distributed Computing》介绍:分布式计算原理课程 《Google's Globally-Distributed Database》介绍:Google全球分布式数据介绍,中文版 《The Architecture Of Algolia’s Distributed Search Network》介绍:Algolia的分布式搜索网络的体系架构介绍 《Build up a High Availability Distributed Key-Value Store》介绍:构建高可用分布式Key-Value存储系统 《Distributed Search Engine with Nanomsg and Bond》介绍:Nanomsg和Bond的分布式搜索引擎 《Distributed Processing With MongoDB And Mongothon》介绍:使用MongoDB和Mongothon进行分布式处理 《Salt: Combining ACID and BASE in a Distributed Database》介绍:分布式数据库中把ACID与BASE结合使用. 《Makes it easy to understand Paxos for Distributed Systems》介绍:理解的Paxos的分布式系统,参考阅读:关于Paxos的历史 《There is No Now Problems with simultaneity in distributed systems》介绍:There is No Now Problems with simultaneity in distributed systems 《Distributed Systems》介绍:伦敦大学学院分布式系统课程课件. 《Distributed systems for fun and profit》介绍:分布式系统电子书籍. 《Distributed Systems Spring 2015》介绍:卡内基梅隆大学春季分布式课程主页 《Distributed Systems: Concepts and Design (5th Edition)》介绍: 电子书,分布式系统概念与设计(第五版) 《走向分布式》介绍:这是一位台湾网友 ccshih 的文字,短短的篇幅介绍了分布式系统的若干要点。pdf 《Introduction to Distributed Systems Spring 2013》介绍:清华大学分布式系统课程主页,里面的schedule栏目有很多宝贵的资源 《Distributed systems》介绍:免费的在线分布式系统书籍 《Some good resources for learning about distributed computing》介绍:Quora上面的一篇关于学习分布式计算的资源. 《Spanner: Google’s Globally-Distributed Database》介绍:这个是第一个全球意义上的分布式数据库,也是Google的作品。其中介绍了很多一致性方面的设计考虑,为了简单的逻辑设计,还采用了原子钟,同样在分布式系统方面具有很强的借鉴意义. 《The Chubby lock service for loosely-coupled distributed systems》介绍:Google的统面向松散耦合的分布式系统的锁服务,这篇论文详细介绍了Google的分布式锁实现机制Chubby。Chubby是一个基于文件实现的分布式锁,Google的Bigtable、Mapreduce和Spanner服务都是在这个基础上构建的,所以Chubby实际上是Google分布式事务的基础,具有非常高的参考价值。另外,著名的zookeeper就是基于Chubby的开源实现.推荐The google stack,Youtube:The Chubby lock service for loosely-coupled distributed systems 《Sinfonia: a new paradigm for building scalable distributed systems》介绍:这篇论文是SOSP2007的Best Paper,阐述了一种构建分布式文件系统的范式方法,个人感觉非常有用。淘宝在构建TFS、OceanBase和Tair这些系统时都充分参考了这篇论文. 《Data-Intensive Text Processing with MapReduce》介绍:Ebook:Data-Intensive Text Processing with MapReduce. 《Design and Implementation of a Query Processor for a Trusted Distributed Data Base Management System》介绍:Design and Implementation of a Query Processor for a Trusted Distributed Data Base Management System. 《Distributed Query Processing》介绍:分布式查询入门. 《Distributed Systems and the End of the API》介绍:分布式系统和api总结. 《Distributed Query Reading》介绍:分布式系统阅读论文,此外还推荐github上面的一个论文列表The Distributed Reader。 《Replication, atomicity and order in distributed systems》介绍:Replication, atomicity and order in distributed systems 《MIT course:Distributed Systems》介绍:2015年MIT分布式系统课程主页,这次用Golang作为授课语言。6.824 Distributed Systems课程主页 《Distributed systems for fun and profit》介绍:免费分布式系统电子书。 《Ori:A Secure Distributed File System》介绍:斯坦福开源的分布式文件系统。 《Availability in Globally Distributed Storage Systems》介绍:Google论文:设计一个高可用的全球分布式存储系统。 《Calvin: Fast Distributed Transactions For Partitioned Database Systems》介绍:对于分区数据库的分布式事务处理。 《Distributed Systems Building Block: Flake Ids》介绍:Distributed Systems Building Block: Flake Ids. 《Introduction to Distributed System Design》介绍:Google Code University课程,如何设计一个分布式系统。 《Sheepdog: Distributed Storage System for KVM》介绍:KVM的分布式存储系统. 《Readings in Distributed Systems Systems》介绍:分布式系统课程列表,包括数据库、算法等. 《Tera》介绍:来自百度的分布式表格系统. 《Distributed systems: for fun and profit》介绍:分布式系统的在线电子书. 《Distributed Systems Reading List》介绍:分布式系统资料,此外还推荐Various articles about distributed systems. 《Designs, Lessons and Advice from Building Large Distributed Systems》介绍:Designs, Lessons and Advice from Building Large Distributed Systems. 《Testing a Distributed System》介绍:Testing a distributed system can be trying even under the best of circumstances. 《The Google File System》介绍: 基于普通服务器构建超大规模文件系统的典型案例,主要面向大文件和批处理系统, 设计简单而实用。 GFS是google的重要基础设施, 大数据的基石, 也是Hadoop HDFS的参考对象。 主要技术特点包括: 假设硬件故障是常态(容错能力强), 64MB大块, 单Master设计,Lease/链式复制, 支持追加写不支持随机写. 《Bigtable: A Distributed Storage System for Structured Data》介绍:支持PB数据量级的多维非关系型大表, 在google内部应用广泛,大数据的奠基作品之一 , Hbase就是参考BigTable设计。 Bigtable的主要技术特点包括: 基于GFS实现数据高可靠, 使用非原地更新技术(LSM树)实现数据修改, 通过range分区并实现自动伸缩等.中文版 《PacificA: Replication in Log-Based Distributed Storage Systems》介绍:面向log-based存储的强一致的主从复制协议, 具有较强实用性。 这篇文章系统地讲述了主从复制系统应该考虑的问题, 能加深对主从强一致复制的理解程度。 技术特点: 支持强一致主从复制协议, 允许多种存储实现, 分布式的故障检测/Lease/集群成员管理方法. 《Object Storage on CRAQ, High-throughput chain replication for read-mostly workloads》介绍:分布式存储论文:支持强一直的链式复制方法, 支持从多个副本读取数据,实现code. 《Finding a needle in Haystack: Facebook’s photo storage》介绍:Facebook分布式Blob存储,主要用于存储图片. 主要技术特色:小文件合并成大文件,小文件元数据放在内存因此读写只需一次IO. 《Windows Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency》介绍: 微软的分布式存储平台, 除了支持类S3对象存储,还支持表格、队列等数据模型. 主要技术特点:采用Stream/Partition两层设计(类似BigTable);写错(写满)就封存Extent,使得副本字节一致, 简化了选主和恢复操作; 将S3对象存储、表格、队列、块设备等融入到统一的底层存储架构中. 《Paxos Made Live – An Engineering Perspective》介绍:从工程实现角度说明了Paxo在chubby系统的应用, 是理解Paxo协议及其应用场景的必备论文。 主要技术特点: paxo协议, replicated log, multi-paxo.参考阅读:关于Paxos的历史 《Dynamo: Amazon’s Highly Available Key-Value Store》介绍:Amazon设计的高可用的kv系统,主要技术特点:综和运用一致性哈希,vector clock,最终一致性构建一个高可用的kv系统, 可应用于amazon购物车场景.新内容来自分布式存储必读论文 《Efficient Replica Maintenance for Distributed Storage Systems》介绍:分布式存储系统中的副本存储问题. 《PADS: A Policy Architecture for Distributed Storage Systems》介绍:分布式存储系统架构. 《The Chirp Distributed Filesystem》介绍:开源分布式文件系统Chirp,对于想深入研究的开发者可以阅读文章的相关Papers. 《Time, Clocks, and the Ordering of Events in a Distributed System》介绍:经典论文分布式时钟顺序的实现原理. 《Making reliable distributed systems in the presence of sodware errors》介绍:面向软件错误构建可靠的分布式系统,中文笔记. 《MapReduce: Simplified Data Processing on Large Clusters》介绍:MapReduce:超大集群的简单数据处理. 《Distributed Computer Systems Engineering》介绍:麻省理工的分布式计算课程主页,里面的ppt和阅读列表很多干货. 《The Styx Architecture for Distributed Systems》介绍:分布式系统Styx的架构剖析. 《What are some good resources for learning about distributed computing? Why?》介绍:Quora上面的一个问答:有哪些关于分布式计算学习的好资源. 《RebornDB: The Next Generation Distributed Key-Value Store》介绍:下一代分布式k-v存储数据库. 《Operating System Concepts Ninth Edition》介绍:分布式系统归根结底还是需要操作系统的知识,这是耶鲁大学的操作系统概念书籍首页,里面有提供了第8版的在线电子版和最新的学习操作系统指南,学习分布式最好先学习操作系统. 《The Log: What every software engineer should know about real-time data's unifying abstraction》介绍:分布式系统Log剖析,非常的详细与精彩. 中文翻译 | 中文版笔记. 《Operating Systems Study Guide》介绍:分布式系统基础之操作系统学习指南. 《分布式系统领域经典论文翻译集》介绍:分布式系统领域经典论文翻译集. 《Maintaining performance in distributed systems》介绍:分布式系统性能维护. 《Computer Science from the Bottom Up》介绍:计算机科学,自底向上,小到机器码,大到操作系统内部体系架构,学习操作系统的另一个在线好材料. 《Operating Systems: Three Easy Pieces》介绍:<操作系统:三部曲>在线电子书,虚拟、并发、持续. 《Database Systems: reading list》介绍:数据库系统经典论文阅读列,此外推送github上面的db reading. 《Unix System Administration》介绍:Unix System Administration ebook. 《The Amoeba Distributed Operating System》介绍:分布式系统经典论文. 《Principles of Computer Systems》介绍:计算机系统概念,以分布式为主.此外推荐Introduction to Operating Systems笔记 《Person page of EMİN GÜN SİRER》介绍:推荐康奈尔大学的教授EMİN GÜN SİRER的主页,他的研究项目有分布式,数据存储。例如HyperDex数据库就是他的其中一个项目之一. 《Scalable, Secure, and Highly Available Distributed File Access》介绍:来自卡内基梅隆如何构建可扩展的、安全、高可用性的分布式文件系统,其他papers. 《Distributed (Deep) Machine Learning Common》介绍:分布式机器学习常用库. 《The Datacenter as a Computer》介绍:介绍了如何构建仓储式数据中心,尤其是对于现在的云计算,分布式学习来说很有帮助.本书是Synthesis Lectures on Computer Architecture系列的书籍之一,这套丛书还有 《The Memory System》,《Automatic Parallelization》,《Computer Architecture Techniques for Power Efficiency》,《Performance Analysis and Tuning for General Purpose Graphics Processing Units》,《Introduction to Reconfigurable Supercomputing》,Memory Systems Cache, DRAM, Disk 等 《helsinki:Distributed Systems Course slider》介绍:来自芬兰赫尔辛基的分布式系统课程课件:什么是分布式,复制,一致性,容错,同步,通信. 《TiDB is a distributed SQL database》介绍:分布式数据库TiDB,Golang开发. 《S897: Large-Scale Systems》介绍:课程资料:大规模系统. 《Large-scale L-BFGS using MapReduce》介绍:使用MapReduce进行大规模分布式集群环境下并行L-BFGS. 《Twitter是如何构建高性能分布式日志的》介绍:Twitter是如何构建高性能分布式日志的. 《Distributed Systems: When Limping Hardware Is Worse Than Dead Hardware》介绍:在分布式系统中某个组件彻底死了影响很小,但半死不活(网络/磁盘),对整个系统却是毁灭性的. 《Tera - 高性能、可伸缩的结构化数据库》介绍:来自百度的分布式数据库. 《SequoiaDB is a distributed document-oriented NoSQL Database》介绍:SequoiaDB分布式文档数据库开源. 《Readings in distributed systems》介绍:这个网址里收集了一堆各TOP大学分布式相关的课程. 《Paxos vs Raft》介绍:这个网站是Raft算法的作者为教授Paxos和Raft算法做的,其中有两个视频链接,分别讲上述两个算法.参考阅读:关于Paxos的历史 《A Scalable Content-Addressable Network》介绍:A Scalable Content-Addressable Network. 《500 Lines or Less》介绍:这个项目其实是一本书( The Architecture of Open Source Applications)的源代码附录,是一堆大牛合写的. 《MIT 6.824 Distributed System》介绍:这只是一个课程主页,没有上课的视频,但是并不影响你跟着它上课:每一周读两篇课程指定的论文,读完之后看lecture-notes里对该论文内容的讨论,回答里面的问题来加深理解,最后在课程lab里把所看的论文实现。当你把这门课的作业刷完后,你会发现自己实现了一个分布式数据库. 《HDFS-alike in Go》介绍:使用go开发的分布式文件系统. 《What are some good resources for learning about distributed computing? Why?》介绍:Quora上关于学习分布式的资源问答. 《SeaweedFS is a simple and highly scalable distributed file system》介绍:SeaweedFS是使用go开发的分布式文件系统项目,代码简单,逻辑清晰. 《Codis - yet another fast distributed solution for Redis》介绍:Codis 是一个分布式 Redis 解决方案, 对于上层的应用来说, 连接到 Codis Proxy 和连接原生的 Redis Server 没有明显的区别 《Paper: Coordination Avoidance In Distributed Databases By Peter Bailis》介绍:Coordination Avoidance In Distributed Databases. 《从零开始写分布式数据库》介绍:本文以TiDB 源码为例. 《what we talk about when we talk about distributed systems》介绍:分布式系统概念梳理,为分布式系统涉及的主要概念进行了梳理. 《Distributed locks with Redis》介绍:使用Redis实现分布式锁. 《CS244b: Distributed Systems》介绍: 斯坦福2014年秋季分布式课程. 《RAMP Made Easy》介绍: 分布式的“读原子性”. 《Strategies and Principles of Distributed Machine Learning on Big Data》介绍: 大数据分布式机器学习的策略与原理. 《Distributed Systems: What is the CAP theorem?》介绍: 分布式CAP法则. 《How should I start to learn distributed storage system as a beginner?》介绍: 新手如何步入分布式存储系统. 《Cassandra - A Decentralized Structured Storage System》介绍: 分布式存储系统Cassandra剖析,推荐白皮书Introduction to Apache Cassandra. 《What is the best resource to learn about distributed systems?》介绍: 分布式系统学习资源. 《What are some high performance TCP hacks?》介绍: 一些高性能TCP黑客技巧. 《Maintaining performance in distributed systems》介绍:分布式系统性能提升. 《A simple totally ordered broadcast protocol》介绍:Benjamin Reed 和 Flavio P.Junqueira 所著论文,对Zab算法进行了介绍,zab算法是Zookeeper保持数据一致性的核心,在国内有很多公司都使用zookeeper做为分布式的解决方案.推荐与此相关的一篇文章ZooKeeper’s atomic broadcast protocol: Theory and practice. 《zFS - A Scalable Distributed File System Using Object Disk》介绍:可扩展的分布式文件系统ZFS,The Zettabyte File System,End-to-end Data Integrity for File Systems: A ZFS Case Study. 《A Distributed Haskell for the Modern Web》介绍:分布式Haskell在当前web中的应用. 《Reasoning about Consistency Choices in Distributed Systems》介绍:POPL2016的论文,关于分布式系统一致性选择的论述,POPL所接受的论文,github上已经有人整理. 《Paxos Made Simple》介绍:Paxos让分布式更简单.译文.参考阅读:关于Paxos的历史,understanding Paxos part1,Understanding Paxos – Part 2.Quora: What is a simple explanation of the Paxos algorithm?,Tutorial Summary: Paxos Explained from Scratch,Paxos algorithm explained, part 1: The essentials,Paxos algorithm explained, part 2: Insights 《Consensus Protocols: Paxos》介绍:分布式系统一致性协议:Paxos.参考阅读:关于Paxos的历史 《Consensus on Transaction Commit》介绍:事务提交的一致性探讨. 《The Part-Time Parliaments》介绍:在《The Part-Time Parliament》中描述了基本协议的交互过程。在基本协议的基础上完善各种问题得到了最终的议会协议。 为了让人更容易理解《The Part-Time Parliament》中描述的Paxos算法,Lamport在2001发表了《Paxos Made Simple》,以更平直的口头语言描述了Paxos,而没有包含正式的证明和数学术语。《Paxos Made Simple》中,将算法的参与者更细致的划分成了几个角色:Proposer、Acceptor、Learner。另外还有Leader和Client.参考阅读:关于Paxos的历史 《Paxos Made Practical》介绍:看这篇论文时可以先看看理解Paxos Made Practical. 《PaxosLease: Diskless Paxos for Leases》介绍:PaxosLease:实现租约的无盘Paxos算法,译文. 《Paxos Made Moderately Complex》介绍:Paxos算法实现,译文,同时推荐42 Paxos Made Moderately Complex. 《Hadoop Reading List》介绍:Hadoop学习清单. 《Hadoop Reading List》介绍:Hadoop学习清单. 《2010 NoSQL Summer Reading List》介绍:NoSQL知识清单,里面不仅仅包含了数据库阅读清单还包含了分布式系统资料. 《Raft: Understandable Distributed Consensus》介绍:Raft可视化图帮助理解分布式一致性 《Etcd:Distributed reliable key-value store for the most critical data of a distributed system》介绍:Etcd分布式Key-Value存储引擎 《Understanding Availability》介绍:理解peer-to-peer系统中的可用性究竟是指什么.同时推荐基于 Peer-to-Peer 的分布式存储系统的设计 《Process structuring, synchronization, and recovery using atomic actions》介绍:经典论文 《Programming Languages for Parallel Processing》介绍:并行处理的编程语音 《Analysis of Six Distributed File Systems》介绍:此篇论文对HDFS,MooseFS,iRODS,Ceph,GlusterFS,Lustre六个存储系统做了详细分析.如果是自己研发对应的存储系统推荐先阅读此篇论文 《A Survey of Distributed File Systems》介绍:分布式文件系统综述 《Concepts of Concurrent Programming》介绍:并行编程的概念,同时推荐卡内基梅隆FTP 《Concurrency Control Performance Modeling:Alternatives and Implications》介绍:并发控制性能建模:选择与意义 《Distributed Systems - Concepts and Design 5th Edition》介绍:ebook分布式系统概念与设计 《分布式系统设计的形式方法》介绍:分布式系统设计的形式方法 《互斥和选举算法》介绍:互斥和选举算法 《Actors:A model Of Concurrent Cornputation In Distributed Systems》介绍:经典论文 《Security Engineering: A Guide to Building Dependable Distributed Systems》介绍:如何构建一个安全可靠的分布式系统,About the Author,Bibliography:文献资料,章节访问把链接最后的01换成01-27即可 《15-712 Advanced and Distributed Operating Systems》介绍:卡内基梅隆大学的分布式系统博士生课程主页,有很丰富的资料 《Dapper, Google's Large-Scale Distributed Systems Tracing Infrastructure》介绍:Dapper,大规模分布式系统的跟踪系统,译文,译文对照 《CS262a: Advanced Topics in Computer Systems》介绍:伯克利大学计算机系统进阶课程,内容有深度,涵盖分布式,数据库等内容 《Egnyte Architecture: Lessons Learned In Building And Scaling A Multi Petabyte Distributed System》介绍:PB级分布式系统构建/扩展经验 《CS162: Operating Systems and Systems Programming》介绍:伯克利大学计算机系统课程:操作系统与系统编程 《MDCC: Multi-Data Center Consistency》介绍:MDCC主要解决跨数据中心的一致性问题中间件,一种新的协议 《Research at Google:Distributed Systems and Parallel Computing》介绍:google公开对外发表的分布式系统与并行计算论文 《HDFS Architecture Guide》介绍:分布式文件系统HDFS架构 《ActorDB distributed SQL database》介绍:分布式 Key/Value数据库 《An efficient data location protocol for self-organizing storage clusters》介绍:是著名的Ceph的负载平衡策略,文中提出的几种策略都值得尝试,比较赞的一点是可以对照代码体会和实践,如果你还需要了解可以看看Ceph:一个 Linux PB 级分布式文件系统,除此以外,论文的引用部分也挺值得阅读的,同时推荐Ceph: A Scalable, High-Performance Distributed File System 《A Self-Organizing Storage Cluster for Parallel Data-Intensive Applications》介绍:Surrento的冷热平衡策略就采用了延迟写技术 《HBA: Distributed Metadata Management for Large Cluster-Based Storage Systems》介绍:对于分布式存储系统的元数据管理. 《Server-Side I/O Coordination for Parallel File Systems》介绍:服务器端的I/O协调并行文件系统处理,网络,文件存储等都会涉及到IO操作.不过里面涉及到很多技巧性的思路在实践时需要斟酌 《Distributed File Systems: Concepts and Examples》介绍:分布式文件系统概念与应用 《CSE 221: Graduate Operating Systems》介绍:加利福尼亚大学的研究生操作系统课程主页,论文很值得阅读 《S4: Distributed Stream Computing Platform》介绍:Yahoo出品的流式计算系统,目前最流行的两大流式计算系统之一(另一个是storm),Yahoo的主要广告计算平台 《Pregel: a system for large-scale graph processing》介绍:Google的大规模图计算系统,相当长一段时间是Google PageRank的主要计算系统,对开源的影响也很大(包括GraphLab和GraphChi) 《GraphLab: A New Framework for Parallel Machine Learning》介绍:CMU基于图计算的分布式机器学习框架,目前已经成立了专门的商业公司,在分布式机器学习上很有两把刷子,其单机版的GraphChi在百万维度的矩阵分解都只需要2~3分钟; 《F1: A Distributed SQL Database That Scales》介绍:这篇论文是Google 2013年发表的,介绍了F1的架构思路,13年时就开始支撑Google的AdWords业务,另外两篇介绍文章F1 - The Fault-Tolerant Distributed RDBMS Supporting Google's Ad Business .Google NewSQL之F1 《Cockroach DB:A Scalable, Survivable, Strongly-Consistent SQL Database》介绍:CockroachDB :一个可伸缩的、跨地域复制的,且支持事务的数据存储,InfoQ介绍,Design and Architecture of CockroachDb 《Multi-Paxos: An Implementation and Evaluation》介绍:Multi-Paxos实现与总结,此外推荐Paxos/Multi-paxos Algorithm,Multi-Paxos Example,地址:ftp://ftp.cs.washington.edu/tr/2009/09/UW-CSE-09-09-02.PDF 《Zab: High-performance broadcast for primary-backup systems》介绍:一致性协议zab分析 《A Distributed Hash Table》介绍:分布式哈希算法论文,扩展阅读Introduction to Distributed Hash Tables,Distributed Hash Tables 《Comparing the performance of distributed hash tables under churn》介绍:分布式hash表性能的Churn问题 《Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web》介绍:分布式系统的CAP问题,推荐Perspectives on the CAP Theorem.对CAP理论的解析文章,PODC ppt,A plain english introduction to CAP Theorem,IEEE Computer issue on the CAP Theorem 《F2FS: A New File System for Flash Storage》介绍:闪存存储文件系统F2FS 《Better I/O Through Byte-Addressable, Persistent Memory》介绍:微软发表的关于i/o访问优化论文 《tmpfs: A Virtual Memory File System》介绍:虚拟内存文件系统tmpfs 《BTRFS: The Linux B-tree Filesystem》介绍:Linux B-tree文件系统. 《Akamai technical publication》介绍:Akamai是全球最大的云计算机平台之一,承载了全球15-30%网络流量,如果你是做CDN或者是云服务,这个里面的论文会给你很有帮助.例如这几天看facebook开源的osquery。找到通过db的方式运维,找到Keeping Track of 70,000+ Servers: The Akamai Query System这篇论文,先看论文领会思想,然后再使用工具osquery实践 《BASE: An Acid Alternative》介绍:来自eBay 的解决方案,译文Base: 一种Acid的替代方案,应用案例参考保证分布式系统数据一致性的6种方案 《A Note on Distributed Computing》介绍:Jim Waldo和Sam Kendall等人共同撰写了一篇非常有名的论文“分布式计算备忘录”,这篇论文在Reddit上被人推荐为“每个程序员都应当至少读上两篇”的论文。在这篇论文中,作者表示“忽略本地计算与分布式计算之间的区别是一种危险的思想”,特别指出了Emerald、Argus、DCOM以及CORBA的设计问题。作者将这些设计问题归纳为“三个错误的原则”: “对于某个应用来说,无论它的部署环境如何,总有一种单一的、自然的面向对象设计可以符合其需求。” “故障与性能问题与某个应用的组件实现直接相关,在最初的设计中无需考虑这些问题。” “对象的接口与使用对象的上下文无关”. 《Distributed Systems Papers》介绍:分布式系统领域经典论文列表. 《Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web》介绍:Consistent Hashing算法描述. 《SIGMOD 2016: Accepted Research Papers》介绍:SIGMOD是世界上最有名的数据库会议之一,最具有权威性,收录论文审核非常严格.2016年的SIGMOD 会议照常进行,上面收录了今年SIGMOD收录的论文,把题目输入google中加上pdf就能找到,很多论文值得阅读,SIGMOD 2015 《Notes on CPSC 465/565: Theory of Distributed Systems》介绍:耶鲁大学的分布式系统理论课程笔记 《Distributed Operating System Doc PDF》介绍:分布式系统文档资源(可下载) 《Anatomy of a database system》介绍:数据库系统剖析,这本书是由伯克利大学的Joseph M. Hellerstein和M. Stonebraker合著的一篇论文.对数据库剖析很有深度.除此以外还有一篇文章Architecture of a Database System。数据库系统架构,厦门大学的数据库实验室教授林子雨组织过翻译 《A Relational Model of Data for Large Shared Data Banks》介绍:数据库关系模型论文 《RUC Innovative data systems reaserch lab recommand papers》介绍:中国人民大学数据研究实验室推荐的数据库领域论文 《A Scalable Distributed Information Management System》介绍:构建可扩展的分布式信息管理系统 《Distributed Systems in Haskell》介绍:Haskell中的分布式系统开发 《Large-scale cluster management at Google with Borg》介绍:Google使用Borg进行大规模集群的管理,伯克利大学ppt介绍,中文版 《Lock Free Programming Practice》介绍:并发编程(Concurrency Programming)资料,主要涵盖lock free数据结构实现、内存回收方法、memory model等备份链接 密码: xc5j 《Distributed Algorithms Lecture Notes for 6.852》介绍:Nancy Lynch's的分布式算法研究生课程讲义 《Distributed Algorithms for Topic Models》介绍:分布式算法主题模型. 《RecSys - ACM Recommender Systems》介绍:世界上非常有名的推荐系统会议,我比较推荐接收的PAPER 《All Things Distributed》介绍:推荐一个博客,博主是Amazon CTO Werner Vogels,这是一个关注分布式领域的博客.大部分博文是关于在工业界应用. 《programming, database, distributed system resource list》介绍:这个Git是由阿里(alibaba)的技术专家何登成维护,主要是分布式数据库. 《Making reliable distributed systems in the presence of sodware errors》介绍:Erlang的作者Joe Armstrong撰写的论文,面对软件错误构建可靠的分布式系统.中文译版 《CS 525: Advanced Distributed Systems[Spring 2016]》介绍:伊利诺伊大学的Advanced Distributed Systems 里把各个方向重要papers(updated Spring 2015)列举出来,可以参考一下 《Distributed Algorithms》介绍:这是一本分布式算法电子书,作者是Jukka Suomela.讲述了多个计算模型,一致性,唯一标示,并发等. 《TinyLFU: A Highly Efficient Cache Admission Policy》介绍:当时是在阅读如何设计一个缓存系统时看到的,然后通过Google找到了这一篇关于缓存策略的论文,它是LFU的改良版,中文介绍.如果有兴趣可以看看Golang实现版。结合起来可能会帮助你理解 《6.S897: Large-Scale Systems》介绍:斯坦福大学给研究生开的分布式系统课程。教师是 spark 作者 matei. 能把这些内容真正理解透,分布式系统的功力就很强了。 《学习分布式系统需要怎样的知识?》介绍:[怎么学系列]学习分布式系统需要怎样的知识? 《Distributed systems theory for the distributed systems engineer》介绍:分布式系统工程师的分布式系统理论 《A Distributed Systems Reading List》介绍:分布式系统论文阅读列表 《Distributed Systems Reading Group》介绍:麻省理工大学分布式系统小组,他们会把平时阅读到的优秀论文分享出来。虽然有些论文本页已经收录,但是里面的安排表schedule还是挺赞的 《Scalable Software Architecture》介绍:分布式系统、可扩展性与系统设计相关报告、论文与网络资源汇总. 《MapReduce&Hadoop resource》介绍:MapReduce&Hadoop相关论文,涉及分布式系统设计,性能分析,实践,优化等多个方面 《Distributed Systems: Principles and Paradigms(second edtion)》介绍:分布式系统原理与范型第二版,课后解答 《Distributed Systems Seminar's reading list for Spring 2017》介绍:分布式系统研讨会论文阅读列表 《A Critique of the CAP Theorem》介绍:这是一篇评论CAP定理的论文,学习CAP很有帮助,推荐阅读评论文章"A Critique of the CAP Theorem" 《Evolving Distributed Systems》介绍:推荐文章不断进化的分布式系统.

suonayi 2019-12-02 03:17:27 0 浏览量 回答数 0

问题

【阿里云产品评测】个人WP站的云体验

cnsjw 2019-12-01 20:54:27 22207 浏览量 回答数 25
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 企业信息查询 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站 阿里云双十一主会场 阿里云双十一新人会场 1024程序员加油包 阿里云双十一拼团会场 场景化解决方案 阿里云双十一直播大厅