前一篇有提到，MapReduce 是 Google 所提出來的一個 software framework，只要把握它的原則，實作它並不會很困難。我們來看看 Google 和 Hadoop 三大碁石的對應表:

雖然目前會先以 open-source 的 Hadoop MapReduce 為主，但是我們可以看的到這兩個都是用 Distributed file system 來作資料的交換，也有自己的 MapReduce 的方法，所以概念上相去不遠。

在開始講之前，有件事應該要先提一下，因為 Hadoop 是以 Java 開發的，所以不熟的人可能會很排斥，老實說我也如此。但是 Hadoop 有提供一些方法讓開發者可以用其它的語言來寫 MapReduce。

我想 Java 的使用者不管是 Hadoop 的說明文件，還是範例程式應該都不是甚麼問題，因此我主要會以 C 以及 Python 為主，然後盡量也會帶點 Ruby 和 Perl。

我們先來看看 Hadoop MapReduce 的 work flow:

這張 work flow 我們往後也會一直看到。如同前一篇提到的，MapReduce 有四個很重要的步驟。我們來看看 Hadoop 在這四個階段作了甚麼事情。

1) Input
將要處理的資料上傳到分散式檔案系統中。預設的格式是文字檔 (我們也不會用其它的檔案格式)，而分散式檔案系統以 HDFS 當範例。

完成上傳到分散式檔案系統之後，所有的資料都可以被每一個 node 去存取。而每一個檔案，會以行當單位，自動被分割成固定大小的 Block，分散在各個 node 之中，然而這件事對我們而言是 transparent 的。(不過這裡特別提的原因是這有可能會影響到 Map 的數目，所以有個印象即可。)

以 Block 大小是 64MB 當例子，假設原始檔案是 200MB，那第一個 Block 是從頭算起的第 64 MB，再往後找到第一個換行 (\n) 為止。這樣作是為了方便 Map 不用處理這種 boundary case。同樣的，第二個 Block 就是該換行的下一個 byte，取 64MB 再找換行，如此不斷的反覆直到檔案結尾。換句話說，最後一個 Block 的大小會隨機變動，也和下一個檔案無關。

2) Map
雖然 Map 的數目是可以設定的，但是預設每個 Block 理論上都會被一個 Map 處理。那 Map 的邏輯就是讀 stdin，以行為單位處理之後，印成 key-value pair 到 stdout。就像是 unix 上的 pipeline一樣。key 跟 value 預設是以 tab (\t) 當分割。(精確的說，是以第一個 tab 當中介，往前是 key，往後是 value，這也是可以設定的。)

因為 Map 的程式是我們可以動手的，所以我們可以記得 Map 就是把一行的文字，轉換成一個 key-value pair 的邏輯。

3) Shuffle/Sort
為甚麼是 key-value pair 呢? 那是因為相同的 key 會送到同一個 reduce，而每個 reduce 會產生自己獨立的 output file。如果 map 的結果是隨機送往 reduce，那這個的 work flow 便會有其限制了。這就是第三個階段 Shuffle/Sort 的工作。

舉個例子，假設我們是要將 input file 的每個單字出現的次數。其中一行是 “one for all; all for one”，我們的 map 程式就是把每一個單字，都作成一個 key-value pair 往後送。Key 當然是單字本身，那 value 就是 1，代表 count 是 1。因此，上例會產生六個 key-value pair: (one,1), (for,1), (all,1), (all,1), (for,1), (one,1)。如果是隨機送往 reduce，那有可能 reduce1 收到前三個，reduce2 收到後三個，加上彼此的 reduce 不會互相參照，所以這結果並不是我們要的。(因為 for 這個字有些在 reduce1 的 output file，有些在 reduce2 的 output file，那還要特別寫程式作加總才是我們要的結果。當然如果 reduce 只有一個就沒有這樣的問題。)

那相同的 key 會送到同一個 reduce 的 case 會發生甚麼事? 我們可以保證同一個單字不會送到不同的 reduce，所以某個 reduce 的 output file 的任一單字的數目，一定代表原始所有檔案中，該單字的出現的次數。

那 sort 在做甚麼? 在上例我們看不出來關聯性，但是如果我們要的不單是單字出現的次數，還要排序，那就會有差別了。

一樣用 “one for all; all for one” 當例子。如果碰巧二個 reduce 收到的是:

1) Reduce1: (one, 1), (for, 1), (for, 1), (one, 1)
2) Reduce2: (all, 1), (all, 1)

PS: 斜體代表是 all for one。

那每個 reduce 程式還要先讀完全部的 stdin 才能加以 sort，這樣就沒有效率了。反過來說，如果先把資料 sort 好再給 reduce 程式，reduce 就可以 streaming 的方式運作，寫法也比較簡單。

4) Reduce
Reduce 的邏輯和 Map 相似。它是把 key-value pair，轉換成我們要的結果。也是拿上面的例子，經過 Shuffle/Sort 之後，Reduce 會收到:

1) Reduce1: (one, 1), (one, 1), (for, 1), (for, 1)
2) Reduce2: (all, 1), (all, 1)

PS: 斜體代表是 all for one。注意，第二個 one 跑到 for 之前了。

所以我們 reduce 的作的事情是: “在遇到下一個單字前，累加 value，如果遇到新的單字，就印出這個單字和總量到 stdout。” 所以我們的結果是

1) Output1: (one, 2) 和 (for, 2) 共兩行
2) Output2: (all, 2) 一行

這就是我們的結果。

這篇文章雖然長，但是瞭解之後可以大概的知道 Hadoop 整個 work flow。下一篇我們就要動手試我們的程式了。

這句話的意思是，當我們的兵力大過敵人兵力十倍，就用包圍攻擊來殲滅對方。反過來說，當對方的兵力大過我們，就想辦法分開他們而各自擊破。雖然我的翻譯不是很好，但是老祖宗的智慧，就是 computer science 中，一個非常著名的演算法 divide and conquer。

我們會用到雲端運算，要處理的資料一定是非比尋常的大，大多數的這類的分散式演算法本質上都和 divide and conquer 接近。我們這邊要介紹的 framework，就是 Google 所提的 MapReduce。

以下的圖，就是一個簡化過的 MapReduce 的 work flow。一般來說，它分成四個階段:

1) Input

雖然原始的資料量太大，但是我們有很多個 node 可以來運算。所以將原始的資料切成若干等份的 block，並往下一個階段送。

2) Map

對傳過來的 block 中的每一個元素，進行 Map function 的運算成為中繼資料。然後將中繼資料往下一個階段送。

3) Reduce

對傳過來的中繼資料，以及前一個 reduce 的結果，進行 Reduce function 的運算。然後將運算結果往下一個階段送。Reduce 和 Map 不同，它有兩個 input。

4) Output

將運算結果寫進檔案系統，完成運算。

這個 design pattern 就是這麼簡單，不知不覺得用上 MapReduce。當然，Map 和 Reduce 的數目，與可以運算的 Node，都是影響效能的關鍵，這個我們容後再講。目前我們所要知道的，就是如何把問題轉化成 MapReduce 的解法，一旦可以套用，那問題幾乎是解了一半了，剩下的就是動手 coding 而己。

我再舉另一些例子。如何從某個電子書中找到最常用到的單字? 這個問題是不是有點像在用 google search 時，出現的關鍵字自動補齊功能 (search autocomplete) 呢? 只是問題簡化過而己。我們來看看這個問題怎麼用 MapReduce。

1) Input

電子書以章為單位，分別送給每一個 Map。

2) Map

Map 找出該章裡所有的單字，接著送給 Reduce。

3) Reduce

Reduce 對上一個 Reduce 排序好的結果，加上對應的 Map 送過來的單字，兩者再排序之後送給下一個 Reduce。

4) Output

最後一個 Reduce 處理完之後，就是最終的單字排序名單。

大家可以多想一些例子來練習這樣的 work flow。

雖然概念上是這樣，但是實際上的作法大家都略有差異。下一篇就是針對 Hadoop 的 MapReduce 來作說明。

子曰：「工欲善其事,必先利其器。」

當然，比賽最好先熟一下工具會比較有信心。我第一個要先介紹的 framework 就是 Hadoop (Wikipedia: Hadoop)。

因為 Hadoop 算是一個非常知名的雲端運算平台，加上 Wikipedia 寫的也非常的仔細，所以我這邊就不贅述了。但是因為它的設定不太容易而且費時，加上這部份對於簡單的程式來說，並沒有太大的影響。所以我推薦在開發階段，可以先用 Hadoop Virtual Image 就可以了。

Hadoop Virtual Image 是一個 Ubuntu Linux 7.04 的 OS, 然後內建了 Java machine (Sun JRE 6 u2) 以及 Hadoop 0.13.0 的一個 virtual machine image。我們可以用免費的 VMware Player 來執行它。

雖然它沒有 GUI，但是最令人感到興奮的是，它預設已經把 Hadoop 的環境設定好成 pseudo-distributed mode (也就是在同一台電腦上用不同的 port 當作不同的機器，然後在利用 ssh 去跟這些假機器作溝通)。雖然預設只有一個機器，不過目前應該無傷大雅。

以下就是用 VMware Player 執行這個 virtual machine image 的樣子。

然後用 guest 登入:

因為這個 guest OS 已經裝了 Hadoop, 所以我們可以執行它裡面的範例程式來簡單的跑一下。指令如下:

這個範例就是在 Hadoop 的平台上, 用蒙地卡羅法 (Monte Carlo Method) 來分散計算 Pi 的值。換句話說，這就是最簡單的雲端運算 (因為只有一個機器)。

下面是跑完的結果:

有看到上面的正常結果，代表我們的環境是正常的，可以開始作一些程式開發了。為了更了解雲端運算，它的 working flow 是一定要先知道。下一篇就是要來講 Google 所提出來的 MapReduce framework。

Finally, we can now use the Python standard libraries urllib, urllib2 or httplib to make HTTP requests.

“咦? 你們之前寫某個 Server 的時候, 怎麼讓程式自己產生 Core dump 啊?”

“那幫我看一下為啥我照著那樣寫不會動..”

沒想到就開始了殘酷的惡夢~ 讓我們花費了不少工夫才發現為甚麼.

在 Linux 上, 預設是不會有 Core dump 的, 而要讓程式產生 Core dump 的方法就是利用 bash built-in 的 ulimit 指令. 我去年這篇 How to enlarge Coredump Size and File Descriptor Limitations 剛好也有寫到.

不過意外常常有, 所以除了讓 System administrator 設 ulimit -c unlimited 之外, 我自己也會在程式裡面利用 setrlimit(2) 這隻 system call, 讓程式在執行時, 能夠不管 administrator 有沒有用 ulimit 設定 Core dump size, 保證一定會產生 Core dump. 在程式 crash 的時候, Core dump 是很重要線索啊! 就像 CSI 一樣, 讓證據會說話.

可是在看完 Samuel 的程式時, 我和他兩個就覺得很奇怪, 應該是會 work 才對, 因為同樣的 code 寫的程式已經在 production server 上跑了一段時間, 應該不會有問題才對, 這時候, 我才猛然想起來, 管機器的 administrator 曾說過有時候 Core dump 不會出現. “God! 該不會就是同一個問題吧?”

和 Samuel 兩個人找完資料的答案, 就是寫這篇文章的動機了. 我們發現, 如果一個程式按照上面的方法都無法產生 Core dump, 那要看看這個程式是否是用了 setuid(2) 這個 System call. 我們發現, 一個 setuid(2) 或 seteuid(2) 過後的程式, 是沒有辦法產生 Core dump 的.

好巧不巧, 通常 Server 為了一些安全性的考量, 也會實作 setuid(2) 或 seteuid(2) 來達到 Running with Least Privilege (相對應 Windows 的指令就是 Run As). 也就是說, setuid(2) 一定是不能略過的. 解決方法有兩種.

第一種是只有這個程式有效. 用的方法就是 prctl(2). 這個方法是可以改 source, 然後 rebuild 的狀況下才能用. Sample code 如下:

這種方法要注意的事情有:

• 一定要用 root 執行.
  setuid 然後讓一般 user 去執行的方法不行.
  (e.g. sudo chown root a.out; sudo chgrp root a.out; sudo chmod 4755 a.out)
• 因為 Core dump 產生的目錄和執行檔在同一個目錄下, 這個目錄的權限一定要是 root 這個 user, root 這個 group 同時都可以寫入才行. 要注意這個 case, 不要把 root 當成是 super-user, 而是要當作 regular user.
  比方說, (drwxrwxr-x, root root) 和 (drwxrwxrwx, nobody nogroup) 可以, 但是 (drwxr-xr-x root root) 和 (drwxrwxr-x root nogroup) 都不行. 很弔詭吧! 我也不知道為甚麼~

第二種方法是 system-wide 的, 也就是會影響到所有在系統執行的程式. 方法就是 /proc/sys/fs/suid_dumpable. 因為這個和 kernel 的版本有關, 請 man 5 proc 比較保險. 這是在無法動 source code, 而且原程式沒有用 prctl(2) 情況下的殺手鐧.

要注意的事情和第一種方法一樣, 把 /proc/sys/fs/suid_dumpable 設成 1 或 2 的差別, 是會決定 core dump file 的擁有者. 如果設成 1, 就會和第一種方法一樣是被 switch 的 owner (本例是 nobody). 如果設 2 就一定是 root, 但是這個似乎要 kernel 2.6.13 以上才有 support? 我不是很確定.

希望這篇文章給大家當作個參考囉!

PS: 這篇竟然寫了快二個周末, 真是夠久的~

Yes, it’s very obvious that the first parameter is the socket fd. But, what’s the meaning of backlog number? Some body would tell us like manpage LISTEN(2) says: “The backlog parameter defines the maximum length the queue of pending connections may grow to. If a connection request arrives with the queue full the client may receive an error with an indication of ECONNREFUSED or, if the underlying protocol supports retransmission, the request may be ignored so that retries succeed.”

From a robust server’s perspective, what’s the maximum value it should be assign? At first, I assigned very large number like 1,024 (of course, listen system call still returns successfully). After saw the manpage LISTEN(2) in Linux, I was wrong..

It doesn’t mention kernel 2.6. But it’s fine. Let’s investigate into Linux kernel source code.

In Linux kernel 2.6.20.1, we can see the listen system call implementation in net/socket.c line 1306. As it shows, the maximum number of backlog cannot be large than sysctl_somaxconn, which is assigned to SOMAXCONN. Furthermore, SOMAXCONN is defined 128 in include/linux/socket.h line 226.

In my opinion, in Linux 2.0 to 2.6, this means backlog cannot exceed 128 by default, or it would be truncated to SOMAXCONN silently like the manpage says.

How about FreeBSD? We can see the note of manpage LISTEN(2) in FreeBSD 6:

I’m not very familiar with FreeBSD kernel, but let me try to trace. The start point is to check sys/kern/uipc_syscalls.c of cvstag RELENG_6 in FreeBSD. We can see listen system call will invoke solisten(so, uap->backlog, td). Thus, we go to sys/kern/uipc_socket.c now to see the implementation of solisten(struct socket *so, int backlog, struct thread *td). The same, the maximum value is somaxconn which is assigned to SOMAXCONN by default. Finally, we can see the value is defined in sys/sys/socket.h. The value is the same as Linux — 128.

To put it another way, if you’re writing a server program in either Linux or FreeBSD platform, it’s very appropriate to assign the value of backlog to 128. in FreeBSD, however, you can assign a negative backlog to request the maximum allowable value.

You may ask what’s the value of backlog in popular modern server? Let’s check the source of Apache HTTP Server. As you see in /server/listen.c, ap_listenbacklog is assigned to DEFAULT_LISTENBACKLOG which is defined 511 in /include/mpm_common.h.

Q:

I would like to allow the transferring of data between ISR’s, kernel and user code, without requiring copying.

I envision allocating buffers in the kernel and then mapping them so that they appear at the same addresses to all code, and never being swapped out of memory.

Is this feasible for all supported Linux architectures and is there existing code that someone could point me towards?

A:

Your better off having application mmap a device, then transfer the data to there. Something like AF_PACKET.

Used judiciously, asynchronous I/O (short for AIO) can provide a significant speed benefit, says David Chisnall. Perhaps enough to help your program overcome the fact that modern processors can really zoom, while hard drives still drag.

Code using AIO on Linux must be linked with -lrt to provide support for the POSIX real-time extensions, which means it may not be the kernel I/O mechanism, especially Kernel AIO Support for Linux has not been merged into mainline kernel yet.

After studying rt extensions in glibc source, I find how do they implement posix AIO in glibc — a thread pool plus a request waiting queue. Besides, helper thread will be spawned to manage the request, hence it’s not so trivial.

There is something interesting when freeing allocated resources. You can see the function libc_freeres_fn() in aio_misc.c. This is also why it is unnecessary to implement “destroy” API.

Whereas, FreeBSD has AIO family system calls. I, however, have no experience with AIO in FreeBSD, but it seems AIO in FreeBSD has kernel support? If so, it would be more efficient than Linux until now?

Besides, here is a tutorial from MSDN on how Microsoft makes their Windows XP icons.