Честно говоря не самая удачная статья - многие важные моменты упущены, а схемы не точны. Вот в этой статье принцип получения токена и его обновления описаны гораздо подробнее и понятнее: https://habr.com/ru/company/flant/blog/475942
Можно и Argo или ещё какую-то GitOps штуку. По моим ощущениям Tekton в фаворе — на него и OpenShift переезжает вместо Jenkins, и, собственно, Jenkins X его может использовать в качестве движка.
Тема очень актуальная и интересная!
Сейчас много хороших инструментов, которые позволяют устраивать контролируемые эксперименты. Мне понравился Chaos Toolkit — у него простой синтаксис и достаточно широкие возможности по эмуляции сбоев, в том числе в Kubernetes. Сейчас как раз работаю над тем, чтобы интегрировать его в пайплайн для автоматизированного тестирования приложений на устойчивость сбоям после развёртывания обновлений.
Приветствую!
По сути да — описание получившегося подхода.
Когда я брался за эту задачу, то стал искать готовые варианты модели работы с Git, включавшие бы в себя ревью кода, и мне они не попались. Поэтому, когда мы пришли к более-менее рабочему варианту, я систематизировал получившийся материал и решил поделиться.
З.Ы. Для контроля скинул текст паре человек на ревью — им показалось интересно :)
Спасибо большое за ценные дополнения!
На счёт конфликтов — двояко: большая часть доступна для решения из GUI, но попадаются такие, которые можно решить только локально.
Всё верно — Spark и Impala используют Hive только для получения метаданных (без использования MapReduce. Про него я написал просто чтобы подчеркнуть, что конфигурация Hive on Spark не использовалась).
Спасибо, теперь вопрос стал более понятным.
В рамках проекта не стояла задача настройки работы Hive через Spark — наоборот, Spark использовал Hive для задач обработки данных, а Hive по умолчанию использует MapReduce.
Насколько я понимаю, Cloudera на данный момент не поддерживает подобную конфигурацию Hive (по информации из официального сообщества — community.cloudera.com/t5/Cloudera-Manager-Installation/Hive-on-spark2/td-p/62641).
Приветствую!
По порядку:
1. На счёт Hive и Spark2 — да, для этого потребовалось сконфигурировать Spark2 (описано тут — spark.apache.org/docs/latest/running-on-yarn.html).
2. На счёт внешних клиентов — не совсем понятна суть вопроса, уточните пожалуйста, что именно интересует.
3. Impala использовали для обработки запросов из SpagoBI — её использование дало ощутимый прирост производительности.
4. Джобы Spark запускаем по-разному — из Zeppelin (там создаётся Spark Context при запуске интерпретатора), с помощью spark-submit и из Oozie (если требуется запланировать их регулярный запуск).
Приветствую!
Большое спасибо за дополнение!
Эта информация действительно более актуальна для темы, описанной в предыдущем посте. Странно, что нет прав его комментировать. Обращусь с этим вопросам в службу поддержки сайта.
Часть из того, что Вы описали, было в предыдущем посте, а часть я хотел отобразить в следующем в разделе «Решение проблем».
Будет интересно узнать о Вашем опыте. Если решите сделать отдельный пост — пришлите пожалуйста ссылку, с удовольствием ознакомлюсь :)
Приветствую!
Да, тестовая и препрод среда остались на прежних ресурсах из приватного облака.
Тестовой среды действительно не хватает для полноценного выполнения задач, поэтому не ней происходит отладка инструментов и задач загрузки и построения витрин на ограниченном наборе данных для быстрой оценки.
Ресурсов препрод среды для задач загрузки и построения витрин вполне достаточно. Проблемы с производительностью начинают возникать только при параллельном запуске большого количества задач по анализу данных и построению моделей в Jupyter и Apache Zeppelin. Сейчас большинство этих задач выполняется в прод среде и влияние на препрод минимально.
Честно говоря не самая удачная статья - многие важные моменты упущены, а схемы не точны. Вот в этой статье принцип получения токена и его обновления описаны гораздо подробнее и понятнее: https://habr.com/ru/company/flant/blog/475942
Сейчас много хороших инструментов, которые позволяют устраивать контролируемые эксперименты. Мне понравился Chaos Toolkit — у него простой синтаксис и достаточно широкие возможности по эмуляции сбоев, в том числе в Kubernetes. Сейчас как раз работаю над тем, чтобы интегрировать его в пайплайн для автоматизированного тестирования приложений на устойчивость сбоям после развёртывания обновлений.
По сути да — описание получившегося подхода.
Когда я брался за эту задачу, то стал искать готовые варианты модели работы с Git, включавшие бы в себя ревью кода, и мне они не попались. Поэтому, когда мы пришли к более-менее рабочему варианту, я систематизировал получившийся материал и решил поделиться.
З.Ы. Для контроля скинул текст паре человек на ревью — им показалось интересно :)
На счёт конфликтов — двояко: большая часть доступна для решения из GUI, но попадаются такие, которые можно решить только локально.
В рамках проекта не стояла задача настройки работы Hive через Spark — наоборот, Spark использовал Hive для задач обработки данных, а Hive по умолчанию использует MapReduce.
Насколько я понимаю, Cloudera на данный момент не поддерживает подобную конфигурацию Hive (по информации из официального сообщества — community.cloudera.com/t5/Cloudera-Manager-Installation/Hive-on-spark2/td-p/62641).
По порядку:
1. На счёт Hive и Spark2 — да, для этого потребовалось сконфигурировать Spark2 (описано тут — spark.apache.org/docs/latest/running-on-yarn.html).
2. На счёт внешних клиентов — не совсем понятна суть вопроса, уточните пожалуйста, что именно интересует.
3. Impala использовали для обработки запросов из SpagoBI — её использование дало ощутимый прирост производительности.
4. Джобы Spark запускаем по-разному — из Zeppelin (там создаётся Spark Context при запуске интерпретатора), с помощью spark-submit и из Oozie (если требуется запланировать их регулярный запуск).
Хорошо, большое спасибо!
Большое спасибо за дополнение!
Эта информация действительно более актуальна для темы, описанной в предыдущем посте. Странно, что нет прав его комментировать. Обращусь с этим вопросам в службу поддержки сайта.
Часть из того, что Вы описали, было в предыдущем посте, а часть я хотел отобразить в следующем в разделе «Решение проблем».
Будет интересно узнать о Вашем опыте. Если решите сделать отдельный пост — пришлите пожалуйста ссылку, с удовольствием ознакомлюсь :)
Да, тестовая и препрод среда остались на прежних ресурсах из приватного облака.
Тестовой среды действительно не хватает для полноценного выполнения задач, поэтому не ней происходит отладка инструментов и задач загрузки и построения витрин на ограниченном наборе данных для быстрой оценки.
Ресурсов препрод среды для задач загрузки и построения витрин вполне достаточно. Проблемы с производительностью начинают возникать только при параллельном запуске большого количества задач по анализу данных и построению моделей в Jupyter и Apache Zeppelin. Сейчас большинство этих задач выполняется в прод среде и влияние на препрод минимально.