View profile

#146 - Xử lý dữ liệu lỗi trong Streaming System của Gojek

Revue
 
 

Grokking Newsletter

November 8 · Issue #147 · View online

Tuyển tập những bài viết hay cùng sự kiện bổ ích dành cho kĩ sư phần mềm tại Việt Nam.


Những bài viết hay
Handling Dead Letters in a Streaming System Handling Dead Letters in a Streaming System
A Complete Guide to React Rendering Behavior
3 CQRS Architectures that Every Software Architect Should Know
Comparing API Architectural Styles: SOAP vs REST vs GraphQL vs RPC
Góc Distributed System
Càng ngày các hệ thống phân tán càng tiến hoá theo chiều hướng dễ dàng tiếp cận hơn với người vận hành thông qua các công cụ hỗ trợ đắc lực và dễ sử dụng; trong khi vẫn duy trì được những đặc tính ưu việt của nó, đó là một mạng lưới các servers hoạt động một cách ổn định (reliability), dễ mở rộng (scalability) và luôn sẵn sàng (availability). Một trong những keyword chúng ta thường xuyên nghe thấy hiện nay là Overlay Network. Đây là lớp mạng lõi của các hệ thống phân tán giúp duy trì kết nối trao đổi thông tin một cách thông suốt và linh hoạt giữa các server, và hẳn nó đã tồn tại ngay từ những ngày sơ khai của các mạng phân tán. Tuy nhiên khái niệm Overlay Network chỉ thực sự trở nên phổ biến và thân thiện khi trào lưu Software Defined Network (SDN) phát triển. Có thể chúng ta đã nghe nhiều về keywork Overlay Network, nhưng bạn có thực sự hiểu nó là gì ?Về cơ bản, Overlay Network mô tả cách vận hành hệ thống network thông qua các phần mềm dễ tiếp cận với người lập trình (và vận hành) mà ẩn đi (omit) tất cả những sự phức tạp của công nghệ mạng ở phía dưới. Để hiểu kĩ hơn về Overlay Network, góc Distributed System lần này mời bạn tìm hiểu loạt bài viết dưới đây nhé.
Góc Database
Nếu bạn đã từng tìm hiểu về các thiết kế của các hệ thống database, hẳn bạn sẽ biết việc thiết kế các phương thức truy xuất dữ liệu (access methods) sẽ phụ thuộc nhiều vào phần cứng và yêu cầu tải (workload requirement).
Để đưa ra một cơ sở lý luận cho việc thiết kế các phương thức truy xuất dữ liệu ngày càng hiệu quả hơn trong tương lai, Manos Athanassoulis và nhóm tác giả đến từ Havard, IBM Research, EPFL và Facebook đã đưa ra một mô hình phân tích về tradeoff trong quá trình thiết kế các phương thức truy xuất dữ liệu.
Trước tiên, chúng ta hãy cùng làm quen một vài khái niệm:
Khái niệm overhead. Trong bài báo này các bạn sẽ nghe đề cập nhiều đến khái niệm overhead. Khái niệm này có thể hiểu một cách nôm na là sự lãng phí, trong ngữ cảnh của bài báo (và có thể nhiều ngữ cảnh khác) khái niệm này ám chỉ những chi phí phát sinh bên lề khi bạn thực thi một tác vụ nào đó.
Read overhead (RO) là chỉ số ám chỉ lượng dữ liệu dư thừa mà bạn phải đọc chỉ để lấy ra thông tin cần thiết. Ví dụ như bạn có một file có 500 dòng chứa thông tin học sinh của một khoa. Bạn muốn lấy thông tin của học sinh A ở dòng thứ 31. Tuy nhiên do hệ thống chỉ cho phép bạn đọc dữ liệu theo batch mỗi lần 30 dòng nên bạn phải tải hết dữ liệu từ dòng 31 đến dòng 60 lên bộ nhớ chỉ để lấy thông tin về dòng thứ 31. Trong ví dụ này, 29 dòng dữ liệu từ 32 đến 60 được xem là “read overhead”.
Update overhead (UO) là chỉ số ám chỉ lượng dữ liệu phải được cập nhật một cách không chủ đích chỉ để các dòng dữ liệu mà bạn muốn thay đổi. Tương tự ví dụ trên, bạn có thể hình dung nếu ta chỉ muốn cập nhật dữ liệu của dòng 31, tuy nhiên do giới hạn phần cứng buộc ta phải ghi 30 dòng một lúc thì 29 dòng dữ liệu được ghi kèm theo (mặc dù không có thay đổi gì) được xem là “update overhead”.
Memory overhead (MO) là chỉ số ám chỉ phần không gian bộ nhớ phải tiêu tốn chỉ để lưu trữ các dữ liệu dư thừa đi kèm phần dữ liệu chính muốn xử lý. Trong ví dụ trên, phần bộ nhớ dùng để lưu trữ 29 dòng dữ liệu kèm theo được xem là “memory overhead”.
Giống như động cơ vĩnh cửu vẫn đang là niềm mơ ước của các nhà khoa học vật lý, bài toán làm sao giảm thiểu hết mức ba loại chỉ số RO, UO, MO cũng được xem là thử thách mà các nhà khoa học máy tính đang không ngừng tìm kiếm giải pháp. Nhưng liệu chúng ta có thể tạo ra một giải pháp đồng thời đạt được cả ba không?
Nếu như định lý CAP (đã đề cập trong newsletter #137) trong hệ dữ liệu phân tán đã đưa ra giới hạn rằng trong một giải pháp thì chỉ có thể chọn hai trong ba yếu tố C-A-P mà không thể nào đạt được cả ba thì trong bài báo này các tác giả cũng đưa ra Phỏng đoán RUM tiên đoán rằng một phương thức truy cập chỉ có thể tối ưu được hai trong ba yếu tố RO, UO, MO nêu trên.
Mời các bạn cùng tham khảo bài báo được xuất bản vào năm 2016 trong khuôn khổ hội nghị Extending Database Technology (EDBT) để hiểu thêm về các phân tích của nhóm tác giả. Link bài báo.
Code & Tools
This week sponsor
Established in 2012, Chotot.com is the leading online classified website in Vietnam with more than 1,2 billion monthly page views, 10 million monthly users, 3,6 million transactions in 2019. With the motto “Muốn Là Có” (“A Way to Your Wants”), Chotot.com provides an effective online marketplace for Vietnamese to buy and sell various types of products easily. For more information, please visit www.chotot.com.
Góc tuyển dụng
ChoTot create product using a variety of open source and cloud native technologies, to name some: Kubernetes, Kafka, Elastic Search, PostgreSQL, MongoDB, TimescaleDB. We utilize Google Cloud Platform, such as Airflow, Argo, Data Catalog, Google AI Platform, Google BigQuery, Google Analytics, Superset for our infrastructure needs while running our heavy workloads on our own on-premises infrastructure. Visit careers.chotot.com to learn more about our vacancies and company culture.
Quotes
A language that doesn’t affect the way you think about programming is not worth knowing.
- Alan J. Perlis
Did you enjoy this issue?
If you don't want these updates anymore, please unsubscribe here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Powered by Revue
Charmington La Pointe, 181 Cao Thang, Dist 10, Ho Chi Minh city, Viet Nam