«Вопросы для собеседования по большим данным» V3.0》, на этот раз я не только собрал детали, которые собрал ранее, но и разместил на Niuke опыт, которым поделились другие. Теперь я сделал предварительный обзор. итог。

Следующие несколько вопросов являются наиболее часто задаваемыми среди всех интервью (их касаются только интервью Niuke по разработке больших данных). В некоторых компаниях вопросы даже повторяются в одном или двух интервью (например, Meituan~).

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

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

Я тоже очень невиновен. Я не просто собираю (сканирую) лицевые писания? Обязательно ли со мной так обращаться~ Тем не менее, набор видеороликов, которые я смотрел ранее, действительно хорош. Я поделюсь им с вами, когда придет время. Версия 2020 года преподается двумя забавными докторами Цинхуа (стиль Дэюньше). Теперь я тоже выпустил новую версию. недавно смотрел новую версию Directory, там есть небольшая демонстрация (сканирование комментариев Ююня), которую можно изменить, чтобы сделать дизайн для выпускного. В будущем я подумаю, смогу ли я визуализировать демо, обработать данные, а затем рассмотреть возможность хранения данных в тегах и обработки данных в автономном режиме (Spark SQL). Конечно, я также могу рассмотреть возможность использования режима реального времени (Spark или Flink). оба являются приемлемыми).

Конечно, это отступление от сегодняшней темы, перейдем к делу.

Hadoop

1. Процесс записи и чтения файлов HDFS

Могу ответить гибко：

1) Принцип чтения и записи HDFS (процесс)

2) Процесс загрузки и скачивания HDFS

3) Поговорим о (введение) HDFS

4) Механизм хранения HDFS

Я спросил некоторые компании：Али×3,Социальный рекрутинг Alibaba,Тенсент х2,Байты х2,Байду,Пиндуодуо x2,Китовое облако,Просо,Люлишо,СФ Экспресс,Облачная музыка NetEase×2,Лайки×2,Зулун Развлечения,360×2,SenseTime,Сеть CMB,Убежденный,TOEIC,Дахуа,быстрый работник,Телекоммуникационные облачные вычисления,повернись,Мейтуань x4,shopee×2: Чем подробнее ответ, тем лучше,Юаньфудао×2,iFlytek,Ханг Сен Электроникс,Соху,Цзиндун,заголовки,Футу

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

Выбор узла реплики Hadoop3.x:

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

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

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

Что касается процесса чтения и записи HDFS, вот две версии, которые помогут понять. Первая версия: краткая версия

Процесс записи данных HDFS

1) Клиент запрашивает NameNode для загрузки файлов через модуль Distributed FileSystem. NameNode проверяет, существует ли уже целевой файл и существует ли родительский каталог.

2) NameNode возвращает, можно ли его загрузить.

3) На какие серверы datanode клиент запрашивает загрузку первого блока?

4) NameNode возвращает 3 узла данных, а именно dn1, dn2 и dn3.

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

6) dn1, dn2 и dn3 отвечают клиенту шаг за шагом.

7) Клиент начинает загружать первый блок в dn1 (сначала считывать данные с диска и помещать их в кэш локальной памяти). В пакетах, когда dn1 получит пакет, он будет передан dn2, а dn2 будет). передается dn3; dn1 каждый раз передает его dn2. Передаваемый пакет будет помещен в очередь ответа, ожидающую ответа.

8) Когда передача блока завершена, клиент снова запрашивает NameNode загрузить второй блок на сервер. (Повторите шаги 3–7).

Процесс чтения данных HDFS

1) Клиент запрашивает NameNode загрузить файл через Распределенную файловую систему, а NameNode находит адрес DataNode, где расположен файловый блок, путем запроса метаданных.

2) Выберите сервер DataNode (принцип близости, затем случайный) и запросите чтение данных.

3) DataNode начинает передавать данные клиенту (читает входной поток данных с диска и выполняет проверку пакетами).

4) Клиент получает пакеты порциями, сначала кэширует их локально, а затем записывает в целевой файл.

Вторая версия: Подробная версия, полезная для понимания.

Процесс записи данных HDFS

1) Клиент делит FileA на блоки по 128M. Разделен на два блока: блок1 и блок2;

2) Клиент отправляет запрос на запись данных в nameNode.,Как показано синим пунктиром①------>。

3) Узел NameNode,Запишите информацию о блоке. и вернуть доступный изDataNode,как розовый пунктир②--------->。

Block1: host2,host1,host6

Block2: host7,host3,host4

4) Клиент отправляет блок 1 в DataNode; процесс отправки — потоковая запись.

Процесс записи потокового видео:

(1) Разделите блок 1 64M на пакеты по 64k;

(2) Затем отправьте первый пакет на хост2;

(3) После того, как хост2 получает его, он отправляет первый пакет на хост1, и в то же время клиент хочет отправить второй пакет на хост2;

(4) После того, как хост1 получает первый пакет, он отправляет его на хост6 и одновременно получает второй пакет от хоста2.

(5) И так далее, как показано сплошной красной линией на рисунке, пока не будет отправлен блок 1.

(6) Хост2, хост1 и хост6 отправляют уведомления NameNode, а хост2 — Клиенту, сообщая, что «сообщение отправлено». Как показано на рисунке розовой сплошной линией.

(7) После получения сообщения от хоста2 клиент отправляет на namenode сообщение о том, что я закончил писать. Вот и все. Как показано на рисунке толстой желтой сплошной линией.

(8) После отправки блока 1 отправьте блок 2 на хосты 7, хосты 3 и хосты 4, как показано синей сплошной линией на рисунке.

(9) После отправки блока2 хост7, хост3 и хост4 отправляют уведомления в NameNode, а хост7 отправляет уведомления Клиенту, как показано светло-зеленой сплошной линией на рисунке.

(10) Клиент отправляет в NameNode сообщение о том, что я закончил писать, как показано толстой желтой сплошной линией на рисунке. . . Вот и все.

Процесс чтения данных HDFS

1) Клиент отправляет запрос на чтение на namenode.

2) Namenode проверяет информацию метаданных и возвращает местоположение блока fileA.

block1：host2,host1,host6

block2：host7,host3,host4

3) Позиции блоков в порядке. Сначала прочитайте блок 1, затем блок 2. И блок 1 отправляется на хост 2 для чтения, затем блок 2 переходит на хост 7 для чтения;

2. Принцип работы MapReduce

Гибкий ответ:

1) Процесс выполнения MapReduce

2) Понимание MapReduce

3) Процесс MapReduce

4) Подробный процесс MapReduce

5) Механизм работы MapTask и ReducTask

6) Участвует ли в MapReduce сортировка?

Я спросил некоторые компании：（Мейтуанлюбимый）Мейтуан×15,Али×3,Байты × 6,заголовки,Диди,Байду,Тенцент×4,Shopee,Просо,iQiyi,Зулун Развлечения,360×5,SenseTime,NetEase×5,51×2,Технология звездного кольца,Сеть CMB,Инке Live,Байты × 2,Нравиться,58×3,Хуавей х2,Технология Чуанлу,ми Хо Йо,быстрый работник,Цзиндун×3,Тренд Микро,Хиквидение,СФ Экспресс,хорошее будущее,Немного информации,Коронная группа скачет,Центр кредитных карт CITIC,Цзиньшань Облако,ми Хо Йо,Туниу

1) Подготовьте файл размером 200 МБ и нарежьте исходные данные при отправке;

2) Клиент отправляет информацию в YARN, и YARN запускает MrAppmaster. MrAppmaster считывает информацию, соответствующую клиенту, в основном job.split, а затем запускает соответствующее количество MapTasks (2) в соответствии с количеством срезов (здесь 2). ;

3) MapTask считывает данные через InputFormat (по умолчанию читается по строкам), K — это смещение, а V — содержимое строки. После считывания данных они передаются в Mapper, а затем данные обрабатываются в соответствии с ними. потребностям бизнеса пользователя;

4) После обработки данных данные выводятся в кольцевой буфер (по умолчанию 100M). Одна сторона кольцевого буфера хранит данные, а другая сторона хранит индексы (метаданные, описывающие данные). После того, как кольцевой буфер достигает 80% хранимых данных, выполняется обратное переполнение, а данные секционируются и сортируются;

5) Затем объединяем и сортируем размеченные и упорядоченные файлы в зоне, а затем сохраняем их на диске;

6) Когда все задачи MapTask будут выполнены, запустите соответствующее количество Редуц-Таск и укажите, что Редуц-Таск должен обработать диапазон данных (раздел данных). Примечание. Перед запуском не обязательно дожидаться завершения всех MapTask. Вы можете настроить это самостоятельно.

7) После включения Редуц Таск Редуц Таск активно извлекает данные из раздела, соответствующего MapTask;

8) Затем выполните глобальное слияние и сортировку данных, полученных с помощью Редуктор Таск;

9) Читать данные последовательно и разделять их по ключу. Данные с одним и тем же ключом поступают в один и тот же Редюсер и считывают по одному набору данных за раз;

10) После того, как Редуктор обработает данные, он записывает данные через OutPutFormat, чтобы сформировать соответствующий файл.

Краткая версия: интервью можно писать от руки

Zookeeper

Механизм выборов смотрителя зоопарка

Гибкий ответ:

1) Стратегия выборов смотрителя зоопарка

2) Процесс выборов смотрителя зоопарка

3) Как осуществляются выборы лидера Zookeeper?

Я спросил некоторые компании：Али,Байты х2,Тенсент,оболочка,NetEase,куда пойти

1) Полумеханизм: более половины машин в кластере выживают и кластер доступен. Поэтому Zookeeper подходит для установки нечетного количества серверов.

2) Хотя Zookeeper не указывает в файле конфигурации Master и Slave. Однако, когда Zookeeper работает, один узел является лидером, а остальные — последователями. Лидер временно генерируется с помощью внутреннего механизма выборов.

3) Избирательный процесс

Предположим, есть кластер Zookeeper, состоящий из пяти серверов. Их идентификаторы варьируются от 1 до 5. При этом все они запущены заново, то есть исторических данных нет. Объем хранимых данных одинаковый. Давайте посмотрим, что произойдет, если эти серверы запустить последовательно.

(1) Сервер 1 запускается и инициирует выборы. Сервер 1 голосует. В это время сервер 1 имеет один голос, которого не хватает более чем на половину (3 голоса), выборы не могут быть завершены, а статус сервера 1 остается ИЩЕТ;

(2) Сервер 2 запускается и инициирует новые выборы. Серверы 1 и 2 голосуют каждый за себя и обмениваются информацией о голосовании: в это время сервер 1 обнаруживает, что идентификатор сервера 2 больше, чем тот, за который он в данный момент голосует (сервер 1), и меняет голосование, чтобы рекомендовать сервер 2. В это время у сервера 1 0 голосов, у сервера 2 2 голоса, а результатов осталось не более половины. Выборы не могут быть завершены, а статус серверов 1 и 2 остается ИЩЕТ.

(3) Сервер 3 запускается и инициирует выборы. В это время оба сервера 1 и 2 изменят голоса на сервер 3. Результаты этого голосования: Сервер 1 имеет 0 голосов, Сервер 2 имеет 0 голосов и Сервер 3 имеет 3 голоса. В это время сервер 3 имеет более половины голосов, и сервер 3 избирается лидером. Серверы 1 и 2 меняют статус на СЛЕДУЮЩИЙ, а сервер 3 меняет статус на ВЕДУЩИЙ;

(4) Сервер 4 запускается и инициирует выборы. В настоящее время серверы 1, 2 и 3 больше не находятся в состоянии ПРОСМОТР и не будут менять информацию для голосования. Результат обмена информацией о голосовании: Сервер 3 имеет 3 голоса, а Сервер 4 имеет 1 голос. В это время сервер 4 подчиняется большинству, меняет информацию о голосовании на сервер 3 и меняет статус на СЛЕДУЮЩИЙ;

(5) Сервер 5 запускается и действует как младший брат, как и сервер 4.

Hive

Разница между внутренними и внешними таблицами Hive

Я спросил некоторые компании：байт,Социальный рекрутинг Alibaba,быстрый работник,Мейтуань x2,Могуджие x2,Зулун Развлечения,Помощь с домашним заданием x2,360,Просо,конкурентный мир,Юаньфудао,Коронная группа скачет,хорошее будущее,Футу

Внутренняя таблица (управляемая таблица): не изменяется внешней

Внешняя таблица: изменена внешней

разница:

1) Данные внутренней таблицы управляются самим Hive, а данные внешней таблицы — HDFS;

2) Место хранения данных внутренней таблицы — hive.metastore.warehouse.dir (по умолчанию: /user/hive/warehouse). Место хранения данных внешней таблицы определяется вами (если LOCATION отсутствует, Hive будет находиться в нем). /user/ в HDFS Создайте папку с именем внешней таблицы в папке hive/warehouse и сохраните здесь данные, принадлежащие этой таблице);

3) Удаление внутренней таблицы приведет к непосредственному удалению метаданных и сохраненных данных. При удалении внешней таблицы будут удалены только метаданные, а файлы в HDFS не будут удалены;

4) Изменения внутренней таблицы напрямую синхронизируют изменения метаданных, а изменения структуры таблицы и разделов внешней таблицы требуют ремонта (MSCK REPAIR TABLE имя_таблицы;)

Flume

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

Гибкий ответ:

1) Какие типы источников, каналов и приемников используются в Flume?

2) Дымоход израковина Кафки

3) Каковы части Flume?

4) Тип канала

Я спросил некоторые компании：Алиx2,Тенсент,байт,быстрый работникx2,Люлишо,Технология Чуанлу,Юсинь Технология,Юаньфудао,повернись,bigo,TOEIC,Футуx2

Структура состава Flume показана ниже.

Agent

Агент — это процесс JVM, который отправляет данные от источника к месту назначения в виде событий.

Агент в основном состоит из трех частей: источника, канала и приемника.

Source

Источник — компонент, отвечающий за получение данных в Flume Agent.

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

Sink Sink постоянно опрашивает события в Channel и удаляет их пакетами, а также пакетно записывает эти события в систему хранения или индексации или отправляет в другой Flume. Agent。

Kafka

Как Kafka достигает высокой пропускной способности

Гибкий ответ:

1) Почему Kafka имеет низкую задержку и высокую пропускную способность?

2) Причины высокой пропускной способности Kafka

3) Почему Kafka имеет высокую доступность и высокую пропускную способность?

4) Как Kafka обеспечивает высокую пропускную способность?

Я спросил некоторые компании：Могуджие x2,Тенсент,Мейтуань x2,Юаньфудао,повернись,Xpeng Моторс,Цзиндун,байт,NetEase

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

Kafka в основном использует следующие методы для достижения сверхвысокой пропускной способности.

1) Последовательное чтение и запись.

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

Кафка официально приводит данные испытаний (Рейд-5, 7200 об/мин):

Последовательный ввод-вывод: 600 МБ/с.

Случайный ввод-вывод: 100 КБ/с.

2) Нулевая копия

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

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

Внутри операционной системы весь процесс выглядит следующим образом:

После ядра Linux 2.2 появился механизм системного вызова под названием «нулевое копирование», который пропускает копирование «буфера пользователя» и устанавливает прямое сопоставление дискового пространства и памяти. Данные больше не копируются в «буфер пользовательского режима».

Переключение системного контекста сокращается в 2 раза, что позволяет удвоить производительность.

3) Сегментация файлов Тема очереди Kafka разделена на несколько разделов, и каждый раздел разделен на несколько сегментов, поэтому сообщения в очереди фактически хранятся в N файлах с несколькими сегментами.

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

4) Отправлять партиями

Kafka позволяет отправлять сообщения пакетами. Сообщения сначала кэшируются в памяти, а затем отправляются пакетами с одним запросом. Например, вы можете указать, что кэшированные сообщения будут отправляться, когда они достигнут определенного количества, или они будут отправлены. отправляться после того, как они были кэшированы в течение фиксированного времени, например, отправлять каждые 100 сообщений или отправлять каждые 5 секунд. Эта стратегия значительно сократит количество операций ввода-вывода на сервере.

5) Сжатие данных

Kafka также поддерживает сжатие коллекций сообщений. Producer может сжимать коллекции сообщений в формате GZIP или Snappy. Преимущество сжатия заключается в уменьшении объема передаваемых данных и уменьшении нагрузки на передачу по сети. После сжатия Producer их необходимо распаковать. Потребительский. Хотя это увеличивает рабочую нагрузку на ЦП, но когда дело доходит до обработки больших данных, узким местом является сеть, а не ЦП, поэтому затраты того стоят.

HBase

Принципы проектирования клавиш HBase

Гибкий ответ:

1) Как HBase разрабатывает ключ строки?

2) Почему ваша клавиша строки HBase спроектирована именно так? Каковы плюсы и минусы?

3) Обратите внимание на настройку Hbase rowKey.

Я спросил некоторые компании：Алиx3,Тенсент х2,Мейтуань x3,СФ Экспресс,360,Просоx4,Футу,могуджие,Момокс2,Мейтуан,Коронная группа скачет,Cтрип x2,vivo

В HBase таблица будет разделена на 1...n регионов и размещена на RegionServer. Два важных атрибута региона: StartKey и EndKey представляют диапазон rowKey, поддерживаемый этим регионом. Когда мы хотим читать/записывать данные, если rowKey попадает в определенный диапазон начальных ключей, тогда целевой регион будет найден и прочитан/прочитан. write Напишите соответствующие данные.

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

Принципы проектирования следующие:

1. Принцип длины Роуки

Rowkey — это поток двоичного кода. Многие разработчики предполагают, что длина Rowkey должна быть от 10 до 100 байт. Однако рекомендуется, чтобы чем короче, тем лучше, но не превышало 16 байт.

Вот почему:

1) Файл сохранения данных HFile сохраняется в соответствии со значением ключа. Если ключ строки слишком длинный, например 100 байт, один ключ строки для 10 миллионов столбцов данных будет занимать 100 * 10 миллионов = 1 миллиард байт, что составляет почти 1 ГБ. данных Это сильно повлияет на эффективность хранения HFile;

2) MemStore кэширует некоторые данные в памяти. Если поле Rowkey слишком длинное, эффективное использование памяти будет уменьшено, и система не сможет кэшировать больше данных, что снизит эффективность поиска. Следовательно, чем короче длина Rowkey в байтах, тем лучше;

3) Все текущие операционные системы являются 64-битными, а память выровнена по 8 байтам. Управляемые 16 байтами целые числа, кратные 8 байтам, используют лучшие возможности операционной системы.

2. Принцип хеширования Роуки

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

3. Уникальный принцип Роуки

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

Spark

Проблема неравномерности данных Spark + решение

Я спросил некоторые компании：байтбитьx8,Информация о Аньхэне,СФ Экспресс,Тенсент,NetEaseоблачная музыкаx2,Просо,Зулун Развлечения,SenseTime,Али,ми Хо Йо,быстрый работник,Байду Социальный рекрутинг,Тач Пал,TOEIC,оболочка,ebayx2,Цзиндун,Цзяюньданные

1. Перекос данных

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

Искажение данных имеет два основных прямых и фатальных последствия.

1) Перекос данных напрямую приведет к ситуации: Недостаточно памяти.

2) Медленный бег

В основном происходит на этапе «Перетасовка». Для одного и того же ключа слишком много элементов данных. В результате объем данных Задачи, в которых находится определенный ключ (8 миллиардов на рисунке ниже), оказывается слишком большим. Значительно превышает объем данных, обрабатываемых другими задачами

Эмпирический вывод таков: в целом причина ООМ — перекос данных.

2. Как обнаружить неточности в данных

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

Просмотр задач->ПроверятьStage->Проверять代码

Вы также можете рассмотреть следующие ситуации:

1) Есть ли ситуация OOM? Обычно это небольшое количество проблем с переполнением памяти.

2) Время работы приложения сильно отличается и общее время очень велико?

3) Вам необходимо понимать распределение ключей данных, которые вы обрабатываете. Если некоторые ключи имеют большое количество записей, вы должны быть осторожны с неравномерностью данных.

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

5) Проверьте, есть ли в коде операторы, вызывающие Shuffle.

3. Несколько типичных ситуаций перекоса данных

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

3.2. Различные ключи в наборе данных приводят к искажению данных из-за методов секционирования.

3.3 При операции JOIN данные в одном наборе данных распределяются неравномерно, а другой набор данных меньше (в основном)

3.4 Во время операции агрегирования данные в наборе данных распределяются неравномерно (в основном)

3.5 В операции JOIN оба набора данных относительно велики, а распределение данных лишь нескольких ключей неравномерно.

3.6 В операции JOIN оба набора данных относительно велики, и имеется множество ключей с неравномерным распределением данных.

3.7 Некоторые ключи в наборе данных содержат большой объем данных и не важны, тогда как другие данные четны.

4. Как бороться с неточностью данных

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

Решение. Избегайте перекоса данных в источниках данных.

Принцип реализации：проходитьсуществоватьHiveЦентр для наклонаизданныеруководить预处理,И старайтесь распределять его равномерно при распространении данных Кафки. Это решение фундаментально устраняет неравномерность данных.,Полностью позволяет избежать выполнения операторов перемешивания в Spark.,Тогда точно не будет проблемы с перекосом данных.

Преимущества решения：Просто и удобно реализовать,Эффект очень хороший,Полностью исключает искажение данных,Производительность работы Spark будет значительно улучшена.

Недостатки решения：Борьба с симптомами, а не с первопричиной,Рассогласование данных по-прежнему будет происходить в Hive или Kafka.

Применимые ситуации：существовать НекоторыйJavaСистема иSparkИспользуется совместно сиз В проекте,Будут сценарии, в которых код Java часто вызывает задания Spark.,Более того, производительность выполнения заданий Spark очень требовательна.,Более целесообразно использовать это решение。将данные倾斜提前到上游изHive ETL выполняется только один раз в день, и только этот раз относительно медленно. После этого каждый раз, когда Java вызывает задание Spark, скорость выполнения будет очень высокой, что может обеспечить лучшее взаимодействие с пользователем.

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

4.2. Различные ключи в наборе данных приводят к искажению данных из-за методов секционирования.

Решение 1. Отрегулируйте параллелизм

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

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

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

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

Решение 2:

Пользовательский разделитель (устранение искажения данных)

Применимые сценарии：Много разныхизKeyназначен к тому жеизTaskвызываяTaskданные量过大。

решение： Используйте собственный класс реализации Partitioner вместо HashPartitioner по умолчанию и постарайтесь равномерно распределить все разные ключи по разным задачам.

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

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

4.3 При операции JOIN данные в одном наборе данных распределяются неравномерно, а другой набор данных меньше (в основном)

Решение:

Уменьшите изменения стороны соединения на стороне карты.

Применимые сценарии：существоватьверноRDDиспользоватьjoinОперации класса,или естьсуществоватьSpark Если в SQL используется оператор соединения, а объем данных в RDD или таблице в операции соединения относительно невелик (например, несколько сотен М), это решение является более подходящим.

Принцип реализации：обычноизjoinДа, могу ходитьshuffleпроцессиз,И однажды перетасовать,Это эквивалентно преобразованию того же самогоkeyизданные拉取到一个shuffle read Соединение выполняется снова в задаче, которая в данный момент сокращается. присоединиться. Но если RDD относительно небольшой, вы можете использовать широковещательную рассылку всех данных небольшого оператора RDD + Map, чтобы добиться того же эффекта, что и соединение, то есть Map соединения, в этот момент не будет выполняться операция перемешивания и не произойдет искажения данных.

преимущество：верноjoinрезультат операцииизданные倾斜,Эффект очень хороший,Потому что тасования вообще не произойдет,Никакого искажения данных не будет.

недостаток：Применимые графиков меньше, поскольку это решение применимо только к ситуации с одним большим столом и одним маленьким столом.

4.4 Во время операции агрегирования данные в наборе данных распределяются неравномерно (в основном)

Решение: Двухэтапная агрегация (локальная агрегация + глобальная агрегация)

Применимые сценарии：верноRDDосуществлятьreduceByKeyКласс агрегацииshuffleоператор илисуществоватьSpark Использование групп в SQL Это решение больше подходит, когда оператор by используется для агрегации групп.

Принцип реализации：Сделайте оригинал таким жеизkeyпроходить附加случайныйпрефиксиз Способ,Станьте несколькими разными ключами,Это позволяет распределять данные, первоначально обработанные одной задачей, по нескольким задачам для локального агрегирования.,Это решает проблему чрезмерного объема данных, обрабатываемых одной задачей. Затем уберите приставку случайный,Снова глобальная агрегация,Вы можете получить окончательный результат. Конкретный принцип смотрите на рисунке ниже.

преимущество：верно于聚合类изshuffleрезультат операцииизданные倾斜,Эффект очень хороший. Неравномерность данных обычно можно устранить.,Или, по крайней мере, значительно уменьшить искажение данных.,Улучшите производительность заданий Spark более чем в несколько раз.

недостаток：Применяется только к агрегированным классамизshuffleдействовать,Область применения относительно узкая. Если это операция перемешивания класса соединения,Вам придется использовать другие решения

Разделить данные с помощью одного и того же ключа

4.5. В операции JOIN оба набора данных относительно велики, а распределение данных лишь нескольких ключей неравномерно.

Решение: Добавить случайный префикс/суффикс к клавише наклона.

Применимые сценарии：Обе таблицы относительно большие.,Соединение на стороне карты использовать нельзя. У одного из RDD есть несколько ключей, и объем данных слишком велик.,В остальном распределение RDDizKey относительно равномерное.

решение：将有данные倾斜изRDDсредний наклонKeyверно应изданные集单独抽取出来加上случайныйпрефикс,В другом СДР каждая часть данных объединяется с префиксом случайный для формирования нового из СДР (декартово произведение,Это эквивалентно увеличению его данных в N раз.,N — общее количество случайных префиксов из),Затем соедините их и удалите префикс. Затем присоединяем оставшиеся данные, не содержащие перекоса Keyиз. Наконец, два набора результатов объединения объединяются посредством объединения.,Вы можете получить все результаты объединения.

Преимущества：相верно于MapсторонаJoin,Более адаптируемый к большим данныеSETизJoin. Если ресурсов достаточно, асимметричный частичный набор данных и неасимметричный частичный набор данных могут обрабатываться параллельно, и эффективность значительно повышается. Расширение данных выполняется только для наклоненной части данных, а повышенное потребление ресурсов ограничено.

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

Примечание. В наборе данных RDD с перекошенными ключами количество ключей относительно невелико.

4.6 В операции JOIN оба набора данных относительно велики, и имеется множество ключей с неравномерным распределением данных.

решение：случайныйпрефикси РасширениеRDDруководитьjoin

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

Идеи реализации：это будетRDDиз每条данные都打上一个nв пределахизслучайныйпрефикс。同часверно另外一个正常изRDDруководить Расширение,Разверните каждый фрагмент данных на n фрагментов данных.,После расширения каждому фрагменту данных присваивается префикс 0~niz. Наконец, соедините два обработанных RDD. Предыдущее решение — попытаться выполнить специальную обработку только данных, соответствующих нескольким ключам перекоса.,Поскольку процесс обработки требует расширения СДР,Следовательно, предыдущее решение не занимает большой объем памяти после расширения RDD, и это решение предназначено для ситуации, когда имеется большое количество перекошенных ключей;,Невозможно выделить некоторые ключи для отдельной обработки,Таким образом, расширение данных может быть выполнено только на всем СДР.,Высокие требования к ресурсам памяти.

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

недостаток：Программа болееиз是缓解данные倾斜,Вместо того, чтобы полностью избежать искажения данных. И весь РДД надо расширять,Высокие требования к ресурсам памяти.

Практический опыт：曾经развивать一个данные需求изкогда,Было обнаружено, что объединение приводило к искажению данных. До оптимизации,Время выполнения задания после оптимизации с использованием данного решения составляет около 60 минут;,Время выполнения сокращено примерно до 10 минут.,Производительность улучшилась в 6 раз.

Уведомление：наклонитсяKeyдобавить в1-Nизслучайныйпрефикс,И объединенный набор данных будет соответственно расширен N раз (к каждому фрагменту данных в качестве префикса необходимо добавить числа 1-N)

4.7 Некоторые ключи в наборе данных содержат большой объем данных и не важны, тогда как другие данные четны.

решение：отфильтровать несколько искаженийKey

Применимые сценарии：если发现导致倾斜изkeyВсего несколько,И это мало влияет на сам расчет.,Поэтому использование этого решения очень удобно. Например, 99%изключа соответствует 10 фрагментам данных.,Но только один ключ соответствует 1 миллиону данных,Это приводит к искажению данных.

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

недостаток：Применимые Сцен не так много, в большинстве случаев в результате наклона клавиши все равно много, а не несколько.

Практический опыт：существовать В проекте我们也采用过这种方案解决данные倾斜。Однажды я обнаружил, что однаждыSparkОперациясуществоватьбегатьизкогда突然OOMПонятно,После расследования было обнаружено,Именно данные определенного ключа в таблице Hive в тот день являются ненормальными.,Это приводит к резкому увеличению объема данных. Таким образом, выборка выполняется перед каждым выполнением.,После вычисления наибольшего количества ключей в выборке,,Напрямую отфильтруйте эти ключи в существующей программе.

Давайте поговорим о широких и узких зависимостях RDD.

Гибкий ответ:

1) Почему широкие и узкие зависимости Spark так разделены?

Я спросил некоторые компании：байтx7,Просоx5,Алиx4,быстрый работникx3,Мейтуань x2,Технология Мяоин,заголовкиx2,Облако NetEase,могуджие,Цзиндунx3,Хиквидение,Тик Ток,ми Хо Йо,СФ Экспрессx2,360,Пиндуодуо,Тенсент х2,Помощь в выполнении домашних заданий Социальный рекрутинг,Юаньфудао,ebay

Существует два разных типа отношений между RDD и родительскими RDD, от которых он зависит: узкая зависимость и широкая зависимость.

1) Узкая зависимость означает, что каждый раздел родительского RDD может использоваться не более чем одним разделом дочернего RDD.

2) Широкая зависимость означает, что разделы нескольких дочерних СДР будут зависеть от разделов одного и того же родительского СДР.

Flink

Флинк: Точно Как гарантировать семантику Once Гибкий ответ:

1) Как Flink обеспечивает точное разовое потребление?

2) Как Flink реализует Exactly Once?

3) Как Flink гарантирует семантику ровно один раз?

4) Сквозная версия Flink Exactly Once?

Я спросил некоторые компании：（Социальный рекрутинг问из Ята）заголовкиx3,Небольшая консультация,байт,Вэйчжун,Момо,Тач Пал,NetEase,оболочка

По сравнению с другими движками потоковых вычислений, самое выдающееся или лучшее в Flink — это управление состоянием. Что такое статус? Например, в нашей повседневной разработке нам необходимо выполнять подсчет, сумму, максимум и другие операции с данными. Эти промежуточные результаты (то есть статус) необходимо сохранять, поскольку их необходимо постоянно обновлять, и эти значения. Или переменные можно понимать как смещение. Возьмем в качестве примера чтение Kafka. Нам нужно записать позицию чтения данных (то есть смещение) и сохранить смещение. На данный момент смещение также можно понимать как смещение. состояние.

Как Flink гарантирует отсутствие потери или избыточности данных во время отказоустойчивого восстановления? Контрольная точка — это внутренний механизм, который позволяет Flink восстанавливаться после сбоев. Контрольная точка — это согласованная копия состояния приложения Flink, включая сайты чтения ввода. В случае сбоя Flink восстанавливается, загружая состояние приложения из контрольной точки и продолжая обработку с восстановленной точки чтения, как будто ничего не произошло. Состояние Flink хранится внутри Flink. Преимущество этого подхода в том, что оно больше не зависит от внешних систем и снижает зависимость от внешних систем. Внутри Флинка. Доступ к переменным состояния через собственный процесс. В то же время сохранение контрольных точек будет выполняться регулярно. Храните контрольные точки в распределенной персистентной системе. Если возникла неисправность. Состояние всего потока будет восстановлено с самой последней контрольной точки.

Давайте получим данные из Kafka через Flink и поговорим о том, как управлять смещением, чтобы добиться ровно одного раза.

Потребитель Kafka, реализованный в Apache Flink, представляет собой оператор с отслеживанием состояния, который интегрирует механизм контрольных точек Flink. Его состояние — это смещение чтения всех разделов Kafka. При срабатывании контрольной точки смещение каждого раздела сохраняется в контрольной точке. Механизм контрольных точек Flink гарантирует единообразие статуса хранения всех задач оператора. Что здесь означает «последовательный»? Это означает, что сохраняемое ими состояние основано на одних и тех же входных данных. Контрольная точка считается завершенной, когда все задачи оператора успешно сохранили свое состояние. Таким образом, система обеспечивает семантику обновления состояния ровно один раз при восстановлении после потенциальных сбоев системы.

Ниже мы шаг за шагом покажем, как сайт потребления Kafka в Apache Flink выполняет контрольные точки. В примере этой статьи данные хранятся в JobMaster от Flink. Стоит отметить, что в случаях POC или производственного использования эти данные лучше всего хранить во внешней файловой системе (например, HDFS или S3).

первый шаг: Как показано ниже, Кафка тема, есть два раздела, каждый раздел содержит «А», «Б», «С», «Г», «Е» 5 сообщений. Мы устанавливаем смещение обоих разделов на 0.

Шаг второй: Kafka потребитель (потребитель) начинается с partition 0 Прочитайте сообщение. Сообщение «А» находится в обработке, первое consumer из offset стало 1.

Шаг третий: Сообщение «А» приходит во Флинк. Map Задача. два Оба потребителя начинают читать следующее сообщение (раздел 0 читает «B», раздел 1 читает «A»). Каждый обновляет смещение до 2и1. В то же время Флинкиз JobMaster начал активировать контрольную точку на источнике.

Шаг 4: Далее, поскольку источник запускает контрольную точку, Кафка Потребитель создает первый снимок своего состояния («смещение = 2, 1") и сохраните снимок на Flinkиз. JobMaster середина. Источник В сообщениях «Б» и «А» из раздела 0 и 1 После отправки я отправил checkpoint barrier。Checkopint barrier для каждого operator task Выравнивание контрольных точек между ними обеспечивает согласованность всей контрольной точки. Сообщение «А» пришло. Flink Map Задача, пока выше из consumer Продолжите читать следующее сообщение (сообщение «С»).

Шаг 5:

Flink Map Задача собрала все ту же версию checkpoint после барьера,Тогда его собственный статус также будет сохранен в JobMaster. в то же время,Потребитель продолжит читать сообщения от Кафки.

Шаг 6: Flink Map После того, как Задача завершит свой собственный статус и процесс создания моментального снимка, она отправит отчет Flink. JobMaster сообщает, что этот контрольный пункт пройден. Когда все задачи сообщат о завершении своей контрольной точки состояния, JobMaster отметит контрольную точку как успешную. Отныне это Контрольную точку можно использовать для восстановления. Стоит отметить, что Флинк не опирается на Кафку. offset восстанавливается после системных сбоев.

Восстановление При возникновении сбоя (например, работник кладет трубку) все операторы Задачи будут перезапущены, а их статус будет сброшен до последней успешной контрольной точки. Кафка источник соответственно из смещения 2и1Начать читать сообщения снова（потому что это сделаноизcheckpointЧжунцуньизoffset）。当Операция重启назад,Можно ожидать нормальной работы системы,Как будто неисправности раньше не было. Как показано ниже:

Flinkizcheckpoint основан на алгоритме Чанди-Лампорта и снимке распределенной согласованности. Если вы хотите узнать больше о Flinkizcheckpoint, вы можете узнать об этом алгоритме.

хранилище данных

стратификация хранилища данных (деление по уровням), что делает каждый уровень?

Я спросил некоторые компании：байт,Алиx2,iQiyi,Байдуx2,NetEasex3,Мейтуанx5,оболочка,keep,Мафенгвок2,повернись,Диди,Просо,ми Хо Йо,Нравитьсяx2,Юаньфудао,58x2,Помощь в выполнении домашних заданий Социальный рекрутинг,байт Социальный рекрутинг,Тенсент Социальный рекрутингx2,Цзиндун,Тач Пал

CIF Иерархическая архитектура (информационная фабрика) представляет различные решения моделирования на разных уровнях посредством многоуровневого представления, CIF. 将хранилище данные разделены на четыре слоя, как показано на рисунке:

Вот еще одно изображение иерархической архитектуры хранилища данных в проекте.

Многоуровневое преимущество: сложные проблемы упрощены、Понятная структура данных (легко управлять)、Повышение возможности повторного использования данных、Изолировать необработанные данные (развязка)

ODS（Operational Data Store）：

Уровень хранения оперативных данных,Часто это взаимно однозначное сопоставление таблиц бизнес-базы данных.,将业务данные库серединаизлистсуществовать ODS Восстановите данные, данные полностью совпадают;

DWD（Data Warehouse Detail）：

Уровень детализации данных,существовать DWD Выполнять очистку данных, десенсибилизацию, унификацию и другие операции, DWD Слой данных чистый и имеет хорошую согласованность данных;

DWS（Data Warehouse Service）：

Уровень служебных данных (общедоступный сводный уровень),существует слой DWS для легкого суммирования,Предоставлять общедоступные сводные данные по различным темам на уровне DM;

DM（Data Market）：

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

Другие типы

Scala реализует подсчет слов

Я спросил некоторые компании：Облако NetEase,Байты х2,четвертая парадигма

Приходите первымСложная версияиз

object WordCount {  def main(args: Array[String]): Unit = {    //Определяем список    val list = List("java scala java","scala python scala")    //Обрабатываем исходные данные и получаем каждое слово      val words = list.flatMap(_.split(" "))    println(words)//List(java, scala, java, scala, python, scala)    //Изменяем формат на кортеж (слово, 1)      val wordOne = words.map((_,1))    println(wordOne)//List((java,1), (scala,1), (java,1), (scala,1), (python,1), (scala,1))    //Согласно значению ключа в (word, 1) word группа      val wordG = wordOne.groupBy(_._1)    println(wordG)//Map(scala -> List((scala,1), (scala,1), (scala,1)), java -> List((java,1), (java,1)), python -> List((python,1)))    //Получаем изvalue на карте и выполняем статистику по изtupleiz._2 (то есть 1) в этом значении (то есть суперпозицию)    val wordCount = wordG.mapValues(_.foldLeft(0)(_+_._2))    println(wordCount)//Map(scala -> 3, java -> 2, python -> 1)  }}

версия однострочного кода

import org.apache.spark.rdd.RDDimport org.apache.spark.{SparkConf, SparkContext} object WorldCount {  def main(args: Array[String]): Unit = {    new SparkContext(new SparkConf().setAppName("WC").setMaster("local")).textFile("./data/words").flatMap(_.split(" ")).map((_,1)).reduceByKey(_+_).foreach(println)  }}

Saprk Разница между потоковой передачей и Flink Могу ответить гибко：

1) Отличия Сапрка и Flinkиз

2) Каковы различия между Flink и Spark для пакетной обработки?

3) Spark Streaming превосходит Flinkиз Недостатки

Я спросил некоторые компании：байтx3,Алиx3,iQiyix2,Цзяюнь,Тенсент,быстрый работник,Могуджие x2,360,Кредитная карта СИТИК,Мейтуан Социальный рекрутинг,оболочка,Информация о Аньхэне,Хиквидение,Сеть CMB,Тач Пал,конкурентный мир,Тренд Микро,NetEase,Мейтуан

Этот вопрос очень макро-вопрос,Потому что между этими двумя структурами существует много различий. Однако во время интервью есть очень важный момент, на который необходимо ответить: Flink — это стандартный механизм обработки данных в реальном времени.,Событийно-ориентированный. И Искра Потоковая передача — это модель Micro-Batch.

Ниже мы представим две основные структуры в нескольких аспектах:

1）С точки зрения обработки потока,Spark основан на микропакетной обработке.,Думайте о потоковых данных как о небольших пакетных блоках данных и обрабатывайте их отдельно.,Таким образом, задержка может быть достигнута только в секундах. Flink обрабатывает каждое событие на основе,Всякий раз, когда вводятся новые данные, они будут немедленно обработаны.,Верно из потоковых вычислений,Поддерживает вычисления на уровне миллисекунд. по тем же причинам,Spark поддерживает только оконные операции на основе времени (время обработки или время события).,Flink поддерживает оконные операции, что очень гибко.,Не только поддерживает временные окна,Он также поддерживает окна, основанные на самих данных (кроме того, он также поддерживает время, количество и сеансы).,и оконные операции, управляемые данными),Разработчики могут свободно определять желаемые оконные операции.

2）Из функции SQL с точки зрения,SparkиFlink предоставляет SparkSQLиTable API, обеспечивающий SQL соответственно

3）Интерактивная поддержка。Сравните два,В Spark улучшена поддержка SQL.,Соответствующая оптимизация, расширение и повышение производительности.,Есть еще много возможностей для улучшения поддержки Flinkсуществовать SQL.

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

5）С точки зрения соответствующей экосистемы,Сообщество Sparkiz определенно более активно. Можно сказать, что Spark имеет наибольшее количество участников с открытым исходным кодом под Apache.,И существует множество различных библиотек, которые можно использовать для разных сценариев. Поскольку Флинк новее,На данном этапе сообщество открытого исходного кода не так активно, как Spark.,Функции различных библиотек не столь обширны, как у Spark. Но Flink все еще развивается,Различные функции также постепенно совершенствуются.

Подвести итог

Вышеупомянутое из опубликовано другими пользователями на Niuke избольшие данные Миан Джингли“Покажи свое лицо”Скорость относительно высокаяиз Вопросы для интервью,Но из Ниуке может быть, а из нет, поэтому он здесь не в счет.,По сути, это, вероятно, семьдесят семь или восемьдесят восемь.

На самом деле это не просто вопрос на собеседовании,за каждый кадр,每个知识点руководить汇总Подвести В общем, все это очень хорошие способы продвижения, потому что есть вещи, на которые вы можете взглянуть с первого взгляда и, вероятно, знаете их все, но когда вы проведете некоторое исследование по этому вопросу, итогчас,При описании на своем родном языке,Часто вы не можете отложить ручку (или печатать на клавиатуре).,В это время вы будете использовать систему для проверки очков знаний в этой области.,Резюме понемногу,Превратите знания других людей в свои собственные.

«Вопросы для собеседования по большим данным» V3.0》Эта версия завершена и в основном содержит большинство вопросов для интервью по большим данным на Niuke.