• Как перемещать, выгружать и интегрировать очень большие данные дёшево и быстро? Что такое pushdown-оптимизация?

      Любая операция с большими данными требует больших вычислительных мощностей. Обычное перемещение данных из базы на Hadoop может длиться неделями или стоить, как крыло самолёта. Не хотите ждать и тратиться? Сбалансируйте нагрузку на разные платформы. Один из способов – pushdown-оптимизация.
      Я попросил ведущего в России тренера по разработке и администрированию продуктов Informatica Алексея Ананьева рассказать о функции pushdown-оптимизации в Informatica Big Data Management (BDM). Когда-то учились работать с продуктами Informatica? Скорее всего именно Алексей рассказывал вам азы PowerCenter и объяснял, как строить маппинги.


      Алексей Ананьев, руководитель направления по обучению DIS Group


      Что такое pushdown?


      Многие из вас уже знакомы с Informatica Big Data Management (BDM). Продукт умеет интегрировать большие данные из разных источников, перемещать их между разными системами, обеспечивает к ним лёгкий доступ, позволяет профилировать их и многое другое.
      В умелых руках BDM способен творить чудеса: задачи будут выполняться быстро и с минимальными вычислительными ресурсами.
      Тоже так хотите? Научитесь использовать функцию pushdown в BDM для распределения вычислительной нагрузки между разными платформами. Технология pushdown позволяет превратить маппинг в скрипт и выбрать среду, в которой этот скрипт запуститься. Возможность такого выбора позволяет комбинировать сильные стороны разных платформ и достигать их максимальной производительности.
      Для настройки среды исполнения скрипта нужно выбрать тип pushdown. Скрипт может быть полностью запущен на Hadoop или частично распределен между источником и приемником. Есть 4 возможных типа pushdown. Маппинг можно не превращать в скрипт (native). Маппинг можно исполнить максимально на источнике (source) или полностью на источнике (full). Также маппинг можно превратить в скрипт Hadoop (none).

      Читать дальше →
    • Как загрузить OpenStreetMap в Hive?

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

        Адреса для определенности российские, и главное — зачастую написаны криво, то есть с ошибками, неоднозначностями и прочими прелестями. И находятся эти адреса в базе данных Hive, на кластере Hadoop.


        Ну казалось бы — берем Google Maps Geocoding API (или, если вы сторонник импортозамещения, то Yandex Maps API), и работаем. Но тут нас, как впрочем и c обратным геокодированием, ждет небольшая засада.
        Читать дальше →
      • Как геокодировать миллион точек на Spark по-быстрому?

          В моем предыдущем проекте перед нами встала задача провести обратное геокодирование для множества пар географических координат. Обратное геокодирование — это процедура, которая паре широта-долгота ставит в соответствие адрес или название объекта на карте, к которому принадлежит или близка заданная координатами точка. То есть, берем координаты, скажем такие: @55.7602485,37.6170409, и получаем результат либо «Россия, Центральный федеральный округ, Москва, Театральная площадь, дом такой-то», либо например «Большой театр».

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

          В качестве исходных данных у нас на входе было примерно 100 или 200 тысяч точек, которые лежали в кластере Hadoop в виде таблицы Hive. Это чтобы был понятен масштаб задачи.

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

            Мы – Big Data в МТС и это наш первый пост. Сегодня расскажем о том, какие технологии позволяют нам хранить и обрабатывать большие данные так, чтобы всегда хватало ресурсов для аналитики, и затраты на закупки железа не уходили в заоблачные дали.

            О создании центра Big Data в МТС задумались в 2014 году: появилась необходимость масштабирования классического аналитического хранилища и BI-отчетности над ним. На тот момент движок для обработки данных и BI были SASовские – так сложилось исторически. И хотя потребности бизнеса в хранилище были закрыты, со временем функционал BI и ad-hoc-аналитики поверх аналитического хранилища разросся настолько, что нужно было решать вопрос увеличения производительности, учитывая, что с годами количество пользователей увеличилось в десятки раз и продолжало расти.

            В результате конкурса в МТС появилась MPP-система Teradata, покрывающая потребности телекома на тот момент. Это стало толчком к тому, чтобы попробовать что-то более популярное и open source’вое.

            image

            На фото — команда Big Data МТС в новом офисе «Декарт» в Москве
            Читать дальше →
          • Как мы строим систему обработки, хранения и анализа данных в СИБУРе

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

              Наша цифровизация началась с создания двух центров и соответствующих им функциональных блоков.

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



              И вот как раз главная задача дата-офиса заключается в том, чтобы полноценно внедрить культуру принятия решений, основанных на данных (да, да, data-driven decision), а также в принципе упорядочить всё, что касается работы с данными: аналитика, обработка, хранение и отчетность. Особенность в том, что все наши цифровые инструменты должны будут не только активно использовать собственные данные, то есть те, которые генерируют сами (например, мобильные обходы, или датчики IIoT), но и внешние данные, с четким пониманием, где и зачем их нужно использовать.

              Меня зовут Артем Данилов, я руководитель направления «Инфраструктура и технологии» в СИБУРе, в этом посте я расскажу, как и на чем мы строим большую систему обработки и хранения данных для всего СИБУРа. Для начала поговорим только о верхнеуровневой архитектуре и о том, как можно стать частью нашей команды.
              Читать дальше →
            • Тестирование и отладка MapReduce

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


                Читать дальше →
                • +21
                • 3,7k
                • 6
              • Apache NiFi: что это такое и краткий обзор возможностей

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

                  image

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

                    Мне давно хотелось изложить свои впечатления об Apache Spark, и тут как раз попалась на глаза вот эта статья от сотрудника Pivotal Robert Bennett, опубликованная совсем недавно, 26 июня 2018.

                    Это не будет перевод, а скорее все-таки мои впечатления и комментарии на тему.
                    Читать дальше →
                    • +12
                    • 6,4k
                    • 2
                  • Распределенное хранилище данных в концепции Data Lake: администрирование кластера

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



                      Читать дальше →
                    • Теория и практика использования HBase

                        Добрый день! Меня зовут Данил Липовой, наша команда в Сбертехе начала использовать 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. Выводы
                        Читать дальше →

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