Thứ Bảy, ngày 30 tháng 8 năm 2014

TL;DR - Quy trình thực thi một HTTP Request

Bài này muốn đề cập về trình tự các bước xử lý request được thực hiện bởi trình duyệt, web server thông qua đường truyền mạng. Lưu ý rằng, trình tự này có thể thêm hoặc thay đổi tuỳ vào cách hiện thực và tối ưu của từng trình duyệt.

OK. Đây là bài theo tiêu chí "dài quá không đọc" (Too Long, Didn't Read), nên tôi sẽ bắt đầu bằng biểu đồ sau:


Bạn chỉ cần nhìn qua là hiểu rồi nhỉ? Vậy là bài này có thể kết thúc ở đây...

Nhưng... Tôi muốn đề cập nhiều hơn một xíu về biểu đồ thời gian thực thi này...

Biểu đồ trên là biểu đồ rút gọn lại trên trang định nghĩa của W3C: http://www.w3.org/TR/navigation-timing/. Và nó gồm 4 phần được tô 4 màu khác nhau.

Đầu tiên, khi bạn gõ URL lên thanh địa chỉ và Enter. Trình duyệt lập tức kiểm tra resource này tồn tại trong cache hay không, nếu có và nếu bản cache đó có các header thích hợp (ví dụ Expire, Cache-Control,...), thì trình duyệt sẽ trả resource đã cache đó, mà không thực hiện request lên server, giúp thời gian tải nhanh hơn.

Lưu ý rằng, trước bước kiểm tra cache thì có bước kiểm tra redirect. Nên nhớ rằng redirect ở đây ý đang muốn nói tới những resource đã được đánh dấu với code 302 Moved Permanently. Và tất nhiên việc redirect này cũng thực hiện cấp kỳ mà không gửi thông tin lên server.

Bước 2, với URL đã được cung cấp, trình duyệt sẽ phân tích ra {schema, host, port} của resource. Dựa vào đó, nó sẽ phân giải tên miền ra địa chỉ IP. Thông thường các trình duyệt hiện đại sẽ lưu nhớ các địa chỉ nào sẽ được phân giải ra IP nào (nếu trước đó đã truy cập). Nếu không có sẵn, trình duyệt sẽ yêu cầu ISP phân giải DNS, quá trình này nhanh chậm phụ thuộc vào nhà cung cấp internet của bạn.

Một nguyên lý đơn giản là nếu trang web của bạn nổi tiếng, sẽ có nhiều máy chủ DNS của nhiều ISP cùng lưu giữ thông tin IP, như vậy quá trình phân giải DNS sẽ nhanh hơn nhiều.

Bước 3, sau khi có IP, tiếp theo là thực hiện "bắt tay 3 bước" trên TCP: SYN > SYN-ACK > ACK.


Nếu bạn muốn biết nó là cái gì, hãy thử tìm hiểu thêm với từ khoá "three-way handshake". Tuy nhiên, báo cho bạn biết rằng bước này lần nào cũng thực hiện cho mỗi lần request, và tốc độ nhanh chậm tuỳ thuộc vào khoảng cách của trình duyệt của mình với server. Một tin buồn nữa là nếu URL là dạng HTTPS thì nó sẽ thực hiện thêm 2 lần khác tương tự như vậy nữa (hoặc chỉ có 1 lần nếu ta đã có cache trong SSL session).

Thêm một thông tin: Vì HTTPS lại cần chứng thực từ một server chứng thực tin cậy, nên còn thêm một tin buồn nữa là lần đầu truy cập thì trình duyệt sẽ đi lấy chứng thực, mà bước lấy chứng thực thì tương đương với một request mới hoàn toàn (đầy đủ các bước).

Và cuối cùng, trình duyệt sẽ thật sự gửi request lên server, và chờ nhận response.

Nếu bạn dùng các chương trình debug, bạn sẽ thấy thời gian request và response được tách ra làm 2. Nhưng thực ra trình duyệt không thể xác định được thời gian chính xác, mà họ tính rằng: thời gian request = từ lúc gửi request tới lúc nhận byte response đầu tiên, và tất nhiên response chỉ đơn giản là thời gian nhận byte đầu tiên tới byte cuối cùng. Như vậy, thời gian request sẽ tương đương với thời gian request đi trên đường truyền + thời gian server xử lý + thời gian response đi trên đường truyền.

---
Bạn nào có câu hỏi gì thì vui lòng comment nhé...

Thứ Năm, ngày 28 tháng 8 năm 2014

7 việc cần để bắt đầu với Big Data

Bài này với mục tiêu đưa ra vài tiêu chí để người đọc có thể tiếp cận vào lĩnh vực Big Data/Analytic (đọc thêm bài viết này để biết Big Data là gì).

Thứ nhất: Thu thập dữ liệu


Khoan hãy nói về các mục tiêu khác, việc đầu tiên là bạn phải thu thập dữ liệu cái đã. Công việc này nghe có vẻ dễ dàng nhưng cực kỳ quan trọng. Bản thân chữ "big data" có nghĩa đơn giản là dữ liệu lớn, do đó bạn cần phải có dữ liệu, mà phải là thật nhiều dữ liệu cơ. Việc thu thập dữ liệu sẽ ảnh hưởng tới thông tin mà bạn thu được sau này.

Tất nhiên, bạn không cần phải giữ toàn bộ dữ liệu trong một thời gian dài, nhưng bạn sẽ không biết bạn có thể có dữ liệu nào và cái nào mới cần thiết trước khi bạn bắt đầu thu thập dữ liệu. Một nguyên lý cơ bản là: Càng nhiều dữ liệu có ích, thì bạn có thể phân tích nhiều khía cạnh khác nhau của dữ liệu.

Rất may, chúng ta có được một "ông trùm" trong lĩnh vực lưu dữ liệu lớn và xử lý dữ liệu lớn này. Tên nó là Hadoop. Hoàn toàn nguồn mở. Lưu đủ thứ dữ liệu, từ dạng web server log, thông tin monitor,... đến email và tweet, từ có cấu trúc đến không có cấu trúc,...

Một khi bạn bắt đầu với Hadoop, bạn sẽ gặp nhiều thành phần khác nữa, và bạn phải nghiên cứu nhiều. Nhưng đừng quên "ông trùm" Hadoop này là được.

Thứ hai: Gom dữ liệu thành nhóm theo logic


Khi có dữ liệu, hãy ngay lập tức tìm cách phân tích dữ liệu này, để xem thử chúng nó có liên quan gì với nhau. Nếu chúng nó có liên quan mật thiết, hãy gom thành một nhóm, đưa vào trong các bucket chung.

Một vài câu hỏi mà bạn có thể đặt ra: Dữ liệu nào có tiềm năng giúp ích cho business? Hay có thể phân tích và tìm ra các ưu thế cạnh tranh? Hoặc giúp bạn phục vụ khách hàng tốt hơn?... Sau khi phân nhóm và xếp độ ưu tiên, bạn sẽ dễ dàng nhận ra dữ liệu nào mà bạn muốn phân tích.

Một từ khoá mà bạn nên biết đó là Map Reduce. Hãy thử tìm hiểu về Map Reduce đi, nếu bạn còn lơ mơ về nó.

Thứ ba: Đừng vứt bỏ hệ thống hiện tại


Đây là suy nghĩ thường thấy của nhiều người, khi họ đọc và biết về hệ thống Big Data, họ choáng ngợp về khả năng của việc xử lý Big Data và về thông tin mà họ có được. Nó nhiều chiều hơn và đầy đủ tất cả thông tin mà họ cần. Tuy nhiên, thành thật mà nói thì nó không thể thay thế được các hệ thống đơn giản mà họ đã xây dựng trước đó, với một mục tiêu báo cáo doanh thu hay gì gì đó.

Thật khó để đưa ra một lý do thuyết phục vấn đề này, nhưng việc đó không quan trọng. Quan trọng là để hệ thống Big Data thay thế được hệ thống hiện tại, bạn phải tích hợp nó với hệ thống hiện tại, và việc này thực tế phải tốn thời gian và công sức rất nhiều. Nhưng lợi ích thì được cái gì? Vậy nên hãy duy trì hệ thống hiện tại và phát triển thêm hệ thống Big Data bên cạnh đó để phân tích, và chỉ dùng để phân tích những thứ mà hệ thống cũ không thể phân tích được mà thôi.

Thứ tư: Hãy nghĩ đến việc sử dụng cloud


Thay vì lo lắng và tính toán xem bạn sẽ xây dựng infrastructure thế nào cho phù hợp với việc xử lý và phân tích Big Data, hãy sử dụng các hệ thống cloud có sẵn các công cụ Map Reduce. Việc này sẽ tiết kiệm rất nhiều thời gian và công sức để setup, hơn nữa việc mở rộng lại dễ dàng.

Hiện nay, các hệ thống cloud lớn đều hỗ trợ sẵn Map Reduce mà Amazon Web Service và Google AppEngine là ví dụ.

Thứ năm: Tự cung cấp dịch vụ


Việc này là cực kỳ quan trọng đối với những người làm business, những người thật sự có được lợi ích lớn khi sử dụng Big Data. Hãy cung cấp cho họ một giao diện dễ sử dụng, hỗ trợ kéo thả, và tự họ có thể tuỳ biến các chiều và góc nhìn data.

Nếu bạn thấy lạ lẫm, hãy thử tìm hiểu về Pivot Table. Còn nếu bạn muốn sử dụng một công cụ hoàn chỉnh luôn thì luôn có Pentaho, Jasper, Tableau,... Phần lớn chúng có bản community (hoàn toàn free) để bạn xài thử, và cũng có bản Enterprise.

Thứ sáu: Hãy nghĩ về quản trị dữ liệu (data governance)


Bạn đang làm (hoặc nghĩ) về Big Data, điều chắc chắn rằng dữ liệu của bạn sẽ trở nên khổng lồ nhanh chóng, khi bắt đầu thực hiện chiến lược phân tích Big Data này. Bạn có 2 con đường để khắc phục vấn đề này: 1- Tiết kiệm dung lượng, bằng cách giảm trùng lắp, nén dữ liệu,... 2- Đầu tư vào thiết bị để nâng cao khả năng lưu trữ và xử lý của hệ thống. Và dù bạn chọn cách nào hoặc kết hợp cả hai, thì bạn cần phải suy tính càng sớm càng tốt.

Thông thường, với một sản phẩm bình thường, bạn sẽ tiếp cận theo hướng làm một bản thử nghiệm, ra được vài kết quả đầu tiên, và dùng nó để thuyết phục mọi người tiếp tục đầu tư. Hệ quả là sẽ tốn rất nhiều chi phí để chuyển đổi và thiết kế lại, hoặc là bạn phải chấp nhận sử dụng một hệ thống không hoàn hảo như mong đợi.

Cách tốt nhất nên là nghĩ về data governance ngay từ đầu, thuyết phục các bộ phận business và infrastructure để xây dựng hệ thống tốt, đáp ứng nhu cầu phân tích tối đa. Và thiết kế kiến trúc sao cho thích hợp và tiết kiệm nhất.

Thứ bảy: Đừng làm một mình


Đọc đến đây, chắc các bạn cũng hiểu vì sao không được làm một mình. Big Data là một vấn đề lớn, lợi ích không mang lại một sớm một chiều, mà cần có sự kiên nhẫn lâu dài, hướng tới mục tiêu lớn. Kết quả thu được lại phục vụ cho các mục đích kinh doanh, phân tích các vấn đề hiện tại, và định hướng tương lai của doanh nghiệp. Do đó, luôn cần một sự đồng bộ giữa các bộ phận.

Nếu bạn là start-up? Hãy cân nhắc kỹ việc tự xây dựng hệ thống của mình với việc sử dụng các phần mềm sẵn có. Đừng nghĩ rằng tự xây dựng thì giá sẽ rẻ hơn thuê/mua các phần mềm/dịch vụ sẵn có. Thực tế, chi phí để tự xây dựng sẽ lớn hơn nhiều.

Thứ Năm, ngày 14 tháng 8 năm 2014

Tùy chỉnh tiêu đề trên trang blogger

OK. Bạn có một trang blog trên blogger.com, với khá nhiều bài ở đó. Tuy nhiên, bạn sẽ thấy mỗi khi share lên Facebook, Google+,... thì tiêu đề của bài viết luôn có dạng là:

KimKha's Weblog: Tùy chỉnh tiêu đề trên trang blogger

Bạn cảm thấy rằng nó không được chuyên nghiệp cho lắm. Và nếu bạn rành các thủ thuật SEO, hẳn bạn cũng biết, tiêu đề là một nơi rất quan trọng để các search engine đánh index, nhưng việc để tên blog nằm choáng mất "chỗ tốt" thì không được thú vị cho lắm.

Bài viết này nhằm mục đích hướng dẫn cho bạn cách chỉnh tiêu đề (title) theo ý của bạn.


Cách thực hiện

Blogger là một trang viết blog khá mạnh mẽ, nó cho phép bạn chỉnh sửa nhiều thứ theo ý bạn. Nhất là khi bạn là một web developer. Tuy nhiên, thủ thuật dưới đây không cần bạn phải rành về web mới làm được, tất cả chỉ vài bước đơn giản:

Bước 1: Mở trang Blogger Dashboard, và nhấp vào link Template ở bên trái trang quản lý blog của bạn.

Lưu ý là hãy backup template lại, trước khi quậy tung nó lên. Bởi vì nếu không, bạn sẽ làm hư template hiện tại, và tốn nhiều công sức để phục hồi.

Bước 2: Nhấp vào nút Edit HTML

Bước 3: Tìm cụm này trong phần source code HTML:

<title><data:blog.pageTitle/></title>

Và thay bằng:

<b:if cond='data:blog.pageType == "index"'>
<title><data:blog.title/></title>
<b:else/>
<title><data:blog.pageName/> - <data:blog.title/></title>
</b:if>

Bước 4: Save Template và xong. Xong rồi... Giờ thì tiêu đề blog của bạn sẽ giống với của mình, dạng thế này:

Tùy chỉnh tiêu đề trên trang blogger - KimKha's Weblog

Tại sao bạn cần chỉnh lại tiêu đề?

Bạn có thể không làm, và giữ mặc định. Các trang blog thường để mặc định là tên blog trước tên bài viết, bởi vì điều đó thích hợp cho blog thuần tuý hơn. Tuy nhiên, ngày nay thì blog còn làm được nhiều thứ hơn là một trang nhật ký (weblogs), nhất là đối với blog chia sẻ về công nghệ của mình.

Một vài nguyên nhân cho việc chỉnh lại tiêu đề, mà mình nghĩ có ích:
  1. Dễ đọc hơn khi share lên Facebook, Google+,... và các trang mạng xã hội khác. Bởi người xem thường liếc qua tiêu đề, và nếu họ đọc được thông tin mà họ cần ngay từ đầu, khả năng cao là họ sẽ quan tâm và click vào xem.
  2. Thân thiện với các Search Engine (thuật ngữ chuyên ngành là SEF). Bởi vì các robot của search engine sẽ tìm từ khoá và đánh trọng số dựa trên tiêu đề và bài viết, trong đó tiêu đề thường đánh trọng số cao hơn. Hơn nữa, phần đầu của tiêu đề lại có phần cao trọng số hơn phần sau.
  3. Dễ nhận biết trên các tab trên các trình duyệt hiện nay. Nếu bạn để ý, thì các trình duyệt đều ghi tiêu đề lên tab, mà chiều rộng của tab thì nhỏ, bởi vậy nếu không đưa tiêu đề bài viết (nội dung đáng để chú ý) lên đầu thì có lẽ người dùng sẽ xao nhãng và quên mất cái tab chứa bài viết của mình.
  4. Lý do cuối cùng là vì... mình thích tuỳ biến. Blog của mình, theo phong cách của mình...

Chủ Nhật, ngày 27 tháng 7 năm 2014

Google Apps Script - những kinh nghiệm đầu tiên

Tôi biết về Google Apps Script được gần 6 tháng. Nhưng "biết" ở đây đúng nghĩa của từ "chỉ biết" mà thôi. Tuần trước tôi mới sử dụng nó.

Nó là cái gì? Là một sản phẩm của Google, muốn biết chi tiết thì đọc ở đây: https://developers.google.com/apps-script/

Giải thích ngắn gọn: Google đã có các sản phẩm như Google Docs, Spreadsheet, Calendar,... Giờ thì Google tạo ra Apps Script để có thể viết tương tác với các sản phẩm này một cách dễ dàng, hoặc thực hiện một hành vi tự động.

Ví dụ: Bạn có một file dữ liệu lớn trên Spreadsheet, bạn muốn nó tạo biểu đồ ngay khi bạn thêm dữ liệu vào đó. Còn nếu không thì mỗi lần thêm dữ liệu, bạn phải chọn chart hoặc pivot table các kiểu rồi chờ nó generate. Thêm một điểm lợi nữa là Apps Script cũng có thể gửi email đến sếp của bạn báo kết quả thay vì bạn phải export biểu đồ ra và gửi email.


Và sau đây là bài học tôi học được.

Bài toán: Tôi có một file gồm khoảng 30 sheet chứa dữ liệu, và tôi cần nó tổng hợp dữ liệu vào một sheet duy nhất để tôi có thể thấy tổng quát.

Theo bạn nghĩ tôi sẽ làm thế nào?

Phương án 1: Cứ viết script và chạy thôi. Tôi viết một script dài, công việc là đọc dữ liệu của từng sheet, tính toán và đưa và sheet Summary.

Quá đơn giản, và tôi hì hục viết. Xong. Chạy thử. Và chờ...

2 phút... Tôi đứng dậy lấy nước uống, rồi trở lại màn hình và... chờ...

Dữ liệu của tôi thật sự lớn, đến khoảng 300 row trong mỗi sheet, và có khoảng 30 sheet như vậy. Cuối cùng, nó cũng có phản hồi với tôi, và rằng "Exceeded maximum execution time".

Đọc thêm document, tôi biết rằng Apps Script bị giới hạn trong 5 phút xử lý. Phương án 1 bị bỏ.

Phương án 2: Theo hướng dẫn trên stackoverflow, tôi đưa trigger vào, và định khi xử lý 1 sheet xong thì đặt trigger để 1 phút sau chạy tiếp sheet tiếp theo, và cứ thế.

Viết xong, trông mọi thứ có vẻ hoàn hảo. Ngoại trừ việc nó có tạo trigger mà đến thời hạn thì trigger vẫn nằm sờ ra đó, không chịu chạy. Ặc ặc.

Lò dò mãi... tôi không tìm thấy cách nào cho nó chạy... Trước khi phát hiện ra trong document có ghi mà tôi không để ý rằng trigger có thể chạy trước hoặc sau thời gian ấn định 15 phút... Mình đang cần nó chạy ngay mà! Đâu có cần nó có khoảng delta thời gian thế!!! Dẹp. Không chơi với phương án 2 này nữa.

Phương án 3: Tôi để một link trên menu của Google Spreadsheet, để mình có thể chạy nhiều lần, mỗi lần xử lý cho 3 sheet, và khi nào chạy xong một lượt thì bấm lần nữa để chạy tiếp.

Phương án này cũng dễ làm, chỉ là mình đưa danh sách 30 sheet vào queue, và mỗi lần chạy là pop() trong queue ra từng sheet mà làm, khi nào nhắm sắp hết 5 phút thì ngừng lại, lưu trạng thái và để dành cho lần chạy kế.

Đây là một cheat khá hiệu quả mà tôi nghĩ ra, nó giúp cho tôi có thể xử lý hết 30 sheet mà không gặp trở ngại nào.

Điểm bất lợi duy nhất là... tôi không thấy nó tự động cho lắm, bởi tôi phải click, rồi chờ, rồi lại click, rồi lại chờ... Mệt mỏi luôn!

Phương án 4: Cố gắng cả buổi mới phát hiện ra Apps Script có hỗ trợ cái sidebar. Tôi quyết định đưa sidebar vào, và sidebar sẽ gọi lệnh lên server của Apps Script mà chạy cho từng sheet một.

Mô tả sơ bộ là khi khởi động sidebar, nó sẽ tạo cái queue các sheet cần chạy, và khi tôi bấm Run thì nó trình tự gọi lên server, hết sheet này đến sheet khác. Và đó là phương án cuối cùng của tôi, tôi cảm thấy hài lòng với phương án này.

Điểm yếu ư? Có 2 điểm yếu này:

Một là tôi phải để màn hình spreadsheet trên trình duyệt. Để nó có thể gọi liên tục lên server check trạng thái và để thực hiện sheet tiếp theo. Tuy nhiên, không hề gì cả, tôi có thể để nó chạy, và mở một tab khác để xem phim trong khi đợi. Tất nhiên, tôi code thêm một vài dòng để nó có thể resume khi tôi cần.

Hai là Google lâu lâu thì bị ngưng cấp phát resource để chạy, do cái sidebar gọi liên tục lên server Google nên nó... giận, không chạy nữa. Cách né cũng đơn giản là đợi một thời gian dài hơn trước khi gọi lên server, và đồng thời áp dụng cơ chế resume là có thể đảm bảo.

OK. Vài kinh nghiệm để share với bà con thôi. Cảm ơn mọi người.

Thứ Sáu, ngày 18 tháng 7 năm 2014

TL;DR - Khái niệm về ACID

ACID là viết tắt của 4 chữ Atomicity, Consistency, Isolation, và Durability. Đó là 4 thuộc tính quan trọng mà mỗi database đều phải đảm bảo nhằm bảo vệ tính toàn vẹn và chính xác của dữ liệu.

À, mà tôi không đề cập đến khái niệm acid trong ngành hoá học đâu nhé.

Vì tiêu chí bài viết là Dài quá không đọc (TLDR - Too long didn't read) nên tôi chỉ điểm qua một nét cơ bản thôi...



Atomicity (Tính nguyên tố): Ghi xuống 1 lô dữ liệu, thì kết quả sẽ hoặc là thành công hết, hoặc là thất bại hết. Không chấp nhận việc ghi xuống một nửa thì được, nửa còn lại bị lỗi. Kiểu như viết "anh yeu em nhieu" mà máy chỉ nhắn đi rằng "anh yeu em nhi", gặp trúng cô người yêu hay ghen thì sẽ bị vặn hỏi "em Nhi là em nào?"

Consistency (Tính nhất quán): Dữ liệu luôn luôn ở trạng thái hợp lệ. Không bao giờ để cho một giao dịch làm mất trạng thái hợp lệ. Hoặc là nó thành công và chuyển sang trạng thái hợp lệ mới, hoặc là trở về với trạng thái hợp lệ cũ.

Isolation (Tính tách biệt): Khi một giao dịch đang thực hiện chưa xong, thì nó cần phải tách biệt với hệ thống hiện tại.

Durability (Tính bền vững): Khi giao dịch hoàn tất, dữ liệu sẽ được đảm bảo ngay cả khi có hỏng hóc hoặc cháy nổ gì đó.

Vậy, chuyện gì sẽ xảy ra nếu...

Tính nguyên tố bị vi phạm? Như đã đề cập, dữ liệu bị thiếu và sẽ rối tung lên cho mà xem.

Tính nhất quán bị vi phạm? Bởi vì dữ liệu không còn hợp lệ nữa tức là đã bị sai, và mọi giao dịch tiếp theo sẽ chồng chất cái sai lên... Không thể tưởng tượng được nó như thế nào nữa...

Tính tách biệt bị vi phạm? Rất dễ xảy ra tình trạng đụng độ khi 2 thao tác khác nhau cùng diễn ra trên 1 dữ liệu. Và còn đau đầu hơn khi một thao tác bị lỗi và cần trả lại trạng thái ban đầu, khi đó, khó mà có thể rollback lại được.

Tính bền vững bị vi phạm? Đồng nghĩa với việc dữ liệu có thể bị mất. What the hell? Nếu thế thì cần database làm gì nữa...

Đó là 4 yếu tố cho sự phát triển của database. Sự khác nhau giữa các loại database chỉ là cách hiện thực và phương án ưu tiên yếu tố nào cao nhất mà thôi... :)

Thứ Bảy, ngày 14 tháng 12 năm 2013

Big Data là cái gì?

"Big data" ngày nay có thể xem là một thuật ngữ "thời thượng" của giới công nghệ, bên cạnh những thuật ngữ như "cloud", "web apps",... Thế nhưng, bạn có biết big data thật sự là thế nào?

Với tiêu chí "Dài quá không đọc" (TL;DR), tôi chỉ đề cập sơ sơ vài nét chính dưới dạng Q&A.


1. Ở đâu ra Big Data?


Tất nhiên là khi có nhiều người cùng tham gia tương tác trên các dịch vụ, thì dữ liệu của các dịch vụ này sẽ lớn.

Việc này đồng nghĩa với việc các trang web đưa tin truyền thống hay trang web giới thiệu công ty/sản phẩm ít khi được xem là Big Data, bởi vì data ở đó rất nhỏ bé.

2. Data lớn như thế nào mới gọi là Big Data?


Hãy nói về phương pháp đo độ lớn. Trong một bài viết như bài viết này, mỗi chữ cái chiếm 1byte, như vậy một bài tương đối dài sẽ chiếm khoảng 5KB (5*1024 byte). Nếu như một trang web có khoảng hơn 1000 bài thì data của trang web đó khoảng 5MB, đó là một con số khá lớn cho một trang blog hoặc tin tức.

Thông thường khi người ta đề cập tới Big Data, người ta thường nói tới data tới hàng Terabyte. Để dễ hình dung thì 5TB tương đương với hơn 1 tỷ bài theo cách tính của chúng ta. Đó quả thật là con số khổng lồ so với dung lượng RAM khoảng 16GB (phổ biến ở các server hiện nay).

Nói thêm về những "ông lớn" như Google hay Facebook thì dữ liệu của họ sẽ lớn tới mức phải tính bằng Petabyte hoặc hơn nữa...

3. Xử lý Big Data là thế nào?


Server thông thường chỉ có tối đa 16GB trên vùng RAM, và khi một người xem đọc một bài viết thì bài viết sẽ được server trả về từ RAM sẽ nhanh hơn rất nhiều so với trả về từ ổ đĩa.

Thế nhưng data thì có tới hàng trăm GB, do đó cần phải có một cơ chế caching thế nào cho việc truy xuất bài viết là nhanh nhất. Đó là mức thấp nhất của việc xử lý Big Data.

4. Tại sao phải quan tâm tới việc xử lý Big Data?

Xuất phát từ một nhu cầu cực kỳ có ý nghĩa kinh doanh: Phân tích (Analysis) và Báo cáo (Reporting).

Tại sao? Tại vì người ta muốn biết người xem muốn cái gì? Cái gì ở trang web hấp dẫn người ta nhất? Đâu là vị trí mà người xem dễ thấy nhất? Trang web của chúng ta có lỗi gì không? Và còn rất nhiều câu hỏi khác... Muốn trả lời được cần phải ghi lại các hành động của người xem và đem đi phân tích.

Tuy nhiên, dữ liệu về hành động của người xem thật sự là khổng lồ. Thực tế cho thấy thì khi trang web có lượng truy cập đồng thời chỉ 1000 người, thì dữ liệu access log đã ở mức 1GB/ngày. Như vậy một năm sẽ là 365GB. 365GB cho một dịch vụ "nhỏ" chỉ khoảng 1000 truy cập đồng thời đó cũng là một con số khá lớn rồi...

Đã vậy, mục tiêu lại phải trả lời những câu hỏi cực kỳ phức tạp như: "Cái gì ở trang web hấp dẫn người ta nhất?", như vậy cần phải tính toán và tổng hợp trên một dữ liệu khổng lồ kia, thì công việc sẽ phức tạp đến thế nào.

5. Sử dụng Database gì là thích hợp?


Nếu trang của bạn ít lượt truy cập hoặc không cần phân tích, hãy nghĩ một cách đơn giản và thiết thực: MySQL đã là đủ. Nếu bạn làm tốt, MySQL có thể chịu được data trên 10GB.

Nếu trang của bạn lớn, nhưng không cần phân tích, hoặc chỉ phân tích đơn giản, dữ liệu "nhỏ" ở mức khoảng dưới 1TB, tôi nghĩ những thứ NoSQL như MongoDB rất dễ tiếp cận và cũng hiệu quả.

Còn nếu dịch vụ của bạn cực kỳ lớn, số lượng user tới hàng triệu, phân tích chiến lược phức tạp,... lúc đó hãy nghĩ tới Big Data thật sự, nổi nhất hiện nay vẫn là Hadoop và một loạt công nghệ liên quan như HDFS, Hive, Pig,... Tất nhiên, chi phí để setup và làm quen với những thứ đó không phải là ít.

6. Cần phải chuẩn bị gì cho sân chơi Big Data?


Tất nhiên là bạn phải có dữ liệu cực lớn trước. Tuy nhiên, nhiều công ty đã có sẵn rồi và họ cần một đội ngũ để làm và hoàn thiện nó (như công ty của mình là một ví dụ).

Với cá nhân mỗi người, cái cần chuẩn bị là tư tưởng mở, sẵn sàng học hỏi và lao vào công việc bằng tất đam mê.

Tiếp theo, sân chơi này không phải dành cho tất cả mọi người, bạn chỉ nên tham gia khi bạn có nền tảng tốt về hệ thống, về kiến trúc phần mềm. Bạn cũng cần phải search bằng tiếng Anh và đọc hàng trăm trang tài liệu tiếng Anh mỗi ngày làm việc (bạn chỉ có thể làm khi bạn hiểu rõ về nó mà thôi).

Thêm một điều đặc biệt nữa là phải đọc code của người khác mỗi ngày, bởi có nhiều thứ không có tài liệu, cách duy nhất để bạn hiểu được đó là mở code của người ta mà đọc. Rất nhiều code opensource về big data này cho bạn, cái chính là bạn cần phải biết mình đọc cái gì và cần hiểu cái gì...

Và điều cuối cùng là: Phải thật sự cẩn thận. Nhiều khi chỉ vì bạn lỡ xóa một cái gì đó mà tất cả mọi công sức sẽ đem đổ sông đổ biển.

Kết luận


Big data thật sự đang là thứ challenge cho tất cả mọi người đam mê, và trở thành một trong những ngành hot nhất hiện nay. Trong tương lai xa nó vẫn sẽ hot, bởi vì lúc nào người kinh doanh cũng cần phân tích mà. Tuy nhiên, sân chơi này chỉ dành cho một số ít người thật sự có đam mê.

Chúng tôi đang tuyển...


Bạn nào muốn tham gia vào lĩnh vực này, có thể nộp đơn vào công ty GNT Vietnam của tôi.

Ngoài ra, các bạn có thể hỏi tôi nhiều hơn về Big Data trên Group mới lập: https://www.facebook.com/groups/ask.bigdata/ hoặc https://plus.google.com/communities/117413572964133445398 hoặc xem các bài trên Facebook của tôi: https://www.facebook.com/nkimkha (Nếu thích thì các bạn có thể Follow, đừng kết bạn)

Thông tin về tuyển dụng DBA (làm công việc liên quan tới Big Data)




Thứ Bảy, ngày 21 tháng 9 năm 2013

TLDR: Phân biệt OLAP và OLTP

OLAP và OLTP là hai công nghệ xử lý dữ liệu khác nhau và bù trừ nhau trong ngành IT "online" ngày nay. OLTP thì cực kỳ cần thiết và phổ biến, bạn sử dụng nó mỗi ngày. Trong khi OLAP lại được sử dụng khá rộng rãi trong giới quản lý/vận hành các công ty.

Nhưng khoan đã! Bạn đã biết 2 khái niệm này chưa?


Vài dòng định nghĩa


OTLP - viết tắt của OnLine Transaction Processing (Xử lý giao dịch trực tuyến). Gần hết các "giao dịch trực tuyến" đều dựa trên cái này. Từ việc bạn vào facebook, xem blog,... cho tới việc bạn mua hàng trực tuyến hay giao dịch ATM, đều được quy về chung khái niệm OLTP.

OLAP - viết tắt của OnLine Analytics Processing (Xử lý phân tích trực tuyến). Được định nghĩa là những thứ "trực tuyến" khác liên quan tới vấn đề phân tích và xử lý khối lượng lớn dữ liệu, giúp người quản lý/vận hành đưa ra các chiến lược kinh doanh hợp lý.

OK. Tạm thời tôi định nghĩa là vậy, bạn có thể tìm thêm trên net.

Vậy tại sao ta lại phải quan tâm? Suy cho cùng thì cũng là vấn đề lưu trữ dữ liệu. Với OLTP, người sử dụng cần nhanh chóng và chính xác đến từng giao dịch, nên cần một DB hữu hiệu cho việc này. Ngược lại, OLAP phục vụ người quản lý, vốn chỉ cần biết dữ liệu để thống kê và phân tích nên cần khối lượng lớn dữ liệu và quan hệ phức tạp, nhưng lại cần truy vấn nhanh ở dạng tổng quan, bởi vậy DB phải thiết kế tối ưu cho việc đó.

TLDR Comparison - Dành cho người không muốn đọc nhiều



OLTP OLAP
Ứng dụng Vận hành: ERP, CRM, ứng dụng truyền thống, tin tức, weblog, ... Hệ thống quản lý thông tin, Hệ thống hỗ trợ ra quyết định,...
Người dùng chủ yếu Người dùng, nhân viên Quản lý, điều hành
Phạm vi xử lý Hàng tuần/tháng Hàng năm
Mức độ làm mới Ngay tức thì Định kỳ
Mô hình dữ liệu Entity-relationship, hoặc thích thì có thể BigData, key-value,... Multi-dimensional
Schema Normalized (Chuẩn hoá dữ liệu) Star hoặc snowflake
Nhấn mạnh Cập nhật Truy hồi thông tin
Số lượng người dùng Hàng ngàn tới hàng triệu Hàng trăm
Dung lượng ổ đĩa MB tới GB GB tới TB
Đo lường Số lượng giao dịch/người dùng đồng thời Số lượng câu truy vấn và thời gian phản hồi


OK. Vài dòng tóm lược như vậy thôi, mọi người có thể tìm hiểu sâu hơn nếu quan tâm.

Điều cuối cùng


Đừng bao giờ xử lý OLAP trên DB theo mô hình của OLTP, bởi vì chúng thật sự không giống nhau. Tuy nhiên, bạn có thể làm thế nếu bạn chỉ muốn phân tích bài toán nhỏ và đơn giản. Trade-off thôi...

---------
Bài viết này dựa trên bài http://www.cbsolution.net/techniques/ontarget/olap_vs_oltp_what_makes và một số nguồn khác.