• Yamha
  • Những gã khổng lồ công nghệ quản lý dữ liệu thế nào?

    09:1112/03/2013

    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, 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, hãy cùng tìm hiểu.

     Google, Yahoo, Microsoft, Facebook 

    Google File System

    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.

    Google, Yahoo, Microsoft, Facebook

    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.

    Để đá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, Yahoo, Microsoft, Facebook

    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ô 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, Yahoo, Microsoft, Facebook

    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, Yahoo, Microsoft, Facebook

    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, tạ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 Microsoft trong các bài sắp tới.

    Theo GenK





    Gửi nhận xét về bài viết:
    Họ tên:    Email:
    Nội dung:
    • DTTD