Skip to content

Conversation

@swsvc
Copy link
Contributor

@swsvc swsvc commented Oct 9, 2025

No description provided.

@swsvc swsvc force-pushed the feat/fill-transaction-meta-on-chunk-store branch from 05ed9cc to 32e4854 Compare October 9, 2025 12:40
sa.Column("process_ts", sa.Float), # Время последней успешной обработки
sa.Column("is_success", sa.Boolean), # Успешно ли обработана строка
sa.Column("priority", sa.Integer), # Приоритет обработки (чем больше, тем выше)
sa.Column("status", sa.String), # Статус исполнения трансформации
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Возможно тогда is_success лишняя колонка

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

удаляю

@halconel
Copy link
Contributor

Пока из того что я вижу, тут получится full table scan + cross joins при записи: O(N × T × M) где T - кол-во трансформаций, M - размер связанных таблиц.

Вот в чем суть проблемы:
при каждом вызове store_chunk(), для каждой трансформации зовем get_index_data() для всех связанных таблиц. а get_index_data() читает все данные таблицы. второе, это cross joins при не совпадающих ключах: 1000 profiles х 100K posts = 100M записей в TransformMetaTable

Я бы покрыл новую логику store_chunk() нагрузочными тестами, что бы убедится, что мы не переложили проблему из одного места в другое.

@swsvc
Copy link
Contributor Author

swsvc commented Oct 13, 2025

@halconel суть вот в чем. Если на вход трансформации приходит две или больше таблиц, то по transform_keys этот джойн все равно будет исполняться. Ну просто по логике работы трубы. Насколько я понимаю, этот джойн еще нужно делать вручную в коде трансформации, потому что на вход трансформации приходит несколько таблиц и они там внутри джойнятся. И это не перекладывание проблемы из одного места в другое, это просто то, что задается человеком в пайплайне. От этого никуда не уйти.

На примере: если есть таблица картинок и таблица моделей классификации, которые надо прогнать по этим картинкам, то тут будет кросс джойн, просто из-за логики того, что хочет человек. Получается, что раньше в этом месте потенциально было две больших операции: кросс джойн из-за логики и большой full outer join, от которого хотим уйти. Теперь большой full outer join уходит, а кросс джойн переносится на этап записи данных в таблицу

@halconel
Copy link
Contributor

halconel commented Oct 13, 2025

@halconel суть вот в чем. Если на вход трансформации приходит две или больше таблиц, то по transform_keys этот джойн все равно будет исполняться. Ну просто по логике работы трубы. Насколько я понимаю, этот джойн еще нужно делать вручную в коде трансформации, потому что на вход трансформации приходит несколько таблиц и они там внутри джойнятся. И это не перекладывание проблемы из одного места в другое, это просто то, что задается человеком в пайплайне. От этого никуда не уйти.

На примере: если есть таблица картинок и таблица моделей классификации, которые надо прогнать по этим картинкам, то тут будет кросс джойн, просто из-за логики того, что хочет человек. Получается, что раньше в этом месте потенциально было две больших операции: кросс джойн из-за логики и большой full outer join, от которого хотим уйти. Теперь большой full outer join уходит, а кросс джойн переносится на этап записи данных в таблицу

  1. Запись происходит намного чаще чем чтение в типичных ETL пайплайнах.
  2. Чтение всех связанных таблиц при записи в store_chunk - это не cross join, это full table scan.

@swsvc Я все еще очень надеюсь, что это будет покрыто нагрузочными тестами и мы увидим, как изменилась производительность при записи.

@swsvc
Copy link
Contributor Author

swsvc commented Oct 13, 2025

  • Очевидно, что производительность при записи упадет, потому что выполняются дополнительные операции. Она упадет для разных типов операций по-разному - это тоже очевидно. Нагрузочные тесты я планирую сделать

assert len(list(tmp_dir.glob("tbl2/*.png"))) == 10


@pytest.mark.skip(reason="impossible to trace changes when they happen externally")
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Этот тест изменяет данные на диске вручную. Так как изменения в мету трансформаций прилетают только когда эти изменения отлавливаются (а здесь они не отлавливаются), то заскипал тест

out.write('{"id": "2", "text": "text2"}\n')


@pytest.mark.skip(reason="impossible to trace changes when they happen externally")
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Точто так же как в предыдущем тесте: файл меняется не через трубу а напрямую через file IO. Скипнул

yield pd.DataFrame({"id": [1], "embedding": [[0.1]], "str_payload": ["foo"], "int_payload": [42]})


@pytest.mark.skip(reason="qdrant store cannot read all the rows from the index")
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Вот это теперь снова работает

@swsvc swsvc force-pushed the feat/fill-transaction-meta-on-chunk-store branch from d7b59d9 to aaa2756 Compare October 21, 2025 09:48
if not transform_meta_table_exists:
meta_index = extract_transformation_meta(self.input_dts, self.transform_keys)
if not meta_index.empty:
self.meta_table.insert_rows(meta_index)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Я вот здесь не уверен, надо ли это прямо так делать. Может быть лучше это контролируемо через отдельные менеджмент команды?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

я убрал в метод класса и напрямую вызываю в тестах. Потом если будет юзкейс, то станет понятно, как лучше сделать

@swsvc swsvc force-pushed the feat/fill-transaction-meta-on-chunk-store branch from 2153276 to 565deb4 Compare October 28, 2025 15:26
@swsvc
Copy link
Contributor Author

swsvc commented Nov 12, 2025

В этом коммите есть реализованный алгоритм записи меты для транзакций полностью на sql. Однако он используется только в одном случае: когда все таблицы, участвующие в трансформации, лежат в одной sql базе данных (postgres, sqlite). Если это не так, то джойн происходит в пандасе (потребляет много памяти, потому что выкачивает таблицы для джойна)

@swsvc swsvc force-pushed the feat/fill-transaction-meta-on-chunk-store branch from e9e6b1a to bd2dbfb Compare November 18, 2025 20:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants