My Notes From Spark+AI Summit 2020 (Application-Agnostic Talks)

eugeneyan

eugeneyan

Начните отсюда Статьи Выступления Прототипирование О себе

My Notes From Spark+AI Summit 2020 (Application-Agnostic Talks)

Мои заметки с Spark+AI Summit 2020 (доклады, не привязанные к приложениям)

[ machinelearning deeplearning survey ] · 11 min read

[ machinelearning deeplearning survey ] · чтение на 11 мин

Spark+AI Summit 2020 took place on 24-26 June. I’m only halfway through and it’s filled with gems of practical knowledge.

Spark+AI Summit 2020 прошёл 24–26 июня. Я пока прошёл лишь половину, но он уже наполнен жемчужинами практических знаний.

Figuring out which talks to attend can be overwhelming though. For example, 24th June has close to 100 sessions, not including keynotes and forums. ctrl+f on the following gives us the following matches:

Однако понять, какие доклады посетить, бывает непросто. Например, 24 июня было почти 100 сессий, не считая ключевых выступлений и форумов. ctrl+f по следующим словам даёт такие совпадения:

«beginner»: 4 «intermediate»: 56 «advanced»: 7 «sponsored»: 24 «ask me anything»: 6

Most people don’t have the time to sift through and attend these talks. Thus, I’m tidying up my notes and sharing a high-level summary on selected talks. This write-up will focus on the application-agnostic talks; the next one will be application-specific.

У большинства людей нет времени, чтобы перебрать все эти доклады и посетить их. Поэтому я привожу в порядок свои заметки и делюсь кратким обзором отдельных докладов. Эта статья посвящена докладам, не привязанным к конкретным приложениям; следующая будет о специфичных для приложений.

Table of Contents

Содержание

Масштабирование глубокого обучения через уменьшение моделей Как (не) масштабировать глубокое обучение за 6 шагов Масштабирование AI-исследований до продакшена с PyTorch Вероятностные структуры данных для людей Улучшение broadcast join в Apache Spark

Scaling Up Deep Learning By Scaling Down (24th June)

Масштабирование глубокого обучения через уменьшение моделей (24 июня)

Nick Pentreath, Principal Engineer at IBM’s Center for Open Data and AI, shares four ways to improve model training and performance efficiency.

Nick Pentreath, ведущий инженер в IBM Center for Open Data and AI, делится четырьмя способами повысить эффективность обучения и работы моделей.

Architecture improvements: Inception V3 uses the standard convolution block and has 24 million parameters. In contrast, MobileNet V1 uses depth-wise convolution blocks and has only 4 million parameters. However, accuracy also suffers (78.8% vs 70.9% on ImageNet).

Улучшения архитектуры. Inception V3 использует стандартный свёрточный блок и имеет 24 миллиона параметров. Напротив, MobileNet V1 использует поканальные (depth-wise) свёрточные блоки и имеет всего 4 миллиона параметров. Однако при этом страдает и точность (78,8% против 70,9% на ImageNet).

Trends in deep learning are changing. In the past, CNN models focused on accuracy (getting higher on the y-axis). Recently, the focus has shifted towards accuracy and efficiency (keeping the x-axis and the size of the models low).

Тенденции в глубоком обучении меняются. Раньше CNN-модели были нацелены на точность (продвижение выше по оси Y). В последнее время фокус сместился к точности и эффективности (сохранение низких значений по оси X и небольшого размера моделей).

Initially, models were moving to the top-right; now, the focus is on the top-left and keeping them small

Изначально модели двигались в верхний правый угол; теперь акцент сделан на верхний левый и сохранение их небольшими

Google also shared about EfficientNet which use neural architecture search to find optimal architectures. However, searching for the right architecture consumes a lot of resources.

Google также рассказал о EfficientNet, которая использует поиск нейронных архитектур (neural architecture search) для нахождения оптимальных архитектур. Однако поиск подходящей архитектуры потребляет много ресурсов.

Model pruning. Many of the weights in a neural network are not used. Here’s example of how we could prune as much as half the weights in InceptionV3 and MobileNet V1 with minimal loss in accuracy on ImageNet.

Обрезка модели (pruning). Многие веса в нейронной сети не используются. Вот пример того, как можно обрезать до половины весов в Inception V3 и MobileNet V1 с минимальной потерей точности на ImageNet.

Half of the weights can be pruned with minimal performance loss

Половину весов можно обрезать с минимальной потерей производительности

Quantization. We can reduce the numerical precision of weights by binning the values (i.e., reducing from 32-bit to 16-bit while still retaining the histogram distribution).

Квантизация. Мы можем снизить числовую точность весов, группируя значения по корзинам (то есть уменьшая разрядность с 32 бит до 16 бит, сохраняя при этом гистограммное распределение).

The distribution of weights can be retained at lower precision

Распределение весов можно сохранить и при пониженной точности

Quantization has two flavours: post-training and training-aware. Post-training quantization avoids retraining a model again, but there’s some drop in accuracy (77.2% vs 63.7%). Training-aware quantization is more complex though it has lesser accuracy loss (77.5% vs 70.9%)

Квантизация бывает двух видов: после обучения (post-training) и с учётом обучения (training-aware). Квантизация после обучения позволяет избежать повторного обучения модели, но при этом есть некоторое падение точности (77,2% против 63,7%). Квантизация с учётом обучения сложнее, зато потеря точности меньше (77,5% против 70,9%)

Model distillation. From the examples on pruning, it’s clear that our large neural networks are usually over parameterised. One way to slim them down is to train a smaller (student) model to mimic the larger (teacher) model’s predictions.

Дистилляция модели. Из примеров с обрезкой ясно, что наши крупные нейронные сети обычно переизбыточно параметризованы. Один из способов их уменьшить — обучить меньшую модель (ученика) имитировать предсказания большей модели (учителя).

A distilled (student) model can be trained on the teacher model's output, and ground truth labels

Дистиллированную модель (ученика) можно обучать на выходе модели-учителя и на истинных метках

The smaller model can be trained on both the teacher’s soft-labels and the ground truth labels. The soft-labels usually have higher entropy and provide more information and less variance. Thus, the smaller model can be trained on less data at a higher learning rate.

Меньшую модель можно обучать как на «мягких» метках учителя, так и на истинных метках. Мягкие метки обычно имеют более высокую энтропию и несут больше информации при меньшей дисперсии. Поэтому меньшую модель можно обучать на меньшем объёме данных и с более высокой скоростью обучения.

In some cases, the distilled model is stronger than the original model, providing higher accuracy and efficiency (further demonstrating that most models are over-parameterised). Some successful distilled models include DistilBERT and TinyBERT.

В некоторых случаях дистиллированная модель оказывается сильнее исходной, обеспечивая более высокую точность и эффективность (что дополнительно подтверждает, что большинство моделей переизбыточно параметризованы). Среди успешных дистиллированных моделей — DistilBERT и TinyBERT.

Instagram’s Feed recommendation system uses a stack of models, with the first layer being a distilled model. Here’s how it works during inference:

Рекомендательная система ленты Instagram использует стек моделей, первым слоем которого является дистиллированная модель. Вот как это работает на этапе инференса:

Первый проход: дистилляционная модель, которая имитирует следующие два этапа и отбирает 150 кандидатов. Второй проход: лёгкая нейронная сеть (с полным набором плотных признаков) сужает список до 50 кандидатов. Финальный проход: глубокая нейронная сеть (с полным набором плотных и разреженных признаков) выбирает топ-25 кандидатов.

They shared how the distillation model is trained: First, they record the (candidate) input and respective output from the teacher models. Then, the distillation model is trained on the recorded data to replicate the results, optimising for NDCG ranking loss over the teacher model’s output.

Они рассказали, как обучается дистилляционная модель: сначала они записывают входные данные (кандидатов) и соответствующий выход от моделей-учителей. Затем дистилляционная модель обучается на записанных данных, чтобы воспроизводить результаты, оптимизируя ранжирующую функцию потерь NDCG по выходу модели-учителя.

Further Reading:

Дополнительное чтение:

Слайды «Scaling Up Deep Learning By Scaling Down» Benchmark Analysis of Representative Deep Neural Network Architectures To prune, or not to prune: exploring the efficacy of pruning for model compression Deep compression: Compressing deep neural networks with pruning, trained quantization and Huffman coding. Distilling the Knowledge in a Neural Network

How (Not) To Scale Deep Learning in 6 Steps (24 June)

Как (не) масштабировать глубокое обучение за 6 шагов (24 июня)

Sean Owen, Principle Solutions Architect at Databricks, shares 6 tips on how to scale the training of deep learning models, in the following order:

Sean Owen, ведущий архитектор решений в Databricks, делится 6 советами о том, как масштабировать обучение моделей глубокого обучения, в следующем порядке:

These steps use a 10% sample of the data for quick experimentation and iteration (Step 0 is “Use a sample and work in memory”):

Эти шаги используют 10%-ю выборку данных для быстрого экспериментирования и итераций (Шаг 0 — «Используй выборку и работай в памяти»):

Используй GPU: облако упрощает доступ к ним. Используй раннюю остановку (early stopping): в приведённом примере это сократило время обучения с 60 до 18 минут при лучшей точности (76% против 76,7%). Используй большие размеры батчей, чтобы загрузить GPU по максимуму: это ещё сократило время обучения до 9 минут при схожей точности (76,3%)

These steps use the full data set to optimize for model performance:

Эти шаги используют полный набор данных для оптимизации производительности модели:

Используй Petastorm для итерации по большим данным: Petastorm был разработан Uber для итеративной подачи данных на основе Parquet в фреймворки глубокого обучения (изначально TensorFlow, теперь поддерживается и PyTorch) почти так же эффективно, как в памяти. Хотя мы используем в 10 раз больше данных, время одной эпохи увеличивается лишь в 11 раз. Точность поднимается до 83%. Используй несколько GPU: большинство современных фреймворков глубокого обучения позволяют использовать несколько GPU с минимальными изменениями кода. Используй Horovod на нескольких машинах: если нескольких GPU на одной машине недостаточно, рассмотри Horovod, который помогает масштабировать обучение на GPU по нескольким машинам.

Further Reading:

Дополнительное чтение:

How (Not) To Scale Deep Learning in 6 Easy Steps Meet Horovod: Uber’s Open Source Distributed Deep Learning Framework for TensorFlow (Теперь работает и с PyTorch, ура!)

Scaling Research to Production with PyTorch (26 Jun)

Масштабирование исследований до продакшена с PyTorch (26 июня)

Joe Spisak, PyTorch Product Lead at Facebook, drops knowledge on PyTorch and its ecosystem that helps simplify the training and deployment of models at scale.

Joe Spisak, руководитель продукта PyTorch в Facebook, делится знаниями о PyTorch и его экосистеме, которая помогает упростить обучение и развёртывание моделей в масштабе.

To reduce model size and computation requirements, PyTorch comes with in-built model pruning and quantization. Facebook has been deploying quantized models for years and it helps with inference at scale, especially on model devices.

Чтобы уменьшить размер модели и требования к вычислениям, PyTorch имеет встроенную обрезку и квантизацию моделей. Facebook годами развёртывает квантизованные модели, и это помогает с инференсом в масштабе, особенно на устройствах.

To train models at scale, there’s TorchElastic. It enables distributed PyTorch jobs in a fault-tolerant and elastic manner. This ensures that jobs don’t get disrupted when machine(s) go down, or when your AWS spot instance gets outbid.

Чтобы обучать модели в масштабе, есть TorchElastic. Он позволяет запускать распределённые задачи PyTorch отказоустойчивым и эластичным образом. Это гарантирует, что задачи не прерываются, когда машина(ы) выходят из строя или когда вашу AWS spot-инстанс перебивают по цене.

To deploy models at scale, there’s TorchServe which was jointly developed with AWS. It makes it easy to achieve lightweight serving, provides default handlers for common tasks, model versioning for A/B testing, etc.

Чтобы развёртывать модели в масштабе, есть TorchServe, разработанный совместно с AWS. Он упрощает лёгкое обслуживание моделей, предоставляет обработчики по умолчанию для распространённых задач, версионирование моделей для A/B-тестирования и т. д.

Further Reading:

Дополнительное чтение:

Introducing TorchServe: a PyTorch model serving framework TorchElastic on GitHub TorchServe on GitHub

Probabilistic Data Structures For Humans (25 June)

Вероятностные структуры данных для людей (25 июня)

Yeshwanth Vijayakumar, Project Lead/Architect at Adobe, shares about three probabilistic data structures for quick queries on large datasets. These data structures work because they’re monoids. Wait, what are monoids?

Yeshwanth Vijayakumar, руководитель проекта/архитектор в Adobe, рассказывает о трёх вероятностных структурах данных для быстрых запросов по большим наборам данных. Эти структуры работают, потому что они являются моноидами. Стоп, а что такое моноиды?

Here’s a simplified explanation. Monoids have the following properties:

Вот упрощённое объяснение. Моноиды обладают следующими свойствами:

Их можно комбинировать с другими значениями (того же типа), образуя новые значения (того же типа): int(1) + int(2) = int(3). Операции ассоциативны (порядок не важен): 1 + (2 + 3) = (1 + 2) + 3. У них есть нейтральный элемент: 1 + 0 == 1, где 0 — нейтральный элемент

Bloom filters check for membership in a probabilistic way (e.g., set.exist(item)). They can be used to answer questions like: Has the user viewed this product before?

Фильтры Блума (Bloom filters) проверяют принадлежность вероятностным образом (например, set.exist(item)). Их можно использовать для ответа на вопросы вроде: видел ли пользователь этот товар раньше?

If the result is False, then the item definitely does not exist in the set. If the result is True, there’s a possibility that the item does not exist in the set.

Если результат — False, то item точно отсутствует в set. Если результат — True, есть вероятность, что элемента в множестве всё же нет.

HyperLogLog counts the number of distinct elements in a set (e.g., set.count_distinct()). This can be used to answer questions like: How many unique users bought items A, B, and C?

HyperLogLog подсчитывает число различных элементов в множестве (например, set.count_distinct()). Это можно использовать для ответа на вопросы вроде: сколько уникальных пользователей купили товары A, B и C?

Because HyperLogLog is a monoid, we can count the number of unique users for each product, then perform a union across all the products.

Поскольку HyperLogLog — моноид, мы можем подсчитать число уникальных пользователей для каждого товара, а затем выполнить объединение по всем товарам.

Count-min sketch can be thought of as a frequency table of events in a stream of data. This can be used to answer questions like: How many items did this seller transact today?

Count-min sketch можно представить как таблицу частот событий в потоке данных. Это можно использовать для ответа на вопросы вроде: сколько товаров продал этот продавец сегодня?

It uses hash functions to map events to frequencies—thus, it uses sub-linear, instead of O(n), space. However, because it uses a hash function, it could over count some events due to collisions.

Он использует хеш-функции для отображения событий в частоты — поэтому он использует сублинейное пространство вместо O(n). Однако, поскольку он использует хеш-функцию, он может завышать счёт некоторых событий из-за коллизий.

Further Reading:

Дополнительное чтение:

Monoids Count-min Sketch Why Spark Can’t Fold Left

Improving Broadcast Joins In Apache Spark (25 June)

Улучшение broadcast join в Apache Spark (25 июня)

Jianneng Li, Software Engineer at Workday, shares practical insight and experiment results from optimising broadcast joins.

Jianneng Li, инженер-программист в Workday, делится практическими наблюдениями и результатами экспериментов по оптимизации broadcast join.

Is the broadcast join always faster (if the data can fit into memory)? Not necessary. There’s significant overhead to broadcast joins, which includes:

Всегда ли broadcast join быстрее (если данные помещаются в память)? Не обязательно. У broadcast join есть значительные накладные расходы, в том числе:

Сбор транслируемой (broadcasted) таблицы (на драйвере) Построение хеш-таблицы (на драйвере) Отправка хеш-таблицы исполнителю (executor) Десериализация хеш-таблицы (на исполнителе)

What’s the I/O cost difference between the (regular) sortMergeJoin and the broadcastHashJoin? Let’s assume we have two tables: A is the bigger table and B is the smaller table to be broadcasted. We also have n cores.

В чём разница по стоимости ввода-вывода (I/O) между (обычным) sortMergeJoin и broadcastHashJoin? Допустим, у нас есть две таблицы: A — большая таблица, а B — меньшая таблица, которая будет транслироваться. Также у нас есть n ядер.

For sortMergeJoin (SMJ), the total I/O cost is 3(A/n) + 3(B/n):

Для sortMergeJoin (SMJ) суммарная стоимость I/O равна 3(A/n) + 3(B/n):

По A: Чтение (A/n), Сортировка, Запись (A/n) По B: Чтение (B/n), Сортировка, Запись (B/n) Join: Чтение (A/n), Чтение (B/n), Соединение

For broadcastHashJoin (BHJ), the total I/O cost is: A/n + B/n + 2B:

Для broadcastHashJoin (BHJ) суммарная стоимость I/O равна: A/n + B/n + 2B:

По B: Чтение (B/n), Построение хеш-таблицы, Запись (B) Join: Чтение (A/n), Чтение (B), Соединение

Simplifying the above, the cost difference between both SMJ and BHJ is 2(A + B)/n - 2B. We can further simplify this by considering A as a magnitude of B: If A has 10 million rows and B has 2 million rows, then B = 1 and A = 5. Thus, the cost difference between SMJ and BHJ is (A+1)/n.

Упрощая вышесказанное, разница в стоимости между SMJ и BHJ составляет 2(A + B)/n - 2B. Это можно ещё упростить, рассматривая A как кратное B: если в A 10 миллионов строк, а в B — 2 миллиона строк, то B = 1 и A = 5. Таким образом, разница в стоимости между SMJ и BHJ составляет (A+1)/n.

When (A+1)/n is less than 1 (i.e., you have many cores), then SMJ will be faster. But if (A+1)/n is much greater than 1 (i.e., your left table is much bigger than the right, broadcasted table), then BHJ will be faster.

Когда (A+1)/n меньше 1 (то есть у вас много ядер), SMJ будет быстрее. Но если (A+1)/n намного больше 1 (то есть ваша левая таблица намного больше правой, транслируемой таблицы), то быстрее будет BHJ.

In an experiment where A = 60 million and B = 15 million (thus A+B = 5), we see that with more than 5 cores, SMJ does better (i.e., lesser time). Otherwise, BHJ does better.

В эксперименте, где A = 60 миллионов, а B = 15 миллионов (то есть A+B = 5), мы видим, что при более чем 5 ядрах SMJ показывает лучшие результаты (то есть меньше времени). В противном случае лучше BHJ.

As the number of cores exceed 5, sort-merge join performs better.

Когда число ядер превышает 5, sort-merge join работает лучше.

Similarly, keeping n (number of cores) constant at 18, we see that BHJ outperforms SMJ when A+B exceeds 20.

Аналогично, при постоянном n (числе ядер), равном 18, мы видим, что BHJ превосходит SMJ, когда A+B превышает 20.

As the left table A grows relative to the broadcast table B, broadcast-hash join performs better.

По мере того как левая таблица A растёт относительно транслируемой таблицы B, broadcast-hash join работает лучше.

However, with automatic broadcasting (via adjusting the broadcast threshold), make sure the smaller table is on the right. Even when the smaller table is on the left, Spark will try to broadcast the bigger table on the right, leading to inefficiency.

Однако при автоматической трансляции (через настройку порога broadcast) убедитесь, что меньшая таблица находится справа. Даже когда меньшая таблица слева, Spark попытается транслировать большую таблицу справа, что приведёт к неэффективности.

Workday is currently working on executor-side BHJ (Spark currently has driver-side BHJ) which has shown tremendous improvement in broadcast performance (SPARK-17556). Hopefully, this will be merged soon.

Workday сейчас работает над BHJ на стороне исполнителя (в Spark сейчас BHJ на стороне драйвера), что показало колоссальное улучшение производительности broadcast (SPARK-17556). Надеюсь, это скоро вольют в основную ветку.

There were other excellent sessions on optimising Spark but I didn’t have time to tidy up my notes on them. I recommended:

Были и другие отличные сессии по оптимизации Spark, но у меня не хватило времени привести в порядок заметки по ним. Я рекомендую:

Fine Tuning and Enhancing Performance of Apache Spark Jobs (25 июня): IBM рассказывает, что они сделали, чтобы сократить задачу с 4+ часов до 35 минут. How to Performance-Tune Apache Spark Applications in Large Clusters (25 июня): Uber делится приёмами по улучшению хранилища, CPU/времени выполнения, эффективности вычислений и памяти. Optimize Large Scale Graph Applications Using Spark with 4-5x Performance (25 июня): PayPal рассказывает о том, как улучшить масштабируемость больших графовых вычислений и оптимизацию продакшен-задач. Memory Optimization and Reliable Metrics in ML Pipelines at Netflix (26 июня): Netflix рассказывает о том, как они оптимизировали использование памяти для задачи, делясь подходами от перепартиционирования и прохода по промежуточным датафреймам до собственного управления памятью.

Further Reading:

Дополнительное чтение:

Performance Tuning: Converting sort-merge join to broadcast join What is the Difference between Broadcast hash join and Broadcast Nested loop join? SPARK-17556 Executor side broadcast for broadcast joins

Eager to apply this practical knowledge

С нетерпением жду применения этих практических знаний

The practical knowledge from Spark+AI Summit 2020 is invaluable. I’m eager to apply it to my work on spark pipelines and deep learning. Next week, I’ll share some application-specific talks at the conference.

Практические знания с Spark+AI Summit 2020 бесценны. Мне не терпится применить их в своей работе над spark-пайплайнами и глубоким обучением. На следующей неделе я поделюсь некоторыми специфичными для приложений докладами с конференции.

Spark+AI Summit 2020 was epic. Some great talks👇:

Improving Broadcast Joins In Apache Spark (25 June)

• broadcastHashJoin is not always faster; building hashtable has overhead
• More cores: sortMergeJoin performs better
• Bigger left table: broadcastHashJoin performs better

Spark+AI Summit 2020 был эпичным. Несколько отличных докладов👇:Improving Broadcast Joins In Apache Spark (25 июня)• broadcastHashJoin не всегда быстрее; построение хеш-таблицы имеет накладные расходы• Больше ядер: sortMergeJoin работает лучше• Больше левая таблица: broadcastHashJoin работает лучше— Eugene Yan (@eugeneyan) July 1, 2020

P.S., Are there any good sessions I missed? Let me know in the comments below =)

P.S. Я пропустил какие-нибудь хорошие сессии? Дайте знать в комментариях ниже =)

If you found this useful, please cite this write-up as:

Если это было вам полезно, пожалуйста, цитируйте эту статью так:

Yan, Ziyou. (Jun 2020). My Notes From Spark+AI Summit 2020 (Application-Agnostic Talks). eugeneyan.com. https://eugeneyan.com/writing/notes-from-sparkai-summit-application-agnostic/.

Yan, Ziyou. (Jun 2020). My Notes From Spark+AI Summit 2020 (Application-Agnostic Talks). eugeneyan.com. https://eugeneyan.com/writing/notes-from-sparkai-summit-application-agnostic/.

or

или

@article{yan2020spark, title = {My Notes From Spark+AI Summit 2020 (Application-Agnostic Talks)}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2020}, month = {Jun}, url = {https://eugeneyan.com/writing/notes-from-sparkai-summit-application-agnostic/} }

@article{yan2020spark, title = {My Notes From Spark+AI Summit 2020 (Application-Agnostic Talks)}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2020}, month = {Jun}, url = {https://eugeneyan.com/writing/notes-from-sparkai-summit-application-agnostic/} }

Join 11,800+ readers getting updates on machine learning, RecSys, LLMs, and engineering.

Присоединяйтесь к 11 800+ читателям, получающим обновления о машинном обучении, RecSys, LLM и инженерии.