Если вы открыли эту дверь статью, то наверняка, вы уже имели дело с ClickHouse и можно упустить интересные подробности об его удобстве и скорости, а перейти сразу к делу – собственно, к тому, как создавать словари и работать с ними в ClickHouse.

Современные Data Pipelines превратились в commodity наподобие электричества в розетке – они просто должны быть и функционировать, обеспечивая базовые потребности аналитиков и инженеров. 

Множество компаний, таких как Fivetran, Hevo, Alooma, сегодня зарабатывают на предоставлении Data Pipelines / Integration как сервис. Наряду с очевидными преимуществами, основными недостатками являются закрытый исходный код и отсутствие возможности быстро добавлять новые коннекторы.

В этой публикации на примере репликации данных открытого счетчика Яндекс.Метрика в объектное хранилище S3 я познакомлю вас с Airbyte – решением с открытым исходным кодом. Это новый стандарт для выстраивания потоков интеграции данных из всевозможных приложений, баз данных и API в аналитические хранилища данных, озера данных.

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

Кэширование

Давайте начнем с самых простых, но довольно мощных функций модуля functools. Начнем с функций кэширования (а также декораторов) - lru_cache, cache и cached_property. Первая из них - lru_cache предоставляет кэш последних результатов выполнения функций, или другими словами, запоминает результат их работы:

SQL – это нескучно. С современными инструментами возможности языка кратно возросли. Мультитул для моделирования данных dbt, современные колоночные аналитические СУБД позволяют буквально творить с данными чудеса.

Меня зовут Артемий и я Analytics Engineer в компании Wheely. И сегодня я подготовил небольшой экскурс в реальные и интересные сценарии использования гибридного SQL

– Операции Pivot и Unpivot для табличных данных

– Генерирование суррогатного ключа и ключа конкатенации

– Гибкая фильтрация записей из таблиц-источников

– Автоматизация экспорта данных из Хранилища в S3

– Валютные курсы, Continuous Integration, Data Quality

MongoDB – одна из самых популярных документ-ориентированных баз данных класса NoSQL с большим сообществом пользователей. Ее основными преимуществами являются гибкость схемы хранения, иерархическая структура документов, поддержка расширенного набора типов данных. Сегодня MongoDB чаще всего используется как бэкенд веб- и мобильных приложений.

Казалось бы, зачем может потребоваться извлекать схему данных в schemaless database? Однако это может быть крайне полезно и в некоторых ситуациях абсолютно необходимо:

•  Репликация данных в аналитическое хранилище

•  Интерактивная аналитика из BI-инструментов (SQL)

•  Аудит имеющейся структуры БД

В этой публикации я хотел бы показать простой и удобный способ получения схемы хранения данных, даже при наличии сотен коллекций и миллионов документов в MongoDB.

Что такое дизайн информационных систем

В свободное и не свободное время[1] я развиваю несколько своих проектов на github, а также, по мере сил, участвую в жизни интересных для меня, как программиста, проектах.

Недавно один из коллег попросил консультацию: как выложить разработанную им библиотеку на github. Библиотека никак не связана с бизнес-логикой приложения компании, по сути это адаптер к некоему API, реализующему определённый стандарт. Помогая ему, я понял что вещи, интуитивно понятные и давно очевидные для меня, в этой области, совершенно неизвестны человеку делающему это впервые и далёкому от Open Source.

Я провел небольшое исследование и обнаружил что большинство публикаций по этой теме на habrahabr освещают тему участия (contributing), либо просто мотивируют каким-нибудь образом примкнуть к Open Source, но не дают исчерпывающей инструкции как правильно оформить свой проект. В целом в рунете, если верить Яндекс, тема освещена со стороны мотивации, этикета контрибуции и основ пользования github. Но не с точки зрения конкретных шагов, которые следует предпринять.

Так что из себя представляет стильный, модный, молодёжный Open Source проект в 201* году?

В данной статье мы рассмотрим небезопасные варианты написания собственного Dockerfile, а также лучшие практики, включая работу с секретами и встраивание инструментов статического анализа. Тем не менее для написания безопасного Dockerfile наличия документа с лучшими практиками мало. В первую очередь требуется организовать культуру написания кода. К ней, например, относятся формализация и контроль процесса использования сторонних компонентов, организация собственных Software Bill-of-Materials (SBOM), выстраивание принципов при написании собственных базовых образов, согласованное использование безопасных функций, и так далее. В данном случае отправной точкой для организации процессов может служить модель оценки зрелости BSIMM. Однако в этой статьей пойдет речь именно о технических аспектах.

Прежде чем фича попадет на прод, в наше время сложных оркестраторов и CI/CD предстоит пройти долгий путь от коммита до тестов и доставки. Раньше можно было кинуть новые файлы по FTP (так больше никто не делает, верно?), и процесс «деплоя» занимал секунды. Теперь же надо создать merge request и ждать немалое время, пока фича доберётся до пользователей.

Часть этого пути — сборка Docker-образа. Иногда сборка длится минуты, иногда — десятки минут, что сложно назвать нормальным. В данной статье возьмём простое приложение, которое упакуем в образ, применим несколько методов для ускорения сборки и рассмотрим нюансы работы этих методов.

Так повелось, что в нашей компании основным языком для backend разработки был выбран C#. Мы, кстати, этим выбором всегда были довольны, а когда MS начали развивать платформу .net Core, стало еще интереснее, так как C# — это хорошо, но C# под Linux — еще лучше.

Путь перехода на кросс-платформенную разработку я описывать не стану, так как уже очень многие прошли путь перехода с Framework на Core.

Сделаю акцент на одном моменте. Помимо всего прочего, в сторону хостинга наших приложений под Linux нас подтолкнул Docker, так как очень хотелось приобщиться к молодежному течению контейнеризации всего что только возможно.

Поскольку мы разрабатываем enterprise, то вместе с нами должна была убежать под linux и сквозная windows аутентификация. Собственно это и стало побудителем к написанию статьи. Так как информация находилась весьма трудно, отдельными кусками, и общением со многими людьми, идея собрать все необходимое в одном месте и описать работающий вариант показалась неплохой.

По нашей просьбе Хабр создал хаб Kubernetes и нам приятно разместить первую публикацию в нём. Подписывайтесь!

Рано или поздно аналитик сталкивается с проблемой организации данных. Их становится все больше, структура перестает быть прозрачной, а одни и те же SQL-запросы приходится переписывать по несколько раз. Решить эту проблему можно с помощью dbt – инструмента, который открывает новый подход к трансформации и моделированию данных. Под катом – перевод отличной статьи Дэвида Кревитта о том, что такое dbt, и как этот инструмент помогает аналитикам облегчить свою работу.

• Разбираемся, как на самом деле считаются суммы и проценты в клиентском приложении.

• Собираем все данные по портфелю и по всем операциям через Tinkoff API.

• Строим огромную Excel таблицу со всеми данными.

• Узнаём, сколько комиссий и налогов с нас уже содрали и что нам останется при выводе.

• Пытаемся понять, что нам с этим делать.