Что такое etl средства
Чернобровов Алексей Аналитик
ETL: что такое, зачем и для кого
В статье рассмотрено одно из ключевых BI-понятий (Business Intelligence) – ETL-технологии: определение, история возникновения, основные принципы работы, примеры реализации и типовые варианты использования (use cases). Также отмечены некоторые проблемы применения ETL и способы их решения с помощью программных инструментов обработки больших данных (Big Data).
Что такое ETL и зачем это нужно
Начнем с определения: ETL (Extract, Transform, Load) – это совокупность процессов управления хранилищами данных, включая [1]:
Понятие ETL возникло в результате появления множества корпоративных информационных систем, которые необходимо интегрировать друг с другом с целью унификации и анализа хранимых в них данных. Реляционная модель представления данных, подходящая для потребностей транзакционных систем, оказалась неэффективной для комплексной обработки и анализа информации. Поиск унифицированного решения привел к развитию хранилищ и витрин данных – самостоятельных систем хранения консолидированной информации в виде измерений и показателей, что считается оптимальным для формирования аналитических запросов [2].
Прикладное назначение ETL состоит в том, чтобы организовать такую структуру данных с помощью интеграции различных информационных систем. Учитывая, что BI-технологии позиционируются как «концепции и методы для улучшения принятия бизнес-решений с использованием систем на основе бизнес-данных» [3], можно сделать вывод о прямой принадлежность ETL к этому технологическому стеку.
Как устроена ETL-система: архитектура и принцип работы
Независимо от особенностей построения и функционирования ETL-система должна обеспечивать выполнение трех основных этапов процесса ETL-процесса (рис.1) [4]:
Рис. 1. Обобщенная структура процесса ETL
Таким образом, ETL-процесс представляет собой перемещение информации (потока данных) от источника к получателю через промежуточную область, содержащую вспомогательные таблицы, которые создаются временно и исключительно для организации процесса выгрузки (рис. 2) [1]. Требования к организации потока данных описывает аналитик. Поэтому ETL – это не только процесс переноса данных из одного приложения в другое, но и инструмент подготовки данных к анализу.
Рис. 2. Потоки данных между компонентами ETL
Для подобных запросов предназначены OLAP-системы. OLAP (Online Analytical Processing) – это интерактивная аналитическая обработка, подготовка суммарной (агрегированной) информации на основе больших массивов данных, структурированных по многомерному принципу. При этом строится сложная структура данных – OLAP-куб, включающий таблицу фактов, по которым делаются ключевые запросы и таблицы агрегатов (измерений), показывающие, как могут анализироваться агрегированные данные. Например, группировка продуктов по городам, производителям, потребителям и другие сложные запросы, которые могут понадобиться аналитику. Куб потенциально содержит всю информацию, нужную для ответов на любые количественные и пространственно-временные вопросы. При огромном количестве агрегатов зачастую полный расчёт происходит только для некоторых измерений, для остальных же производится «по требованию» [6].
Таким образом, основные функции ETL-системы можно представить в виде последовательности операций по передаче данных из OLTP в OLAP (рис. 3) [7]:
Рис. 3. ETL-процесс по передаче данных от OLTP в OLAP
Немного про хранилища и витрины данных
ETL часто рассматривают как средство переноса данных из различных источников в централизованное КХД. Однако КХД не связано с решением какой-то конкретной аналитической задачи, его цель — обеспечивать надежный и быстрый доступ к данным, поддерживая их хронологию, целостность и непротиворечивость. Чтобы понять, каким образом КХД связаны с аналитическими задачами и ETL, для начала обратимся к определению.
Корпоративное хранилище данных (КХД, DWH – Data Warehouse) – это предметно-ориентированная информационная база данных, специально разработанная и предназначенная для подготовки отчётов и бизнес-анализа с целью поддержки принятия решений в организации. Информация в КХД, как правило, доступна только для чтения. Данные из OLTP-системы копируются в КХД таким образом, чтобы при построении отчётов и OLAP-анализе не использовались ресурсы транзакционной системы и не нарушалась её стабильность. Есть два варианта обновления данных в хранилище [8]:
ETL-процесс позволяет реализовать оба этих способа. Отметим основные принципы организации КХД [8]:
Витрина данных (Data Mart) представляет собой срез КХД в виде массива тематической, узконаправленной информации, ориентированного, например, на пользователей одной рабочей группы или департамента. Витрина данных, аналогично дэшборд-панели, позволяет аналитику увидеть агрегированную информацию в определенном временном или тематическом разрезе, а также сформировать и распечатать отчетные данные в виде шаблонизированного документа [9].
При проектировании хранилищ и витрин данных аналитику следует ориентироваться на возможности их прикладного использования и с учетом этого разрабатывать ETL-процессы. Например, если известно, что информация, поступающая из определенных подразделений, является самой важной и полезной, а также наиболее часто анализируется, то в регламент переноса данных в хранилище стоит внести соответствующие приоритеты. Это позволит ускорить работу с информацией, что особенно важно для data-driven организаций со сложной многоуровневой филиальной структурой и большим количеством подразделений [4].
Прикладные кейсы использования ETL-технологий
Рассмотрим пару типовых примеров использования ETL-систем [10].
Кейс 1. Прием нового сотрудника на работу, когда требуется завести учетную карточку во множестве корпоративных систем. В реальности в средних и крупных организациях этим занимаются специалисты разных подразделений, не скоординировав задачу между собой. Поэтому на практике часто возникают ситуации, когда принятый на работу сотрудник подолгу не может получить банковскую карту, потому что его учетная запись не была вовремя заведёна в бухгалтерии, а уже уволенные сотрудники имеют доступ к корпоративной почте и приложениям, т.к. их аккаунты не заблокированы в домене. ETL поможет быстро наладить взаимодействие между всеми корпоративными информационными системами.
Аналогичным образом ETL-технологии помогут автоматизировать удаление аккаунтов сотрудника из всех корпоративных систем в случае увольнения. В частности, как только в HR-систему попадут данные о дате окончания карьеры сотрудника на этом месте работы, информация о необходимости блокировки его записи поступит контроллеру домена, его корпоративная почта автоматически архивируется, а почтовый ящик блокируется. Также возможен полуавтоматический режим с созданием заявки на блокировку в службу технической поддержки, например, Help Desk.
Кейс 2. Разноска платежей, когда при взаимодействии со множеством контрагентов необходимо сопоставить информацию в виде платёжных документов, с деньгами, поступившими на расчетный счёт. В реальности это два независимых потока данных, которые сотрудники бухгалтерии или операционисты связывают вручную. Далеко не все корпоративные финансовые системы имеют функцию автоматической привязки платежей.
Итак, информация о платежах поступает от платежной сети в зашифрованном виде, т.к. содержит персональные данные. Вторым потоком данных являются файлы в формате DBF, содержащие информацию о банках-контрагентах, которая требуется для геолокации платежа. Наконец, с минимальной задержкой в три банковских дня, приходят деньги и выписка с платежами, проведёнными через банк-партнёр. Отметим, что в реальности прямой связи между всеми этими данными нет: номера документов, указанные в реестрах от платёжной системы и банка, не совпадают, а из-за особенностей работы банка дата платежа, которая значится в выписке, может не соответствовать дате реальной оплаты, которая содержится в зашифрованном файле реестра.
Расшифровку данных можно включить в ETL-процесс, в результате чего получится текстовый файл сложной структуры, содержащий ФИО, телефон, паспортные данные плательщика, сумму и дату платежа, а также дополнительные технические данных, идентифицирующие транзакцию. Это как раз позволит связать платёж с данными из банковской выписки. Данные из реестра обогащаются информацией о банках-контрагентах (филиалах, подразделениях, городах и адресах отделений), после этого осуществляются их соответствие (мэппинг) к конкретным полям таблиц корпоративных информационных систем и загрузка в КХД. Обогащение уже очищенных данных происходит в рамках реляционной модели с использованием внешних ключей.
После прихода банковской выписки запускается ещё один ETL-процесс, задача которого состоит в сопоставлении ранее полученной информации о платежах с реально пришедшими деньгами. Поскольку выписки приходят из банка в текстовом формате, первым шагом трансформации является разбор файла, затем идет процесс автоматической привязки платежей с использованием информации, ранее загруженной в корпоративную систему из реестров платежей и банков. В процессе привязки происходит сравнение не только ключей, идентифицирующих транзакцию, но и суммы и ФИО плательщика, а также отделения банка. Также решается задача исправления неверной даты платежа, указанной в банковской выписке, на реальную дату его совершения.
В результате нескольких ETL-процессов получилась система автоматической привязки платежей, при этом основные затраты были связаны с не с разработкой программного обеспечения, а с проектированием и изучением форматов файлов. В редких случаях ручной привязки обогащение данных с помощью ETL-технологии существенно облегчает эту процедуру. В частности, наличие телефонного номера плательщика позволяет уточнить данные о платеже лично у него, а геолокация платежа даёт информацию для аналитических отчётов и позволяет более эффективно отслеживать переводы от партнёров-брокеров (рис. 4).
Рис. 4. Организация разноски платежей с помощью ETL
Современный рынок ETL-систем и особенности выбора
Существует множество готовых ETL-систем, реализующих функции загрузки данных в КХД. Среди коммерческих решений наиболее популярными считаются следующие [11]:
К категории условно бесплатных можно отнести [11]:
При выборе готовой ETL-системы необходимо, в первую очередь, руководствоваться не бюджетом ее покупки или стоимостью использования, а следующими функциональными критериями:
Многие из современных промышленных решений представляют собой технологические платформы, позволяющие масштабировать ETL-процессы с поддержкой параллелизма выполнения операций, перераспределением нагрузки по обработке информации между источниками и самой системой, а также другими функциями в области интеграции данных. Поэтому выбор ETL-средства – это своего рода компромисс между конкретным проектным решением, текущими и будущими перспективами использования ETL-инструментария, а также стоимостью разработки и поддержания в актуальном состоянии всех используемых функций ETL-процесса [2].
Некоторые проблемы ETL-технологий и способы их решения
Как правило, ETL-системы самостоятельно справляются с проблемами подготовки данных к агрегированию и анализу, выполняя операции очистки данных. При этом устраняются проблемы качества данных: проверка на корректность форматов и типов, приведение значений к нужному диапазону, заполнение пропусков, удаление дубликатов, противоречий и нарушений структуры. Однако, кроме очистки данных, можно выделить еще пару трудоемких задач, которые не решаются автоматически:
значимость данных с точки зрения анализа; сложность получения данных из источников; возможное нарушение целостности и достоверности данных; объем данных в источнике.
На практике часто приходится искать компромисс между этими факторами. Например, данные могут представлять несомненную ценность для анализа, но сложность их извлечения или очистки может свести на нет все преимущества от использования [4].
Таким образом, Big Data инструменты пакетной и потоковой обработки позволяют дополнить типовые ETL-системы, предоставляя бизнес-пользователям более широкие возможности по работе с корпоративной информацией. Однако, в этом случае временные, трудовые и финансовые затраты на аналитику данных существенно возрастут, т.к. понадобятся дорогие специалисты: Data Engineer, который выстроит конвейер данных (pipeline), а также Data Scientist, который разработает программное приложение для онлайн-аналитики, включая оригинальные ML-алгоритмы. Впрочем, такие инвестиции будут оправданы, если предприятие достигло хотя бы 3-го уровня управленческой зрелости по модели CMMI, обладает большим количеством разных данных с высоким потенциалом для аналитики и стремится стать настоящей data-driven компанией. Однако, чтобы эти вложения принесли выгоду, а не превратились в пустые траты, стоит адекватно оценить свои потребности и возможности, возможно, с привлечением внешнего консультанта по аналитике данных.
Стоит отметить, что разработчики многих ETL-систем учитывают потребность аналитики больших данных с помощью своих продуктов и потому включают в их возможности работы с Apache Hadoop и Spark, как, например, Pentaho Business Analytics Platform [14]. В этом случае не придется самостоятельно разрабатывать средства интеграции ETL-системы с распределенными решениями сбора и обработки больших данных, а можно воспользоваться готовыми коннекторами и API-интерфейсами. Впрочем, это не отменяет необходимость предварительной аналитической работы по проектированию и реализации ETL-процесса. Организация сбора информации в хранилище данных может достигать до 80% трудозатрат по проекту. Учет различных аспектов ETL-процессов с прицелом на будущее позволит тщательно спланировать необходимые работы, избежать увеличения общего времени реализации и стоимости проекта, а также обеспечить BI-систему надежными и актуальными данными для анализа [2].
ETL в анализе данных без перерывов на кофе и курилку
Кадр из фильма «Индиана Джонс: В поисках утраченного ковчега» (1981)
Наблюдаемая все чаще и чаще картина в задаче анализа данных вызывает удручающее впечатление. Intel, AMD и другие производители непрерывно наращивают вычислительную мощность. Гениальные математики-программисты пишут суперэффективные библиотеки и алгоритмы. И вся эта мощь гасится и распыляется рядовыми аналитиками и разработчиками. Причем начинается это все с нулевого этапа — этап подготовки и загрузки данных для анализа. Многочисленные вопросы и диалоги показывают, что в нынешних программах обучения зияют огромные дыры. Людям просто незнакомы многие концепции и инструменты, уже давно придуманные для этих задач. Для тех, кто хочет увеличить свою продуктивность, далее тезисно будут рассмотрены ряд таких подходов и инструментов в частичной привязке к реальным задачам.
В первую очередь, материал ориентирован на аналитиков, которые манипулируют разумными объемами данных, необходимых для решения практических задач. ETL из Бигдаты в котором перекачиваются сотни Тб ежесуточно живет своей отдельной жизнью.
Разграничим задачи анализа данных на два больших класса:
Технологически сильно больших различий между этими классами нет за исключением того, что при периодическом обмене вы можете дополнительно настоять на получении в аналитический контур машиночитаемых форматов в валидированном виде. При эпизодическом обмене вы можете получать на вход совершенно любые носители и представления и форматы. Бумажные носители или их скан также не являются исключением.
Ключевые ошибки в работе с такими грязными данным можно свести к следующим:
Разделение задач
С точки зрения бизнеса задача предварительной обработки данных не несет никакой ценности. Задача преобразования данных в удобочитаемый формат и задача аналитики должны быть физически разнесены. Преобразование входных файлов в пригодный формат проводится однократно, аналитика же на этих данных может проводиться многократно. Типичная ошибка — когда в один пайп смешиваются задачи загрузки исходников из непригодных форматов (сложные скрипты, огромное время) и аналитика.
В зависимости от задач и объемов, преобразованные данные могут размещаться в локальные файлы, в БД, в облако — да куда угодно. Ключевое требование — минимальное время загрузки в RAM и возможность выборочной загрузки для больших объемов.
Важным эффектом от такого разделения — выполнение аналитики в совершенно чистом пространстве. Все проблемы, утечки памяти, резервы ресурсов и пр., случившиеся на этапе преобразования забыты после завершения этого процесса. У вас на руках только чистые входные данные — можно решать основную задачу.
Задача препроцессинга заканчивается генерацией чистых форматов. Сохранять данные можно разными способами. Если данных чуть больше чем много, то сохранять надо исключительно в бинаризированном виде (БД или файлы) и никаких CSV. При сохранении в БД надо учитывать еще большие накладные расходы на передачу по сети. Так что, если это локальный промежуточный шаг, то оптимально сбрасывать все в локальные файлы, используя, в зависимости от задач только быстрые библиотеки и алгоритмы:
Ниже посмотрим, что можно сделать в отдельных случаях. Смотрим по умолчанию в контексте эпизодической ad-hoc аналитики, хотя большинство решений может быть применено и в потоковом продуктивном контуре.
Предварительный препроцессинг входных файлов
Типовой сценарий — начинается поиск библиотек для работы с этим форматом. Даже если они и находятся, у этих библиотек возникает куча ограничение и сложностей.
Проблемы больше не существует.
PDF формат слабо пригоден для анализа. Формально — это контейнер, содержащий атомарные данные и инструкции для типографской машины по их размещению на листе. В нем сборище графических примитивов. Можно почитать спецификацию «Document management — Portable document format — Part 1: PDF 1.7». Однако PDF весьма популярен при публикации открытых данных различными компаниями, особенно гос.службами.
Какие прагматичные варианты есть? Не очень много.
Не исключено, что pdf файл стоит перед этим предварительно обрезать (crop страниц), разделить на блоки или выдрать только нужные страницы. Это решается как средствами командной строки, так и облачными сервисами — на вкус и цвет найдется любой инструмент. Исключительно для примера — кроссплатформенная утилита PDFsam Basic или облачный сервис PDFResizer.com. Мышкой клац-клац и файл подрезан.
При немного набитой руке и поставленном процессе можно вытаскивать даже табличные данные сложные из сканов практически без ручной правки.
Проблема может и осталась, но объезжена и почти не брыкается.
Когда-то, в конце 90-х, этому формату прочили большое будущее. Даже БД на нем хотели строить. По факту все свалилось куда-то на обочину. Избыточно, крайне сложно, если все делать по-настоящему (c dtd). Но формат стал во многих областях де-факто средством кросс-обмена между программными компонентами или предоставления данных для публикации.
Штатный подход DS — загрузим все в память и распарсим дерево, а так делают «не задумываясь» большинство начинающих и некоторое количество слегка продолжающих, не приводит к успеху на данных чуть больше мизерных. Либо времени требует очень много, либо памяти не хватает. Ситуация усугубляется еще тем, что для анализа достаточно всего некоторого количества полей. Но даже если и удалось весь документ разобрать — обход многоуровневой вложенности циклами по распарсенному дереву на языке высокого уровня — типичный антипаттерн для ETL задач. Так делать совершенно не стоит.
Полагаете тема надумана? Для примера берем открытый «Единый реестр субъектов малого и среднего предпринимательства»,
Какие есть альтернативы?
На самом деле XSLT / XPath из командной строки является единственным серьезным ответом в случае больших объемов и сложной разветвленной структуры. Все было в XML технологии продумано и структурировано до мелочей, а потом и стандартизировано. Но что-то где-то пошло не так.
За компактной сводкой по синтаксису и примерами кода можно обратиться, например, на
W3School.
Проблемы больше не существует, осталось только неудобство.
Json успешно заменяет формат xml, особенно в части обмена данными между отдельными модулями посредством REST API. В большинстве случаев эти структуры данных предназначены для разработчиков и их сложная нефиксированная древовидная структура доставляет много мучений аналитикам данных. Ведь для большинства алгоритмов и функций требуются либо матрицы либо прямоугольные таблицы ( data.frame ).
Типичный способ решения задачи преобразования иерархического json в data.frame — многоуровневые циклы. Такое решение плохо по множеству различных моментов:
Типовой пример из окружающего нас информационного мира. Аналитика помарочного учета.
Собрать данные ветки childs в таблицу штатными функциями парсинга не удастся. Тут и иерархические вложенные массивы и дублирование имен параметров. Ничего удивительного — это же протокол M2M обмена, там цели совсем другие ставились.
Что делаем? Правильно, циклы. На выходе получается примерно такой код.
Можно было бы успокоиться, но мы сделаем еще пару шагов.
Альтернативное решение, которое ни на каких курсах не рассказывают.
И сам код трансформации в R
Все, в одну строчку получили чистое прямоугольное представление. Компактно, стабильно и очень быстро. Вот ссылки на базисные ресурсы по jq :
Шаг 2. Смотрим по сторонам
Хорошо, что есть люди, которых посредственные показатели не устраивают. Совсем недавно появилась библиотека simdjson для парсинга JSON, основанная в т.ч. на применении SIMD инструкций процессоров. Эффект впечатляющий. Детально с принципами и результатами можно ознакомиться в работе Geoff Langdale, Daniel Lemire, «Parsing Gigabytes of JSON per Second, VLDB Journal 28 (6), 2019». https://arxiv.org/abs/1902.08318. Байндинги сделаны почти ко всем популярным языкам.
С упомянутыми инструментами почти никакой json вам не будет страшен, а стиль работы может измениться неузнаваемым образом.
Ну тут то многие вздохнут и скажут, что с этим нет проблем. И могут легко ошибиться.
Возьмем, для примера, практическую задачку. Миллионы «IoT» устройств (электросчетчики, например) фиксируют по расписанию показания своих регистров. И вот эта все сводка приходит вам в виде кучи файлов в весьма странном формате. А что, разработчики счетчиков тоже люди. Они хотели сделать как лучше. Но работаем мы с тем что есть.
Итак, вот пример входного файла:
Тут у нас есть все радости — и время представлено не в ISO формате и числа с разделителем десятичной части, отличающимся от системных настроек (обычно это точка). В довершение всего и знак стоит не там, где надо, почти как в SAP выгрузках. Штатные парсеры загрузчиков csv не помогут. Надо делать все самостоятельно. Итого, у стоит задача парсинга временнЫх и числовых показателей. Понятно, что это не проблема. Вопрос скорее в том, как сделать трансформацию со скоростями не меньше (или даже больше) штатной библиотеки импорта.
Построим генератор входных данных
5.8M записей — в целом, для теста сущие пустяки.
Типовой сценарий — воспроизвести логику загрузчика. Загрузить все как текст и потом построчно провести преобразование. Насколько эффективен этот способ? На это нельзя дать однозначный ответ. Сильно зависит от языка, навыков аналитики, используемых библиотек и особенности структуры данных и специфики предметной области.
Проводим загрузку данных, смотрим тайминги. Чтобы все везде было хорошо, именуйте файлы с использованием только цифр и латинского алфавита.
ВременнАя метка. Немного трюков
Начнем с временной метки. Временные показатели исполнения, естественно, будут зависеть от мощности машины. Поэтому приводимые показатели важны для сопоставительного анализа.
Воспользуемся базовыми функциями R, на сгенерированном датасете получаем примерно 130 секунд. Большинство аналитиков (неважно, на каком языке пишут) скажут, что это вполне нормальная ситуация, нет смысла хотеть бОльшего.
Но не будем на этом останавливаться. Вдруг данных будет немного больше (это же IoT по постановке задачи). 50М или 500М? Поменяем библиотеку с пониманием того, как она устроена внутри и как устроен POSIXct.
Получаем 3.5 секунды на нашем датасете.
Останавливаемся? А почему, собственно, да? Можно попробовать другие библиотеки. Но мы пойдем другим способом. Так уже получается, что у нас есть весь загруженный датасет в память. Давайте пользоваться спецификой предметной области и спецификой преобразуемых данных. Преобразование строки в дату — очень трудозатратная операция. Зачем прикидываться, что мы ничего не знаем о данных и делать эту операцию для каждой строки? Можно же сделать преобразование только для уникальных значений временных меток. Таковых оказывается на порядки меньше, сказывается специфика задачи.
Используем этот подход + меняем библиотеку.
Вариант через групповую обработку — получаем 2.9 сек.
Для потоковых преобразований ограниченных подмножеств наилучшим подходом является предварительное создание словаря «входное значение — преобразованное значение». Тогда вся трансформация будет сводится выборке из этого словаря. Вариант через слияние по ссылкам со словарем дает чуть лучший результат 1.3 сек:
Это все? Потенциально, если расщепить словари даты и времени, то можно сократить объем преобразований еще примерно в 10 раз (1113 + 48 против 53K). Таймзоны в исходных данных не наблюдаются, городов тоже, значит все условно можно считать в UTC.
В таком варианте получаем примерно 0.7 сек.
Итого, путем краткого исследования исходной задачи и незначительных манипуляций получаем ускорение со 130 сек (которые многие аналитики сочли приемлемым) до 0.7 сек. (
180 раз) в базовом варианте, или с 3.5 сек до 0.7 сек (
Числовые показатели. Немного трюков
Формат, конечно, не очень удобный. Штатный парсер такую подачу не берет. Задача нормализации строки тривиальная, легко решается заменами или регулярками. Фактически, надо
На этом можно было бы остановится и большинство делают именно так. Но попробуем сделать еще пару шагов.
Шаг 1. Использование форматного сканера.
Шаг 2. Смотрим по сторонам.
Казалось бы, задача парсинга текстового представления в числа, которой уже «50 лет» и используется везде и всюду, должна быть выверена до мелочей. Многие на это и уповают. Однако, как оказалось, это не так. Техника за это время сильно изменилась, а новые возможности открывают новые способы реализации. Удивительно, что взглянуть на старую задачу по новому решили только в 2020 году. SIMD + словарь преобразований. Daniel Lemire, «Number Parsing at a Gigabyte per Second, Software: Pratice and Experience 51 (8), 2021». https://arxiv.org/abs/2101.11408
Итого, подводим итоги. Оценим временной вклад, который дает предварительное преобразование строки на векторе в 100k значений.
Теперь прогоним различные тесты с учетом базового сценария и шагов 1 и 2.
Видно, что подход настройки параметров парсера лидирует на таком объеме, если числа действительно приходят в кривоватом формате (нет менеджмента памяти!). Базовый же подход самый неудачный. Но на правильных данных, когда не будет накладных на преобразование строк, использование современной библиотеки SIMD парсинга может дать выигрыш, особенно на больших датасетах, на порядок и больше. Тут уже будет все зависеть от числа доступных ядер процессора, объема данных и т.д. Чем всего больше, тем существеннее разница.
Вот так вот. Вы на какой стороне? Черной, белой или зеленой?
Утилиты командной строки
Как только мы договорились, что фаза предварительной подготовки данных и фаза аналитики разведены, можно ни в чем себе не отказывать. Большое количество задач по предварительному процессингу может быть выполнено утилитами командной строки. Зачастую это будет даже быстрее, чем поднимать DS инструменты. Тут и построчный анализ и работа с фиксированным буфером без пула операций менеджмента памяти и оптимизированные *nix библиотеки и устранение всяких байндингов и механизм передачи результатов посредством пайпов, без обращения к диску.
Там, конечно, тоже все нетривиально и есть масса подводных камней. Вот интересный список ссылок, которые высвечивают фонариком разные аспекты в формате попурри. И книги и «полудетективные истории».
Еще быстрее. GNU parallel
В качестве дополнительной вишенки на торте — параллелизация исполнения скриптов в shell. Все инструменты есть в ОС, просто пишите скрипт и бейте задачу. Все остальное — удел операционной системы. Можно начинать читать с разных мест, например с «Get more done at the Linux command line with GNU Parallel»
Заключение
Экспериментальные наблюдения показали, что сочетание различных методов, упомянутых в публикации, может привести к двум результатам: