Apache *

В нашей компании СберТех (Сбербанк Технологии) на данный момент используется HDFS 2.8.4 так как у него есть ряд преимуществ, таких как экосистема Hadoop, быстрая работа с большими объемами данных, он хорош в аналитике и многое другое. Но в декабре 2017 года Apache Software Foundation выпустила новую версию открытого фреймворка для разработки и выполнения распределённых программ — Hadoop 3.0.0, которая включает в себя ряд существенных улучшений по сравнению с предыдущей основной линией выпуска (hadoop-2.x). Одно из самых важных и интересующих нас обновлений это поддержка кодов избыточности (Erasure Coding). Поэтому была поставлена задача сравнить данные версии между собой.

Компанией СберТех на данную исследовательскую работу было выделено 10 виртуальных машин размером по 40 Гбайт. Так как политика кодирования RS(10,4) требует минимум 14 машин, то протестировать ее не получится.

На одной из машин будет расположен NameNode помимо DataNode. Тестирования будет проводиться при следующих политиках кодирования:

• XOR(2,1)
• RS(3,2)
• RS(6,3)

А также, используя репликацию с фактором репликации равным 3.

Размер блока данных был выбран равным 32 Мб.

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

Скорее всего какие-то части этой статьи уже знакомы многим хаброжителям, но в связи с покупкой нового рабочего ноутбука я решил собрать все крупинки воедино и организовать удобное средство для разработки. Мне часто приходится работать со множеством маленьких проектов, с разными версиями PHP, часто переводить старые проекты на новые версии. В далёком прошлом, когда я был пользователем Windows то использовал OpenServer. Но с переходом на Linux мне нехватало той простоты создания хостов и переключений версий которые были в нём. Поэтому пришлось сделать еще более удобное решение на Linux =)

Цели

1. Использовать текущий на момент написания статьи софт
2. Чтоб разграничить локальные домены, будем использовать специальный домен .loc
3. Переключения версий PHP реализуем через поддомен c помощью fast-cgi
4. Автоматическое создание хоста с помощью vhost_alias и dnsmasq

Что имеем в итоге. При переходе на

56.test.loc

Apache запустит c версией PHP 5.6.36

/var/www/test.loc/public_html/index.php

Поменяв поддомен на

72.test.loc

будет запущен тот же файл но уже с версией PHP 7.2.7

Другие версии доставляются аналогичным описанным ниже способом.

Для создания еще одного сайта просто создаем в /var/www/ папку имеющую окончание .loc, внутри которой должна быть папка public_html являющаяся корнем сайта

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

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

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

В этом посте мы рассмотрим доступ к API Spark из различных языков программирования в JVM, а также некоторые вопросы производительности при выходе за пределы языка Scala. Даже если вы работаете вне JVM, данный раздел может оказаться полезен, поскольку не-JVM-языки часто зависят от API Java, а не от API Scala.

Работа на других языках программирования далеко не всегда означает необходимость выхода за пределы JVM, и работа в JVM имеет немало преимуществ с точки зрения производительности — в основном вследствие того, что не требуется копировать данные. Хотя для обращения к Spark не из языка Scala не обязательно нужны специальные библиотеки привязки или адаптеры, вызвать код на языке Scala из других языков программирования может быть непросто. Фреймворк Spark поддерживает использование в преобразованиях лямбда-выражений языка Java 8, а у тех, кто применяет более старые версии JDK, есть возможность реализовать соответствующий интерфейс из пакета org.apache.spark.api.java.function. Даже в случаях, когда не требуется копировать данные, у работы на другом языке программирования могут быть небольшие, но важные нюансы, связанные с производительностью.

Данная статья предлагает пошаговую инструкцию по установке сертификата на HTTP сервер Apache. Обратите внимание, что с версии 2.4.8 Apache параметры конфигурации сервера были изменены.

Часть 2: Решение

И снова здравствуйте! Сегодня я продолжу свой рассказ о том, как мы классифицируем большие объёмы данных на Apache Spark, используя произвольные модели машинного обучения. В первой части статьи мы рассмотрели саму постановку задачи, а также основные проблемы, которые возникают при организации взаимодействия между кластером, на котором хранятся и обрабатываются исходные данные, и внешним сервисом классификации. Во второй части мы рассмотрим один из вариантов решения данной задачи с использованием подхода Reactive Streams и его реализации с использованием библиотеки akka-streams.

Привет, Хабр!

Работаю на большом интеграционном проекте (IBM WAS, WebSphere MQ, Oracle) и оплетаю наш кровавый энтерпрайз паутиной функциональных тестов в JMeter, который крутится на тестовом стенде и пробуждается по зову Jenkins после деплоя нового билда. По мере увеличения количества тестов столкнулся с проблемой поддержания тестовой документации в актуальном виде.

Часть 1: Постановка задачи

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

• Как представить модель машинного обучения в виде сервиса (Model as a Service)?
• Как физически выполняются задачи распределенной обработки больших объемов данных при помощи Apache Spark?
• Какие проблемы возникают при взаимодействии Apache Spark с внешними сервисами?
• Как при помощи библиотек akka-streams и akka-http, а также подхода Reactive Streams можно организовать эффективное взаимодействие Apache Spark с внешними сервисами?

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

Привет, Хабр!

Сегодня мы предлагаем вам сравнительно краткую, но при этом толковую и информативную статью об устройстве и вариантах применения Apache Kafka. Рассчитываем перевести и выпустить книгу Нии Нархид (Neha Narkhede) et. al до конца лета.


Приятного чтения!

Введение

В этой статье хочу поделиться своим опытом интеграции сетевого приложения (в моем случае — игры) с социальными сетями. Так как я стараюсь, по возможности, не прибегать к сторонним решениям, то сетевая часть была разработана на том, что предлагает Unity3D, а именно — Unet с использованием его низкоуровневой части (LLAPI). NetworkClient на клиенте соединяется с NetworkServer на удаленном сервере. Игровой сервер тоже написан на Unity3D. Работа в такой связке, хоть и требует углубленных знаний Unet , но имеет свои неоспоримые плюсы.

Проблема

И вот настало время разместить приложение в соц. сети. Подключив API соц. сети, настроил приложение в самой соц. сети, скомпилировал WebGl сборку и выложил игру на сервер. Первый запуск приложения сразу выявил ошибку: WebGl сборка не может открыть обычный Socket и требует работать только через WebSocket. Здесь все понятно — это мое упущение, ведь крайнее приложение я делал еще под Unity Web Player, который работал на обычных Socket'ах. Решив вопрос настройки сети для работы с WebSocket'ами (об этом чуть позже), я столкнулся со следующей проблемой. Т.к. соц. сети (по крайней мере та, с которой я интегрировался) работает по защищенному протоколу (Https) и предъявляет требование к своему контенту, так же работать через защищенный протокол. «Не беда» — подумал я, сейчас сделаем… Несколько дней «копания» интернета, общения с разработчиками Unity ввергло меня в уныние: поддержки защищенных WebSocket'ов (WSS) в Unet нет и неизвестно когда будет. Насколько я понимаю, большинство разработчиков в этом месте уходят в «фотон». Но мы не такие!

Так вот при чем тут соц. сети. Для обычной web-сборки работаем с обычными WebSocket'ами и радуемся жизни.

Возникла задача отслеживания загрузок файлов с сайта (изображений, документов, видео, дистрибутивов, …), т.к. обычные сервисы статистики не могут это делать без изменения URL файлов. И статистика должна быть видна в привычном месте (например, Google Analytics или FireBase).

Перебрав несколько плагинов (большинство имеют в названии слова Download и Manager), я обнаружил, что все они организованы по принципу ручного составления списка файлов для мониторинга. И во многих из них реализованы защиты от неавторизированного скачивания, что в данной задаче избыточно. Можно было бы воспользоваться ими, но если файлов много, то в итоге:

• слишком неудобно и долго заводить элемент под каждый файл;
• файлы могут менять свое расположение – опять придется исправлять элемент.

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

Ссылка на бесплатный плагин тут для тех кому информации выше достаточно. Дальше приведены примеры результатов статистик и подробности технической реализации.

6-7 апреля в Москве в шестой раз пройдет JPoint – международная Java-конференция для опытных разработчиков. В этот раз в ней примет участие Клаус Ибсен (Claus Ibsen) – старший инженер Red Hat, гуру Apache. Ниже приводим перевод начала его книги «Camel in Action» – эксклюзивно для читателей нашего блога.

Привет, Хабр!

Мы продолжаем интересоваться новыми решениями от Apache. Рассчитываем выпустить в мае книгу «High Performance Spark» Холдена Карау (книга в верстке), а в августе — книгу «Kafka: The Definitive Guide» Нии Нархид (еще в переводе). Сегодня же хотим предложить краткую ознакомительную статью об Apache Ignite и оценить масштаб интереса к теме.

Приятного чтения!

На просторах интернета не нашел единого рецепта по установке и настройке такого, довольно нестандартного сервера. Решил написать свой рецепт.

Принцип работы следующий:


Статические данные (файлы) отдает Nginx, а динамикой занимается Apache.

При первом знакомстве с Solaris единственным для меня недостатком был тот факт, что пакеты которые возможно установить являются довольно устарелыми, но к счастью актуальные версии можно собрать из исходного кода. В данной публикации пойдёт речь о сборке apache и php из исходного кода(mysql можно скачать в виде готового пакета с сайта mysql.com). На момент написания данной публикации актуальная версия apache была 2.4.29, а php 7.2.3.

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

Можно выполнять операции get/put как c Map, например в java, эти операции имеют название сквозного чтения, записи в постоянное хранилище (write-through and read-through). Т.е. после того как кеш загружен при выполнении операции get объект будет взят их него, а не из базы, а при записи он изменится в кеше и будет записан в хранилище данных. Если при попытке взятия объекта его не будет в кеше он будет вначале в него записан. Понятно что операции чтения уже будут из памяти кеша и очень быстро. Все это актуально для операций get/put. Для других операций поиска, например для поиска объекта не по ключу есть — Query, как быстрее находить данные в кеше?, работа с транзакциями, все это ниже в статье…

Вычисления в гриде или майнинг «красивых» хешей, такую задачу я решил проверить для вычисления в гриде Apache Ignite. Ранее я пробовал и писал Ignite как Sql БД, но для себя я понял что это пока удобная опция в этой вычислительной системе (к SQL на Ignite я еще вернусь), именно так как вычислительная система я себе ее представляю с возможностью быстрой и не дорогой масштабируемостью. Вот это и посмотрим, как можно быстро и недорого нарастить вычисления, или нет, например нарастить вычисления 1 мощного компьютера добавляя к нему несколько слабых.

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

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

Материал прозаичен, но может оказаться кому-нибудь полезным, чему я буду очень рад. Ещё больше буду признателен конструктивным советам и отзывам.

Итак, наша тема – «Как реализовать Single Sign-On для веб-приложения в условиях разношёрстности и нормальной лохматости системного зоопарка».

Apache Ignite – распределенная база данных в памяти, подобные БД получают распространение и хочется сравнить с тем что уже есть и зарекомендовало себя, например реляционная СУБД Oracle. Ignite имеет широкие возможности распределенных вычислений, также есть поддержка SQL на уровне ANSI-99, в производительности SQL и хочется сделать некоторое сравнение. Настройка БД будет в обоих случаях во многом по умолчанию, в случае Oracle это XE, а в случае Ignite это два узла(node) на одном компьютере. Компьютер i5 7400 (4-ядра) 3.5Ггц, 8Гб ОЗУ, SSD диск.
В качестве тестовых данных буду использовать данные КЛАДР (~223 тыс. записей) в качестве среды выполнения запросов DBeaver в котором настроены два подключения к Ignite и Oracle. И первое что сделаю импортирую данные в таблицы, Данные КЛАДР из DBF переведу в CSV, а затем средствами DBeaver выполню импорт в таблицы.