Известное об известном: spark работает с “датафреймами” (dataframes), которые являются алгоритмами трансформации. Алгоритм запускается в самый последний момент для того, чтобы "дать больше места" оптимизации и за счет оптимизации максимально эффективно его выполнить.

Под катом мы разберем — как можно разложить многостраничный SQL запрос на атомы (без потери эффективности) и как можно за счет этого существенно уменьшить время выполнения ETL конвейера.

Привет всем, немного информации "из под капота" дата инженерного цеха Альфастрахования — что будоражит наши технические умы.

Apache Spark — замечательный инструмент, позволяющий просто и очень быстро обрабатывать большие объемы данных на достаточно скромных вычислительных ресурсах (я имею в виду кластерную обработку).

Традиционно, в процессе ad hoc обработки данных используется jupyter notebook. В комбинации со Spark-ом это позволяет нам манипулировать долго живущими дата фреймами (распределением ресурсов занимается Spark, дата фреймы "живут" где-то в кластере, время их жизни ограничено временем жизни Spark контекста).

После переноса обработки данных в Apache Airflow время жизни дата фреймов сильно сокращается — Spark контекст "живет" в пределах одного оператора Airflow. Как это обойти, зачем обходить и при чем здесь Livy — читайте под катом.

В Альфастраховании мы активно пользуемся "Вики", движком которого выступает Atlassian Confluence. Когда я первый раз с ним всерьез столкнулся (в попытке создать в нем контент), мне в нем не хватило "динамичности" — хотелось иметь возможность программно формировать части страниц, взаимодействовать с другими системами и т.п.

Некоторое время бился головой в разные стены, но потом увидел, что "в доме не было одной стены". Хочу поделиться опытом — как можно добавить динамики в Confluence. Надеюсь, это будет полезно тем, кто им пользуется. И, как обычно, всем любознательным.

В Hadoop входят продукты, которые могут работать с файлами разных форматов. Я неоднократно искал, читал и думал над тем — какой же формат лучше. Относительно случайно столкнувшись с форматом ORC, заинтересовался, почитал (и даже чуть покодил) и вот что понял — сравнивать форматы как таковые некорректно. Точнее, их обычно сравнивают, на мой взгляд, некорректным образом. Собственно, статья об этом, а также о формате Apache ORC (в техническом плане) и предоставляемых им возможностях.

Начну с вопроса: каким может быть размер реляционной таблицы (в байтах и очень примерно), состоящей из 10 тысяч строк (по два целых поля в строке)? Обычно здесь ставят кат, а ответ помещают под катом — я отвечу здесь: 628 байт. А детали и историю перенесу под кат.

Мы в Альфастраховании используем SAP ERP как процессную систему урегулирования убытков. И так уж получилось, что мы ее немножко дорабатываем, это неизбежно приводит к возникновению в коде ошибок. Если ошибки доходят до продуктивной системы — это плохо. Этого надо избегать, один из способов — регрессионное тестирование. В этой статье я расскажу о том, как именно мы проводим "регресс" для SAP, потому что делаем мы это (эх!) нестандартно.

Началось все это несколько лет назад. В те годы мы уже активно использовали регрессионное тестирование, но никак не могли сделать этого в SAP — используемые инструменты с SAP-ом не работали, изучать "заточенные" под SAP инструменты команда тестировщиков что-то не хотела. Уже точно и не вспомню почему, но я воспринял это как вызов (это было еще до того, как я переключился на дата инженерию) и решил "изучить" вопрос.

Результаты изучения (а также "делания") — в этой статье (ниже), кратко скажу так: мы автоматически тестируем SAP (и его ближайшее окружение), делаем это достаточно эффективно (во всех смыслах), мы не потратили ни рубля на лицензии и обучение, наш подход прост и вполне воспроизводим. И мы не используем никакие инструменты SAP для автоматического тестирования SAP (разве что в том месте, где мы встроились в его транспортную систему).

В первой статье о структуре QVD-файла я описал общую структуру и достаточно подробно остановился на метаданных, во второй — на хранении колонок (символов). В этой статье я опишу формат хранения информации о строках, подытожу, расскажу о планах и достижениях.

Итак (вспоминаем) QVD-файл соответствует реляционной таблице, в QVD файле таблица хранится в виде двух косвенно связанных частей:

Таблицы символов (термин мой) содержат уникальные значения каждой колонки исходной таблицы. О них я рассказывал во второй статье.

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

В первой статье о структуре QVD файла я описал общую структуру и достаточно подробно остановился на метаданных. В этой статье я опишу формат хранения информации о колонках, поделюсь своим опытом трактовки этих данных.

Итак (вспоминаем) QVD файл соответствует реляционной таблице, которая, как известно состоит из строк. Каждая строка таблицы в свою очередь состоит из колонок (или полей), причем строки имеют одинаковую структуру, которая может быть описана, например, SQL оператором (create table).

В QVD файле таблица хранится в виде двух косвенно связанных частей:

Таблицы символов (термин мой) содержат уникальные значения каждой колонки исходной таблицы. Именно о них пойдет речь ниже.

Таблица строк содержит строки исходной таблицы, каждая строка хранит индексы значений колонки (поля) строки в соответствующей таблице символов. О таблице строк более подробно я расскажу в третьей части этой серии.

QlikView и его младший брат QlikSense — замечательные BI инструменты, достаточно популярные у нас в стране и "за рубежом". Очень часто эти системы сохраняют "промежуточные" результаты своей работы — данные, которые визуализируют их "дашборды" — в так называемые "QVD файлы". Часто QVD файлы используются в качестве основного хранилища в многоэтапных ETL процессах, построенных на базе Qlik. И тогда у некоторых (у меня, например, — я занимаюсь в компании вопросами инженерии данных) возникает вопрос — можно ли и как воспользоваться этими данными без QlikView/QlikSense? Или другой — а что там и правильно ли "оно" посчиталось?

QVD — это формат файла, оптимизированный для работы QlikView/QlikSense (чтение из запись информации этими приложениями в файлы такого формата происходит существенно быстрее, чем в файлы любого другого формата). Структура этого файла недокументирована и покрыта "мраком проприетарности", практически не существует приложений, которые способны работать такими файлами (читать и тем более писать). В этой серии статей я поделюсь своим опытом и полученными практическими познаниями: я знаю, как устроен QVD, умею напрямую и быстро его читать и в него писать.

Кому будет интересна данная информация: в первую очередь тем, кто работает с QlikView/QlikSense, а также тем, кто (как и я) хотел бы воспользоваться данными, хранящимися в QVD файлах. Ну и, конечно, всем любознательным.