从工具使用的痛苦说开去

painful

是因为最近团队里的数据分析师(data analyst)向我抱怨,为了分析数据,要跑 job,要执行 pipeline,要用 Spark 来算结果,但是期间遇到各种问题,虽然我们一起研究问题的解决方法,但是依然非常耗时而且令人沮丧。这些问题大多并非数据本身的问题,而是工程问题。换言之,我认为数据分析师的价值在于数据思维,他们有我们软件工程师不具备的数据敏感性,他们能从海量的数据中获得有价值的信息——但是如今他们却陷入了因为工具问题而导致才华无法施展的境地,确实令人叹息。而工具的问题,正是应该由软件工程师来解决的。

上班同车的同事 Kai 和我说,现在和几年前不同的是,“全民 dev 化”了。除了上面说的数据

[……]阅读全文

Spark 性能优化——和 shuffle 搏斗

Spark

Spark 的性能分析和调优很有意思,今天再写一篇。主要话题是 shuffle,当然也牵涉一些其他代码上的小把戏。

以前写过一篇文章,比较了 几种不同场景的性能优化 ,包括 portal 的性能优化,web service 的性能优化,还有 Spark job 的性能优化。Spark 的性能优化有一些特殊的地方,比如实时性一般不在考虑范围之内,通常我们用 Spark 来处理的数据,都是要求异步得到结果的数据;再比如数据量一般都很大,要不然也没有必要在集群上操纵这么一个大家伙,等等。事实上,我们都知道没有银弹,但是每一种性能优化场景都有一些特定的“大 boss”,通常抓住和解决大 boss 以后,能解决其中一大部分问题。比

[……]阅读全文

从淘汰 Oracle 数据库的事情说起

tech

公司搞淘汰 Oracle 数据库的事情已经搞了好久了,这个事情其实和国内淘宝系搞的去 IOE(IBM、Oracle 和 EMC)是类似的,基本上也是迫不得已,Oracle 的维护成本太高,而公司内部基于 Oracle 数据库的数据仓库,也是问题频出;另一个原因则是 scalability。我相信这两个原因许多人都非常清楚。而这个淘汰,也不是简简单单换一个关系数据库,比如把 Oracle 换成 MySQL,或者换到云上(RDS)。而是有明确阶段性地演进,比如替换到 DynamoDB 这样的 NoSQL 数据库上面去;或者更彻底地,像我们接触到的某个产品,数据本身换到更廉价的存储 S3 上去,元数据才存在 DynamoDB 里,而原本

[……]阅读全文

三次性能优化经历

performance

最近在做一些性能优化工作,回想起工作这些年来,参与过的三次集中性能优化,每次都得折腾少则一个月,多则半年。这些内容既是不同视角、不同思路的比较,也是挺有趣的工作经历。

Portal 的性能优化

这已经是大概五年前了,搞了接近半年的 Portal 性能优化,后来某些内容总结在 这篇文章里面 。既然是 Portal,性能优化上就有它的特点。比如说:

Portal 的性能优化需要从前端和后端两个角度去思考问题,先考虑客户端和服务端之间的交互模型,然后再在客户端和服务端单独考虑分而治之。这个其实和设计的思路是一样的,交互问题需要首先考虑,定义好交互的报文形式(比如某 JSON 的具体形式)以后,包括用户触发什么行为引

[……]阅读全文

Spark 的性能调优

Spark

下面这些关于 Spark 的性能调优项,有的是来自官方的,有的是来自别的的工程师,有的则是我自己总结的。

基本概念和原则

首先,要搞清楚 Spark 的几个基本概念和原则,否则系统的性能调优无从谈起:

  • 每一台 host 上面可以并行 N 个 worker,每一个 worker 下面可以并行 M 个 executor,task 们会被分配到 executor 上面去执行。Stage 指的是一组并行运行的 task,stage 内部是不能出现 shuffle 的,因为 shuffle 的就像篱笆一样阻止了并行 task 的运行,遇到 shuffle 就意味着到了 stage 的边界。
  • CPU 的 core 数量,每个 executor 可以占用一个或多个 core

[……]阅读全文

back to top