• Энтропия и выявление аномалий сетевого трафика



      В данной статье Даниил Волков, ведущий эксперт бизнес-направления Data Science компании Neoflex, рассказывает о методах обнаружения сетевых аномалий, основанных на использовании энтропии – основной характеристики систем с точки зрения теории информации. Также он отмечает некоторые способы обнаружения аномалий временных рядов.

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

      • Масштабируемость. Предложенные методы способны использовать агрегированные данные (например, записи Netflow), что делает возможным использование в сколь угодно сложных и высоконагруженных сетях.
      • Чувствительность к изменениям распределений характеристик трафика. Энтропийный подход помогает среагировать на аномалию, и в тех случаях, когда такие классические характеристики трафика, как packets rate (rps) не обнаруживают значимого аномального поведения (т.о., способен выявлять атаки с низким относительным packets rate).
      • Легкость реализации и доступная интерпретация. Быстрая готовность к работе, отсутствие необходимости в данных для обучения и способность находить атаки zero-day.

      Сетевые потоки


      Итак, предлагаемые системы обнаружения аномалий на основе понятия «энтропия» анализируют сетевые потоки, а не отдельные сетевые пакеты. Определим сетевые потоки (далее просто потоки) как однонаправленную метаинформацию о сетевых пакетах, имеющих одинаковые исходный и целевой IP-адрес и порты, а также тип протокола IP. Важно отметить, что вся сетевая активность в OSI уровня 3 и выше сводится к потокам, т.е. это не только TCP- соединения, но и протоколы без сохранения состояния, такие как UDP и ICMP. Преимущества использования концепции потоков:
      Читать дальше →
    • AWS Control Tower и почему мы его не используем



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

        Однако для управления аккаунтами одного сервиса AWS Organizations недостаточно. Есть желание не просто создавать аккаунты, но создавать их так, чтобы они удовлетворяли принятым в компании нормам и политикам, иметь возможность отслеживать состояние созданных аккаунтов, управлять политиками, не редактируя JSON документ, а более удобным способом. Также в случае роста количества аккаунтов в организации понимание того, что возможностей сервиса AWS Organizations не хватает приходит достаточно быстро. И вот тем, кто вступил на этот путь есть два варианта – или использовать инструмент от AWS – Control Tower или разработать собственные скрипты управления. Дальше в статье рассказывается почему мы выбрали второй вариант.

        Что такое AWS Control Tower?


        Начать стоит с определения AWS Landing Zone – решение, которое помогает пользователям быстро настроить безопасную среду AWS с несколькими аккаунтами основываясь на лучших практиках. Именно оно лежит в основе AWS Control Tower. Как следует из официальной информации, решение это продолжает существовать, но без будущих доработок и новым пользователям настоятельно рекомендуется использовать AWS Control Tower для управления AWS средой с несколькими аккаунтами.
        Читать дальше →
      • Настройка DBT + Spark для кластера Cloudera on-prem



          Для управления кодом Spark-приложений мы используем подход, описанный в предыдущей статье.

          Речь идет об управлении качеством кода при разработке Spark ETL, чтобы не превратить работу над проектом в полет души, пугающий даже автора. В результате Spark ETL application выглядит просто как последовательность Spark SQL-запросов. Сама ETL-трансформация описывается как объект в отдельном файле конфигурации.
          Читать дальше →
        • Управление кодом Spark-приложений



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

            Как можно управлять сложностью проекта по разработке ETL-трансформаций на Spark?

            Тут все не так просто.

            Как это выглядит в жизни? Заказчик предлагает создать приложение, собирающее витрину. Вроде бы надо выполнить через Spark SQL код и сохранить результат. В ходе разработки выясняется, что для сборки этой витрины требуется 20 источников данных, из которых 15 похожи, остальные нет. Эти источники надо объединить. Далее выясняется, что для половины из них надо писать собственные процедуры сборки, очистки, нормализации.

            И простая витрина после детального описания начинает выглядеть примерно так:



            В результате простой проект, который должен был всего лишь запустить на Spark скрипт SQL собирающий витрину, обрастает собственным конфигуратором, блоком чтения большого числа настроечных файлов, собственным ответвлением маппинга, трансляторами каких-нибудь специальных правил и т.д.
            Читать дальше →
          • Spark schemaEvolution на практике

              Уважаемые читатели, доброго дня!

              В данной статье ведущий консультант бизнес-направления Big Data Solutions компании «Неофлекс», подробно описывает варианты построения витрин переменной структуры с использованием Apache Spark.

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

              Обычно это логи, или ответы различных систем, сохраняемые в виде JSON или XML. Данные выгружаются в Hadoop, далее из них нужно построить витрину. Организовать доступ к созданной витрине можем, например, через Impala.

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

              Например, сегодня логируется такой ответ:

              {source: "app1", error_code: ""}

              а завтра от этой же системы приходит такой ответ:

              {source: "app1", error_code: "error", description: "Network error"}

              В результате в витрину должно добавиться еще одно поле — description, и придет оно или нет, никто не знает.

              Задача создания витрины на таких данных довольно стандартная, и у Spark для этого есть ряд инструментов. Для парсинга исходных данных есть поддержка и JSON, и XML, а для неизвестной заранее схемы предусмотрена поддержка schemaEvolution.

              С первого взгляда решение выглядит просто. Надо взять папку с JSON и прочитать в dataframe. Spark создаст схему, вложенные данные превратит в структуры. Далее все нужно сохранить в parquet, который поддерживается в том числе и в Impala, зарегистрировав витрину в Hive metastore.

              Вроде бы все просто.
              Читать дальше →
            • Применение low-code в аналитических платформах

                Уважаемые читатели, доброго дня!

                Задача построения ИТ-платформ для накопления и анализа данных рано или поздно возникает у любой компании, в основе бизнеса которой лежат интеллектуально нагруженная модель оказания услуг или создание технически сложных продуктов. Построение аналитических платформ — сложная и трудозатратная задача. Однако любую задачу можно упростить. В этой статье я хочу поделиться опытом применения low-code-инструментов, помогающих в создании аналитических решений. Данный опыт был приобретён при реализации ряда проектов направления Big Data Solutions компании «Неофлекс». Направление Big Data Solutions компании «Неофлекс» с 2005 года занимается вопросами построения хранилищ и озёр данных, решает задачи оптимизации скорости обработки информации и работает над методологией управления качеством данных.



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

                Однако в каком случае задачи аналитики данных могут перерасти в задачи класса «Rocket Science»? Пожалуй, в тот момент, когда речь идёт о действительно больших данных.
                Чтобы упростить задачу «Rocket Science», можно есть слона по частям.



                Чем большая дискретность и автономность будет у ваших приложений/сервисов/микросервисов, тем проще вам, вашим коллегам и всему бизнесу будет переваривать слона.

                К этому постулату пришли практически все наши клиенты, перестроив ландшафт, основываясь на инженерных практиках DevOps-команд.
                Читать дальше →
              • Kubernetes на собственной инфраструктуре: «за» и «против» приватных облаков

                  Уважаемые читатели, доброго дня!

                  В данной статье Игорь Котенко, главный архитектор компании «Неофлекс», делится опытом развертывания платформы контейнеризации на инфраструктуре предприятия.
                  Читать дальше →
                • Запускаем Apache Spark на Kubernetes

                    Дорогие читатели, доброго дня. Сегодня поговорим немного про Apache Spark и его перспективы развития.



                    В современном мире Big Data Apache Spark является де факто стандартом при разработке задач пакетной обработки данных. Помимо этого, он также используется для создания стриминговых приложений, работающих в концепции micro batch, обрабатывающих и отгружающих данные маленькими порциями (Spark Structured Streaming). И традиционно он являлся частью общего стека Hadoop, используя в качестве менеджера ресурсов YARN (или, в некоторых случаях, Apache Mesos). К 2020 году его использование в традиционном виде для большинства компаний находится под большим вопросом в виду отсутствия приличных дистрибутивов Hadoop — развитие HDP и CDH остановлено, CDH недостаточно проработан и имеет высокую стоимость, а остальные поставщики Hadoop либо прекратили своё существование, либо имеют туманное будущее. Поэтому всё больший интерес у сообщества и крупных компаний вызывает запуск Apache Spark с помощью Kubernetes — став стандартом в оркестрации контейнеров и управлении ресурсами в приватных и публичных облаках, он решает проблему с неудобным планированием ресурсов задач Spark на YARN и предоставляет стабильно развивающуюся платформу с множеством коммерческих и открытых дистрибутивов для компаний всех размеров и мастей. К тому же на волне популярности большинство уже успело обзавестись парой-тройкой своих инсталляций и нарастить экспертизу в его использовании, что упрощает переезд.

                    Начиная с версии 2.3.0 Apache Spark обзавёлся официальной поддержкой запуска задач в кластере Kubernetes и сегодня, мы поговорим о текущей зрелости данного подхода, различных вариантах его использования и подводных камнях, с которыми предстоит столкнуться при внедрении.
                    Читать дальше →
                  • Data Platform для целей формирования регуляторной отчетности

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

                      Совокупность этих факторов привела к изменению процессов управления данными. Data Platform – подход, который предлагает переосмысление традиционной концепции классического хранилища данных (КХД) с использованием технологий Big Data и новых подходов, применяемых при построении Data Lake платформ. Data Platform позволяет качественно учесть такие важные факторы, как рост количества пользователей, требования к time2customer (обеспечить возможность высокой скорости выполнения изменений), а также стоимость получаемого решения, в том числе, с учётом его дальнейшего масштабирования и развития.
                      Читать дальше →
                    • Business Intelligence по-русски — на квинтетах

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


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




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

                        Читать дальше →
                      • Обучающий курс по DataPower

                        • Tutorial

                        Материал подготовлен в соавторстве с пользователем wedmeed


                        В 2017 году, когда начинался наш проект во Вьетнаме, мы столкнулись с новым для нас зверем IBM DataPower. IBM DataPower – продукт, представляющий собой gateway между клиентами и бэкендами, предназначенный для фильтрации, маршрутизации, обогащения или других преобразований проходящих через него сообщений (далее – запросов). Обучаться нужно было быстро, времени на раскачку не было, поэтому нам было предложено самостоятельно ознакомиться с ним, после чего были многочасовые конференции по скайпу с нашим коллегой из Москвы, который передавал нам свои знания и опыт работы с этим продуктом.


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


                        Стоит также заметить, что приведенная в практике структура будет приближена к реальному проекту, что позволит вам использовать ее как базу, расширяя и дополняя под ваши требования. В заключение к разделам «Теория» будет приведено несколько слов об уже реализованном проекте, а также некоторые особенности, на которые стоит обратить внимание.



                        Читать дальше →
                      • Квинтет как базовая сущность для описания предметной области

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



                        Я расскажу о новом подходе к хранению и обработке информации и поделюсь мыслями о создании платформы разработки в этой новой парадигме.
                        Взглянуть по-новому на известные вещи
                      • Как мы в Neoflex развиваем экспертизу DevOps

                          После выделения DevOps внутри компании «Неофлекс» в отдельное бизнес-направление команда стала активно наращивать экспертизу и делиться найденными источниками знаний друг с другом. В этом посте я поделюсь с вами личным опытом погружения в тему и наиболее интересными ресурсами.




                          Основными источниками информации по теме стали следующие:


                          • Интернет-ресурсы – как независимые, так и компаний разработчиков
                          • Статьи и презентации
                          • Литература
                          • Конференции
                          • Программы обучения – как платные, так и бесплатные
                          Читать дальше →
                        • Как развернуть окружение для разработки приложений на React Native на Windows

                          • Tutorial

                          Доброго времени суток!


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

                          Конечно, на официальном сайте есть подробное описание, но следуя только этим рекомендациям, было довольно сложно сделать все настройки.


                          Читать дальше →
                          • +9
                          • 26,9k
                          • 9
                        • Организация хранения кода в GitLab и интеграция код ревью в GitFlow

                            Не так давно на одном из проектов нашей компании было принято решение наконец отказаться от использования Subversion для хранения и версионирования кода в пользу Git.



                            Основными целями перехода были следующие:


                            • Повышение прозрачности процесса разработки.
                            • Внедрение обязательной процедуры код ревью до выноса обновлений на тестовые среды.
                            • Внедрение непрерывной интеграции для сборки обновлений после код ревью и установки их на тестовые среды.

                            Читать дальше →
                          • Распределенное хранилище данных в концепции Data Lake: администрирование кластера

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



                              Читать дальше →
                            • Continuous design в разработке: методология и принцип

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


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


                                Я думаю, что лучше всего выстраивать коммуникацию с пользователем по принципу continuous design, о котором и пойдет речь в статье.


                                Читать дальше →
                              • Spark SQL. Немного об оптимизаторе запросов

                                  Всем привет. В качестве введения, хочется рассказать, как я дошел до жизни такой.


                                  До того как встретиться с Big Data и Spark, в частности, мне довелось много и часто оптимизировать SQL запросы, сначала для MSSQL, потом для Oracle, и вот теперь я столкнулся со SparkSQL.


                                  И если для СУБД уже существует множество хороших книг, описывающих методологию и «ручки», которые можно покрутить для получения оптимального плана запроса, то для Spark такого рода книг я не встречал. На глаза попадались больше статьи и наборы практик, причем больше относящиеся к работе через RDD/Dataset API, а не чистому SQL. Для меня одной из эталонных книг на тему оптимизации SQL является книга Дж. Льюис «Oracle. Основы стоимостной оптимизации». Что-то подобное по глубине проработки я и искал. Почему предметом исследования стал именно SparkSQL, а не API, лежащий в основе? Тут интерес был вызван особенностями проекта, над которым я работаю.



                                  Читать дальше →
                                • Распределенное хранилище данных в концепции Data Lake: установка CDH

                                    Продолжаем делиться опытом по организации хранилища данных, о котором начали рассказывать в предыдущем посте. На этот раз хотим поговорить о том, как мы решали задачи по установке CDH.



                                    Читать дальше →
                                  • Распределенное хранилище данных в концепции Data Lake: с чего начать

                                      В мире энтерпрайза наступило пресыщение фронтовыми системами, шинами данных и прочими классическими системами, которые внедряли все кому не лень последние 10-15 лет. Но есть один сегмент, который до недавнего времени был в статусе «все хотят, но никто не знает, что это». И это Big Data. Красиво звучит, продвигается топовыми западными компаниями – как не стать лакомым кусочком?



                                      Но пока большинство только смотрит и приценивается, некоторые компании начали активно внедрять решения на базе этого технологического стека в свой IT ландшафт. Важную роль в этом сыграло появление коммерческих дистрибутивов Apache Hadoop, разработчики которых обеспечивают своим клиентам техническую поддержку. Ощутив необходимость в подобном решении, один из наших клиентов принял решение об организации распределенного хранилища данных в концепции Data Lake на базе Apache Hadoop.
                                      Читать дальше →

                                    Самое читаемое