• Как попасть на стажировку в Google
    +2
    Также могут задать вопрос на oбъектно-ориентированный дизайн, чтобы посмотреть, насколько хорошо вы разбираетесь в проектировании программного обеспечения. Например, могут попросить спроектировать простенький онлайн-магазин. Правда мне ни разу не попадалось такой задачи, по решению которой действительно можно было бы судить об этом навыке.
    Задачи на дизайн обычно начинаются с уровней L4/L5, их не задают джуниурам и тем более стажерам.

    По их результатам мне согласились дать оффер и начали искать команду, однако я отказался от этого варианта, поскольку решил закончить магистратуру.
    Попасть в Гугл после стажировки — самый простой вариант. После магистратуры вам придется проходить 5 онсайт интервью, среди которых уже будет NALSD, и пройти его значительно сложнее, чем те 2 интервью в рамках Intern Conversion.
  • Программистом к ирландским букмекерам
    0
    3.5 года в Ирландии, и придерживаюсь противоположного мнения — как раз с детьми переезжать сюда лучше, чем одиноким и парам без детей. Для детей здесь хорошие школы, бесплатное медицинское обслуживание, чистый воздух и возможность жить в своем доме с садом, при этом оставаясь в городе. Без семьи я бы скорее переехал в США или Лондон/Цюрих, а для семейных Ирландия — более удачный вариант.
  • Чего боятся программисты?
    0

    Выкатывать хотфиксы сразу в прод — а вы рисковый. С точки зрения SRE, сначала безусловно делается rollback к предыдущему релизу, а уж потом анализ причин поломки, исправления и т.д. Roll forward — только для чего-то не очень критичного.

  • Применение моделей CatBoost внутри ClickHouse. Лекция Яндекса
    +1
    Дополнительно ClickHouse сжимает данные, и то, что мы храним данные по столбцам, дает нам преимущество. Данные получаются более отдаленные и лучше сжимаются.

    Наверное, оговорка: в одном столбце данные более гомогенные, поэтому и сжимаются лучше.

    … есть пример — вычисление средней длительности сессии.

    Наверное, в запросе опечатка — на слайде выбирается только avg_duration, но не FirstPartyCookie, то есть запрос возвращает только средние длительности сессий без привязки к кукисам, что в общем-то бесполезно.

    Также мы использовали sampling: сказали, что будем читать 1/10 часть данных. ClickHouse делает это эффективно, он выбрасывает ненужные данные сразу после прочтения данных с диска.

    Насколько мне известно, в аналитических СУБД основное время тратится именно на общение СУБД с диском. То есть проведение сэмплинга после чтения с диска в большинстве случаев лишено смысла — я практически уверен, что в приведенном примере запросы с сэмплингом и без будут выполняться приблизительно одинаковое время. Другое дело, что сэмплинг на уровне блоков не будет случайным, но это уже другой вопрос.

    У нас есть обученная модель, она выдает хорошее качество. Как теперь ее внедрять?
    Казалось бы, вопрос простой. Давайте делать просто: каждый понедельник выгружать из ClickHouse данные за предыдущий месяц, запускать питоновские скрипты, получать вероятность покупки и загружать обратно, скажем, в ту же таблицу ClickHouse

    Стоп. Зачем выгружать, зачем питоновские скрипты? Давайте сначала остановимся и опишем, какую именно задачу мы хотим решить? В большинстве случаев намного более эффективным будет применение модели в реальном времени — пользователь присылает запрос, и специальный сервис применяет последнюю версию вашей модели к данным конкретного запроса. Почему вы решили, что нужно применить именно оффлайн предпосчет вероятностей, без указания мотивации этого решения?

    Вопрос по существу 1: вы храните данные в column-oriented таблицах, и предлагаете применять к этим данным одну из обученных моделей. Проблема в том, что для применения модели зачастую требуются практически все столбцы таблицы. В итоге, колоночная СУБД для вашего запроса собирает полные строки исходных данных — не является ли overkill'ом использование колоночной БД в этом случае? Согласно моему опыту, колоночное хранение данных выигрывает у построчного при использовании <50% столбцов в запросе, а использование 100% столбцов — худший кейс для колоночной БД.

    Вопрос по существу 2: вы используете свой XML-подобный формат для хранения моделей. Почему не PMML, являющийся стандартом де-факто в индустрии?
  • Кинетика больших кластеров
    0
    Вопрос не в «цифра не нравится», а предсказание предложенной вами модели расходится с практически наблюдаемыми значениями на 7-8 порядков. 7-8 порядков — это не просто статистическая погрешность
  • Кинетика больших кластеров
    0
    Модель хорошая, но боюсь, что из вашей статьи могут сделать неверные выводы. Особенно режет глаза цифра в 100'000'000 лет для кластера в 1000 нод.

    Люди могут прочитать, и пойти деплоить кластеры Hadoop на 1000 нод с r=3 и думать, что они могут спать спокойно. Но, например, при выпадении ToR свича вы потеряете сразу всю стойку. Та же HDFS хранит r=3, но при этом 2 копии по умолчанию приземляются на одну стойку, значит при выпадении стойки приблизительно треть хранимых ей блоков оказывается в единственном экземпляре. Треть полной стойки двухюнитовых серверов — это до 320'000'000 чанков, соответственно каждый из оставшихся в кластере дисков будет в среднем хранить 27'210 чанков, у которых осталась одна последняя живая реплика. Если у сети нет oversubscription, то дореплицироваться эти чанки в идеальном случае будут: 27210 чанков * 1MB / 50 MB/sec ~= 9 минут. Плюс время на обнаружение проблемы. Плюс заметим, что в используемой у вас LRC-8-2-2 нужно еще и контрольные чанки пересчитать, то есть при восстановлении вам придется прочитать раз в 6 больше данных, то есть мы уже говорим о почти часе на абсолютно пустом кластере. Плюс в критический момент оказывается, что Hadoop сам не инициирует восстановление коэффициента репликации, и делать это нужно ручками на уровне файлов или директорий. А во время восстановления кластера выпадение еще одного любого диска — это недоступность данных.

    Поэтому я склонен считать что ваши рассуждения, к сожалению, тоже не верны. Автор критикуемой вами статьи не учитывает динамику. Вы учитываете динамику, но не учитываете другие возможные причины отказа — проблемы сетевого оборудования, проблемы питания, возвращение нодами некорректных данных, ошибки памяти, человеческий фактор и т.д. Не учитываете также то, что «динамика» — вещь относительная, и для вашего кластера и кластера Hadoop динамика восстановления будет отнюдь не одинаковая. Добавление же всех этих факторов в модель сделает её настолько сложной, что практическая польза от нее будет весьма спорной. Но на бумаге выглядит хорошо.
  • Кинетика больших кластеров
    0
    Я закладывал 1 день на замену. Даже если все будет работать идеально, системе все равно потребуется время на восстановление потерянных чанков, и в зависимости от нагрузки на кластере это время может быть довольно значительным, полчаса-час. Но как я сказал, я не учитывал множество других факторов. Например, Яндекс в силу объемов данных наверняка использует commodity диски, у которых ARR около 4-5%. Плюс диск не всегда отказывает и исчезает, иногда он начинает просто отдавать битые данные. Диск в наличии, а данные на нем неправильные, на диагностику такой проблемы тоже нужно время.

    Вы работаете с реальными кластерами подобных размеров, и сами используете LRC-8-2-2 (то есть можно потерять до 2 реплик из группы без потери данных) — какая у вас статистика по потерям чанков? Неужели действительно ни одной потери? Как следует из вашей формулы с 100 000 000 лет, даже вы имея 100 кластеров в течении 10 лет, получите вероятность отказа вероятность отказа всего 0.001%
  • Кинетика больших кластеров
    +1
    Дано:
    3-кратная репликация, размер чанка 1 Мб, 4 ТБ диски, 1000 серверов в кластере, каждый сервер с 12 дисками, ARR для диска составляет 1%, 1 день на замену сломавшегося диска.

    Расчет:
    • 1000 серверов, каждый с 12 дисками, итого в кластере 12'000 дисков. Отдельные диски вмещают до 4 ТБ / 1 МБ = 4'000'000 чанков.
      Когда один диск ломается, 4'000'000 его чанков становятся недоступными. Каждый из оставшихся в кластере дисков будет содержать приблизительно 4'000'000 / 12'000 = 333 чанка данных, хранившихся на сломанном диске. Это означает, что любые 2 отказавших диска в кластере приведут к тому, что 333 чанка в кластере останутся с единственной репликой. Эти 333 чанка должны лежать на разных дисках. Итого, когда любые 2 жестких диска в кластере одновременно выходят из строя, отказ любого из 333 жестких дисков, содержащих последнюю реплику наших данных, приведет к потере данных.
    • 12000 дисков в кластере и ARR 1%, дает нам 12000 * 1% = 120 отказов жестких дисков в год. Если замена происходит в течение 1 дня, то когда один жесткий диск вышел из строя, вероятность того, что сломается еще один, равна 11999 * 1% * 1/365 ~= 33%. Поскольку у нас 120 сломанных дисков в год, каждый из которых требует ремонта в течение 1 дня, примерно 120 * 33% ~= 39,5 дней в году, мы будем работать в кластере с двумя отказавшими дисками.
    • В кластере с двумя отказавшими дисками мы зависим от 333 других дисков, содержащих последнюю живую реплику данных. Какова вероятность того, что один из них откажет? 333 диска * 1% ARR * 39,5 дней в году без 2 дисков / 365 = 36%, в год. Таким образом, примерно раз в три года вы потеряете один чанк своих данных. Для многих приложений недоступность одного чанка — это уже проблема.

    Так или иначе, это никак не 100'000'000 лет. Теперь добавим сверху падения других компонент кроме дисков, проблемы с сетью, перезагрузки серверов (накатываем обновления, например), когда часть чанков тоже становится недоступна, время на обнаружение проблемы с диском и восстановление данных, и т.д. Итоговая цифра намного больше соотносится с реальностью, чем ваши вычисления. Уж вы-то в Яндексе должны знать на основании своего опыта, что для кластера с 1000 машин и 3-кратной репликацией потеря данных будет происходить раз в год или чаще.
  • Архитектура поиска в Booking.com
    +3
    Коллега, есть такое понятие как «tail latency». Нельзя судить о времени отклика нагруженного сервиса только по среднему, зачастую та же 95-я и 99-я перцентили намного важнее.
  • Как мы проводим собеседования в Pivotal
    +3

    Интересный выбор статьи для перевода. Мне довелось поработать в Pivotal, и Элизабет была моим прямым руководителем какое-то время.


    Про интервью — все действительно так, но есть несколько но:


    1. Это онсайт-интервью. Перед ним проводится несколько телефонных интервью, где задачки уже ближе к алгоритмическим, и где производится основной отсев неподходящих кандидатов. Если вы попали на онсайт, то с вероятностью около 50% вас возьмут.
    2. Задача этого интервью — не только проверка навыков, но и оценка того, как хорошо вы вольетесь в коллектив, насколько приятно будет другим разработчикам с вами работать.

    По поводу траты времени — собеседования во все крупные компании занимают полный день. У Pivotal 2000+ сотрудников, и оценочная стоимость компании $2b+, то есть они могут себе позволить подобные интервью.


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

  • Очереди и блокировки. Теория и практика
    0
    Я утрировал. СУБД обычно не используются для организации очередей. Скорее СУБД можно использовать для регистрации событий исходной системы, для последующей их пакетной обработки (и, соответственно, хранения истории). Писатели и так не блокируют друг друга (параллельные insert уже давно исполняются СУБД без блокировки), а читателей при пакетной обработке не много и не нужно дикости вроде полной блокировки таблицы, как в примере автора. Для классического кейса с большим количеством параллельных читателей для распределения нагрузки, СУБД будет работать плохо

    Что хорошо в очередях, и из-за чего появилось много решений для организации очередей — им не нужна полноценная ACID. А по поводу произвольной выборки — та же Kafka умеет читать из произвольного места в очереди.
  • Очереди и блокировки. Теория и практика
    0
    Плакал, читая вашу статью:
    Нам понадобилась очередь, и мы решили использовать для ее организации СУБД. А там блокировки, да и хранит данные она на диске, непорядок! Решили использовать модный распределенный ObjectStore для организации очереди, он работает побыстрее, но все равно оверхед большой и управлять им сложно, не то. Затем для реализации очереди мы решили использовать распределенный in-memory key-value store (а почему бы и нет?). Затем не распределенный in-memory key-value store. Затем мы решили все-таки попробовать продукты, реализующие функционал очередей, но что-то у них настройка больно мудреная, и мы не осилили

    Это же основы. ПО для организации очередей писалось не дураками, и писалось именно потому, что другие инструменты конкретно для задачи организации очередей подходят плохо. ActiveMQ, ZeroMQ, RabbitMQ, Kafka и многие другие — создавались именно для того, чтобы снизить оверхед на операции с очередями, гарантировать сохранность данных и их последующую обработку. По определению никакие СУБД, key-value store, object store и прочие не будут решать эту задачу лучше, за исключением ситуации, когда у вас одно сообщение в секунду и вам не важно, будет ли оно в итоге обработано или потеряно.
  • PostgreSQL 9.6: Параллелизация последовательного чтения
    +2
    Это приятное дополнение к функциональности Postgres, но использовать его нужно с умом. Если на машине с Postgres подсистема ввода-вывода является узким местом, то параллельное сканирование может только усугубить картину, ухудшив общую производительность системы.

    К тому же, параллельное сканирование — это движение в сторону OLAP, и тут стоит вспомнить, что на одной машине совмещать OLAP и OLTP далеко не лучшее решение, т.к. несколько параллельных запросов аналитиков в 8 воркеров каждый создадут такую нагрузку на IO, что с SLA транзакционной части придется попрощаться
  • Big Data головного мозга
    +1
    — Нет, я так не говорю. Количество записей на диск не зависит от количества трансормаций, оно зависит от количества shuffle. Каждый раз, когда Spark производит shuffle, все данные приземляются на диск. У вас может быть одна трансформация join, которая будет исполнена в виде reduce-side join, и оба участвующих RDD будут перераспределены (shuffle) по кластеру перед join'ом. А может быть трансформация «filter», которая всегда пайплайнится с другими трансформациями, и соответственно никакого приземления данных на диск не будет
    — Нет, такого варианта нет. Данные во время shuffle всегда приземляются на диск. По-другому асинхронное выполнение тасков работать и не может
  • Big Data головного мозга
    +1
    Советую вам ориентироваться не на презентации, а на код

    Вот оригинальный комментарий из кода менеджера shuffle в Spark:
    /**
     * In sort-based shuffle, incoming records are sorted according to their target partition ids, then
     * written to a single map output file. Reducers fetch contiguous regions of this file in order to
     * read their portion of the map output. In cases where the map output data is too large to fit in
     * memory, sorted subsets of the output can are spilled to disk and those on-disk files are merged
     * to produce the final output file.
     */
    

    Если по коду, то здесь происходит запись на диск, которая вызывается отсюда, в свою очередь вызывается отсюда, объявляется здесь и вызывается тут. Это наиболее актуальная имплементация, т.н. Tungsten, а вот более старая

    Как я и говорил, специалистов, способные разделять реальность и маркетинг, не так уж много.

    И да, в презентации говорится про «storage»: они имеют в виду возможность Spark кэшировать данные, а не то, что во время shuffle он не сбрасывает данные на диск
  • Big Data головного мозга
    +1
    Apache HAWQ интегрирован с YARN, то есть глобальный менеджер ресурсов в кластере будет и HAWQ не сможет забрать себе всё. Но нужно понимать, что YARN управляет только квотами на память и CPU, то есть IO может стать узким местом. Еще стоит учесть, что совмещать на одном кластере аналитические и транзакционные системы — моветон. То есть HAWQ + Sqoop + Flume + Spark будут вместе жить нормально, а вот HAWQ + HBase — уже не очень
  • Big Data головного мозга
    0
    К сожалению, таких данных у меня нет. Но ожидаемо, что запросы к Hive-таблицам будут медленнее. Нативные таблицы парсятся кодом HAWQ (написанным на C), а для обращения к Hive таблицам нужно поднимать Java-десериализаторы, соответствующие формату хранения, что довольно долго.

    Но Apache HAWQ — это open source, и вы свободно можете протестировать его и самостоятельно увидеть разницу в производительности
  • Big Data головного мозга
    0
    Не согласен с вами касательно MPP. Основная идея MPP как раз в том, что она массивно-параллельная, то есть много процессов параллельно выполняют одну и ту же задачу над разными данными. MapReduce и подобные подходы не являются MPP, т.к. в этих системах нет гарантии параллельного выполнения задач, это системы пакетной обработки данных. По сути это «data parallelism» против «task parallelism» — первый параллельно обрабатывает одни и те же данные набором процессоров, а второй разбивает задачу на независимые «таски» и назначает их свободным процессорам по мере их доступности и глобальных приоритетов

    Про Kudu — да, прочитайте их публикацию

    Лично я считаю, что популярность Hadoop обусловлена потребностью рынка и маркетингом. А когда начинается использование Hadoop, все «корпоративные» клиенты хотят иметь к нему SQL-интерфейс, при этом быстрый и с транзакциями — вот и потребность
  • Big Data головного мозга
    +1
    HAWQ 2.0 нативно поддерживает чтение таблиц, объявленных в Hive Metastore, без плясок с бубном вроде внешних таблиц. А скоро будет поддерживать и их создание
    Да, вы правы, GPDB уже умеет многое. В то же время HAWQ работает поверх Hadoop и интегрируется с YARN, что позволяет ему более удачно вписаться в Hadoop-кластер, а вот GPDB требует для своей работы отдельный кластер и немного другую организацию дисков
  • Big Data головного мозга
    0
    На официальном сайте есть этому объяснение: https://www.mongodb.com/big-data-explained
    Вся эта статья про аналитические системы, а MongoDB — это т.н. «operational» система. Обычно она всплывает в контексте обсуждения Cassandra, HBase и подобных систем этого класса
  • Big Data головного мозга
    +4
    Хорошая статья, спасибо! Приятно, что есть еще специалисты, способные разделять реальность и маркетинг

    В целом направление мысли верное, но есть некоторые фактические ошибки:
    • если, например, маперы уже прекратили свою работу, то ресурсы редьюсерам уже не освободятся — на самом деле освободятся. Даже если у вас YARN настроен на возможность выполнения только одного таска единовременно (один маппер или один редюсер), вы сможете выполнить задачу в 1000 мапперов и столько же редюсеров. Конечно, работать они при этом будут последовательно
    • Spark не понимает, как данные лежат в HDFS. Это хоть и MPP-система — Spark не MPP, это тот же Batch Processing, что и MapReduce. Задача обработки данных разбивается на таски и они выполняются асинхронно, промежуточные данные сбрасываются на диск
    • Spark Streaming и, возможно, это будет действительно таким «долгоиграющим» решением — Как раз у Spark Streaming наиболее сильные конкуренты — Apache Storm, Apache Heron, Apache Flink, да и та же Kafka c Kafka Streams. Конкурировать micro-batch подходу Spark Streaming с «честным» streaming в вышеназванных системах будет очень проблематично
    • Impala, Drill и Kudu… это такие же МРР-движки поверх HDFS как Spark и MR — Kudu не имеет зависимости от HDFS, это как раз более быстрая замена HDFS для обработки табличных данных с поддержкой update (в отличии от HDFS). И, конечно, она не имеет отношения к MPP
    • Apache HAWQ… они взяли традиционный Greenplum и натянули его на HDFS… какой-то практической целесообразности в этом мало. — по сути это ответ рынку. MPP over Hadoop востребована (посмотрите на те же Hive и Impala), вот Pivotal и выпустил этот продукт. К слову сказать, среди решений его класса он является наиболее быстрым и продвинутым в плане поддержки SQL, но как и любое связанное с Hadoop решение является сложным в сопровождении
    • Появятся первые дистрибутивы CDH уже с частичным отказом от использования HDFS — уже появились, ведь Kudu — это не HDFS


    Greenpum сделает свой аналог Flex Zone, путем слияния кода с HAWQ, либо сам станет non-HDFS частью HAWQ, в конце концов, кого-то мы потеряем — на самом деле я поднимал этот вопрос перед руководством практически сразу после форка HAWQ от GPDB, но такой цели нет. Сейчас же их ветки ушли чересчур далеко друг от друга и я не вижу возможности их слияния в будущем. Скорее GPDB расширит функционал для нативной поддержки HDFS таблиц, да и только.

    В свое время я тоже писал и про Kudu, и про неструктурированные данные, и про перспективы Big Data, и про перспективы Spark. В целом же я рекомендую вам писать статьи на английском — это даст охват аудитории в 10 раз выше и возможность дискуссии с интересными специалистами (как, например, мой спор с одним из создателей Spark в комментариях к этой статье)
  • Яндекс открывает ClickHouse
    +8
    Что примечательно, практически вся СУБД была создана одним человеком
    В целом же молодцы, что открыли исходники! Очень интересно посмотреть, как оно работает изнутри
  • Docker на службе команды .NET-разработчиков
    0
    Правильное направление — признание лидерства Linux в области серверных ОС и работа в сторону лучшей с ним интеграции (нативный запуск Linux-приложений в Windows, версия MSSQL для Linux, портирование Docker и Hadoop, и т.д.)

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

    Мобильные ОС (смартфоны) — пример рынка, на который MS также опоздала, и так и не сумела выйти в лидеры
  • Docker на службе команды .NET-разработчиков
    –2
    Intel: 107'300, Red Hat: 8'300, Samsung: 307'000, Google: 57'100, IBM: 377'757, TI: 31'003 — мне продолжать по остальным 1294 компаниям?

    К тому же из 118,584 человек в Microsoft только 43,860 инженеры. Из них, например, над Windows 7 работали 2'000 разработчиков. По другой информации всего над Windows работает около 5'000 человек

    Лично я считаю, что Microsoft движется в правильном направлении, но они сильно опоздали на этот рынок. Я профессионально занимаюсь кластерными системами, и по моему опыту серверные инсталляции Windows популярны только в Израиле (из всего региона EMEA). Так же, например, Microsoft опоздали на рынок мобильных ОС
  • Docker на службе команды .NET-разработчиков
    –4
    Пока ядро Windows проприетарно, добиться успеха в области серверных приложений у них не получится. Кто делает вклад в ядро Linux: Intel, Red Hat, Samsung, IBM, SUSE, Texas Instruments, Google, всего более 1200 компаний. Кто делает вклад в ядро Windows: Microsoft. У них просто нет такого количества квалифицированных ресурсов, чтобы конкурировать с таким большим open source сообществом
  • Docker на службе команды .NET-разработчиков
    +1
    Сообщество Linux в течении более чем 10 лет разрабатывало функционал ядра Linux для поддержки приложений вроде LXC и Docker — это и cgroups для контроля потребления ресурсов, и различные namespace для изоляции процессов, и различные union fs вроде aufs для поддержки файловой системы контейнера, и виртуальные сетевые адаптеры. Это всё в ядре Linux, и что-то уже очень давно.

    Похоже, Microsoft желает сделать то же самое за год-другой. Конечно, ни о каком запуске контейнеров Linux в Windows речи не идет — для этого Windows должен поддерживать чересчур много системных вызовов Linux, от чего они пока весьма далеко. Но прогресс идет в этом направлении, что весьма интересно — сначала Linux пытался догнать Windows, улучшая GUI и борясь за десктопных пользователей, а теперь Microsoft эмулирует системные вызовы Linux и портирует функционал их ядра, борясь за серверных пользователей.
  • Сравнение производительности Hadoop на DAS и Isilon
    0
    Несколько замечаний:
    1. В DAS-кластере 6 рабочих узлов по 8 дисков каждая — итого 48 дисков
      В Isilon-кластере 4 узла x410 по 30 дисков в каждом минимум — итого 120 дисков + SSD
      Серьезно ли сравнивать производительность файловых систем кластеров в такой конфигурации?
    2. Не указана конфигурация дисковой подсистемы для DAS-узлов, т.е. непонятно, сколько из 8 дисков на сервер реально используется для обработки данных. Может быть 2 диска собраны в RAID1 и отданы OS, а под данные используются только 6 дисков на ноду? От этого сильно зависят результаты
    3. Не указан объем данных, на котором тестировался NFS, и количество передаваемых файлов. У Isilon 3.2TB SSD-дисков. В вашем тесте NFS-запись на него длится около 35 секунд. Если до Isilon проброшено 4 кабеля по 10GbE, то их суммарная производительность будет 40 Gbit/sec или 5GB/sec. За 35 секунд через такой канал можно передать 175GB данных, что заведомо меньше объема доступных SSD, то есть данные по большей части лягут на быстрые SSD. Если кабелей 8 картина не меняется — будет 350GB переданных данных
    4. Для terasort не указали объем данных, на котором тестировались, и количество файлов. Результат Teragen на Isilon — 600 секунд. Используя расчеты из п.2, у меня получается что объем данных был около 3TB, что опять же меньше объема SSD, доступного у Isilon.

    Итого по teragen и terasort, имея в 3 раза больше дисков в Isilon, производительность по сравнению с DAS-кластером выше в 2.6 и 1.5 раза соответственно. Честно говоря, это не удивительно, но все же хотелось бы, чтобы сравнивали яблоки с яблоками

    В целом, Isilon — штука довольно интересная и реально используемая многими крупными компаниями, имеющая свои преимущества для enterprise-заказчиков. Но все же это не повод к публикации подобных спорных бенчмарков
  • IBM Watson помогает ВВС США автоматизировать процесс госзакупок
    0
    Компаний довольно много, и для примера приведем 8 организаций, изменившихся к лучшему благодаря когнитивной системе
    Самого примера так почему-то и не последовало. Не до конца перевели статью?
  • Визуализация инструментов обработки данных с Github
    +4
    Полностью согласен, это было бы очень здорово. Если решите такую сделать, поделитесь ссылкой
  • BDRA – современная архитектура для аналитики больших данных
    +2
    На самом деле попыток запускать Hadoop поверх СХД предпринималось уже довольно много, практически все вендоры СХД имеют своё решение для этого. В пику этому по сети гуляет множество статей вроде Never, ever do this to Hadoop, осуждающих такой дизайн. Даже я как-то написал одну.

    На самом деле тут все довольно просто. Подобные системы имеют смысл только при сильном дизбалансе требований к объему хранимых данных и вычислительной мощности. Например, большой кластер Apache Spark для обработки пары десятков терабайт данных в MLlib, или же хранение нескольких петабайт данных и периодические запросы к ним в Hive.

    Рациональная же составляющая тут следующая — не верьте маркетингу. Если у вас есть N процессоров и M жестких дисков, то добавив между ними сеть вы никак не получите +30% в производительности чтения (да и откуда, жестких дисков-то ровно столько же). Затем, при использовании приведенной архитектуры нужно не забывать про стоимость лицензий на софт, поставляемый HPE (те же СХД — это не просто кучка железа, это проприетарный софт на них). Масштабировать такой кластер в будущем можно будет только компонентами HP, то есть вендор lock-in гарантирован. К тому же требования к сети у таких решений по сравнению с традиционными кластерами Hadoop сильно выше — если на текущий момент множество кластеров Hadoop спокойно живет с 1GbE ввиду парадигмы вычислений MR, то тут без 10GbE не обойтись, а желательно еще и по нескольку кабелей к каждой из нод подвести (20 LFF дисков на вычислительную ноду смогут отдать ей около 1200MB/sec, а это уже больше возможностей одного 10GbE порта).

    Как показывает практика, чаще всего подобные системы внедряются крупными банками и подобными им корпорациями, в которых нет своей экспертизы по Hadoop, но которые хотят показать всему миру что "мы тоже умеем Hadoop". Зачастую внедренные таким образом системы либо практически не используются, либо заменяются нормальными кластерами с ростом нагрузки на них и экспертизы на стороне заказчика.
  • 0 марта. Сеймур Пейперт и обучение программированию через тело (и бессознательное)
    +1
    Если у нас две шестеренки по 50 зубцов в каждой, то как возможно, чтобы за один оборот вокруг зафиксированной шестеренки движущаяся совершила два оборота? Ведь она пройдет ровно 50 зубцов зафиксированной шестеренки, и завершит оборот ровно на том зубце, с которого начинала. Разве не так?
  • Рекурсия. Занимательные задачки
    +1
    Задача D — можно ограничиться целыми числами:
    Решение
    def ispow2(num):
        if num == 1:
            return True
        if num % 2 == 1:
            return False
        return ispow2(num/2)
    
    print ispow2(1024)
    



    H — самая очевидная оптимизация — это проверять делимость не до N/2, а до sqrt(N), сложность уже будет O(sqrt(N)). Есть еще вот такой вариант: en.wikipedia.org/wiki/AKS_primality_test, а вообще это сложная проблема: www.math.uni-bonn.de/people/saxena/talks/May2007-Turku.pdf
    Задача K
    вместо:
                // Шаг рекурсии / рекурсивное условие
                if (n % 2 == 1) {
                    System.out.println(n);
                    recursion();
                } else {
                    recursion();
                }
    

    написать:
                // Шаг рекурсии / рекурсивное условие
                if (n % 2 == 1) {
                    System.out.println(n);
                }
                recursion();
    


    Задача S — вот оба варианта, реализованные на Python. Рекурсивный начинает тормозить уже при вычислении суммы для 9 символов, а вариант с меморизацией выводит результат и для 50 символов за миллисекунды:
    Задача S
    # Recursive version
    def findrec(target, length):
        res = 0
        if length == 1 and target < 10:
            res = 1
        elif length > 1:
            for i in range(min(10,target)):
                res += findrec(target-i, length-1)
        return res
    
    # Memorization version
    def findmem(target, length, mem):
        if mem[target][length] > -1:
            return mem[target][length]
        res = 0
        if length == 1 and target < 10:
            res = 1
        elif length > 1:
            for i in range(min(10,target)):
                r = findmem(target-i, length-1, mem)
                mem[target-i][length-1] = r
                res += r
        return res
    
    def find(target, length):
        mem = [[-1]*(length+1) for _ in range(target+1)]
        return findmem(target, length, mem)
    

  • Рекурсия. Занимательные задачки
    +2
    A: От 1 до n — склеивать числа в строку крайне неэффективно, почему бы их прямо из функции не печатать?
    B: От A до B — аналогично
    D: Точная степень двойки — решение через числа с плавающей точкой просто режет глаза, неужели нельзя было просто делить пополам и проверять остаток от деления?
    H: Проверка числа на простоту — в условии решение должно быть за O(logN), ваше же решение O(N) по вычислениям и O(N) по памяти засчет стека рекурсии
    I: Разложение на множители — FYI, даже решето Эратосфена не дает O(logN). Ваше решение O(N) по вычислениям и O(N) по памяти
    K: Вывести нечетные числа последовательности — пример вообще дикий, при этом зачем-то два рекурсивных вызова вместо одного
    S: Заданная сумма цифр — тут хорошо добавить условия ранней остановки рекурсии (sum > s) и меморизацию по (len,sum) чтобы тысячи раз не считать одно и то же
    U: Разворот числа — как уже заметили, решение с логарифмами и степенями весьма дико. Код будет такой:
    def rev(num,tmp):
        res = tmp*10 + num%10
        if num > 10:
            res = rev(num/10, res)
        return res
    
    print rev(123456789,0)
    

    Хорошие задачи на рекурсию:
    Задача на BFS/DFS — http://www.careercup.com/question?id=4716965625069568
    Задача на аналог qsort — найдите k-ое по величине число в заданной последовательности
  • IBM продолжает работу с Apache Spark: корпорация запускает Spark-as-a-service
    +4
    Печально. Похоже, что инвестиция в $300m делается не в Apache Spark как таковой, а в интеграцию Apache Spark с проприетарными продуктами IBM и портирование решений IBM на платформу Apache Spark. Переписать 40 миллионов строк DataWorks — не проблема, а вот сделать достаточный вклад в Apache Spark (около 400к строк кода всего), чтобы у IBM появился хоть один коммитер — уже намного сложнее.

    В целом же статья чисто маркетинговая, порадовали «распознавание естественных языков» (имелось в виду наверное NLP?), «технологию обработки изображений» (а вот тут уже нужно «распознавание», плюс такой технологии нет в Spark), «компания считает свой инструмент весьма надежным» (ага, свой).
  • Деанонимизация программиста возможна не только через исходный код, но и через скомпилированный бинарный файл
    +1
    Даже не так — нужна большая база кода, в которой разные программисты решали одну и ту же задачу, в противном случае их решение работать не будет
    Плюс тут еще много тонкостей — в GCJ почти у всех участников есть свои «шаблоны» решений, в которых для ответа на поставленную задачу чаще всего достаточно дописать только одну функцию. Отсюда и такое качество классификации, т.к. шаблоны чаще всего индивидуальны
  • Эволюция структур данных в Яндекс.Метрике
    0
    Спасибо за развернутый ответ.
    Я знаком с архитектурами современных MPP решений. Поэтому и интересно узнать вашу архитектуру, т.к. если ваше собственное решение, написанное за 2 года, обгоняет коммерческий продукт c 10-летней историей, спроектированный небезызвестным Стоунбрейкером, у вас однозначно должны быть какие-то ноу-хау в плане компрессии, обработки сжатых данных, индексов/bloom filters и т.д.
  • Apache Spark в «боевых» проектах — опыт выживания
    0
    Вопрос скорее в том, что некоторые вещи позволительно сказать при живом выступлении — ошибиться в ряде терминов, назвать что-то неправильно и т.д. Это допускается, так как выступление — это зачастую импровизация. Но когда вы пишете статью ожидается, что вы проверите приведенные факты и высказывания перед публикацией, ведь в отличии от живого выступления времени на это у вас достаточно
  • Apache Spark в «боевых» проектах — опыт выживания
    +3
    Местами статью больно читать:
    дифференциальные вычисления, линейную алгебру, теорию вероятности, машинное обучение, графы и обучение на них, логистическую регрессию, линейный дискриминантный анализ и так далее
    Смесь из разделов математики и конкретных алгоритмов, непонятно как взаимосвязанных. К тому же дифференциальные вычисления никаким боком к большим объемам данных не относятся. Так же как и обозначенные алгоритмы — это то, что можно делать с данными (не обязательно большими), но чтобы работать с большими данными знать это сосвем не обязательно

    Но вдруг, перед релизом, или когда данных окажется больше, чем вы ожидали, вы обнаружите, что этот алгоритм не работает в «параллельном режиме», не работает через MapReduce — им можно загрузить только одно ядро процессора. Поэтому вам нужно будет экстренно и заново изобрести еще один алгоритм, который умеет работать параллельно, и придумать, как он должен работать в парадигме MapReduce.
    Вы это серьезно, переделывать алгоритм для работы на кластере нужно обязательно непосредственно перед релизом? Может для начала при выборе алгоритма стоит проверить, как он работает на кластере из виртуалок? Или хотя бы в локальном режиме MapReduce?

    Spark — берет, выполняет все задания, а затем выгружает результат
    При этом на каждом shuffle бережно складывая данные на жесткий диск и затем вычитывая их

    Можно кинуть в ответ Apache Tez или отыскать что-нибудь мелкое в зоопарке Apache — но, поверьте, для снижения рисков лучше использовать mainstream-технологии, которые развиваются в ногу с рынком.
    Apache Tez — это mainstream для Apache Hive. Никто в своем уме сейчас не использует Apache Hive поверх MapReduce: либо Hive+Tez, либо Impala или аналог

    Полученные результаты мы выгружаем в Apache Mahout и на выходе получаем конкретные рекомендации для клиента
    Зачем вам Apache Mahout и чем не понравился Spark MLlib? К слову сказать, Apache Mahout мертв чуть более чем 3 года

    Deep learning — это, простыми словами, «качественное» машинное обучение, подразумевающее очень детальное изучение проблемы машиной и, часто, использование многослойной рекуррентной нейронной сети
    Deep не имеет отношения к качеству и детальности проработки, а означает «глубину» (количество слоев) обучаемой сети

    Также, все более активно используются HBase, Casandra, Mahout, Spark MLLib
    Как я уже написал выше, Mahout мертв и имеет скорее отрицательную динамику использования. Также странно видеть в одном ряду два Key-Value хранилища и подпроект Spark для машинного обучения

    DAG (directed acyclic graph) vs Hadoop MapReduce vs Hadoop Streaming.
    DAG — абстракция уровня исполнения задачи в Spark, Hadoop MapReduce — фреймворк для обработки данных на кластере, Hadoop Streaming — дефолтный job MapReduce, который передает данные в виде текста стороннему приложению и получает от него результат. Как они могут быть в одном списке?

    Streaming реализован в Spark гораздо лучше, чем в Hadoop, им гораздо удобнее пользоваться и работает часто эффективнее, за счет кэширования данных в памяти.
    Как уже писали выше, MapReduce Streaming и Spark Streaming — вещи абсолютно разные

    Удобные коллекции: filter, map, flatMap
    Постойте, filter — это коллекция, вы уверены?

    Master-машины, которые контролируют вообще весь кластер. На них установлен Spark Master
    Такой вещи как Spark Master нет. Spark Master — это просто jar'ник Apache Spark, стартовавший с определенными параметрами. Это штука динамическая и зависит от того, в каком режиме вы запускаете Spark

    Core-машины, на которых развернута файловая система — HDFS. Их может быть несколько штук. Правда, рекомендуется только увеличивать количество core-машин, а не уменьшать, иначе теряются данные.
    Вы это серьезно? Слышали ли вы о таких вещах, как HDFS Node Decommission, HDFS Balancer, replication factor?

    Для всего остального используются task-машины. Это обычные Spark-серверы, на которых работают воркеры
    Вот это — sparc-серверы, а то, о чем вы пишете, это просто ноды вашего кластера, предназначенные для запуска процессов Spark

    В Yarn-кластерах, как и в Oracle, используется множество настроек, и, по хорошему, нужен админ, который в этом очень хорошо разбирается
    Да, для работы с кластером Hadoop нужны определенные знания. Но если вы пишете статью, то как бы подразумевается, что вы этими знаниями обладаете

    Что такое Reduce? Когда в один worker собираются сгруппированные по одному ключу данные
    В один worker… Коллеги, вы видели когда-нибудь настройку mapreduce.job.reduces? Один — это значение по умолчанию, их может быть сколько угодно. В Apache Spark же это задается дефолтным уровнем паралелизма и количеством партиций в целевом RDD (практически все трансформации принимают как параметр количество партиций в целевом RDD). При этом значение по умолчанию — не 1, а количество партиций в исходном RDD

    Допустим, вам нужно выгрузить из Spark данные в модель. Если объем велик, то это будет выполняться очень долго
    А сохранить в ту же HDFS и вычитать оттуда? А записать через тот же JdbcRDD в любимый MySQL?
  • Эволюция структур данных в Яндекс.Метрике
    +3
    Было бы интересно прочитать побольше о архитектуре ClickHouse, а также за счет чего и на каких тестах она работает в 2,8-3,4 раза быстрее HP Vertica
  • Apache Spark как ядро проекта. Часть 1
    0
    Плюс примера с Python в том, что он интерактивный, то есть вы просто поднимаете процесс PySpark и контекст уже создан для вас. Если вас интересует вариант с поднятием кластера, можно сделать, допустим, так:
    pyspark --master yarn-client --num-executors 6 --executor-memory 4g --executor-cores 12
    

    Запуск через spark-submit хорошо описан в официальной документации, нужно просто вместо jar-файла передать py-скрипт