Зачем очередная статья про то, как писать нейронные сети с нуля? Увы, я не смог найти статьи, где были бы описаны теория и код с нуля до полностью работающей модели. Сразу предупреждаю, что тут будет много математики. Я предполагаю, что читатель знаком с основами линейной алгебры, частными производными и хотя бы частично, с теорией вероятностей, а также Python и Numpy. Будем разбираться с полносвязной нейронной сетью и MNIST.

Интересный факт – 20% населения планеты хотя бы на каком-то уровне говорит на английском языке, а его носителями являются всего 5% населения. При этом, этот язык – пожалуй, главный в интернете. По статистике, на нем написано 55,5% всего размещенного онлайн-контента.

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

Привет, читатель.

Меня зовут Рушан, и я автор Telegram‑канала Нейрон. Не забудьте поделиться с коллегами или просто с теми, кому интересны такие статьи. Представляю пост который идёт строго (!) в закладки и передаётся коллегам. Он с подборкой примечательных файлов формата Jupyter Notebook по Machine Learning, Data Science и другим сферам, связанным с анализом данных. Эти блокноты Jupyter, будут наиболее полезны специалистам по анализу данных — как обучающимся новичкам, так и практикующим профи.



Итак, приступим.

Вводные курсы в Jupyter Notebook

• Учебник по Python
• Подборка блокнотов по командам IPython
• Пособие по Matplotlib

Привет, Хабр! Data Engineering становится все более популярным, многие компании постепенно открывают соответствующие вакансии. В связи с этим мы взяли интервью у Senior Data Science Engineer, Aligned Research Group LLC и преподавателя на программах “Специалист по большим данным” и “Data Engineer” Николая Маркова о том, что должны уметь data scientist-ы и data engineer-ы, чего им чаще всего не хватает и как найти свое место в анализе данных.

Приветствую всех.

В этом посте я расскажу, что такое VBA и как с ним работать в Microsoft Excel 2007/2010 (для более старых версий изменяется лишь интерфейс — код, скорее всего, будет таким же) для автоматизации различной рутины.

Итак, дорогие хабровчане, хочу представить на ваше обозрение инструкцию, как нам пришлось поднимать OLAP-сервер в нашей компании. Шаг за шагом мы пройдем по пути, который был нами проделан, начиная с установки и настройки Pentaho и заканчивая подготовкой таблиц данных и публикацией olap-куба на сервере. Естественно, многое здесь может быть сумбурным/неточным/неоптимальным, но когда нам понадобилось поднять сервер и посмотреть, сможет ли Pentaho заменить нашу самописную статистику, у нас не было и такого…

Как вы думаете, кто лучше настроит PostgreSQL — DBA или ML алгоритм? И если второй, то пора ли нам задуматься, чем заняться, когда нас заменят машины. Или до этого не дойдет, и важные решения все-таки должен принимать человек. Наверное, уровень изоляции и требования к устойчивости транзакций должны оставаться в ведении администратора. Но индексы уже скоро можно будет доверить машине определять самостоятельно.



Энди Павло на HighLoad++ рассказал про СУБД будущего, которые можно «потрогать» уже сейчас. Если пропустили это выступление или предпочитаете получать информацию на русском языке — под катом перевод выступления.

Речь пойдет о проекте университета Карнеги-Меллона, посвященном созданию автономных СУБД. Под термином «автономный» подразумевается система, которая может автоматически развертывать, настраивать, конфигурировать себя без какого-либо вмешательства человека. Возможно, потребуется около десяти лет, чтобы разработать что-то подобное, но именно этим заняты Энди и его студенты. Конечно, для создания автономной СУБД необходимы алгоритмы машинного обучения, однако, в этой статье сосредоточимся только на инженерной стороне темы. Рассмотрим, как проектировать программное обеспечение, чтобы сделать его автономным.

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

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

Отношения (relations)

Если заглянуть внутрь таблиц и индексов, то окажется, что они устроены схожим образом. И то, и другое — объекты базы, которые содержат некоторые данные, состоящие из строк.

То, что таблица состоит из строк, не вызывает сомнений; для индекса это менее очевидно. Тем не менее, представьте B-дерево: оно состоит из узлов, которые содержат индексированные значения и ссылки на другие узлы или на табличные строки. Вот эти узлы и можно считать индексными строками — фактически, так оно и есть.

На самом деле есть еще некоторое количество объектов, устроенных похожим образом: последовательности (по сути однострочные таблицы), материализованные представления (по сути таблицы, помнящие запрос). А еще есть обычные представления, которые сами по себе не хранят данные, но во всех остальных смыслах похожи на таблицы.

Все эти объекты в PostgreSQL называются общим словом отношение (по-английски relation). Слово крайне неудачное, потому что это термин из реляционной теории. Можно провести параллель между отношением и таблицей (представлением), но уж никак не между отношением и индексом. Но так уж сложилось: дают о себе знать академические корни PostgreSQL. Мне думается, что сначала так называли именно таблицы и представления, а остальное наросло со временем.

Привет, Хабр! Представляю вашему вниманию перевод статьи "Machine Learning for Anyone Who Took Math in Eighth Grade" автора Kyle Gallatin.

Я обычно замечаю, что искусственный интеллект объясняется одним из двух способов: через все более сенсационную призму различных медиа, или через плотную научную литературу, пронизанную излишним языком и специфическими для области терминами.

Между этими крайностями существует менее публикуемая область, где, я думаю, литература должна немного активизироваться. Новости о «прорывах», по типу этого глупого робота София, поднимают хайп вокруг искусственного интеллекта и может показаться, что это чем-то похоже на человеческое сознание, в то время как в действительности София не умнее, чем SmarterChild у AOL Instant Messenger.

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

Всем привет! Я руковожу центром киберзащиты DataLine. К нам приходят заказчики с задачей выполнения требований 152-ФЗ в облаке или на физической инфраструктуре.
Практически в каждом проекте приходится проводить просветительскую работу по развенчанию мифов вокруг этого закона. Я собрал самые частые заблуждения, которые могут дорого обойтись бюджету и нервной системе оператора персональных данных. Сразу оговорюсь, что случаи госконтор (ГИС), имеющих дело с гостайной, КИИ и пр. останутся за рамками этой статьи.

При использовании библиотеки pandas для анализа маленьких наборов данных, размер которых не превышает 100 мегабайт, производительность редко становится проблемой. Но когда речь идёт об исследовании наборов данных, размеры которых могут достигать нескольких гигабайт, проблемы с производительностью могут приводить к значительному увеличению длительности анализа данных и даже могут становиться причиной невозможности проведения анализа из-за нехватки памяти.

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



В материале, перевод которого мы публикуем сегодня, мы поговорим об особенностях работы с памятью при использовании pandas, и о том, как, просто подбирая подходящие типы данных, хранящихся в столбцах табличных структур данных DataFrame, снизить потребление памяти почти на 90%.

В сегодняшней части перевода серии материалов о Docker мы поговорим о работе с данными. В частности — о томах Docker. В этих материалах мы постоянно сравнивали программные механизмы Docker с разными съедобными аналогиями. Не будем отходить от этой традиции и здесь. Данные в Docker пусть будут специями. В мире существует множество видов специй, а в Docker — множество способов работы с данными.

→ Часть 1: основы
→ Часть 2: термины и концепции
→ Часть 3: файлы Dockerfile
→ Часть 4: уменьшение размеров образов и ускорение их сборки
→ Часть 5: команды
→ Часть 6: работа с данными

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

Курсы по анализу данных в CS центре читает Вадим Леонардович Аббакумов — кандидат физ.-мат. наук, он работает главным экспертом-аналитиком в компании Газпромнефть-Альтернативное топливо.

Лекции предназначены для двух категорий слушателей. Первая — начинающие аналитики, которым сложно начинать с изучения, например, книги The Elements of Statistical Learning. Курс подготовит их к дальнейшей работе. Вторая — опытные аналитики, не получившие систематического образования в области анализа данных. Они могут заполнить пробелы в знаниях. С прошлого года на занятиях используется язык программирования Python.

Чтобы понимать материал, достаточно когда-то прослушанных курсов математического анализа, линейной алгебры и теории вероятностей и базовых знаний языка Python.

Приятного просмотра!

Привет, Хабр! Несколько месяцев назад у меня остро встал вопрос смены профиля деятельности и я обнаружил, что для претендента на вакансию web-разработчика сейчас недостаточно навыков десятилетней давности (какая неожиданность!). Пришлось срочно актуализировать свои знания. Заодно я решил составить шпаргалку с описанием большинства современных технологий, чтобы в случае чего кидать жаждущим новых знаний линк на эту статью, да и самому не забывать.

Всем привет. Когда я начинал изучение Python, устанавливал впервые Jupyter Notebook, потом пытался передать с созданное в нём приложение на предприятие, я часто сталкивался с различными проблемами. То кириллица в имени пользователя мешает, то настройки не перенеслись, то ещё чего-то. Все эти проблемы я преодолел в основном самостоятельно, используя Google и затратив немало времени на их решение.

По мере роста опыта я научился создавать папку, в которой лежит переносимое с одного компьютера на другой виртуальное окружение Python, настройки Jupyter и Matplotlib, портативные программы (ffmpeg и др.) и шрифты. Я мог написать дома программу, скопировать всю эту папку на компьютер предприятия, и быть уверенным, что ничего не потеряется и не сломается на ровном месте. Потом я подумал, что такую папку можно дать и новичку в Python, и он получит полностью настроенную и переносимую среду.

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

Data Science — наука о данных, возникшая на стыке нескольких обширных направлений: программирования, математики и машинного обучения. Этим обусловлен высокий порог вхождения в профессию и необходимость постоянно получать новые знания.

Ключевыми навыками для начинающих специалистов являются:

• умение писать код (Python);
• способность визуализировать свои результаты;
• понимание того, что происходит «под капотом».

На эти три категории разделены книги, которые специалисты Plarium Krasnodar подобрали для читателей с начальными знаниями в Data Science.

Привет, Хабр! Мы уже говорили про Theano и Tensorflow (а также много про что еще), а сегодня сегодня пришло время поговорить про Keras.

Изначально Keras вырос как удобная надстройка над Theano. Отсюда и его греческое имя — κέρας, что значит "рог" по-гречески, что, в свою очередь, является отсылкой к Одиссее Гомера. Хотя, с тех пор утекло много воды, и Keras стал сначала поддерживать Tensorflow, а потом и вовсе стал его частью. Впрочем, наш рассказ будет посвящен не сложной судьбе этого фреймворка, а его возможностям. Если вам интересно, добро пожаловать под кат.

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



Речь пойдет о компании федерального уровня с большим числом филиалов и подфилиалов. Но, как обычно, все началось давным-давно с одного маленького магазина. С течением лет шло достаточно быстрое и стихийное развитие, появлялись филиалы, подразделения и прочие офисы, а ИТ-инфраструктуре не уделялось в те времена должного внимания, и это тоже частое явление. Конечно же, везде использовалась 1С77, без задела на какие-либо репликации и масштабирование, поэтому, сами понимаете, в конце пришли к тому, что был порожден спрут-франкенштейн с примотанными изолентой щупальцами — в каждом филиале автономный мутант, который с центральной базой обменивался в «наколеночном» режиме лишь несколькими справочниками, без которых ну вообще никак было нельзя, а остальное автономно. Какое-то время довольствовались копиями (десятки их!) филиальных баз в центральном офисе, но данные в них отставали на несколько дней.

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

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

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