View profile

#222 - Tìm hiểu về Data Observability

Grokking Vietnam
Grokking Vietnam
Trong số này, chúng ta cùng tìm hiểu về:
  • Bài toán xử lý dữ liệu của Trivago
  • Cloudflare cải thiện tốc độ xây dựng DNS records lên hơn 4.000 lần
  • Tại sao không nên dùng JSON cho Configuration?
  • Data Observability là gì?
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 nhé.

Những bài viết hay
How we got on top of our data
(by quangle)
Trivago là công cụ tìm kiếm và so sánh giá với kho dữ liệu lên đến hơn 11 triệu khách sạn với các thông tin về địa điểm, độ uy tín, v.v. Trước đây, khi có event thay đổi từ stream, việc đọc toàn bộ dữ liệu, lưu vào memory trước khi khởi động hệ thống và cập nhật phải tốn đến 5 phút, dẫn đến những trải nghiệm không tốt cho người dùng. Đồng thời phát sinh nhiều bất cập khác về cấp phát resource, tính nhất quán khi sync dữ liệu và rất khó khăn khi scale.
Vậy các kỹ sự tại Trivago đã giải quyết bài toán trên thế nào? Thay vì tải data và lưu vào memory một lần như trước đó, họ quyết định tách biệt data khỏi logic để giúp hệ thống nhẹ hơn và dễ scale. Module data với sự kết hợp của Redis, Kafka và Hadoop. Những thay đổi về dữ liệu từ Hadoop sẽ được đẩy vào các topic tương ứng của Kafka. Từ Kafka, dữ liệu tiếp tục được consume thông qua Kafka Sink Connector và đồng bộ với Redis bằng Redis Sink Connector. Các thao tác đọc ghi từ hệ thống micro-services sẽ giao tiếp với Redis qua mô hình leader-follower.
Việc tái cấu trúc đã giúp tối ưu thời gian khởi động của hệ thống và có thể dễ dàng scale hơn. Để tìm hiểu chi tiết về hướng giải quyết, mời bạn đọc cùng tham khảo bài viết.
tech.trivago.com
How we improved DNS record build speed by more than 4,000x
(by lpv)
Với hơn 38 ngàn tỉ DNS query mỗi tháng, Cloudflare đang là một trong những nhà cung cấp dịch vụ DNS hàng đầu thế giới. Mạng lưới của họ trải dài trên 270 thành phố tại hơn 100 quốc gia. Theo thống kê của w3, hiện Cloudflare đang được sử dụng làm nhà cung cấp máy chủ DNS bởi hơn 15% trang web trên toàn thế giới.
Ngoài response time, DNS query còn có những metric quan trọng khác nhưng đôi khi chưa được chú ý. Cụ thể là DNS Record Propagation, đây là khoảng thời gian một thay đổi được gửi tới thông qua API sẽ được phản ánh qua DNS query response.
Cloudflare sử dụng một multi-stage pipeline cho phép khách hàng thay đổi DNS record và push chúng lên mạng lưới toàn cầu.
Các bước thực hiện được tóm tắt như sau:
  1. Khách hàng thay đổi record thông qua DNS Records API (hoặc UI).
  2. Thay đổi được lưu xuống cơ sở dữ liệu.
  3. Database event kích hoạt gửi một Kafka message tới Zone Builder.
  4. Zone Builder nhận message và đẩy dữ liệu vào Quicksilver, một cơ sở dữ liệu phân tán dạng Key-value.
  5. Quicksilver đưa các thông tin ra mạng lưới bên ngoài.
Trong thực tế, Cloudflare phải xử lý hàng ngàn request thay đổi DNS record mỗi giây, trong khi vẫn phải đảm bảo tính nhất quán với DNS query response. 
Trước đây, một trong những điểm thắt cổ chai trong mô hình này nằm ở Zone Builder. Zone Builder chịu trách nhiệm thu thập, tổ chức các record để ghi vào mạng lưới toàn cầu, và thường tiêu tốn thời gian nhiều nhất trong toàn bộ quá trình lan truyền thông tin (propagation), đặc biệt là với những khu vực lớn. Khi Cloudflare liên tục mở rộng quy mô, cần phải loại bỏ những điểm thắt cổ chai này trong hệ thống.
Mỗi mili giây cũng đều có giá trị quan trọng vì nó cho phép khách hàng nhanh chóng thay đổi cấu hình, giúp hệ thống nhanh hơn. Mặc dù đường truyền DNS của Cloudflare vốn dĩ đã rất nhanh, nhưng họ cũng đã xác định được một số cải tiến để cải thiện hiệu suất.
Zone Builder sẽ chỉ truy vấn từ cơ sở dữ liệu những record đã thay đổi, sau đó gửi những thông tin này đi. Tuy nhiên cách thực hiện lại không hề dễ dàng.
Trong bài viết này, tác giả giải thích cách cải tiến tốc độ cho DNS Record Propagation và các tác động của nó đối với khách hàng.
Mời các bạn cùng đọc và tìm hiểu.
blog.cloudflare.com
Why JSON isn't a Good Configuration Language
(by nhij)
JSON được sử dụng để viết cấu hình trong rất nhiều project, trong đó phổ biến nhất là tệp package.json được sử dụng bởi npm và yarn. Tuy nhiên, JSON thực sự không phải là một ngôn ngữ tốt để viết tệp cấu hình. Trong bài viết này, tác giả đã đề cập tới những vẫn đề của JSON khi sử dụng để viết các tệp cấu hình:
  • Không có hỗ trợ comment
  • Quá nghiêm ngặt
  • Không hỗ trợ multi-line strings
  • Thiếu sự hỗ trợ cho kiểu dữ liệu số
Ngoài ra, tác giả có đưa ra một số lựa chọn để thay thế JSON như TOML, HJSON, HOCON và YAML. Mời bạn đọc xem chi tiết các phân tích trong bài viết gốc.
www.lucidchart.com
Góc Data
What Is Data Observability? 5 Pillars You Need To Know
(by MS)
Observability không còn chỉ dành cho software engineering. Với sự gia tăng của thời gian ngừng hoạt động của dữ liệu (data downtime) và sự phức tạp ngày càng tăng của data stack, khả năng quan sát (Observability) cũng nổi lên như một mối quan tâm quan trọng đối với các data teams.
Observability đề cập đến việc giám sát, theo dõi và phân loại các sự cố để hạn chế downtime. Với sự phổ biến hơn của các hệ thế phân tán, observability engineering cũng ngày càng phát triển và đóng một vai trò quan trọng. Về cốt lõi, có ba yếu tố cần thiết cho Observability, đó là Metrics, Logs và Traces. 
Vậy trong ngữ cảnh của Data Engineering thì Data Observability bao gồm những gì? Trong bài viết, tác giả có đề cập đến 5 yếu tố quan trọng: 
  • Freshness: data được cập nhập và làm mới liên tục như thế nào. Điều này rất quan trọng khi đưa ra các quyết định về business. 
  • Distribution: chức năng thể hiện các giá trị có thể có của data, cho bạn biết liệu data của bạn có nằm trong phạm vi được chấp nhận hay không
  • Volume: đề cập đến tính đầy đủ của các bảng dữ liệu và cung cấp thông tin chi tiết về tình trạng của các nguồn dữ liệu
  • Schema: cấu trúc dữ liệu luôn luôn có thể thay đổi, việc theo dõi và quản lý cấu trúc dữ liệu giúp giảm thiểu broken data hoặc ảnh hưởng đến các downstream services
  • Lineage: Khi dữ liệu có vấn đề, câu hỏi đầu tiên luôn là “Ở đâu?” Data lineage cung cấp câu trả lời bằng cách cho bạn biết các nguồn upstream tạo ra dữ liệu, nguồn downstream bị tác động, cũng như team nào đang tạo dữ liệu và ai đang truy cập nó. Data Lineage cũng cho bạn cái nhìn tổng quát về việc dữ liệu được tạo ra và sử dụng như thế nào, từ nguồn nào đến nguồn nào. Qua đó, giúp bạn hiểu hơn về dữ liệu muốn dùng. 
www.montecarlodata.com
Góc Lập Trình
Đề ra tuần này: Fraction to Recurring Decimal
Cho hai số nguyên biểu thị tử số và mẫu số của một phân số, hãy trả về phân số ở định dạng chuỗi.
Ví dụ:
Input: numerator = 1, denominator = 2
Output: “0.5”
Lời giải đề bài tuần trước: Linked List Cycle II
(by ndaadn)
Bài toán yêu cầu xác định xem một Linked List cho trước có chu trình (vòng lặp) hay không và trả về phần tử bắt đầu của chu trình đó.
Đọc đề bài, ta có thể nghĩ ngay đến một giải thuật đơn giản đơn giản bằng cách duyệt qua toàn bộ Linked List, với mỗi phần tử, ta đưa phần tử đó vào một HashSet cho đến khi gặp phần tử lặp và trả về kết quả là phần tử đó, hoặc cho đến khi duyệt hết toàn bộ List và trả về kết quả null (List không có chu trình). Giải thuật này có độ phức tạp thời gian O(N), độ phức tạp không gian O(N). Tuy nhiên, đây vốn là một bài toán kinh điển, còn có tên gọi là “Bài toán thỏ và rùa của Floyd” (Floyd’s tortoise and hare). Giải thuật tối ưu cho bài toán này như sau:
  • Chúng ta bắt đầu ở phần tử đầu của Linked List bằng 2 con trỏ. Gọi tên 2 con trỏ này là slow và fast.
  • Di chuyển con trỏ slow qua từng phần tử của list. Di chuyển con trỏ fast nhanh gấp đôi con trỏ slow, tức là sẽ di chuyển qua mỗi 2 phần tử của list.
  • Nếu trong Linked List tồn tại một chu trình, 2 con trỏ này chắc chắn sẽ gặp nhau tại một phần tử nào đó.
  • Sau khi chu trình được phát hiện, tạo một con trỏ (tạm gọi là temp) khác bắt đầu từ phần tử đầu tiên của list.
  • Di chuyển con trỏ temp và con trỏ slow theo từng phần tử một. Phần tử nơi 2 con trỏ này gặp nhau chính là phần tử đầu tiên của chu trình trong Linked List đã cho.
Giải thuật được cài đặt như sau: https://pastebin.com/Vuyn78VL
Giải thuật có độ phức tạp thời gian O(N), không gian O(1). Bạn đọc có thể tham khảo thêm về bài toán, cũng như chứng minh giải thuật ở trang wiki sau: https://en.wikipedia.org/wiki/Cycle_detection
Code & Tools
  • Metriql: Một kho lưu trữ metrics mã nguồn mở cho phép các công ty xác định các metrics của họ dưới dạng code và chia sẻ chúng trên các công cụ dữ liệu và BI của họ một cách dễ dàng
Quotes
“Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.”
― Rick Cook, The Wizardry Compiled
Feedback
Bạn đánh giá nội dung số newsletter này thế nào?
(1 = Rất tệ / 5 = Rất tốt)
👎 1 ——-2 —— 3 —— 4 —— 5 👍
(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)
Did you enjoy this issue? Yes No
Grokking Vietnam
Grokking Vietnam

Cảm ơn bạn đã dành thời gian đọc newsletter kỳ này và chúng tôi hi vọng rằng bạn đã khám phá ra một số điều mới mẻ từ các bài viết trên. Các bạn có thể đọc lại các số cũ tại website newsletter.grokking.org

In order to unsubscribe, click here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Created with Revue by Twitter.
Viet Nam