分布式系统中唯一 ID 的生成

其实老早就像写一点这个话题。几乎我见过的所有大型系统中,都需要一个唯一 ID 的生成逻辑。别看小小的 ID,需求和场景还挺多:

  • 这个 ID 多数为数字,但有时候是数字字母的组合;
  • 可能随机,也可能要求随时间严格递增;
  • 有时 ID 的长度和组成并不重要,有时候却要求它严格遵循规则,或者考虑可读性而要求长度越短越好;
  • 某些系统要求 ID 可以预期,某些系统却要求 ID 随机性强,无法猜测(例如避免爬虫等等原因)。

独立的生成服务

比如数据库。最常见的一种,也是应用最多的一种,就是利用数据库的自增长序列。比如 Oracle 中的 sequence 的 nextVal。有多台 application 的 h[……] 阅读全文

Spark 性能优化——和 shuffle 搏斗

Spark

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

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

[……]阅读全文

Spark 的性能调优

Spark

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

基本概念和原则

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

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

[……]阅读全文

Hadoop 的 Map-side join 和 Reduce-side join

hadoop join

Hadoop 中连接(join)操作很常见,Hadoop“连接”的概念本身,和 SQL 的“连接”是一致的。SQL 的连接,在 维基百科 中已经说得非常清楚。比如 dataset A 是关于用户个人信息的,key 是用户 id,value 是用户姓名等等个人信息;dataset B 是关于用户交易记录的,key 是用户 id,value 是用户的交易历史等信息。我们当然可以对这两者以共同键用户 id 为基准来连接两边的数据。

首先,在一切开始之前,先确定真的需要使用 Hadoop 的连接操作吗?

如果要把两个数据集合放到一起操作,Hadoop 还提供了 Side Data Distribution(data sharing)的方式,

[……]阅读全文

Hadoop 的 Secondary Sorting

map-reduce 这几天项目中使用 Hadoop 遇到一个问题,对于这样 key-value 的数据集合:id-biz object,对 id 进行 partition(比如根据某特定的 hash 算法 P),分为 a 份;使用数量为 b 的 reducer,在 reducer 里面要使用第三方组件进行批量上传;上传成文件,文件数量为 c,但是有两个要求:

  • 上述 a、b、c 都相等,从而使得每个 partition 的数据最终都通过同一个 reducer 上传到同一个文件中去;
  • 每个 reducer 中上传的数据要求 id 必须有序。

最开始,想到的办法是,为了保证 reducer 中的批量上传,需要使得传入 reducer 的 key 变成一个经过 hash 算法 A 计算得到的

[……]阅读全文

Dynamo 的实现技术和去中心化

Amazon Dynamo 是分布式的 key-value 系统,最近阅读了 Dynamo 最初的论文 《Dynamo: Amazon's Highly Available Key-value Store》,本文想聊一聊它的去中心化(decentralization)。既有阅读相关材料后对其实现的理解,也有自己的思考,其中如有不正确言论欢迎指出。

中心节点

通常,我们见到的分布式存储结构都是具备中心(总控)节点的,比如 Google File System(GFS),包括了中心的 Master 和数据节点 Chunck Server;再比如 HDFS,包括了中心的 Name Node 和数据节点 Data

[……]阅读全文

Hadoop 无法解决的问题

因为项目的需要,学习使用了 Hadoop,和所有过热的技术一样,“大数据”、“海量”这类词语在互联网上满天乱飞。Hadoop 是一个非常优秀的分布式编程框架,设计精巧而且目前没有同级别同重量的替代品。另外也接触到一个内部使用的框架,对于 Hadoop 做了封装和定制,使得更满足业务需求。我最近也想写一些 Hadoop 的学习和使用心得,但是看到网上那么泛滥的文章,我觉得再写点笔记一样的东西实在是没有价值。倒不如在漫天颂歌的时候冷静下来看看,有哪些不适合 Hadoop 解决的难题呢?

Hadoop

这张图就是 Hadoop 的架构图,Map 和 Reduce 是两个最基本的处理阶段,之前有输入数据格式定义和数据分片,之后有输出数据格

[……]阅读全文

Notes: Hadoop-based open source projects

Here's my notes about introduction and some hints for Hadoop-based open source projects. Hope it's useful to you.

Management Tool

Ambari: A web-based tool for provisioning, managing, and monitoring Apache Hadoop clusters which includes support for Hadoop HDFS, Hadoop MapReduce, Hive, HCata

[……]阅读全文

关于“ 无状态”,从 Amazon 的工作流框架中获得的思考

这个话题是从我对 Amazon 云平台的工作流框架 AWS Flow Framework 的使用研究中想到的,对于一个工作流引擎来说,一个完整工作流的某个阶段完成后,当前阶段的状态必须要被存储下来。

 

1

 

Workflow(Decider) 来决定任务的执行流程,Activity 来执行实际的任务,二者都封装在相应的 Worker 中执行,但不直接交互,而是通过 SWF 管理起来。不过,除了 SWF 的日志,它们都不记录任何当前任务执行状态的信息 ,即所有的任务执行情况只能从 SWF 的日志中找到。譬如一个 Workflow 由 Activity1 和 Activity2 组成,在执行完 Activity

[……]阅读全文

关于“ 异步”,从 Amazon 的工作流框架中获得的思考

云平台的工作流框架 AWS Flow Framework 给我带来的另一个有所感触的话题是“ 异步”:

1

这个框架把异步的行为划分为 Workflow 端执行的部分和 Activity 端执行的部分,Workflow 控制工作流程,Activity 执行具体的工作流 task,二者都以 poll 的模式不断从中心 SWF 去获取任务。对于开发者来说,用类似这样简单的代码,就完成了整个工作流任务的部署,框架为开发人员隐藏了大部分实现细节:

@Workflow  
public interface CalculateWorkflow  
{  
    @Execute  
    pu

[……]阅读全文

back to top