Измените свою позицию и начните работу с большими данными

HBase Hadoop HDFS

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

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

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

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

В этот раз мы не будем заморачиваться конкретными определениями и проигнорируем традиционные учения типа 4 Vs и 6 Cs. Мы даже не хотим говорить об эволюции архитектуры и различных методах настройки. Если вы это понимаете, вы не можете это запомнить, и вы не можете использовать это, если вы это помните.

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

один

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

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

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

два

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

  • Хранение большого количества данных может решить проблему невозможности установки.

  • Расчет большого количества данных решает проблему медленного расчета.

Поэтому основа больших данных состоит из двух частей: хранения и вычислений.

три

Когда мы работаем на одной машине или когда объем данных не такой большой, у нас есть два требования к хранилищу:

  • файловое хранилище

  • хранение в базе данных

Хранение в виде файлов является самым основным требованием, таким как журналы, созданные различными службами, данные, просканированные поисковыми роботами, мультимедийные файлы, такие как изображения и аудио, и так далее. Соответствует самым исходным данным.

Хранилищем в виде базы данных обычно являются данные, которые могут быть непосредственно использованы для бизнес-программного использования после обработки.Например, ip посетителя, ua и другая информация обрабатывается из файла журнала доступа и сохраняется в реляционной базе данных, так что он может отображаться непосредственно на странице с помощью веб-программы. Соответствует данным, которые удобно использовать после обработки.

Большие данные — это только большой объем данных, и эти две потребности совпадают. Хотя это и не обязательно строго, первое можно назвать автономным хранилищем, а второе — онлайн-хранилищем.

Четыре

Автономное хранилище этой HDFS (распределенной файловой системы Hadoop) в основном является стандартом де-факто. Как видно из названия, это распределенная файловая система. На самом деле «распределение» также является общим методом решения проблем с большими данными: только распределенная система, поддерживающая бесконечное горизонтальное расширение, теоретически может решить проблему, вызванную бесконечно растущим объемом данных. Конечно, бесконечность здесь надо брать в кавычки.

Это простая диаграмма архитектуры HDFS, она все равно выглядит неинтуитивно, но суть всего в нескольких предложениях:

  • Файлы разбиты на блоки и хранятся на разных серверах, причем каждый блок дублируется на разных машинах.

  • Есть две роли, NameNode и DataNode, первая хранит метаданные, то есть где хранится каждый блок, а вторая отвечает за хранение фактических данных.

  • Для чтения и записи данных необходимо сначала получить метаданные соответствующего файла из NameNode, а затем найти соответствующий DataNode для получения фактических данных.

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

Для того, чтобы обеспечить высокую доступность данных, например, если сервер вдруг сломается и не сможет снова встать, HDFS решает эту проблему за счет избыточности (обычно 3 копии). Это также наиболее часто используемый метод обеспечения высокой доступности в распределенных системах, хотя его стоимость может быть высокой.

Высокая доступность имеет смысл только на системном уровне, поэтому, помимо высокой доступности данных, также важна высокая доступность метаданных. Идея та же — резервное копирование. HDFS предоставляет Secondary NameNode для обеспечения избыточности метаданных. Конечно, лучший способ — использовать NameNode HA для обеспечения непрерывного чтения и записи метаданных через активную/резервную группу NameNodes.

Точно так же масштабируемость рассматривала только горизонтальное расширение данных, а как насчет метаданных? Когда объем данных достигает определенного уровня, метаданные также будут очень большими, подобно проблеме расширения индекса, с которой мы сталкиваемся в традиционных реляционных базах данных. Решением является федерация NameNode. Проще говоря, исходная группа активных/резервных NameNodes разделена на несколько групп, каждая группа управляет только частью метаданных. После разделения он предоставляет услуги внешнему миру в целом методом, аналогичным тому, как мы монтируем жесткие диски в системах Linux. Эти группы NameNode независимы друг от друга.HDFS версии 2.x реализует настройку нескольких групп на клиенте посредством абстракции ViewFS. Прозрачный доступ к NameNode, версия HDFS 3.x реализует новую федерацию маршрутизаторов для обеспечения прозрачного доступа к нескольким группам NameNode на стороне сервера.

Можно видеть, что горизонтальное расширение метаданных точно такое же, как горизонтальное расширение фактических данных, которые разделены и распределены.

пять

Автономному хранилищу соответствует онлайн-хранилище, которое можно понять, обратившись к традиционным базам данных, таким как MySQL и Oracle. Наиболее часто в сфере больших данных используется HBase.

Существует множество стандартов классификации данных, и HBase можно классифицировать как базу данных NoSQL, столбцовую базу данных, распределенную базу данных и т. д.

Она называется базой данных NoSQL, потому что HBase не предоставляет многих функций традиционных реляционных баз данных. Например, не поддерживает чтение и запись данных в виде SQL, хотя сторонние решения, такие как Apache Phoenix, можно интегрировать, но ведь нативно он не поддерживается; Secondary Index не поддерживается, устроен только rowkey in sequence используется в качестве первичного ключа, хотя встроенным сопроцессором этого можно добиться.Сторонний Apache Phoenix также предоставляет функцию создания вторичных индексов с операторами SQL, но ведь она нативно не поддерживается; не так структурирован и детерминирован, и предоставляет только семейства столбцов для классификации столбцов и управления ими.Нет ограничений на количество и тип столбцов, которые полностью определяются при записи данных, и даже общее количество столбцов может быть определено только путем полного сканирования таблицы. С этой точки зрения HBase Даже не база данных, а скорее хранилище данных.

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

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

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

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

Эта схема архитектуры достаточно проста для выхода в интернет, перечислим несколько ключевых моментов:

  • На каждом узле есть программа RegionServer для предоставления услуг чтения и записи данных.

  • Каждая таблица делится на множество регионов, а затем равномерно распределяется по каждому серверу регионов.

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

Легко заметить, что распределение HBase очень похоже на HDFS, RegionServer — на DataNode, HMaster — на NameNode, а Region — на Block.

Пока DataNode расширяется на уровне HDFS, а RegionServer расширяется на уровне HBase, легко реализовать горизонтальное расширение HBase для удовлетворения требований чтения и записи большего количества данных.

Внимательные люди должны были заметить, что метаданные не отражаются на картинке. Метаданные в HDFS контролируются NameNode, аналогично метаданные в HBase контролируются HMaster. Метаданные в HBase хранят, какие регионы есть в таблице и какой RegionServer предоставляет услуги.

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

Поскольку метаданные HBase используют регион в качестве степени детализации, которая намного больше, чем степень детализации блоков в HDFS, объем данных метаданных, как правило, не станет узким местом производительности, и нет необходимости учитывать горизонтальное расширение метаданных.

Что касается высокой доступности, уровень хранения уже гарантирован HDFS, а уровень обслуживания должен предоставить несколько HMasters в качестве основного и резервного.

шесть

Тема хранения здесь. Давайте посмотрим на расчет.

Как и в случае с хранилищем, независимо от размера данных, мы можем разделить вычисления на два типа:

  • Автономные вычисления или пакетные вычисления/обработка

  • Онлайн-вычисления или вычисления в реальном времени, потоковые вычисления/обработка

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

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

Задержка расчета партии, как правило, велика, в минутах, часах или даже днях. Потоковая обработка обычно требует, чтобы обработка данных выполнялась за миллисекунды или секунды. Стоит отметить, что между ними есть термин для вычислений в квазиреальном времени, с задержками обычно в пределах от секунд до десятков секунд. Вычисления в квазиреальном времени вполне возможны для достижения приемлемого баланса между задержкой и объемом обрабатываемых данных.

Семь

Самым старым пакетным вычислением в области больших данных является MapReduce. MapReduce и вышеупомянутая HDFS вместе составляют Hadoop. А Hadoop на протяжении многих лет был де-факто стандартной инфраструктурой для больших данных. С этого момента также видно, что это также самый простой способ классификации технологий больших данных в зависимости от хранения и вычислений.

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

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

Взяв в качестве примера "Hello World" -- "Word Count" в области больших данных, чтобы рассчитать количество вхождений каждого слова в 10 T данных в 100 файлах, на этапе карты может быть 100 картографов, которые можно выделить. себя параллельно Полученные данные сегментируются, а затем одно и то же слово «перетасовывается» в один и тот же редуктор для агрегации и суммирования.Эти редьюсеры также выполняются параллельно и, наконец, выводят свои соответствующие результаты выполнения независимо, что вместе является окончательным полным результат.

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

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

8

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

Координация ресурсов

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

Ранний MapReduce, то есть MR1, полностью реализовывал эти функции. Центральная и унифицированная координирующая роль называется JobTracker. Кроме того, на каждом узле будет TaskTracker, отвечающий за сбор данных об использовании локальных ресурсов и отправку отчетов в JobTracker в качестве основы. для распределения ресурсов.

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

Итак, MapReduce второго поколения после рефакторинга — MR2, и у него новое имя YARN (Yet-Another-Resource-Negotiator).

Две основные функции JobTracker — управление ресурсами и планирование/мониторинг задач — разделены и выполняются ResourceManager и ApplicationMaster соответственно. ResouerceManager в основном отвечает за распределение вычислительных ресурсов (на самом деле, он также включает в себя инициализацию и мониторинг ApplicationMaster), работа становится очень простой, уже не так просто стать узким местом, и легко добиться высокой доступности после развертывания нескольких экземпляры. ApplicationMaster назначается каждому приложению, и все приложения ресурсов заданий, планирование выполнения, мониторинг состояния, повторный запуск и т. д. организуются им. Таким образом, самая тяжелая работа распределяется между Когда AM ушел, узкое место не существует.

Затраты на разработку

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

Естественная идея состоит в том, чтобы использовать SQL.Боюсь, что для базовой обработки данных нет более общего языка, чем SQL.

В первые дни существовало в основном две реализации фреймворка для SQLизации MapReduce. Один из них — Apache Pig, а другой — Apache Hive. Первый является относительно нишевым, а второй — выбором большинства компаний.

Основная функция, реализованная Hive, заключается в том, чтобы интерпретировать ваши операторы SQL в задачи MapReduce для выполнения.

Например, создадим сейчас такую ​​тестовую таблицу:

create table test2018(id int, name string, province string);

Затем запустите команду объяснения, чтобы просмотреть план выполнения следующего оператора select:

explain select province, count(*) from test2018 group by province;

Как видите, Hive только что анализирует оператор SQL в задачу MapReduce. Этот SQL очень прост.Если это сложный SQL, он может быть разобран на множество задач MapReduce, которые выполняются непрерывно в зависимости от выполнения.

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

скорость расчета

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

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

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

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

модель программирования

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

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

В Spark это сделает всего одно предложение ds.groupby(key).avg(). По сравнению с этим действительно нет никакого вреда.

Девять

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

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

Здесь мы кратко рассмотрим три самых популярных фреймворка для потоковой обработки: Spark Streaming, Storm и Flink.

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

  • парадигма программирования

Вообще говоря, парадигмы программирования или, говоря простым языком, то, как пишутся программы, можно разделить на две категории: императивные и декларативные. Первому нужно четко написать «как делать» шаг за шагом, что ближе к машине, а второму нужно написать только «что делать», что ближе к человеку. В упомянутом выше примере WordCount версия MapReduce является императивной, а версия Spark — декларативной.

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

  • задержка

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

  • пропускная способность

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

Давайте взглянем на эти три фреймворка потоковой обработки с точки зрения этих измерений.

Spark Streaming

Spark Streaming и Spark, о которых мы упоминали ранее для пакетной обработки в автономном режиме, основаны на одном и том же вычислительном движке, который по сути является так называемым mirco-batch, но для этого пакета можно установить небольшой размер, и он работает почти в реальном времени. эффект.

  • парадигма программирования

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

  • Задерживать

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

Поскольку это потоковая обработка, основанная на пакетной обработке, определено, что независимо от того, как настроена задержка Spark Streaming, она не может соответствовать требованиям некоторых сценариев. Чтобы решить эту проблему, еще не выпущенный официально Spark 2.3 будет поддерживать непрерывную обработку, обеспечивая задержку не уступающую нативной потоковой передаче. Как следует из названия, непрерывная обработка отказывается от псевдопотоковой обработки mirco-batch и использует ту же длительную задачу, что и собственная потоковая обработка для обработки данных. В это время пользователям будет разрешено самостоятельно выбирать способ конфигурации Микропакетная или непрерывная обработка для потоковой передачи.

 

  • пропускная способность

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

Storm

Модель программирования Storm чем-то похожа на MapReduce, определяя Spout для обработки ввода и Bolt для обработки логики. Несколько носиков и болтов соединены друг с другом и зависят друг от друга, образуя топологию. И Spout, и Bolt должны определить некоторые классы и реализовать определенные методы, такие как MR.

  • парадигма программирования

Очевидно, что это необходимо.

  • Задерживать

Storm — это строго система обработки в реальном времени (собственная потоковая передача), которая обрабатывает один фрагмент данных, поэтому задержка очень мала, обычно на уровне миллисекунд.

  • пропускная способность

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

Необходимо добавить, что обновленная версия STORM Trident внесла очень большое изменение, используя режим mirco-Batch, аналогичный Spark Street, поэтому задержка выше, чем у Storm (варьируется), пропускная способность выше, чем у Storm (становится ) И парадигма программирования также стала более низкой стоимостью разработки.

Flink

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

  • парадигма программирования

Типичный декларативный.

  • Задерживать

Как и Storm, Flink также обрабатывает один за другим, обеспечивая низкую задержку.

  • пропускная способность

В системах обработки в реальном времени низкая задержка часто приводит к низкой пропускной способности (Storm), а высокая пропускная способность приводит к высокой задержке (Spark Streaming). Эти два показателя эффективности также являются общими компромиссами, и компромиссы обычно требуются.

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

десять

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

Тем не менее, есть некоторые ситуации, которые заставляют нас внедрять решения для пакетной и потоковой обработки в одном и том же бизнесе:

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

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

  • ...

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

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

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

Поэтому в последние годы также была предложена Kappa Architecture, несущая другую единую идею, но и имеющая очевидные недостатки. Из-за ограничений по объему мы не будем их здесь повторять.

11

Вычислительный фреймворк — одно из самых конкурентоспособных направлений в сфере больших данных, помимо вышеперечисленных решений есть Impla, Tez, Presto, Samza и др. Многим компаниям нравится создавать колеса и заявлять, что их колеса лучше других. С точки зрения процесса разработки каждого фреймворка есть четкий смысл учиться друг у друга.

Среди множества вариантов амбиции и возможности Spark как универсальной распределенной вычислительной среды были полностью продемонстрированы и проверены и все еще быстро развиваются: Spark SQL поддерживает обработку данных чистого SQL, подобную Hive, а Spark Streaming поддерживает вычисления в реальном времени. Spark MLlib поддерживает машинное обучение, а Spark GraphX ​​— графовые вычисления. Унификация базовых механизмов выполнения для потоковой и пакетной обработки также снижает затраты на разработку и обслуживание Spark в рамках архитектуры Lambda до приемлемого уровня.

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

двенадцать

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

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

Категории