Любопытно. Какой хеш используется для разделения юзеров на сегменты? Сталкивались ли с тем, что User ID исторически распределены неравномерно в силу разных причин?
Мы в своё время настрадались от подхода с хешами и пошли немного другим путём. Отдельной колонкой раздали всем юзерам true random номер сегмента, который никогда не меняется. Общее кол-во сегментов выбрали таким образом, чтобы оно делилось без остатка на 2,3,4,5,6. Это самое частое количество вариантов в тесте.
При создании каждого нового теста генерируем маленькую случайную карту для перемешивания сегментов (статичный сегмент юзера => случайный сегмент теста), чтобы один и тот же юзер не попадал постоянно в один и тот же вариант.
В результате получили схему, при которой:
Вообще нет односторонних хешей нигде;
В случае параллельных тестов можно заранее оценить % пересечений и даже найти отдельные user_id при помощи простого JOIN в СУБД;
Думаю, компартрия Китая давно контролирует основные пулы. Просто сейчас не вмешиваются и ждут удобного момента. С их стороны было бы абсолютной глупостью этого не сделать.
Что-то не так с этой задачей. ФИО — не уникальный ключ. Может быть несколько разных людей с одинаковым именем. И один и тот же человек может писать своё имя по-разному в зависимости от настроения (Наталия, Наталья).
Должно быть ещё что-то. Дата рождения, номер паспорта, номер полиса, адрес. Возможно, есть смысл сначала искать прямой match по этим параметрам, а затем уже перебирать имена.
Плюс учитываем то, что женщины склонны менять фамилию после замужества. Это один и тот же пациент, но с другой фамилией начиная с определённой даты. А иногда такое и несколько раз происходит.
Видимо, последний вопрос. Можно ли сделать ожидание на некий внешний источник за пределами Airflow? Например, «появились файлы в HDFS» или «внешний API ответил, что он готов». В теории, можно сделать через retry и долго пытаться, пока не получится. Но ещё лучше совсем в очередь задачу не ставить, пока данные не готовы. Можно ли так сделать?
> Здесь ещё предстоит много работы.
Поделюсь немного информацией о том, какой подход у нас успешно работает. Возможно, какие-то идеи пригодятся.
У каждого разработчика свой отдельный девел на отдельном домене. Конфиги цепочек хранятся в JSON файлах и отслеживаются гитом. Конфиги — не в базе.
База с очередью задач одна на всех, но у каждой таблицы есть колонка «user». Каждый разработчик видит только свою очередь и свои логи. Есть кнопка «Debug reset», которая очищает все данные разработчика и позволяет начать тест с чистого листа.
Колоночная СУБД (Exasol) одна на всех, но есть возможность указать custom prefix для имён схем. Например, обычная схема «FINANCE», а с префиксом будет «VASYA_FINANCE». Такие схемы создаются автоматически на основании DDL из кода. Вместо имён схем в коде везде используются плейсхолдеры. Имена таблиц остаются без изменений. Это позволяет избежать конфликтов DDL и локов, когда сразу несколько человек тестируют что-то одновременно.
При отладке можно указать конкретные цепочки (DAG'и), которые нужно протестировать. Зависимости учитываются автоматически и тоже выполняются. Помогает побыстрее тестировать небольшие изменения и делать code review за разумное время.
На девел загружаются живые данные с production источников, но применяется жёсткий sampling. Вместо миллиарда записей тянем сто записей. Вместо загрузки всех файлов тянем по сто рядов из первых и последних файлов. Всё это позволяет провести некий аналог функционального теста на весь ETL за 20-30 минут.
В идеале, стремимся к полностью изолированным девелам. Насколько это упрощает жизнь — словами не передать.
Самый адский момент с интерфейсом можно увидеть, если один из вариантов финального босса вообще не бить, а только взламывать. Мини-игра происходит прямо в главном меню.
И ещё хорошо получился момент калибровки 2B в начале. Там можно немного подождать или делать не то, что просит 9S. Он будет думать, что что-то сломалось :)
Прочитал и вспомнил свои школьные годы. Мы тогда над одной игрой работали, и был к ней уже готовый редактор. Но мой компьютер едва-едва его тянул. Загрузка реально шла минут 40. И ещё система перегревалась и начинала выдавать BSOD.
Чтобы бороться с перегревом, я брал у родителей в морозилке кусок мяса (!), оборачивал его в четыре пакета и клал внутрь системника. Также ставил будильник, чтобы не забыть через час его поменять, иначе протечёт. Так я работал много месяцев. Всё хорошо закончилось!
Есть желание — найдётся тысяча возможностей. Нет желания — найдётся тысяча причин! (с)
Интересно. Мы в Badoo сделали очень похожую систему, только на php. Некоторые детали отличаются, но общая картина абсолютно такая же.
Все процессы разделены на цепочки (chains). Внутри одной цепочки задачи выполняются всегда последовательно. Цепочки сами выполняют всегда параллельно, но с учётом зависимостей. Схема просто непобедимая в своей простоте.
Как дела обстоят с логикой повторных попыток в случае ошибки (retry)? Как работает перезагрузка блока старых данных? Например, хотим перезагрузить все логи транзакций за 2016 год и всё, что от них зависит за то же самое время. Удобно ли это сделать?
Как организован devel environment? Можно ли целиком протестировать ETL на своей ветке, используя sample от production данных и не мешая при этом другим разработчикам?
Самое сложное в программировании — продвинуть в жизнь какую-то идею, отличную от «общепринятого мнения» и от «привычного порядка вещей». Даже если уже в прошлом такое успешно делал сто раз, всё равно и в 101-ый раз всё по новой.
Сам кодинг, технические сложности, дедлайны, недостаток знаний и опыта — это всё решаемо. Всегда можно сесть и ещё подумать, ещё получше разобраться. Но потом сдвинуть всю махину в правильную сторону — big deal.
Не совсем понимаю, на что они рассчитывали. Понятно, что рано или поздно такой способ раскусят. И об этом узнают в том числе все клиенты, которых уже успели обмануть. Вся репутация прахом, все вложения в движок рекомендаций — в корзину.
У CitusDB нет более-менее эффективных произвольных JOIN'ов. Хотят видеть только JOIN по одинаковым распределённым ключам.
У monetdb и его последователя VectorWise всё неплохо, но нет нормального шардинга. Есть только REMOTE TABLE. После того, как упираешься в мощность одной ноды, наступает беда.
Не знаю, как сейчас, а не так давно можно было сравнительно легко деанонимизировать и авторов анонимных постов с картинками.
В URL картинки была часть, которая указывала на три последних цифры ID пользователя. Далее мы через API выбираем всех подписчиков паблика, фильтруем их по этим цифрам, по полу и примерно возрасту. Далее сортируем оставшихся по дате последнего появления в онлайне.
Как правило, один из первых юзеров в списке и есть наш искомый автор. У меня где-то даже скрипт лежал, который автоматизировал весь процесс.
Главная проблема datatype'ов с поддержкой таймзон — отсутствие единого железного стандарта о том, как они должны работать. Как видим, даже внутри SQL Server поведение типа DateTimeOffset немного отличается от DateTime.
Что будет, если понадобится выгрузить эти данные для обработки в Hive, в BigQuery, в системы аналитики, в визуализаторы (Tableau etc.)? Что будет, если захотим поменять СУБД целиком?
Именно на терабайтную базу косты одинаковые будут. 1Тб сырых данных как раз примерно ужмутся в 200Гб сжатых и целиком влезут в память бесплатной версии. И как раз это всё заведётся на машинке с 256Гб памяти.
Тут вопрос немного в другом. При росте объёма данных те проблемы и острые углы, которые есть у любого продукта, начинают проявляться намного ярче. По шести сотням мегабайт и fullscan можно сделать, сохранив адекватное время ответа. А вот хотя бы на пятистах гигах ClickHouse должен оторваться от MySQL уже на много порядков. Особенно на запросе чуть посложнее WHERE + ORDER BY.
Ради интереса, сгенерировал tours.csv и положил в Exasol (1 node, бесплатный который).
Размер в сжатом виде получился 180.06 Мб.
По времени выполнения, все запросы идут 0.2 — 0.5 секунд, из которых львиная доля уходит на EXECUTE \ COMPILE. Просто на то, чтобы взлететь и понять, что нужно сделать. Данных совсем мало чтобы получить заметную разницу.
Вот бы взять ~1Тб туров, колоночек сделать штук пятьдесят и запрос чуть посложнее. Например, «топ 50 туров, которые искали люди, похожие на вас».
Фармация, первый мед. На удивление полезное образование. Понимаю, что пишут в этих огромных медицинских энциклопедиях, какие лекарства выписал врач, как устроено производство. Ещё генетика, токсикология, физ химия, вот это всё.
С книгами, на мой взгляд, ситуация немного изменилась в последние годы. Раньше они действительно служили отличным источником знаний для тех, кто учится самостоятельно. Но, в текущих условиях, я бы посоветовал бы в первую очередь читать документацию и смотреть реально работающий код.
Причины следующие:
Над книгой обычно работает небольшой коллектив авторов. Правку в документацию может предложить любой человек из коммьюнити.
Всё быстро меняется. Нередко книга устаревает за то время, пока она проходит все технические этапы на стороне издателя. Документация изменяется моментально.
К документации часто есть комментарии, в которых пользователи делятся неочевидными деталями.
Не нужно носить с собой тяжёлые объекты.
Сам пишу код, при этом диплом совсем в другой области. За всю жизнь прочитал 2-3 книги по программированию. Проблем не испытываю, всё хорошо.
Нет ME, нет проблем.
Мы в своё время настрадались от подхода с хешами и пошли немного другим путём. Отдельной колонкой раздали всем юзерам true random номер сегмента, который никогда не меняется. Общее кол-во сегментов выбрали таким образом, чтобы оно делилось без остатка на 2,3,4,5,6. Это самое частое количество вариантов в тесте.
При создании каждого нового теста генерируем маленькую случайную карту для перемешивания сегментов (статичный сегмент юзера => случайный сегмент теста), чтобы один и тот же юзер не попадал постоянно в один и тот же вариант.
В результате получили схему, при которой:
Должно быть ещё что-то. Дата рождения, номер паспорта, номер полиса, адрес. Возможно, есть смысл сначала искать прямой match по этим параметрам, а затем уже перебирать имена.
Плюс учитываем то, что женщины склонны менять фамилию после замужества. Это один и тот же пациент, но с другой фамилией начиная с определённой даты. А иногда такое и несколько раз происходит.
Видимо, последний вопрос. Можно ли сделать ожидание на некий внешний источник за пределами Airflow? Например, «появились файлы в HDFS» или «внешний API ответил, что он готов». В теории, можно сделать через retry и долго пытаться, пока не получится. Но ещё лучше совсем в очередь задачу не ставить, пока данные не готовы. Можно ли так сделать?
> Здесь ещё предстоит много работы.
Поделюсь немного информацией о том, какой подход у нас успешно работает. Возможно, какие-то идеи пригодятся.
В идеале, стремимся к полностью изолированным девелам. Насколько это упрощает жизнь — словами не передать.
Ближе к концу видео:
(Massive spoilers, если собираетесь проходить сами, ни в коем случае не смотреть)
www.youtube.com/watch?v=8UW0sXZx53Q
И ещё хорошо получился момент калибровки 2B в начале. Там можно немного подождать или делать не то, что просит 9S. Он будет думать, что что-то сломалось :)
Чтобы бороться с перегревом, я брал у родителей в морозилке кусок мяса (!), оборачивал его в четыре пакета и клал внутрь системника. Также ставил будильник, чтобы не забыть через час его поменять, иначе протечёт. Так я работал много месяцев. Всё хорошо закончилось!
Есть желание — найдётся тысяча возможностей. Нет желания — найдётся тысяча причин! (с)
Все процессы разделены на цепочки (chains). Внутри одной цепочки задачи выполняются всегда последовательно. Цепочки сами выполняют всегда параллельно, но с учётом зависимостей. Схема просто непобедимая в своей простоте.
Как дела обстоят с логикой повторных попыток в случае ошибки (retry)? Как работает перезагрузка блока старых данных? Например, хотим перезагрузить все логи транзакций за 2016 год и всё, что от них зависит за то же самое время. Удобно ли это сделать?
Как организован devel environment? Можно ли целиком протестировать ETL на своей ветке, используя sample от production данных и не мешая при этом другим разработчикам?
Сам кодинг, технические сложности, дедлайны, недостаток знаний и опыта — это всё решаемо. Всегда можно сесть и ещё подумать, ещё получше разобраться. Но потом сдвинуть всю махину в правильную сторону — big deal.
И стоило оно того?
У monetdb и его последователя VectorWise всё неплохо, но нет нормального шардинга. Есть только REMOTE TABLE. После того, как упираешься в мощность одной ноды, наступает беда.
В URL картинки была часть, которая указывала на три последних цифры ID пользователя. Далее мы через API выбираем всех подписчиков паблика, фильтруем их по этим цифрам, по полу и примерно возрасту. Далее сортируем оставшихся по дате последнего появления в онлайне.
Как правило, один из первых юзеров в списке и есть наш искомый автор. У меня где-то даже скрипт лежал, который автоматизировал весь процесс.
Что будет, если понадобится выгрузить эти данные для обработки в Hive, в BigQuery, в системы аналитики, в визуализаторы (Tableau etc.)? Что будет, если захотим поменять СУБД целиком?
Тут вопрос немного в другом. При росте объёма данных те проблемы и острые углы, которые есть у любого продукта, начинают проявляться намного ярче. По шести сотням мегабайт и fullscan можно сделать, сохранив адекватное время ответа. А вот хотя бы на пятистах гигах ClickHouse должен оторваться от MySQL уже на много порядков. Особенно на запросе чуть посложнее WHERE + ORDER BY.
Размер в сжатом виде получился 180.06 Мб.
По времени выполнения, все запросы идут 0.2 — 0.5 секунд, из которых львиная доля уходит на EXECUTE \ COMPILE. Просто на то, чтобы взлететь и понять, что нужно сделать. Данных совсем мало чтобы получить заметную разницу.
Вот бы взять ~1Тб туров, колоночек сделать штук пятьдесят и запрос чуть посложнее. Например, «топ 50 туров, которые искали люди, похожие на вас».
Интересно ^^
Причины следующие:
Сам пишу код, при этом диплом совсем в другой области. За всю жизнь прочитал 2-3 книги по программированию. Проблем не испытываю, всё хорошо.