Тут главное, чтобы биллинговые отчёты потом не показывали меньше денег, которые надо компании заплатить. И чтобы ночью дежурная смена не беспокоила падениями с индекс аут оф баунд ексепшон. Кто сказал, что вы на боевых данных выловите все возможные сочетания, которые могут возникнуть в дальнейшем?

кмк вы вообще щас про разные вещи говорите

О, эти великолепные секули на 2000 строк, как я по ним скучаю.

Скучал, я вот принёс

Всем привет, а не подскажите, что может тут быть не правильно?
уже день махаюсь с этим
процедура отрабатывает но не возвращает данные (((
https://pastebin.com/iKnd5bgq

Спасибо

К сожалению, во многих местах, где я работал, бизнесу и руководителю разработки зачастую глубоко наплевать на накапливающийся техдолг. У них KPI не на этом построен. И если бизнес скажет что вот этот скуль на 2к строк завтра должен быть на проде - увы, не до оптимизации кода. Лишь в одном месте был хороший руководитель разработки, у которого хватало политического веса и стальных яиц, чтобы бодаться с бизнесом за качество кода. Таких мало))

ну вот кстати DBTшные тесты хорошо против такого работают: декомпозируем на разные модели, пишем тесты против конкретных кусочков, и  какие-то тесты поверх еще

особенно если это датапайплайн, тут же столько логики описано, ее надо обложить тестами

ну это то реалии уже разные)

более, чем достаточно

коллеги, доброе утро!
кто-то пробовал профилировать данные в Clickhouse с помощью great_expectations?

я КХ не делал, но у меня стоит в бэклоге добавить поддержку для нашей базы, и я смотрел - вроде там довольно просто, если есть диалект для SQLAlchemy https://docs.greatexpectations.io/en/latest/guides/how_to_guides/miscellaneous/how_to_add_and_test_a_new_sqlalchemydataset_class.html

Антон, спасибо! как всегда - четко и по делу 🙂

Господа. Есть спецы по HIVE?
Есть пайплайн "Скачивание дельты с источника - вставка в таблицу в HIVE"

Дельта всего 50-60млн строк. Таблица в HIVE партицирована по дате. (и дельта собственно по этой дате и тянется)

У коллег из ETL - вставка данных в HIVE занимает 2,5 часа. И мне кажется это дико странным и очень долгим.

Единственный ньюанс, ETL зачем то используют транзакционные таблицы.

Вот с точки зрения записи\чтения данных с таблицы. Тем более когда ты записываешь\читаешь конкретную партицию... Почему может быть так долго?

партиций много перезаписывается?

и бакетирована ли таблица? а то будет столько писателей, сколько бакетов

данные в базу через питон лучше генератором построчно кидать или же можно df.to_sql, какие +-?

второе точно сильно быстрее

зависит от того какая база, сколько грузить..

2 партиции перезаписывается. Собственно тянем все новые данные со вчера. Бакетирование сейчас не применено.