AM
граф выполняемого запроса если наведет на какую мысль
Size: a a a
2021 March 03
KS
Кострикин + зорич в двух томах и будет секс
Хорошая связка. Ещё Курош у нас на матфаке был.
А
что если важные дробные данные хранить в программном типе decimal, тогда же не будет таких проблем?
либо по старинке без дробных частей вообще (в копейках, вместо рублей, к примеру)
select cast(1.1 as double)*cast(1.1 as double)*cast(1.1 as double) as dbl, cast(1.1 as decimal(2,1))*cast(1.1 as decimal(2,1))*cast(1.1 as decimal(2,1)) as dcml
либо по старинке без дробных частей вообще (в копейках, вместо рублей, к примеру)
KS
В копейках надежнее, особенно если финансовые данные.
KS
Потом просто умножаем на 1000 или сколько там и всё.
A
не стесняйтесь подаваться, тут столько людей с крутыми архитектурами i.e. @xhumanoid каждый раз чем-то нас убивает
А что сразу косой?
Может я как и хрыч просто жадный и умею грязь находить
Может я как и хрыч просто жадный и умею грязь находить
KS
Народ подскажите как нормально реализовать проверку целостности данных, если они проходят несколько стадий ETL, enrichment и т.д. Это что-то типа транзакций нужно реализовывать, чтобы откатывать на предыдущие чекпойнты или на начало с очисткой промежуточных данных?
ИК
Народ подскажите как нормально реализовать проверку целостности данных, если они проходят несколько стадий ETL, enrichment и т.д. Это что-то типа транзакций нужно реализовывать, чтобы откатывать на предыдущие чекпойнты или на начало с очисткой промежуточных данных?
Если каждый этап может проверить, корректны ли выходные данные, то это будет заметно проще, чем прикручивать транзакции, если их нет. Кроме того, даже транзакция должна как-то понимать, к какому чекпоинту вернуться
Больше подробностей!
Больше подробностей!
KS
Допустим получен снепшот данных в 4.7 млн записей, прошёл первый этап валидации нормально, потом его разбивают на чанки для присоединения ещё данных и если тут всё хорошо, передать другой команде для ещё одного цикла трансформаций, где всё падает и нужно откатиться на самое начало, почистив промежуточные данные, сформированные на первых двух этапах.
KS
Возможно это уже всё где-то реализовано, а я пытаюсь изобрести велосипед, или как выражаются наши западные партнеры изобрести колесо.
KS
Если каждый этап может проверить, корректны ли выходные данные, то это будет заметно проще, чем прикручивать транзакции, если их нет. Кроме того, даже транзакция должна как-то понимать, к какому чекпоинту вернуться
Больше подробностей!
Больше подробностей!
Условий для отката может быть несколько сразу или по одному, например необходимо и достаточно наличие как минимум трёх источников данных (reference data) не старше одного дня на момент обработки текущего снепшота.
ИК
И какой сейчас dataflow?
Пока что выглядит так, что можно проверить условия по if else и никакой rocket science))
Пока что выглядит так, что можно проверить условия по if else и никакой rocket science))
KS
И какой сейчас dataflow?
Пока что выглядит так, что можно проверить условия по if else и никакой rocket science))
Пока что выглядит так, что можно проверить условия по if else и никакой rocket science))
В пределах одного этапа несложно, однако нужно как то хранить состояние каждого из этапов (промежуточные данные, статусы и т.д.), чтобы если следующие этапы не могут завершиться, то процесс знает с какой точки возобновить обработку и с какими промежуточными данными.
KS
Представьте, что процесс разделен на этапы между разными департаментами, а то и компаниями.
KS
То есть нужно как то мониторить состояние процесса на всех этапах с помощью внешнего сервиса.
AS
В пределах одного этапа несложно, однако нужно как то хранить состояние каждого из этапов (промежуточные данные, статусы и т.д.), чтобы если следующие этапы не могут завершиться, то процесс знает с какой точки возобновить обработку и с какими промежуточными данными.
Храни в Кафке, ретеншион для протухающих данных
VM
В копейках надежнее, особенно если финансовые данные.
Помнится у нас пол копейки получилось, сидели чесали репу, что с ней делать
N
Всем привет, знает кто как/чем посмотреть что там с такой яростью собирает GC? Судя по метрикам кол-во входных данных на каждую партицию одинаковое, но при этом разница по времени сборки мусора более чем двукратная и не могу понять почему. Сама операция - join большой таблицы (~500млн) с маленькой (~40млн)
Garbage collector яростно собирает мусор. Тебе надо понять, где он тупит, на минорных сборках или на старых/полных. Для этого можно задать в executor extra java opts вывод в отладку метрики гарбадж коллекшона. Gc verbose xx:printgcdatestampts и вот это вот всё. Только файл лога надо заранее создавать, если его нет, он не ругнется. А потом прогоняй через анализаторы и смотри. Кейсов много может быть. Маленький еден и от этого частые сборки по нему, не успевает в конкарент моде старье почистить, ошибки эвакуации g1 и всё такое прочее.
AM
Garbage collector яростно собирает мусор. Тебе надо понять, где он тупит, на минорных сборках или на старых/полных. Для этого можно задать в executor extra java opts вывод в отладку метрики гарбадж коллекшона. Gc verbose xx:printgcdatestampts и вот это вот всё. Только файл лога надо заранее создавать, если его нет, он не ругнется. А потом прогоняй через анализаторы и смотри. Кейсов много может быть. Маленький еден и от этого частые сборки по нему, не успевает в конкарент моде старье почистить, ошибки эвакуации g1 и всё такое прочее.
спасибо, сейчас попробую