Привет, Хабр!
Меня зовут Жеронкин Антон, я Data Engineer и участник профессионального сообщества NTA.
Иногда специфику работы дата‑инженера можно описать следующей картинкой:
И сейчас я расскажу почему: в одном проекте необходимо было использовать датасет, представляющий из себя около 5 млн. статей и связанных с ними сущностей (авторы, издательства, и т. д.).
Отмечу, что перед командой стояла задача адаптировать и загрузить этот датасет в PostgreSQL. При адаптации датасета необходимо было сохранить все связи между сущностями «Статья»‑»Автор», «Статья»‑»Издательство», «Статья»‑»Ключевое слово». Можно поспорить, что такой датасет можно сразу загрузить в MongoDB, ведь она является документоориентированной СУБД и гораздо лучше заточена для работы со слабоструктурированными сущностями, но в нашей команде не было достаточных навыков работы с ней.
Датасеты поставляются в формате одного JSON‑файла. Ниже привожу выдержку из описания датасета, составленного его авторами — с полной версией можно ознакомиться на странице датасета.
Какой вывод можно сделать из этого описания? У датасета есть структура, и она, на первый взгляд, кажется простой — создаётся впечатление, что датасет можно легко трансформировать в любой нужный нам вид. При его преобразовании в валидный для реляционных СУБД вид, достаточно будет извлечь отдельные столбцы, образовать связи между таблицами путем извлечения пар их ID. Так думал и я, решив, что преобразование этого датасета не займет много времени.
Первое, с чем мне пришлось столкнуться — впечатляющий размер датасета (17 ГБ) и встречающиеся иногда невалидные (нарушен синтаксис, баланс скобок) JSON‑записи.
Второе — записи в датасете слабоструктурированы. Слабоструктурированные сущности в данном контексте — это сущности, под хранение которых нет чётко и однозначно описанной структуры данных, как в тех же реляционных СУБД. В соседних записях половина атрибутов может быть общей для всех, а другая половина — быть уникальной для данной конкретной записи.
Таким образом, требовалось понять, что датасет из себя представляет и провести разведочный анализ. Было решено подгружать датасет в pandas с разбивкой по группам строк (чанкам), т.к.:
Сырой JSON‑файл размером в 17 ГБ целиком не загрузить как в текстовый редактор, так и в словарь через библиотеку json. В pandas через доп.параметр chunksize этот момент можно контролировать
Неясно, сколько на самом деле атрибутов, как они форматированы в JSON, насколько сложно их будет читать в сыром виде. Pandas хотя бы на верхнем уровне может представить записи в виде таблицы с плоской структурой.
Как и ожидалось, связанные со статьей сущности (авторы, издания), оформлены не в виде плоской структуры (одна строка — одна статья — один автор), а в виде вложенных списков внутри столбцов таблицы:
Для того, чтобы такие отношения между статьями и авторами, изданиями корректно отразить в реляционной СУБД, нам необходимо выровнять сущности, нормализовать и правильно смоделировать связь «Многие‑ко‑многим».
Если эти термины незнакомы, покажу на пальцах, как это работает. Допустим, мы имеем следующую таблицу:
И мы придерживаемся следующего порядка действий:
Преобразуем таблицу в первую нормальную форму (1НФ):
В новой структуре таблицы одной связи будет соответствовать ровно одна строка.
Дополнительно присвоим каждому из значений столбцов уникальный ID:
Разбиваем таблицу на две, а для их связи создаём дополнительную таблицу, в которой будут храниться пары ID подписчиков и издателей:
Естественно, пример, который я привёл выше, является сильно упрощенным «объяснением на пальцах», однако он позволяет продемонстрировать, что будет происходить дальше. Теперь я реализую это на Python:
import itertools import pandas as pd # читаем json порциями по 10000 записей chunks = pd.read_json(raw_data_line, chunksize=10000, lines = True) lst_authors = [] lst_paper_author = [] lst_venues = [] lst_references = [] i=0 # цикл обработки for chunk in chunks: chunk.fillna('', inplace = True) #АВТОРЫ paper_author_tuples = [([x[0]], x[1]) for x in list(zip(chunk['_id'], chunk['authors'].fillna(''))) if x[1] != ''] paper_author_pairs = [item for x in paper_author_tuples for item in list(itertools.product(x[0],x[1]))] paper_author_pairs = [(x[0], {k:v for k,v in x[1].items() if k in ['_id', 'name', 'org']}) for x in paper_author_pairs ] paper_author_pairs = fix_ids(paper_author_pairs) paper_author = [{'paper_id': x[0], 'author_id': x[1]['_id']} for x in paper_author_pairs] authors = [x[1] for x in paper_author_pairs] lst_paper_author.extend(paper_author) lst_authors.extend(authors) # Издательства (venues) # аналогичная обработка, только у одной статьи не много издательств, а одно # references if 'references' in chunk: references_tuples = [([x[0]], x[1]) for x in list(zip(chunk['_id'], chunk['references'])) if x[1] != ''] references_pairs = [item for x in references_tuples for item in list(itertools.product(x[0],x[1]))] lst_references.extend(references_pairs) del chunk['references'] del chunk['authors'] chunk.to_csv(f'clearsets\\papers-{i}.csv', sep='\t', encoding='utf-8') i+=1 # формируем csv с уникальными авторами и их id pd.DataFrame(lst_authors).drop_duplicates(subset='_id').to_csv(f'clearsets\\authors.csv', sep='\t', encoding='utf-8') # формируем csv со связями статей и авторов pd.DataFrame(lst_paper_author).to_csv(f'clearsets\\paper_author.csv', sep='\t', encoding='utf-8') # формируем csv со ссылками статей друг на друга pd.DataFrame(lst_references).to_csv(f'clearsets\\references.csv', sep='\t', encoding='utf-8')
Пояснения к отдельным вызовам функций я прикрепил в комментариях. В целом, логика работы с датасетом соответствует той, что я описывал ранее.
# извлекаем пары значений (id статьи, [все авторы в статье]) paper_author_tuples = [([x[0]], x[1]) for x in list(zip(chunk['_id'], chunk['authors'].fillna(''))) if x[1] != ''] # раскрытие списков на вторых позициях кортежей # создание уникальных пар (один id статьи, один автор) paper_author_pairs = [item for x in paper_author_tuples for item in list(itertools.product(x[0],x[1]))] # фильтрация ключей в авторах, очистка от ненужных атрибутов paper_author_pairs = [(x[0], {k:v for k,v in x[1].items() if k in ['_id', 'name', 'org']}) for x in paper_author_pairs ] # пары айдишников для связи авторов и статей paper_author = [{'paper_id': x[0], 'author_id': x[1]['_id']} for x in paper_author_pairs] authors = [x[1] for x in paper_author_pairs] lst_paper_author.extend(paper_author) lst_authors.extend(authors)
Попробуем выполнить этот код.
Оказывается, у некоторых авторов нет даже ID, о чем нам красноречиво сигнализирует эта ошибка.
Чтобы обойти этот недостаток датасета, напишем функцию генерации недостающих ID и интегрируем её в обработку.
import uuid def fix_ids(pairs): for pair in pairs: if '_id' not in pair[1]: pair[1]['_id'] = uuid.uuid4().hex[:24] return pairs # создаем отсутствующие айдишники paper_author_pairs = fix_ids(paper_author_pairs)
Выбор 24-символьного UUID обусловлен тем, что этот формат ID уже применяется в датасете, и у меня нет особой потребности переделывать их под какой‑то другой формат.
За скобками я оставил дополнительный скрипт, который проверяет уникальность каждого ID — поскольку ID будут использоваться как первичные ключи таблиц, необходимо исключить их дублирование. Хотя эта проверка у меня не выявила дублирования (кстати, СУБД тоже нормально приняла датасет). Этими проверками пренебрегать не стоит.
После того, как датасет обработан, остается залить его в заранее подготовленные таблицы и можно спокойно им пользоваться.
Подведем итоги
Когда мы сталкиваемся с большим ненормализованным датасетом, да еще и в формате JSON, который нужно переложить в связанные SQL‑таблицы, мы:
Читаем датасет по чанкам;
Анализируем датасет на качество, смотрим на атрибуты;
Нормализуем датасет, раскрываем связи между сущностями и следим за их целостностью.
В целом, знание этих пунктов позволит сразу адаптировать датасет под реляционные СУБД и значительно сократить время, затраченное на его обработку, ведь со структурной точки зрения его не потребуется переделывать бессчётное количество раз. А для всего остального — есть функционал SQL. Удачи!
