Cách Google quản lý dữ liệu của họ như

thế nào?
December 15, 2013 admin Tin khác

Với một lượng dữ liệu khổng lồ được xử lý từng giây

thì cách quản lý dữ liệu trong hệ thống của Google là
một phần hết sức quan trọng và khác biệt so với các
hệ thống nhỏ khác. Sau đây, chúng ta sẽ tìm hiểu cách
Google quản lý dữ liệu của họ như thế nào để đạt
được hiệu quả cao nhất.

Google servers

Trong thế giới hiện đại ngày nay, đằng sau mỗi thao tác đơn giản của chúng ta
trên thế giới mạng là cả một hệ thống đồ sộ đang vận hành. Từng giờ, từng
giây trên thế giới có hàng chục triệu người đang sử dụng dịch vụ của các hãng
công nghệ lớn trên thế giới như Google, Yahoo, Microsoft, Facebook..v.v.. Điều
này đòi hỏi sức mạnh từ của hàng ngàn bộ xử lý trên hàng ngàn server của
các hãng này. Chỉ tính riêng công việc trả về kết quả tìm kiếm mỗi khi người
dùng gõ từ khóa vào search box, Google dã phải vận hành hàng loạt server
đặt khắp thế giới, liên tục thực hiện thuật toán tìm kiếm cũng như sục sạo
khắp thế giới web để có được một bức tranh toàn cảnh sẵn sàng được sử dụng
để phục vụ người dùng một cách nhanh nhất. Với cường độ hoạt động 24/7,
365 ngày/ năm không có lấy một giây ngơi nghỉ, riêng việc phục vụ nhu cầu
tìm kiếm đã đòi hỏi các hệ thống của Google xử lý xấp xỉ 20 petabyte dữ liệu
mỗi ngày, một con số mà người bình thường khó có thể tưởng tượng ra nổi.
Ở tầm vóc này, mọi sai lầm dù là nhỏ nhất, dù là trong khâu thiết kế hay triển
khai cũng có tiềm năng gây hậu quả lâu dài. Mọi công việc từ bổ sung dung
lượng lưu trữ đến thay đổi đôi chút kết cấu cơ sở dữ liệu đều sẽ cần được
được cân nhắc kỹ lưỡng, và quan trọng nhất là cần một thiết kế hợp lý để
không làm ảnh hưởng đến hàng triệu người dùng đang “kêu gào” đòi hỏi ngoài
kia. Với hàng trăm ngàn người dùng đang online và hàng ngàn terabyte dữ liệu
được đọc/ghi ngay cả vào những thời điểm hệ thống đang được nâng cấp, các
giải pháp công nghệ đơn giản của các trung tâm dữ liệu thông thường sẽ khó
mà phù hợp cho quy mô này. Vậy rốt cuộc, những người khổng lồ công nghệ
này quản lý dữ liệu của mình như thế nào để đáp ứng nhu cầu ngày càng gia
tăng đó? Qua bài viết của Arcstechnica, chúng ta hãy cùng điểm qua một vài
giải pháp dễ hiểu nhất mà Google, Amazon và Microsoft sử dụng.

Google HDD Tech

Google File System (GFS)

Không lấy gì làm lạ khi Google là một trong những hãng đầu tiên phải đối mặt
với bài toán về lưu trữ khi xét đến số lượng người dùng mà hãng này phục vụ.
Lời giải được các kỹ sư của hãng đưa ra vào năm 2003 là hệ thống lưu trữ
phân tán, được tối ưu cho các dịch vụ mà Google cung cấp: Google File
System (GFS). Có thể nói GFS là xương sống cho hầu hết mọi dịch vụ mà
Google cung cấp. Hệ thống cơ sở dữ liệu người dùng đồ sộ, các dịch vụ điện
toán đám mây và lượng dữ liệu khổng lồ phục vụ việc tìm kiếm, tất cả đều
được quản lý dựa trên GFS.

Các chi tiết kỹ thuật GFS dĩ nhiên là được Google…giữ kín cho riêng mình,
nhưng chúng ta vẫn có thể hình dung ra phần nào cách hệ thống này vận
hành dựa trên những gì mà kỹ sư trưởng Howard Gobioff và Shun-Tak Leung
chia sẻ hồi năm 2003. Tiêu chí hoạt động của GFS có thể gói gọn trong một
câu: binh quý hồ…đa. Nói cách khác, với quy mô dữ liệu mà mình phải vận
hành, các kỹ sư thiết kế GFS coi trọng khả năng mở rộng hệ thống, tăng số
lượng server và ổ cứng thay vì đầu tư quá nhiều vào việc tạo ra các server hay
thiết bị lưu trữ chất lượng cao. Google muốn kết hợp các server cũng như thiết
bị lưu trữ rẻ và đơn giản thành một hệ thống với khả năng chịu lỗi cao nhất có
thể. Như thế nào ư? Hãy nhìn vào câu phát biểu sau đây.

Nói cụ thể ra một chút, với cường độ hoạt động mà người dùng và Google đòi
hỏi, các Server này sớm muộn cũng sẽ…ra đi. Và thiết kế của GFS được tạo ra
để bảo đảm rằng, dù có phải thường xuyên thay đổi các server trong hệ thống,
lượng dữ liệu bị mất đi vẫn sẽ được giữ ở mức tối thiểu. Trong các hệ thống
của mình, Google thường lưu trữ dữ liệu trên các file dung lượng cực lớn, và
các file này sẽ được đọc, ghi, sử dụng bởi rất nhiều ứng dụng tại cùng một
thời điểm. Vì vậy GFS còn cần một đặc tính nữa là khả năng cung cấp lượng
lớn dữ liệu ở tốc độ cao cho các ứng dụng này trong mọi thời điểm.

Có thể bạn muốn xem :

 Email Marketing : Bắt tay xây dựng Database (thông tin/cơ sở dữ liệu)
khách hàng ngay hôm nay
 Những dịch vụ chia sẻ tài liệu trực tuyến tốt nhất để làm marketing
 Cách sao lưu và đồng bộ dữ liệu VPS/Server bằng RSYNC thông qua SSH
Để đáp ứng được 2 yêu cầu kể trên (tốc độ và khả năng chịu lỗi), hiển nhiên
ta sẽ nghĩ ngay đến công nghệ RAID, và quả thực GFS hoạt động với cơ chế
tương tự. Các tập hợp, gói file dữ liệu với dung lượng được định sẵn sẽ được
rải đều trên một số cụm (cluster) server. Với cách tiếp cận như đã nêu: sử
dụng các phần cứng giá thành rẻ, lấy số lượng lớn để bù đắp cho hiệu năng;
sẽ là không ngoa khi nói các server này của Google “thăng” với tần suất khá
thường xuyên, nhưng số lượng dữ liệu bị mất vẫn luôn được giữ ở mức hết sức
tối thiểu.

Google servers data center

Tuy nói là “tương tự”, nhưng quả thực trừ việc tăng tốc độ truy xuất và khả
năng chịu lỗi, GFS khác rất nhiều so với RAID. Các server kể trên có thể nằm
trong các dải mạng khác nhau, có lúc thuộc cùng datacenter, có lúc thậm chí
còn không thuộc cùng một datacenter (tùy thuộc vào việc các file dữ liệu trên
đó phục vụ việc gì). Quy mô của hai công nghệ rất chênh lệch. Với quy môt
hoạt động của Google, khi nhắc đến “lưu trữ” thì ổ đĩa cứng là cách nghĩ quá
hạn hẹp.

Điều này còn được thể hiện trong cách nhìn nhận đơn vị dữ liệu. Trong GFS,
các kỹ sư chú trọng đến việc cung cấp dữ liệu theo từng khối cho việc xử lý, vì
vậy khả năng cho phép đọc lượng lớn dữ liệu ở tốc độ cao là quan trọng nhất,
còn tốc độ đọc hay ghi từng file vẫn chỉ được xếp vào hàng thứ yếu. Như các
kỹ sư đã nêu trong bài viết của mình “Việc thực hiện một thay đổi bất kỳ trên
từng file dĩ nhiên vẫn được hỗ trợ trong GFS, nhưng không được ưu tiên và
hiệu năng của việc này cũng không được chú trọng tối ưu”. Nói dễ hiểu hơn,
với quy mô của mình – GFS chủ yếu làm việc với dữ liệu theo từng khối, có thể
bao gồm hàng triệu file với dung lượng từ hàng trăm MB đến vài GB. Và bởi
các file dữ liệu này sẽ được rất nhiều ứng dụng sử dụng tại cùng một thời
điểm, một cơ chế chịu lỗi khác cũng được thiết kế để bảo đảm rẵng mối khi có
một thao tác ghi (write) xảy ra lỗi, dữ liệu sẽ có thể được rollback lại thời điểm
ngay trước đó mà không làm ảnh hưởng đến các ứng dụng khác. Làm được
điều này một cách chính xác mà không gây ảnh hưởng lớn đến hiệu năng là cả
một kỳ công.

GFS gồm ba lớp: các GFS client sẽ xử lý các yêu cầu truy xuất dữ liệu của các
ứng dụng; GFS master chuyên quản lý việc phân phối và theo dõi vị trí của các
khối dữ liệu trên các cụm server (mỗi cụm chứa cùng loại dữ liệu), cũng như
các file nằm trong đó (có thể nói dễ hiểu là các tiếp tân và một tay…thủ kho);
cuối cùng chính là các server. Ngày trước, khi mà mọi thứ còn “đơn giản”, mô
hình cơ bản sẽ là một master cho mỗi cụm server, các Client được đặt rải rác
khắp nơi có thể liên lạc với bất kỳ Master nào khi cần. Nhưng hiện nay với nhu
cầu ngày càng gia tăng của thế giới web, Google đã phải mở rộng mô hình
phát triển một hệ thống master mới chuyên để quản lý các master cấp dưới,
thông tin cụ thể về hệ thống này đáng tiếc lại chưa được hé lộ đầy đủ
 Google File System (GFS) Architecture

Khi GFS client nhận được yêu cầu về một file dữ liệu từ một ứng dụng nào đó,
nó sẽ gửi yêu cầu về thông tin vị trí của file này cho server master. Server
master sẽ cung cấp vị trí của một trong các server/cụm server có chứa file đó
(nhớ rằng các máy này đóng vai trò như các RAID trong hệ thống nhỏ mà ta
thường gặp). Nếu việc kết nối thành công, GFS Client sẽ làm việc trực tiếp với
server dữ liệu đó để lấy file, Master sẽ không tham gia vào quá trình giao tiếp
này trừ khi có lỗi xảy ra buộc Client phải quay lại “cầu cứu”.

Để đổi lại tốc độ cung cấp dữ liệu, các kỹ sư thiết kế GFS quyết định đánh đổi
một phần tính nhất quán (consistency) của hệ thống. Hệ thống vẫn chịu lỗi tốt,
vì như đã nói nếu có trục trặc trong quá trình ghi mọi thứ liên quan sẽ được
rollback, đồng thời Client có thể sẽ được cung cấp một địa chỉ lưu trữ khác để
tìm cách ghi dữ liệu đó lần nữa nếu trục trặc tiếp tục xảy ra. Nhưng do Master
không trực tiếp theo dõi quá trình trao đổi giữa Client và các server dữ liệu,
các thao tác “ghi” mà Client thực hiện trên một server sẽ không lập tức được
đồng bộ với các bản sao của nó trong cùng cụm đó. Giải pháp của Google cho
vấn đề này là “relaxed consistency model” (Tạm dịch: mô hình nhất quán
lỏng). Nói một cách đơn giản thì lý thuyết này cho rằng nếu nhu cầu đang cấp
thiết thì cung cấp cho Client địa chỉ của một server chứa dữ liệu hơi cũ cũng…
chẳng sao, miễn sao sau đó các thay đổi trên khối dữ liệu sẽ được đồng bộ
vào…một lúc nào đó. Theo từng chu kỳ, Master sẽ tìm kiếm thay đổi trên các
khối dữ liệu của các server (được quản lý theo “phiên bản” – version) và bảo
đảm việc đồng bộ được diễn ra thường xuyên nhất có thể mà vẫn không làm
Client phải chờ lâu. Nếu có một server dữ liệu nào đó tụt lại quá xa – ví dụ như
có quá nhiều khối dữ liệu cũ hoặc một khối nào đó quá cũ, Master sẽ bảo đảm
nó không được “giới thiệu” cho Client nữa đến khi được cập nhật bằng bạn
bằng bè.

Nhưng vẫn còn hai vấn đề, tại thời điểm Master phát hiện ra kẻ “tụt hậu” này,
các phiên làm việc của Client với nó vẫn tiếp diễn. Client sẽ không biết được
các dữ liệu trên đó là phiên bản cũ cho đến khi Master cập nhật cơ sở dữ liệu
của mình. Bản thân cơ sở dữ liệu này của Master cũng được sao lưu ra nhiều
nơi phòng khi Master hỏng, và không có Master thì các cụm server dữ liệu đó
sẽ trở nên vô dụng. Tuy nhiên các thay đổi mà Client thực hiện trên dữ liệu tại
thời điểm Master “thăng” cũng sẽ mất và gây ảnh hưởng đến tính nhất quán,
bất kể có backup thường xuyên thế nào đi chăng nữa. Một lần nữa điều này
được giải quyết bằng lý thuyết chứ không phải bằng một công nghệ đột phá gì
: đại đa số các dữ liệu phục vụ việc tìm kiếm không cần phải được cập nhật
mới với tốc độ quá khủng khiếp (đó cũng là lí do cho phát biểu ở trên : việc lấy
lượng lớn dữ liệu ra mới là quan trọng”), và các thay đổi thường là bổ sung dữ
liệu mới, chứ không phải thay thế dữ liệu cũ. Hai vấn đề cùng được giải quyết
chỉ bằng một lý luận ngắn gọn này, nhưng rốt cuộc điều đó chỉ đúng với bộ
máy tìm kiếm mà thôi.

Bigtable
 Google Bigtable

Như bạn đọc cũng đoán được, khi Google bổ sung các dịch vụ khác như
Youtube, Google Docs .v.v.. việc chỉ dựa vào một hệ thống quản lý dữ liệu
theo từng khối, lại không chú trọng tính nhất quán là hoàn toàn không phù
hợp. Để giải quyết vấn đề này, trên nền GFS hãng đã bổ sung Bigtable, công
nghệ quản lý dữ liệu có dạng như một cơ sở dữ liệu. Mọi thứ được quản lý
dưới dạng “bảng” (table) (cũng là lý do nhiều người coi BigTable có dạng như
cơ sở dữ liệu dù rằng nói chính xác thì không phải vậy). Với hàng tỷ (vâng,
hàng tỷ) webpage cần được lưu, các BigTable có tên hàng là các URL và các
đặc tính liên quan của webpage đó (keyword, ngôn ngữ.v.v. ) làm tên các cột.
Nội dung của trang đó sẽ được lưu vào các ô tương ứng với thông tin về thời
điểm ghi, phiên bản (timestamp). Về cơ bản, cách mà Bigtable xử lý dữ liệu
cũng vẫn khá giống GFS : ưu tiên việc đọc dữ liệu hơn và các thay đổi chủ yếu
được thực hiện dưới dạng bổ sung, đi kèm là một chỉ số “phiên bản” chứ
không trực tiếp thay đổi các dữ liệu cũ (kể cả là các dữ liệu cho dịch vụ dạng
Google Docs cũng được quản lý theo dạng này). Tuy vậy cách tổ chức dạng
bảng này cũng đủ khác biệt để giúp khắc phục các khó khăn trước đó mà
Google gặp phải khi mở rộng số lượng dịch vụ mà chỉ dựa vào GFS. Như chúng
ta đều thấy, các dịch vụ mail, video, calendar.v.v.. chúng ta đang sử dụng
ngày nay được cập nhật mới khá chính xác. Đi sâu hơn về chi tiết kỹ thuật,
Bigtable sẽ khá khó hiểu cho những ai không có nền tảng về cơ sở dữ liệu
cũng như hệ thống thông tin nói chúng, vì vậy chúng ta sẽ từ biệt Google ở
đây để chuẩn bị “nhòm ngó” Amazon và Microsoft trong các bài sắp tới.