А ты придумал задачу для Яндекса?
3 октября (суббота) пройдёт конференция Яндекса "Я про бэкенд" – в Москве и онлайн. Участие бесплатное, но нужна регистрация. В программе – архитектура и эксплуатация систем вокруг AI, потоковая обработка данных и отказоустойчивость.
➡️ Меня особенно заинтересовала секция с архитектурной задачей. Зрители присылают свои кейсы, организаторы выбирают один, а backend-разработчики Яндекса разбирают его в прямом эфире. Причём решающий увидит условие впервые. Пожалуй, хороший повод посмотреть, как специалист из топовой компании и с большим опытом выясняет требования и ищет компромиссы.
Решил тоже подать заявку – с задачей поиска/фильтрации медицинских документов, о которой уже писал ранее. Если кратко:
25 млн пациентов, (уже) 7 млрд документов и ещё ~5 млн новых каждый день. В среднем у пациента всего 200 документов, и поиск по его медицинской карте должен укладываться в 200 мс на P99. Но тот же сервис должен искать по всей базе за <5 секунд на P99, поддерживать произвольные сочетания фильтров и учитывать изменения документов не позднее чем через 1 секунду после сохранения. Запросы почти всегда идут без ограничения по периоду создания, а хранить данные нужно десятилетиями.
Это вполне прикладная задача: поиск нужен врачам каждый день. Задача сложная, и мне было бы очень интересно посмотреть, насколько мои идеи близки или далеки от того, что могут предложить инженеры Яндекса.
Но помимо прочего хотелось бы посмотреть на ход доказательства.
Допустим, запрос, который за всю историю найдёт только два документа. Или вообще ничего. Как будет вести себя выбранная архитектура в таком случае, и сколько ресурсов потребуется по мере роста базы? Как совместить быстрый поиск по пациенту с поиском по всей истории? Как расширять хранилище и поддерживать актуальность индекса при непрерывной работе сервиса?
Для ответа на все эти вопросы недостаточно выстроить простую логическую цепочку, нужно спроектировать доказательную базу, по которой можно будет оценить корректность выбранной архитектуры. И это нужно сделать до начала разработки и тем более до внедрения.
Вы также можете подать заявку на решение своей задачи. Основное требование: задача должна быть связана с областью информационного поиска, затрагивать одну или несколько смежных тем. Подробности тут.
〰️〰️〰️
Пока Яндекс думает, решать или не решать, анонсирую три ближайших события:
📆 24 сентября, 19:00-20:00 МСК – Открытая сессия "Нейроколлеги в SourceCraft: когда код пишут не только люди". Тут ссылка на YouTube-трансляцию.
📆 25 сентября – LeTeam, фестиваль LentaTech в Санкт-Петербурге и онлайн. Участие бесплатное, по регистрации. Мероприятие больше для тех, кто в ретейле, но мне было бы интересно посмотреть на два доклада (в 15:00 МСК): "Трансформация платформы данных" и "Почему AI-фичи быстро прототипируются и долго доходят до продакшена".
📆 28 сентября – 2 октября – Podlodka Techlead Crew, онлайн-неделя "Techlead в эпоху AI". Про работу техлида, внедрение AI в разработку и оценку его пользы для команды. Это Подлодка, тут все доклады ожидаемы и хороши. :)
#conf
3 октября (суббота) пройдёт конференция Яндекса "Я про бэкенд" – в Москве и онлайн. Участие бесплатное, но нужна регистрация. В программе – архитектура и эксплуатация систем вокруг AI, потоковая обработка данных и отказоустойчивость.
➡️ Меня особенно заинтересовала секция с архитектурной задачей. Зрители присылают свои кейсы, организаторы выбирают один, а backend-разработчики Яндекса разбирают его в прямом эфире. Причём решающий увидит условие впервые. Пожалуй, хороший повод посмотреть, как специалист из топовой компании и с большим опытом выясняет требования и ищет компромиссы.
Решил тоже подать заявку – с задачей поиска/фильтрации медицинских документов, о которой уже писал ранее. Если кратко:
25 млн пациентов, (уже) 7 млрд документов и ещё ~5 млн новых каждый день. В среднем у пациента всего 200 документов, и поиск по его медицинской карте должен укладываться в 200 мс на P99. Но тот же сервис должен искать по всей базе за <5 секунд на P99, поддерживать произвольные сочетания фильтров и учитывать изменения документов не позднее чем через 1 секунду после сохранения. Запросы почти всегда идут без ограничения по периоду создания, а хранить данные нужно десятилетиями.
Это вполне прикладная задача: поиск нужен врачам каждый день. Задача сложная, и мне было бы очень интересно посмотреть, насколько мои идеи близки или далеки от того, что могут предложить инженеры Яндекса.
Но помимо прочего хотелось бы посмотреть на ход доказательства.
Допустим, запрос, который за всю историю найдёт только два документа. Или вообще ничего. Как будет вести себя выбранная архитектура в таком случае, и сколько ресурсов потребуется по мере роста базы? Как совместить быстрый поиск по пациенту с поиском по всей истории? Как расширять хранилище и поддерживать актуальность индекса при непрерывной работе сервиса?
Для ответа на все эти вопросы недостаточно выстроить простую логическую цепочку, нужно спроектировать доказательную базу, по которой можно будет оценить корректность выбранной архитектуры. И это нужно сделать до начала разработки и тем более до внедрения.
Вы также можете подать заявку на решение своей задачи. Основное требование: задача должна быть связана с областью информационного поиска, затрагивать одну или несколько смежных тем. Подробности тут.
〰️〰️〰️
Пока Яндекс думает, решать или не решать, анонсирую три ближайших события:
📆 24 сентября, 19:00-20:00 МСК – Открытая сессия "Нейроколлеги в SourceCraft: когда код пишут не только люди". Тут ссылка на YouTube-трансляцию.
📆 25 сентября – LeTeam, фестиваль LentaTech в Санкт-Петербурге и онлайн. Участие бесплатное, по регистрации. Мероприятие больше для тех, кто в ретейле, но мне было бы интересно посмотреть на два доклада (в 15:00 МСК): "Трансформация платформы данных" и "Почему AI-фичи быстро прототипируются и долго доходят до продакшена".
📆 28 сентября – 2 октября – Podlodka Techlead Crew, онлайн-неделя "Techlead в эпоху AI". Про работу техлида, внедрение AI в разработку и оценку его пользы для команды. Это Подлодка, тут все доклады ожидаемы и хороши. :)
#conf
Просмотры: 18