Như các bạn đã biết, tiktok hiện nay là một ứng dụng giải trí phổ biến và đứng top 1 trong số lượt tải xuống từ CH play và AppStore. Thành công của tiktok là do họ đã xây dựng khá thành công thuật toán gợi ý video cho người dùng, làm cho người dùng “cuốn” vào các video họ đề xuất, mà không biết chán. Ngày 27/09/2022, họ đã công bố bài báo có tự đề Monolith: Real Time Recommendation System With Collisionless Embedding Table tại địa chỉ https://arxiv.org/pdf/2209.07663.pdf. Chủ đề này khá nặng về khả năng xây dựng hệ thống để làm sao đạt được mô hình chất lượng với thời gian near-realtime. Để có thể hiểu sâu bài này, các bạn có nên có kiến thức về Recurrent Neural Networks for Recommendations.

Phần dẫn nhập - Chào đầu

Các doanh nghiệp có nhu cầu xây dựng real-time recommendation để phục vụ khách hàng tốt hơn.

Các framwork deep-learning được sử dụng trong production thường không đáp ứng được nhu cầu recommend của doanh nghiệp, lý do là:

1. Tinh chỉnh hệ thống dựa trên các tham số tĩnh và thực hiện nhiều phép tính toán trên feature thưa (sparse) và động (dinamic) làm giảm chất lượng mô hình.

2. Việc training và serving tách bạch nhau, không có online training (model không thể retrain ngay lập tức khi có feedback của người dùng)

Vì những nguyên nhân trên, nhóm tác giả của ByteDance đã thiết kế một mô hình online training mới, đặt tên là Monolith.

Mô hình mới có 2 thành tố mới:

• Đề xuất collisionless embedding table với các tối ưu như expirable embeddings và frequency filtering để giảm lượng bộ nhớ tiêu thụ.

• Đề xuất một mô hình kiến trúc production-ready online training với high fault-tolerance.

• Cuối cùng, chứng minh rằng độ tin cậy của hệ thống có thể đánh đổi bằng việc học theo thời gian thực.

1. Phần giới thiệu

“Hình 1: Monolith Online Training Architecture - Hình ảnh được cắt từ paper

Data của recommendation khác xa data của language modeling hoặc computer vision ở 2 khía cạnh:

1. Hầu hết các đặc trưng rất thưa, có tính phân loại và thay đổi linh hoạt.

2. Phân phối của data là không dừng (non-stationary) , vd Concept Drift. [8]

1.1 Sparsity và Dynamism

Nhắc lại, dữ liệu cho recommendation hầu hết là các đặc trưng category dạng thưa, một vài trong số đó có tầng suất xuất hiện rất thấp. Việc mapping chúng lên không gian đặc trưng cao chiều hơn sẽ gặp các vấn đề:

• Không giống như các mô hình ngôn ngữ có số lượng từ hạn chế, data user ranking item thường rất rất lớn. Khả năng cao là 1 máy chủ siêu mạnh hiện nay của các doanh nghiệp không chứa nổi Embedding table trên bộ nhớ chính.

• Trường hợp tệ nhất,kích thước của Embedding table sẽ tiếp tục tăng theo thời gian do người dùng và sản phẩm mới liên tục được thêm vào hệ thống. Trong khi đó, một số frameword recommendation sử dụng fixed-size dense variables để biểu diễn embedding table. Ví dụ framework [1,17]

Trong thực tế, nhiều thuật toán đã dùng vài “mẹo”, như xài hashing như bài báo [3] và bài báo [6] , để giảm lượng memory tiêu thụ và cho phép tăng ID. Ý tưởng này dựa trên giả định là ID trong Embedding table phân phối đều và việc collisions thì vô hại. Giả định này không đúng trong hiện thực, khi mà một nhóm nhỏ user hoặc item có tầng suất xuất hiện cao hơn. Với sự tăng trưởng tự nhiên của embedding table, xác suất hash key đụng độ sẽ càng cao, dẫn đến giảm chất lượng mô hình.

Do đó, nhu cầu tự nhiên của một hệ thống gợi ý là có khả năng capture càng nhiều đặc trưng trong chính các tham số của mô hình, và có khả năng điều chỉnh linh hoạt số user và số item mà nó có khả năng lưu giữ.

1.2 Non-stationary Distribution

Các pattern mới về hình ảnh và ngôn ngữ trong bài toán xử lý ảnh và xử lý ngôn ngữ thường không thay đổi nhiều trong hàng thế kỷ. Trong khi đó, sự quan tâm của người dùng về một chủ đề nào đó có thể thay đổi từng phút một. Kết quả là, phân phối của dữ liệu người dùng là không cố định, và hiện tượng này thường được gọi với tên là Concept Drift.

Thông thường, thông tin lịch sử gần nhất thường có đóng góp hiệu quả nhất cho việc dự đoán việc thay đổi hành vi người dùng. Để giảm thiểu tác động của Concept Drift, các mô hình “serving” cần phải cập nhật thường xuyên từ những phản hồi của người dùng, càng real-time càng tốt, để phản ánh tốt nhất xu hướng quan tâm của người dùng.

Dựa trên các phân tích trên, nhóm tác giả đã xây dựng nên monolith, có khả năng:

1. Cung cấp đầy đủ năng lực xử lý cho các đặc trưng thưa bằng cách thiết kế một collisionless hash table và cơ chế loại bỏ các dynamic feature.

2. Đưa thông tin feedback của người dùng vào training realtime với online training

Dựa vào kiến trúc này, mô hình monolith vượt trội hơn so với các hệ thống sử dụng collisions hash table với dung lượng bộ nhớ sử dụng là tương đương nhau

2. Design colisionless Hash Table và Online Training

Hình 2: Worker-PS Architecture - Hình ảnh được cắt từ paper

Kiến trúc của Monolith sử dụng TensorFlow’s distributed Worker-ParameterServer (Worker-PS) như hình trên. Trong mô hình, các máy được phân công với các nhiệm vụ khác nhau. Worker machine chịu trách nhiệm tính toán theo định nghĩa trước, PS machine lưu trữ các tham số và cập nhật kết quả tham số theo workers.

Trong mô hình recommendation, các tham số được phân loại làm hai nhóm: nhóm dense và nhóm sparse. Các tham số Dense là các trọng số của mô hình DNN, các tham số sparse tham chiếu tới embedding table tương ứng với các sparse feature. Cả Dense parameter và sparse parameter đều là các phần của TensorFlow Graph, và được lưu trữ trên parameters servers.

2.1 Xây dựng Hash Table

Hình 3: Cuckoo HashMap. - Hình ảnh được cắt từ paper

Nguyên tắc đầu tiên để xây dựng các tham số biểu diễn tính thưa là tránh thu gọn thông tin từ các IDs khác nhau về cùng một fixed-sze embedding.

Việc xây dựng một embedding table sử dụng TensorFlow Variable sẽ dẫn đến việc đụng độ ID khi số lượng ID mới và table tăng lênh. Do đó, thay vì xây embedding table dựa trên Variable, tác giả đã phát triển một key-value HashTable cho các tham số thưa.

HashTable này sử dụng Cuckoo Hashmap [16], hỗ trợ việc thêm một key mới mà không đụng độ với key cũ. Cuckoo Hashing trong trường hợp xấu nhất có độ phức tạp O(1) trong việc tìm kiếm và xoá, và O(1) cho việc thêm mới. Như trong hình 3, nó sử dụng hai bảng T0 và T1 với hai hàm hash khác nhau có tên là h0(x) và h1(x), và một phần tử sẽ được lưu trữ trong một trong hai bảng trên. Khi cố gán thêm một phần tử A vào T0, đầu tiên, nó cố gán đặt A vào h0(A). Nếu h0(A) đã hold 1 phần tử B nào đó, nó sẽ xoá B từ T0 và gán B vào T1 với logic tương tự. Quá trình này được lặp đi lặp lại đến khi ổn định.

Việc giảm bộ nhớ lưu trữ cũng là một yếu tố quang trọng trong thiết kế hệ thống. Một cách tự nhiên, việc mỗi lần thêm 1 phần tử mới vào HashTable sẽ làm cho bộ nhớ nhanh chóng đầy. Có 2 kết luận có thể được rút ra:

1. Các ID xuất hiện vài lần có đóng góp rất hạn chế đối với việc cải thiện chất lượng mô hình. Các quan sát quan trọng là các quan sát mà các IDs ở dạng long-tail distributed, khi các ID phổ biến có số lần xuất hiện hàng triệu lần, trong khi đó, các ID không phổ biến xuất hiện không quá mười lần. Các ID tầng suất thấp làm mô hình underfit do thiếu data training và model sẽ không có khả năng đưa ra dự đoán tốt dưa trên những thông tin mà chúng cung cấp. Hơn hết, các thông tin của các ID trên thường ít ảnh hưởng đến kết quả của mô hình, do đó, việc xoá đi các ID có tầng suất thấp không ảnh hưởng nhiều đến chất lượng mô hình.

2. Lịch sử từ thời napoleon có đóng góp rất thấp vào mô hình hiện tại. Do người dùng ngừng hoạt động, hoặc là video đã lỗi thời. Việc lưu trữ embedding cho các ID này không giúp ích cho mô hình, ngược lại chúng còn góp phần làm tăng chi phí lưu trữ và chi phí tính toán.

Dựa trên những điều trên, nhóm kỹ sư đề xuất thiết kế ID filtering heuristic để giúp tối ưu hoá bộ nhớ lưu trữ:

1. Các ID được lọc trước khi được đưa vào trong hệ thống embedding table. Có 2 phương pháp lọc

• Lọc theo tầng xuất xuất hiện trước khi ID được thêm vào. Giá trị ngưỡng là siêu tham số và được turning.
• Lọc theo xác xuất, giúp cho giảm bộ nhớ tiêu thụ.

2. ID được gán thời gian và bị expire sau một khoảng thời gian inactive.

HashTable được implement dưới dạng Tensorflow resource operation.

2.2 Online training

Việc trainnig được chia làm 2 giai đoạn:

1. Giai đoạn Batch training. Giai đoạn này hoạt động như việc training mô hình TF bình thường. Trong mỗi bước training, các worker đọc một mini-batch data training từ storage, lấy tham số từ PS, tính lan truyền xuôi, lan truyền ngược, và cập nhật tham số vào PS. Dataset được train 1 lần duy nhất.

2. Giai đoạn training online. Sau khi model được deploy vào online serving, việc traning không có dừng hẵng, mà chuyển qua giai đoạn online training. Thay vì đọc các mini-batch data từ storage, training worker sẽ lấy realtime data để train và cập nhật lại PS. Training PS sẽ định kỳ cập nhật các tham số vào serving PS.

2.2.1 Streaming Engine

Hình 4: Streaming Engine. The information feedback loop from [User → Model Server → Training Worker → Model Server → User] would spend a long time when taking the Batch Training path, while the Online Training will close the loop more instantly - Hình ảnh được cắt từ paper

Hình 4 phía trên mô tả việc chuyển đổi liền mạch giữa batch training và online training.

Mô hình sử dụng Kafka Queue [13] để log lại các hành động của user ( click item, like item, thả tim…. ) và một Kafka queue khác lưu lại các đặc trưng. Core engine là Flink [4] stream job cho online feature joiner. Online joiner kết hợp các đặc trưng với nhãn từ user action tạo thành training example, sau đó đẩy vào kafka queue. Queue cho training example được consumer bới online training và batch training.

• Với online training, training worker trực tiếp đọc dữ liệu từ kafka Queue.

• Với batch training, data sẽ được đóng gói vào file HDFS (dump job handle việc này). Sau khi data trong HDFS tích luỹ với số lượng đủ dùng, training worker sẽ load data từ HDFS và thực hiện batch training.

2.2 .2 Online Joiner

Hình 5: : Online Joiner - Hình ảnh được cắt từ paper

Trong ứng dụng thực tế, hành động của user và feature của user được stream vào online joiner mà không đảm bảo thứ tự về thời gian. Do đó, cần phát sinh một unique key cho mỗi request để đảm bảo pair được chúng với nhau.

Việc user bị lag cũng là một vấn đề cần được xem xét. Ví dụ, một user có khả năng mất vài ngày mới ra quyết định mua một sản phẩm mà họ đã xem vài ngày trước đó. Đây là một thách thức thật sự, bởi vì nếu toàn bộ các đặc trưng được lưu trữ trong bộ nhớ chính, thì chúng ta sẽ không đủ bộ nhớ để lưu trữ. Nhóm tác giả đã sử dụng on-disk key-value storage để lưu trữ các đặc trưng của người dùng ở quá khứ. Khi log của người dùng được đẩy vào hệ thống, trước hết nó sẽ được tìm kiếm trong memory cache, trong trường hợp mising cache, nó sẽ tìm trong key-value storage.

Một vấn đề nữa là phân bố mẫu âm và mẫu dương trong data không đồng đều. Trong đó, lượng mẫu dương thường cao hơn rất nhiều so với mẫu âm. Để ngăn chặng thằng mẫu dương thống trị, một chiến lược thường hay được sử dụng là sampling mẫu âm. Tất nhiên việc này sẽ làm thay đổi phân bố của mô hình huấn luyện. Và sử dụng log odds corection trong quá trình serving [19]

2.2.3 Parameter Synchronization

Trong suốt quá trình training, dữ liệu sẽ liên tục đổ về online serving module và cập nhật tham số trên PS. Trong môi trường thật, sẽ có một vài thách thức:

1. Model trên online serving PS bắt buộc phải hoạt động khi update. Kích thước model khá lớn, và việc update toàn bộ tham số sẽ tốn kha khá thời gian (lưu ý ở đây là không thể thực hiện update từng phần, mà phải update toàn bộ tham số). Nên phải tìm cách thức nào đó để việc update không ảnh hưởng tới việc infer của model.

2. Việc tranfer model có kích thước lớn từ training PS tới online server PS sẽ gây áp lực lớn đến băng thông mạng và bộ nhớ trên PS. Một yêu cầu tối thiểu là bộ nhớ phải có kích thước ít nhất là gấp 2 lần kích thước của model (trên RAM)

Để scale up model cho phù hợp với nghiệp vụ kinh doanh, nhóm tác giả đã thiết kế riêng một cơ chế đồng bộ hoá, dựa trên các quan sát sau:

1. Các tham số thưa thì thường thống trị kích thước của mô hình gợi ý.

2. Trong một khoảng thời gian ngắn (short range of time window), chỉ một nhóm nhỏ các ID được training, và chỉ những embedding của những ID đó được cập nhật.

3. Các biến Dense tranfer chậm hơn so với spare embeddings. Bởi vì size của Dense variable rất lớn.

Nhận định 1 và 2 ở nhận cho phép chúng ta tránh cập nhật sparse của toàn bộ các đặc trưng của ID. Trong mô hình, các ID chưa được huấn luyện kể từ lần huấn luyện cuối cùng sẽ được đẩy vào touched key. Sau khi training xong, chúng ta sẽ đẩy các sparse parameter trong touched key vào online serving PS với tần suất tính bằng phút. Gói cập nhật này khá nhỏ (so với toàn bộ ), nên chúng ít sẽ sử dụng băng thông mạng rất thấp, và sẽ không tạo mô hình răng cưa cho bộ nhớ RAM trong quá trình đồng bộ.

Với nhận định (3), chúng ta sẽ giảm I/O mạng và bộ nhớ sử dụng bằng cách đặt lịch đồng bộ hoá dày hơn cho các tham số thưa, trong khi đó sẽ có tầng xuất cập nhật tham số dense ít hơn. Việc này cũng gây ra tình huống là các tham số thưa sẽ mới hơn rất nhiều so với tham số dense, do đó sẽ có mất mát xảy ra. Mất mát này được chấp nhận do nó không quá nghiêm trọng. Trong phần cuối có thí nghiệm về vấn đề này.

2.3 Fault Tolerance

Đối với hệ thống thực, kiến trúc của hệ thống phải đảm bảo khả năng phục hồi trong trường hợp có lỗi xảy ra. Một lựa chọn phổ biến thường được hay dùng là snapshot trạng thái của model định kỳ, và phục hồi dữ liệu từ lần snapshot cuối cùng khi nhận thấy có lỗi. Việc lựa chọn tầng suất snapshot dựa vào hai yếu tố chính:

1. Chất lượng model. Dĩ nhiên rằng model snapshot ở càng gần phiên bản cuối càng tốt, do đó tầng suất snapshot phải tăng lên.

2. Chi phí sử dụng hệ thống. Việc snapshot một model có kích thước lớn sẽ tốn kha khá cpu và bộ nhớ để copy data, ngoài ra còng tăng disk I/O

Để cân bằng giữa 2 cái trên, Monolith snapshot toàn bộ training PS mỗi ngày. Chúng ta sẽ mất 1 ngày update data khi lỗi xảy ra. Nhưng qua các thử nghiệm của nhóm kỹ sư ByteDance, thì hiệu năng suy giảm vẫn ở mức chấp nhận được.

3. Đánh giá - EVALUATION

Để hiểu hơn về lợi ích và sự đánh đổi của mô hình được đề xuất,chúng ta xây dựng một vài thí nghiệm và A/B testing trên môi trường thực. Mục tiêu là trả lời các câu hỏi sau:

1. Lợi ích của collisionless hashtable là bao nhiêu?

2. Mức độ quang trọng của realtime training online?

3. Liệu rằng mô hình thiết kế của Monolith với các tham số được đồng bộ như trên đã đủ tốt trong môi trường thực tế?

3.1 Thiết lập thí nghiệm

3.1.1 Xây dựng embedding table

Như mô tả ở mục 2.1, embedding table trong monolith là collisionless hashtable. Để chứng minh sự cần thiết của việc tránh đụng độ trong việc thiết kế embedding table và lợi ích nhận được từ phiên bản collisionless mà mô hình đề xuất, chúng ta thực hiện hai nhóm thí nghiệm trên tập Movielens và trong tập internal production dataset của ByteDance.

Hình 6: DeepFM model architecture - Hình ảnh được cắt từ paper

1. MovieLens. Là tập dataset chuẩn , mở, bao gồm 25 triệu đánh giá từ xấp xỉ 162000 user và 62000 bộ phim:

• Tiền xử lý label. Label gốc của tập có giá trị từ 0.5 đến 5, trong khi đó, mô hình monolith nhận giá trị binary từ user. Chúng ta sẽ chuyển giá trị từ scale label sang binary label bằng việc đặt ngưỡng >=3.5 là positive sample và bé hơn 3.5 là negative sample

• Đánh giá Model và metrics. Chúng ta sẽ implement DeepFM model, một kiến trúc model phổ biến cho bài toán recommend. Nó bao gồm thành phần FM và thành phần dense (xem kỹ hình 6).Sử dụng AUC để đánh giá giá trị predict.

• Đánh giá Embedding collisions. Dataset này có gần 160k user và 60k movie. Để so sánh, chúng ta sẽ sử dụng MD5 làm quân đỏ và mapping vào một nhóm nhỏ ID space, mục đích là làm cho một vài ID sẽ dùng chung embedding với nhau. Bảng bên dưới sẽ hiển thị chi tiết thống kê của user và movie trước và sau hash

VPB	User IDs	Movie IDs
# Before Hashing	162541	59047
# After Hashing	149970	57361
Collision rate	7.73%	2.86%

Bảng 1: Thống kê ID trước và sau khi hash

3.1.2 Online training

Trong quá trình online training, chúng ta sẽ cập nhật tham số từ training PS sang online PS với tần suất theo phút. Chúng ta thiết kế hai nhóm thí nghiệm để đánh giá chất lượng của mô hình và độ tải của hệ thống.

1. Update frequency. Để đánh giá sự cần thiết của việc update theo phút, chúng ta xây dựng thí nghiệm với tầng xuất update khác nhau và xem sự hiệu quả.

Chúng ta sử dụng Criteo Display Ads Challenge dataset (https://www.kaggle.com/competitions/criteo-display-ad-challenge/data), đây là dataset được sử dụng để benchmarking CTR model. Data bao gồm 7 ngày dữ liệu, ghi nhận feature và hành động click của người dùng. Trong thí nghiệm này, chúng ta xài mô hình DeepFM mô tả trong hình 6. Để mô phỏng online training, chúng ta sẽ chia tập dữ liệu thành 2 phần. Phần đầu tiên là 5 ngày, dùng để train, phần thứ 2 là 2 ngày còn lại, dùng cho online training. Trong 2 ngày dữ liệu của phần 2, chúng ta sẽ chia thành N shard. Thí nghiệm với N =10, 50, 100, tương ứng 5h (2 ngày = 48 tiếng / 10 = 4.8 tiếng ~ 5 tiếng), 1h ( 48/50 ) và 30 phút cập nhật dữ liệu một lần.

2. Live experiment. Thêm nữa, chúng ta sẽ thực hiện thí nghiệm thực thế với real serving traffice để mô phỏng sự quang trọng của online training trong ứng dụng thực. Thí nghiệm A/B testing này so online training (A) vs batch training (B).

3.2 Kết quả và phân tích

3.2.1 Hiệu quả của embedding collision

Hình 7: Effect of Embedding Collision On DeepFM, MovieLens

Cả hai kết quả từ MovieLens dataset và Internal recommedation dataset đều chỉ ra rằng collisions embedding gây tổn hại cho chất lượng của mô hình.

1. Mô hình với collisionless HashTable cho kết quả tốt hơn, luôn có đồ thị nằm ở ngoài so với mô hình collision. Kết luận này luôn luôn đúng, cho dù:

• Tăng số lượng training epoch. Như kết quả ở hình 7. Mô hình collisionless embedding table có AUC cao hơn ở epoch đầu tiên, và hội tụ với giá trị cao hơn.

• Thay đổi phân phối theo thời gian (Concept Drift). Như hiển thị trong hình 8, mô hình với collisionless embedding table cũng cho kết quả rất tốt trong ngữ cảnh user/items thay đổi.

2. Tính thưa của data được sinh ra bởi collisionless embedding table sẽ không làm cho mô hình bị overfit. Như kết quả ở hình 7, mô hình không bị overfit sau khi nó đã hội tụ

3.2.2 Online Training: Trading-off Reliability For Realtime.

Hình 8: Effect of Embedding Collision On A Recommendation Model In Production.

Chúng ta khám phá ra rằng việc đồng bộ các tham số với tầng suất cao thì luôn luôn cải tiến online serving AUC, và mô hình tốt hơn so với kỳ vọng.

1. The Effect of Parameter Synchronization Frequency. Trong thí nghiệm về online stream training với Criteo Display Ads Challenge dataset, chất lượng model sẽ tốt hơn nếu tăng tầng suất đồng bộ hoá mô hình, chứng minh bằng hai khía cạnh sau:

• Model có online training sẽ tốt hơn so với mô hình không có online training. Xem hình 9

• Model có tần suất cập nhật cao sẽ tốt hơn so với mô hình có tuần suất cập nhật thấp. Xem hình 10 và bảng 2

Hình 9: : Online training v.s. Batch training on Criteo dataset. Blue lines: AUC of models with online training; Yellow lines: AUC of batch training models evaluated against streaming data.

Sync Interval	Average AUC (online)	Average AUC (batch)
5 hr	79.66 ± 0.020	79.42 ± 0.026
1 hr	79.78 ± 0.005	79.44 ± 0.030
30 min	79.80 ± 0.008	79.43 ± 0.025

Bảng 2: Average AUC comparison for DeepFM model on Criteo dataset

Hình 10: Comparison of different sync intervals for online training.

Bên cạnh các quan sát này, chúng ta thực hiện đồng bộ sparse parameter vào serving PS với tầng suất càng sớm càng tốt (theo phút) để mở rộng khả năng tính toán và độ tin cậy của hệ thống.

Giả sử rằng các dense parameter yêu cầu tầng suất cập nhật ít hơn như thảo luận ở mục 2.2.3, chúng ta sẽ cập nhật chúng ở mức ngày, và xác xuất hệ thống bị quá tải sẽ rất thấp. Ví dụ chúng ta có 100k ID được cập nhật trong 1 phút, embedding có kích thước 1024, tổng kích thước của data cần để chuyển 4KB x 100000 = 40000 MB một phút. Với dense parameter, nếu chúng ta thực hiện daily sync, chúng ta sẽ chọn thời điểm sync mà traffice là thấp nhất ( gần sáng chẳng hạn)

2. The effect of PS reliability

Với việc đồng bộ hoá các tham số ở mức phút, chúng ta tự nhiên suy nghĩ trong đầu rằng tầng suất snapshot cũng nên phải tương đương như vậy. Tuy nhiên trong thực tế, khi chúng ta sử dụng snapshot với tầng suất 1 ngày delay, chất lượng mô hình cũng không giảm quá nhiều.

Việc tìm kiếm điểm cân bằng giữa chất lượng mô hình và năng lực tính toán là rất khó trong bành toán personalized ranking. Khi user cực kỳ nhạy cảm với chất lượng recommendation. Theo truyền thống, các hệ thống lớn thường có xu hướng đặt tầng xuất retrain theo hướng hi sinh năng lực tính toán (chạy ì ạch, lâu cũng được) và đánh đổi bởi cực tiểu hoá độ lỗi.

Ví dụ với tỷ lệ lỗi 0.01 của PS machine / day, chúng ta sẽ snapshot lại tham số của ngày hôm trước, Giả sử dúng ta sharding parameter vào 1000PS, chúng snapshot mỗi ngày. Tỷ lệ lỗi 0.01%, mỗi một máy sẽ bị lỗi sau 10 ngày , và chúng ta sẽ mất toàn bộ data của 1 ngày cập nhật. Giả sử DAU của 10 triệu và chúng ta mất 1 ngày dữ liệu của 5k user mỗi 10 ngày. Điều này có thể được chấp nhận bởi vì

a. Với các đặc trưng thưa của user, nó tương đương với tỷ lệ mất 0.01% DAU

b. Với các đặc trưng Dense, chúng ta cập nhật khá chậm, như thảo luận ở mục 2.2.3, việc mất 1 ngày update của 1000 PS là không đáng kể.

Qua những quan sát và tính toán ở trên, chúng ta có thể kết luận rằng tầng xuất snapshot thấp không ảnh hưởng nhiều đến khả năng chịu lỗi, và giảm khả năng xử lý của hệ thống.

Cảm ơn nhóm kỹ sư ByteDance đã cung cấp rất nhiều thông tin hữu ích trong bài viết. Hi vọng lần sau sẽ đọc được nhiều bài chất lượng hơn thế nữa.

Tài liệu tham khảo của paper

[1] “Martín Abadi, Paul Barham, Jianmin Chen, Z. Chen, Andy Davis, Jeffrey Dean, Matthieu Devin, Sanjay Ghemawat, Geoffrey Irving, Michael Isard, Manjunath Kudlur, Josh Levenberg, Rajat Monga, Sherry Moore, Derek Gordon Murray, Benoit Steiner, Paul A. Tucker, Vijay Vasudevan, Pete Warden, Martin Wicke, Yuan Yu, and Xiaoqiang Zhang. 2016. TensorFlow: A system for large-scale machine learning. ArXiv abs/1605.08695 (2016).”

[2] Andrew P. Bradley. 1997. The use of the area under the ROC curve in the evaluation of machine learning algorithms. Pattern Recognit. 30 (1997), 1145–1159.

[3] Thomas Bredillet. 2019. Core modeling at Instagram. https://instagramengineering.com/core-modeling-at-instagram-a51e0158aa48

[4] Paris Carbone, Asterios Katsifodimos, Stephan Ewen, Volker Markl, Seif Haridi, and Kostas Tzoumas. 2015. Apache Flink™: Stream and Batch Processing in a Single Engine. IEEE Data Eng. Bull. 38 (2015), 28–38.

[5] Heng-Tze Cheng, Levent Koc, Jeremiah Harmsen, Tal Shaked, Tushar Chandra, Hrishikesh B. Aradhye, Glen Anderson, Gregory S. Corrado, Wei Chai, Mustafa Ispir, Rohan Anil, Zakaria Haque, Lichan Hong, Vihan Jain, Xiaobing Liu, and Hemal Shah. 2016. Wide & Deep Learning for Recommender Systems. Proceedings of the 1st Workshop on Deep Learning for Recommender Systems (2016).

[6] Paul Covington, Jay K. Adams, and Emre Sargin. 2016. Deep Neural Networks for YouTube Recommendations. Proceedings of the 10th ACM Conference on Recommender Systems (2016).

[7] Alexandra Egg. 2021. Online Learning for Recommendations at Grubhub. Fifteenth ACM Conference on Recommender Systems (2021).

[8] João Gama, Indre Žliobait ˙ e, Albert Bifet, Mykola Pechenizkiy, and A. Bouchachia. 2014. A survey on concept drift adaptation. ACM Computing Surveys (CSUR) 46 (2014), 1 – 37.

[9] Huifeng Guo, Ruiming Tang, Yunming Ye, Zhenguo Li, and Xiuqiang He. 2017. DeepFM: A Factorization-Machine based Neural Network for CTR Prediction. In IJCAI.

[10] Udit Gupta, Xiaodong Wang, Maxim Naumov, Carole-Jean Wu, Brandon Reagen, David M. Brooks, Bradford Cottel, Kim M. Hazelwood, Bill Jia, Hsien-Hsin S. Lee, Andrey Malevich, Dheevatsa Mudigere, Mikhail Smelyanskiy, Liang Xiong, and Xuan Zhang. 2020. The Architectural Implications of Facebook’s DNN-Based Personalized Recommendation. 2020 IEEE International Symposium on High Performance Computer Architecture (HPCA) (2020), 488–501.

[11] F. Maxwell Harper and Joseph A. Konstan. 2015. The MovieLens Datasets: History and Context. ACM Trans. Interact. Intell. Syst. 5 (2015), 19:1–19:19.

[12] Biye Jiang, Chao Deng, Huimin Yi, Zelin Hu, Guorui Zhou, Yang Zheng, Sui Huang, Xinyang Guo, Dongyue Wang, Yue Song, Liqin Zhao, Zhi Wang, PengSun, Yu Zhang, Di Zhang, Jinhui Li, Jian Xu, Xiaoqiang Zhu, and Kun Gai. 2019 XDL: an industrial deep learning framework for high-dimensional sparse data. Proceedings of the 1st International Workshop on Deep Learning Practice for HighDimensional Sparse Data (2019).

[13] Jay Kreps. 2011. Kafka : a Distributed Messaging System for Log Processing.

[14] Xiangru Lian, Binhang Yuan, Xuefeng Zhu, Yulong Wang, Yongjun He, Honghuan Wu, Lei Sun, Haodong Lyu, Chengjun Liu, Xing Dong, Yiqiao Liao, Mingnan Luo, Congfei Zhang, Jingru Xie, Haonan Li, Lei Chen, Renjie Huang, Jianying Lin, Chengchun Shu, Xue-Bo Qiu, Zhishan Liu, Dongying Kong, Lei Yuan, Haibo Yu, Sen Yang, Ce Zhang, and Ji Liu. 2021. Persia: An Open, Hybrid System Scaling Deep Learning-based Recommenders up to 100 Trillion Parameters. ArXivabs/2111.05897 (2021).

[15] Meituan. 2021. Distributed Training Optimization for TensorFlow in Recommender Systems (in Chinese). https://tech.meituan.com/202112/09/meituantensorflow-in-recommender-systems.html

[16] R. Pagh and Flemming Friche Rodler. 2001. Cuckoo Hashing. In ESA.

[17] Adam Paszke, Sam Gross, Francisco Massa, Adam Lerer, James Bradbury, Gregory Chanan, Trevor Killeen, Zeming Lin, Natalia Gimelshein, Luca Antiga, Alban Desmaison, Andreas Köpf, Edward Yang, Zach DeVito, Martin Raison, Alykhan Tejani, Sasank Chilamkurthy, Benoit Steiner, Lu Fang, Junjie Bai, and Soumith Chintala. 2019. PyTorch: An Imperative Style, High-Performance Deep Learning Library. In NeurIPS.

[18] Konstantin V. Shvachko, Hairong Kuang, Sanjay R. Radia, and Robert J. Chansler. 2010. The Hadoop Distributed File System. 2010 IEEE 26th Symposium on Mass Storage Systems and Technologies (MSST) (2010), 1–10.

[19] HaiYing Wang, Aonan Zhang, and Chong Wang. 2021. Nonuniform Negative Sampling and Log Odds Correction with Rare Events Data. In Advances in Neural Information Processing Systems.

[20] Minhui Xie, Kai Ren, Youyou Lu, Guangxu Yang, Qingxing Xu, Bihai Wu, Jiazhen Lin, Hongbo Ao, Wanhong Xu, and Jiwu Shu. 2020. Kraken: Memory-Efficient Continual Learning for Large-Scale Real-Time Recommendations. SC20: International Conference for High Performance Computing, Networking, Storage and Analysis (2020), 1–17.

[21] Weijie Zhao, Jingyuan Zhang, Deping Xie, Yulei Qian, Ronglai Jia, and Ping Li.2019. AIBox: CTR Prediction Model Training on a Single Node. Proceedings of the 28th ACM International Conference on Information and Knowledge Management (2019).

Tham khảo

https://arxiv.org/pdf/2209.07663.pdf

Cảm ơn các bạn đã dành thời gian đọc bài tóm tắt này của mình. Nếu có bất kỳ vấn đề gì, hãy để lại comment bên dưới hoặc email cho mình qua địa chỉ [email protected]. Hẹn gặp lại các bạn ở bài viết tiếp theo.