《Python分布式计算》 第8章 继续学习 (Distributed Computing with Python)前两章工具云平台和HPC调试和监控继续学习

这本书是一个简短但有趣的用Python编写并行和分布式应用的旅程。这本书真正要做的是让读者相信使用Python编写一个小型或中型分布式应用不仅是大多数开发者都能做的,而且也是非常简单的。

即使是一个简单的分布式应用也有许多组件,远多于单体应用。也有更多的错误方式,不同的机器上同一时间发生的事情也更多。

但是,幸好可以使用高质量的Python库和框架,来搭建分布式系统,使用起来也比多数人想象的简单。

另外,并行和分布式计算正逐渐变为主流,随着多核CPU的发展,如果还继续遵守摩尔定律,编写并行代码是必须的。

Celery、Python-RQ、Pyro等工具,只需要极少的精力,就可以获得性能极大地提高。

但是,必须要知道,分布式应用缺少强大的调试器和分析器,这个问题不局限于Python。监督和日志可以检测性能的瓶颈,进而查找到错误。现在这种缺少调试工具的状况,需要改善。

本章剩下的部分回顾了前面的所学,还给感兴趣的读者提了继续学习哪些工具和课题的建议。

前两章

本书的最初章节讲解了一些并行和分布式计算的基本理论。引入了一些重要的概念,如共享内存和分布式内存架构以及它们之间的差异。

这两章还用阿姆达尔定律研究了并行加速的基本算法。讨论的收获是,投入并行计算的收益是递减的。另外,绕过阿姆达尔定律的方法之一是增加的问题的规模,使并行代码所占的份额更大(古斯塔夫森定律)。

另一个收获是,尽量保持进程间通讯越小越好。最好让各个进程都是独立的。进程之间的通讯越少,代码越简单,损耗越少。

大多数实际场景都需要一系列扇出和扇入同步/还原步骤,大多数框架都能合理有效地处理这些步骤。然而,并行步骤中的数据依赖或大量消息传递通常会成为严重的问题。

提到的另一种架构是数据列车或数据并行。这是一种处理方式,其中一个启动大量的worker进程,超过可用硬件资源的数量。正如所看到的,数据并行的主要优点是很好的伸缩性和更简单的代码。此外,大多数操作系统和任务规划器在交错I/O和计算方面会做得很好,从而掩盖系统延迟。

我们还研究了两种完全不同的编程范式:同步和异步编程。我们看到Python对futures、回调、协程的支持很好,这是异步编程的核心。

正如我们所讨论的,异步代码具有避免,或者减少了竞争条件,因为只有一段代码可以在给定的时间点运行。这意味着,数据访问模式被大大简化了,但代码和调试变复杂了;当使用回调和协程,很难跟踪执行路径。

在本书中,我们看到了使用线程、多进程、协程的并行代码的性能。对于I/O操作,我们看到这三个并发策略可以实现显着的加速。然而,由于Python全局锁,CPU操作并没有获得加速,除非使用多个进程。

同步和异步编程都有其优点。使用的越多,越会发现线程和系统编程的C和C++很像。协程的优点之一就是避免竞争条件。多个进程,虽然在一台机器上相当笨重,但为更一般的分布式计算架构铺平了道路。使用哪种风格取决于个人喜好和必须使用的特定库。

工具

在第3章中,我们学习了Python的标准库模块,来编写并行应用。我们使用了threadingmultiprocessing模块,还使用了更为高级的concurrent.futures模块。

我们看到Python为分布式并行应用构建了一个坚固的基础。前面的是哪个模块都是Python安装包自带的,没有外部依赖,因此很受欢迎。

我们在第4章学习了一些第三方Python模块,包括Celery、Python-RQ和Pyro。我们学习了怎么使用它们,并看到它们都很容易使用。

它们都需要一些内部组件,比如消息代理、数据库或nameserver,它们可能不适用于所有情况。同时,它们都可以让开发者轻易地开发小型和中型的分布应用。它们都有活跃的社区给予支持。

关于代码的性能,最重要的是分析哪些代码是值得优化的。如果使用更快的解释器,比如pypy,不能使性能提高,就要考虑更优化的库,比如对数值代码使用Numpy,或使用C或Cython,它们都可以使性能提高。

如果这些方法不成,还可以考虑并发、并行和分布式结算,但会提高复杂性。

一个简单的办法是使用数据并行(例如,对不同的数据启用多个代码实例)。可以使用任务规划器,比如HTCondor。

稍微复杂一点的办法是使用concurrent.futures或Celery,使代码并行化。高级用户,特别是HP用户,还可以考虑使用MPI作为进程间通讯框架。

但是,并非所有的分布式应用都要用到Celery、Python-RQ和Pyro。特别是当应用需要复杂、高性能、分布式图片处理,使用Celery就不好。

此时,开发者可以使用工作流管理系统,例如Luigi (https://github.com/spotify/luigi),或流处理,比如Apache Spark或Storm。对于专门的Python工具,可以参考https://spark.apache.org/docs/0.9.1/python-programming-guide.html andhttps://github.com/Parsely/streamparse

云平台和HPC

第5章简要介绍了云计算和AWS。这是现在的热点,原因很简单:只要很少的投入,几乎不需要等待,就可以租用一些虚拟机,还可以租数据库和数据存储。如果需要更多的性能,可以方便地进行扩展。

Things, unfortunately, are never as simple as vendor brochures like to depict, especially when outsourcing a critical piece of infrastructure to a third party whose interests might not be perfectly aligned with ours.

不过,事情不像销售商手册描述的那样简单,特别是当把一个重要的工作外包给一个可能与我们的利益不完全一致的第三方的时候。

我的建议是总是设想最坏的情况,并在本地自动备份整个应用及其软件栈(至少在单独的个体上)。理想情况下(但实际上并不是这样),人们会在一个完全独立的云平台上运行一个缩减的、但最新的完整应用的拷贝,作为发生错误的保险。

使用第三方服务时,进行本地备份是非常重要的。用户虚拟机和数据被删除,不可找回,这种错误绝不要发生。还要考虑过度依赖某个服务商,当应用过大时,迁移到另一个服务商几乎是不可能的。

只使用最小公分母(例如,只使用EC2和AWS)既有吸引力,也可能让人沮丧,只能使用AWS提供的功能。

总之,云平台是一把双刃剑。对于小团队和小应用来说,它无疑是方便和低成本的。对于大型应用程序或处理大量数据的应用来说,它可能是相当昂贵的,因为带宽往往非常贵。

此外,学术界、政府部门或政府机构的团队可能很难获得支付云平台所需的资金。事实上,在这些部门,通常更容易获得资金购买设施自建而不是服务。

另一个关于严重限制了云计算在许多情况下的适用性问题,就是数据隐私和数据托管问题。例如,大公司往往不愿意在别人的机器上存放他们私有的,通常是机密的数据。

医疗数据,这类与客户或患者唯一相关的数据,对它应该存储在哪里以及如何使用有它自己的一套法律限制。最近美国有关国家监管部门要求欧洲公司使用云平台时,加大对其数据的隐私权和法律管辖权管理。

HPC使用的工具,在这几十年来还是只限于自身的范围,没怎么用到其他领域。

虽然有若干原因导致了这个问题,还是要学习下任务规划器,如HTCondor,和如何使用它。HTCondor可以在许多不同的环境中使用。它是一个强大的分布式计算中间件,适用于小型和大型应用。

现在的任务规划器提供了大量的功能,它们在容错、工作流管理和数据移动规划等领域尤其强大。它们都支持运行任何可执行文件,这意味着它们可以轻易的规划和运行Python代码。

让人感兴趣的可能是用云平台虚拟机动态扩展HPC系统。有些任务规划器自身支持使用适配器,如Eucalyptus。

高级HPC用户可能希望将其应用指定运行在机群的某些机器上。事实上,事实上,HPC系统中的网络结构是按层次结构组织的:高速网络连接同一级上的节点。下一个性能层连接同一个机柜中或一组机柜。InfiniBand等级连接剩下的机柜租,最后,较慢的以太网连接机群,彼此连接和连接外部。

结果是,应用程序需要大量的进程间通信和/或数据迁移,使用较少数量的位于同一级的处理器,而不是多个等级的处理器,就可以使性能大幅提高。类似的方法也适用于所使用的网络文件系统,以及是否为元文件的大量操作付出性能的代价。

当然这些优化,缺点是它们是不可移植的,这是由于HPC系统的声明周期只有几年,因此需要尽量使用最高性能的代码(这是HPC集群存在的理由)。

调试和监控

第7章中介绍少的日志、监控、分析和吊事分布式系统,即使放在现在,也是困难的工作,尤其是使用的语言不是C、C++或Fortran。这里没有什么要说的了,除了有一个重要的空白要填补。

多数的中大型团队使用日志聚合器如Sentry (https://getsentry.com),和监控方案如Ganglia (http://ganglia.sourceforge.net)。

对于Python应用,可以使用IO监控工具,如Darshan (http://www.mcs.anl.gov/research/projects/darshan/),和分布式分析工具MAP (http://www.allinea.com/products/map)。

继续学习

正如我们所看到的,用Python中构建小型、中型分布式应用并不是特别困难。一旦分布式系统发展到更大的规模,所需的设计和开发工作量也将以超线性方式增长。

在这种情况下,就需要更牢固的分布式系统理论。在线和离线都有许多可用的资源。许多大学都开设有关这个课程,其中一些是在线免费的。

一个例子就是ETH的《分布式计算原理》(http://dcg.ethz.ch/lectures/podc_allstars/index.html),它包含了一些基本原理,包括同步、一致性和最终一致性(包括著名的CAP定理)。

最后要说,初学者应该感到鼓舞。用几行代码的一个简单框架,如Python-RQ,就可以让代码性能大幅提升!


本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏企鹅号快讯

C语言真的太强大了,C几乎无处不在!

今天存在的许多C项目都是在几十年前开始的。 UNIX操作系统的开发始于1969年,其代码在1972年被重写为C语言。C语言实际上是为了将UNIX内核代码从汇编语...

5167
来自专栏后端技术探索

Uber工程技术栈(二):看曾经的独角兽背后用了哪些技术

我们的服务彼此交互,还与移动设备进行交互,而那些交互对业务状况(比如动态定价)和内部使用(比如调试)来说都很重要。就日志而言,我们使用了多个Kafka集群,数据...

954
来自专栏phodal

如何看待 GitHub 上许多笔记、面经等获得过多的 star?

文章来源于,我在知乎相关话题上的回答。问题大意是:SQLite 和 SQLAlchemy 项目的 Star 比许多学习笔记、面经还要少。

1071
来自专栏along的开发之旅

互联网后台的奥秘 - 腾讯一大牛的分享

作者举了一个异步的例子, 是关于获取时间的. 获取时间涉及到内核调用, 内核调用涉及到用户态和内核态的上下文切换, 会比较耗时. 但是在程序中很多地方都需要获得...

1242
来自专栏开源项目

GVP 特辑!PHP 老司机力荐的 6 款实战项目 | 码云周刊第 40 期

GVP 特辑 有数据显示,全球前100万的站点中,有超过70%的站点是使用 PHP 开发的。面对如此流行的编程语言,我们如何才能更有效率的学习?今天小编特意...

5205
来自专栏互联网数据官iCDO

【基础知识】现在很火的app上的deeplink技术,到底是什么?

主编前言: Deeplink,简单讲,就是你在手机上点击一个链接之后,可以直接链接到app内部的某个页面,而不是app正常打开时显示的首页。不似web,一个链接...

3.1K7
来自专栏廖念波的专栏

谈谈 KV 存储集群的设计要点

不同于无数据的逻辑层框架,KV 存储系统的架构设计会更复杂、运维工作更繁琐、运营过程中可能出现的状况更多、bug 收敛时间会更长。一句话:团队自己做一个 KV ...

2.2K0
来自专栏FreeBuf

选个“靶子”练练手:15个漏洞测试网站带你飞

俗话说进攻是最好的防御,而这与信息安全世界并没有什么不同。通过这15个故意存漏洞网站来提升你的黑客技能,你会成为最好的防守者——无论你是一名开发人员、安全管理者...

3687
来自专栏java学习

为什么一定要前后端分离?

原文: http://www.cnblogs.com/rjzheng/p/9185502.html

1721
来自专栏FreeBuf

APP漏洞自动化扫描专业评测报告(上篇)

*本文原创作者:Sunnieli,本文属FreeBuf原创奖励计划,未经许可禁止转载 一、前言 随着Android操作系统的快速发展,运行于Android之上的...

4286

扫码关注云+社区

领取腾讯云代金券