Пошук Яндекса з інженерної точки зору. Лекція в Яндексі

Сьогодні ми публікуємо ще один з доповідей, що прозвучали на літній зустрічі про пристрої пошуку Яндекса. Виступ керівника відділу ранжирування Петра Попова вийшло в той день самим доступним для широкої аудиторії: мінімум формул, максимум загальних понять про пошук. Але цікаво було всім, тому що Петро кілька разів переходив до деталей і в підсумку розповів багато такого, про що Яндекс ніколи раніше публічно не заявляв.

До речі, одночасно з публікацією цієї розшифровки починається друга зустріч з серії, присвяченій технологіям Яндекса. Сьогоднішній захід — вже не про пошук, а про інфраструктуру. Ось посилання на трансляцію.


Ну а під катом — лекція Петра Попова і частина слайдів.



Мене звати Петро Попов, я працюю в Яндексі. Тут я вже приблизно сім років. До цього програмував комп'ютерні ігри, займався 3D-графікою, знав про відеокартки, писав на SSE-асемблері, загалом, такими речами займався.

Треба сказати, що, влаштовуючись на роботу в Яндекс, я досить мало знав про предметної області — про те, що тут люди роблять. Знав тільки, що тут працюють хороші люди. Тому мав деякі сумніви.



Зараз я розповім досить повно, але не дуже глибоко про те, як виглядає наш пошук. Що таке Яндекс? Це пошуковик. Ми повинні отримати запит користувача та сформувати десятку результатів. Чому саме десятку? Користувачі надзвичайно рідко переходять на більш далекі сторінки. Можна вважати, що десять документів — це все, що ми показуємо.

Не знаю, чи є в залі люди, які займаються рекламою Яндекса, тому що вони вважають, що основний продукт Яндекса — це зовсім інше. Як правило, тут дві точки зору і обидві правильні.

Ми вважаємо, що основне — це щастя користувача. І, як не дивно, від складу десятки і того, як десятки отранжирована, це щастя залежить. Якщо ми погіршуємо видачу, користувачі користуються Яндексом менше, йдуть в інші пошуковики, погано себе почувають.



Яку конструкцію ми спорудили задля вирішення цієї простої задачі — показати десять документів? Конструкція досить потужна, знизу, мабуть, розробники на неї дивляться.

Наша модель роботи. Нам потрібно зробити всього кілька речей. Нам потрібно обійти інтернет, проіндексувати отримані документи. Документом ми називаємо завантажену веб-сторінку. Проіндексувати, скласти в пошуковий індекс, запустити над цим індексом пошукову програму, ну і відповісти користувачеві. Загалом-то, все, профіт.

Пройдемося по кроках цього конвеєра. Що таке інтернет і якого обсягу? Інтернет, вважай, нескінченний. Візьмемо будь-який сайт, який продає що-небудь, який-небудь інтернет-магазин, змінимо там параметри сортування — з'явиться інша сторінка. Тобто можна ставити СGI-параметри сторінки, і зміст буде зовсім інше.

Скільки ми знаємо принципово значущих сторінок з точністю до відкидання незначущих CGI-параметрів? Зараз — порядку декількох трильйонів. Викачуємо ми сторінки зі швидкістю порядку кількох мільярдів сторінок в день. І здавалося б, що нашу роботу ми могли б виконати за кінцеве час, там, за два роки.

Як ми взагалі знаходимо нові сторінки в інтернеті? Ми обійшли якусь сторінку, витягли звідти посилання. Вони — наші потенційні жертви для скачування. Можливо, за два роки ми обійдемо ці трильйони URL, але з'являться нові, і в процесі парсинга документів з'являться посилання на нові сторінки. Вже тут видно, що наше основне завдання — боротися з нескінченністю інтернету, маючи на руках кінцеві інженерні ресурси у вигляді дата-центрів.

Ми завантажили всі божевільні трильйони документів, проіндексували. Далі потрібно покласти їх в пошуковий індекс. В індекс ми кладемо не всі, а тільки найкраще з того, що завантажили.



Є товариш Ашманов, широко відомий у вузьких колах фахівець з пошукових систем в інтернеті. Він будує різні графіки якості пошукових систем. Це графік повноти пошукової бази. Як він будується? Задається запит з рідкісного слова, виглядає, які документи є у всіх пошукових системах, це 100%. Кожен пошуковик знає про якусь частку. Зверху червоним кольором ми, знизу чорним кольором — наш основний конкурент.

Тут можна задатися питанням: як ми досягли такого? Можливі кілька варіантів відповіді. Варіант перший: ми пропарсили сторінку з цими тестами, видерли звідти всі URL, всі запити, які задає товариш Ашманов і проіндексували сторінки. Ні, ми так не робили. Другий варіант: для нас Росія є основним ринком, а для конкурентів вона — щось маргінальне, десь на периферії зору. Ця відповідь має право на життя, але він мені теж не подобається.

Відповідь, яка мені подобається, полягає в тому, що ми виконали велику інженерну роботу, зробили проект, який називається «велика база», під це закупили багато заліза і зараз спостерігаємо цей результат. Конкурента теж можна бити, він не залізний.



Документи ми завантажили. Як ми будуємо пошукову базу? Ось схема нашої контент-системи. Є інтернет, хмарка документів. Є машини, які його обходять — спайдери, павуки. Документ ми завантажили. Для початку — поклали його в збережену копію. Це, фактично, окрема междатацентровая хеш-таблиця, куди можна читати і писати на випадок, якщо ми захочемо потім цей документ проіндексувати або показати користувачеві як збережену копію на видачу.

Далі ми документ проіндексували, визначили мову і витягли звідти слова, наведені згідно морфології мови до основних форм. Ще ми витягли звідти посилання на інші сторінки.

Є ще одне джерело даних, який ми широко використовуємо при побудові індексу і взагалі в ранжуванні — логи Яндекса. Задав користувач запит, отримав десятку результатів і як там себе веде. Йому здалися документи, він клікає або не клацає.

Розумно припустити, що якщо документ з'явився у видачі, або, тим більше, якщо користувач клікнув по ньому, провів якийсь взаємодія, то такий документ потрібно залишити в пошуковій базі. Крім того, логічно припустити, що посилання з такого хорошого документа ведуть на документи, які теж гарні і які непогано б пріоритетно скачати. Тут зображено планування обходу. Стрілочка від планування обходу повинна вести в обхід.

Далі є стадія побудови пошукового індексу. Ці округлі прямоугольнички лежать в MapReduce, нашої власної реалізації MapReduce, яка називається YT, Yandex Table. Тут я трошки лакую — насправді побудова бази і шардирование оперують з індексами як з файлами. Ми це трошки зафиксим. Ці округлі прямоугольнички будуть лежати в MapReduce. Сумарний обсяг даних тут — близько 50 ПБ. Тут вони перетворюються в пошукові індекси, файлики.

В цій схемі є проблеми. Основна пов'язана з тим, що MapReduce — суто батчевая операція. Щоб визначити пріоритетні документи для обходу, наприклад, ми беремо весь линковый граф, мержим його з усім користувальницьким поведінкою і формуємо чергу для скачки. Це процес досить латентний, займає якийсь час. Рівно так само з побудовою індексу. Там є стадії обробки — вони батчевые для всієї бази. І викладка так само влаштована, ми або дельту викладаємо, або все.

Важливе завдання при цих обсягах — прискорити процедуру доставки індексу. Треба сказати, що це завдання для нас складна. Мова йде про боротьбу з батчевым характером побудови бази. У нас є спеціальний швидкий контур, який качає всякі новини в real time, доносить до користувача. Це наш напрямок роботи, те, чим ми займаємося.



А ось друга сторона медалі. Перша — контент-система, друга — пошук. Можна зрозуміти, чому я малював пірамідку — тому що пошук Яндекса дійсно схожий на піраміду, таку ієрархічну структуру. Зверху стоять балансеры, фронти, які генерують видачу. Трохи нижче — агрегуючі метапоиски, які агрегують видачу з різних вертикалей. Треба сказати, що на видачу ви напевно бачили веб-документи, відео і картинки. У нас три різних індексу, вони опитуються незалежно.

Кожен ваш пошуковий запит іде по цій ієрархії вниз і спускається до кожного шматочка пошукової бази. Ми весь індекс, який побудували, розбили на тисячі шматків. Умовно, — на дві-три-п'ять тисяч. Над кожним шматком підняли пошук, і цей запит всюди спустився.



Тут же видно, що пошук Яндекса — велика штука. Чому вона велика? Тому що ми у своїй пам'яті зберігаємо, як ви бачили на попередніх слайдах, досить репрезентативний і потужний шматок інтернету. Зберігаємо не один раз: в кожному дата-центрі від двох до чотирьох копій індексу. Запит наш спускається до кожного пошуку, фактично проходиться за кожним індексом. Зараз використовувані структури даних — такі, що ми змушені все це зберігати безпосередньо в оперативці.



Що потрібно робити? Замість дорогої оперативки використовувати дешевий SSD, прискорити пошук, припустимо, в два рази, і отримати профіт — десятки чи сотні мільйонів доларів капітальних витрат. Але тут не треба говорити: криза, Яндекс економить і все таке. Насправді все, що ми заощадимо, ми пустимо в корисну справу. Ми збільшимо індекс в два рази. Ми будемо за нього якісніше шукати. І це те, заради чого здійснюється такого роду складна інженерка. Це реальний проект, щоправда, досить важкий і повільний, але ми дійсно так робимо, що хочемо пошук наш поліпшити.

Пошуковий кластер не тільки досить великий — він ще і дуже складний. Там реально крутяться мільйони инстансов різних програм. Я спочатку написав — сотні тисяч, але товариші з експлуатації мене поправили — таки мільйони. На кожній машинці в дуже багатьох примірниках 10-20 штук точно крутиться.

У нас тисячі різних типів сервісів розмазані по кластеру. Треба пояснити: кластер — це такі машинки, хости, на них запущені програми, всі вони спілкуються через TCP/IP. Програми мають різне споживання ПРОЦЕСОРА, пам'яті, жорсткого диска, мережі — коротше, всіх цих ресурсів. Програми живуть на хостах в гуртожитку. Точніше, якщо будемо садити одну програму на хост, то утилізація кластера буде ніякої. Тому ми вимушені селити програми один з одним.

Далі слайд про те, що з цим робити. А тут — невелике зауваження, що всі дані програми, всі релізи ми катаємо з допомогою торрентів, і кількість роздач на нашому торрент-трекері перевищує це число на Pirate Bay. Ми реально великі.

Що потрібно робити з усією цією кластерної конструкцією? Потрібно поліпшувати механізми віртуалізації. Ми реально вкладаємося в розробку ядра Linux, у нас є власна система управління контейнерами а-ля Docker, про неї Олег детальніше розповість.

Нам потрібно заздалегідь планувати, на яких хостах які програми один з одним селити, це теж складне завдання. У нас постійно щось на кластер їде. Зараз там напевно десять релізів котяться.

Нам потрібно грамотно селити програми один з одним, потрібно покращувати віртуалізацію, треба-таки об'єднати два великих кластера — роботный і пошуковий. Ми як-то незалежно замовляли залізо і вважали, що є окремо машинки з величезним числом дисків і окремо — тонкі блейды для пошуку. Зараз ми зрозуміли, що краще замовляти уніфіковане залізо і запускати MapReduce і пошукові програми в ізоляції: одне жере в основному диски і мережа, друге в основному CPU, але за CPU у них баланс, потрібно туди-сюди крутити. Це великі інженерні проекти, які ми теж ведемо.

Що ми з цього отримуємо? Користь в десятки мільйонів доларів економії капітальних витрат. Ви вже знаєте, як ми ці гроші витратимо — ми витратимо їх на поліпшення нашого пошуку.

Тут я розповів про конструкції в цілому. Якісь окремі будівельні блоки. Ці блоки люди довбали стамескою, і у них щось вийшло.



Ранжирующая функція Матрікснет. Досить проста функція. Можете почитати — там лежать у векторі бінарні ознаки документа, а в цьому циклі відбувається обчислення релевантності. Я впевнений, що серед вас є фахівці, які вміють на SSE програмувати, і вони живо це прискорили в десять разів. Так воно в якийсь момент і сталося. Тисяча рядків коду нам врятували 10-15% загального споживання CPU на нашому кластері, що знову ж таки становить десятки мільйонів доларів капітальних витрат, які ми знаємо, як витратити. Це тисяча рядків коду, яка коштують дуже дорого.

Ми більш-менш вичистили з репозиторію, соптимизировали, але там ще є що поробиш.

Є у нас платформа для машинного навчання. Індекси з попереднього слайда потрібно підбирати жадібним чином, перебираючи всі можливості. На CPU це робити довго. На GPU — швидко, зате пули для навчання не лізуть в пам'ять. Що потрібно робити? Або купувати кастомні рішення, куди цих залозок багато-багато встромляється, або пов'язувати машинки швидким, використовувати інтерконнект якийсь, infiniband, вчитися з цим жити. Воно типово глючить, не працює. Це дуже забавний інженерний виклик, з яким ми теж зустрічаємося. Він, здавалося б, зовсім не пов'язаних з нашою основною діяльністю, але тим не менш.



У що ми ще інвестуємо, так це в алгоритми стиснення даних. Основне завдання стиснення виглядає приблизно наступним чином: є послідовність цілих чисел, треба її якось компресувати, але не просто компресувати — потрібно ще мати випадковий доступ до i-того елементу. Типовий алгоритм — маленькими блоками стиснути це, мати розмітку для загального потоку даних. Така задача — зовсім інша, ніж контекстне стиснення типу zip чи LZ-family. Там зовсім інші алгоритми. Можна стиснути Хаффманом, Varlnt, блоками типу PFORX. У нас є власний запатентований алгоритм, ми покращуємо його, і це знову ж 10-15% економії оперативної пам'яті на простенький алгоритм.

У нас є всякі забавні дрібниці, наприклад доопрацювання в CPU, планувальники Linux. Там якась проблема з гипертредными камінням від Intel? Те, що на фізичному ядрі є два потоки. Коли там два треда займають два потоку, то вони працюють повільно, латенция збільшується. Потрібно правильно розкидати задачки з фізичним процесорам.

Якщо розкидати правильно, а не так, як робить стоковий планувальник, можна отримати 10-15% латентності нашого запиту, умовно. Це те, що бачать користувачі. Зекономлені мілісекунди множте на кількість пошуків — ось і зекономлений час для користувачів.

У нас є якісь зовсім дивні речі типу власної реалізації malloc, який насправді не працює. Він працює в аренах, і кожна локація просто пересуває курсор усередині цієї арени. Ну і rev counter арени піднімає на одиничку. Арена жива, поки жива остання локація. Для всякої змішаної навантаження, коли у нас є короткоживущая і довгоживуча локація, це не працює, це виглядає як втрата пам'яті. Але наші серверні програми влаштовані не так. Приходить запит, ми там аллоцируем внутрішні структури, як-то працюємо, потім віддаємо відповідь користувачу, все зноситься. Цей аллокатор ідеально працює для наших серверних програм, які без стану. За рахунок того, що всі локації локальні, послідовні в арені, вона працює дуже швидко. Там немає ніяких page fold, cache miss і т. п. Дуже швидко — це від 5% до 25% швидкості роботи наших типових серверних програм.

Це інженерка, що ще можна робити? Можна займатися машинним навчанням. Про це вам з любов'ю розповість Саша Сафронов.

А зараз запитання й відповіді.

Я візьму дуже сподобався мені питання, який прийшов на розсилку і який слід було б включити в мою презентацію. Товариш Анатолій Драпков запитує: є знаменитий слайд про те, як швидко зростала формула до впровадження Матрікснета. Насправді і до, і після. Чи є зараз проблеми зростання?

Проблеми зростання у нас стоять у повний зріст. Черговий порядок збільшення числа ітерацій у формулі ранжирування. Зараз ми там близько 200 тисяч ітерацій робимо функції Матрікснет, щоб відповісти користувачеві. Був отриманий таким інженерним кроком. Раніше ми ранжирували на базових. Це означає, що кожен базовий запускає у себе Матрікснет і видає сто результатів. Ми сказали: давайте ми кращі сто результатів об'єднаємо на середньому і отранжируем ще раз зовсім важкої формулою. Так, ми це зробили, на середньому можна обчислювати в декількох потоках функцію Матрікснет, тому що ресурсів потрібно в тисячу разів менше. Це проект, який дозволив нам досягти чергового порядку збільшення обсягів ранжирующей функції. Що буде ще — не знаю.

Андрій Стыскин, керівник управління пошукових продуктів Яндекса:
— Скільки займала байт перша формула ранжирування Яндекса?

Петро:
— Десяток, напевно.

Андрій:
— Ну, так, напевно, десь символів сто. А скільки зараз займає формула ранжирування Яндекса?

Петро:
— Десь 100 МБ.

Андрій:
— Формула релевантності. Це для наших наглядачів з трансляцій, фахівців з SEO. Спробуйте зареверсинженирить наші 100 МБ ранжирування.

Олеся Болгова, Intel:
— З останнього слайда про malloc не могли б пояснити, як ви виділяєте пам'ять? Дуже цікаво.

Петро:
Береться звичайна сторінка, 4 КБ, на початку у неї rev counter, і далі ми кожну аллокації… якщо маленькі алокації менше сторінки, ми просто рухаємося на цій сторінці. У кожному тред, природно, ця сторінка своя. Коли закрили сторінку — все, про неї забули. Єдине, у неї rev counter на початку.

Олеся:
— Тобто ви сторінку виділяєте?

Петро:
— Всередині сторінки аллокациями ось так ростемо. Єдине, сторінка живе, поки в ній остання алокація живе. Для звичайного workload це виглядає як витік, для нашого — як нормальна робота.

— Як ви визначаєте якість сторінки, варто класти в індекс чи ні? Теж машинне навчання?

Петро:
— Так, звичайно. У сторіночки є безліч факторів, від її розміру до показів на пошуку, до…

Андрій:
— До robot rank. Вона знаходиться на якомусь хості, в якийсь піддиректорії хоста, на неї скільки-то вхідних посилань. Ті, хто на неї посилаються, володіють якимось якістю. Усе це беремо і намагаємося передбачити, з якою ймовірністю, якщо завантажити дану сторінку, на ній буде інформація, яка надійде за якимось запитом про видачу. Це прорікав, відбирається топ з урахуванням розміру документів — тому що в залежності від розміру документа ймовірність, що вона хоч по якомусь запитом потрапить, підвищується. Задача про оптимальний вміст рюкзака. Відбирається з урахуванням розміру документа і кладеться топова в індекс.

—…

Андрій:
— Давай ми тебе представимо спочатку.

— Може, не варто?

Андрій:
— Володимир Гулін, начальник ранжирування пошукової системи Mail.Ru.

Володимир:
— Перший мій питання — про кількість пошуків взагалі. Ви говорили, що ви там драматично збільшили розмір бази. Хочеться взагалі розуміти, з якого обсягу ви стартували, яким був обсяг російського індексу, іноземного індексу, скільки документів припадало на кожен шард, ну і після збільшення…

Петро:
— Це такі цифри, дуже технічні. Може, в кулуарах я б сказав. Я можу сказати, у скільки разів ми приблизно збільшилися — на півтора близько десь. В 30 разів, умовно. За останні три роки.

Володимир:
— Я тоді абсолютні цифри в кулуарах уточню.

Петро:
— Так, за окрему плату, що називається.

Володимир:
— Гаразд. Що стосується свіжості — який приблизно зараз в Яндексі обсяг швидкого індексу? І взагалі з якою швидкістю ви це все оновлюєте, змішуєте?

Петро:
— Індекс реально реалтаймовый, там близько двох хвилин латенції на те, щоб додати документ в індекс. Від моменту, як ми його проіндексували, і діскавері теж — швидка стрибка.

Володимир:
— Але саме знайти документ. Спочатку треба дізнатися, що документ існує.

Петро:
— Я розумію, що питання таке — незрозуміло, коли в інтернеті з'явилася перша посилання на цей документ. Коли ми дізналися першу посилання, то далі це питання хвилин в швидкому шарі.

Андрій:
— Мова йде про мільйони документів, які щодня перебувають у цьому швидкому індексі. Про них зазвичай дуже багато зовнішньої інформації: згадка в Твіттері, сайтмэпы, згадка новини на сайті Lenta.ru. І так як ми перекачуємо мало не кожну секунду морду Lenta.ru ми дуже швидко виявляємо ці документи і протягом одиниць хвилин в гіршому випадку доставляємо їх до пошуку. Вони можуть шукатися. Порівняно з великим індексом мова йде про драматично маленьке число документів, це мільйони.

Петро:
— Так, на 3-4 порядки менше.

Андрій:
— Так, це мільйони документів, які вміють оновлюватися real time.

Володимир:
— Мільйони документів в добу?

Петро:
— Побільше трохи, але приблизно так, так.

Володимир:
— Тепер питання про змішування свіжих результатів і результатів основного пошуку.

Петро:
— У нас два способи змішування. Один — документ тієї ж формулою ранжується, що і батчевый звичайний документ. А другий — спеціальна новинне підмішування, коли ми визначаємо интент запиту, розуміємо, що він реально свіжий і що потрібно щось показати. Два способи.

Володимир:
— Як ви боретеся з ситуацією, коли у вас з популярним запитам, де дофіга кліків, з'являються свіжі результати? Як ви визначаєте, що свіжий результат треба показувати вище того результату, який вже накликан? Запитали у вас: «Google». Ви начебто знаєте, які результати за таким запитом хороші. Але тим не менш, в новинах ще щось, якісь статті…

Петро:
— Це всякі запросные фактори, всякі тренди і все таке.

Андрій:
— Для всіх поясню, в чому складність завдання і питання. Про документ, який довго існує в інтернеті, ми багато чого знаємо. Ми багато знаємо входять на нього посилань, знаємо, скільки на ньому люди проводили часу, а про свіжі документи цього всього не знаємо. Тому складність завдання ранжирування свіжих документів та новин — вгадувати, чи люди це читати, вміти передбачати кількість посилань, які він набере за якийсь час, щоб його показувати нормально. І для підмішування документів за запитом «Google», коли Google щось добре зробив, там існує певна оптимізаційна метрика, яка у нас називається профіцит. Ми вміємо її оптимізувати.

Петро:
— Ми знаємо потік запитів, зміст свежескачанных сторінок. Ці дві речі ми можемо аналізувати і розуміти, що реально свіжий запит вимагає підмішування.

Андрій:
— А потім, на основі ручної оцінки і користувальницького поведінки саме в цю секунду в цей день, ми розуміємо, що саме сьогодні ця новина за запитом важлива і у неї є такі фактори: документ тільки з'явився, на нього стільки-то ретвітів. І тому таку новину, яка буде з таким же розподілом ознак, теж потрібно показувати, коли вона набере відповідні значення.

Петро:
—А фактори там можуть бути такими: кількість знайденого в звичайному шарі проти числа знайденого по цьому запиту в свіжому. Такі наївні, хоча ми його випилюємо ретельно.

Андрій:
— Для тих, кого лякає слово «фактори», спеціально буде третя доповідь, де ми розповімо базові принципи — як взагалі влаштовано машинне навчання, ранжування, що таке фактори, як з допомогою цього зробити пошуковик, який видає нормальні хороші результати.

Володимир:
— Спасибі, решта спитаю потім.

Микита Пустовойтов:
— Виходить, у вас існує велика кількість урлов, про які ви в принципі знаєте, а качати ви можете на кілька порядків менше. Оскільки за час скачування будуть з'являтися нові, більше ви ніколи не відвідаєте. Для вибору застосовується машинне навчання, якісь евристики?

Петро:
—Тільки машинне навчання. Ідея там проста: ми маємо сигнал на якийсь документ, будь, кількість показів, і його розповсюджуємо по посилального графу. Все це агрегируем на сторінці «мета посилання», далі машинним навчанням так само навчаємо шанс здатися, виходячи з цих даних.

Микита:
— Друге питання — інженерний. Ви говорили, що у вас багато CPU-витратних завдань. Чи розглядали ви варіант використання процесора від Intel Xeon Phi? Він начебто набагато швидше працює з оперативною пам'яттю, ніж GPU.

Петро:
— Ми його розглядали завдань для навчання саме нашого Матрікснета, нашої формули, і там він феєрично погано себе показав. А так взагалі у нас дуже плоский профіль, у нас топова функція десь 1,5%. Ми все, що можна, руками соптимизировали, а так у нас онучі С++-коду, який туди не лягає.

— Наскільки я знаю, Яндекс був першим пошуковиком, який почав працювати з російською морфологією. Скажіть, на даний момент це все ще є якимось перевагою чи всі пошуковики однаково добре працюють з російською морфологією?

Петро:
— Зараз в області морфології наука не стоїть на місці. Саша Сафронов розповість про те, чого ми зараз досягаємо, там реально є нові підходи і нові способи вирішення проблем. Наприклад, визначення запитів, схожих на цей, по даній поведінці. Не розширення окремих слів, а розширення запитів запитами.

Андрій:
— Тобто це не зовсім морфологія. Морфологію дійсно, напевно, всі пошуковики більш-менш освоїли, але це базова річ. А ось лінгвістика, знаходження, чим і які слова запиту можна розширити, які ще речі варто пошукати в документі, щоб знайти кандидатів, які будуть більш релевантні — про це буде третій доповідь. Там наше ноу-хау, ми розповімо.

Петро:
— Принаймні, натякніть.

Андрій (глядач):
— Спасибі за короткий екскурс в настільки складну технологію, як пошук Яндекса. Використовує Яндекс deep learning і алгоритми навчання з підкріпленням в побудові швидкого індексу або кеша? Взагалі якщо використовуєте десь, то як?

Петро:
— Deep learning використовуємо для того, щоб чинники ранжирування навчати. Безвідносно до швидкого або повільного індексу. Він використовується для картинок, веба і всього такого.

Андрій Стыскин:
— Влітку запустили версію ранжирування, яка дала 0,5% приросту якості, де ми правильно зварили deep learning на словах. Приїжджали наші колишні колеги з-за кордону і розповідали, що там таке не працює, а ми навчилися.

Петро:
— А може, це тому, що ми для топ-100 документів це робимо. Мова йде про дуже витратною задачі. Наш спосіб побудови пайплайна пошуку дозволяє для сотні документів це робити.

Андрій Стыскин:
— Неможливо порахувати deep learning для всіх кандидатів, яких сотні мільйонів на запити, але для топа документів можна провернути, і у нас ця схема пошуку рівно так працює — дозволяє такі дуже складні наукомісткі алгоритми впроваджувати.

Ігор:
— Про майбутнє пошукача в цілому. Інтернет зараз росте дуже швидко, обсяг, напевно, зростає експоненціально. Чи впевнені ви, що через 10 років ви будете встигати за зростанням інтернету, і впевнені, що будете охоплювати його в такому ж обсязі? Повторіть ще раз, в якому обсязі зараз інтернет охоплений за вашою оцінкою, і що буде через 10 років?

Петро:
— На жаль, можна тільки відсотково по відношенню з ким-то ступінь охоплення визначати. Тому що він реально нескінченний.

Андрій:
— Це гарний філософський питання. Поки ми в нашому колективі за законом Мура встигаємо, кожен рік кратно збільшуємо наш розмір бази. Але це правда складно, правда цікаво, і, звичайно ж, нам навіть не вистачає рук, щоб це робити, але ми хочемо, і знаємо, як це збільшувати в найближчі кілька років деякими серіями поліпшень.

Петро:
— 10 років — занадто далеко, але найближчі роки, подужаємо.

Андрій (глядач):
— Скільки важить репліка інтернету, як вона розноситься між ДЦ, і як здійснюється синхронізація реплік?

Петро:
— Повний обсяг роботных даних — близько 50 ПБ, репліка менше, індекс менше. Можете помножити на коефіцієнт, який вам здається розумним. Ви ж інженер, прикиньте.

Андрій:
— А як розноситься?

Петро:
— Розноситься банально — через torrent, torrent share. Потім качаємо цей файлик.

Андрій:
— Тобто в якийсь момент часу вони не консистентны?

Петро:
— Ні, там потім консистентні перемикання. Буває, що перемикаємо з ДЦ, коли вночі воно раптом не консистентним.

Андрій:
— Тобто можна через F5 — якщо натискаємо, один документ маємо…

Петро:
— Ми боремося з цією проблемою, знаємо про неї, її рішення варто в наших планах.

Іван:
— Як ви боретеся з різними бот-системами і за що можна відправитися в бан?

Петро:
— У нас є спеціальні люди, які знають відповідь на це питання, але вони не скажуть.

Андрій Стыскин:
— На сьогоднішньому заході ми хотіли поговорити про технічні деталі.

Петро:
— Про роботоловилку ми можемо відповісти. Нас дійсно регулярно ддосят, тому у нас прямо на балансере, на першому шарі, коли запит потрапляє, є детекція, що запит з якоїсь мережі прийшов непридатною. Це швидко оновлюється, ми швидко реджектим, воно не валить наш кластер.

Андрій:
— І це теж влаштовано методом машинного навчання. Показується капча, і в залежності від того, як ти її разгадываешь, ми отримуємо позитивні і негативні приклади. На якихось факторах — типу айпишника вкладеної сітки, якогось поведінки, часу між діями — навчаємо і баним або не баним такі запити. DDoS не пройде.

Андрій Аксьонов, Sphinx Search:
— У мене технічні питання. Прохідний питання — чому пам'ять? Невже навіть децл подисковать на SSD не виходить, щоб індекс трохи не влазив, зрідка упирався в SSD?

Петро
— Там виходить так, що футпринт одного запиту порядку 50-100 МБ, він прямо жорсткий. З такою швидкістю ти не зможеш сервить тисячу запитів в секунду, як ми хочемо. Ми працюємо над тим, щоб цей футпринт зменшити. Проблема, що дані про документ розсипані по всьому диску. Ми хочемо зібрати в одне місце, і тоді наша спільна мрія здійсниться.

Андрій Аксьонов:
— Впирається в bandwidth або latency?

Петро:
— В обидва. Ми і послідовно пейджфолдимся, та великі обсяги.

Андрій Аксьонов:
— Тобто неймовірно, але факт: навіть якщо трохи…

Петро:
— Так, навіть якщо трохи отожрешь — все.

Андрій Аксьонов:
— Експоненційний падіння у багато разів?

Петро:
— Так-так.

Андрій Аксьонов:
— Тепер найважливіше питання для промислового господарства: скільки класів рядок і класів векторів в базі?

Петро:
— А ось все менше і менше.

Андрій Аксьонов:
— Ну конкретніше.

Петро:
— У нас прийшли правильні люди, вони насаджують правильні порядки. Зараз це число зменшується.

Андрій Аксьонов:
— Векторів-то скільки і рядків?

Петро:
— Зараз векторів, напевно, навіть один-два максимум.

Андрій Аксьонов:
— Один не буває, хоч два…

Петро:
— Ну ось бачиш.

Андрій Аксьонов:
— А рядків?

Петро:
— Ну має ж бути корпоративний якийсь дух Яндекса.

Андрій Аксьонов:
— Скажи, не томи, ну.

Петро:
— Рядків мінімум дві. Ну три, може.

Андрій Аксьонов:
— Не п'ять?

Петро:
— Не п'ять.

Андрій Аксьонов:
— Очевидний прогрес, спасибі.

Федір:
— Про вашу схему з метапоисками. У вас дуже високий каскад. Які таймінги на кожному рівні, можете озвучити?

Петро Попов:
— Прямо зараз вставляємо ще один шар, не вистачає. Часи відповідей… Середній метапошук робить три раунди ходінь туди-сюди, у нього близько 250 мс, 95-я квантиль. Далі побудова видачі не дуже швидке, але вся конструкція десь за 700 мс відпрацьовує.

Андрій Стыскин:
— Так, там вище JavaScript, так що це 250 мс, а там 700.

Петро:
— Те, що знизу, воно робить купу раундів. У нас теж фахівці зайняті прямо зараз вирішенням цієї проблеми.

Федір:
— У вас намальовано три групи вертикалей. Але у вас є ще Афіша, Новини і так далі. Де ви їх замішуєте в підсумку?

Петро:
— У побудові видачі у нас є такий блендер, який об'єднує всі ці вертикалі, по даній поведінці вирішує, кого показати. Це як раз побудова видачі.

Андрій:
— Вертикалей близько сотні, це шар, який називається верхнім метапоиском. У ньому зливаються результати середніх метапоисков з вертикалі веба, Картинок, Відео і ряду інших, а також з маленьких базових джерел типу Афіші, Розкладів, ТБ і Електричок.

Петро:
— Це до питання про те, чому у нас тисячі різних типів програм. Там дуже багато всяких джерел, воно набігає.

Федір:
— Раз у вас так багато вертикалей, є серед них сторонні, які не ви вважаєте?

Петро:
— Особливо ні. Реклама наша теж вертикальна, окремо від пошуку, але стороннього особливо немає.

Артем:
— У вашого основного конкурента видача завжди була real time, він дельта-індексами докидывал. А в Яндекс був up видачі. Складалося враження, що темною ніччю раз в сім днів людина натискає важіль і розкачує індекси.

Петро:
— На жаль, так і відбувається.

Артем:
— Правильно розумію, що швидкий індекс був зроблений для того, щоб актуалізувати видачу real time?

Петро:
— Так, але загальне рішення. Багато хто так реально роблять, в тому числі і наш основний конкурент.

Артем:
— Чи прагнете ви до того, щоб теж дельта-індексами підкидати, просто відмовитися від швидкого індексу?

Петро:
— Звісно, прагнемо. Ще б знати, як.

Артем:
— Коли можна очікувати?

Петро:
— Хороше питання. На тих же графіках Ашманова видно, як ми оновлюємо індекс. Зараз це видно менше, і ми робимо так, щоб це проходило зовсім швидко і непомітно. Така одна з наших завдань.

Артем:
— Ви кожен раз обробляєте запит користувача? Приходить запит, ви надсилаєте його на бекенд, розраховується формула і результат?

Петро:
— Є кеші, але вони працюють в 50% випадків. 40-50% запитів користувачів — унікальні і ніколи більше не будуть задані. Дуже багато по-справжньому унікальних запитів користувачів взагалі за все життя Яндекса. Кешируем 50-60%. Для кешування теж своя система.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.