#130 - Pinterest xây dựng hệ thống tìm kiếm thông minh như thế nào?
Để nhóm biên tập có thể nhiều phản hồi trực tiếp từ bạn đọc, nhóm biên tập xin mời các bạn đọc cùng tham gia vào nhóm Facebook dành riêng cho Newsletter Subscriber: https://www.facebook.com/groups/300419931101401. Các bạn có thể đưa ra góp ý, ý tưởng cải thiện, phản hồi cho chất lượng newsletter … trực tiếp cho nhóm biên tập. Hy vọng sẽ nhận được nhiều đóng góp từ các bạn đọc để chất lượng của Newsletter ngày càng hoàn thiện hơn.
- Nhóm biên tập Grokking Newsletter
Những bài viết hay
Building a universal search system for Pinterest — medium.com
Khi sử dụng Pinterest để tìm kiếm nội dung, chúng ta có thể dùng bộ lọc để hiển thị nội dung theo ý ta muốn. Đội ngũ kỹ sư tại Pinterest đã xây dựng một hệ thống có khả năng dự đoán được nội dung mà người dùng muốn tìm kiếm, từ đó cải thiện trải nghiệm của người dùng (UX).
Có 3 thành phần chính trong trong hệ thống này:
Query understanding: chịu trách nhiệm xác định mục đích của người dùng (vertical intent) dựa trên lịch sử các query tokens cũng như lịch sử quan tâm của họ. Các vertical intent này được chia thành nhiều phần nhỏ ví dụ như Pin Vertical, Video Vertical, Shopping,..
Query planning: chịu trách nhiệm gửi request đến những vertical intent cụ thể, dựa trên những dự định đã được xác định của người dùng. Bên cạnh đó nó còn gửi request đến những vertical intent ngẫu nhiên khác để sinh ra dữ liệu training cho machine learning.
Blending: Chịu trách nhiệm cho việc hợp nhất các kết quả trả về từ các vertical intent thành những kết quả tìm kiếm chính thức.
Static Analysis at Scale: An Instagram Story — instagram-engineering.com
Tại Instagram, các đội ngũ kỹ sư phần lớn dùng Python cho hệ thống backend của họ. Hàng ngày, Instagram có tới hàng trăm commits được đẩy lên production với một tiêu chí là sẽ không tốn quá 1 tiếng đồng hồ kể từ khi commit được land trên master tới lúc commit được xuất hiện trên hệ thống production. Do đó, việc phân tích chương trình để tìm ra bugs hoặc anti-patterns ở mỗi commit phải được thực hiện một cách nhanh chóng để đội ngũ kỹ sư đạt được hiệu quả cao trong công việc.
Instagram đã dùng tới static analysis để tự động hóa việc kiểm tra code và sửa code từ những lint rules họ tạo ra. Để đạt sự thành công lớn trong việc phân tích code, các kỹ sư ở Instagram đã dùng Abstract Syntax Tree (AST) và Concrete Syntax Tree (CST) của Python để tạo nên LibCST, một tool để phân tích code một cách nhanh chóng và dễ dàng hơn từ việc kết hợp AST và CST. Để scale một cách hiệu quả, LibCST đã sử dụng visitor pattern cho việc đi qua từng node ở syntax tree. Do Instagram phải thi hành rất nhiều lint rules cùng một lúc cho mỗi commit, họ đã lấy cảm hứng từ JavaScript ESLint để tạo ra một hệ thống đăng ký visitor (centralized visitor registry) cho việc tối ưu hóa việc phân tích code từ nhiều lint rules. Thay vì phải chạy qua hết syntax tree cho mỗi lint rule cho tất cả code ở commit đó, họ chỉ cần chạy qua syntax tree một lần và áp dụng lint rule cho từng node dựa vào thông tin từ centralized visitor registry.
Bài viết sau đây của một kỹ sư ở Instagram sẽ nói cụ thể hơn cách mà họ scale static analysis như thế nào để có thể chạy một số lớn lint rules và codemods trên một lượng lớn Python monolithic codebase.
Why You Shouldn’t Use OFFSET and LIMIT For Your Pagination — medium.com
Khi dữ liệu nhiều lên, phân trang (pagination) là một giải pháp để cải thiện tốc độ. Nếu là backend developer trong một thời gian, có lẽ bạn đã thực hiện các truy vấn phân trang kiểu như thế này:
SELECT * FROM table_name LIMIT 10 OFFSET 40
Tuy nhiên, việc dùng LIMIT và OFFSET cũng gây ra vấn đề performance. Cụ thể ở ví dụ bên trên, để hiện dữ liệu từ vị trí 40 đến 50, bạn cần load cả 50 row lên memory. Bạn có thể thấy nếu OFFSET càng lớn, performance càng kém.
Bài viết sau, tác giả Ivo Pereira giới thiệu hướng tiếp cận phân trang dựa trên con trỏ - Cursor based pagination - để khắc phục vấn đề performance của LIMIT + OFFSET.
SELECT * FROM table_name WHERE id>40 LIMIT 10
Software Architect: Bad practices software architecture — kipalog.com
Bài viết sau đây của bạn Minh Monmen trên kipalog nói về những thói quen xấu mà một Software Architect thường gặp phải, đặc biệt là khi hệ thống được làm ra không có hợp với nhu cầu hiện tại của doanh nghiệp
Software Architecture Rule of Thumb — Failing to Think about Failure — medium.com
Có bao giờ bạn rơi vào trường hợp hệ thống bị lỗi chưa biết nguyên nhân. Bạn thì đang hì hục debug, phân tích, khách hàng thì réo, sếp thì liên tục hỏi, còn vài "thằng đệ" ngồi sau xem sự nghiêm trọng của Failure. Lúc này bạn mới thật sự hiểu được tầm quan trọng của "Think about failure" khi thiết kế hệ thống.
Bất kể bạn có thiết kế hệ thống tốt cỡ nào, hay bỏ công sức và thời gian để phòng ngừa lỗi ra sao, một thực tế rằng lỗi vẫn sẽ xảy ra, nó có thể đến từ người dùng cuối, tích hợp hệ thống, hay lỗi data v.v. Bạn luôn phải tìm câu trả lời cho câu hỏi "sẽ như thế nào khi service/component này bị lỗi?" Bạn phải có kế hoạch và công cụ để khôi phục hệ thống cho trường hợp lỗi xảy ra.
Code & Tools
Góc Database
Trong các kỳ newsletter trước, chúng ta đã được biết rằng Google Big Query là một phiên bản dành cho công chúng trên nền tảng hệ thống Dremel của Google. Trong bài báo này, các bạn có thể tìm hiểu rõ hơn về cách Dremel được thiết kế cũng như những điểm tương đồng/khác biệt so với cách tiếp cận của MapReduce cho các bài toán phân tích dữ liệu lớn.
Tải bài báo ở đây: link.
Quotes
Knowledge is power
– Francis Bacon