Яндекс Лабс в 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 запросов, и смежных задач не исключено что да

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

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

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

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