5 трендов баз данных. Идеи с конференции VLDB’2112.10.2021 15:01

В середине августа мы приняли участие в международной научной конференции VLDB (Very Large Data Bases), и хотим поделиться актуальными идеями о работе с базами данных.

Если вы специалист по базам данных, или так или иначе связаны с ними, то приглашаем к чтению.

Немного контекста

Коротко о конференции. VLDB интересна тем, что не смотря на научный уклон, к ней проявляют интерес и со стороны бизнеса. Зачастую на VLDB читают доклады от Microsoft, Oracle, Google и т.д. Более академические доклады читают представители MIT, Stanford, CMU, TUM. 

Как вы понимаете, отбор на конференцию довольно серьезный (только 10–15% докладчиков получают возможность выступить, а за всю историю современной России можно насчитать не более десяти докладов, которые туда прошли).

Автор: Чернышев Георгий, Руководитель Лаборатории Юнидата. Занимаюсь исследованиями в области работы с данными, помогаю связывать научную теорию с практикой.

Дальнейшее описание трендов будет представлено через призму опыта и интересов автора. В основном занимался реляционными read-only движками, недавно начал смотреть всё про управление данными — data profiling, data cleaning и data quality.

Графов, транзакций, differential privacy и других идей в данном обзоре не будет. На конференции 250+ работ, посмотреть все нереально (конференция шла неделю, ~12 часов в день). Но для интересующихся есть ссылка. Все работы есть в открытом доступе, причем у некоторых есть видео на Ютубе.

Теперь перейдём к трендам.

Тренд №1

Машинное обучение и классические базы данных. К 2021 году можно сказать, что машинное обучение «пришло» в классические базы данных, и уже видны некоторые промежуточные итоги. Можно, потому что появились доклады вида «tutorial». То есть, в докладах дают обзор существующих исследований, с классификацией и какими-то размышлениями. К слову сказать, на данной конференции такой доклад был, и довольно интересный. По ссылке анонсы и слайды всех tutorial с данной конференции.

Внутри этого тренда можно выделить следующие направления:

1) Оценка размера результата (cardinality estimation). Кажется, что это самый большой успех применения машинного обучения. Предложенные подходы дают очень хорошую точность, ошибка предсказания иногда в десятки раз лучше альтернатив (гистограмм). При этом, на времени выполнения запроса статистика улучшенного качества не отражается настолько прямолинейно. Например, на воркшопе LADSIOS в докладе про Microsoft Cosmos говорилось, что на наборе запросов улучшение по времени работы в районе 7%.

2) Оптимизация (join order selection). На мой взгляд здесь результаты хуже. Исследовательские прототипы есть, но, в отличие от предыдущего направления, внедрить это в продакшн, и заставить стабильно работать, требует огромных инженерных усилий. Кроме того, подобную систему надо будет еще смочь администрировать, хотя в случае cloud-native баз все должно быть легче. Впрочем, время покажет.

3) Структуры данных, оптимизированные под данные (instance optimized data structures). Собственно, ради них я и пошел на эту конференцию, а точнее на воркшоп LADSIOS. Потенциально это революция, которая началась еще пару лет назад. На пальцах, идея этого подхода следующая: заменить классический индекс (пусть, на B-дереве), на иерархию «моделей», которые будут предсказывать, где лежит ключ. Результаты очень многообещающие: рост производительности в разы, а размер индекса становится меньше в тысячу раз.

В прошлом году прогремел индекс ALEX (статья ALEX: An Updatable Adaptive Learned Index). На рисунках ниже представлены результаты бенчмарка, где можно видеть, что классика серьезно проигрывает на всех запросах, кроме bulk loading. Темой активно занимается академия и компании. Например на том же воркшопе был рассказ от Microsoft про их усилия в этом направлении. Вцелом, сообщество не ограничиваются B-деревом, пробуют другие, а также пытаются встраивать такие подходы в сторейдж.

Конечно, сейчас там полно проблем — значения переменного размера, обновления, и прочее. Однако если все это действительно заработает, то под вопросом окажутся даже базовые программистские курсы. Я веду практику по программированию и структурам данных на матмехе СПбГУ, и, конечно, рассказываю про B-дерево и другие. Если действительно те структуры лучше — смысла давать «классические» деревья поиска станет совсем мало, и возможно надо будет как-то модернизировать программу. Причем учебников по новинкам даже на западе сейчас нет.

Тренд №2

Исследование датасетов (dataset exploration / data lake exploration / dataset discovery) — это родственные темы, которые решают задачи такого рода: необходимо найти определенный набор данных, или просто разобраться в скоплении таблиц. Это очень горячая тема в академическом сообществе, причем с практическим «выхлопом»: есть пилотные проекты во многих организациях, в том числе банках.

На конференции таких работ было много, ради экономии места я опишу три. Этот класс работ «стоит на плечах гигантов»: в нем используются как классические наработки из области баз данных 90х-00х, таких как schema matching и entity resolution, так и совсем новые, такие как определение семантического типа колонки по данным при помощи глубокого обучения, о котором мы писали ранее.

1) Auctus: A Dataset Search Engine for Data Discovery and Augmentation — эта статья меня поразила больше всего (здесь есть видео). Идея в том, чтобы создать своеобразный гугл для таблиц, который умеет гораздо больше, чем просто искать по ключевому слову. Есть простой профайлер и детектор семантического типа колонки, может делать привязку к google maps. Можно искать датасеты не только по ключевым словам, но и по времени, месту (региону). Далее, можно искать «подклеиваемые» датасеты: снизу (unionable) и справа (joinable). Один из экранов этой системы представлен на рисунке ниже (взято из оригинальной статьи, там есть больше).

2) DICE: Data Discovery by Example — проект MIT у которого немного другая задача. Есть data lake, куча таблиц и нам надо найти какие-то данные. Вручную искать тяжело, автоматически — надо знать язык запросов, и тоже придется поработать. Идея: query-by-example — мы покажем, как должны выглядеть результаты, а система найдет. Система ищет не просто таблицы, а результат: он может лежать в нескольких исходных таблицах, которые надо соединять. Система интерактивна, с циклом общения с пользователем.

3) A data discovery platform empowered by knowledge graph technologies challenges and opportunities. Это статья с воркшопа SEA Data, проект Concordia University. Делают систему KGLac, пытаются использовать базу знаний для поиска таблиц. База строится на отношениях между колонками, которые вычисляются с помощью эмбеддингов, которые берутся из колонок (данных). Конечная цель — гонять SPARQL запросы на этом графе. Может интегрироваться с питоном.

Тренд №3

Визуальная аналитика. Тут идея такая: сделать коллаборативный dashboard, на который можно визуально накидывать данные, модели машобуча, и другие объекты. Их можно по-всякому соединять и строить пайплайны. Можно создавать различную визуализацию, считать метрики, использовать их для принятия решений.

Интегрируются базы данных, питон, spark, файлы. Причём, это всё обычно работает на СУБД с поддержкой частичных ответов на потоках данных (progressive computation), а также на истории данных (provenance). Одной из ключевых особенностей являются новые пользовательские интерфейсы, когда, например можно визуально выбирать подмножество данных из результата SQL, представленного в виде, допустим, графика.

Здесь мне запомнились две работы:

1) Davos: A System for Interactive Data-Driven Decision Making. Это industrial, то есть

продукт уже существует. Доклад от компании, которая является результатом коммерциализации MIT&Brown University. На рисунке ниже изображен скриншот предоставляемого dashboard, взятый из статьи.

2) Набор демонстраций от Eugene Wu. Это скорее рассказ про отдельные компоненты для построения системы, подобной Davos, про их устройство. Доклад (кейноут) был сделан на воркшопе SEA Data.

Тренд №4

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

Причин на мой взгляд две:

1) Движковая тема исчерпала себя и стала «индустриальной». То есть, стало требоваться очень много инжиниринга для того, чтобы сделать что-то интересное. Не секрет, что академические учёные зачастую не имеют достаточного количества ресурсов, которые можно на потратить реализацию.

2) Наработки в машинном обучении, а конкретно, в глубоком обучении, позволили «подвигать» старые темы, за которые брались еще с 80х, и где больших успехов, в общем, достигнуто тогда не было.

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

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

1) Entity Matching, Entity Resolution, Record Linkage, Duplicate detection. Это очень старый набор тем, родом прямо из 80х, который испытал уже несколько всплесков интереса. Суть такова: есть набор записей в таблице (таблицах), в ней возможны дубликаты, которые надо как-то найти и убрать. Причем дубликаты могут быть семантическими, а не просто опечатками. Например, в случае двух таблиц с персональными данными человека, в одной из них может не быть отчества, или же имя и отчество могут совместно храниться в одной колонке.

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

 * Deep Entity Matching with Pre-Trained Language Models — Сериализуют обе записи в последовательности токенов, затем применяют языковую модель (из семейства BERT) для классификации пары предложений.

 * Deep Learning for Blocking in Entity Matching A Design Space Exploration — Работа раскрывает проблему распределения записей-кандидатов по блокам. Дело в том, что сравнивать каждую запись с каждой очень дорого на больших датасетах, поэтому обычно делают двухфазные алгоритмы. На первой фазе распределяют по блокам, где вероятно совпадение, а потом делают попарное сравнение внутри блока. Авторы сравнивали различные методы машинного обучения с классическими, в ней проведена просто огромная работа.

Еще на SIGMOD»21 был кейноут от Wang-Chiew Tan «Deep Data Integration», то есть уже сейчас сделано гораздо больше. От того же автора есть очень свежая статья Deep Entity Matching: Challenges and Opportunities, которая, как я подозреваю, перекликается с кейноутом.

2) Schema Matching и Schema Mapping. Это тоже две очень старые и очень сложные задачи. Идея первой: имея на входе две базы данных, описывающих какие-то схожие (или даже одни и те же) предметные области, сопоставить таблицы (схему базы) друг с другом. Вторая скорее про то, как имея уже некоторое сопоставление, перевести одну схему в другую.

На конференции мне запомнилась работа «Valentine in Action: Matching Tabular Data at Scale». Тут авторы представили огромный фреймворк, в котором есть не только множество известных алгоритмов, но и генераторы данных, и оценщик метрик качества. 

3) Data profiling и data cleaning. Data profiling посвящена извлечению различных свойств (закономерностей) из данных (таблиц) и тому, как представить их пользователю. Тут важно отметить, что эти закономерности обычно доступны для трактовки и понимания. Их примерами могут служить функциональные зависимости или уникальные наборы колонок (unique column combinations): проекции, в которых нет дубликатов. Data cleaning — это, собственно, очистка данных с помощью этих закономерностей. Как это можно сделать? Допустим, если функциональная зависимость почти выполняется, то есть, верна на всей таблице кроме одной записи, то скорее всего в этой записи опечатка.

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

Зависимости можно использовать двумя способами: в автоматическом режиме, и в ручном. В автоматическом режиме некоторый алгоритм получает набор зависимостей, сам выбирает схему исправлений и её придерживается. Обычно такие алгоритмы очень затратны по вычислительным ресурсам (так как основной ресурс уходит на выбор схемы), и в статье Horizon: Scalable Dependency-driven Data Cleaning был представлен очень быстрый алгоритм такого рода.

 В ручном же режиме пользователь как-то работает с зависимостями и данными и сам выбирает, что и как исправлять для каждого случая. Тут система openclean (статья From Papers to Practice: The openclean Open-Source Data Cleaning Library) приходит на помощь. Её идея — собрать open-source библиотеку для очистки данных. Она позволяет использовать довольно большой арсенал средств по профайлингу и очистке данных в питоне. При этом она интегрирует в себе некоторые известные результаты сообщества баз данных, например для поиска зависимостей она использует алгоритмы из проекта Metanome.

 4) Получение данных из таблиц, построение баз знаний. Тут такая идея: построить базу знаний на тройках субъект-действие-объект. Из троек получается граф, описывающий некоторую область. При этом, стараются не вводить данные вручную, а пытаются парсить из интернета. Например википедию. Такая база позволит отвечать на вопросы вида «кто получил нобелевскую премию по математике в 2021 году». Баз знаний, построенных на подобных принципах, несколько, например Yago или Wikidata. Вроде как на подобных технологиях работают быстрые ответы у поисковых систем.

 Данные для баз знаний хорошо берутся из таблиц, поэтому, традиционно, сообщество баз данных любит извлекать знания из таблиц. Более десяти лет назад, еще аспирантом, я впервые послушал Герхарда Вейкума, одного из авторов Yago. Наверное, он один из лучших лекторов, кого я слушал в свой жизни. На этой конференции от него был кейноут, куда я конечно же пошел. Он назывался Knowledge Graphs 2021: a Data Odyssey, и там рассказывалось про применение глубокого обучения для вот таких задач.

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

 Ещё о базах знаний на конференции был туториал On the Limits of Machine Knowledge Completeness Recall and Negation in Web scale Knowledge. Также недавно у авторов обоих докладов вышла книга — Machine Knowledge Creation and Curation of Comprehensive Knowledge Bases.

Далее, на конференции была представлена работа TURL: Table Understanding through Representation Learning. В каком-то смысле это расширение подхода Sherlock, который мы разбирали ранее.

 Наконец, я хочу отметить работу The Secret Life of Wikipedia Tables, с воркшопа SEA Data. Там занимаются сопоставлением разных версий одной и той же таблицы, и авторы провели анализ таблиц из википедии. Получился очень интересный рассказ. Ниже представлена некоторая статистика по таблицам из работы, довольно интересная на мой взгляд (в самой статье ее еще больше). А сам алгоритм, которым сопоставляли, был представлен еще в работе Structured Object Matching Across Web Page Revisions.

Тренд №5

 Будущее курсов по базам данным.Отличительной чертой VLDB этого года было множество обсуждений, в том числе в формате круглого стола. Есть большой вопрос, волнующий всё сообщество баз данных: не устарел ли их материал в свете роста data science и интереса к нему.

Было выступление одного из авторов «книги с коровой» (знаменитого на западе учебника по базам данных), а сам круглый стол так и назывался: «The future of database education: is the cow book dead?». Далее я накидаю разных интересных мыслей от выступавших.

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

 При этом, это не только хайп, это фундаментальная разница в изучаемых объектах. Есть такое противопоставление:

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

 Мысль об устаревании подогревается и появлением облачных технологий: все современные СУБД работают в облаке, серьезный data science — в облаке. Масса других систем там же. Вообще, облачность это просто способ предоставить ресурсы, и на мой взгляд, эта тематика универсально востребована.

 При этом классический курс баз данных (книга с коровой, книги Ульмана, Дэйта) устарел на 20 лет. Он делался под те реалии, под то железо и технологии. Высказывалось мнение, что от старого (вводного) курса останется 25%, а остальное будет дополнено из data science и облака. Как вариант, предлагалось убрать из общего курса нелюбимые мной транзакции и восстановление, так как это стало слишком нишевым. Пора делить информацию: делать один вводный курс, за которым последует серия новых курсов.

Причем вводный курс должен покрывать три темы: cloud, ML-for-DB, DB-for-ML. Надо делать курсы под набор специальностей: DBAs; Business/Data Analysts; Data Scientists; Domain Scientists; Data Engineers; ML Engineers. Аналогичная эволюция за 50 лет прошла в software engineering, где появились: test engineer, software development engineer, security, network admin, system admin, DBA. Кроме того, надо избавляться от массового представления, что базы данных это реляционные СУБД (RDBMS supremacy:)) — это сильно мешает жить. Базы данных, это вообще про любые способы хранения, обработки и представления данных.

Отмечалось, что то, что происходит сейчас с data science vs databases это ровно тоже самое, что происходило в 70х с computer science vs math, когда математики говорили что computer science это просто еще одна прикладная наука. Тогда computer science победила: финансирование, студенты, рабочие места и, самое главное, возможность определять направление развития человечества осталась за ними.

Были и позитивные мнения: отставить doom & gloom. Сообщество успешно, есть ядерный набор алгоритмов, методов, идей, который всегда останется за ним. Рынок баз данных растет и вырастет в разы, люди востребованы индустрией, сообщество рождает успешные компании (Snowflake, Databricks).

При этом надо начать говорить о «Data Infrastructure»: это покроет и облачные системы, и data science. Ведь эта пара и есть собственно то, что называется машинным обучением. Необходимо адаптироваться и расширять курсы обучения на data infrastructure и data science.

Теперь про, собственно, варианты что делать с курсами обучения (в университетах и не только). Высказывались профессоры из разных университетов.

Кто-то делился опытом про вводный курс без баз данных вообще, ибо data scientist«у это не нужно. Data scientist должен концентрироваться на том, как использовать данные, а не как их хранить. При этом, и о хранении неплохо было бы что-то знать.

В другом вузе data scientist«ов учат SQL, так как все их инструменты становятся неудобными, когда сложность схемы возрастает. Их инструменты достаточно примитивны, а оптимизаторов нет вообще — это ниша для привнесения опыта из классического БД.

Был рассказан и достаточно интересный вариант действий: «отпустить» курс по БД. В одном вузе был эксперимент, когда БД сделали необязательным курсом, но он все равно был самым популярным. Причем, такая модель достаточно известна: есть и другие вузы, которые так делают, в одном из них 500 человек ежегодно выбирают базы данных. И сейчас есть возможность также поступить с курсами по data science и БД. Пусть студенты сами разбираются, что они хотят.

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

Отдельно высказывалось проблема, что нет учебника, объединяющего базы данных и data science, даже на западе. Его надо делать, и работа эта не простая.

Наконец, по поводу «книги с коровой» было сказано следующее: не книга с коровой мертва (она еще полезна и используется почти всеми выступающими), а в целом учебники мертвы. Люди теперь получают информацию по-другому, и тут тоже надо адаптироваться.

В итоге можно сказать, что множество университетов уже разделило учебные программы на БД и Data scientist. Но какой курс «главнее» ещё не ясно. Например, сейчас в Германии большинство университетов имеют классическое БД в качестве обязательного курса. Американские же университеты запустили целые направления по data science, где курс по базам данных не главный. Время покажет, устоит ли классика.

Подготовил Георгий Чернышев

© Habrahabr.ru