Интервью с Матей Захария обо всем, что касается искусственного интеллекта, облака и надежности данных

Одно дело сказать, что ваша компания управляется данными. Другое дело - извлекать значимые выводы из своих данных.

Просто спросите Матей Захария, оригинального создателя Apache Spark. С момента его первоначального выпуска в 2010 году Matei и U.C. AMPLab от Berkeley, Apache Spark превратился в одну из ведущих в мире платформ кластерных вычислений с открытым исходным кодом, предоставляя группам данных более быстрый и эффективный способ обработки и совместной работы над крупномасштабной аналитикой данных.

Создав Databricks, Матей и его команда перенесли свое видение масштабируемых и надежных данных в облако, создав платформу, которая помогает группам данных более эффективно управлять своими конвейерами и генерировать модели машинного обучения. В конце концов, как отмечает Матей: ваш ИИ хорош настолько, насколько хороши данные, которые вы в него вводите.

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

Вы выпустили Spark в 2010 году в качестве исследователя в Калифорнийском университете. Беркли, и с тех пор она стала одной из наиболее широко используемых технологий современного стека данных. Что в первую очередь вдохновило вашу команду на разработку проекта?

Матей Захария (МЗ): Десять лет назад был большой интерес к использованию больших наборов данных для аналитики, но обычно нужно было быть инженером-программистом и знать Java или другие языки программирования, чтобы пишите для них заявки. До Apache Spark существовали MapReduce и Hadoop в качестве реализации с открытым исходным кодом для обработки и генерации больших наборов данных, но моя команда из AMPLab в Беркли хотела найти способ сделать обработку данных более доступной для пользователей, помимо штатного программного обеспечения. инженеры, такие как аналитики данных и специалисты по данным.

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

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

Что воодушевило вас и остальных членов вашей группы в U.C. Berkeley, чтобы превратить ваш исследовательский проект в решение для корпоративных групп данных?

Довольно рано в исследовательском проекте было несколько технологических компаний, которые были заинтересованы в использовании Apache Spark, например Yahoo !, в которой работала одна из крупнейших в то время команд, использующих Hadoop, и несколько стартапов. Поэтому мы были взволнованы, увидев, сможем ли мы удовлетворить их потребности и, благодаря этому сотрудничеству, генерировать идеи для новых исследовательских проблем, поскольку это все еще было таким новым пространством.

Таким образом, на раннем этапе мы потратили много времени на то, чтобы сделать Apache Spark доступным для предприятий. Затем, в 2013 году, основная исследовательская группа этого проекта завершала работу над докторской степенью, и мы хотели продолжить работу над этой технологией. Мы решили, что лучший способ доставить это множеству людей устойчивым и простым в использовании способом - это через облако, и так родились Databricks.

Семь лет спустя ваше видение сбылось. В 2020 году все больше и больше групп данных переходят в облако для создания своих платформ данных. Какие факторы следует учитывать группам корпоративных данных при проектировании стеков данных?

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

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

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

Раньше вы говорили: ИИ хорош настолько, насколько хороши данные, которые вы в него вводите. Я не могу с этим согласиться. Не могли бы вы уточнить?

Я бы даже сказал, что искусственный интеллект или машинное обучение действительно следует называть чем-то вроде «экстраполяции данных», потому что это в основном то, что алгоритмы машинного обучения делают по определению: каким-то образом обобщают известные данные, очень часто используя какие-то статистическая модель. Итак, если вы так выразились, я думаю, становится очень ясно, что данные, которые вы вводите, являются наиболее важным элементом, верно?

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

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

Аналогичным образом, охватывают ли данные, которые вы вводите, достаточно разнообразный набор условий, или вам не хватает критических реальных условий, в которых ваша модель должна работать хорошо?

С этой целью какие шаги могут предпринять группы по обработке данных, чтобы получить высоконадежные данные?

На высоком уровне я видел несколько разных подходов, каждый из которых можно комбинировать. Один из них так же прост, как наличие схемы и ожиданий относительно типа данных, которые будут помещены в таблицу или в отчет. Например, в платформе Databricks основным форматом хранения, который мы используем, является так называемое Delta Lake, которое по сути является более многофункциональной версией Apache Parquet с управлением версиями и транзакциями в ваших таблицах. И мы можем установить схему того, какие данные помещаются в таблицу.

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

Последнее, что я хотел бы отметить, касается того, как вы проектируете конвейеры данных. По сути, чем меньше у вас будет шагов копирования данных, ETL и транспорта, тем больше вероятность того, что ваша система будет надежной, потому что меньше всего может пойти не так. Например, вы можете взять таблицу Delta Lake и рассматривать ее как поток и иметь задания, которые указаны в списке изменений, поэтому вам не нужно реплицировать изменения в шину сообщений. Вы также можете запрашивать эти таблицы напрямую с помощью инструмента бизнес-аналитики, такого как Tableau, поэтому вам не нужно копировать данные в какую-либо другую систему для визуализации и отчетности.

Надежность данных - это очень быстро развивающаяся область, и я знаю, что Монте-Карло делает здесь много интересного.

Когда вы были соучредителем Databricks, облако было еще зарождающимся. Сейчас многие из лучших компаний, занимающихся данными, строят для облака. Что привело к такому развитию современного стека облачных данных?

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

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

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

Это означает, что поставщик облачных услуг должен быть очень хорош в обновлении чего-либо в реальном времени, не нарушая рабочих нагрузок, но для пользователя это в основном означает, что вы получаете более качественное программное обеспечение быстрее: представьте, что сегодня вы можете получить доступ к программному обеспечению, которое вы бы только получили на один или два года в будущем от местного поставщика.

Это важные факторы, которые сделали облачные продукты успешными на рынке.

Узнайте больше об исследованиях Матей, Apache Spark или Databricks.

Хотите узнать больше о надежности данных? Обратитесь к Барру Моисею и команде Монте-Карло.

Эта статья написана в соавторстве с Молли Форверк.