• Разумный женский календарь: как делают приложение № 1 в категории «Здоровье и фитнес»
    0

    Можно, но ведь мой вопрос был не про то, как можно использовать такие данные, а про то, какие компании готовы работать с ними в обход закона (например, купив данные на чёрном рынке). Вы можете представить, что какой-нибудь условный Johnson & Johnson приходит к какому-нибудь условному DoubleClick и просит запустить рекламу по данным купленным у неофициальных источников? Любая адекватная компания постарается не подходить к таким сделкам ближе чем на 12 адвокатов. Всё, что касается медицинской и околомедицинской тематики, строго регулируется, там даже при благих намерениях можно попасть на миллиардные штрафы, так что уж говорить про очевидный фрод.


    В то же время, есть масса простых, дешёвых и абсолютно законных способов узнать, например, о том, что девушка беременна: поисковые запросы, сайты с товарами для беременных, информационные сайты той же тематики и т.д. Да что уж говорить, я знаю научные статьи о том, как по 3м лайкам в Fb можно узнать политические взгляды и сексуальную ориентацию человека. Так зачем в таких условиях ввязываться в грязные сделки, если вся нужная информация и так элементарно вычисляется по доступным для адвертайзера данным?

  • Разумный женский календарь: как делают приложение № 1 в категории «Здоровье и фитнес»
    0

    А вы много знаете компаний, производящих товары для беременных и готовых работать с чёрным рынком? :)

  • Как решить 90% задач NLP: пошаговое руководство по обработке естественного языка
    +1

    Не всё в статье правильно и объективно, есть явный перекос в сторону определённых задач и соответсвующих инструментов.


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

    Во-первых, обычно у нас либо есть задача обучения с учителем (например, сентиментный анализ), либо без учителя (например, сравнение текстов по похожести). В задаче с учителем разметка данных нужна так или иначе: нельзя научить алгоритм отделять положительные твиты от отрицательных, если мы ему предварительно не рассказали, что такое положительный и отрицательный.


    Во-вторых, размечать данные дорого и долго. Хорошо, если у вас открытые данные, а принцип разметки легко объяснить — в этом случае можно закинуть данные в Amazon MTurk или Яндекс Толоку и просто подождать пару дней. А вот если данные выгружать в сторонние системы нельзя, или разметка требует определённой экспертизы, создание набора данных может стать просто адски долгим.


    Далее следует чеклист, который используется при очистке наших данных

    Здесь чувствуется явный перекос в сторону классификации с bag of words представлением на небольшом объёме данных. Если вы хотите разбирать структуру предложений или искать упоминания (dependency parsing & coreference resolution), находить именованные сущности (named entity recognition), переводить или генерировать текст, или даже просто использовать модели на основе рекуррентных или свёрточных сетей, то многие пункты из этого списка могут сделать данные только хуже. Например, попробуйте по словам только в нижнем регистре определить, является ли "cure" упоминанием лекарства или группы "The Cure".


    Дальше по тексту смешиваются понятия one-hot encoding (в переводе), bag of words и embeddings, хотя embeddings — это как раз встраивание из пространства с одним измерением на слово в пространство с меньшей размерностью с плотным непрерывным представлением.


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

    Во-первых, очевидно, что логистическая регрессия покрывает только классификацию на 2 класса. Что делать, если классов больше, автор не рассказывает. Можно было бы додумать статью и вспомнить про софтмакс регрессию, но интерпретировать её коэффициенты уже сложнее.


    Во-вторых, даже если у вас очень хорошие данные, и логистическая регрессия выдала в первой десятке максимальных коэффициентов действительно релевантные слова, то остальные 19990 слов вы всё равно не просматриваете. Поэтому аргумент про интерпретируемость для меня выглядит довольно странным.


    Данный интерпретатор, работающий по принципу черного ящика, позволяет пользователям объяснять решения любого классификатора на одном конкретном примере при помощи изменения ввода (в нашем случае — удаления слова из предложения) и наблюдения за тем, как изменяется предсказание.

    Что будет работать только на классификаторах, которые считают все слова независимыми. Если 2 слова зависимы, удаление одного может привести к непредсказуемым результатам (по-отдельности слова "так" и "себе" значат совсем не то же самое, что "так себе").


    [свёрточные сети] обычно гораздо быстрее обучаются, чем большинство сложных подходов NLP (например, LSTM-сети и архитектуры Encoder/Decoder )

    Откуда взялось сравнение свёрточных сетей и encoder/decoder архитектур, учитывая, что они решают разные задачи, и вообще encoder/decoder может включать в себя CNN, для меня загадка.

  • Про вероятности
    0

    Над самим по себе натуральным рядом не определена вероятность, так что распределением он не является. Хотя он учвствует в определении счётного множества, которое является основой для бесконечных дискретных распределений, это да.

  • Про вероятности
    +1

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

  • Про вероятности
    0

    Поправил, спасибо.

  • Про вероятности
    0

    Хм, согласен. Наверное, распределение Пуассона сюда тоже попадёт, хотя я его плохо знаю. Убрал "конечное", спасибо за пример.

  • Про вероятности
    0

    Всё верно, задача с небольшим подвохом, чтобы ответ совсем уж очевидным не был.

  • Про вероятности
    +2

    Если быть точным, то значения дискретной переменной могут принадлежать конечному (finite) либо счётному (countable) множеству. Счётное множество — это, например, множество всех возможных строк из символов таблицы ASCII. В теории для них тоже можно построить распределение вероятностей, свойства которого будут чем-то средним между свойствами непрерывного и конечного дискретного распределения. На практике мне ещё не приходилось работать с бесконечным набором признаков объекта, да и окунать читателя в детали теории множеств не особо хотелось. Поэтому, я надеюсь, вы простите мне эту маленьку ложь.


    (В статье, кстати, ещё много примеров маленькой лжи. Самая большая маленькая ложь, пожалуй, это определение вероятности, которую я сначала показываю на примере подсчёта встречаемости, потом обзываю функцией с шумом, а на самом деле это мера, да ещё и с несколькими возможными интерпретациями; а случайная переменная, соответсвенно, — это измеримая функция. Но последний раз, когда я пытался быть математически точным, люди начинали похрапывать минуте на 8й и выходили с полным отсутствием понимания).

  • Про вероятности
    0

    А ведь и правда, пропустил эту деталь. Добавил "нормально распределённая случайная переменная".


    Спасибо!

  • REST — это новый SOAP
    +1
    другой сервис, который синхронизирует пользователей себе локально, для чего обращается к нашему и если видит, что его уже нет, то удаляет и у себя, например.

    Так он удаляет у себя, а не на нашем сервере. К тому же, если он удаляет пользователя локально, значит для него это что-то вроде кеша и он может потом ещё раз сделать GET и всё восстановить.


    Я понимаю, что автор хотел показать разницу между транспортным и логическим уровнем, но в этом треде уже довольно много комментариев, но пока никто так и не привёл более или менее реального пример, когда описанная ситуация могла на самом деле случиться. Теоретически — это возможно, на практике — ситуация надуманная.


    Какой http-код вы возвращаете если вам нужно сказать клиенту, что транзакция длилась слишком долго и была отменена? [...] Всё верно, проблема только, что на все случаи кодов нет и особенно для более сложных api всё равно приходится что-то придумывать сверх того, что есть.

    Лично я бы использовал 422 (unprocessable entity), но если сомневаетесь, возвращайте 400 (bad request) и пояснение. Расспространённое заблуждение, что HTTP коды должны описывать все возможные ситуации и ошибки, но по сути это классы ошибок, а внутри ответа уже может быть указана точная причина. Это ничем не отличается, например, от классов исключительных ситуаций (скажем, OSError или LookupError в Python), которые покрывают сразу массу возможных причин, а точная проблема диагностируется по полям эксепшена.


    В заключении вы говорите о том, что автор привык к soap

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


    Но есть масса других доменов, где требования совершенно другие. От GitHub API мне не нужны все 250 эндпойнтов, я хочу просто доставать количество звёзд проекта. От StackOverflow мне не нужен полноценный клиент, мне достаточно уметь считывать текст вопроса и теги. С другой стороны, мне это надо делать из разных языков, в т.ч. тех, для которых нет *RPC клиента. И если я смогу для своего запроса использовать обычный, доступный везде HTTP с уже знакомой семантикой (знакомые "глаголы", коды, с которыми я уже работал и т.д.), то это, как ни крути, большой плюс.

  • REST — это новый SOAP
    0

    Нажали ссылку где? В письме GET запросом по URL без аутентификации в аккаунт?


    За свою жизнь я не видел ни одного ресурса, где аккаунт можно было бы удалить просто нажав кнопку. Обычно для этого нужно войти в свой аккаунт и в "опасной зоне" своего профиля нажать красную кнопку, а затем ещё и подтвердить паролем. И даже после этого аккаунт обычно помечается как "удалённый", но у пользователя есть N дней, чтобы отменить действие.


    И это не говоря уже о том, что игра могла не работать из-за десятка других причин — проблем сети, неудачного деплоя, бага, перегрузки сервера и т.д. И есть десяток способов защититься от этого — алертинг, автоматическое и ручное тестирование, мониторинг внешними инструментами. Но виноват, конечно, REST.

  • REST — это новый SOAP
    0

    Так вы пример такой ситуации-то приведите.

  • REST — это новый SOAP
    0
    Все locations работают, кроме одного. Но самого важного для пользователей

    Опять же, речь ведь идёт про внешний сервис, с UI, пользователями и всем таким? Значит пользователь не знает ни про какие locations, ему нужно войти в свой аккаунт, найти кнопку "delete my account" и нажать на неё. Но войти он не может, потому что 404.


    Автоматические программы могли бы знать про locations, но если такая программа делает DELETE /myobject после того как GET /myobject вернул 404 — это тоже, мягко говоря, странное поведение.


    А как они обрабатывали стандартные и полустандартные коды? Хотя бы 201, 204, 409, 422? Как обрабатывали 302 — постандарту или как браузеры?

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


    Остальные коды обрабатывались в соответствии с логикой, описанной в документации. Если какой-то код не описан в документации, то и обрабатывать его не надо.

  • REST — это новый SOAP
    +7

    Эээ, так а о чём тогда статья?


    Я, в основном, реагировал на конкретные фразы в статье, которые у меня вызвали недоумение и ощущение "запугивания" читателя. Ну вот, например:


    Использовать HTTP 404 Not Found для уведомления об отсутствующем ресурсе — звучит чертовски по-RESTful, верно? Паршивое решение: ваш nginx был ошибочно сконфигурирован на один час, так что пользователи вашего API получают только ошибки 404 и вычищают сотни аккаунтов, думая, что они удалены…

    Речь, судя по всему, идёт про внешние ресурсы а-ля интернет-магазинов, т.е. не про внутренние сервисы, которые общаются автоматически. Соответственно, девопс или админ продеплоил конфигурацию nginx, не проверил, работает ли оно, на сервере не был настроен алертинг и никакие внешние сервисы типа pingdom? Ну ок, не очень ответственный человек, но поверим. Но, если пользователи не могут войти в свой аккаунт, то как они "вычищают" их? Т.е. вся ситуация выглядит притянутой за уши.


    Ну или вот:


    В результате, как и большинство пользователей REST, вы, вероятно, для выражения исключений в своём приложении используете случайные HTTP-коды вроде HTTP 418 I’m a teapot или вообще неприсвоенные номера. [...] Удачи вам в общении с такими API из автономных программ.

    За последние 3-4 года я написал штук 20 REST-сервисов, и ни в одном не использовал "левые" коды, как раз потому что к моим сервисам обращались автономные программы, которые по коду понимали, что делать дальше — подождать (503), запросить авторизацию (401 / 403), создать тикет (500) или нормально обработать результат (200). Люди, с которым я работал, тоже никогда так не делали. Публичные API, с которыми приходилось работать, тоже использовали коды по назначению. Тем не менее, автор делает необоснованные предположения, либо чтобы усилить свой аргумент, либо потому что привык к другой среде, о чём я и написал в заключении.


    Я писал сервисы, которые общались друг с другом по SOAP, REST, Websockets (включая подпротоколы), голому TCP, AMQP, NATS, Kafka и т.д., поэтому, наверное, я всё-таки немного в теме. И даже если допустить, что статью целиком я не понял, отдельные фразы вроде указанных выше интерпретировать иначе чертовски сложно.

  • REST — это новый SOAP
    +2

    Товарищи, которые минусуют, вы хоть комментарии какие-нибудь оставьте. А то видно, что вы не согласны, но с чем и почему, остаётся только догадываться :)

  • REST — это новый SOAP
    0

    По Swagger / OpenAPI описанию можно генерировать клиента (например), плюс многие библиотеки сразу дают красивый UI с примерами запросов, от чего клиенты обычно в восторге.

  • REST — это новый SOAP
    +3

    Не прочувствовал проблемы.


    Никаких стандартов, никаких точных спецификаций.

    HTTP — стандарт, хорошо задукоментированный. Пути, как правильно, достаточно понятны. Хочется большей точности — пишите документацию, тут никак не отвертишься, ни в случае с REST, ни в случае с чем-то ещё — ни SOAP, ни GraphQL не покроют всех деталей.


    Какую URL-endpoint вы присваиваете каждому «ресурсу»? Да, это просто, но приходится делать в любом случае. [...] Как вы сопоставите точные функции из приведённого примера с CRUD-операциями?

    Здесь автор предполагает, что API просто оборачивает какую-то БД, где есть какие-то таблицы-ресурсы. Но API может делать много чего другого — запускать процессы на кластере, делать вычисления, обращаться к другим API и т.д. Какой протокол покроет это? XML-схема здесь чем-нибудь поможет?


    Паршивое решение: ваш nginx был ошибочно сконфигурирован на один час, так что пользователи вашего API получают только ошибки 404 и вычищают сотни аккаунтов, думая, что они удалены…

    Откройте для себя www.pingdom.com иди десятки подобных ресурсов. Сайт может упасть по десяткам причин, с таким же успехом можно делать быстрые правки по SSH прямо на сервере и не проверять результат.


    Хотите с помощью PUT обновлять свои ресурсы? [...] Хотите для обновления своего ресурса использовать PATCH? [...] Хотите удалять ресурсы с помощью DELETE?

    Ок, если такие проблемы, используйте везде POST. Не по стандарту? Да, наверное, и что? Покрыть стандартом 100% случаев невозможно, но вас никто и не заставляет в точности следовать стандарту. REST вполне неплохо описывает то, что от вас будут ожидать пользователи, например, что GET не будет менять состояние, что DELETE удалит объект и т.п., но если в некоторых случаях такое поведение невозможно, пометьте эту часть в документации жирным.


    В общем и целом видно, что автор пришёл из определённого окружения, где SOAP хорошо работал, а REST работает хуже. Ну ок, нет серебрянной пули и всё такое. Но кроме окружения автора есть ещё сотни и тысячи вариантов использования, где REST если не оптимален, то как минимум лучше тяжеловесных решений типа SOAP.

  • Почему дизайн Go плох для умных программистов
    +5

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

  • Почему дизайн Go плох для умных программистов
    0

    Получается, что отсутствие версионирования зависимостей работает только для Google с их большим монолитным репозиторием, так?

  • Почему дизайн Go плох для умных программистов
    0
    Просто крупные игроки не хотят зависеть от какой-то третьей стороны, поэтому делают свой «улучшенный язык», который и продвигают везде.

    Да нет, не думаю — для Android, например, Google не стал изобретать новый язык программирования, а просто сделал свою реализацию рантайма.


    К тому же, потребность в своём собственном языке никак не влияет на дизайн этого языка. Задачи Google не так сильно отличаются от задач тысяч других компаний — (микро)сервисы с максимальной утилизацией CPU и памяти. Это объясняет горутины, например. Стремление к простоте изучения и близости к C тоже понятна, учитывая тысячи работающих у них студентов, хотя для многих других компаний это свойство языка может быть совершенно ненужным или неуместным. А вот замена дженериков на кодогенерацию или использование зависимостей без чёткого версионирования лично для меня ну совсем непонятны.

  • Большие данные и машинное обучение: новые возможности для медицины
    0

    Спасибо!

  • Большие данные и машинное обучение: новые возможности для медицины
    0
    появление открытых баз данных химических соединений и реакций

    А не подскажете пару-тройку источников таких данных? А то медицинские и биохемические базы зачастую либо очень маленькие, либо распространяются исключительно между университетами и крупными компаниями.

  • Автоэнкодеры в Keras, Часть 3: Вариационные автоэнкодеры (VAE)
    0

    +1 и буду ждать статью про VAE + GAN. Единственное, что не понял, это:


    Если метрика L_2, то мы считаем шум нормальным

    А как эти понятия вообще связаны в данном случае?

  • Hadoop: что, где и зачем
    0

    Пожалуйста!

  • Google DeepMind и Blizzard превратят StarCraft 2 в среду для изучения ИИ
    +4
    Пожалуйста, не пишите на темы, связанные с искусственным интеллектом или машинным обучением — вы напрочь не понимаете, о чём идёт речь. DeepMind не разрабатывает ИИ для StarCraft, он создаёт среду для других разработчиков, в которой те смогут отрабатывать свои алгоритмы ИИ. По сути, просто API, предоставляющий удобный программный доступ к игре.

    Для тех, кто всё-таки в теме, читайте оригинальную статью — там всё вполне логично.
  • Deep Learning: Сравнение фреймворков для символьного глубокого обучения
    0

    Судя по всему, автор статьи как раз и попал в ту терминологическую путаницу, про которую я говорю. Смотрите:


    The second advantage of symbolic computing is the automatic differentiation

    Здесь есть 2 понятия: символьные вычисления и автоматическое дифференцирование.


    Символные вычисления — это очень общее направление в информатике, описывающее вычисления над некоторыми символами. Как вы правильно обратили внимание, выражения, состоящие из переменных и операций могут быть предствлены в виде графа символов. Над этими выражениями можно проводить ряд символьных преобразований (например, упрощать выражения или находить символьные производные), трансформировать в код или план выполнения (как в случае с SQL) или делать логический вывод (как в случае эспертных систем). Графы в Theano и TensorFlow только частично являются символьными, ибо кроме имени символа хранят информацию о типе данных (это важно, см. ниже про символьное дифференцирование).


    Автоматическое дифференцирование (AD) в основном встречается в двух вариантах: forward-mode AD и reverse-mode AD. Forward-mode AD позволяет эффективно вычислять производные функций вида R -> R^n, что в рамках машинного обучения не очень интересно. А вот reverse-mode AD как раз хорошо работает с функциями R^n -> R, т.е. как раз к большинству функций потерь, для которых и требуется вычислить градиент.


    Фишка в том, что reverse-mode AD, вообще говоря, не требует никакого символьного представления. Например, стандартный алгоритм обратного распространения ошибки (backpropagation) — это как раз частный случай reverse-mode AD, но никакого симпольного графа в нём и рядом нет.


    Есть и другое направление — символьное дифференцирование. Чистое символьное дифференцирование, например, используется в Mathematica или SymPy. Пример из последнего:


    >>> diff(cos(x), x)
    -sin(x)

    Обратите внимание, что мы нигде не указали тип переменной x. По сути, большинство движков символьного дифференцирования умеет работать только с числами, но не с тензорами более высокого порядка. Более того, символьное дифференцирование не умеет обрабатывать условные переходы и циклы. С точки зрения математики, любое ветвление теоретически создаёт точку разрыва, а производная функции с точками разрыва может вообще не существовать или иметь очень сложну форму, вычислить которую компьютерными средствами ппц как нетривиально.


    Автоматическое дифференцирование не имеет таких проблем: в нём мы не пытаемся найти единое символьное представление для производной, а только находим её значение в одной конкретной точке, заданной на входе. Это и плюс и минус: с одной стороны, мы можем анализировать голый программный код, с условмиями, циклами, структурами данных и т.д., а с другой, на выходе мы получаем не красивое символьное выражение, а вычислительный граф, работать с которым всё-таки посложней (как минимум, человек не сможет его "прочитать" и вручную закодировать). Кроме того, в reverse-mode AD мы вынуждены сохранять значения промежуточных переменных, а это могут быть тензоры довольно больших размеров.


    Как Theano, так и TensorFlow (про MXNet не знаю) используют reverse-mode AD. Имена переменных (т.е. собственно "символы") при построении графа в них являются опциональными и могут польностью игнорироваться пользователем (сравните это с тем же SymPy или с логическими движками типа Prolog, где пользователя как раз и интересует конкретный символьных результат). Соответсвенно, слово "символьный" в названии, насколько я понимаю, не несёт никакой смысловой нагрузки и "символьное глубокое обучение" ничем не отличается от обычного :)


    (а началось всё с того, что я понадеялся увидеть совмещение современных глубоких сетей и старого доброго символьного AI :))

  • Deep Learning: Сравнение фреймворков для символьного глубокого обучения
    0

    В том то и дело, что там есть графы, но не символы :) В TensorFlow, например, граф состоит из переменных и операций, в MXNet — из переменых и слоёв, а термин "символ" встречается для обозначения тех же переменных только в Theano :)

  • Deep Learning: Сравнение фреймворков для символьного глубокого обучения
    –1

    Непонятно только, почему автор решил назвать эти фреймворки символьными: термин "symbolic AI" имеет совершенно другой смысл и относится скорее к логическому выводу в экспертных системах. Есть подозрение, что вся статья навеяна термином "symbol" в Theano, где он оправдан только наполовину (например, дифференцирование в нём всё-таки автоматическое, а не символьное).

  • Big Data головного мозга
    0
    Поставте s3 api на любое абстрактное хранилище, хоть полку c дисками — эффект будет тот же.


    Это всё понятно, вопрос был в том, нужен ли HDFS, если все данные — структурированые. Я привёл пример того, где абсолютно структирированные данные пишутся на HDFS, а не в RDBMS, потому что RDBMS не даёт нужного уровня абстракции и контроля.
    В конечном счете, если мы говорим о realtime — все, что не висит в памяти, напрямую из application или косвенно как object store — не есть realtime, ибо (относительно памяти) медленно.


    Real-time — понятие относительное. Например, Википедия говорит нам, что
    "real-time" means a range from milliseconds to a few seconds (5s) after the business event has occurred


    На практике же всё определяется ожиданиями клиента: если клиент загружает 3Гб данных и видит по ним аналитику через 15 минут, 13 из которых заливался файл, то для него это всё ещё "real-time".
  • Big Data головного мозга
    0
    Горячие данные он хранит под собой, сливая на hdfs (или s3, или ceph...) исторические свертки.


    Т.е. на распределённую файловую систему, которая в данном случае является необходимостью, а не "лишними издержками" :)
  • Big Data головного мозга
    0

    Расскажите use case, мы тоже считаем в т.ч. и клики, но 0.3 для вертики, честно говоря, звучит фантастически.

  • Big Data головного мозга
    0
    Пример, под Hadoop лежит «еще одна» файловая система, приводящая к фрагментации и рандому при чтении.


    WAT?? Поясните, пожалуйста, о какой фрагментации и рандомном чтении идёт речь?
    Если у вас нормальные, структурированные данные — вам не нужен HDFS, это лишние издержки.


    Расскажите, как, например, Vertica, справляется с real-time аналитикой? Я отвечу за вас: плохо. А вот, например, Druid, хранящий абсолютно структурированные данные на HDFS, делает это вполне эффективно. А всё потому, что HDFS и Hadoop вообще предоставляют более низкоуровневые инструменты и гораздо более широкие возможности, чем любая отдельно взятая SQL СУБД.
  • Big Data головного мозга
    0
    В Teradata Aster можно вроде как реализовывать задачи запускаемые непосредственно в самой базе либо на Java, либо на C/С++, про R как раз-таки не уверен.


    Про R у них прямо на сайте написано, так что я так понял, что это основной аналитический инструмент у них.

    В остальном да, согласен — термин перегретый, часто рождает мифы и слухи. Но и статьи вроде этой не помогают: автор явно пристрастен к SQL базам данных, поэтому я и пытаюсь показать примеры, где SQL сильно проигрывает.
  • Big Data головного мозга
    0

    О, значит, наконец, допилили. А вы случайно не пользовали? Как оно вообще, стабильно? Быстро? Для нас сейчас не суперактуально, но на будущее хотелось бы знать.

  • Big Data головного мозга
    0
    Другое дело насколько эта поддержка удовлетворяет вашим потребностям.


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

    А я потом приведу пример, как это делается в Spark, хоть со встроенным MLlib, хоть с использованием сторонних библиотек и их алгоритмов. И вот тогда уже можно будет предметно обсудить, стоит ли Hadoop своей славы или нет.
  • Big Data головного мозга
    0

    Продукт интересный, согласен, но я всё-таки задачи для примера привёл, чтобы показать, что SQL базы обычно не умеют. Для Teradata можно найти кучу других примеров (например, меня сразу смутило, что из general purpose языков, судя по всему, поддерживается только R и только через межпроцессорное взаимодействие, весь продукт недоступен шикорому кругу open source разработчиков, что замедляет развитие и т.д.). И точно так же можно назвать кучу недостатков для любого продукта из инфраструктуры Hadoop. Но нельзя говорить, что весь кипеш вокруг Hadoop и big data — это исключительно работа маркетологов: для формирования текущего рынка были вполне обоснованные исторически предпосылки со вполне конкретной выгодой.

  • Big Data головного мозга
    +1
    Открою для вас горькую правду — ничего бесплатного в нашем мире нет. Используя CDH или Hortonworks, вы должны купить подписку на поддержку, которая, кстати, не бесплатная.


    Нет, не должны. За деньги вы можете получить версию с парой дополнительных фич и да, поддержку, но и абсолютно бесплатной community edition обычно хватает за глаза.
    Все это есть в любой аналитической МРР системе, в том же Greenplum — библиотека MadLib, умеет делать очень много и на SQL-подобном языке.


    Так покажите мне, как конкретно решить эту задачу на Greenplum. Я не спорю, что вы сможете через трёхэтажный неэффективный запрос вы сможете сделать наивный Байсовский классификатор, может быть даже реализуете безумную логистическую регрессию, SVM — уже маловероятно. А на Spark я это (и много гораздо более сложных вещей) сделаю в пару строк кода. Смысл в том, что в отличие от SQL баз данных, Hadoop позволяет использовать любой кастомный код, строить любые статистические модели, вызывать любые сторонние API, сохранять состояние, отсылать метрики процесса и многое многое другое. Вы же увидели только SQL составляющу Hadoop и пытаетесь доказать, что все компании страдают ерундой, разворачивая себе Hadoop кластер вместо SQL СУБД.
    Согласен, не все так категорично, но перед тем как эти две таблички связать, необходимо провести много работы и не обязательно для этого использовать инструменты из зоопарка Hadoop.


    Естественно, и никто чисто на Hadoop не завязывается. Просто в инфраструктуре Hadoop много новых полезных инструментов таких как Spark, Storm, Kafka, GraphX, HBase и т.д., которые могут крутиться на одном и том же кластере и хорошо интегрированы друг с другом. Это удобно, но я пока не видел ни одной компании, которая бы замыкалась только на Hadoop и не использовала другие инструменты (в т.ч. классические SQL базы данных).
  • Big Data головного мозга
    +3
    Ну давайте по пунткам:
    Hadoop как средство для индексирования


    Hadoop вырос из Nutch, который вырос из Lucene. Но к моменту формирования Hadoop как отдельного проекта ASF (а тем более к моменту, когда он стал проектом верхнего уровня), Hadoop уже был вполне самостоятельным продуктом, вышедшим далеко за пределы индексирования текста.
    Миф 1. Hadoop — это бесплатно


    Софт — бесплатно, цена железа остаётся, и я пока не встречал менеджеров, которые это не понимали. Но цена софта тоже имеет значение: у нас, например, одна только лицензия на Vertica стоит больше чем лизинг серверов Hadoop и стоимость фулл-тайм администратора для него. Мы используем и то, и другое, для разных задач, потому что в одних случаях дешевле решать задачу одним способом, в другом — другим.
    Миф 2. Hadoop для обработки неструктурированной информации.


    Ок, задача: классифицировать 10Тб сообщений пользователей на Facebook. Опробовать статистические методы: наивный Байесовский классификатор, логистическая регрессия, машина опорных векторов. Покажите как это сделать на Vertica, Teradata или что вам больше нравится, а потом сравним это с реализацией на Hadoop/Spark.
    По цене CDH выходит немного дешевле Vertica/Greenplum.


    Да, например бесплатно. С поправкой на железо, конечно, но про это я уже сказал.
    Все это более-менее эффективно работает на простых запросах.


    Ага, поэтому мы сейчас переписываем уже почти загнувшееся решение на Redshift/Vertica на Spark/SparkSQL.
    Vertica будет полировать свою интеграцию с HDFS


    Полировать — это сильно сказано. Когда мы последний раз пытались написать свой (!) ридер паркетовский файлов из HDFS с помощью Vertica UDF, внезапно оказалось, что Vertica вообще не умеет парсить бинарные данные и пытается перевести из "битой" кодировки в "нормальный UTF-8". Бинарные данные в UTF-8, ага.

    В общем, вы явно либо не поняли сути технологического стека Hadoop, либо просто не хотите слазить с SQL-ориентированных задач. Увы, не всё в мире сводится к JOIN-у двух таблиц.
  • [Видео] Визуализация движений кунг-фу
    0
    Боюсь, VR здесь не сильно поможет, потому что почти во всех направляениях визуальная составляющая весьма незначительна :) С другой стороны, в традиционных БИ есть куча комплексов, которые позволяют подготовить тело и прочувствовать «обратную связь». Вот их можно делать и на дому.