Неожиданно. Пост на техническую тему.
Уже третий год занимаемся разработкой ETL backend, за это время накопилось небольшое количество опыта и идей, возможно, буду делиться ими здесь.
Один из паттернов, используемых для ETL является Staging Area или Staging Database, то есть промежуточное хранилище (стоит, правда, отдельно отметить, что это хранилище может быть и не базой, по крайней мере не реляционной базой).
Staging Area полезен в случае, когда у вас есть два источника данных, которые асинхронно поставляют вам информацию по одним и тем же сущностям.
К примеру, один из источников поставляет информацию по условиям ценных бумаг, а другой поставляет цены. Предположим, что цены поставляются раз в день после закрытия торгов на бирже. Общая информация по ценным бумагам поставляется постоянно. Информацию по ценам можно загрузить в промежуточное хранилище и проиндексировать. Когда приходит очередное обновление по ценным бумагам то для того, чтобы поднять цены, мы делаем запрос в Staging Area используя ранее созданные индексы. Действительно, не делать же нам поиск по файлам каждый раз.
Staging Area также используется в случаях, когда мы хотим, чтобы база данных сделала за нас некую работу, к примеру join. Полезно в случаях, когда мы сами не можем сделать join, к примеру, по причине объема данных - ни один из входных наборов данных не влазит в память. Если вы используете серьезный ETL tool, то это может и не быть проблемой. В случае нехватки памяти ETL tool может делать дамп на диск. Естественно, это замедлит обработку, но все же может быть быстрее, чем полная вгрузка данных в базу. Однако, если мы пишем ETL process на традиционных языках, то база может быть простым решением этой проблемы.
Стоит однако помнить, что основной проблемой данного приема является повышенная нагрузка на диск. Диск является наиболее частой проблемой с производительностью ETL процессов, поэтому если возможно обойтись без промежуточного хранения на диск - лучше это делать. Все также усугубляется тем, что скорость диска плохо масштабируется.
Практика показывает, что даже при рациональном использовании рано или поздно диск становится проблемой, поэтому стоит сделать так, чтобы это случилось поздно.
Комментариев нет:
Отправить комментарий