Привет, Хабр! Сегодня мы построим систему, которая будет при помощи Spark Streaming обрабатывать потоки сообщений Apache Kafka и записывать результат обработки в облачную базу данных AWS RDS.

Представим, что некая кредитная организация ставит перед нами задачу обработки входящих транзакций «на лету» по всем своим филиалам. Это может быть сделано с целью оперативного расчета открытой валютой позиции для казначейства, лимитов или финансового результата по сделкам и т.д.

Как реализовать этот кейс без применения магии и волшебных заклинаний — читаем под катом! Поехали!


(Источник картинки)

По данным ssh.com и Wikipedia, первая версия и реализация протокола SSH увидела свет в 1995 году. Задачей автора было разработать безопасную альтернативу использовавшимся тогда для удалённого администрирования rlogin, telnet и rsh. Любопытно, что появлению протокола SSH поспособствовал инцидент информационной безопасности, в результате которого злоумышленник собрал внушительную базу логинов/паролей от серверов, просто прослушивая университетскую сеть и выделяя пакеты аутентификации (пары логин/пароль в них передавались в незашифрованном виде).

Протокол быстро завоевал популярность и после длительного периода доработок и улучшений был стандартизован IETF в 2006 году. С тех пор он успел стать де-факто стандартом для удалённого управления системами с текстовой консолью. Помимо собственно текстовой консоли в протоколе предусмотрена масса других полезных функций, таких как передача файлов и переадресация портов. Именно о переадресации портов (port forwarding) и её не слишком очевидном применении пойдёт речь в этой статье.

С чего начинается родина мы все знаем, а глубокое обучение начинается с данных. Без них невозможно обучить модель, оценить ее, да и вообще использовать. Занимаясь исследованиями, увеличивая индекс Хирша статьями о новых архитектурах нейронных сетей и экспериментируя, мы опираемся на простейшие локальные источники данных; обычно — файлы в различных форматах. Это работает, но неплохо было бы помнить про боевую систему, содержащую терабайты постоянно меняющихся данных. А это значит, что нужно упростить и ускорить передачу данных в продакшене, а также иметь возможность работы с большими данными. Вот тут и наступает время Apache Ignite.

Apache Ignite – это распределенная memory-centric база данных, а также платформа для кэширования и обработки операций, связанных с транзакциями, аналитикой и потоковыми нагрузками. Система способна перемалывать петабайты данных со скоростью оперативной памяти. В статье речь пойдет об интеграции между Apache Ignite и TensorFlow, которая позволяет применять Apache Ignite в качестве источника данных для обучения нейронной сети и инференса, а также в качестве хранилища обучаемых моделей и системы управления кластером при распределенном обучении.

Представляем IBM Watson Studio

Специалисты начинают пользоваться искусственным интеллектом для превращения нашего самого ценного ресурса — данных — в новые формы ведения бизнеса. Искусственный интеллект дает нам возможность закончить битву с данными и начать пользоваться ими для подготовки убедительных рекомендаций, ускорения научных исследований и повышения качества взаимодействия с клиентами в удобной для них форме. Задача систем искусственного интеллекта — дополнять интеллект человека, и сегодня мы делаем еще один шаг на пути к тому, чтобы сделать ИИ более доступным каждому. Встречайте IBM Watson Studio.

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

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

Итого, как в таких условиях нарисовать вот такую картинку за 180 строчек кода?

Перевели для вас статью Лори Хартикка (Lauri Hartikka) о создании простейшего ИИ для шахмат. Она написана еще в 2017 году, но базовые принципы остались теми же. Все файлы, которые использовал Лори, тоже доступны.

Простой искусственный интеллект, который умеет играть в шахматы, можно создать на базе четырех концепций:

1. 1. Перемещение;
2. 2. Оценка доски;
3. 3. Минимакс;
4. 4. Альфа-бета-отсечение. На каждом этапе работы с алгоритмом будет использоваться одна из них, это позволит постепенно совершенствовать игровые способности ИИ.

Это третья статья в цикле full-stack dev о секретной жизни данных. Она посвящена сложному и длинному маршруту SMS: набор, сохранение, отправка, получение и отображение. Добавлю немного истории и контекст, чтобы разбавить перечень протоколов. Хотя текст довольно технический, всё довольно легко понять.

Первые две части цикла:

• Cetus, о распространении ошибок в предках электронных таблиц XVII века
• «Вниз по кроличьей норе», о безумно сложном поиске источника одного набора данных

Итак, начнём…

Подготовили перевод следующей части многосерийной статьи, где сравнивается функциональность Apache Kafka и RabbitMQ. В этой публикации речь идёт о семантике и гарантии доставки сообщений. Обращаем ваше внимание, что автор учитывал Кафку до версии 0.10 включительно, а в версии 0.11 появился exactly-once. Тем не менее, статья остаётся актуальной и полна полезных с практической точки зрения моментов.
Предыдущие части: первая, вторая.

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

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

Внимание: просто рассматривать мой код, равно как и просто читать эту статью с чашкой чая в руке, смысла не имеет. Эта статья рассчитана на то, что вы возьмётесь за клавиатуру и напишете ваш собственный движок. Он наверняка будет лучше моего. Ну или просто смените язык программирования!

Итак, сегодня я покажу, как отрисовывать подобные картинки:

В этом руководстве я расскажу, как написать собственную виртуальную машину (VM), способную запускать программы на ассемблере, такие как 2048 (моего друга) или Roguelike (моя). Если вы умеете программировать, но хотите лучше понять, что происходит внутри компьютера и как работают языки программирования, то этот проект для вас. Написание собственной виртуальной машины может показаться немного страшным, но я обещаю, что тема удивительно простая и поучительная.

Окончательный код составляет около 250 строк на C. Достаточно знать лишь основы C или C++, такие как двоичная арифметика. Для сборки и запуска подходит любая Unix-система (включая macOS). Несколько API Unix используются для настройки ввода и отображения консоли, но они не являются существенными для основного кода. (Реализация поддержки Windows приветствуется).

Примечание: эта VM — грамотная программа. То есть вы прямо сейчас уже читаете её исходный код! Каждый фрагмент кода будет показан и подробно объяснён, так что можете быть уверены: ничего не упущено. Окончательный код создан сплетением блоков кода. Репозиторий проекта тут.

Сегодня на тематических зарубежных сайтах о Big Data можно встретить упоминание такого относительно нового для экосистемы Hadoop инструмента как Apache NiFi. Это современный open source ETL-инструмент. Распределенная архитектура для быстрой параллельной загрузки и обработки данных, большое количество плагинов для источников и преобразований, версионирование конфигураций – это только часть его преимуществ. При всей своей мощи NiFi остается достаточно простым в использовании.



Мы в «Ростелекоме» стремимся развивать работу с Hadoop, так что уже попробовали и оценили преимущества Apache NiFi по сравнению с другими решениями. В этой статье я расскажу, чем нас привлек этот инструмент и как мы его используем.

В «Ростелекоме» мы используем Hadoop для хранения и обработки данных, загруженных из многочисленных источников с помощью java-приложений. Сейчас мы переехали на новую версию hadoop с Kerberos Authentication. При переезде столкнулись с рядом проблем, в том числе и с использованием YARN API. Работа Hadoop с Kerberos Authentication заслуживает отдельной статьи, а в этой мы поговорим об отладке Hadoop MapReduce.

Добрый день! Меня зовут Данил Липовой, наша команда в Сбертехе начала использовать HBase в качестве хранилища оперативных данных. В ходе его изучения накопился опыт, который захотелось систематизировать и описать (надеемся, что многим будет полезно). Все приведенные ниже эксперименты проводились с версиями HBase 1.2.0-cdh5.14.2 и 2.0.0-cdh6.0.0-beta1.

1. Общая архитектура
2. Запись данных в HBASE
3. Чтение данных из HBASE
4. Кэширование данных
5. Пакетная обработка данных MultiGet/MultiPut
6. Стратегия разбивки таблиц на регионы (спилитинг)
7. Отказоустойчивость, компактификация и локальность данных
8. Настройки и производительность
9. Нагрузочное тестирование
10. Выводы

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

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

В ночь с 27 на 28 июля 2018 года произойдут два довольно редких астрономических явления. Факт их календарного совпадения не делает эти явления более ценными для науки, но создает вокруг них дополнительный интерес. Некоторые люди рассматривают совпадение двух астрономических явлений как некоторое самостоятельное явление, что не вполне корректно, но заслуживает отдельного рассмотрения с точки зрения понимания того, насколько часто подобное происходит, и влияет ли одно на другое хоть как-то.

Что же произойдет?

Здравствуйте, коллеги! Напоминаем, что не так давно у нас вышла книга о Spark, а прямо сейчас проходит последнюю корректуру книга о Kafka.


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

В прошлых двух статьях мы рассказывали об IIoT — индустриальном интернете вещей — строили архитектуру, чтобы принимать данные от сенсоров, паяли сами сенсоры. Краеугольным камнем архитектур IIoT да и вообще любых архитектур работающих с BigData является потоковая обработка данных. В ее основе лежит концепция передачи сообщений и очередей. Стандартом работы с рассылкой сообщений сейчас стала Apache Kafka. Однако, для того, чтобы разобраться в ее преимуществах (и понять ее недостатки) было бы хорошо разобраться в основах работы систем очередей в целом, механизмах их работы, шаблонах использования и основной функциональности.

Мы нашли отличную серию статей, которая сравнивает функциональность Apache Kafka и другого (незаслуженно игнорируемого) гиганта среди систем очередей — RabbitMQ. Эту серию статей мы перевели, снабдили своими комментариями и дополнили. Хотя серия и написана в декабре 2017 года, мир систем обмена сообщениями (и особенно Apache Kafka) меняется так быстро, что уже к лету 2018-го года некоторые вещи изменились.

Крупный бизнес и кровавый энтерпрайз уже давно нашли замену взрослым рсубд на задачах DWH и аналитики. DWH массово движется в сторону DataLake и Hadoop. Выглядит, что и небольшим компаниям уже нет особого смысла запускать аналитику на серьезной рсубд. С ростом кол-ва ядер доступных даже небольшому бизнесу пытаться лицензировать полноценную редакцию взрослой субд типа Oracle смысла мало. Standard редакция Oracle хоть и лицензируется по сокетам, но при этом вырезан важнейший функционал. Во первых в standard редакции нет partitioning

Речь пойдёт об использовании Apache Spark для анализа поведенческих факторов на сайте, который имеет очень большую посещаемость. Учёт поведенческих факторов весьма часто используется для повышения конверсии ресурса. Кроме этого, возможности Интернет позволяют очень просто и быстро собирать и анализировать гигантское количество самой разной статистической информации. Будут показаны примеры кода и даны некоторые советы, основанные на личном опыте автора статьи.

Как вы думаете, чего в апельсине больше — кожуры, или, хм, апельсина?



Предлагаю, если есть возможность, пойти на кухню, взять апельсин, очистить и проверить. Если лень или нет под рукой — воспользуемся скучной математикой: объем шара мы помним из школы. Пусть, скажем, толщина кожуры равна от радиуса, тогда , ; вычтем одно из другого, поделим объем кожуры на объем апельсина… получается, что кожуры что-то около 16%. Не так уж мало, кстати.

Как насчет апельсина в тысячемерном пространстве?

Пойти на кухню на этот раз не получится; подозреваю, что формулу наизусть тоже не все знают, но Википедия нам в помощь. Повторяем аналогичные вычисления, и с интересом обнаруживаем, что:

• во-первых, в тысячемерном гиперапельсине кожуры больше, чем мякоти
• а во-вторых, ее больше примерно в 246993291800602563115535632700000000000000 раз

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

Начнем с этого, пожалуй.