[Ingress] High Density of Dropped Resonators Forced colse Attack/Defense

Source:technologybanker

Two weeks ago we builded a L8 x 14 portal farm in Taiwan, and had a great Harvest.

This week, even more we build a L8 x 16 portal in same place. But we all hit the limit of resources we can carry. So many of our friends start to drop some low level resonators , such as L5,L6. I guest there are more than 1k resonators over there. Then the tragedy happend....

Everyone's ingress forced to be closed. The apps crash!! Even people who use portal key want to remote charge portal got the same result. I look into the stack trace see IllegalArgumentException:Vertex count large than usable with GL_SIGNED_SHOT

PS. Vertex count is the array divided by the size of the vertex ex. (x,y) or (x,y,z)

So We cannot hack those portal , neither the resistance can attack our portal.

We call this action as High Density of Dropped Resonators Forced colse Attack/Defense (something like Ddos...XD )

ApacheCon2013 - Continuous Delivery with Maven, Puppet and Tomcat

Source：Carlos Sanchez - Continuous Delivery with Maven, Puppet and Tomcat

參加ApacheCon2013的筆記持續整理消化中....Orz..

話說在DevOps 的概念裡面本來就有包含QA的概念，不過很多時候卻被人誤解成，不需要QA或者是QA不重要，因此講者就在投影片引用一句話：

To make error is human. To propagate error to all server in automatic way is  Devops

所以越是自動化的部屬，就越需要QA的參與，所以講者就特別把QA獨立出來強調，因此才有DevQaOps的詞..XD 其實目的都是為了能達到Agile - Continuous Delivery 的境界。

雖然之前我有整理過一篇文章關於DevOps的工具與技術 -  Continuous delivery - tools and techniques ，但是對於這塊的著墨還是略嫌不足，而這次參加這個Session

這篇文章列出一堆幫助DevOps的工具與技術，而這個Session 雖然題目是寫Maven + Puppet + Tomcat 的組合，但是裡面主要介紹必較新奇的技術卻是 "Puppet + vagrant" 的組合，透過Puppet + vagrant 的組合能快速的建立vm環境和開發環境，加速複製和重建的時間，然後也可以利用puppet 控制maven 的安裝與控制，詳細的範例可以參考講者放在Github上的範例專案：

• Continuous Delivery with Maven, Puppet and Tomcat
• https://github.com/carlossg/continuous-delivery
• puppet + vagrant + maven 的組合
• https://github.com/maestrodev/puppet-maven

延伸閱讀：

• From Dev to DevOps with Maven and Puppet
• Provisioning Maven artifacts with Puppet

投影片：

Continuous Delivery with Maven, Puppet and Tomcat - ApacheCon NA 2013 from Carlos Sanchez

後記：

因為筆者都在介紹Puppet我就好奇，那Chef呢？因為這也是常見常聽到的技術，所以我就順便Google了 Chef 與 Puppet之間的差異。

• Chef vs Puppet – my take on the holy war
• Puppet or Chef?
• What is the difference between Chef and Puppet in configuration management software?
• Puppet versus Chef: 10 reasons why Puppet wins

簡單來說就是Chef 是新公司做出來的產品，有著跟Puppet相同的目標但是不同的技術，所以Puppet陣營的說法就是Chef沒有經過大型系統Deploy 的驗證與知名公司的背書 (不過最近Facebook採用了~:P)

所以同樣的也有Chef 跟Maven 整合的專案和套件：

• https://github.com/opscode-cookbooks/maven
• https://github.com/bryanwb/chef-maven-bin#readme

觀察各公司在Hadoop Ecosystem 的committer 與PMC 數量

圖片來源：Datameer 2013

相信這張圖大家應該都看過，是關於Hadoop Ecosystem technology partnerships之間的關係，第一名的是Cloudera。

剛好今天收到一封信說Hortonwork在Hadoop 專案的數量遠遠超過Cloudera，我就在想這樣看不準啊，因為cloudera在其他專案也有投入許多人力啊！？於是就燃起我一定要察個水落石出的念頭！！(工程師魂~~~~~)

剛好這也算是由另一個角度來分析，藉由觀察各公司在Hadoop Ecosystem (個專案) 的Commiter 與PMC 數量，來看個公司的主力方向以及參與程度。

整理的方法，就是收集Hadoop ecosystem 比較主要專案的PMC 與 committer 名單，雖然發現有幾個committer有跨專案，不過這邊最主要是要比較每間公司佔各專案的人數，所以就先不管混在一起計算(其實是偷懶....)，另外我也只計算幾個人數比較多的大公司，其他小公司或獨立開發者就沒特別列出來。

Ambari	Hortonworks	18
	IBM	2
Avro	Cloudera	4
Pig	Hortonworks	5
	Cloudera	1
	IBM	1
	Twitter	3
	Yahoo	3
Hive	Facebook	6
	Hoetonwork	1
Sqoop	Cloudera	9
Mahout	LinkedIn	2
HCatalog	Facebook	1
	Hortonworks	6
	Twitter	1
	Yahoo	2
Oozie	Cloudera	3
	Hortonworks	2
	Yahoo	3
	MS	2
Flume	Cloudera	12
BigTop	Cloudera	8
	Facebook	2
	Hortonworks	3
ZooKeeper	Cloudera	4
	Hortonworks	2
	Yahoo	6
Hbase	Cloudera	9
	Facebook	5
	Hortonworks	4
Hadoop PMC	Cloudera	7
	Facebook	3 + 2
	Hortonworks	13+ 4
	Yahoo	3 +7
	IBM	0+ 3

--------------------------------------
所以最後統計結果如下，果然還是Hortonwork 大勝！！

Hortonworks	61
Cloudera	48
Yahoo	27
Facebook	17
IBM	6
Twitter	9
LinkedIn	4

報告完畢~~我真無聊....XD

Spring Data - How to configure hbase

接續上一篇 "Spring Data - Hadoop and MapReduce "，本篇要補齊的就是關於Hbase的設定部分，因為我覺得書上講的不是很清楚(或者應該說對於spring 不夠熟悉的人，會覺得不容易了解)。

開發環境：

• Eclipse JunoSR2
• Lib 
• Spring Data 1.0.0.RELEASE
• Spring 3.2.1.RELEASE
• Hadoop 1.1.1
• Hbase 0.94.2
• Hadoop Platform (single node - pseudo-distributed mode)
• Hortonworks sandbox

話說Hortonworks sandbox 是一包裝再VM裡面的Hadoop大集合，很適合用來開發測試程式，這樣一來我只要帶著Notebook到哪裡都可以開發和做實驗了，安裝好以後web畫面如下：

圖片來源：螢幕截圖

首先我們先來看，關於Hbase Spring 設定檔的部份

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:context="http://www.springframework.org/schema/context" xmlns:hdp="http://www.springframework.org/schema/hadoop"
xmlns:p="http://www.springframework.org/schema/p"
xsi:schemaLocation="http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context.xsd
http://www.springframework.org/schema/hadoop
http://www.springframework.org/schema/hadoop/spring-hadoop.xsd">


<!-- 把所有classpath 內的 .properity 都讀進來 -->
<context:property-placeholder location="classpath*:*.properties">

<!-- Spring data for hadoop 的設定 -->
<hdp:configuration>
<!-- hdfs url設定 -->
    fs.default.name=${hd.fs}
<!-- authorization 設定 -->
    hadoop.security.authorization=true
</hdp:configuration>

<!--Spring Data Hbase 設定 -->
<hdp:hbase-configuration delete-connection="true" stop-proxy="false">
<!-- Hbase rootdir 設定 -->
    hbase.rootdir=${hbase.rootdir}
<!-- Hbase zookeeper cluster 設定 -->
    hbase.zookeeper.quorum=${hbase.zookeeper.quorum}
</hdp:hbase-configuration>


<!-- Spring Data for Hbase template -->
<bean class="org.springframework.data.hadoop.hbase.HbaseTemplate" id="hTemplate" p:configuration-ref="hbaseConfiguration">
<!-- 設定component-scan dao這個目錄 -->
<context:component-scan base-package="com.howie.hadoop.hbase.dao">
    <context:include-filter expression="org.springframework.stereotype.Repository" type="annotation"> </context:include-filter>
</context:component-scan>


hbase.properties 設定
hbase.zookeeper.quorum=sandbox
zk-port=2181
hbase.rootdir=hdfs://sandbox:8020/apps/hbase/data


當然這只是最基本讓程式可以動的設定(for single node - pseudo-distributed mode)，如果針對Real Cluster mode 就會需要更多的設定，詳情請參考 Hadoop Configuration, MapReduce, and Distributed Cache , Working with HBase。

另外在這邊補充如何使用Spring & JUnit 幫 Hbase Program做Unit Test


@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = {"classpath:META-INF/spring/hbase-spring-context.xml"})
public class UserDaoIntegrationTest {

   @Autowired
    private UserDao userDao;

    @Test
    public void testSave() {

        User user = userDao.save("test1", "test1@gmail.com", "test1..");

        System.out.println("User:" + user);
    }
}


這樣就可以很方便的幫Hbase 的程式做Unit testing了 (其實是Integration Test...)
不過至於MapReduce 的Unit Test 可能就要借助MRUnit，不過我也還在研究要怎麼跟Spring 整合...

順帶一提的就是在Run unit test 我遇到了下面這個錯誤訊息：

[info] ipc.hbaserpc problem connecting to server 60020

我原本以為是我設定錯誤，但是似乎是sandbox的Hbase掛了，連不上HMaster...
所以到底是sandbox不穩？還是我的程式沒正常斷線造成出問題？這也還得研究研究....

Scrum與Architecture是否有矛盾或衝突 (2)

Source：The Role of the Agile Architect

這篇放著好久都沒有完成...因為最近又開始規劃新系統的Architecture，而且專案的狀態似乎又有點傾向waterfull....所以開始懷念起以前實行Agile，邊設計邊開發的那段日子....

專家怎麼說?

延續很久很久以前的一篇文章"Agile(Scrum)與Architecture是否有矛盾或衝突 (1)"，我就繼續上網搜尋一堆大師對對於Agile 與 Architecture 的看法，以及一些所謂的Best practice，第一個看到的文章就是 Community Roundtable: Agility versus Architecture，我整理出這篇文章的一些重點如下：

P. Shepherd 認為：
如果High Level Architecture 沒有設計好，那你將會建立一個對於整體而言沒有長期可行性，或是價值的系統。

K. Ishkhanova 認為：
很多人不喜歡看企業等級(enterprise level)的架構，他們喜歡快速的跳到技術細節去，但是他們往往會遺失了幾個重點，如果你沒有規劃好系統能力和關鍵的訊息，整個架構將會非常脆弱與傾倒。因此對我來說敏捷(Agile)常常會等同於衝動(impulsive)。人們把Agile視為非常快，非常快的一種方法，但卻沒有深入了解，它應該是真正的敏捷和不只是衝動。

I see a conflict between Agile and Architecture!?

所以依照這個key word：Conflict between agile and architecture一搜尋，馬上就找到一堆文章在探討這個議題。

• The conflict between agile and architecture (part 1) 
• InfoQ：Agile and Architecture Conflict
• The conflict between agile and architecture – myth or reality?
• Conflict between Agile and Architecture
• Agile Architecture Revolution: a new buzz, a new dream, or a new reality?
•  The Role of the Agile Architect

有興趣的人可以點進去看那些文章(不過我想大家應該沒時間看)，所以結論是什麼？結論就是There is no conflict between agile and architecture，只是解讀角度和觀點不同。


..........所以又回歸原點....既然沒有衝突那該如何取得平衡呢？

Spring Data - Hadoop and MapReduce

O'Reilly 的 Spring Data 這本書中文翻譯本出了！速度真快，英文版都還沒看幾張就翻譯好了~＠o＠ 對於資訊焦慮又懶惰如我的人來說，這本書的架構清楚有條理，內容算是深入淺出可以很快就吸收。

話說這次會想要看這本書主要是想搞清楚Spring Data 對於在寫Hadoop的程式能有啥幫助，因為以前用過Spring Data 搭配MongoDB就覺得很方便。

這本書為了讓讀者容易了解Spring Data的好處，所以在鋪陳上有下一番功夫，首先先介紹一般MapReduce程式是如何撰寫，有什麼麻煩和不方變得地方，如果用了Spring Data 以後能有什麼改變，甚至還進一步的建議讀者搭配Spring Integration 和 Spring Batch 一起服用。

首先作者先以Hadoop 的 hello word - word count來舉例，一般Hadoop必須怎麼寫與執行，必須先設定好Hadoop的環境變數，然後再執行以下指令：

# hadoop jar hadoop-examples-1.0.1.jar wordcount /user/howie/input/article.txt /user/howie/output


但是真實世界的案例，一定是希望能透過傳遞參數直接改變程式所要連接的對象(比如說不同的Hadoop Server)，因此這本書透過範例，一步一步取代傳統的作法，首先先利用maven 的appassembler:assemble 功能，包成在Linux下的執行檔：

# cd hadoop/wordcount
# mvn clean package appassembler:assemble
# sh ./target/appassembler/bin/wordcount hdfs://localhost:9000/user/howie/input
hdfs://localhost:9000/user/howie/output


不過這個方法的缺點是連線的參數與設定檔已經跟程式包在一起，所以第二步再開始取代掉程式寫死設定Job的方法，改成由spring 的方式，可以透過xml設定，這也是為了之後可以把參數設定拉出來埋下伏筆：

Job job = new Job(conf, "word count");
job.setJarByClass(WordCount.class);
job.setMapperClass(TokenizerMapper.class);
job.setCombinerClass(IntSumReducer.class);
job.setReducerClass(IntSumReducer.class);
job.setOutputKeyClass(Text.class);
job.setOutputValueClass(IntWritable.class);


改成把所有設定值都拉到spring-context.xml

fs.default.name=${hd.fs}
input-path="${wordcount.input.path}"
output-path="${wordcount.output.path}"
mapper="org.apache.hadoop.examples.WordCount.TokenizerMapper"
reducer="org.apache.hadoop.examples.WordCount.IntSumReducer"


最後只需要這樣就可以執行程式，其他東西都透過讀取設定檔來搞定

$ mvn clean package appassembler:assemble
$ sh ./target/appassembler/bin/wordcount


而且只要改成這樣，之後就可以完全納入Spring 的 @Autowired 管理範疇，不過我發現這本比較著重在MapReduce的範例，反而Hbase的設定就草草帶過，結果反而在Hbase遇到比較多問題....=_= 之後再整理一下Hbase的設定改如何設定。


感覺最近又進入死腦筋鑽牛角尖狀態...明明還有好多事要做，卻一直堅持要把spring data 跟hadoop搞清楚...Orz..

關於Data analystis 線上課程

圖片來源：pcconlinecourses

在這個年代，只有想不想學或是有沒有時間學，而沒有學不學的到這件事了...Orz..
(其實還是有學不會的可能~XD) 有興趣的可以參考看看



Standford University - Machine Learning
https://www.coursera.org/course/ml

Toronto University - Neural Networks for Machine Learning
https://www.coursera.org/course/neuralnets

Washington University - Machine Learning
https://www.coursera.org/course/machlearning

Washington University - Introduction to Data Science
https://www.coursera.org/course/datasci

Johns Hopkins University - Data Analysis
https://www.coursera.org/course/dataanalysis

Johns Hopkins University - Computing for Data Analysis (by R)
https://www.coursera.org/course/compdata


Statistics
https://www.udacity.com/course/st095

Online Education in Analytics, Data Mining and Data Science
http://www.kdnuggets.com/education/online.html

cloudstack 與 openstack 目前的發展趨勢

圖片來源：Kiwi He (殊途同歸)

最近參加許多研討會，或是在網路上的論壇，最常聽到的就是在詢問Openstack 與 CloudStack的比較與差異，網路上也有許多文章從各種角度去比較各個Open Source IaaS平台之間得差異，有的從功能面，有的從參與的廠商數，有的從社群的活躍度(Mail list 討論量，Bug Report量，Release 的速度，甚至活動的參與人數)，舉例圖片如下：

 圖片來源：婉兮清扬 [3]

就我的觀察，目前Open Source IaaS 的兩大陣營 CloudStack 與 OpenStack，是分別從不同的設計理念出發，但是最終的目標就是希望能迎頭趕上Amazon ，成為像AWS一樣的Public Cloud。目前這兩個IaaS的所處位置就如圖下圖所示：

圖片來源：opennebula

OpenStack

從社群面來說：

OpenStack 去年呈現爆炸性的成長(參與人數)，有許多大廠都跳進來搖旗吶喊，從正面的角度來看社群欣欣向榮，有這麼多大廠人力和財力的支持，發展起來一定很威，但是從反面角度思考，畢竟各家廠商都還是有商業利益考量，所以針對規格和發展方向就會進行拉扯與角力，這一點讓人隱憂。

從架構面來說：

此外OpenStack 的設計理念從一開始就是為了超大型的IaaS 架構在設計，所以所有的元件(Service) 一開始就是以分散式的架構在開發，每個Service 都可以獨立運作，也是由個社群團隊獨立開發，優點是如果整合的好的話，對於將來Scale out 整個系統會非常方便，但是目前的狀況卻似乎不是這樣，每個Service 的開發與整合感覺沒有那麼同步，所以不管在安裝上與整合上都有一定的門檻。不過隨著時間的演進這個問題應該會慢慢的解決。

從語言面來說：

OpenStack 主要是以Python 來開發，這部份我就不多評論，因為我跟pythone不熟~:P


CloudStack 

從社群面來說：

CloudStack 最早其實是Cloud.com所以開發的軟體，後來被Cirtix 所併購，所以這個產品一開始就算是一個成熟的產品，直到2012年Citrix 把 CloudStack 以Apache 的License 的方式捐獻出去，整個社群就開始蓬勃發展，這次去參加ApacheCon 2013 就有超過11個Session 就是跟CloudStack有關。

從架構面來說：

就我的觀察CloudStack的設計理念反而是從Private Cloud走向Public Cloud 架構，也就是CloudStack 在一開始開發時，主要是以管理較小的機房架構(Private Cloud)為主，所以不管在安裝的容易度上，和產品的整合度上都非常成熟，在這邊分別把我覺得不錯的優點和特色一一舉出：

1. 出色直覺化的UI

 最讓我覺得驚訝的就是建立Virtual Machine 的畫面，跟我之前開發MechCloud的想法一模一樣，利用圖像化直覺的設計，讓使用者很清楚他現在在做什麼，以及到哪個步驟了，下面第一張圖是當初MechCloud一開始的設計，第二張圖示Cloudstack的設計，是不是很像。

再來談談Architecute，下圖是Cloudstack的Architecture階層圖，管理階層是從Zone，Pod，Cluster，Host，到VM。直接看到這張架構圖應該是很好理解，但是如果在安裝與設定時要怎麼對應成這張圖呢？

Cloudstack 直接把上面階層的概念做成UI，讓你由圖片可以很清楚的了解整個Deploy 架構和網路設定

 2.支援多種網路架構(主要由Basic Mode and Advanced Mode去組合變化)

IaaS裡面最複雜的一部分就是網路規劃，以及Vlan的設定，CloudStack 同樣也是透過圖形化的方式讓管理者很容易去設定和了解網路的架構，下圖分別是Basic mode 和 Advanced Mode的畫面。

 詳情請參考：

• CloudStack Advanced Mode Step by Step
• Understanding Cloudstack's physical network architecture

3.歡迎各家廠商加入的Plugin-in 架構

這部份算是CloudStack最受歡迎的部份，這次參加ApacheCon 2013 裡面就有人提到OpenStack和CloudStack在這方便最大的差別：

Open source Community Leadership Drives Enterprise Grade innovation.Cloudstack's plug-in model permit enterprise-grade adapters.

Cloustack的理念是這樣，企業在尋找的是可以更客製化的Iaas環境，但是如果要客製化Iaas，必須先了解整個cloustack或是openstack實在是太困難，所以cloudstack 允許企業可以從 plug-in or adapter的架構切入，讓企業可以直接針對自己的需求與所需要支援的硬體去開發plugin，不用受限於社群的審查和投票流程，因為傳統在社群上要開發新Feature必須經過以下流程：

• 在Maillist 宣布，讓大家都能知道，是否能接受
• 公開Function Spec & Design
• JIRA ticket for feature
• Setup a Dev Environment
• Branch on github use your own (publich) branch
• Submit changes to Review board
• Post-reviw for large package of changes
• Decide on the wiki you want

所以Plugin 的架構可以讓企業在開發上增加彈性，不論是要直接捐獻給社群，或是沒有捐獻給社群直接拿來獲利都是可以。


4. 使用Java 開發

好啦，這其實是我的私心，因為Java比較熟，所以從Cloudstack切入會比較容易，不管是要改寫,patch 或是寫plugin都非常方便。


最後，就如同我說的cloudstack一開始就是從Private cloud的角度去開發，所以之前的架構是把所有servie 都綁在一起 ，如果要比較大規模的佈署時(類似AWS)可能就會遇到Scale 的問題，因此cloudstack社群也有注意到這個問題，在 4.1 已經開始在把系統架構重構(代號Javelin)，目的是要把架構變成Loosely-coupled component oriented distributed architecture。

結論：

青菜蘿蔔個有所愛，所以也不能因為我比較喜歡cloudstack就說openstack不好，一切還是要回歸企業的應用與需求為主，上面所寫的只是希望可以給各位在選擇解決方案時能有所參考。



延伸閱讀：
[1] CloudStack 與 OpenStack 誰將稱王
[2] OpenStack vs CloudStack: The Latest Score
[3] CY12-Q4 Community Analysis — OpenStack vs OpenNebula vs Eucalyptus vs CloudStack

Apache Kafka 又一個messaging system !?

圖片來源：網路

這次在ApacheCon2013 上看到  Apache Kafka 的專案介紹，心想又一個messaging system !?

Intra-cluster Replication in Apache Kafka

於是又好奇的去收集了許多資料，首先參考Slideshare的一篇介紹Apache Kafka 的投影片，Kafka號稱最大的特色是同時混和了Offline log以及Realtime Message  兩種功能。

還記得上一篇文章我有提到各種分散式Log-aggregation系統 (如Scribe 和 Flume)，他們的架構都是Push driven architecture，雖然具高效能高擴充性，但是有以下缺點：

• 預期的端點(End points)都是大型叢集(如：Hadoop)
• 端點(End points)不能有太多即時性商業邏輯 (business logic in real-time)

因為他們最主要的工作就是盡量快速的去消化客戶端push 過來的log，而跟傳統的Messaging System(如：RabbitMQ , ActiveMQ)，並不夠Scale ?：
(不太懂這邊的意思，還需要要研究一下...)

• No API for batching, transcational (broker retain consumers stream position)
• No Message persistence means multiple consumers over time are impossible limiting architecture

圖片來源：Apache Kafka

談到MQ大家最有興趣的一點就是效能了，看到投影片的圖...有沒有那麼神！？

圖片來源：Apache Kafka

不過仔細看benchmark 的條件與環境設定，還是發現他為了增加吞吐的效能，對於資料的的完整性和確保性作了取捨：

Kafka producer currently doesn't wait for ack form the broker. Without ack , there is no gurantee that every published message is actually receved by the broker

所以如果是必須保證送達的系統，可能就不能使用Kafka 了~

RabbitMQ vs. Kafka

了解了Kafka特性後，還是不免會想要跟RabbitMQ作一下比較，參考Quora的這篇文章"RabbitMQ vs Kafka which one for durable messaging with good query feature"，針對兩個系統的特色，節錄以下內容：

a) Use Kafka if you have a fire hose of events (100k+/sec) you need delivered in partitioned order 'at least once' with a mix of online and batch consumers, you want to be able to re-read messages, you can deal with current limitations around node-level HA (or can use trunk code), and/or you don't mind supporting incubator-level software yourself via forums/IRC. 

b) Use Rabbit if you have messages (20k+/sec) that need to be routed in complex ways to consumers, you want per-message delivery guarantees, you don't care about ordered delivery, you need HA at the cluster-node level now, and/or you need 24x7 paid support in addition to forums/IRC.

不過作者也回答道，如果要求的是Real time streaming process (filter/query) 的功能的話，這兩個都不適合，反而應該考慮Storm：

Neither offers great "filter/query" capabilities - if you need that, consider using Storm on top of one of these solutions to add computation, filtering, querying, on your streams

透過這些文章與解釋我似乎開始了解 Kafka or Storm 的用途與應用情境，也漸漸了解到為什麼很多公司都是使這兩個系統用來補足Hadoop real-time process 不足的地方，因為實在有太多公司使用這種組合，下面舉例infochimps這間公司如何看待Storm and Kafka：

Why should you care?

With Storm and Kafka, you can conduct stream processing at linear scale, assured that every message gets processed in real-time, reliably. In tandem, Storm and Kafka can handle data velocities of tens of thousands of messages every second.
Stream processing solutions like Storm and Kafka have caught the attention of many enterprises due to their superior approach to ETL (extract, transform, load) and data integration.
Storm and Kafka are also great at in-memory analytics, and real-time decision support. Companies are quickly realizing that batch processing in Hadoop does not support real-time business needs. Real-time streaming analytics is a must-have component in any enterprise Big Data solution or stack, because of how elegantly they handle the “three V’s” — volume, velocity and variety.
Storm and Kafka are the two technologies on the list that we’re most committed to at Infochimps, and it is reasonable to expect that they’ll be a formal part of our platform soon.

ps. 話說趨勢也有自己的MQ叫做TME - TrendMicro Message Exchange，所以我才會覺得怎麼又一個MQ....XD

Reference:
[1] Message Queue Evaluation Notes
[2] Background Jobs in Ruby on Rails
[3] Intra-cluster Replication in Apache Kafka

ApacheCon2013 - About BigTop

參加Conference要觀察一個技術或是專案的受重視程度，通常可以藉由幾個指標來觀察：

1. Session Room的安排 (越熱門的會議室通常越大間，越熱門的越早報告)
2. 類似題目sharing 次數 (越熱門的題目通常會被分享比較多次)

而這次參加ApacheCon最明顯的感受就是關於Bigtop 的受重視程度，因為光是Bigtop相關的題目就有三四場：

• Build & Deploy your own big data distribution with Apache Bigtop 
• Getting Hadoop, Hive and Hbase up and running in less than 15 min  [投影片]
• Lessons in Apache Software Integration [投影片]

三場的內容整理如下：

Why Bigtop ?

首先先從Hadoop的痛開始說起，傳統安裝Hadoop & Ecosystem 都會從Apache網站下載tar開始，然後接下來的步驟可能如下：

1. 下載安裝Hadoop
2. 設定環境變數 (當發現出現一堆error message 才會想起什麼環境變數忘了設定)
3. 設定HDFS權限 (當發現權限錯誤時才會想起要設定權限)
4. 如果要安裝Hive 就會遇到版本問題 (安裝其他ecosystem也常發生這些問題...Orz..)

所以社群就發現這不是跟當年的Linux一樣嘛？！最一開始Linux 都得要自己去下載套件，自己去Build每個套件，找出相依性....

  圖片來源：Bigtop

這種痛苦直到Debain出現才解決，除了提供一個整合的安裝還境外，由於是Debain完全由社群所貢獻，並不會由特定公司所把持，仍可以保持自由軟體的特性，但是也歡迎其他公司另外基於Debain上再做出更好的產(例如：ubuntu)。畢竟對於大部分的使用者來說，能用apt-get install 來安裝軟體是最好的，誰還會想由 tar ball來安裝呢？因為還得解決一堆相依性的問題。

圖片來源：Bigtop

所以BigTop 的概念就是類似Debain 的角色，要靠社群的力量來完成一個套件，其他公司如Cloudera和Hortoneworks ...等，可以基於Bigtop上加值和再開發。

所以Bigtop的定位就是：

Bigtop make building block to distribution

想像以後如果想要安裝任何Hadoop ecosystem時，只要下以下的指令，不是很棒嘛：

# bigtop lanuch-cluster -config ./hbase.ini

Key challenges

有願景是好的，不過Bigtop專案目前也遇到以下許多問題：

• A really drivers set of components
• High churn APIs 
• 不像Linux 有一個統一的架構，大家都不知道hadoop的最終方向，都是邊走邊改，所以API之間的相容性永遠是問題
• Asynchronous development cycles.
• 每個專案由於熱門程度不同，開法速度也不一樣，所以在升級上很難做到同步一致。
• Combinatorial explosion of dependency
• 永遠有各種版本的組合，也永遠會有不同的Bug
• Java based
• Java 開源專案最怕的 dependency 地獄，就算用 maven 也會有衝突的問題，最有常遇到的例子就是slf4j 和 log4j版本的問題
• Fundamentally distributed application
• Apache 的好處就是提供各式各樣的專案和building block，但是缺點就是太多了，你必須到市場去慢慢挑選你要怎麼整合，一個Architecture 就像一個廚師，你必須先知道每個食材的特色，和相互之間的關係，你才可以知道要挑什麼食材煮一套菜。

所以Bigtop的願景怎麼實現？這個專案到底要提供什麼？

• Integration 
• Build (make, Maven)
• Packaging (RPM, DEB)
• Deployment (Puppet)
• Testing (integration Test)
• A continuous integration Jenkins server 

所以目前Bigtop所使用的方法是一步一步慢慢推進，Embrace asynchronous nature (擁抱不同不的Hadoop)，總是找出一個最好的build ，然後再每次慢慢改一個lib 來測試推進。

Ps. 講者特別再會場徵求

目前Bigtop的Jenkins和測試整環境放在EC2 由cloudera提供，他們也歡迎任何公司/學術機構提供Test Case (放在Hadoop 跑的Real Case)，讓他們放在Jenkins 上持續的跑整合測試。



延伸閱讀：
[1] What is Bigtop, and Why Should You Care
[2] How to install Hadoop distribution from Bigtop 

自助旅行的決策模型與資料收集

圖片來源：網路

前一陣子覺得遊記如果沒有寫的很完整，只是一些短短的見聞或感想似乎沒有必要寫出來，或是如果沒有寫的文情並茂，只是一堆流水帳和貼一堆照片和註解的文章似乎也是上不了檯面 ( 其實就是偷懶的藉口...Orz..)

但是這次去美國出差真的就受惠於許多部落客的分享文章(尤其可能是微不足道的小事)，因為很多時候根本沒有辦法事先做功課，或是只能趁空檔安排個行程，這時候只要有網路能上網搜尋，就可以得到很多的幫助～\@o@/

所以想法一改變就覺得這次似乎有很多東西都值得寫..... (但是時間真的不夠用啊)

不過這倒是觸發我另外一些想法，關於自助旅行的人都怎麼收集資料，如何決定要去哪裡玩和怎麼玩？這一連串的決策過程往往就跟資料的收集過程有很大的關係，通常旅遊的資訊來源有幾個，在這邊簡單分類一下：

• 部落客的遊記 
• 優點：內容較為廣泛，只要能上網/能搜尋就很容易找到自己想要的資訊
• 缺點：較為分散，需要倚賴搜尋技巧和時間，要注意時效性
• 背包客棧的分享文/答問文 
• 優點：較為集中，很容易找到/問到最新的資訊
• 缺點：比較詳細的圖文資訊還是得連到外部Blog，論壇式討論很多廢話~:P
• 旅遊書 / 雜誌
• 優點：攜帶方便，不需要網路
• 缺點：貴，資料較少，可能一整本只有幾頁你需要，資料的時效性也要注意
• 旅遊景點/國家 官網 
• 優點：資料集中有整理，能很快的抓到這個城市或國家的重點
• 缺點： 對於景點介紹太...官方說法...過於美化~:P
• 旅遊規劃網站  (參考與規劃行程)
• 優點：可以參考別人的行程與玩法，懶人規劃法~
• 缺點：行程不一定適合你，詳細資料還是得搭配Blog 來參考
• Location based 導覽/推薦 APP
• 優點：到當地如果都沒做功課臨時抱佛腳用~
• 缺點： 一定要有網路，一旦出了國....就很不太好用了..

由上面所列出來的資料來源就可以發現，絕大部分都還是要靠鄉民分享的力量，不論是是寫Blog，在論壇上分享與討論，或者是在旅遊規劃網站分享旅遊行程，甚至現在很多旅遊書都是Bloger出的。

於是這就變成一個Feedback Loop，有人先分享他的旅遊見聞與紀錄，而這些資訊就成為大家資料收集的來源，然後根據這些資料規劃下一次旅行，藉由實地去旅行，又可以產生新的Feedback 和心得的資訊，讓下一個要去玩的人可以拿到最新的資料...

所以最後的結論就是，大家請不要害羞或是懶惰停止寫遊記或是分享的文章，你的文章可以造福下一個要去玩的人！！

各種 Distributed Log collection framework

Open Source 的迷人之處，同時也是最讓人頭痛的地方就是選擇太多，迫使我們常常必須在這麼多Solution中找出適合自己專案的來用，如果每個Solution 都有專門擅長的領域，或是使用的語言差異很大，那可能還好選擇，就怕是技術同質性高的東西。

舉例來說，以前就知道光是Message Queue (MQ) 就有很多種選擇，但是前一陣子去參加ApacheCon 居然又看到好幾種新的MQ專案，感覺同質性也非常高，雖說會要開發新的一定是為了要解決某種特殊問題，或是覺得舊的不夠用....不過沒花時間深入研究的話是根本比較不出來，所以到現在都還在頭痛中，到底該怎麼選擇...... (找機會再來整理一下各種MQ Solution )。

不過今天不是要談MQ是要談Distributed Log collection framework(DLCF)，主要是看到了Treasure Data的這個投影片 "The Basic of Fluentd"，裡面有針對幾個比較熱門的DLCF做比較，於是我就想是應該把這一陣子有看到的都整理一下了，因為選擇也越來越多了！！

Fluentd (It's like syslog,but uses JSON for log message)

官網：http://fluentd.org/
GitHub: https://github.com/fluent/fluentd

Scribe (Log collector for Facebook )-----> Calligraphus

GitHub: https://github.com/facebook/scribe
Wiki: https://github.com/facebook/scribe/wiki/Scribe-Overview

Ps. 在這篇投影片裡面有提到Facebook 打算從Scribe (C based) 換成 Calligraphus (Java Based)

Flume (Distributed log collector by Cloudera now in Apache)

官網：http://flume.apache.org/FlumeUserGuide.html
Wiki: https://cwiki.apache.org/FLUME/home.html
GitHub: https://github.com/cloudera/flume

Chukwa

官網：http://incubator.apache.org/chukwa/

BigStream (Streams is inspired by Chukwa)

官網：http://code.google.com/p/bigstreams/

logstash  (logstash is a tool for managing events and logs)

官網：http://logstash.net/


是不是很多！！為什麼大家都要來搞一套呢？光是Apache 就有兩三套....不過由Molliza 的案例應該就可以了解為什麼會有那麼多Log framework，話說在2010年初Molliza使用的技術是Flume + Hive，在這篇Molliza 的Blog Collecting and analyzing log data via Flume and Hive 裡面提到：

Chukwa, Scribe and Flume are headed in the right direction, but the final piece of puzzle of analyzing the data still remained unsolved, until few weeks back as we, at Mozilla, started integrating Flume with Hive.

不過呢，才到了2010年底， 內部就有不同的聲音了"Flume, Hive and realtime indexing via ElasticSearch"，好還要在更好是吧~

Flume + Hive really solves our needs, but we would ideally like a solution that indexes our data and can be queried in real-time

所以這次ApacheCon 2013 Mozilla的人去演講的題目 "Firefox Crash Analysis Laura Thomson" 就是在講他們自己新開發的系統：

Socorro (A server for collecting, processing, and displaying crash reports from clients using the Breakpad libraries)

Wiki: https://wiki.mozilla.org/Socorro
GitHub: https://github.com/mozilla/socorro

主要的Use Case 就是如果Firefox 當機了，必須要知道以下資訊：怎麼當的，版本，那一個build?OS?channel，是新發現的問題還是舊的？

有興趣的人可以去這邊下載投影片來看

ApacheCon 2013 BarCamp 初體驗

圖片來源：Apache barcamp Portland wiki

這是我第一次參加barcamp，之前完全沒聽過，也不了解裡面的內容，所以在參加前還先上網研究了一下到底barcamp 都在做什麼，節錄規則如下：

1. 你必須做關於 BarCamp部落格。
2. 如果你想要介紹，你必須將你的主題以及名稱寫在簡報上。
3. 自我介紹只講三個詞！請先想一下要用哪三個詞來表達自己關心的事情
4. 不預先排定議程，也不僅僅來當個過客！
5. 除非影響到其他人的說話時間，不然講者可以盡情地講！
6. 第一次參加 Barcamp 的人們，請一定要講些東西

關於1,2,4,5都還ok，但是一看到3,6就有點峱峱的....

不過因為Apache  的 mini Barcamp有 Expedia 贊助自助霸和飲酒霸(啤酒和紅酒)，衝著時食物就硬著頭皮上了！XDD

首先大會開始會有一個主持人 (主要是負責控制時間)，然後大家亂哄哄的開始報名想要討論的題目，然後就會投票主持人幫忙記票和排時間，下圖紅色圈起來的就是會議議程表(很Agile 的fu)，然後紅色頭髮那位就是主持人 (叫做Nóirín)~XD

最後排定了，幾個討論的題目，然後主持人就會依照上面的時間來提醒大家，然後再時間內大家都可以踴躍發言和分享。

看老外嘴砲討論真的還蠻有趣的，他們都還蠻喜歡針對嚴肅的議題做討論，然後問題和回答都很犀利，如果場景回到台灣，可能都是場面一片和諧，大家都不好意思說話，說的也都是場面話？(不過大陸人這點就比較像老外，問問題很不客氣的~:P)

對我印象最深刻的幾個議題：

• GPL2 vs. Apache License v2 的比較
• 為什麼越來越多專案轉移到Apache License
• 怎麼看待individual contribution 和 company contributions
• 討論政府是否可以像Open source這樣運行，同樣的Open source 在管理上面是否適用所謂民主的表決？

通常想發言的就會舉手，但是太溫和還是會被插話~:P

其實，除了少數幾個人比較踴躍發言外，大部分的人都鄉民一樣，拉板凳拿啤酒看好戲...XD

我大概是太累了眼殘...把PALE ALE...自動解讀成APPLE....想說蘋果口味啤酒一定要喝喝看，結果好難喝.....Orz..