Pull to refresh

Comments 27

>Из плюсов — есть русскоязычная документация и поддержка ( новички и те, кто работал с поддержкой в виде индусов в Америке — должен оценить),
В смысле, кому и кто должен? Не, я понимаю что русскоязычная поддержка желательна, но в реальности определяющим все-таки является ее качество, а какое оно будет — еще неизвестно.

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

>изрядно непонятный — без Spark, Zeppelin и Ranger,
Насколько я понимаю, Ranger это аналог Sentry (ну или наоборот)? Да, это странно для энтерпрайза, как и отсутствие спарка.

Ну а так Zeppelin скажем у нас тоже нет — и ничего, как-то никто не страдает, это все-таки не критичная часть дистрибутива, вполне можно и отдельно доставить.

Ну и в целом удивляетесь вы зря, мне кажется. Есть проект bigtop, на основе которого вполне можно собрать свою сборку. Это не будет совсем легко, конечно же, но и не запредельно сложно.
Можно и руками собрать из пакетов, но удовольствия при этом не получаешь, зато багов…
Кстати, новичкам Data Engeneer'ам советовал бы попробовать этот путь, скакать по граблям очень познавательно.
PS Ходят слухи с той стороны океана, что от Sentry откажутся в дистрибутивах Cloudera CDH в пользу Ranger.
Взяли за основу древнюю версию. Код полностью скопирован с hdp и hdf с минимальными допилами. Аж прослезился, давно уже не видел этот древний код.
Искренне надеюсь, что выйдет новая версия.
Импортозамещение же!
Поэтому пойдёт в госорганы, значит, любой поддержке придётся копаться и настраивать не самый свежий релиз.
Используем в проде, 2 года версию 1.4 на кластере побольше (2448 VCores), и недавно начали использовать 1.6 на кластере поменьше…
Полет нормальный.
Без поддержжки иногда бывает непросто — не все ответы находятся в Интернете.
И, может не нужно ругать Аренадату за использование не самых свежих релизов. Да, как разработчику — хочется новое, фичастое… Но, потеря важных данных на непроверенных версиях может выйти боком…
Стоял HDP 2.6 с llap, который админы никак не хотели включать — мол, Tez проверенный движок, а это какие-то новомодные заморочки.
После того, как на удалось на админов надавить и включили — запросы ускорились раз в 20, а примитивные запросы типа «select * from… limit 10» начали вместо 2 минут исполняться 0.9 секунд.
Пришли ошаращенные Data Scientists и задали два вопроса: — Что это такое вы сделали и почему этого раньше не сделали?!
Мораль истории проста: не всё, что проверено временем, полезно.
А новые версии можно ( и нужно) на небольшом тестовом кластере обкатывать.
PS В Arenadata добавлен LLAP в качестве движка для Hive?
Да, LLAP есть, но, со слов нашей поддержки, вам очень повезло что он работает хорошо. У нас были кейсы с ним, используем очень осторожно.
Всем привет.
Я отвечаю за продуктовое наполнение платформы в Arenadata. Попробую ответить на вопросы в статье и в комментариях. В нашей платформе я технически больше погружен в Greenplum и Clickhouse, чем в Hadoop, но постараюсь использовать экспертизу коллег. Боюсь, правда, получится очень много букв :)

Для начала, кто мы такие. Команда Arenadata (AD) формировалась в 2014-2017 году. Все мы (на тот момент около 5 человек, сейчас уже больше 40) до AD многие годы занимались корпоративными хранилищами данных (КХД) — кто-то разрабатывал Hadoop и Greenplum (CEO и CTO пришли из Pivotal), кто-то внедрял в интеграторах (Glowbyte), кто-то поддерживал на местах (я занимался эксплуатацией Greenplum и Hadoop в Tinkoff). В какой-то момент мы поняли, что объединившись мы сможем улучшить те open-source проекты, с которыми до этого работали, объединив их в единую платформу и наделив её enterprise-фичами — глубоким саппортом, единым мониторингом и управлением, обучающими программами для спецов заказчика и возможностью менять код под заказчиков.

При этом мы не просто собираем open-source на коленке и продаём:
1) Большинство наших разработок мы отдаём в open-source (комитим в проекты, больше всего в Greenplum, в Hadoop поменьше)
2) Мы разрабатываем собственную систему управления кластерами (вот тут и тут можно посмотреть как это выглядит), и она доступна абсолютно бесплатно на нашем сайте. Код также скоро будет открыт. Мы берём деньги лишь за техподдержку.

Да вы же просто слизали всё у Хортона! DrunkBear
И да, и нет. Мы никогда не ставили себе целью сильно отличаться от Hortonworks (точнее, от Bigtop) — это банально вопрос совместимости, заказчики не хотят vendor lock-in. Более того, специально для того, чтобы не отличаться от Хортон и Клаудеры, в 2015-м году мы прошли сертификацию нашего дистрибутива в ODPi — часть Linux Foundation (и каждый год проходим её снова) — это гарантия того, что мы не делаем наколеночного, закрытого и несовместимого ни с чем решения.
Также, мы никогда не будем сильно отличаться от Bigtop ещё и потому, что более-менее серьёзные изменения в коде мы комитим в сам Bigtop и другие репы. Кстати, один из наших PR принял лично Alan Gates.
С другой стороны, мы видим слабые стороны у дистрибутивов Хортона и Кладудеры (хотя теперь уже не разберёшь кто есть кто), которые мы смогли сделать своими преимуществами:
1) Сильное отставание версий компонентов от upstream
2) Невозможность обновлять компоненты по отдельности (по краней мере без танцев с бубном, но мы же говорим об Enterprise, верно?)
Поэтому версии компонентов у нас всегда немного впереди (про 3.0 чуть дальше), а благодаря нашему Cluster Manager заказчики могут обновлять компоненты по отдельности.

Когда наконец будет 3.х? DrunkBear
Ох, тоже самое спрашивают наши заказчики) С 3.х есть два нюанса:
1) Недавно было объявлено, что Ambari — deprecated и скоро умрет, поэтому мы решили полностью отказаться от Ambari в нашем 3.х и перевести всё управление в Arenadata Cluster Manager, чем сейчас и занимаемся. Это займёт ещё несколько месяцев, дальше будет проще.
2) По мнению наших спецов, 3.х ещё всё-таки не настолько стабилен, чтобы брать его на саппорт.

Что с саппортом? Можете ли вы соответствовать уровню хортона? DrunkBear
Да, можем, а за счёт 3-го пункта мы даже немного лучше:
1) У нас саппорт 24х7, за счёт того что наши специалисты находятся в разных часовых поясах в России
2) За этот год мы очень сильно нарастили ресурсы на саппорт — сейчас это самый многочисленный отдел в AD (9 человек + подключаем разработчиков на сложные кейсы)
3) В отличии от Хортона и Клаудеры, мы готовы адаптировать дистрибутив под адекватные хотелки заказчиков — в том числе вносить (комитить) изменения в основные OS-репы. Мы здесь, в России, с нами можно и нужно встречаться, договариваться и развивать продукты вместе.

Ваше импортозамещение — это переклеенная этикетка DrunkBear
Вот тут будет сложно, но я попробую.
1) В первую очередь, в нашу платформу входят дистрибутивы продуктов (Hadoop, Greenplum, Clickhouse), а не их аналоги или свои разработки с нуля. Мы нигде и никогда не скрывали, что используем OS-проекты. Разрабатывать с нуля свой аналог дистрибутива Hadoop в 2019-м году — безумие.
2) Работать с open-source можно и нужно только одним способом — делиться ресурсами, отдавая свои наработки в open-source. Это не просто (куча бюрократии, согласований, общения с сообществом и тд), но мы это знаем и умеем. Это значит, что у нас (надеюсь) никогда и не будет своего отдельного форка Hadoop или Greenplum. При этом, мы делаем много дополнительного функционала (коннеткоры, управлялки и тд).
3) Рискую отхватить за политику, но я попробую.
Откуда растут ноги у импортозамещения? Всё просто: большие государственные (иногда и частные) предприятия опасаются, что в какой-то момент они не смогут использовать зарубежное ПО из-за:
— санкций с нашей стороны
— санкций с той стороны
— валютных изменений
— ухода экспертизы по этому ПО с нашего рынка
Мы закрываем эти риски. Более того, в случае глобального экстерминатуса (т-т-т), мы сможем поддерживать и развивать эти OS-проекты независимо (повторюсь, это не является целью).
4) Импортозамещение — не основной драйвер нашего бизнеса, так как большинство наших заказчиков — частные компании, которые в первую очередь ценят экспертизу (Х5 Retail Group, IQ Option, Touch Bank и другие). Потребность в импортозамещении у госов — приятный бонус, не более.

А Pivotal и Hortonworks вообще знают, чем вы тут занимаетесь?
Не просто знают, а ещё и помогают нам. Вот тут к нам на митап приехал Pivotal Director of Data Engineering, а вот тут я выступал на Greenplum Day в Нью-Йорке вместе с CIO Morgan Stanley — крупнейшим пользователем Greenplum в мире. Так работает open-source — рынок захватывает технлология, а уже потом его делят вендоры.

Где Ranger и Zeppelin? sshikov
Ranger есть в платформе, на сайте, увы, сильно устаревшая информация. Мы использовали его в двух проектах, всё ок. Sentry действительно похоже умирает.
А вот от Hue мы отказались в пользу Zeppelin (он у нас выделен в отдельный продукт, как и Kafka) — кстати, рекомендую, новый Zeppelin 0.8 стал очень крутым.

Код полностью скопирован с hdp и hdf с минимальными допилами loltrol
Выше я ответил, почему это так и почему это правильно.

Взяли за основу древнюю версию. loltrol
Вот тут не очень понял — можете указать на версии компонентов, которые по вашему мнению устарели? Уточню у наших ребят.

Сайт у вас отстой.
Мы знаем :( Этот сайт создавался когда нас было 5 человек, мы вообще плохо умеем в дизайн и сайты. Этим летом хотим переделать, если у вас есть контакты студии, которая сможет сделать сайт не хуже pivotal.io — поделитесь в ЛС плз.

Почему у вас нет блога на хабре? Почему так мало информации?
Блога нет, потому что дорого :)
Информации о нас в открытом доступе мало, потому что рынок очень узкий, и мы своих потенциальных заказчиков знаем и так.
Ну и плюс мы активно участвуем в конференциях, организуем митапы и т.д.

А ещё...
А ещё мы:
1) Раз в квартал проводим митапы по распределённым системам — присоединяйтесь, следующий будет в сентябре, сможете спросить и высказать нам всё лично :)
2) Ведём чат в ТГ по Greenplum, там есть почти все наши заказчики — можете спросить их о качестве нашего сервиса
3) Сейчас совместно с Яндекс запускаем продукт на базе Clickhouse — детали сможем опубликовать чуть позже, но получается круто!

Мне кажется, получилось очень много информации для комментария. Есть ли смысл оформить отдельную статью, где рассказать о нас подробней?
>Где Ranger и Zeppelin? sshikov
>Ranger есть в платформе, на сайте, увы, сильно устаревшая информация. Мы использовали его в двух проектах, всё ок. Sentry действительно похоже умирает.

Ну я на самом деле несколько не так спрашивал :) Но не важно. Мы реально нахлебались с Sentry, и не то чтобы хотели заменить на что-то (вряд ли имея не один большой 24/7 кластер это возможно сделать просто), но по крайней мере попробовать альтернативы было бы неплохо.
Hue как средство выполнения запросов, действительно — отстой, но Zeppelin не будет полноценной заменой — это разные продукты.
Спасибо за большой ответ, здесь именно те пункты, которых не хватало.
И да, я не писал про «просто переклеили этикетку», я честно добавил, что в релизах другие версии пакетов — а это автоматом значит совсем другой набор багов и фич.
в релизах другие версии пакетов

Это вообще огромная проблема дитрибутивов на базе Ambari. Что Bigtop, что Horton, что Arenadata 1.x, страдали от глубокой взаимосвязанности продуктов. Если мне память не изменяет, то в ADH 1.5 было 26 сервисов и все они как-то взаимодействовали друг с другом. Проблема была на столько сложна, что, например, Hive все поставляют в неком гибридном виде 1.x + 2.x и внутри это устроено весьма люто.

Подобрать стабильный набор пакетов, работающих и самим, и друг с другом — задача нетривиальная.
А под высокой нагрузкой становится ещё веселее: посмотрел, на стабильном кластере около 20кб правок добавлено в разные Advanced Configuration Snippet for *-site.xml
PS судя по тем же слухам, место Ambari займёт Cloudera Manager

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

Какие-то будут заменять аналогами Horton'a, что-то оставят своё.
Или добавлять к существующим — Tez в качестве движка для hive запросов замечен в CDH 6.
Кстати, спор «как лучше хранить файлы — в orc или parquet» скоро тоже будет устаревшим — оставят parquet.
Не поделитесь инфой про ORC? Очень интересно.
Я скажу только одно слово и это слово будет — Impala.
Она изначально заточена под паркет и остаётся в будущих релизах, поэтому паркет остаётся основным форматом CDH.
Если нужно — могу поискать пруфы, суть передал своими словами.
Только учитите, что ещё 3 года с марта 2019 ( когда завершилось объединение), релизы будут выпускаться под своими брендами, поэтому вотпрямщас Ambari и ORC не выпилят.
Hive проиграл Impala?
Orc — был разработан для ускорения работы Apache Hive и увеличения эффективности хранения в Apache Hadoop. И, в принципе Hive с ним неплохо работает… Spark вот тоже в последних версиях использует vectorized-engine для работы с орками… странно, что всё под хвост…

Так это все ожидаемо. Заопарк надо уменьшать. После выхода в GPDB в opensource все sql движки сильно просели в популярности и искуственно держать два продукта Хортондере невыгодно. А если Hive исчезнет из портфеля ведущего производеля, то судьба его очевидна.

Не знаю, кто кому проиграл, но захватывающие тесты, где сначала Impala в разы быстрее Hive с тюнингом Horton, потом Hive + LLAP в те же разы быстрее Impala, все машут флажками и скандируют что-то про subsecond queries, смотрел с большим интересом.
Возможно, будут менять parquet и внедрят в него фичи ORC — тогда и маркетинг будет цел, и пользователи довольны.
IMHO, основная проблема в том, что Impala не полностью поддерживает orc.
Hive остаётся, в том числе с движками Tez и Hive-on-spark2 ( уже выкатили в Cloudera CDH 6.x.x)
Векторизация parquet тоже
>Не знаю, кто кому проиграл, но захватывающие тесты, где сначала Impala в разы быстрее Hive с тюнингом Horton,

Знаете, я тут как бы мимокрокодил, но пару месяцев наблюдал, как мои коллеги тюнили импалу. Это было что-то с чем-то. Ну т.е. да, она работает, запросы выполняет быстро. Но, во-первых, работает например на 8 пользователях, а потом проседает (или что еще хуже — падает). У Hive это тоже наблюдается, но кривая другая, или не падает. Ну т.е. тут все нетривиально, даже если тесты что-то показали.

Ну и второе — Impala скажем не поддерживает (в нашей версии, а возможно и вообще) некоторые возможности Hive, например скажем типы данных вроде map или struct, или поддерживает иначе, с другим синтаксисом языка. Написание UDF либо практически невозможно, либо сильно различается по трудоемкости.

В общем, выбор тут совсем не очевиден, и он многофакторный.
Многое зависит от версии импалы: чем свежее, тем больше похожа на серьёзный продукт, а не стартап с его не самыми лучшими сторонами.
Я знаю банки, где etl/аналитика построена на Impala и люди довольны.
Что от версии зависит — предсказуемо.

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

Ну то есть, ETL на ней строить — я бы не стал, а что кто-то доволен — почему нет?
Я не про компоненты имел ввиду, а про саму морду — ambari. Там уже много чего улучшено и допилено было. Но так как ходят слухи что амбари уже «мертво» после слияния hortonworks с cloudera, то ничего страшного. Делайте форк и продолжайте допиливать амбари :)

Мы отказали от идеи форкать Амбари ещё года полтора назад по целому ряду причин. Главная из которых Ambari чудовищно большой. По всей видимости это была хитрая форма вендор лока со стороны HW. Например, там своя кривая реализация чего-то напоминающего Ansible, которую писали Java разработчики на Python (получилось ужасно). Есть там конечно и позитивные вещи, но в целом, код получился большой и неповоротливый.


Сейчас мы переходим на собственную реализацию, названную ADCM и написанную на Python, Ansible и немножко Golang. Главная пользовательская фишка в сравнении с Амбари это легкость интеграции со своими приложениями (это ansible), поддержка мультикластера (любых версий разом) и облаков. Например, ADB (GPDB) у нас распространяется только через ADCM (https://docs.arenadata.io/adb/install/adcm/ru/index.html).


Сильно надеюсь, что в этом году мы заборем бюрократию проекта Apache и ADCM станет проектом Apache Foundation. Он и сейчас под лицензией ASF2, но инфраструктуру сборки и работы с исходниками мы пока не раскрыли.

Sign up to leave a comment.

Articles