Яндекс Лабс в Palo Alto набирает С++ developers

[dotcom]

Ну е. А еще помню, как хадуп на ПК Агат работал. База была разбросана по 10 дискетам и хадуп после очередного map-reduce'а командовал оператору: "Вставляй диск #10 верхней стороной!". И ведь работало же!

[crypto5]

А на БЗ-34 не запускали? ))

[dotcom]

А на БЗ-34 не запускали? ))

Не, там только ЕГГОГОлогия жила. На фига всяким мусором полезный агрегат заполнять? Впрочем, у мен МК-52 был, а не Б3-34.

[major Major Major Major]

Не, там только ЕГГОГОлогия жила. На фига всяким мусором полезный агрегат заполнять? Впрочем, у мен МК-52 был, а не Б3-34.

Опасное это дело, охота в системе Юпитера

[Albert_al]

Причем парсить их надо сразу в базу данных и потом на оракловском rac-е в PL/SQL аналитическими функциями кранчить

Так все таки в SQL или в PL/SQL? Я почему то только SQL аналитические функции вспоминаю, да и работают они в SQL машине пошустрее

[Сабина]

Причем парсить их надо сразу в базу данных и потом на оракловском rac-е в PL/SQL аналитическими функциями кранчить

Так все таки в SQL или в PL/SQL? Я почему то только SQL аналитические функции вспоминаю, да и работают они в SQL машине пошустрее

процедура сама конечно в plsql а квери он и в африке квери

[Сабина]

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

Обсуждение ответов я читала местами временами по диагонали. Стало интересно если бы сам интервьюировал к себе тим и услышал вот такой ответ на заданный вопрос что бы сказал ? В смысле сразу бы забраковал ? Или наоборот сразу бы одобрил? Или начал задавать наводяшие но в другом направлении ?

Начнем с частного случая. Если количество уникальных запросов заведомо ограничено настолько, чтобы уместиться в памяти локальной машины, то для хранения count per unique query можно использовать hash map, where key is a unique query and value is an updatable count. Then we iterate through the original array of all queries and for each record increment respective count in the hastable. While iterating, we also keep track of a query with max count and its respective count by routinely comparing current max count and incremented count per query.

If the number of unique queries is too large to keep track of on a single machine, then the map implementation from the example above could be changed to store its entries across multiple machines (nodes). Each of the nodes will be responsible for a subset of map entries. For example, with 10 nodes setup, node #1 will hold entries with hashcode ending with 1, node #2 will hold entries with hashcode ending with 2 and so on. Of course this solution will have to carry a burden of network communications etc.

The third solution relies on sorting. The original array is sorted first. Then we simply iterate through the sorted array while keeping track of the query with max number of entries. The advantage of this solution is that it does not require keeping track of all the counts at the same time: once we are done with a segment for a query, we compare the count with max and forget about it (since we'll never encounter the same query again during the iteration). For example, processing a sorted snapshot could look like

Begin:
maxCount = 0, maxQuery = null

Iterate:
Query1, maxCount = 1, maxQuery=Query1
Query2, maxCount = 1, maxQuery=Query1
Query2, maxCount = 2, maxQuery=Query2
Query2, maxCount = 3, maxQuery=Query2
Query3, maxCount = 3, maxQuery=Query2
Query4, maxCount = 3, maxQuery=Query2
Query4, maxCount = 3, maxQuery=Query2

[crypto5]

If the number of unique queries is too large to keep track of on a single machine, then the map implementation from the example above could be changed to store its entries across multiple machines (nodes). Each of the nodes will be responsible for a subset of map entries. For example, with 10 nodes setup, node #1 will hold entries with hashcode ending with 1, node #2 will hold entries with hashcode ending with 2 and so on. Of course this solution will have to carry a burden of network communications etc.

Проще взять БД кассандра, которая делает именно это ))

[Сабина]

If the number of unique queries is too large to keep track of on a single machine, then the map implementation from the example above could be changed to store its entries across multiple machines (nodes). Each of the nodes will be responsible for a subset of map entries. For example, with 10 nodes setup, node #1 will hold entries with hashcode ending with 1, node #2 will hold entries with hashcode ending with 2 and so on. Of course this solution will have to carry a burden of network communications etc.

Проще взять БД кассандра, которая делает именно это ))

То есть если человек этого не будет знать он типа отстал от жизни или как ?

[crypto5]

If the number of unique queries is too large to keep track of on a single machine, then the map implementation from the example above could be changed to store its entries across multiple machines (nodes). Each of the nodes will be responsible for a subset of map entries. For example, with 10 nodes setup, node #1 will hold entries with hashcode ending with 1, node #2 will hold entries with hashcode ending with 2 and so on. Of course this solution will have to carry a burden of network communications etc.

Проще взять БД кассандра, которая делает именно это ))

То есть если человек этого не будет знать он типа отстал от жизни или как ?

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

[Сабина]

Ну для профессии парсельщика логов и находильщика топ 10 запросов, и смежных задач не исключено что да

Вы хотели сказать "нет" для парсельшика логов ?

Так на основании сказанного Берлагой им как раз пофиг были инструментарии, хотели понять как человек будет думать или я чего недопоняла ?

[Berlaga]

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

Обсуждение ответов я читала местами временами по диагонали. Стало интересно если бы сам интервьюировал к себе тим и услышал вот такой ответ на заданный вопрос что бы сказал ? В смысле сразу бы забраковал ? Или наоборот сразу бы одобрил? Или начал задавать наводяшие но в другом

Ни в коем случае не забраковал бы. Ответ абсолютно правильный в рамках сформулированного, я сам примерно так и начал тогда отвечать. Но был подбит еще на взлете фразой "ты соображаешь сколько нужно времени все эти логи читать!? а надо быстро ответить, желательно - сразу!" Ну тут меня уже понесло в предвычисления ... короче, про сэмплинг не сообразил.

А вот в Амазоне схема с предвычислениями прокатила вполне. Но там меня на другом зарезали, я уже когда-то описывал.

[Berlaga]

Проще взять БД кассандра, которая делает именно это ))

На инженерную позицию такой ответ совершенно не годится, на архитекторско-менеджерскую разве что.

[Berlaga]

Так на основании сказанного Берлагой им как раз пофиг были инструментарии, хотели понять как человек будет думать или я чего недопоняла ?

Инструментарий всем пофиг, с сеньорского уровня примерно. Не знает - научится, если не дурак. А дураков в такие места не берут.

[crypto5]

Ну для профессии парсельщика логов и находильщика топ 10 запросов, и смежных задач не исключено что да

Вы хотели сказать "нет" для парсельшика логов ?

Я хотел сказать "да", всмысле - отстал от жизни.

Так на основании сказанного Берлагой им как раз пофиг были инструментарии, хотели понять как человек будет думать или я чего недопоняла ?

Из показаний Берлаги неизвестно, его же не взяли, а при невзятии не обьясняют обычно что не так.

[crypto5]

Проще взять БД кассандра, которая делает именно это ))

На инженерную позицию такой ответ совершенно не годится, на архитекторско-менеджерскую разве что.

Экак вы за все конторы на свете расписались ))

[crypto5]

Так на основании сказанного Берлагой им как раз пофиг были инструментарии, хотели понять как человек будет думать или я чего недопоняла ?

Инструментарий всем пофиг, с сеньорского уровня примерно. Не знает - научится, если не дурак. А дураков в такие места не берут.

Конкретный инструментарий пофиг, а вот что человек не знает что есть уже куча БД (хбейс, риак, бигтейбл, динамо, симплдб, кочдб, ресинкдб, монгодб) которые решают такие проблемы, уже говорит что ни бекграунда ни кругозора в теме у него нету.

[crypto5]

Но был подбит еще на взлете фразой "ты соображаешь сколько нужно времени все эти логи читать!?

Люблю такие темы, когда на десятой странице топика вытаскивается из кармана очередной туз-деталь к задаче

[dotcom]

О, блин, а их еще и читать надо?

[avitya]

Нищеброды. Что у них все логи не в памяти? Нету петабайт НВРАМа?

[dotcom]

Потом еще выяснится, что ваще на ленте все записано и считать можно только через 100 лет.

[Леонид Ильич Брежнев]

Производительность реального сервиса это порядка 25 тыс. RPS. Это значит 100M log entries в час. В томкатовом логе будет ну скажем 10 филдов (наши данные наверняка еше для чего-то будут нужны), или около 1 миллиардa writes.
Кассандра 1.2 на какой-то тестовой системе в один хост давала около 60К writes per second. Ну пусть 50К. 20 секунд - 1М. Итого за 20 тыс. секунд мы засосем все логи данного часа.
Не, ну можно конечно на обработку логов поставить кассандровый кластер, как у нетфликса, из 200 хостов, но нужно имхо более здравое решение.

[Сабина]

уже говорит что ни бекграунда ни кругозора в теме у него нету.

Как то вы очень сильно тему сузили как мне кажется. По приведенному ответу видно что человек подкован не только в теор основах но и практически решал подобные задачи ( может не с таким обьемом данных и без kassandra db - но решал) и голова соображает. Не видно что знаком с конкретными технологиями - согласна, но заявлять об отсуствии бэкграунда и кругозора - это уж совсем необьективно. Вы же в крусе что кроме big data DBs есть еще жизнь на планете IT ?

[crypto5]

Производительность реального сервиса это порядка 25 тыс. RPS. Это значит 100M log entries в час. В томкатовом логе будет ну скажем 10 филдов (наши данные наверняка еше для чего-то будут нужны), или около 1 миллиардa writes.
Кассандра 1.2 на какой-то тестовой системе в один хост давала около 60К writes per second. Ну пусть 50К. 20 секунд - 1М. Итого за 20 тыс. секунд мы засосем все логи данного часа.
Не, ну можно конечно на обработку логов поставить кассандровый кластер, как у нетфликса, из 200 хостов, но нужно имхо более здравое решение.

Леонид Ильич, в решении Сабины речь шла о 10-и машинах, т.е. за 2сек засасывается час логов, или 30 млн запросов в минуту.
К тому же с умелым батчингом я лично засовывал на своем старом ноутбуке по 100к инсертов/инкрементов в секунду, на хорошем железе это будет в раз 5-10 больше.
И у меня, как человека копавшего внутренности кассандры, есть большие сомнения что ваш отряд пионеров, да даже и весь Дом Юных Техников, за разумное время напишет решение которое обгонит кассандру.

[crypto5]

уже говорит что ни бекграунда ни кругозора в теме у него нету.

Как то вы очень сильно тему сузили как мне кажется. По приведенному ответу видно что человек подкован не только в теор основах но и практически решал подобные задачи ( может не с таким обьемом данных и без kassandra db - но решал) и голова соображает.

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

Не видно что знаком с конкретными технологиями - согласна, но заявлять об отсуствии бэкграунда и кругозора - это уж совсем необьективно. Вы же в крусе что кроме big data DBs есть еще жизнь на планете IT ?

Я в курсе что есть АйТи кроме БигДаты, я четко написал что имею в виду бекграунд в биг дата и серче, вполне может быть что он формы на джаваскрипте красивые делает, с этим спорить глупо.