Building a scalable and real-time recommendation system is vital for many businesses driven by time-sensitive customer feedback, such as short-videos ranking or online ads. Despite the ubiquitous adoption of production-scale deep learning frameworks like TensorFlow or PyTorch, these general-purpose frameworks fall short of business demands in recommendation scenarios for various reasons: on one hand, tweaking systems based on static parameters and dense computations for recommendation with dynamic and sparse features is detrimental to model quality; on the other hand, such frameworks are designed with batch-training stage and serving stage completely separated, preventing the model from interacting with customer feedback in real-time. These issues led us to reexamine traditional approaches and explore radically diferent design choices. In this paper, we present Monolith1, a system tailored for online training. Our design has been driven by observations of our application workloads and production environment that reflects a marked departure from other recommendations systems. Our contributions are manifold: first, we crafted a collisionless embedding table with optimizations such as expirable embeddings and frequency filtering to reduce its memory footprint; second, we provide an production-ready online training architecture with high fault-tolerance; finally, we proved that system reliability could be traded-of for real-time learning. Monolith has successfully landed in the BytePlus Recommend2 product.
The past decade witnessed a boom of businesses powered by recommendation techniques. In pursuit of a better customer experience, delivering personalized content for each individual user as real-time response is a common goal of these business applications. To this end, information from a user’s latest interaction is often used as the primary input for training a model, as it would best depict a user’s portrait and make predictions of user’s interest and future behaviors.
Deep learning have been dominating recommendation models [1, 2, 3, 4, 5, 6] as the gigantic amount of user data is a natural fit for massively data-driven neural models. However, eforts to leverage the power of deep learning in industry-level recommendation systems are constantly encountered with problems arising from the unique characteristics of data derived from real-world user behavior. These data are drastically diferent from those used in conventional deep learning problems like language modeling or computer vision in two aspects: 1. The features are mostly sparse, categorical and
dynamically changing; † Work done during internship at Bytedance Inc. growing of IDs. This relies on an over-idealistic assumption that IDs in the embedding table is distributed evenly quality. Unfortunately this is rarely true for a real-world © 2022 Copyright for this paper by its authors. Use permitted under Creative Commons License in frequency, and collisions are harmless to the model Historical batch data aMnoddbealcfokrwwaarrddpass Online streaming
data aMnoddbealcfokrwwaarrddpass
Data of features and user reactions
Feature IDs
Embedding table lookup
Feature embeddings Feature IDs and gradients
Apply gradient updates Feature IDs
Embedding table lookup
Feature embeddings Feature IDs and gradients
Apply gradient updates recommendation system, where a small group of users or items have significantly more occurrences. With the organic growth of embedding table size, chances of hash key collision increases and lead to deterioration of model quality [10].
Therefore it is a natural demand for production-scale recommendation systems to have the capacity to capture as many features in its parameters, and also have the capability of elastically adjusting the number of users and items it tries to book-keep.
Visual and linguistic patterns barely develop in a time scale of centuries, while the same user interested in one topic could shift their zeal every next minute. As a result, the underlying distribution of user data is non-stationary, a phenomenon commonly referred to as Concept Drift [7].
Intuitively, information from a more recent history can more efectively contribute to predicting the change in a user’s behavior. To mitigate the efect of Concept Drift, serving models need to be updated from new user feedback as close to real-time as possible to reflect the latest interest of a user. Batch Training Stage Online Training Stage Parameter
Sync Embedding table lookup Sync interval Parameter
Sync
Feature IDs Feature embeddings
Model forward pass
User Request Ranking Result
User Actions that arises from our production, we designed Monolith, a large-scale recommendation system to address these pain-points. We did extensive experiments to verify and iterate our design in the production environment. Monolith is able to 1. Provide full expressive power for sparse features by designing a collisionless hash table and a dynamic feature eviction mechanism; 2. Loop serving feedback back to training in realtime with online training.
Empowered by these architectural capacities, Monolith consistently outperforms systems that adopts hash-tricks with collisions with roughly similar memory usage, and achieves state-of-the-art online serving AUC without overly burdening our servers’ computation power.
The rest of the paper is organized as follows. We first elaborate design details of how Monolith tackles existing challenge with collisionless hash table and realtime training in Section 2. Experiments and results will be presented in Section 3, along with production-tested conclusions and some discussion of trade-ofs between timesensitivity, reliability and model quality. Section 4 summarizes related work and compares them with Monolith. Section 5 concludes this work.
1. IDs that appears only a handful of times have limited contribution to improving model quality. An important observation is that IDs are long-tail distributed, where popular IDs may occur millions of times while the unpopular ones appear no more than ten times. Embeddings corresponding to these infrequent IDs are underfit due to lack of training data and the model will not be able to make a good estimation based on them. At the end of the day these IDs are not likely to afect the result, so model quality will not sufer from removal of these IDs with low occurrences; 2. Stale IDs from a distant history seldom contribute to the current model as many of them are never visited. This could possibly due to a user that is no longer active, or a short-video that is outof-date. Storing embeddings for these IDs could not help model in any way but to drain our PS memory in vain.
Based on these observation, we designed several feature ID filtering heuristics for a more memory-eficient implementation of HashTable: 1. IDs are filtered before they are admitted into embedding tables. We have two filtering methods: First we filter by their occurrences before they A B A h0(A)
D C
G h1(D) h1(B)
h0(C) D
E
F
C B
T0 T1 Generate
Features Model Server Online Training Training Worker Batch Training Data
HDFS Batch Training are inserted as keys, where the threshold of occurrences is a tunable hyperparameter that varies for each model; In addition we utilize a probabilistic iflter which helps further reduce memory usage; 2. IDs are timed and set to expire after being inactive for a predefined period of time. The expire time is also tunable for each embedding table to allow for distinguishing features with diferent sensitivity to historical information. enters the online training stage. Instead of reading mini-batch examples from the storage, a training worker consumes realtime data on-the-fly and updates the training PS. The training PS periodically synchronizes its parameters to the serving PS, which will take efect on the user side immediately. This enables our model to interactively adapt itself according to a user’s feedback in realtime.
In Monolith, training is divided into two stages (Figure 1):
In our implementation, HashTable is implemented as a TensorFlow resource operation. Similar to Variable, 2.2.1. Streaming Engine look-ups and updates are also implemented as native TensorFlow operations for easier integration and better compatibility.
Monolith is built with the capability of seamlessly switching between batch training and online training. This is enabled by our design of streaming engine as illustrated by Figure 4.
In our design, we use one Kafka [ 12] queue to log actions of users (E.g. Click on an item or like an item etc.) and another Kafka queue for features. At the core of the engine is a Flink [13] streaming job for online feature 1. Batch training stage. This stage works as an or- Joiner. The online joiner concatenates features with ladinary TensorFlow training loop: In each train- bels from user actions and produces training examples, ing step, a training worker reads one mini-batch which are then written to a Kafka queue. The queue for of training examples from the storage, requests training examples is consumed by both online training parameters from PS, computes a forward and a and batch training: backward pass, and finally push updated parameters to the training PS. Slightly diferent from • For online training, the training worker directly other common deep learning tasks, we only train reads data from the Kafka queue; our dataset for one pass. Batch training is useful • For batch training, a data dumping job will first for training historical data when we modify our dump data to HDFS [14]; After data in HDFS acmodel architecture and retrain the model; cumulated to certain amount, training worker 2. Online training stage. After a model is deployed will retrieve data from HDFS and perform batch to online serving, the training does not stop but training.
Log Kafka (User Actions) In-memory
Cache On-disk KV-Store
Found in Cache Read from KV-Store
Join
Negative Sampling
Training Example
Kafka
Updated parameters in training PS will be pushed to serving PS according to the parameter synchronization schedule.
In real-world applications, user actions log and features are streamed into the online joiner (Figure 5) without guarantee in time order. Therefore we use a unique key for each request so that user action and features could correctly pair up.
The lag of user action could also be a problem. For example, a user may take a few days before they decide to buy an item they were presented days ago. This is a challenge for the joiner because if all features are kept in cache, it would simply not fit in memory. In our system, an on-disk key-value storage is utilized to store features that are waiting for over certain time period. When a user action log arrives, it first looks up the in-memory cache, and then looks up the key-value storage in case of a missing cache.
Another problem that arise in real-world application is that the distribution of negative and positive examples are highly uneven, where number of the former could be magnitudes of order higher than the latter. To prevent positive examples from being overwhelmed by negative ones, a common strategy is to do negative sampling. This would certainly change the underlying distribution of the trained model, tweaking it towards higher probability of making positive predictions. As a remedy, we apply log odds correction [15] during serving, making sure that the online model is an unbiased estimator of the original distribution.
During online training, the Monolith training cluster keeps receiving data from the online serving module and updates parameters on the training PS. A crucial step to enable the online serving PS to benefit from these newly trained parameters is the synchronization of updated model parameters. In production environment, we are encountered by several challenges: • Models on the online serving PS must not stop serving when updating. Our models in production is usually several terabytes in size, and as a result replacing all parameters takes a while. It would be intolerable to stop an online PS from serving the model during the replacement process, and updates must be made on-the-fly; • Transferring a multi-terabyte model of its entirety from training PS to the online serving PS would pose huge pressure to both the network bandwidth and memory on PS, since it requires doubled model size of memory to accept the newly arriving model.
For the online training to scale up to the size of our business scenario, we designed an incremental on-thelfy periodic parameter synchronization mechanism in Monolith based on several noticeable characteristic of our models: 1. Sparse parameters are dominating the size of rec
ommendation models; 2. Given a short range of time window, only a small subset of IDs gets trained and their embeddings updated; 3. Dense variables move much slower than sparse embeddings. This is because in momentum-based optimizers, the accumulation of momentum for dense variables is magnified by the gigantic size of recommendation training data, while only a few sparse embeddings receives updates in a single data batch.
FM . . .
Output Embeddings
IDs . . .
MLP (1) and (2) allows us to exploit the sparse updates across all feature IDs. In Monolith, we maintain a hash set of touched keys, representing IDs whose embeddings get Figure 6: DeepFM model architecture. trained since the last parameter synchronization. We push the subset of sparse parameters whose keys are in the touched-keys set with a minute-level time interval from diferent aspects. We aim to answer the following from the training PS to the online serving PS. This rel- questions by our experiments: atively small pack of incremental parameter update is lightweight for network transmission and will not cause a sharp memory spike during the synchronization.
We also exploit (3) to further reduce network I/O and memory usage by setting a more aggressive sync schedule for sparse parameters, while updating dense parameters less frequently. This could render us a situation where the dense parameters we serve is a relatively stale version compared to sparse part. However, such incon- In this section, we first present our experimental setsistency could be tolerated due to the reason mentioned tings and then discuss results and our findings in detail. in (3) as no conspicuous loss has been observed. 1. How much can we benefit from a collisionless
HashTable? 2. How important is realtime online training? 3. Is Monolith’s design of parameter synchronization robust enough in a large-scale production scenario?
As a system in production, Monolith is designed with the ability to recover a PS in case it fails. A common choice for fault tolerance is to snapshot the state of a model periodically, and recover from the latest snapshot when PS failure is detected. The choice of snapshot frequency has two major impacts: 1. Model quality. Intuitively, model quality sufers less from loss of recent history with increased snapshot frequency. 2. Computation overhead. Snapshotting a multiterabyte model is not free. It incurs large chunks of memory copy and disk I/O.
As a trade-of between model quality and computation overhead, Monolith snapshots all training PS every day. Though a PS will lose one day’s worth of update in case of a failure, we discover that the performance degradation is tolerable through our experiments. We will analyze the efect of PS reliability in the next section.
For a better understanding of benefits and trade-ofs brought about by our proposed design, we conducted several experiments at production scale and A/B test with live serving trafic to evaluate and verify Monolith
As described in Section 2.1, embedding tables in Monolith are implemented as collisionless HashTables. To prove the necessity of avoiding collisions in embedding tables and to quantify gains from our collisionless implementation, we performed two groups of experiments on the Movielens dataset and on our internal production dataset respectively: 1. MovieLens ml-25m dataset [16]. This is a standard public dataset for movie ratings, containing 25 million ratings that involves approximately 162000 users and 62000 movies.
• Preprocessing of labels. The original labels
are ratings from 0.5 to 5.0, while in
production our tasks are mostly receiving binary
signals from users. To better simulate our
production models, we convert scale labels
to binary labels by treating scores ≥ 3.5 as
positive samples and the rest as negative
samples.
• Model and metrics. We implemented a
standard DeepFM [
Predictions are evaluated by AUC [
# Before Hashing # After Hashing Collision rate 2. Internal Recommendation dataset.
We also performed experiments on a recommendation model in production environment. This model generally follows a multi-tower architecture, with each tower responsible for learning to predict a specialized kind of user behavior.
During online training, we update our online serving PS with the latest set of parameters with minute-level intervals. We designed two groups of experiments to verify model quality and system robustness.
1. Update frequency. To investigate the necessity of minute-level update frequency, we conducted experiments that synchronize parameters from training model to prediction model with diferent intervals.
The dataset we use is the Criteo Display Ads
Challenge dataset1, a large-scale standard dataset for
benchmarking CTR models. It contains 7 days of
chronologically ordered data recording features
and click actions. For this experiment, we use a
standard DeepFM [
To simulate online training, we did the following preprocessing for the dataset. We take 7 days of data from the dataset, and split it to two parts: 5 days of data for batch training, and 2 days for online training. We further split the 2 days of data into shards chronologically. Online training is simulated by algorithm 1.
As such, we simulate synchronizing trained parameters to online serving PS with an interval determined by number of data shards. We experimented with = 10, 50, 100 , which roughly correspond to update interval of 5ℎ , 1ℎ , and 30 . 2. Live experiment. In addition, we also performed a live experiment with real serving trafic to further demonstrate the importance of online training in real-world application. This A/B experiment compares online training to batch training one one of our Ads model in production.
Results from MovieLens dataset and the Internal recommedation dataset both show that embedding collisions will jeopardize model quality.
1. Models with collisionless HashTable consistently outperforms those with collision. This conclusion holds true regardless of • Increase of number of training epochs.
As shown in Figure 7, the model with collisionless embedding table has higher AUC from the first epoch and converges at higher value; 1https://www.kaggle.com/competitions/criteo-display-ad-challenge /data • Each model has around 1000 embedding tables, and distribution of size of embedding tables are very uneven; • The original ID space of embedding table was 248. In our baseline, we applied a hashing trick by decomposing to curb the size of embedding table. To be more specific, we use two smaller embedding tables in3.2. Results and Analysis stead of a gigantic one to generate a unique embedding for each ID by vector combina- 3.2.1. The Efect of Embedding Collision tion: =
% 224 = ÷ 2
24 = + , where , are embeddings corresponding to , . This efectively reduces embedding table sizes from 248 to 225; • This model is serving in real production, and the performance of this experiment is measured by online AUC with real serving trafic.
Algorithm 1 Simulated Online Training.
1: Input: ℎ 2: Input: =1⋯ ;
; 3:
← ( 4: for = 1 ⋯ do /* Online training.
5: 6: 7: time due to Concept Drift. As shown in 2. Data sparsity caused by collisionless embedding
We discovered that a higher parameter synchronization frequency is always conducive to improving online serving AUC, and that online serving models are more tolerant with loss of a few shard of PS than we expect. 1. The Efect of Parameter Synchronization Frequency.
In our online streaming training experiment (1) with Criteo Display Ads Challenge dataset, model quality consistently improves with the increase of parameter synchronization frequency, as is evident by comparison from two perspectives: • Models with online training performs better than models without. Figure 9a, 9b, 9c compares AUC of online training models evaluated by the following shard of data versus batch training models evaluated by each shard of data; • Models with smaller parameter synchronization interval performs better that those with larger interval. Figure 10 and Table 2 compares online serving AUC for models with sync interval of 5ℎ , 1ℎ , and 30 respectively.
The live A/B experiment between online training and batch training on an Ads model in production also show that there is a significant bump in online serving AUC (Table 3).
Inspired by this observation, we synchronize sparse parameters to serving PS of our production models as frequent as possible (currently at minute-level), to the extent that the computation overhead and system reliability could endure. Recall that dense variables requires a less frequent update as discussed in 2.2.3, we update them at day-level. By doing so, we can bring down our computation overhead to a very low level. Suppose 100,000 IDs gets updated in a minute, and the dimension of embedding is 1024, the total size of data need to be transferred is 4 × 100, 000 ≈ 400 per minute. For dense parameters, since they are synchronized daily, we choose to schedule the synchronization when the trafic is lowest (e.g. midnight). 2. The Efect of PS reliability.
With a minute-level parameter synchronization, AUC Improvement % 14.443 16.871 17.068 14.028 18.081 16.404 15.202 (b) For dense variables, since they are updated slowly as we discussed in 2.2.3, losing 1 day’s update out of 1000 PS is negligible.
Based on the above observation and calculation, we radically lowered our snapshot frequency and thereby saved quite a bit in computation overhead.
Ever since some earliest successful application of deep learning to industry-level recommendation systems [1, 2], 0 10 20 30 40 50 researchers and engineers have been employing various Hours techniques to ameliorate issues mentioned in Section 1.
To tackle the issue of sparse feature representation, [1, 10] uses fixed-size embedding table with hash-trick.
There are also attempts in improving hashing to reduce
collision [
Hanzhi Zhou provided useful suggestions on revision of this paper. present our system in production, Monolith, to address them and achieved best performance compared to existing solutions.
We proved that a collisionless embedding table is essential for model quality, and demonstrated that our implementation of Cuckoo HashMap based embedding table is both memory eficient and helpful for improving online serving metrics.
We also proved that realtime serving is crucial in recommendation systems, and that parameter synchronization interval should be as short as possible for an ultimate model performance. Our solution for online realtime serving in Monolith has a delicately designed parameter synchronization and a fault tolerance mechanism: In our parameter synchronization algorithm, we showed that consistency of version across diferent parts of parameters could be traded-of for reducing network bandwidth consumption; In fault tolerance design, we demonstrated that our strategy of trading-of PS reliability for realtimeness is a robust solution.
To conclude, Monolith succeeded in providing a general solution for production scale recommendation systems. [5] B. Jiang, C. Deng, H. Yi, Z. Hu, G. Zhou, Y. Zheng,
S. Huang, X. Guo, D. Wang, Y. Song, L. Zhao, Z. Wang, P. Sun, Y. Zhang, D. Zhang, J. Li, J. Xu, X. Zhu, K. Gai, Xdl: an industrial deep learning framework for high-dimensional sparse data, Proceedings of the 1st International Workshop on Deep Learning Practice for High-Dimensional Sparse
Data (2019). [6] H.-T. Cheng, L. Koc, J. Harmsen, T. Shaked, T. Chandra, H. B. Aradhye, G. Anderson, G. S. Corrado, W. Chai, M. Ispir, R. Anil, Z. Haque, L. Hong, V. Jain, X. Liu, H. Shah, Wide & deep learning for recommender systems, Proceedings of the 1st Workshop on Deep Learning for Recommender Systems (2016). [7] J. Gama, I. Žliobaitė, A. Bifet, M. Pechenizkiy,
A. Bouchachia, A survey on concept drift adaptation, ACM Computing Surveys (CSUR) 46 (2014) 1 – 37. [8] M. Abadi, P. Barham, J. Chen, Z. Chen, A. Davis,
J. Dean, M. Devin, S. Ghemawat, G. Irving, M. Isard, M. Kudlur, J. Levenberg, R. Monga, S. Moore, D. G. Murray, B. Steiner, P. A. Tucker, V. Vasudevan, P. Warden, M. Wicke, Y. Yu, X. Zhang, Tensorflow: A system for large-scale machine learning, ArXiv abs/1605.08695 (2016). [9] A. Paszke, S. Gross, F. Massa, A. Lerer, J. Bradbury, G. Chanan, T. Killeen, Z. Lin, N. Gimelshein, L. Antiga, A. Desmaison, A. Köpf, E. Yang, Z. DeVito, M. Raison, A. Tejani, S. Chilamkurthy, B. Steiner, L. Fang, J. Bai, S. Chintala, Pytorch: An imperative style, high-performance deep learning [1] P. Covington, J. K. Adams, E. Sargin, Deep neural library, in: NeurIPS, 2019.
networks for youtube recommendations, Proceed- [10] T. Bredillet, Core modeling at instagram, 2019. URL: ings of the 10th ACM Conference on Recommender https://instagram-engineering.com/core-modelin Systems (2016). g-at-instagram-a51e0158aa48. [2] U. Gupta, X. Wang, M. Naumov, C.-J. Wu, B. Reagen, [11] R. Pagh, F. F. Rodler, Cuckoo hashing, in: ESA, D. M. Brooks, B. Cottel, K. M. Hazelwood, B. Jia, 2001.
H.-H. S. Lee, A. Malevich, D. Mudigere, M. Smelyan- [12] J. Kreps, Kafka : a distributed messaging system for skiy, L. Xiong, X. Zhang, The architectural implica- log processing, 2011. tions of facebook’s dnn-based personalized recom- [13] P. Carbone, A. Katsifodimos, S. Ewen, V. Markl, mendation, 2020 IEEE International Symposium on S. Haridi, K. Tzoumas, Apache flink™: Stream and High Performance Computer Architecture (HPCA) batch processing in a single engine, IEEE Data Eng. (2020) 488–501. Bull. 38 (2015) 28–38. [3] M. Xie, K. Ren, Y. Lu, G. Yang, Q. Xu, B. Wu, J. Lin, [14] K. V. Shvachko, H. Kuang, S. R. Radia, R. J. Chansler, H. Ao, W. Xu, J. Shu, Kraken: Memory-eficient The hadoop distributed file system, 2010 IEEE 26th continual learning for large-scale real-time recom- Symposium on Mass Storage Systems and Techmendations, SC20: International Conference for nologies (MSST) (2010) 1–10.
High Performance Computing, Networking, Stor- [15] H. Wang, A. Zhang, C. Wang, Nonuniform negage and Analysis (2020) 1–17. ative sampling and log odds correction with rare [4] W. Zhao, J. Zhang, D. Xie, Y. Qian, R. Jia, P. Li, Ai- events data, in: Advances in Neural Information box: Ctr prediction model training on a single node, Processing Systems, 2021.
Proceedings of the 28th ACM International Confer- [16] F. M. Harper, J. A. Konstan, The movielens datasets: ence on Information and Knowledge Management History and context, ACM Trans. Interact. Intell. (2019). Syst. 5 (2015) 19:1–19:19.