Работа с большими данными: часть 1

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

В данный момент я работаю над интересным проектом. По сути это извлечение определенных данных из огромного набора закрытой информации. Одна из подзадач – получение номера телефона по ФИО. Ниже я немного расскажу о процессе.

Итак, у нас есть большие текстовые файлы (от 10Гб и более), которые заполнены информацией о людях и их телефонах. Причем не в формате фио – телефон, а с кучей ненужных подробностей, вперемешку с юрлицами, другой информацией, иногда в одном файле фио и ид, а в другом ид и телефон. Само собой с дублями и ошибками.

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



Открываем в нем документ и делим на несколько. Я разделил по числу мегабайт – по 100Мб вышел каждый файл. Эти файлы уже не проблема залить по SFTP на сервер и, главное, работать с ними.

Дальше надо подумать. Да-да, работа программиста зачастую заключается не в написании кода, а в обдумывании процесса, архитектуры. В данной задаче в конечном итоге нам необходимо получить более-менее быстрый поиск номера телефона по ФИО. Формат таблицы напрашивается сам собой – идентификатор, фамилия, имя, отчество, номер телефона.

И сразу приходит в голову возможная оптимизация: сделать не одну таблицу, а несколько. Каждая таблица будет соответствовать одной букве алфавита – первой букве фамилии. Таким образом мы сразу ускоряем поиск в несколько раз.

Создаем обычный массив соответствий

$alfavit = [
    'а' => 'a',
    'б' => 'b',
    'в' => 'v',
    'г' => 'g',
    'д' => 'd',  
    'е' => 'e',
    'ё' => 'yo',
    'ж' => 'zh',
    'з' => 'z',
    'и' => 'i', 
	'й' => 'j',
    'к' => 'k',
    'л' => 'l',
    'м' => 'm',
    'н' => 'n', 
	'о' => 'o',
    'п' => 'p',
    'р' => 'r',
    'с' => 's',
    'т' => 't', 
	'у' => 'u',
    'ф' => 'f',
    'х' => 'h',
    'ц' => 'c',
    'ч' => 'ch', 
	'ш' => 'sh',
    'щ' => 'csh',
    'ь' => 'mz',
    'ы' => 'y',
    'ъ' => 'tz', 
	'э' => 'ye',
    'ю' => 'yu',
    'я' => 'ya'
];

Да, это обычная транслитерация, можно в принципе делать её как угодно. Таблицы называем, например, так – для буквы «а» - surname_a, «б» - surname_b и так далее.

Второй неочевидный (для меня) момент заключался в том, что не надо проверять на дубли при занесении строки таблицу. Почему? Да, я сам сначала стал делать обычную схему: проверяем на дубль и заносим. Однако, это подходит только для занесения одной-нескольких строк в миллионную таблицу. А вот добавление второго миллиона в имеющийся миллион – это уже не оправдывается. Сами посчитайте – пара секунд на поиск – это сколько суток будет?

Таким образом, заносим сразу все, а потом уже делаем две доработки: при поиске отсеиваем дубли и запускаем процесс удаления дублей автоматом, в фоне – пусть хоть несколько лет делается.

Это кстати в реальной разработке для бизнеса не редкость – надо запустить проект сейчас, вот сразу, может еще вчера, а уже потом дорабатываем напильником.