Как использовать продукты Databricks для аналитики и машинного обучения

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.


Всем привет! Меня зовут Владимир Гавриш, я работаю в немецкой компании Soley на позиции Data Engineer / Data Analytic. Сертифицированный Developer for Apache Spark 3.0. Активно поддерживаю сообщество Kyiv Data Science, изучаю сферу Data Analytics, ML и, конечно, Data Science. В свободное время комбинирую CrossFit & Bike & Travel.


Эта статья о практическом применении продуктов компании Databricks для аналитики больших данных, используя парадигму параллельных вычислений Spark. Материал написан таким образом, чтобы был понятен для технических и нетехнических специалистов, так как его цель — ознакомить с технологиями параллельных вычислений и Databricks API.


Статья будет полезна:


  • Начинающим Data Engineer / Data Analytic / Data Scientics для знакомства с Databricks API и Spark.
  • Проектным менеджерам, сталкивающимся с задачами обработки BigData для общего понимания процесса.
  • Разработчикам, которым интересна аналитика и ML.


О компании Soley и задачах


Soley разрабатывает различные аналитические решения для производственных компаний, таких как Bosch Rexroth, Hansgrohe, Filtration Group и многих других. Это глобальные компании, выпускающие целый ряд продуктов на сотнях производств, раскиданных по всему миру, генерируя при этом многомиллионные продажи. Это, естественно, постоянно генерирует много данных.


Так, например, обрабатывая массивы данных о каждом компоненте продукта клиентов (например, из чего он состоит, как и где производится, кем поставляется), совмещая с данными продаж и дистрибуции конечного продукта, мы строим кастомизированные аналитические решения, которые позволяют ответить примерно на такие вопросы:


  1. Какие продукты необходимо вывести с производства в связи с низкой взаимозаменяемостью составляющих компонентов, низкой маржинальностью готового продукта, высокой эксклюзивностью поставщиков или другими динамическими факторами.
  2. Как изменение в портфеле продуктов из первого пункта повлияет на общие результаты компании в будущем.
  3. Возможные комбинации сценариев из пунктов 1 и 2 и выбор оптимального варианта.


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


В самом общем виде такой Data Pipeline выглядит примерно так (4):



Получая структурированные/неструктурированные данные из разных источников (Bronze), они проходят подготовку и очистку (Silver stage) и сохраняются (Gold) для конечной аналитики.


Практически все 3 этапа реализуются в DataBrikcs, который обеспечивает совместную работу аналитиков, data инженеров и проектных менеджеров. Мы также используем Azure cloud, Data Factory, Azure SQL DB на различных этапах разработки для реализации всего цикла — от получения данных до предоставления результатов клиентам в виде web-приложения.


Distributed storing & computing era


В нашем комьюнити (3) недавно проходила встреча (5), которая собственно и послужила причиной написания данной статьи, где мы говорили о предыстории развития парадигмы распределенных вычислений.


Итак, в 2003 году выходит статья сотрудников компании Google (6), которая описала уже реализованную файловую систему хранения данных GFS (7), гарантирующую защиту от сбоев и потерь данных. Сама идея не нова — давайте будем хранить копии (replicas) данных в разных местах одновременно и в случае сбоя просто брать другую доступную копию. Физически данные хранятся на разных компьютерах, объединенных в одну сеть. Когда один узел выходит из строя, вам нужно его просто заменить, без особых дополнительных действий, и система автоматически включит новый узел в работу.


Вдохновленные данным подходом, в 2005 начали разрабатывать проект Hadoop, который позднее был передан в Apache Software Foundation вместе с патентом на использование парадигмы MapReduce (8). Отличительная особенность Hadoop была в том, что эта система не только распределенно хранила файлы, но распределенно их обрабатывала.


Общая схема работы Hadoop (Yarn) (9) :



Apache Hadoop как open-source проект в итоге вобрал в себя другие проекты в этом направлении по организации распределенного хранения данных и их вычислений:


  • Hive от Facebook — хранилище данных с поддержкой T-SQL like запросов.
  • Avro — эффективный формат сериализации распределенных данных.
  • HBase — нереляционная (No-SQL) распределенная база данных.
  • Spark (10) — распределенные вычисления в оперативной памяти в парадигме кластерных вычислений MapReduce.


В контексте статьи нас будет интересовать только Apache Spark, который оказался наиболее успешным для решения задач аналитики и анализа данных, в состав его API входят модули:


  • Spark Core — распределенные вычисления с поддержкой API языков программирования Java, Python, Scala, .NET, R.
  • Spark SQL компонент с абстракций данных DataFrames.
  • Spark Streaming компонент выполнения потоковой аналитики в режиме реального времени.
  • MLlib компонент для машинного обучения для распределенной архитектуры Spark на основе оперативной памяти.
  • GraphX — это распределенная среда обработки графов в Apache Spark.


Оригинальный разработчик Spark Matei Zaharia (11), используя основные компоненты этого open-source проекта, вместе с наработками файловой системы Hadoop создает в 2013 коммерческую компанию Databricks (12).


В каком-то смысле Databricks стал одной из верхних ступеней эволюции Spark, сделав его более доступным коммерческим продуктом.


Databricks API (13)


Давайте разберем основной интерфейс Databricks. Он выглядит достаточно просто, основные элементы — Notebook, Data, Clusters.



Notebook — вы создаете рабочую среду для вычислений, где каждая ячейка может выполнить код на Python, Scala, T-SQL, Java. Нотбуки как интерфейс, наверное, знакомы многим и используются в Google Colab, kaggle notebook, juniper notebook, Azure Notebook и во многих других продуктах.


Вот пример Notebook, где мы создаем DataFrame на Python в одной ячейке и получаем результаты SQL-query в следующей. Как уже говорилось, DataBricks / Spark поддерживает 4 API (Java, Scala, Python, SQL).



Закладка Data — интерфейс для загрузки файлов. Обычно это какие-то небольшие наборы данных в форматах csv, json, txt, excel.


Небольшое отступление. Хотя сам Databricks имеет свою файловую систему DBFS file system (14), рекомендуются хранить анализа файлы вне ее. Идея в том, что, разделяя вычислительные ресурсы и ресурсы по хранению данных, можно более эффективно контролировать расходы и быть более в гибким в выборе комбинаций вариантов. В DataBricks вы платите только за время работы кластера (вычисления), а исходные данные и результаты анализа, базы можно хранить где удобно / выгодно. Хотя для небольших, временных datasets можно это делать и в DBFS.


Давайте рассмотрим пример кода, когда мы загрузили файл в DBFS и проверяем его наличие, выводим его содержание. Сначала через через Data загружаем файл csv и при помощи утилиты dbutils проверяем его существование.


dbutils.fs.ls('/FileStore/tables/ProductCategory.csv')


Читаем его содержание в память и выводим на экран.


data_df = spark.read.csv('/FileStore/tables/ProductCategory.csv', header=True)
data_df.display()


Результат:



Мы прочли csv-файл и записали его в DataFrame. Но не все так просто, как на первый взгляд!


Тут есть тот magic, о котором мы говорили в начале. Эта задача выполняется несколькими отдельными процессами (отдельная JMV (16) для каждого).


Параллелизация происходит под капотом в таком порядке:


  1. Driver разбивает задачи на Jobs в виде DAG (17) и отправляет каждой JMV (ака Executor) для выполнения.
  2. Executor разбивает задачи на Stages и далее на Tasks.
  3. Tasks применяются к каждой partition данных (об этом позднее)


Справа показан лог Spark UI, раздел Jobs, где фиксируются все логи, статистика и много другой полезной информации.


Общая схема выполнения задач, как в Databricks / Spark, выглядит так:



Задачи разбиваются так, чтобы они могли быть применены к каждой части данных (partition).


В данном случае файл небольшой и при чтении была создана всего одна партиция (выделено розовым).


Давайте проведем эксперимент — перезапишем файл из одной партиции в 10, и посмотрим, сколько Job/Stage/Task нам потребуется для выполнения.


Код тогда такой:


Создаем новый dataframe и разбиваем его на 10 partitions по колонке ’ProductCategoryID’ (оранжевым).


data_repartioned_df = data_df.repartition(10, ['ProductCategoryID'])


Проверяем количество partitions (их уже 10) (оранжевым)


data_repartioned_df.rdd.getNumPartitions()


Просто выводим результаты и видим что уже Spark запустил 4 Jobs и 7 Stages (розовым)



Такая параллелизация позволяет выполнять значительные вычисления быстро и минимальными ресурсами, используя различные подходы к оптимизации и адаптивные cost-based модели к построению запросов. (18, 19, 20, 21).


В этом году был поставлен Мировой рекорд 100TB TPC-DS. В одном из тестов DataBriks за счет оптимизации запросов смог прочесть запрос к базе размером 504 terabytes (более 11 trillion rows) с предикатом WHERE src_ip = x AND dst_ip = y за несколько десятков секунд (24) !


Cluster — создание группы вычислительных ресурсов. Тут много вариантов для выбора, подстройки. Но главное, тип кластера и количество ресурсов, которые вы ему задаете. Обычно standard варианта вполне достаточно, и как на картинке видно, мы выбрали 2 worker с возможностью scale до 8 workers.



Сколько же это реальных ресурсов в парадигме параллельных вычислений? Поскольку Spark производит все вычисления в оперативной памяти, реализуя собственную систему memory management (24), мы можем заранее рассчитать вычислительные способности, подобрав их исходя из текущих задач.


На картинке выбрана самая базовая конфигурация кластера — от двух worker node, с возможностью автоскейлинга до 8 worker node, по 14 GB оперативной памяти и 4 core для каждого, плюс Driver node с такими же параметрами.


Итого параметры:


2-8 Workers: от 28 до 112 GB Memory, 8 — 32 Cores


1 Driver: 14 GB Memory, 4 Cores


Конечно, не вся оперативная память будет использовать для вычислений, так как часть памяти резервируется для внутренних процессов, а памяти непосредственно для вычислений у нас будет примерно от 14 G до 56 G RAM. Возьмем конфигурацию, когда кластер задействует максимальные ресурсы и запускает по 2 executors на каждой worker node (7 GB RAM, 2 core каждый).


В итоге нам будет доступно 8 машин * 2 executor на каждый * 2 core = для выполнения 32 задач параллельно (1 задача на 1 core), обрабатывая в памяти ~ 56 GB данных. Как мы уже говорили, Spark разделяет все данные на партиции (partitions) и обрабатывает каждую из них отдельно, и по сути данная конфигурация позволит обрабатывать 32 партиции одновременно, общим размером в 56 GB.


Это не означает, что закончив одну задачу, executor прекратит работу, Driver, который управляет процессами распределения всех задач, отправит следующую доступную для выполнения задачу, вплоть до полного выполнения их всех.


Такая конфигурация достаточна для многих аналитических решений, и будет стоить $0.40/DBU-hour в час (25), что при полной загрузке 24/7 кластера, что может составлять от 220 usd до 450 usd в месяц.


Для своих тестов вы можете попробовать community edition на 14 дней в бесплатном режиме (13). Есть также возможность подключить тестовый период и через известных cloud провайдеров (Azure, AWS, GCP), что тоже бесплатно.


Итак, мы разобрали, как выглядит Databricks API, увидели основные его элементы — Notebooks, Data, Clusters. Можем начинать использовать!


Case 1. Ежедневное обновление курсов валют.


Давайте применим Databricks в решении конкретной задачи. Хотя это совсем Big Data analytics и здесь собственно параллелизация не нужна, мы используем этот case для закрепления знакомства с API и отдельными деталями его реализации.


Taks: Автоматически ежедневно обновлять курсы валют и записывать данные в удобном хранилище для последующего использования внутри компании. Мы знаем, что исторические данные курсов валют используются для различной аналитики продаж, себестоимости, бухгалтерского учета, и их нужно постоянно обновлять и хранить.


Эту задачу можно решить при помощи DataBricks API.


Первый этап. Создаем ноутбук, где реализуем решение на Python, с использованием job clusters, которые в 5 раз дешевле обычных (25, см. Light Job Computes Clusters), запускаются автоматически и не требуют настройки.


Код простой и понятный с self-expanatory комментариями. В правом верхнем углу Scheduler, в котором мы задаем период обновления и apy_key от одного публичного сервиса.



В результате (см. после print(results_fixer), строчка 32) у нас каждое утро будет json с данными валютных пар к евро. Теперь нам нужно определить, где и как это хранить, обновлять и предоставлять API для других пользователей.


Второй этап. Сохраняем результаты одного дня в DBFS системе (26) и создаем SQL таблицу, которая будет постоянно доступна всем пользователям, имеющим доступ к данному workspace (обычно это все сотрудники одного подразделения компании).



В строках 1-4 все должно быть понятно, а вот к 5-6 строчкам присмотримся внимательней. Тут происходят 3 операции:


  1. sc.parallelize([currency_results]) Тут sc (spark context (27)) при помощи метода parallelize транслирует json в абстракцию Spark RDD. RDD в упрощенном виде и есть партиции (partitions), о которых мы уже говорили, то есть наш json теперь распределен по узлам кластера и позволяет работать с ним параллельно.
  2. Spark.read.json метод читает этот распараллеленный json и создает Spark DataFrame для дальнейшей удобной с ним работы.
  3. results_fixer_df.display()— это action, которая выводит первые 1к значений Spark DataFrame в читаемом виде.


Отступление — «Все операции в Spark делятся на actions / transformations. Transformations выполняются в lazy mode» (28) — и первые 2 операции являются Transformations, не требуют ресурсов и не запускают каких либо задач! То есть вы не используете какие-либо ресурсы вообще.


Основные ресурсы будут затрачены на .display()! Неожиданно!


Такой подход позволят значительно экономить и запускать процессы, именно когда необходимо, это также облегчает debag.


Сам Spark DataFrame, упомянутый выше, это удобный объект, поддерживающий много функций (29), легко трансформируется в json, parquet, csv, pandas объекты и т.д. Для него существуют отдельные модули, которые делают его еще более гибким, например, проект Koalas (похоже Pandas для Spark) (30).


Итак, Display() нам показал строчку с одной датой и 7 колонками, где 6 колонок — это искомые курсы валют.


Далее мы определяем путь, где нам хранить эти данные. Для простоты используем сам workspace Databricks и сделаем его файловой системой DBFS (это не рекомендуется для business critical data), сохраним в формате delta. Давайте разберем строчку 4 CMD 3:


Results_fixer_df 
.write – метод для записи данных
.format('delta') – формат delta, позволяет сохранять метаданные (31)
.mode("append") – мы добавляем записи
.option("overwriteSchema", "false") – не перезаписываем схему, если она изменена
.option("path", path) – путь, куда мы записываем, может быть и внешним
.saveAsTable('default.exchangeratetable') – создаем в базе данных 'default` таблицу.


Теперь каждое утро данные будут обновляться, сохраняться на диске системы и предоставляться пользователям как таблица — что собственно и показано в CMD 4. Мы переходим в sql и читаем все записи.


Мы также можем прочесть эти же данные непосредственно с диска, используя просто к ним путь.



Если взглянуть внимательней, можно заметить, что нам также становится доступна вкладка history формата delta которая отражает все изменения, происходившие в файлах в указанном path. В частности, есть записи о создании таблицы и ее обновлении методом append и т.д. Display() идентичен результатам SQL-запроса выше.


Итак, в этом примере мы создали микро-сервис на основе DataBricks-ноутбука, который ежедневно будет обновлять курсы валют, записывать их на диск и обновлять таблицу курса валют для пользователей workspace данной организации.


Лог выполнения этой рутины будет выглядеть так:



Сам тип задач, которые можно реализовать подобным образом, достаточно широкий. Такие решения легко поддерживать, удобно совместно работать с другими разработчиками, легко мониторить результаты. В каком-то смысле такой подход к организации разработки может «захватить мир» ;) (32)


Case 2. Предсказание образа жизни по данным fitness tracker.


Давайте решим простую задачу Data Science: предскажем образ жизни владельца fitness tracker. Собирая био-параметры пользователей с данных устройств, можно успешно их классифицировать и предсказывать, какой образ жизни (lifestyle) примерно будет вести новый пользователь.


Итак, у нас есть 2 дата-сета (33):


Логи устройств (трекеров) со следующими данными:


  • id пользователя;
  • avg(BMI) индекс массы тела;
  • avg(active_heartrate) частота сердечных сокращений при активности;
  • avg(resting_heartrate) частота сердечных сокращений в состоянии покоя;
  • avg(VO2_max) максимальное потребление кислорода;


База пользователей:


  • _id пользователя;
  • First_name имя;
  • Last_name фамилия;
  • Lifestyle образ жизни (варианты);
  • Занятие силовыми видами спорта;
  • Кардио-тренировки;
  • Сидячий образ жизни.


В базе пользователей данные предварительно размечены, то есть типичная задача supervised learning (34).


Делаем новый ноутбук, загружаем данные в DBFS, читаем и переводим в удобную для работы форму — Spark Data Frame.



Смотрим, как выглядит первая строчка из лога устройства — id (похоже на hash) и floats для параметров трекера. Категориальных данных нет, что упрощает жизнь.


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


Объединяем дата-сеты по `_id` и сразу используем встроенный функционал для визуализации Bar Chart.



Сразу очевидны различия между данными группами, почти все параметры неплохо отделены и значит, даже линейные модели будут хорошо работать. Для себя отмечаю, что кардио-тренировки дают, наверное, лучшую комбинацию параметров BMI и потребления кислорода (надо больше бегать?).


Давайте посмотрим на распределение параметров относительно образа жизни. Для визуализации используем Searborn и временно переводим Spark Data Frame в Pandas Data Frame для корректной работы этой библиотеки.



За исключением BMI, различия на этом графике еще более различимы. Вероятно, индекс массы тела не так сильно связан (определяется) с типом спортивной активности, как другие факторы, например, способность максимального потребления кислорода.


Начинаем готовить наши данные для подачи в модель.



Несколько комментариев по коду:


1.ML в основном потребляют numerical values, поэтому переводим текстовые значения типов lifestyle в числовые (0, 1, 2). Делаем это просто, без дополнительных библиотек, сохраняя верность параллельным вычислениям.


2. Известно, что Spak Data Frame объекты — это вроде immutable. Поэтому мы часто просто переопределяем это Data Frame, когда нам нужно добавить к нему новую колонку или изменить значения в существующей. Можно, конечно, делать и так df = df.withColumn(‘New/Old’, Transform(‘New/Old’), но есть шанс ошибиться.


3. Видим простой способ работы функций с колонками, например

F.when
.when</strong>(условие 1, значение 1)
.when</strong>(условие 2, значение 2)
.otherwise</strong>(значение 3)


Очень напоминает T-SQL, смешанный с Python.


Тут же есть метод для DataFrame .drop(колонки), который убирает уже не нужные нам колонки. Все это можно делать через dot notation, составляя совершенно разные transformation, которые, как мы помним, не будут выполняться, пока не вызван любой метод типа action. (см. case Курс валют и (28))


4. Еще один из полезных UE от Databricks — возможность сразу увидеть схему Data Frame: названия колонок и тип данных в них без дополнительных движений. (выделил курсором)


5. Хотя данных не много, но в статье много о parallel computation, решил показать, как выглядят partitions и их размер.


  • Сейчас весь Data Frame в одной партиции, а значит параллелизации нам не видать.
  • Давайте разобьем их на 4 партиции и используем `id` как ключ. Используем метод .repartiotion() (мы уже это делали выше).
  • Видим, что уже у нас 4 партиции с не совсем равномерным распределением данных.


Зачем это нужно? Коротко, когда данных много, а трансформации их сложная, возможно, вы начнете задумываться о Spark tuning, и repartiotion() будет вам в помощь (35, 36, 37).


Поскольку мы изначально решили использовать максимально параллелизацию, используем библиотеки, в которых это реализовано, так сказать Native ML Spark.



Здесь, при помощи метода VectorAssembler, мы собираем все numerical features, и затем случайным образом разбиваем наши данные на две части train / test в пропорциях 80% / 20%. Что именно делает VectorAssembler и зачем он (38)? По сути, он собирает все признаки в один вектор для подачи ML-модели. Как выглядит такой вектор — вы можете увидеть в колонке ‘features’.


Переходим непосредственно к обучению моделей. Для чистоты эксперимента используем 3 разных модели и при помощи mlflow будем сохранять результаты, метрики и модели.


Конечно нужно было бы рассмотреть отдельно несколько важных ML-вопросов — выбор моделей, метрики, feature engineering, поиск гиперпараметров для каждой модели, но тогда размер статьи выйдет за разумный предел, поэтому оставляем данные темы для будущих выпусков.



Может показаться, что много кода, но это просто copy-paste одного решения, где все интуитивно должно быть понятно:


  • В 6 строчке выбираем одну из метрик для задач классификации, например F1.
  • В 8, 23, 38 строчках просто запускаем процесс логирования от mlflow.
  • В 9-16 строчках инициализируем модель, обучаем ее на train данных и пытаем предсказать на результаты, считаем нашу метрику (повторяем это в 24-31 и 38-45 строчках для других моделей).
  • Строки 18-20 логируют модель и метрики (то же самое 33-35, 47-49) .


В левом верхнем углу у нас появляются результаты наших экспериментов, и перейдя во вкладку Experiments, можно увидеть их все сразу. MlFlow позволяет логировать каждую новую версию модели со своим набором features, гиперпараметрами и любыми другими изменениями, которые вы вносите в процессе поиска лучшей модели.



Эксперименты выглядят примерно так — время, описание, версии, метрики и т.д. Из всех экспериментов Random Forest дает нам лучшую метрику на тестовых данных, аж в 0,96 F1 score. Такие результаты без тюнинга для меня выглядит так, будто эта модель переучилась и, возможно, требуется дополнительные усилия / исследование.


Причины? Возможно, данных не так много, чтобы получить больше вариативности (см. Biase & Variance trade-off (40)), возможно, они хорошо разделены для задач классификации (отчасти это видно на графиках выше), но наша базовая задача решена и для использования в production берем Random Forest.


Кликаем на эту модель в интерфейсе Experiments в колонке Models и переходим в интерфейс управления моделью.



Databricks сохраняет все артефакты модели и сразу готов ее использовать для внешнего пользования. Для этого вам нужно зарегистрировать модель в model registry и при помощи REST API использовать по назначению — предсказывать тип lifestyle.


Но мы пойдем простым путем — давайте создадим искусственный лог одного трекера и предскажем это прямо в нашем ноутбуке.



Создаем данные при помощи уже знакомого Spark Data Frame и переводим все features в один вектор (как мы уже делали на этапе подготовки данных). Используем метод объекта .transform (aka .predict()) и получаем, что данный вымышленный пользователь принадлежит к классу 1, то есть с 87%-вероятностью он занимается силовыми видами спорта.


Итак, в этом кейсе мы решили задачу предсказания классификации lifestyle при помощи Databricks API, используя подходы параллельных вычислений и native-библиотеки Spark. В итоге мы получили data pipeline, который сможет обрабатывать значительные объемы данных от трекеров пользователей и, возможно, давать необходимую бизнесу информацию.


Выводы


  1. Databricks может решать разнообразные задачи аналитики и Data Science при помощи интуитивного API, которое содержит исчерпывающий набор инструментов: вычислительных, операционных и файловых.
  2. Парадигма параллельных вычислений, которая находится «под капотом» у Databricks, позволяет решать задачи Big Data, не применяя внешних библиотек, с хорошими результатами по производительности.
  3. Поддержка API Java, Scala, Sql и Python и собственная распределенная база данных Hive облегчает миграцию, кастомизацию решений и делает удобной совместную работу дата-аналитиков, дата-инженеров и дата-scientists.
  4. Наличие отдельных модулей ML, Data Science, Analytics, Sql module в одном workspace организации позволяет эффективно решать задачи безопасности, совместной работы, версионирования, поддержки legacy projects.
  5. Интеграция с известными cloud providers — AWS, Azure, GCP — дополняет цикл разработки необходимыми элементами для реализации полноценного конечного продукта для потребителя.


К недостаткам, чтобы быть максимально объективным, я бы отнес следующее:


  1. Перейдя на Databricks, возможно, вам будет сложно совместить весь функционал в каком-то другом продукте. Может возникнуть некоторая форма зависимости. Компания старается закрыть все потребности в аналитике, по сути работая по модели Iaas (инфраструктура как сервис). Естественно, такая зависимость — это дополнительный риск, особенно, если ваш data pipeline критически важен для бизнеса и должен работать <= 99.999% и зависит от одного провайдера.
  2. Стоимость использования может стать проблемой, если разрабатываемые не проходят контроль на эффективность, code review и бизнес анализ конечного решения.


Спасибо за ваше время, буду рад комментариям и рекомендациям. Если заинтересовали отдельные вопросы, и они заслуживают написания отдельной статьи — дайте знать.


P.S. Если интересна тема Data Science, добро пожаловать в группу Kyiv Data Science.


Полезные материалы:


  1. Код ноутбуков (в .html и .dbc форматах) и материалы доступны здесь: github.com/...​ience/tree/master/kds/dou
  2. Книга Learning Spark Lightning github.com/...​st Big Data Analysis .pdf
  3. Презентация Scalable-ML github.com/...​oks/Scalable-ML-3.4.1.pdf
  4. Книга Spark The Definitive Guide github.com/...​-The Definitive Guide.pdf
  5. Академия Databricks academy.databricks.com


Ссылки:


  1. Soley www.soley.io/en
  2. My certification credentials.databricks.com/...​0c2c528f?record_view=true
  3. Kyiv Data Science community t.me/kyivdatascience
  4. Productionizing Machine Learning with Delta Lake, databricks.com/...​ning-with-delta-lake.html
  5. «Databricks: як, навіщо та що під капотом» Hadoop, Hive, Pyspask, Scala, SQL, Python dou.ua/calendar/41718
  6. Оригинальная статья The Google File System, static.googleusercontent.com/...​/archive/gfs-sosp2003.pdf
  7. Google file system, en.wikipedia.org/wiki/Google_File_System
  8. MapReduce, en.wikipedia.org/wiki/MapReduce
  9. Hadoop, hadoop.apache.org/...​doop-hdfs/HdfsDesign.html
  10. Apache Spark en.wikipedia.org/wiki/Apache_Spark
  11. Matei Zaharia en.wikipedia.org/wiki/Matei_Zaharia
  12. Databricks, en.wikipedia.org/wiki/Databricks
  13. 14 дней пробного периода DataBricks databricks.com/try-databricks
  14. DBFS docs.databricks.com/...​tabricks-file-system.html
  15. Jupyter Notebook jupyter.org
  16. Java virtual machine en.wikipedia.org/...​wiki/Java_virtual_machine
  17. DAG en.wikipedia.org/...​ki/Directed_acyclic_graph
  18. Z-Ordering docs.databricks.com/...​ti-dimensional-clustering
  19. Project Tungsten databricks.com/...​closer-to-bare-metal.html
  20. Adaptive query execution docs.databricks.com/...​latest/spark-sql/aqe.html
  21. Cost Based Optimizer databricks.com/...​-in-apache-spark-2-2.html
  22. Databricks Sets Official Data Warehousing Performance Record databricks.com/...​g-performance-record.html
  23. Processing Petabytes of Data in Seconds with Databricks Delta databricks.com/...​ith-databricks-delta.html
  24. Spark Architecture 0×0fff.com/...​rk-architecture/#more-188
  25. DataBricks pricing azure.microsoft.com/...​icing/details/databricks
  26. Не рекомендуется хранить критически важные данные в DBFS docs.gcp.databricks.com/...​and-usage-recommendations
  27. Spark Context spark.apache.org/...​pyspark.SparkContext.html
  28. Lazy transformation spark.apache.org/...​guide.html#rdd-operations
  29. Spark Data Frame functions spark.apache.org/...​tml#pyspark.sql.DataFrame
  30. Koalas koalas.readthedocs.io/en/latest/index.html
  31. Что такое Delta format delta.io
  32. Оценка DataBricks как компании в 38 млрд. отчасти это подверждает. techcrunch.com/...​-it-blasts-past-600m-arr
  33. Источник данных Databricks academia academy.databricks.com
  34. Unsupervised Learning en.wikipedia.org/wiki/Supervised_learning
  35. Should I re-partition? towardsdatascience.com/...​-repartition-836f7842298c
  36. On Spark Performance and partitioning strategies, medium.com/...​g-strategies-72992bbbf150
  37. Spark Tuning spark.apache.org/...​l-performance-tuning.html
  38. Spark Vector Assembler spark.apache.org/...​ures.html#vectorassembler
  39. ML Flow mlflow.org
  40. Bias—variance tradeoff en.wikipedia.org/...​ki/Bias—variance_tradeoff

👍ПодобаєтьсяСподобалось9
До обраногоВ обраному4
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Підписатись на коментарі