#233 - Tìm hiểu về Colossus, hệ thống lưu trữ phân tán của Google
Vào thứ 2 vừa Grokking phối hợp cùng Phòng thí nghiệm an ninh mạng, Khoa KH&KT Máy tính Trường ĐHBK TP HCM đã tổ chức thành công Techtalk #46 với chủ đề “Những bài học về xâm nhập và bảo vệ hệ thống mạng Việt Nam” do anh Dương Ngọc Thái trình bày. Với hơn 200 bạn tham gia, đã có rất nhiều những thảo luận sôi nổi xung quanh chủ đề này.
Các bạn có thể xem lại slide bài talk tại đây.
Trong số này, chúng ta cùng tìm hiểu về:
The New Rules Of Data Quality.
Triển khai liên tục (CD) trong Distributed System.
Tìm hiểu về Colossus, hệ thống lưu trữ phân tán của Google.
Lời giải bài Snapshot-Array.
John McCarthy, nhà khoa học máy tính người Mỹ và những đóng góp của ông trong lĩnh vực AI.
Ngoài ra các bạn vẫn có thể tiếp tục đặt mua ấn phẩm Dijkstra tập 2 tại đây.
P/S: Tuần này quá bận, nên vẫn là gửi trễ 1 chút. Mong các bạn độc giả thông cảm!
Những bài viết hay
(by steven.do)
Vài năm trước đây, các team data đã áp dụng các phương pháp như unit test để phát hiện các vấn đề liên quan đến data quality. Khi nhu cầu sử dụng và khai thác data của các cônócg ty ngày càng gia tăng, và các data pipeline ngày càng trở nên phức tạp, thì cách tiếp cận theo hướng single point-of-failure này không thể đáp ứng được.
Kiểm tra chất lượng của data là điều bắt buộc phải làm, nhằm phát hiện ra các vấn đề liên quan đến data mà có thể đã và đang xảy ra trên các data pipeline. Hiện tại đã có những công cụ tuyệt vời để hỗ trợ chúng ta làm điều này.
Trên thực tế, dù đã áp dụng kiểm thử tự động (automated testing), chúng ta cũng vẫn cần phải liên tục cập nhật và nâng cấp bộ test case hiện có, nhằm đáp ứng với những thay đổi và phát triển của data. Theo thời gian quá trình này sẽ càng trở nên tẻ nhạt, tốn thời gian, và càng gia tăng technical debt cần phải xử lý về sau.
Có 2 loại vấn đề chính liên quan đến data quality:
Những vấn đề có thể dễ dàng dự đoán trước được (đã biết trước được ẩn số - known unknowns). Đối với những vấn đề dạng này, có thể áp dụng automated data test và thiết lập các ngưỡng cảnh báo nhằm phát hiện và xử lý.
Những vấn đề không dễ dàng để dự đoán trước được (ẩn số không xác định - unknown unknowns) và khi data pipeline càng trở nên phức tạp thì các vấn đề này sẽ càng phát sinh thêm.
Các data team có thể track được các vấn đề có thể dự đoán trước được (known unknowns) và tiến hành test, nhưng vẫn chưa có một cách tiếp cận toàn diện nào để xử lý được những trường hợp vấn đề ngoài dự đoán (unknown unknowns).
Những vấn đề ngoài dự đoán (hay các vấn đề liên quan đến data quality mà chúng ta đã không có cách nào dự đoán trước được) thường không tự bộc lộ cho đến khi chúng gây ra tác động đến các downstream system. Và đến thời điểm này, các thiệt hại đã xảy ra với tổ chức và chúng ta hoàn toàn bị động. Các vấn đề phát sinh ngoài dự đoán có thể bao gồm:
Data phân phối bất thường trong 1 field dữ liệu quan trọng và khiến cho kết quả trên dashboard sai lệch.
Một team khác đã thay đổi JSON Schema từ 6 column thành 600 column.
Các thay đổi ngoài ý muốn liên quan đến quá trình ETL dẫn đến các test cases không bắt được.
Dữ liệu không hoàn chỉnh hoặc đã cũ không được chú ý đến dẫn đến sai lệch kết quả.
Code thay đổi dẫn đến API ngừng việc thu thập dữ liệu để cung cấp cho một product mới quan trọng.
Data drift (Data sai lệch) theo thời gian có thể là một thách thức trong việc phát hiện ra vấn đề, đặc biệt khi mà các test cases chỉ tập trung xem xét dựa trên data được ghi vào thời điểm các job ETL hoạt động mà không tính đến các dữ liệu đã tồn tại trước đó trong 1 table nhất định.
Thông qua bài viết tác giả đã gợi ý hướng tiếp cận mà một vài team data đã áp dụng nhằm giải quyết một cách toàn diện cả 2 nhóm vấn đề trên quy mô lớn.
Surviving continuous deployment in distributed systems
(by nghialuu)
Continuous Deployment (triển khai liên tục) là mỗi commit khi pass được test sẽ được triển khai lên production một cách tự động. Continuous deployment giúp tăng tốc độ triển khai của sản phẩm lên production, giảm thời gian feedback từ người dùng cuối, giảm rủi ro mỗi lần triển khai, và nhiều lợi ích khác. Tuy nhiên, việc áp dụng phong cách 1 commit - 1 deploy này đòi hỏi một cách tiếp cận vấn đề riêng, thay đổi tư duy khác với cách làm truyền thống, để đảm bảo không phá hỏng hay phát sinh lỗi production và giữ được niềm tin từ các stakeholder và người dùng. Bài viết tổng hợp những nguyên tắc cần thiết để áp dụng continuous deployment một cách an toàn:
Thay đổi mindset trong planning: với mỗi commit là một deploy, giờ chúng ta phải lên kế hoạch cho thứ tự development từ đầu thay vì thứ tự deployment như cách truyền thống. Có thể sử dụng vài kĩ thuật hỗ trợ để đơn giản hoá việc này hơn.
Sử dụng feature toggle. Một feature nhất định có thể được kích hoạt hoặc không phụ thuộc vào một flag/toggle. Việc này giúp decouple thứ tự deployment với thứ tự triển khai.
Sử dụng kĩ thuật expand and contract, giúp cho phép việc thay đổi contract, breaking change, mà vẫn giữ nguyên tính năng hiện tại và không gây bất kì đứt gãy, gián đoạn nào
Riêng với việc thay đổi database, expand and contract nên được áp dụng với preemptive double write để giảm rủi ro và không làm mất data
Bài viết gốc có giải thích rõ hơn chi tiết, định nghĩa, ngữ cảnh áp dụng, và các trade off, và các kĩ thuật liên quan khác, mời các bạn cùng tham khảo thêm nhé.
Colossus under the hood: a peek into Google’s scalable storage system
(by nhij)
Google sử dụng một hệ thống lưu trữ dữ liệu chung cho Google Cloud và tất cả các sản phẩm khác như Youtube, Drive hay Gmail. Để lưu trữ và xử lý được lượng dữ liệu khổng lồ sinh ra hàng ngày từ các sản phẩm này đòi hỏi hệ thống file phía sau phải hoạt động một cách hiệu quả. Trong bài viết này, các tác giả chỉ ra ba thành phần chính trong một hạ tầng cơ sở của hệ thống lưu trữ này bao gồm:
Colossus: cluster-level file system, kế nhiệm của Google File System (GFS)
Spanner: global-consistent, scalable relation database
Borg: scalable job scheduler phục vụ toàn bộ các task từ dịch vụ tính toán tới dịch vụ lưu trữ.
Ba thành phần cốt lỗi này là nền tảng của hạ tầng dịch vụ lưu trữ của Google Cloud, từ Firestore tới Cloud SQL tới Filestore và Cloud Storage. Để hiểu rõ hơn cách Colosuss hoạt động, ta sẽ điểm qua một số thông tin về hệ thống này:
Colossus là thế hệ tiếp theo của GFS
Được thiết kế để cải thiện khả năng mở rộng và tính khả dụng để xử lý lượng dữ liệu khổng lồ sinh ra từ các ứng dụng.
Colossus giới thiệu một distributed data model mới với khả năng mở rộng và tính khả dụng cao.
Trong kiến trúc của Colossus:
Client library là cách để các ứng dụng tương tác với Colossus. Đây là thành phần phức tạp nhất trong toàn bộ hệ thống. Người dùng có thể tùy chỉnh cấu hình theo nhu cầu với những chức năng được cung cấp sẵn từ thư viện này, ví dụ software RAID. Các ứng dụng xây dựng trên Colossus sử dụng đa dạng các kiểu encoding để tinh chỉnh trade off giữa hiệu năng và chi phí cho từng workload khác nhau.
Colossus Control Plane là một scalable metadata services bao gồm nhiều Curators. Client sẽ trao đổi trực tiếp với Curator để thực hiện các thao tác điều khiển, ví dụ như tạo file hoặc scale theo chiều ngang.
Metadata database của Colossus là BigTable. Bằng lữu trữ tất cả metadata của file system dùng cơ sở dữ liệu này, Colossus có thể scale up hơn 100 lần so với các cluster GFS lớn nhất.
“D” File Servers là cách network-attached disks giúp tối ưu chi phí của data flows.
Custodians là một background storage managers. Thành phần này đảm nhiệm vai trò tăng tính khả dụng và tính bền vững của dữ liệu cũng như độ hiệu quả chung của toàn hệ thống.
Ngoài các thành phần chính của Colossus, trong bài này, tác giả cũng đề cập đến cách Colossus trở thành một scalable storage và những lợi ích mà hệ thống này mang đến cho người dùng.
News
Góc Lập Trình
Đề ra tuần này: Find Two Non-overlapping Sub-arrays Each With Target Sum
(by ndaadn)
Cho một mảng số nguyên arr và một số nguyên target.
Tìm 2 mảng con của mảng arr sao cho tổng của các phần tử trong mỗi mảng con này bằng target.
Trả về tổng độ dài nhỏ nhất của 2 mảng con đó (có khả năng có nhiều hơn 2 mảng con có tổng các phần tử bằng target, vậy nên cần tìm 2 mảng con có số phần tử ít nhất)
Ví dụ:
Input: arr = [7,3,4,7], target = 7
Output: 2
Giải thích: các mảng con thỏa mãn là ([7], [3,4] và[7]), tuy nhiên ta sẽ chọn mảng con thứ nhất và thứ 3 vì chúng có tổng số phần tử ít nhất.
Lời giải đề bài tuần trước: Snapshot Array
by (ndaadn)
Yêu cầu của bài toán khá rõ ràng, ta có thể nghĩ ngay đến hướng cài đặt lưu dữ liệu vào một mảng, với mỗi lần hàm snap được gọi, ta lưu lại mảng hiện tại và tiếp tục thực hiện các thao tác get, set trên mảng mới. Đó là hướng suy nghĩ lưu snapshot toàn bộ mảng dữ liệu, ngoài ra ta còn có cách giải quyết khác, đó là lưu snapshot theo từng ô của mảng dữ liệu. Dưới đây là 2 cách cài đặt tương ứng bằng ngôn ngữ Java như sau.
1. Lưu snapshot toàn bộ dữ liệu: để tiết kiệm bộ nhớ lưu trữ, ta có thể sử dụng HashMap thay cho mảng thông thường. Mỗi khi cần lưu lại snapshot, ta khởi tạo một HashMap mới, copy và lưu lại toàn bộ giá trị HashMap hiện tại.
Với cách cài đặt này, ta có 2 tham số cần quan tâm khi phân tích độ phức tạp
- length: độ dài của mảng, giả sử gọi là N
- S: số lần gọi hàm snap.
Như vậy trong trường hợp xấu nhất, độ phức tạp thuật toán và không gian của cách cài đặt trên như sau.
+ Hàm void set: độ phức tạp thuật toán O(1).
+ Hàm int snap: độ phức tạp thuật toán O(N).
+ Hàm int get: độ phức tạp thuật toán: O(1).
+ Độ phức tạp không gian của cài đặt: O(N*S).
2. Lưu snapshot từng ô của mảng dữ liệu: thay vì lưu snapshot toàn bộ dữ liệu, ta chỉ cần lưu snapshot của từng ô (phần tử) của cấu trúc dữ liệu ban đầu, mỗi ô chứa thông tin các cặp <snap_id, value>.
Với cách cài đặt này, nếu gọi N là số lần hàm snap được gọi, thì độ phức tạp thuật toán và không gian như sau.
+ Hàm void set: độ phức tạp thuật toán O(log(N)).
+ Hàm int snap: độ phức tạp thuật toán O(1).
+ Hàm int get: độ phức tạp thuật toán: O(log(N)).
+ Độ phức tạp không gian của cài đặt: O(N).
Code & Tools
Anchors, Aliases và Extensions: Sử dụng các Docker Compose file là một cách hữu ích để cấu hình và định nghĩa các containers và services hoạt động cùng nhau. Tuy nhiên, chúng ta có thể dễ dàng tạo ra một file với nhiều code bị lặp đi lặp lại bởi nhiều services hoặc cấu hình tương tự. Bạn của thể tránh những trùng lặp này (Don't Repeat Yourself - DRY) bằng cách tận dụng tính năng aliases và anchors của YAML cũng như các trường mở rộng (extensions) trong Docker Compose file.
https://visbug.web.app/: Một công cụ hữu ích dành cho Web Developer.
History
Chúc mừng sinh nhật John McCarthy
John McCarthy sinh ngày 4 tháng 9 năm 1927 tại Boston và là một nhà khoa học máy tính người Mỹ. Ông là đồng tác giả của tài liệu đầu tiên giới thiệu khái niệm "trí tuệ nhân tạo". Ông giành được nhiều giải thưởng danh giá như giải thưởng Turing năm 1971 cho những đóng góp trong lĩnh vực AI. Ngoài ra ông còn có những đóng góp quan trọng khác về Sharing Time, LISP. Không chỉ dừng lại ở đó, ông cũng là một nhà triết học về trí tuệ nhân tạo. Truyện ngắn "The Robot and the Baby" của ông đã đi sâu khám phá câu hỏi liệu người máy có nên có (hoặc mô phỏng việc có) cảm xúc hay không. Ông mất vào ngày 24 tháng 10 năm 2011.
Các bạn có thể đọc bài viết sau để tìm hiểu kỹ hơn về cuộc đời và sự nghiệp của ông: https://www.wired.com/2011/10/john-mccarthy-father-of-ai-and-lisp-dies-at-84/
(by lpv)
Feedback
Bạn đánh giá nội dung số newsletter này thế nào?
(1 = Rất tệ / 5 = Rất tốt)
(Việc đánh giá của các bạn là rất quan trọng, sẽ giúp chúng tôi liên tục cải thiện nội dung newsletter tốt hơn)
Grokking mang lại cho các bạn những kiến thức mới mẻ và hữu ích thông qua:
Tech Talk: Là một hoạt động thường xuyên của Grokking từ những ngày đầu thành lập. Tại đây các diễn giả chia sẻ kiến thức xoay quanh Computer Science và Software Engineer. Các buổi Tech Talk đều được record và upload lên kênh youtube của Grokking.
Grokking Knowledge Graph: Tập hợp những nguồn kiến thức phong phú với hơn 1000 bài viết chọn lọc, các đầu sách, khóa học, v.v… Các bài viết đều được gán nhãn để giúp bạn đọc dễ dàng tìm kiếm.
Webinar: Là chương trình kết nối các kỹ sư Việt Nam và các kỹ sư đang làm việc tại các công ty công nghệ hàng đầu thế giới.
Dijkstra: Một ấn phẩm được xuất bản bởi các thành viên của Grokking. Với những bài viết đào sâu vào kỹ thuật và kiến thức khoa học máy tính.
Kipalog: Nền tảng chia sẻ kiến thức dành cho các lập trình viên.
Newsletter: Những bài viết hay về công nghệ sẽ được gửi tới bạn hàng tuần qua email.
Chúc các bạn sẽ tìm được nhiều điều mới mẻ khi đến với Grokking và xin hẹn gặp lại các bạn vào tuần sau.
Quotes
"Machines as simple as thermostats can be said to have beliefs, and having beliefs seems to be a characteristic of most machines capable of problem-solving performance." - John McCarthy