
Про Spark ходит несколько мифов:
- Spark’y нужен Hadoop: не нужен!
- Spark’у нужна Scala: не обязательно!
Почему? Смотрите под катом.
Большие данные и всё о них
Продолжение предыдущих публикаций «Инструменты DataScience как альтернатива классической интеграции ИТ систем» и
«Экосистема R как инструмент для автоматизации бизнес-задач».
Настоящая статья является ответом на возникшие вопросы по пакетам R, которые полезны для реализации описанных подходов. Я ее рассматриваю исключительно как справочную информацию, и отправную точку для последующего детального изучения заинтересовавшимися, поскольку за каждым пакетом скрывается огромное пространство со своей философией и идеологией, математикой и путями развития.
Как правило, все пакеты (9109 штук на 07.09.2016) находятся в репозитории CRAN. Те, что по тем или иным причинам, пока не опубликованы в репозиторий, могут быть найдены на GitHub. Итак, кратким списком:
В современном мире нейронные сети находят себе всё больше применений в различных областях науки и бизнеса. Причем чем сложнее задача, тем более сложной получается нейросеть.
Обучение сложных нейронных сетей иногда может занимать дни и недели только для одной конфигурации. А чтобы подобрать оптимальную конфигурацию для конкретной задачи, требуется запустить обучение несколько раз — это может занять месяцы вычислений даже на действительно мощной машине.
В какой-то момент, знакомясь с представленным в 2015 году методом Batch Normalization от компании Google мне, для решения задачи связанной с распознаванием лиц, удалось существенно улучшить скорость работы нейросети.
За подробностями прошу под кат.
В первой части этой серии статей вы узнали о данных и о том, как можно использовать компьютеры чтобы добывать смысловое значение из крупных блоков таких данных. Вы даже видели что-то похожее на большие данные у Amazon.com середины девяностых, когда компания запустила технологию для наблюдения и записи в реальном времени всего, что многотысячная аудитория клиентов одновременно делала на их сайте. Довольно впечатляюще, но назвать это большими данными можно с натяжкой, пухлые данные — больше подойдёт. Организации вроде Агентства национальной безопасности США (NSA) и Центра правительственной связи Великобритании (GCHQ) уже собирали большие данные в то время в рамках шпионских операций, записывая цифровые сообщения, хотя у них и не было простого способа расшифровать их и найти в них смысл. Библиотеки правительственных записей были переполнены наборами бессвязных данных.
То, что сделал Amazon.com, было проще. Уровень удовлетворённости их клиентов мог быть легко определен, даже если он охватывал все десятки тысяч продуктов и миллионы потребителей. Действий, которые клиент может совершить в магазине, реальный он или виртуальный, не так уж много. Клиент может посмотреть что в доступе, запросить дополнительную информацию, сравнить продукты, положить что-то в корзину, купить или уйти. Всё это было в пределах возможностей реляционных баз данных, где отношения между всеми видами действий возможно задать заранее. И они должны быть заданы заранее, с чем у реляционных баз данных проблема — они не так легко расширяемы.
Заранее знать структуру такой базы данных — как составить список всех потенциальных друзей вашего неродившегося ребенка… на всю жизнь. В нём должны быть перечислены все неродившиеся друзья, потому что как только список будет составлен, любое добавление новой позиции потребует серьезного хирургического вмешательства.