197 - GoJek dùng NLP đặt tên các điểm đón như thế nào?
197 - GoJek dùng NLP đặt tên các điểm đón như thế nào?
Trong số này, chúng ta sẽ cùng tìm hiểu về: Cách GoJek dùng NLP để đặt tên các điểm đón như thế nào; Cách Uber migrate dữ liệu từ DynamoDB tới Docstore; Các khó khăn gặp phải khi phát triển hệ thống Daily Executive Dashboard; Theo dõi khoá học U ndergraduate về Distributed Systems của Đại học Cambridge; Cơ chế Remote Compaction ở RocksDB; Thử thách lập trình tuần này về tìm đường đi ngắn nhất; và cuối cùng là cùng nghe về bài tech talk về Delta Lake với Apache Spark
Những bài viết hay
How Gojek Uses NLP to Name Pickup Locations
Khi khách hàng sử dụng dịch vụ đặt xe như GoRide và GoCar, họ được giới thiệu sẵn một vài điểm đón rõ ràng, tiện lợi ở xung quanh. Điều này giúp họ tránh khỏi việc phải gọi cho tài xế, giải thích họ đang ở đâu, họ đang mặc quần áo màu gì, ... Các điểm đón này thường là những vị trí phổ biến ở xung quanh với tên được hiển thị chính xác theo cách gọi thông dụng và được thiết kế để làm cho cuộc sống của cả khách hàng và tài xế trở nên đơn giản, dễ dàng hơn.
Nhưng làm thế nào mà GoJek có thể đặt tên các điểm đón một cách chính xác và trên quy mô lớn?
Họ sử dụng vị trí đặt xe trong quá khứ và lịch sử tin nhắn (chat logs) tương ứng để khám phá ra tên các điểm đón. Cụ thể là họ sẽ "clustering" các điểm đặt xe trong quá khứ để tạo ra các điểm đón tiềm năng, sau đó sử dụng một mô hình ngôn ngữ (Language Model) để chọn cái tên tốt nhất. Tuy nhiên, mô hình thống kê kiểu này sẽ không hiểu ý nghĩa của các tin nhắn do đơn thuần nó chỉ chọn ra các cụm từ có tần suất xuất hiện cao mà không hiểu gì về mặt ngữ nghĩa. Đôi khi nó sẽ tạo ra tên đường, đôi khi là các cụm từ phổ biến nhưng không chứa thông tin liên quan tới địa điểm. Gojek sẽ phải kiểm tra thủ công tất cả trước khi cho chúng xuất hiện trên ứng dụng.
Để cải thiện điều này, Gojek phát triển CartoBert - một mô hình NLP dạng deep learning có thể hiểu và học để phân biệt các điểm đón có tên hợp lệ. Mô hình này lấy cảm hứng và dựa trên kiến trúc của mô hình ALBERT. ALBERT là phiên bản cải tiến của BERT, Bidirectional Encoder Representations from Transformers, một mô hình ngôn ngữ theo ngữ cảnh, được công bố bởi Google vào cuối năm 2018.
CartoBERT sẽ được huấn luyện trên tập dữ liệu đặt xe gồm 200 triệu câu để hiểu tất cả các từ trong câu. Với mỗi từ, CartoBERT tạo ta một vector số có 768 chiều từ lớp mã hóa biến đổi cuối cùng và sử dụng chúng để thể hiện sự thấu hiểu về ý nghĩa của từ trong ngữ cảnh của câu. Từ đó, nó có thể trích xuất tên các điểm đón từ các tin nhắn đặt xe, nếu có.
CartoBERT tăng độ chính xác thêm 25% lên thành 93%. Độ chính xác được đo bằng tỉ lệ tên điểm đón hợp lệ trên tổng tên được tạo ra. Với độ chính xác cao như vậy, Gojek đã có thể tự động tạo ra tên các điểm đón trên quy mô lớn để nhanh chóng hỗ trợ nhiều vị trí địa lý mà không cần công sức input từ con người.
Mời các bạn đọc bài viết gốc để có thêm thông tin chi tiết và ảnh minh họa.
How Uber Migrated Financial Data from DynamoDB to Docstore
Mỗi ngày, Uber tạo ra một lượng lớn giao dịch tài chính cần phải được lưu trữ với sự đảm bảo về tính đầy đủ, nhất quán và tuân thủ theo các quy định.
Uber hiện đang sử dụng LedgerStore, một cơ sở dữ liệu bất biến kiểu sổ cái lưu trữ các giao dịch kinh doanh. LedgerStore cung cấp tính năng ký/niêm phong dữ liệu để đảm bảo tính đầy đủ/đúng đắn của dữ liệu, và phân cấp dữ liệu tự động cho phép chuyển dữ liệu cũ xuống các kho lưu trữ ít tốn kém hơn về mặt chi phí.
Phiên bản đầu tiên của LedgerStore sử DynamoDB làm backend lưu trữ. Trải qua thời gian gần 2 năm sử dụng, một lượng lớn dữ liệu được tạo ra và Uber nhận ra rằng việc vận hành LedgerStore với DynamoDB đang trở nên tốn kém hơn rất nhiều. Chính vì vậy Uber đã quyết định thay đổi backend lưu trữ của LedgerStore là DynamoDB bằng một hệ thống lưu trữ khác.
Họ nhận ra Docstore - một schemaless database do chính Uber tạo ra - là một lựa chọn hợp lý, đảm bảo được các yêu cầu về độ tin cậy, độ khả dụng,... Tuy nhiên, tính năng mà Docstore còn thiếu là Change Data Capture (cần đọc streaming data), và họ đã quyết định build một streaming framework riêng cho Docstore lấy tên là dự án Flux.
Sau khi chọn Docstore làm backend lữu trữ, việc tiếp theo Uber cần đó là những xây dựng thiết kế xoay quanh việc di chuyển (migrate) dữ liệu và lưu lượng truy cập, chẳng hạn như:
Sự thay đổi không làm ảnh hưởng đến khách hàng — các bên liên quan. (ví dụ: thay đổi service logic, mã nguồn ở client, routing...)
Tính khả dụng cao — không có thời gian ngừng hoạt động trong quá trình di chuyển dữ liệu.
Duy trì 100% tính nhất quán của dữ liệu Read-Your-Writes (Tính nhất quán Read-Your-Writes yêu cầu hệ thống đảm bảo rằng, khi một mục đã được cập nhật, bất kỳ truy vấn nào để đọc bản ghi của cùng một ứng dụng khách sẽ trả về giá trị đã cập nhật).
Duy trì các SLO hiệu suất đã có từ trước, chẳng hạn như độ trễ,...
Khả năng chuyển đổi qua lại giữa các cơ sở dữ liệu như một biện pháp đề phòng trong trường hợp khẩn cấp.
Bài viết cũng đã đi sâu vào kiến trúc và giải thích cách toàn bộ quá trình di chuyển dữ liệu được thiết kế và thực hiện mà không ảnh hưởng đến SLA nghiêm ngặt. Mời bạn đọc bài viết gốc để tham khảo rõ hơn về nội dung trên..
From daily dashboards to enterprise grade data pipelines
Với việc tổng hợp, tính toán và xử lý dữ liệu tới từ 50+ luồng dữ liệu, phục vụ cho 40+ chỉ số business khác nhau. Các kỹ sư tại Linkedin đối mặt với các thử thách trong việc phân phối và nâng cao hiệu suất của Daily Executive Dashboard (DED) do tính phức tạp ngày càng tăng của việc tổng hợp và tính toán các chỉ số này.
Trong bài viết này, tác giả điểm qua về các khó khăn gặp phải khi phát triển hệ thống DED, vấn đề không chỉ nằm ở việc lượng dữ liệu ngày càng tăng mà còn dựa vào stack công nghệ của LinkedIn thời điểm lúc bấy giờ. Bài viết đề cập đến những bước phát triển chính của DED và cách mà đội ngũ kỹ sư ở đây giải quyết một số vấn đề về việc lặp lại quy trình và thách thức trong quá trình xây dựng hệ thống. Bố cục của bài viết được tổ chức theo 3 giai đoạn: surviving, scaling, and thriving. Để biết thêm chi tiết, mời các bạn đón đọc tại link:
Góc Distributed System
Góc DS tuần này giới thiệu tới bạn đọc khoá học U ndergraduate về Distributed Systems của Đại học Cambridge do Martin Kleppmann giảng dạy. Khoá học này cover những kiến thức cơ bản và cần phải biết về Distributed Systems nên rất bổ ích cho các bạn muốn tìm hiểu về Distributed Systems từ những vấn đề nền tảng của nó, bao gồm:
Introduction: distributed systems, computer networks, and RPC
System models: network faults, crash and Byzantine faults, synchrony assumptions
Physical clocks, clock synchronisation, and causality
Logical time, broadcast protocols (reliable, FIFO, causal, total order)
Replication, quorum protocols, state machine replication
Consensus, details on the Raft consensus algorithm
Replica consistency, two-phase commit, linearizability, eventual consistency
Case studies: collaboration software, Google’s Spanner
Nội dung của khoá học được ghi lại trên youtube theo đường link sau: https://www.youtube.com/playlist?list=PLeKd45zvjcDFUEv_ohr_HdUFe97RItdiB
Slide bài giảng: https://www.cl.cam.ac.uk/teaching/2021/ConcDisSys/dist-sys-handout.pdf
Góc Database
Cơ chế Remote Compactions cho RocksDB
RocksDB là một storage engine theo kiến trúc LSM tree được giới thiệu ở vài kỳ Grokking newsletter trước do mức độ phổ biến của storage engine này. Cũng như các LSM storage engines khác, RocksDB đều phải trải qua quá trình compaction bằng cách gộp các SST files để tạo các SST files mới với các keys được ghi đè lên hoặc xóa đi. Bằng việc chạy compaction, RocksDB sẽ sử dụng storage ít hơn và có thể đọc dữ liệu nhanh hơn.
Tuy nhiên, một hạn chế của quá trình compaction ở RocksDB là nó sẽ tốn khá là nhiều tài nguyên. Đồng thời, quá trình compaction sẽ diễn ra ở tại máy chủ chứa dữ liệu SST files đó. Do đó, khi mà các máy chủ này quá tải bởi lưu lượng đọc và viết cao, việc có thêm quá trình compaction ở máy đó sẽ bị chậm lại hay dời qua một thời điểm khác. Việc hạn chế này xảy ra khi mà lẫn compute và storage của RocksDB đều nằm ở trên cùng một máy, đặc biệt là cho quá trình compaction.
Để mà giải quyết hạn chế này, các kỹ sư ở Rockset đã xây dựng cơ chế remote compactions để mà có thể scale quá trình compaction dễ dàng hơn khi mà chúng ta có thể tách được compute và storage của RocksDB. Ở Rockset, họ có một hệ thống gọi là RocksDB-Cloud được dùng để chứa các SST files trên những giải pháp cloud storage như là S3. Bởi thế, họ có thể có những máy chủ riêng để truy vấn các SST files này và chạy quá trình compaction để mà các máy chủ nhận reads/writes từ người dùng không bị quá tải hay thiếu hụt tài nguyên quá nhiều. Bài viết sau đây được anh Hiếu Phạm nói cụ thể hơn về cách họ đã xây dựng cơ chế remote compaction như thế nào. Đồng thời, bài viết cũng nói thêm về một vài hạn chế và cách tối ưu cho cơ chế mới này.
Góc Lập Trình
Đề tuần này:
Ta cùng tiếp tục chủ đề tìm đường đi ngắn nhất với bài https://leetcode.com/problems/path-with-minimum-effort/
Lời giải tuần trước:
Đề bài: https://leetcode.com/problems/shortest-path-in-binary-matrix/
Lời giải
Nếu ta biểu diễn ma trận bằng đồ thị, với các ô 0 là đỉnh, các cạnh sẽ nối các ô 0 cạnh nhau. Ta có thể dễ dàng nhận thấy, tất cả các cạnh đều có trọng số là 1, vì vậy ta có thể coi đây là đồ thì không có trọng số (unweighted graph). Giải thuật duyệt theo chiều rộng (BFS) sẽ có ta đường đi ngắn nhất từ đỉnh nguồn tới các đỉnh còn lại với độ phức tạp time complexity là O(V + E) với V là tổng số đỉnh, E là tổng số cạnh, tốt hơn rất nhiều so với giải thuật Dijkstra có độ phức tạp là O(E*logV).
Cách chứng minh được nêu trong sách Introduction to Algorithms (a.k.a CLRS book), mục 22.2 Breadth-first search.
Giải thuật được thực hiện như sau: https://pastebin.com/uuXYdVm6
Ở cách thực hiện này, ta trực tiếp cập nhật độ dài đường đi ngắn nhất tới mảng đầu vào, điều này giúp ta giảm bớt bộ nhớ. Tuy nhiên với mảng đầu vào không phải là integer (ví dụ mảng đầu vào là char[][]), ta không thể thực hiện tối ưu này.
Tech Talks
Making Apache Spark™ Better with Delta Lake — www.youtube.com
Delta Lake là một dự án mã nguồn mở cho phép xây dựng kiến trúc Lakehouse trên trên nền Data Lake. Delta Lake cung cấp khả năng đảm bảo ACID cho các transactions, xử lý lượng metadata cực lớn, cung cấp API giúp thống nhất việc xử lý dữ liệu theo batch và streaming trên các Data Lakes phổ biến hiện tại như S3, ADLS, GCS và HDFS.
Qua buổi Techtalk, Join Michael Armbrust, Head of Delta Lake engineering team, đặt ra các vấn đề phổ biến của Data Engineering như: Historical Queries, Messy/Garbage Data trong Data Lake, xử lý Mistakes và Failures khi chạy các pipelines, thực thi Update operation. Từ đó, để quá trình phân tích dữ liệu và các machine learning model có thể tiếp cận nguồn dữ liệu chất lượng và đáng tin cậy, tác giả đã giới thiệu giải pháp kết hợp giữa Delta Lake và Apache Spark thông qua kiến trúc 3 lớp: Bronze, Silver, Gold.
Các chủ đề cụ thể được bàn luận trong Techtalk bao gồm:
Vai trò của Apache Spark trong Big Data processing
Xử dụng Data Lakes là một phần quan trọng trong kiến trúc dữ liệu.
Các thách thức đối với mức độ tin cậy trong Data Lakes.
Delta Lake đã giúp mang lại mức độ tin cây cao trong Spark processing như thế nào
Các cải tiến cải tiến cụ thể mà Delta Lake bổ sung
Sự dễ dàng của việc sử dụng Delta Lake trên nền Data Lakes
Code & Tools
rocksdb-cloud - A library that provides an embeddable, persistent key-value store for fast storage optimized for AWS
copilot-docs - Documentation for GitHub Copilot
Góc Sponsors
One Mount là tập đoàn kiến tạo hệ sinh thái công nghệ lớn nhất Việt Nam, cung cấp các giải pháp và dịch vụ xuyên suốt chuỗi giá trị, từ lĩnh vực dịch vụ tài chính, phân phối, bất động sản và bán lẻ, với ba sản phẩm chủ lực: VinShop, VinID, OneHousing.
Với trụ sở tại Hà Nội, Hồ Chí Minh và quy tụ hơn 1.500 nhân sự xuất sắc, One Mount tâm huyết xây dựng môi trường làm việc:
Đề cao “Giá trị của công việc ý nghĩa”
Quy tụ nhân tài Việt trên toàn cầu
Văn hóa thành công cùng nhau vươn tới đỉnh cao
Các vị trí hấp dẫn đang mở tuyển:
Back-end Engineer (Java/Golang), Front-end Engineer (ReactJS, Angular), Mobile Developer (iOS, Android)
Data Analysis, Data Engineer, Data Scientist
Business Analysis, QC Engineer
Tham khảo các thông tin về văn hóa, môi trường làm việc, cơ hội nghề nghiệp tại One Mount:
Website: https://careers.onemount.com/
Quotes
The act of describing a program in unambiguous detail and the act of programming are one and the same.
— Kevlin Henney