Connecting Hbase using Java

Connecting HBase using Java

Big Data World

To write a simple Java application with HBase APIs, you surely need hadoop and hbase installation on your machine.

The hbase with Java is done in below versions of Linux, Java, Hadoop and Hbase respectively.

UBUNTU 13.4

JAVA 1.7.0_25

HADOOP 1.1.2 [pseudo distributed setup]

HBASE-0.94.8

To administer HBase, create and drop tables, list and alter tables, use HBaseAdmin. Once created, table access is via an instance of HTable. You add content to a table a row at a time.

Step 1: Start HBase. Start Eclispe.

Step 2: Create a new Java Project (File -> New -> Java Project).

Step 3: Fill up the form. (Here project name = HbaseConnection) and click next.

Step 4: Select Libraries tag from it and click “Add External JARs”.

Step 5: Browse to the $HBASE_HOME directory. ($HBASE_HOME is the directory where you have installed Hbase).

Step 6: Select hbase-0.94.8.jar and click Ok…

View original post 624 more words

Advertisements

Hbase Map Reduce Program (read content from the table and write the same content to another table)

userful

RJ Solusoft

First of all create a table test and insert data.

and create a second table target.

Below program read all the content from test table and copy into target table.
import java.io.IOException;

import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.fs.Path;
import org.apache.hadoop.hbase.HBaseConfiguration;
import org.apache.hadoop.hbase.KeyValue;
import org.apache.hadoop.hbase.KeyValue.SplitKeyValue;
import org.apache.hadoop.hbase.client.Put;
import org.apache.hadoop.hbase.client.Result;
import org.apache.hadoop.hbase.client.Scan;
import org.apache.hadoop.hbase.io.ImmutableBytesWritable;
import org.apache.hadoop.hbase.mapreduce.TableMapReduceUtil;
import org.apache.hadoop.hbase.mapreduce.TableMapper;
import org.apache.hadoop.hbase.mapreduce.TableReducer;
import org.apache.hadoop.hbase.util.Bytes;
import org.apache.hadoop.io.IntWritable;
import org.apache.hadoop.io.LongWritable;
import org.apache.hadoop.io.Text;
import org.apache.hadoop.mapred.JobConf;
import org.apache.hadoop.mapreduce.Job;
import org.apache.hadoop.mapreduce.Mapper;
import org.apache.hadoop.mapreduce.Reducer;
import org.apache.hadoop.mapreduce.lib.input.FileInputFormat;
import org.apache.hadoop.mapreduce.lib.input.TextInputFormat;
import org.apache.hadoop.mapreduce.lib.output.FileOutputFormat;
import org.apache.hadoop.mapreduce.lib.output.TextOutputFormat;

public class MySummaryJob {
public static class MyMapper extends TableMapper<Text, IntWritable>
{
public static final byte[] CF = “data”.getBytes();
public static final byte[] ATTR1 = “1”.getBytes();

private final IntWritable ONE = new IntWritable(1);
private Text text = new Text();

public void map(ImmutableBytesWritable row, Result value, Context context) throws IOException, InterruptedException {
KeyValue[] keyValue= value.raw();
for(int i=0;i<keyValue.length;i++)
{
SplitKeyValue splitKeyValue=keyValue[i].split();
//String val = new String(value.getValue(splitKeyValue.getFamily(), splitKeyValue.getQualifier()));
System.out.println(“Family – “+Bytes.toString(splitKeyValue.getFamily()));
System.out.println(“Qualifier –…

View original post 237 more words

Các trích dẫn hay trong tuyện "Anh có thích nước Mỹ không" của Tân Di Ổ

Đỉnh NGUYỄN

“Anh đối xử với cô không bằng cô đối xử với anh, đó cũng có thể là do tình yêu anh dành cho cô không nhiều như cô dành cho anh, nhưng xét cho cùng tình yêu không phải là buôn bán, làm sao có thể đòi hỏi sự công bằng tuyệt đối, nếu nhất thiết pải có một người yêu nhiều hơn, thì đó là cô cũng chẳng sao. Nếu cô bỏ ra mười phần, anh chỉ đáp lại năm phần, thế thì cô cho anh hai mươi phần, không phải anh sẽ trả cô mười phần đó sao?”.

“Chính cô là người quyết định yêu, không ai ép cô, thế nên chỉ cần dồn mọi tâm huyết để yêu, không phải lúc ở bên anh cô cũng thấy vui đó sao? Tuổi xuân có hạn, điều này không sai, nhưng cô càng không thể phí hoài tuổi xuân…

View original post 699 more words

How does MySQL Replication really work?

While we do have many blog posts on replication on our blog, such as on replication being single-threaded, on semi-synchronous replication or on estimating replication capacity, I don’t think we have one that covers the very basics of how MySQL replication really works on the high level. Or it’s been so long ago I can’t even find it. So, I decided to write one now.
Of course, there are many aspects of MySQL replication, but my main focus will be the logistics – how replication events are written on the master, how they are transferred to the replication slave and then how they are applied there. Note that this is NOT a HOWTO setup replication, but rather a howstuffworks type of thing.

Replication events
I say replication events in this article because I want to avoid discussion about different replication formats. These are covered pretty well in the MySQL manual here. Put simply, the events can be one of two types:

  • Statement based – in which case these are write queries
  • Row based – in this case these are changes to records, sort of row diffs if you will

But other than that, I won’t be going back to differences in replication with different replication formats, mostly because there’s very little that’s different when it comes to transporting the data changes.

On the master
So now let me start with what is happening on the master. For replication to work, first of all master needs to be writing replication events to a special log called binary log. This is usually very lightweight activity (assuming events are not synchronized to disk), because writes are buffered and because they are sequential. The binary log file stores data that replication slave will be reading later.
Whenever a replication slave connects to a master, master creates a new thread for the connection (similar to one that’s used for just about any other server client) and then it does whatever the client – replication slave in this case – asks. Most of that is going to be (a) feeding replication slave with events from the binary log and (b) notifying slave about newly written events to its binary log.
Slaves that are up to date will mostly be reading events that are still cached in OS cache on the master, so there is not going to be any physical disk reads on the master in order to feed binary log events to slave(s). However, when you connect a replication slave that is few hours or even days behind, it will initially start reading binary logs that were written hours or days ago – master may no longer have these cached, so disk reads will occur. If master does not have free IO resources, you may feel a bump at that point.

On the replica
Now let’s see what is happening on the slave. When you start replication, two threads are started on the slave:
1. IO thread
This process called IO thread connects to a master, reads binary log events from the master as they come in and just copies them over to a local log file called relay log. That’s all.
Even though there’s only one thread reading binary log from the master and one writing relay log on the slave, very rarely copying of replication events is a slower element of the replication. There could be a network delay, causing a steady delay of few hundred milliseconds, but that’s about it.

If you want to see where IO thread currently is, check the following in “show slave status\G”:

  • Master_Log_File – last file copied from the master (most of the time it would be the same as last binary log written by a master)
  • Read_Master_Log_Pos – binary log from master is copied over to the relay log on the slave up until this position.

And then you can compare it to the output of “show master status\G” from the master.
2. SQL thread
The second process – SQL thread – reads events from a relay log stored locally on the replication slave (the file that was written by IO thread) and then applies them as fast as possible.
This thread is what people often blame for being single-threaded. Going back to “show slave status\G”, you can get the current status of SQL thread from the following variables:

  • Relay_Master_Log_File – binary log from master, that SQL thread is “working on” (in reality it is working on relay log, so it’s just a convenient way to display information)
  • Exec_Master_Log_Pos – which position from master binary log is being executed by SQL thread.

Replication lag
Now I want to briefly touch the subject of replication lag in this context. When you are dealing with replication lag, first thing you want to know is which of the two replication threads is behind. Most of the time it will be the SQL thread, still it makes sense to double check. You can do that by comparing the replication status variables mentioned above to the master binary log status from the output of “show master status\G” from the master.
If it happens to be IO thread, which, as I mentioned many times already, is very rare, one thing you may want to try to get that fixed is enabling slave compressed protocol.
Otherwise, if you are sure it is SQL thread, then you want to understand what is the reason and that you can usually observe by vmstat. Monitor server activity over time and see if it is “r” or “b” column that is “scoring” most of the time. If it is “r”, replication is CPU-bound, otherwise – IO. If it is not conclusive, mpstat will give you better visibility by CPU thread.
Note this assumes that there is no other activity happening on the server. If there is some activity, then you may also want to look at diskstats or even do a query review for SQL thread to get a good picture.
If you find that replication is CPU bound, this maybe very helpful.
If it is IO bound, then fixing it may not be as easy (or rather, as cheap). Let me explain. If replication is IO bound, most of the time that means that SQL thread is unable to read fast enough because reads are single threaded. Yes, you got that right – it is reads that are limiting replication performance, not writes. Let me explain this further.
Assume you have a RAID10 with a bunch of disks and write-back cache. Writes, even though they are serialized, will be fast because they are buffered in the controller cache and because internally RAID card can parallelize writes to disks. Hence replication slave with similar hardware can write just as fast as master can.
Now Reads. When your workset does not fit in memory, then the data that is about to get modified is going to have to be read from disk first and this is where it is limited by the single-threaded nature of the replication, because one thread will only ever read from one disk at a time.
That being said, one solution to fix IO-bound replication is to increase the amount of memory so working set fits in memory. Another – get IO device that can do much more IO operations per second even with a single thread – fastest traditional disks can do up to 250 iops, SSDs – in the order of 10,000 iops.

Resource: http://www.percona.com/blog/2013/01/09/how-does-mysql-replication-really-work/

Send POST request with python using urllib2

Source code:

import httplib
import urllib
import urllib2

urllib2.install_opener(
    urllib2.build_opener(
        urllib2.ProxyHandler({'http': '127.0.0.1:8080'})
    )
)

headers = {
    #'Host': 'host.com',
    #'Connection': 'keep-alive',
    #'Content-Length': '325', 
    #'Origin': 'https://digitalvita.pitt.edu',
    #'User-Agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.89 Safari/537.1',
    'Content-type': 'application/x-www-form-urlencoded; charset=UTF-8',
    #'Accept': 'text/javascript, text/html, application/xml, text/xml, */*',
    #'Referer': 'https://digitalvita.pitt.edu/index.php',
    #'Accept-Encoding': 'gzip,deflate,sdch',
    #'Accept-Language': 'en-US,en;q=0.8',
    #'Accept-Charset': 'ISO-8859-1,utf-8;q=0.7,*;q=0.3',
    #'Cookie': 'PHPSESSID=lvetilatpgs9okgrntk1nvn595'
}

data = urllib.urlencode({
    "username":"admin",
    "password":"admin"})
req = urllib2.Request('http://abc.def/path', data, headers)
response = urllib2.urlopen(req)
print response.read()



Grid Computing và những khái niệm điện toán mới

Tính toán mạng lưới (grid) ngày nay không còn là một giải pháp hàn lâm hay thử nghiệm. Với những tiến bộ quan trọng về phần mềm triển khai, người ta hy vọng nó sẽ đem sức mạnh của siêu máy tính tới tất cả người dùng PC đơn lẻ trên thế giới.

 

Grid là gì và hoạt động như thế nào?

Grid là một loại hệ thống phân tán, bố trí song song, cho phép linh hoạt chia sẻ, tuyển lựa và tập hợp các nguồn tài nguyên độc lập và rải rác về địa lý, tùy theo khả năng sẵn có, công suất, hoạt động, chi phí và yêu cầu về chất lượng dịch vụ của người sử dụng.

Điện toán mạng lưới (ĐTML) có nghĩa là tất cả hoặc một phần của một nhóm máy tính, máy chủ và thiết bị lưu trữ trong mạng doanh nghiệp, được “ảo hóa” (virtualize) thành một cỗ máy tính lớn. Vì ĐTML giải phóng những khả năng tính toán không được sử dụng vào một thời điểm bất kỳ, chúng có thể cho phép các doanh nghiệp tăng cường rất nhiều về tốc độ, sức mạnh xử lý thông tin và sự liên kết, thúc đẩy các quy trình tính toán mật độ cao. Trong khi đó, chi phí vẫn sẽ được giữ ở mức thấp vì ĐTML có thể được xây dựng từ chính hạ tầng hiện có, góp phần đảm bảo sự huy động tối ưu các khả năng tính toán.

ĐTML cho phép ảo hóa các chức năng tính toán phân tán cũng như các nguồn xử lý, băng thông mạng và khả năng lưu trữ, để từ đó tạo ra một hệ thống đơn đồng nhất, cho phép người sử dụng và các ứng dụng truy cập thông suốt vào các tính năng điện toán rộng lớn. Giống như người lướt web xem một nội dung thống nhất qua web, người sử dụng ĐTML cũng nhìn thấy một máy tính ảo cực lớn duy nhất.

Trọng tâm của ĐTML dựa trên một tập hợp mở của nhiều chuẩn và giao thức, ví dụ Kiến trúc dịch vụ lưới mở (OGSA), cho phép liên lạc qua nhiều môi trường hỗn tạp và phân tán về địa lý. Với ĐTML, các tổ chức và doanh nghiệp có thể tối ưu hóa khả năng tính toán và các nguồn dữ liệu, tập trung chúng lại thành những khối sức mạnh lớn, chia sẻ chúng qua mạng và thúc đẩy sự phối hợp, tương tác.

Giả dụ, khi một người có chiếc máy tính cá nhân tham gia đóng góp sức mạnh xử lý trong một mạng lưới grid muốn chạy một ứng dụng đòi hỏi thêm sức mạnh xử lý thì công việc đang được giải quyết trên chiếc máy đó sẽ được tự động tái phân bổ tới một máy khác trong lưới đang “rảnh rỗi” và không bị trưng dụng sức mạnh tính toàn vào công việc nào.

Xây dựng một lưới grid có thể đơn giản như việc cho phép một số lượng nhỏ PC hoặc server hoặc mạng lưu trữ tận dụng những khả năng chưa được khai thác hết. Từ một quy mô triển khai ban đầu nhỏ, người sử dụng có thể dần dần hoặc lập tức mở rộng lưới tùy theo nhu cầu của doanh nghiệp. Lưới này không chỉ có thể liên kết các quy trình hoạt động của một bộ phận mà có thể phối hợp các phòng ban với nhau hoặc thậm chí liên kết sức mạnh hạ tầng của một số doanh nghiệp độc lập.

Ích lợi của tính toán lưới:

ĐTML có thể đem lại những ích lợi rất rộng lớn. Nó tăng tốc độ xử lý để rút ngắn thời gian thu được kết quả, từ đó cho phép tiết kiệm thời gian và tài nguyên phục vụ cho việc giải quyết những vấn đề mà trước đó chưa được xử lý. ĐTML nâng cao năng suất và sự phối hợp trong doanh nghiệp bằng cách cho phép các bộ phận và phòng ban phân tán ở nhiều nơi tạo ra các “tổ chức ảo” để chia sẻ dữ liệu và tài nguyên. Grid khiến cho hạ tầng hoạt động của doanh nghiệp linh hoạt hơn với việc cho phép truy nhập lập tức vào hệ thống tính toán và các kho dữ liệu để “cảm nhận” và phản hồi kịp thời những yêu cầu. Grid cũng góp phần đảm bảo khai thác tốt nhất các khả năng tính toán hiện có của một công ty dựa trên những khoản đã đầu tư. Triển khai ĐTML cũng góp phần tránh được nguy cơ phân bổ tài nguyên không cân đối xảy ra rất phổ biến và tránh được các chi phí phát sinh. Một ích lợi lớn khác của ĐTML là nó giải phóng các bộ phận quản lý CNTT khỏi gánh nặng của việc quản lý các hệ thống không đồng nhất.

So sánh grid với các công nghệ khác:

So với khái niệm cluster và điện toán phân tán khác, grid có điểm chung là đem các nguồn sức mạnh tính toán lại làm một nhưng khác ở chỗ nó không cần có sự giới hạn về không gian địa lý hay sự đồng nhất về nền điều hành. Khác biệt cơ bản giữa khái niệm cluster (bó) với grid (lưới) chủ yếu nằm ở phương thức quản lý các nguồn tài nguyên. Đối với cluster, việc phân bổ tài nguyên được thực hiện bởi một đối tượng quản lý tài nguyên trung tâm và tất cả các nút (node) mạng hoạt động phối hợp với nhau như một nguồn đơn thống nhất. Đối với grid, mỗi nút có đối tượng quản lý tài nguyên riêng và các nguồn tài nguyên độc lập trong lưới có thể trải rộng khắp một hoặc nhiều tổ chức.

Trên thực tế grid không phải là một cuộc cách mạng mới mà có thể coi nó là một bước tiến hóa trong công nghệ điện toán phân tán, giống như web, chia sẻ file ngang hàng và các công nghệ ảo khác. Giống như web, ĐTML giảm bớt tính phức tạp khi mà nhiều người cùng khai thác một nền hoạt động thống nhất. Cái khác của nó đối với web chủ yếu là sự hỗ trợ liên lạc. So với mạng ngang hàng (P2P), ĐTML có điểm chung là cho phép người sử dụng chia sẻ file nhưng khác ở chỗ việc chia sẻ đó không chỉ là các file mà có thể là nhiều tài nguyên khác. So với các công nghệ ảo khác, grid giống ở chỗ cho phép ảo hóa các nguồn lực CNTT. Điểm khác là trong khi đối tượng và mục tiêu của các công nghệ ảo là một hệ thống đơn thì grid cho phép ảo hóa những nguồn tài nguyên tản mát và vô cùng rộng lớn.

Grid đã được thương mại hóa như thế nào?

Các nhà cung cấp giải pháp điện toán hàng đầu thế giới như Oracle, IBM, HP, Dell, Microsoft và Sun đều đã và đang có sách lược đầu tư lớn vào việc phát triển các sản phẩm và dịch vụ ĐTML.

Thiết lập một hệ thống ĐTML không đơn thuần chỉ là có một mạng máy tính tốc độ cao. Yếu tố quan trọng nhất chính là một nền phần mềm điều phối sức mạnh của các máy tính tham gia đóng góp sức mạnh nhiều dạng khác nhau trong lưới.

Trên thị trường đã xuất hiện những nền phần mềm thương mại hoặc dịch vụ phục vụ cho việc này. Ví dụ, Oracle đã tung ra thị trường Application Server 10g,  được coi là phần mềm trung gian đầu tiên giúp đơn giản hóa việc quản lý các ứng dụng chạy trên môi trường ĐTML. Đây là một bộ sản phẩm gồm khoảng 600 cải tiến trong ứng dụng tích hợp và cơ sở hạ tầng các dịch vụ Web.

Oracle Application Server 10 được xây dựng dựa trên các chuẩn mở, tạo ra một nền tảng thống nhất cho các khả năng hỗ trợ yêu cầu đa dạng của một doanh nghiệp thương mại điện tử, bao gồm các chức năng hỗ trợ như phần mềm cổng dành cho doanh nghiệp, lưu trữ tốc độ cao, tình báo doanh nghiệp, quản lý đồng nhất, phát triển ứng dụng nhanh, kết nối không dây và các dịch vụ Web. Oracle Application Server 10g cũng là sản phẩm trung gian duy nhất trong ngành giải pháp điện toán doanh nghiệp được trang bị các công nghệ tích hợp và ĐTML lắp sẵn.

Với việc đưa thêm khả năng ĐTML, phần mềm Application Server 10g giúp khách hàng giảm thời gian, sức lao động và chi phí cho việc quản lý CNTT bằng cách kết hợp các hệ thống máy chủ, hệ thống lưu trữ và các phần mềm cần thiết. Kết quả là các doanh nghiệp có thể sử dụng sức mạnh của toàn bộ hệ thống hay lưới cho tất cả các ứng dụng dành cho doanh nghiệp chứ không phải mua thêm tính năng cho các ứng dụng riêng biệt. Oracle Application Server 10g được cung cấp với ba phiên bản: Java Edition (giá 5.000 USD tính trên một bộ vi xử lý hoặc 100 USD/một người sử dụng), Standard Edition (10.000 USD/bộ vi xử lý hoặc 200 USD/người sử dụng) và Enterprise Edition (20.000 USD/bộ vi xử lý hoặc 400 USD/một người sử dụng).

Trong khi đó, Sun Microsystems gần đây tung ra một mô hình dịch vụ với cách tiếp cận khác. Họ gọi đây là cơ chế thu tiền tính theo người sử dụng đầu tiên áp dụng đối với kiến trúc ĐTML. Với chi phí khởi điểm là 1 USD/bộ xử lý/giờ, dịch vụ tính toán theo lưới này của Sun được cung cấp theo từng gói tính bằng tiếng đồng hồ. Sun khẳng định mô hình này có thể cho phép khách hàng khai thác sức mạnh tính toán giống như sử dụng các tiện ích thông thường như điện thoại, điện gia dụng hay nước…từ hạ tầng của nhà cung cấp dịch vụ.