Тази публикация е съавтор на Micah Groh, учен по данни, и Michael Green, старши учен по данни.
Изкуствен интелект. Дълбоко обучение. Голяма информация. Потърсете в Google някоя от тези фрази (или gulp, и трите наведнъж) и незабавно ще бъдете затрупани с резултати, които твърдят, че ви дават ноу-хау, способността или и двете, за да анализирате и обучавате вашите данни, използвайки техните „ платформа "всичко в едно". Няма да твърдим, че знаем всичко, но с нашия опит в изграждането на „Empower Data Platform“ можем да посочим много примери, в които сме помогнали на нашите клиенти да преборят своите байтове, за да постигнат резултати. Нашите публикации в блога имат за цел да насочат специалистите по данни и инженерите да направят информиран избор.
Apache Spark е широко приет като златен стандарт с отворен код за инженерни данни и изследвания и разработки на изкуствен интелект в света на бизнеса [1, 2, 3]. Наскоро видяхме статии за преместване от Spark към друга платформа за данни като Снежинка [1, 2]. От „пускането на Snowpark в началото на годината“, който беше създаден, за да разшири работните процеси на AI/ML, все още не сме намерили задълбочена оценка на функционалността на AI/ML на Snowflake. За да коригираме това, ние решихме да предоставим на критичното окосравнение рамо до рамо, обхванато от обучение на модели на изкуствен интелект между Databricks (разработчици на най-новата еволюция на Apache Spark) и Snowflake. В тази публикация искаме да обсъдим дали Snowflake със Snowpark е силен конкурент по отношение на работните потоци с изкуствен интелект.
TLDR; не е. Продължете да четете за нашата разбивка.
Сравнение на работното пространство
Databricks
Databricks използва управлявани клъстери Spark, изградени върху „data Lakehouse“. Тази архитектура позволява общо съхранение на данни, анализ на данни, наука за данни, инженеринг на данни и машинно обучение да бъдат обединени в една платформа. Основният интерфейс за разработчици е твърде познатият бележник, който има вградена Git интеграция и може да се редактира от множество сътрудници едновременно. В допълнение към Python, преносимите компютри позволяват изпълнение на markdown, R, SQL, Scala и Shell, всички с интегрирана документация. Работното пространство поддържа пълната екосистема на PyPI от библиотеки на Python, а Linux пакетите могат да бъдат инсталирани с помощта на персонализирани „скриптове за инициализация“. Струва си да се спомене, че потребителите могат също да разработват в рамките на любимия си IDE или преносим сървър и да използват Databricks Connect, за да планират задания на Spark в клъстера Databricks.
Снежинка/Снежен парк
Snowflake е склад за данни, чийто основен интерфейс е работен лист само за SQL, който може да изпълнява команди върху SQL таблици. Те нямат собствена Git интеграция и множество потребители не могат да редактират съвместно работен лист, както в Databricks. API на Snowpark позволява на потребителите да дефинират трансформации на данни в тяхната локална среда, които да се използват в таблици, съхранявани в Snowflake. Това означава, че данните, манипулирани със Snowpark, остават в рамките на Snowflake. Snowpark също така позволява персонализирани функции да бъдат качени в средата за изпълнение на Snowflake и след това извикани да се изпълняват в склад на Snowflake. Разгледахме библиотеката на Snowpark Python, но Snowpark също поддържа SQL, Scala и Java. Клъстерите Snowflake поддържат няколко Python пакета на трети страни, предоставени и изградени от Anaconda, но списъкът е ограничен и не всички версии на библиотеката се поддържат.
Победител: Databricks
Snowpark получава точки, когато ви позволява да се развивате от комфорта на собствената си среда/език за разработка. В същото време същото прави Databricks, използвайки Databricks Connect. Колаборативните преносими компютри на Databricks са огромен плюс, както и естествената интеграция на Git. Разнообразието от езици, поддържани от преносимите компютри на Databricks, се превръща в изключително удобство за различни разработчици и случаи на употреба, а отстраняването на грешки е лесно. Освен това Databricks има по-добра поддръжка на пакети.
Управление на хардуера
Databricks
Клъстерите Databricks могат да бъдат изградени, за да се справят както с натоварванията на CPU, така и с GPU. В допълнение към стандартния потребителски интерфейс на Databricks има също инструменти Databricks API и CLI, които могат да манипулират ресурсите и модулите на Databricks в работно пространство от друга машина. Можете да изберете тип и брой възли за вашите клъстери в Azure. Администраторите могат да настроят шаблонни клъстерни правила, за да намалят претоварването на опциите за обикновените потребители. Клъстерите могат да бъдат специализирани за генерализирани или ML работни натоварвания. Клъстерите за работни места могат да се използват за оптимизиране на разходите, както и за определяне на случаи.
Снежинка/Снежен парк
Snowflake, от друга страна, поддържа само CPU клъстери. Можете да изберете размери на клъстери, определени от тениска, но освен това няма много възможности за избор. SnowSQL, CLI клиентът на Snowflake, ви позволява да правите API извиквания към вашия клъстер, за да премествате данни, заявки и манипулиране на складове от разстояние. В Snowflake можете да настроите планирани задачи за изпълнение (еквивалент на клъстери за работа в Databricks).
Победител: Databricks
Парализата на избора е реално нещо, но не и когато трябва да оптимизирате клъстер за обучение за машинно обучение. Всяка компания има различна философия относно конфигурацията: Snowflake премахва много възможности за избор вместо вас, докато Databricks ви предлага много. В зависимост от нуждите ви може да предпочетете едно пред друго. Databricks обаче поддържа графични процесори в тяхната среда, което е от решаващо значение за обучението на AI за голям модел, особено в пространствата за компютърна визия и обработка на естествен език.
Обучение с един възел
Databricks
Обучението с един възел в Databricks не се чувства по-различно от обучението на преносим компютър Jupyter във вашата местна среда. Можете да разработите модел и да го стартирате в бележника, като използвате всички популярни ML и DL рамки, като Scikit-Learn, PyTorch или Tensorflow. Можете също така да стартирате бележника си като работа и Databricks ще върти нагоре и надолу ресурси, за да се справи с обучението. Всички данни в работното пространство на Databricks са достъпни за вашия бележник. Имайте предвид, че случаят на използване по подразбиране на Spark е да се извършват изчисления с множество възли. Потребителите на Databricks, които искат да провеждат разпределено широкомащабно обучение или обучение с един възел, са еднакво у дома. Обсъждаме разпределеното обучение в следващия раздел за сравнение.
Снежинка/Снежен парк
Snowflake прави обучение с един възел малко по-различно. Има две опции, за които сме запознати, за да направим това в клъстерите на Snowflake: дефинирани от потребителя функции и съхранени процедури.
Потребителски дефинирани функции (UDF)
UDF са ценни за дефиниране на сложни трансформации на Dataframes. Snowpark поддържа скаларни UDF [1, 2], които могат да приемат ред като вход и да извеждат нова единична стойност. UDF не са стандартна техника за обучение на модели, но Snowflake дава пример за това как да използвате UDF за паралелно обучение на много модели за прогнозиране на времеви редове. В този пример те изравняват данните за обучение и изводи в списъци, преди да ги предадат на UDF със Snowpark. Веднъж в рамките на UDF, данните се изравняват обратно в Dataframes и се предават на тренировъчния цикъл на модела. Веднъж обучен, моделът може да прави изводи от данните за извода и UDF може да вмъкне прогнози в желаната таблица.
Ако горният абзац ви изглежда заплетен, не сте сами. Отне ни доста опити, за да разберем и изградим това сами. Процесът на изравняване на Dataframes и връщането им обратно е податлив на човешка грешка и не е интуитивен. Отстраняването на грешки може да бъде предизвикателство, тъй като кодът се изпълнява в средата за изпълнение на Snowflake, която, тъй като е предназначена за SQL, не винаги е полезна при извеждане на грешки на Python. Освен това UDF са ограничени до едноминутно време за изпълнение, което ограничава този метод до най-малките модели и/или набори от данни. UDF не могат да връщат обекти, така че обученият модел трябва да направи заключение в UDF, преди да бъде изхвърлен.
Съхранени процедури
Съхранените процедури позволяват изпълнението на поредица от команди, които да бъдат използвани повторно. Те позволяват изпълнението на произволен код на Python, което ги прави по-подходящи за модели за обучение за по-голямо разнообразие от случаи на употреба, отколкото UDF. Таблиците на Snowflake могат да бъдат заредени от хранилището на данни Snowflake в Snowpark и трансформациите на тези таблици, използващи Snowpark, ще бъдат насочени към SQL изрази, за да се изпълнят на таблиците в склада Snowflake. Таблиците също могат да бъдат конвертирани в Pandas Dataframes и да се управляват с обичайните функции на Pandas Dataframe. Както при UDF, съхранените процедури разделят средата за разработка и изпълнение, което прави разработването или отстраняването на грешки в код предизвикателство. В допълнение, съхранените процедури поддържат само скаларна връщана стойност, което означава, че всеки неподдържан тип данни ще бъде върнат като JSON сериализиран низ, дори списъците на Python (тъй като SQL не може да „пикилира“ обекти). Съхранените процедури също са ограничени до един час време за изпълнение. Това е повече време от UDF, но все още е много ограничаващо при обучение върху голямо количество данни.
Победител: Databricks
Вижте колко по-кратък е разделът Databricks. Не се шегуваме: много по-лесно е да се извършва обучение с един възел. По време на нашия проучвателен анализ разбрахме, че Snowflake не поддържа OpenCV, популярна библиотека за манипулиране на изображения за компютърно зрение, на техните Linux клъстери. Нито пък Snowflake поддържа Linux пакети като libsndfileза манипулиране на аудио файлове. И накрая, Snowflake не поддържа библиотеки за обучение за укрепване като KerasRL, OpenAI Baselines и Stable Baselines. Това премахва доста клонове на изкуствения интелект от вашия инструментариум. Ограничаването до обучение с един възел означава, че ще бъдете ограничени и до хардуерните спецификации на един екземпляр. Ако вашият модел изисква повече памет, изчислителна мощност или ускорено изчисление, единствената ви възможност е да използвате по-мощна машина. Имайте предвид, че UDF и съхранените процедури също имат ограничения на паметта, дефинирани от склада. Ако достигнете това ограничение, ще трябва да се свържете с екипа за поддръжка на Snowflake, за да повиши този лимит за вас за всеки склад.
Multi-Node/Разпределено обучение
Databricks
Библиотеката Spark ML на Databricks първоначално поддържа многовъзлови реализации на много популярни алгоритми за машинно обучение, включително линейна/логистична регресия, произволни гори и градиентно подсилени дървета на решения. Нашият опит с преобразуването на тръбопроводи за дълбоко обучение с един възел с помощта на Tensorflow в многовъзлов CPU или GPU беше толкова прост, колкото използването на внедряването на „Horovod“ на Spark. Това наложи да променим по-малко от десет реда код в нашия бележник. Това е възможно и с помощта на Pytorch, който Databricks също поддържа.
Потребителският интерфейс на Databrick съдържа интерфейс за използване на възли, който ви позволява да наблюдавате използването на ресурси по време на обучение. Можете да настроите обучение с множество възли на работни клъстери, оптимизирани единствено за този вид задачи, ако искате да имате предвид изчислителните разходи. Тези клъстери за работа се управляват от Databricks във вашия облачен компютър и Databricks ще върти тези клъстери нагоре и надолу вместо вас.
Снежинка/Снежен парк
На пръв поглед многовъзловото/разпределеното обучение е невъзможно в рамките на средата за изпълнение на Snowflake поради начина, по който е настроена средата и възможностите, предоставени на потребителя. Важно е да споменем, че мулти-възелът, в смисъл на обучение на множество независими модели едновременно в един и същи клъстер, е напълно възможен при използване на запомнени процедури и UDF, както се твърди в тази публикация в блога. Но това не трябва да се бърка с истинското разпределено обучение (като DDP за Pytorch/Pytorch Lightning или Horovod за TensorFlow/Keras/Pytorch), дефинирано от Microsoft като работно натоварване за обучете един модел, който е разделен на множество процесори, които работят паралелно, за да ускорят процедурата за обучение на модела. Нашето предпочитание е терминът „разпределен ML“ да се използва само за такива разпределени процеси на обучение. Има два основни типа разпределено обучение: „паралелизъм на данни“ и „паралелизъм на модел“, нито един от които Snowflake не поддържа първоначално.
За да извършвате разпределено обучение с множество възли със Snowflake, трябва да използвате отделен клъстер, като например клъстер Spark с отворен код или доставчик като Azure Synapse или AWS EMR. Моделите могат да се обучават, разпределени в рамките на този клъстер от трета страна, докато комуникират със Snowflake като хранилище на данни (за предпочитане с помощта на API на Snowpark), за да получат данни за обучение, ако е необходимо.
Победител: Databricks, ръцете надолу
Snowflake трябва да използва партньори от трети страни дори за провеждане на обучение с множество възли. Snowpark действа като мост, за да позволи на Snowflake да бъде вашето хранилище за данни, но тогава наистина ли правите AI с Snowflake или с партньор на Snowflake? Междувременно Databricks прави това невероятно лесно за вас.
Заключение?
Databricks предоставя унифицирано работно пространство за съвместно разработване на модели, с огромна поддръжка за различни езици и библиотеки. Snowflake предоставя работни листове за SQL анализатори или Snowpark във вашата локална среда за специалисти по данни. По отношение на функционалността на един възел, Databricks е ясна, докато Snowflake постига това с дефинирани от потребителя функции (UDF) и съхранени процедури. Databricks първоначално предлага обучение с много възли за машинно обучение и натоварвания с дълбоко обучение с незначителни модификации от всяко разработено приложение на Spark. Възможно е обучение с много възли, използващо Snowflake само като източник на данни, но няма собствен метод за извършване на обучение с множество възли в склад на Snowflake.
По-горе обхванахме нашето сравнение само с работни процеси за обучение на AI. Snowflake има потенциал и ние оценяваме неговото инженерно качество по отношение на решенията за съхранение на данни, където блести невероятно. Ако планирате да преминете към разработването на AI в близко бъдеще, има смисъл да започнете с Databricks и Spark. И ние дори не проникнахме в регистъра на моделите, магазина за функции, пътуването във времето, проследяването на експерименти, решенията с ниски/без код като AutoML или други жизненоважни части от тръбопроводи за машинно обучение, нито едно от които Snowflake не поддържа първоначално. Следващата ни публикация в блога ще се фокусира повече върху тези области. Казано накратко, Databricks побеждава Snowflake/Snowpark за AI обучение.
В Empower осъзнахме, че науката за данни, машинното обучение и стриймингът са много по-управляеми и управлявани с Databricks Lakehouse и отворения формат Delta Lake, отколкото алтернативни решения.
Имате въпроси относно това как можем да „ускорим вашите съвременни инициативи за имоти с данни“? Свържете се с нашите експерти!
