#163 - Cách phòng ngừa double payments của Airbnb

Mar 22, 2021

Thân gửi các bạn đọc,

Nhằm mục đích hiểu thêm về trải nghiệm của bạn đọc cũng như lắng nghe các ý tưởng đóng góp làm sao để cải thiện chất lượng nội dung của newsletter, team Grokking Newsletter muốn làm một buổi phỏng vấn nho nhỏ với 4-5 bạn đọc thường xuyên.

Buổi phỏng vấn sẽ diễn ra online trong thời gian 1 tiếng.

Nếu bạn hứng thú tham gia vào buổi khảo sát này thì hãy điền thông tin của bạn vào form sau để nhóm liên lạc: https://forms.gle/Lp89tqXPVV24d4TX7.

P/S: Nhóm newsletter đồng thời sẽ trao tặng Jetbrain license key cho 2 bạn tham gia ngẫu nhiên sau buổi survey.

Những bài viết hay

Snowflake vs BigQuery — medium.com

Nhu cầu lưu trữ và quản lý data phục vụ mục đích phân tích đang ngày càng tăng, đặc biệt khi lượng data người dùng tăng lên chóng mặt và có nhiều doanh nghiệp chú trọng hơn vào data-driven business.

Google BigQuery và Snowflake là hai data warehouse khá phổ biến hiện nay trên thị trường. Trong bài viết, tác giả đi sâu về từng điểm mạnh của mỗi data warehouse kể trên, từ đó giúp chúng ta có đánh giá chi tiết và chính xác hơn để có được một sự lựa chọn phù hợp với mỗi tình huống yêu cầu khác nhau.

Những ưu điểm của Snowflake so với BigQuery:

UI dễ sử dụng và thân thiện với nhiều tính năng hỗ trợ người dùng hơn so với BigQuery
Tất cả các tác vụ đều có thể được viết bởi SQL, điều mà BigQuery không hỗ trợ với một vài tác vụ như drop hay rename 1 column trong table.
Snowflake hỗ trợ Multi-statement transactions, đảm bảo tính transaction với nhiều queries lên nhiều tables khác nhau.
Snowflake hỗ trợ caching giữa các user khác nhau, trong khi BigQuery chỉ hỗ trợ với 1 user.
Tính năng Zero-Copy cloning giúp dễ dàng copy data giữa các môi trường khác nhau mà không phát sinh chi phí lưu trữ
Thiết lập access control (security) dễ dàng và đơn giản hơn so với BigQuery
Snowflake hỗ trợ JDBC & ODBC drivers của riêng mình, trong khi BigQuery outsources cho bên thứ 3.

Những ưu điểm của BigQuery so với Snowflake:

Hỗ trợ phát triển Machine Learning rất tốt
Hỗ trợ real streaming, trong khi Snowflake chỉ hỗ trợ micro-batches streaming
Hỗ trợ query data từ các dịch vụ lưu trữ khác trong Google như Cloud SQL, Cloud Bigtable, Cloud Storage, Cloud Drive.
Dễ dàng replicate dữ liệu giữa các region khác nhau
Cung cấp các tuỳ chỉnh một cách đa dạng hơn như partition, clustering, ... phù hợp với các user-case khác nhau
Dễ dàng scale một query nhất định với khả năng scale resources trong GCP cho từng query
Lưu trữ dữ liệu cũ, ít sử dụng một cách rẻ hơn
BigQuery đã được tối ưu hóa và điều chỉnh trong nhiều năm sử dụng tại Google và nó chạy trên phần cứng tùy chỉnh của GCP để có hiệu năng tốt nhất, điều mà Snowflake không có được

Moving k8s communication to gRPC — blog.cloudflare.com

Từ gần 2 năm trước, CloudFlare đã bắt đầu migrate hệ thống của họ từ các thành phần monolith chạy trên bare metal và Mesos Marathon sang Kubernetes, giúp họ chia tách các module lớn ra thành các microservices dễ dàng hơn và còn đi kèm với nhiều công cụ cho phép triển khai giao tiếp giữa các services và traffic management.

Khi mới triển khai hệ thống trên Kubernetes, Cloudflare sử dụng REST API và Kafka để giao tiếp giữa các internal services. Tuy nhiên, trong quá trình scale hệ thống lên, các kĩ sư tại CloudFlare đã quyết định chuyển sang gRPC để tối ưu hóa việc communicate giữa các services, một trong những lợi điểm lớn nhất là:

gRPC abtract và chuẩn hóa các chi tiết để triển khai/quản lí việc gọi service đơn giản hơn bằng các công cụ code gen (khác với REST HTTP call khi triển khai đòi hỏi phải có HTTP path, request parameters và JSON schema... thống nhất ở client và server)
gRPC cũng có hiệu suất tốt hơn so với REST HTTP API: mặc định sử dụng HTTP/2, serialize/deserialize dữ liệu hiệu quả hơn qua cấu trúc nhị phân Protobuf.

Ngày nay, dữ liệu là một trong những tài nguyên cực kỳ quan trọng cho một công ty. Do đó, việc tìm kiếm dữ liệu (data discovery) sao cho hợp lý và cặn kẽ sẽ giúp các data scientists làm việc hiệu quả hơn. Bài viết sau đây được Shirshanka Das, principal staff engineer ở Linkedin, nói về quá trình tiến hóa của các hệ thống data discovery những năm gần đây thông qua 3 thế hệ chính. Trong mỗi thế hệ, tác giả giải thích các ưu điểm và nhược điểm của hệ thống data discovery ở thời điểm đó để các độc giả hiểu thêm về lý do tại sao một thế hệ mới được hình thành:

Thế hệ 1 - Monolith everything: Trong thế hệ đầu tiên này thì các siêu dữ liệu trong data storage hay logs sẽ được hệ thống data discovery kéo về (pull) để được xử lý và lưu trữ trong hệ thống. Nhờ đó mà các người dùng có thể truy cập hệ thống data discovery để tìm kiếm các siêu dữ liệu cần thiết. Thiết kế này khá là đơn giản nên việc xây dựng và bảo trì sẽ không quá phức tạp. Tuy nhiên, việc metadata được pull về hệ thống trong một thời điểm nhất định sẽ dẫn tới việc thường xuyên quá tải cho băng thông và load ở các nguồn dữ liệu (data sources). Đồng thời, các metadata đa phần sẽ khá cũ và không đáp ứng được nhu cầu real-time metadata. Một vài ví dụ điển hình cho thế hệ này là: Lyft Amundsen, Spotify Lexikon, Shopify Artifact, và Airbnb Dataportal
Thế hệ 2 - 3-tier app with a service API: Trong thế hệ thứ 2 này thì các siêu dữ liệu trong data storage sẽ được đẩy vào (push) hệ thống data discovery để khắc phục các hạn chế ở thế hệ 1. Việc đẩy siêu dữ liệu sẽ giúp load ở các data sources được trải đều hơn chứ không tập trung vào 1 thời gian nhất định. Đồng thời, metadata có thể đáp ứng được nhu cầu real-time một cách dễ dàng hơn. Tuy nhiên, hạn chế của các hệ thống ở thế hệ này là các siêu dữ liệu thường sẽ không có changelog dẫn tới việc debug hay revert nếu có chuyện gì xảy ra sẽ khó hơn. Không những thế, việc một team phải xây dựng và duy trì data model của hệ thống dẫn tới việc hạn chế về sự đa dạng cho những ứng dụng khác do các teams khác phải phụ thuộc vào nhân lực của team này cho việc hỗ trợ một use case mới. Một vài ví dụ điển hình cho thế hệ này là: Collibra, Marquez, và Alation
Thế hệ 3 - Event-sourced metadata: Đây là thế hệ mới nhất của các hệ thống data discovery gần đây. Ở thế hệ này, các changelog cho metadata sẽ được xem như là first-class citizen khi mà các dữ liệu được đưa vô hệ thống sẽ được lưu ở dạng changelog trước rồi mới chỉnh sửa dữ liệu. Đồng thời, các metadata sẽ được tách ra thành những domain nhất định như là user, group, dataset, … Nhờ đó mà các hạn chế ở thế hệ 2 được khắc phục. Tuy nhiên, hệ thống data discovery ở thế hệ này trở nên phức tạp hơn so với ở thế hệ đầu tiên. Do đó, các công ty nhỏ sẽ không có đủ nhân lực để xây dựng các hệ thống data discovery ở thế hệ này một cách dễ dàng. Một vài ví dụ điển hình cho thế hệ này là: Apache Atlas, Egeria, Uber Databook, và Linkedin DataHub

Góc Distributed System

Cách phòng ngừa double payments trong hệ thống thanh toán của Airbnb

Một trong những vấn đề mà các hệ thống thanh toán phải xử lý là data integrity của các giao dịch, ví dụ như một truy vấn xử lý thanh toán bắt buộc phải thực hiện thành công duy nhất một lần (at most once) dù cho truy vấn đó có thể được gọi nhiều lần. Trong bài toán này, tiêu chí quan trọng là tính idempotency của API. Ở airbnb giải pháp cho bài toán này cần phải đủ generic, độc lập, dễ ứng dụng để các services khác nhau có thể sử dụng dễ dàng. Các request tới phải được xác định (identity) và được theo dõi chi tiết trạng thái xử lý phía server. Airbnb đã xây dựng thư viện về idempotency có tên là Orpheus để xử lý vấn đề này. Orpheus kết hợp những yếu tố sau:

Generate idempotency key cho từng request
Dữ liệu luôn được đọc ghi vào master node của database được thiết kế sharding
Lỗi trả về được phân làm 2 loại: retry được hoặc không thể retry.
Transaction được chia thành 3 giai đoạn: pre-rpc, rpc và post-rpc để đảm bảo tính atomicity, với hai yêu cầu:

Trong giai đoạn pre-rpc và post-rpc, không tạo hoặc nhận truy vấn over network.
Trong giai đoạn rpc không được truy vấn database.

Trạng thái xử lý của từng truy vấn được phía server lưu trữ đầy đủ để phản hồi những truy vấn lặp lại (retry). Phía client cần lưu trữ và quản lý idempotency key và có cơ chế retry phù hợp.

Orpheus đã giúp Airbnb đạt 99.999 (five nines) đối với tính consistency của hệ thống thanh toán trong khi khối lượng giao dịch mỗi năm tăng lên gấp đôi so với năm trước. Cụ thể mời bạn đọc ở bài viết chi tiết ở đây

Góc Data Warehouse

Presto là một hệ thống phân tán mã nguồn mở được dùng để truy vấn song song các dữ liệu được chứa trong storage hay database bằng các câu lệnh SQL (open-source massive-parallel-processing distributed SQL engine). Presto được xây dựng chủ yếu để tập trung cho các tác vụ phân tích truy vấn tương tác (interactive analysis) mà cần độ trễ thấp (low latency). Hiện tại, Presto được sử dụng phổ biến ở các data warehouse lớn cùng với những hệ thống tương tự như là Spark SQL hay Apache Impala. Bài báo sau đây được các đội ngũ kỹ sư xây dựng Presto đăng trên hội nghị ICDE vào năm 2019 để nói về cách Presto được xây dựng và tối ưu hóa như thế nào ở các giai đoạn như là: query planning, query scheduling, query execution, resource management, …

Về mặt mô hình thiết kế của hệ thống thì Presto có 2 thành phần chính:

Coordinator: Bộ phận này có nhiệm là tiếp nhận các câu lệnh SQL từ người dùng và phân tích cú pháp để mà tạo ra và tối ưu hóa kế hoạch chạy câu lệnh SQL (thường được gọi là query planning). Một ví dụ về kỹ thuật được Presto áp dụng để tối ưu hóa query plan là: predicate pushdown khi mà các câu lệnh predicate/filter của SQL sẽ được đẩy xuống các tác vụ ở các leaf node của query plan để giảm dữ liệu được truy vấn càng sớm càng tốt. Để mà tận dụng các kỹ thuật tối ưu hóa khác thì Presto có các connectors cho việc truy vấn metadata từ các hệ thống storage để Presto hiểu rõ hơn về dữ liệu được cơ cấu như thế nào. Đồng thời, coordinator có nhiệm vụ dàn dựng và điều phối các tác vụ của query plan tới các workers trong một Presto cluster.
Worker: Bộ phận này có nhiệm vụ là chạy các tác vụ được giao cho từ coordinator. Thường một cluster sẽ có rất nhiều workers để chạy các tác vụ. Mỗi worker có thể được dùng cho nhiều tác vụ của các câu lệnh SQL khác nhau. Tuy nhiên, để đạt được độ trễ thấp thì Presto thường chứa dữ liệu của các tác vụ trên bộ nhớ khi xử lý hay là chuyển giao giữa các workers thay vì lưu trên đĩa, đặc biệt là các dữ liệu tạm giữa các stage của query plan.

Đây là link tới bài báo nếu các bạn muốn tìm hiểu thêm về chi tiết từng bộ phận và cách các đội ngũ kỹ sư Presto tối ưu hóa cho từng giai đoạn như thế nào.

Code & Tools

This Week Sponsors

Remitano là một trong các sàn giao dịch P2P năng động tại nhiều quốc gia, Remitano cung cấp thị trường uy tín, an toàn tối đa và đơn giản cho hoạt động mua bán tiền mã hóa của hàng triệu khách hàng, với sản phẩm đầu tư đa dạng, giao dịch tức thời và đội ngũ hỗ trợ 24/7 bao gồm các chuyên gia ngân hàng có nhiều kinh nghiệm trong các sản phẩm tài chính, tiền điện tử, và hệ thống thanh toán, đảm bảo mang đến trải nghiệm tốt với mức phí thấp nhất cho người dùng.

Quotes

"The trick is to fix the problem you have, rather than the problem you want."

- Bram Cohen