Arrow + ADBC + dlt — новый speed limit для ingestion
DLT недавно сделал бенчмарк, и результат получился интересный:
EL-пайплайны ускоряются примерно в 3.7 раза, если просто перестать ломать Arrow по дороге.
Проблема в том, как обычно устроен ingestion.
Даже если источник уже отдаёт данные в Arrow, дальше они почти всегда проходят через Python.
Arrow-таблица превращается в миллионы dict’ов, потом это всё скармливается ORM или SQLAlchemy, а уже оттуда летит в базу.
Формально пайплайн работает, но по факту мы берём columnar-данные и насильно запихиваем их в row-based мир.
В этот момент Arrow раздувается в Python-объекты, и всё, ради чего он вообще существует, исчезает:
векторизация, zero-copy, нормальная работа с кэшем.
CPU начинает тратиться не на данные, а на сериализацию и сборку мусора.
Поэтому стадия нормализации, которая по идее должна занимать миллисекунды, внезапно занимает минуты и выглядит это как ну, данные большие, ничего не поделаешь.
Решение оказалось банально простым: вообще не выходить из columnar-пути.
Arrow остаётся Arrow от источника до приёмника, ADBC даёт columnar-доступ к базе, а dlt просто оркестрирует этот процесс.
На выходе те самые ~3.7× ускорения, заметно меньшая нагрузка на CPU и ощущение, что пайплайн наконец-то делает работу, а не борется сам с собой.
А если делать ingest с ConnectorX, то вообще будет пушка.
Про то, как arrow захватывает мир данных, был пост в канале.
♾️benchmark ♾️
@five_minutes_of_data
DLT недавно сделал бенчмарк, и результат получился интересный:
EL-пайплайны ускоряются примерно в 3.7 раза, если просто перестать ломать Arrow по дороге.
Проблема в том, как обычно устроен ingestion.
Даже если источник уже отдаёт данные в Arrow, дальше они почти всегда проходят через Python.
Arrow-таблица превращается в миллионы dict’ов, потом это всё скармливается ORM или SQLAlchemy, а уже оттуда летит в базу.
Формально пайплайн работает, но по факту мы берём columnar-данные и насильно запихиваем их в row-based мир.
В этот момент Arrow раздувается в Python-объекты, и всё, ради чего он вообще существует, исчезает:
векторизация, zero-copy, нормальная работа с кэшем.
CPU начинает тратиться не на данные, а на сериализацию и сборку мусора.
Поэтому стадия нормализации, которая по идее должна занимать миллисекунды, внезапно занимает минуты и выглядит это как ну, данные большие, ничего не поделаешь.
Решение оказалось банально простым: вообще не выходить из columnar-пути.
Arrow остаётся Arrow от источника до приёмника, ADBC даёт columnar-доступ к базе, а dlt просто оркестрирует этот процесс.
На выходе те самые ~3.7× ускорения, заметно меньшая нагрузка на CPU и ощущение, что пайплайн наконец-то делает работу, а не борется сам с собой.
А если делать ingest с ConnectorX, то вообще будет пушка.
Про то, как arrow захватывает мир данных, был пост в канале.
♾️benchmark ♾️
@five_minutes_of_data