Business Intelligence на очень больших данных: опыт Yota



    Всем привет! Меня зовут Михаил Волошин, и я, как руководитель отдела инструментов бизнес-анализа, хочу верхнеуровнево рассказать о плюсах и особенностях BI-решения Yota.

    200 Tb Vertica, 400 Tb Hadoop, кластер Tableau, специфичная организация процесса разработки и многое другое ждут вас под катом.

    Внимательный читатель спросит: «А при чем тут Vertica и слоник Hadoop, технологии же разные?» Да ни при чем — это лишь КДПВ.

    1. DWH: ода Вертике


    Vertica. На ее базе построено корпоративное хранилище данных (data warehouse, DWH), являющееся ядром решения. Наша Vertica — первая инсталляция в СНГ — была развернута в 2012 году (я пришел лишь в 2016). 8 лет назад не было и половины зоопарка продуктов Apache, а выбор происходил между Netezza, Greenplum и, собственно, Vertica. Время показало, что выбор оказался верным: IBM прекратила техническую поддержку Netezza в 2019, Greenplum еще в 2015 стал opensource продуктом (т.к. никто не покупал шардированный Postgres). И к началу 2021 года в мире осталось две серьезных аналитических on-premise БД: Vertica и Teradata. Не хочу разводить холивар, но буду рад услышать об иных решениях, позволяющих обычным аналитикам в adhoc запросах оперировать >1 трлн строк за разумное время в минутах и без поддержки команды data engineer + dataops.

    Итак, Vertica — это колоночная MPP БД. Т.е. данные хранятся в колонках, что ускоряет доступ к ним и позволяет оптимизировать хранение. Запросы выполняются одновременно всеми нодами кластера, что также позитивно сказывается на скорости обработки данных (однако происходит высокая утилизация сети и дисков). При этом входной порог для доступа к терабайтам и петабайтам данных низок за счет ANSI SQL 99 с небольшими расширениями. 1-й Tb этого великолепия — бесплатно. Более подробно об архитектуре Vertica здесь.

    У нас 161 Tb на 34 rack нодах HP, каждая из которых имеет:

    • 2*CPU по 20 ядер
    • 256GB RAM
    • 2*10Gb/s сеть
    • быстрые 10k SAS HDD RAID 10 (в 2017/18, когда мы планировали обновление и обновляли RAID массивы, SSD стоили как «чугунный мост» и были не такими надежными как сейчас)

    Vertica может быть развернута на любом железе/виртуалках. Хоть на 3-х ноутбуках сыновей маминой подруги. Однако, важно помнить, что вендор явно рекомендует разворачивать кластер на гомогенном по типу оборудовании. Нас как раз в этом году ждет кейс смены вендора «железа» — аж интересно, как все пройдет.

    В целом продукт достаточно надежный: за все время, что я работаю в Yota (5-й год пошел), кластер ни разу не падал целиком. Были кейсы, когда 9 нод вываливались в течение 10 минут (диски, контроллеры рейдов, иные технические проблемы), и это приводило к просадкам производительности, но кластер не рассыпался, и после вывода сбоивших нод из кластера «на горячую» производительность восстанавливалась. Вывод необходим, т.к. кластер всегда работает со скоростью самой медленной ноды (вспоминаем рекомендацию вендора о гомогенности). Теоретически из строя может выйти до половины всех узлов кластера, но может хватить и 2 нод (при k-safety=1, параметр репликации данных со стандартным значением для большинства инсталляций в мире).

    Еще одним фактом, касающимся надежности DWH, хотя и не красящим нас, является появление бэкапа: он у нас появился лишь в 2019 перед мажорным обновлением версии Vertica. И это при том, что до 2018 года наша Vertica была самой большой в СНГ (сейчас по объему вторая-третья, но по сложности самого хранилища, по-прежнему, первая).

    Обновлялись мы, кстати, сразу на 2 версии (7 -> 8, 8 -> 9). Ну, как обновлялись: в 13:00 остановили кластер и запустили .py скрипт от вендора, а в 21:10 мы уже открывали пиво, после того как кластер начал подниматься. Никаких эксцессов не было. И тут вспомнилась статья на Хабре от коллег из телекома про обновление кластера Greenplum c 4-ой до 5-ой версии. Так они, насколько помню, потратили сотни дней разработчиков на «costylmaking» из-за несовместимости типов данных между мажорными версиями одного продукта.

    Отчасти лукавлю, не рассказывая о сути стабильности нашего кластера, которая кроется в четкой настройке и управлении пулами ресурсов для оркестрации выполняющихся запросов. Это настоящее искусство, лежащее в основе DWH Vertica c uptime из множества девяток после запятой.

    Anchor modeling, Datavault 2.0 — всего этого у нас нет. Мы не фокусировались на жестком соблюдении какой-то одной изначально выбранной методологии, иначе сами себе устроили бы приключения. Почему? Хотя бы потому, что при разворачивании DWH, Yota была независимой компанией и крупнейшим оператором 4G, но предоставлявшим доступ в сеть только для модемных устройств. После покупки МегаФоном в Yota появились голосовые абоненты, а «голос» принципиально иной продукт, и мы бы просто не запустились в крайне сжатые сроки, если бы не определенная архитектурная свобода. У нас 37 схем, и архитектура внутри каждой не то, что схемы, но даже витрины, может отличаться от мейнстрима и выбирается в соответствии с решаемой задачей с учетом особенностей хранения в источниках.

    И еще момент — во внутренней команде нет ни архитектора, ни девопс-гуру. Они просто не нужны fulltime, т.к. Vertica не требует постоянного обслуживания. Эти роли у нас выполняются подрядчиком, а внутренняя команда сфокусирована на создании инструментов анализа бизнес-данных для всей компании и совместном с бизнесом улучшении продуктов. Как бы высокопарно это ни звучало, но Yota изначально — data driven business. У нас под сотню персональных учеток для adhoc-запросов и широкого доступа к данным всем, кому он нужен.

    В завершение разговора о Vertica хочется обсудить регулярно поднимающийся вопрос: «Дорого же! Зачем оно надо?». По моему скромному мнению, в бизнесе нет понятий «дорого/дешево», но есть понятие «эффективно/не эффективно». Давным-давно я работал в складской логистике, так вот, строительство склада начинается с изучения характеристик будущих единиц хранения (SKU) и потоков движения этих SKU. При проектировании хранилища ситуация должна быть аналогичной: изучение данных, подразумеваемых для обработки внутри DWH, выбор наиболее оптимальной архитектуры с параллельными расчетами финансовой модели. Звучит просто, но это позволит избежать догматов: «Делаем только на opensource» или «Наш потрясающий стартап может себе позволить Teradata в топ-комплектации». Пару месяцев назад создал модель Vertica total cost of ownership, и эффективность текущего решения Yota вышла оптимальной. Поделиться, к сожалению, по понятным причинам не смогу.

    Hadoop. Их у нас целых 2 кластера (Cloudera 6.3), которые мы используем как «дешевое» хранилище некритичных для бизнеса данных. К данным, хранящимся в наших Hadoop, не требуется скорость доcтупа, предъявляемая к Вертике. Здесь стоит отметить подставу со стороны Cloudera: когда мы наши Хадупы планировали и разворачивали в 2018-2019, то существовавшая Comminity Edition нас вполне устраивала; однако в феврале 2020 пришла «полярная лисичка» в виде изменения политики лицензирования и, по сути, отмены т.н. free версий. Из-за этого вынуждены думать сейчас о редеплое кластера из 23 нод на CH 5.16 с потерей данных (ими можно пожертвовать). А на маленький кластер Hadoop вынуждены оформлять ненужную нам лицензию.

    Oracle. Легаси-вишенкой на торте DWH выступает хранилище Oracle объемом всего 1.4 Tb. Его мы иногда используем для собственной обработки в ODS слое высокочастотных потоков малонасыщенных данных. Например, 100 000 файлов в сутки по несколько строк в каждом, конечно, можно писать в Вертику напрямую, но разумнее сначала в транзакционную БД, а уже затем часовыми батчами в DWH. Движемся дальше.

    2. ETL


    В нашем случае зачастую ELT, так как наше DWH позволяет перемалывать терабайты внутри себя без реализации стадии Transform на относительно слабых ETL-серверах.

    Высоконагруженные потоки данных. У нас 9 пайплайнов по 2-8 ETL-джобов в каждом. Они редко меняются, и поскольку границы не выходят за staging слой, то мы отдали их нашим подрядчикам. Тем же, которые поддерживают Vertica. Коллеги написали свой EasyLoader на Groovy 3, который сами и поддерживают. EasyLoader вполне неплохо перемалывает свой 1 Tb в сутки, поступающий в Vertica, и до 10 Tb в большой Hadoop.

    Из интересного стоит упомянуть используемый нами механизм CDC от Oracle — Oracle Golden Gate. Kafka пока не используем, но, возможно, начнем, т.к. переезд на Oracle 19 имеет специфичную реализацию Oracle for BigData вместо старого доброго OGG. На текущий момент мы еще в процессе исследований, но как бы не пришлось свои костыли писать…

    Остальные потоки данных. Здесь кроется соль нашего решения — формирование промежуточных и конечных витрин как на основе данных из п. 2.1, так и на собственных интеграциях примерно с 150 системами-источниками. Этим занимается исключительно внутренняя команда. Здесь примерно 1150 ETL-джобов. В основе стэка разработки: Talend Data Integration 7.1. Инструмент условно бесплатный. Условно, т.к. требует лицензии для использования среды выполнения и оркестрации. Я уже не застал того благостного времени, когда использовалась Talend Administration Console, но старшие товарищи рассказывали, что это был тот еще садомазочуланчик папаши Мюллера образцовый UI, привносящий незабываемый UX. Можно, конечно, деплоить джобы Talend в виде .zip пакетов сразу в .sh и оркестрировать в cron, а потом грепать логи. Но было решено еще в 2016 году, что деплоить джобы Talend будем сразу в EasyScheduler (рантайм с web UI для доступа к нему). Который, как уже понятно, написал под нас тот же самый подрядчик. Разумеется, и лицензия стоит дешевле чем TAC, UI оставляет более позитивный UX, и доработки под наши пожелания не затягиваются во времени.

    Пара слов про Talend Data Integration. Это среда «визуального» программирования потоков интеграции. Сам инструмент не уступает Informatica PowerCenter по производительности. JVM под капотом у обоих. Максимум, что придется писать руками — SQL для стадии Transform внутри некоторых компонентов, но его и нет смысла пытаться чем-то заменить. Чтобы не было сомнений в возможностях Talend и иных интеграционных комбайнов, 2 факта:

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

    3. Визуализация данных


    Используем следующие инструменты: MS Analysis Services, Tableau, есть у нас и любимое легаси в виде SAP BO.

    MS Analysis Services. Исторически аналитические кубы были значимым инструментом. В проде у нас всего 16 кубов весом от 6 Mb до 144 Gb, а через пару месяцев после доработок и до 200 Gb. В 2020 году возникла идея о возможном переносе кубов в Tableau, но там уже при экстракте в 5 Gb дэшборд стал люто тормозить. В нашем случае платформа оказалась безальтернативной. Кстати, используем последний free version MS AS 11. Не PowerBI, конечно, но нулевые траты на лицензии нас вполне устраивают.

    Tableau. На конец 2020 у нас было 277 дэшбордов, и бизнесу они адски «заходят». Одна из целей 2021 — максимальная автоматизация «ручной отчетности» аналитиков. И тут мы споткнулись, т.к. наши аналитики, как и любые нормальные аналитики, для прототипирования используют Excel. Без шуток.

    Есть у этих самых аналитиков любовь к типам диаграмм 'водопад':

    Прошу прощения за низкое качество изображения, но суть передана верно

    Очень круто выглядит и нравится топ-менеджменту. Как бывший аналитик данных, сам кайфую, когда вижу такую красоту. Но чтобы реализовать такой «водопад» в Tableau, нужно сделать 5 графиков, обеспечить синхронизацию фильтров между ними… Ок, пару накликать можно. А если в дэшборде их 171? Ну, вы поняли. На одной стороне весов 12 человеко-часов аналитиков на ежемесячный сбор презентации. На другой — полгода разработки сеньором + 100% гарантия превращения дэшборда в «недвижимость». Недавно был тяжелый разговор с аналитиками, где мы зафиксировали, что такой красоты может быть не больше 2-3 графиков на весь дэшборд. Но продолжаем искать пути автоматизации именно этого типа визуализации в юзкейсах наших аналитиков — адская идея скриптами powershell повторить ручные действия в Excel (там их пилят при помощи платной надстройки ThinkCell) пока не отпала. Офтопом стоит отметить сам факт повторения многостраничных презентаций в Tableau, где на самом деле однотипные данные «намертво распечатаны в .pdf во всех возможных измерениях имеющихся в дэшборде». Конечно же, подход спорный, но мы очень клиентоориентированы по отношению к внутренним заказчикам, и мысли об изменении в сторону «сторителлинга» аккуратно и потихоньку продвигаем в жизнь.

    Sap BO. Очевидная legacy система визуализации — устаревшая чуть более, чем полностью. Аккуратно уходим от нее в сторону более современных и гибких решений, т.к. она прекрасна для point-to-point повторения отчетов (именно тут необходимо собирать большие и однотипные презентации аналитиков, но трудозатраты будут еще выше, да и такие «водопады» вообще не факт, что реализуемы в SAP BO), но не позволяет создавать интерактивные дэшборды. Следует отметить, что сам подход реализации point-to-point больших презентаций актуален для большого российского бизнеса, например, из сферы добычи сырья. В 2к21 это, на мой взгляд, выглядит морально устаревшим, особенно для Yota, средних размеров data driven business. Поэтому нам не имеет смысла заниматься реализацией «намертво прибитых» по брендбуку отчетов на миллион вкладок/страниц.

    Инструменты анализа должны быть максимально интерактивными и понятными. Мечта главного «табловеда» — дэшборд в виде смартфона по аналогии с известным дэшбордом McDonalds. Я с ним полностью согласен.

    4. Data science (machine learning)


    Кроме классического BI в отделе есть команда DS и, надеюсь, в этом году здесь появится ссылка на статью о Data Science в Yota, написанную профессионалом. Я таковым не являюсь, т.к. вырос из разработчиков классического BI. Извините, если кто-то зашел сюда только ради этого :-)

    5. Agile? Нет… У нас своё


    Самый спорный пункт повествования. Рассказываю исключительно с целью поделиться тем, как у нас все работает, и почему не планируем менять на что-то более привычное и непротиворечивое.

    В направлении классического BI — 6 инженеров и тимлид. При этом нет ни выделенных архитекторов, ни аналитиков, ни тестировщиков, ни релиз-менеджеров. Каждый инженер = BI-фулстэк, реализует задачу «под ключ», напрямую общаясь с бизнес-заказчиком и лично ответственен за конечный результат. «Кодеров по ТЗ»/токсичных «рок-звезд» нет и не будет от слова «совсем». Но у всей команды изначально хорошие софт-скилы вдобавок к хард. В теории взаимозаменяемы, но жизнь вносит свои коррективы, и кто-то оказывается более сильным в ETL, а кому-то интереснее визуализация в Tableau — пожелания в развитии каждого учитываются и мной, и тимлидом.

    Работа по заявке идет с упором на 2 показателя: time-to-market (TTM) и customer satisfaction index (CSI). Причем сразу на проде, если речь об ETL-задачах в DWH. Тестовая зона, конечно же, есть, но подготовка данных на наших объемах занимает сильно больше времени, чем сама разработка. Важный момент: сообщения в чате наподобие «ой, я оттранкейтил справочник...» встречаются не чаще 1-2 раз в год и исправляются за 5-10 минут. Потерь невосстановимых, критичных для компании данных я не помню. В этом плане интереснее обращения от коллег из систем-источников на 100% реплицируемых в DWH с просьбой выслать из нашего бэкапа какую-нибудь таблицу фактов, которую массово проапдейтили, но что-то пошло не так… За последний год такое было 2 раза.

    Вы спросите, почему все так необычно устроено?

    Кроме самого исчерпывающего объяснения

    Так повелось в этом нашем лесу (с)

    Есть очевидные минусы, с которыми мы умеем жить:

    • Быстроменяющаяся архитектура BI-решения является черным ящиком для всех смежных команд. Эта статья — первый из шагов по расшариванию знаний о нашем решении.
    • Отток в команде потенциально критичен. Однако стабильность команды и преемственность нивелируют этот минус.

    и плюсы:

    • Высокий TTM и высокая пропускная способность команды в целом. Весь проектный портфель компании (почти во всех проектах есть фичи на отдел) составляет 15-20% общего объема разработки отдела. Остальное — прямые пожелания конечных бизнес-заказчиков, реализуемые с минимумом бюрократии.
    • Стабильно высокий CSI, демонстрирующий правильность выбранного подхода в организации разработки. Один раз в квартал мы проводим опрос среди бизнес-заказчиков. В 4Q20 из 43 респондентов ответили 21. По итогу получили 4,89 из 5. Это упавший CSI, хотя я предполагал падение до 4,5. Стандартно у нас ближе к 5. Объясняется это гибкостью в подходе к реализациям задумок бизнес-заказчиков и скоростью появления конечного результата с максимально эффективным использованием имеющихся инструментов/технологий.

    В опросе CSI также можно оставить комментарий, например такой


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

    Пользуясь случаем хочу поблагодарить #BI_TEAM за стабильно высокие результаты: ребята — вы крутые, мне повезло работать со всеми вами! Спасибо.

    6. Заключение


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

    По идее здесь должны быть вакансии отдела, но извините – full house) И даже есть небольшой лист ожидания… Однако в соседних, не менее интересных, командах еще требуются люди. Буду рад комментариям – нам есть куда расти.
    Yota
    Company

    Comments 40

      +1
      >>5. Agile? Нет… У нас своё

      супер, спасибо, что поделились. Тоже опытным путем пришли к точно такому же подходу как и вы: тимлид и фулл-стек БИ, у каждого свои сильные стороны: есть Табло-джедай мастер, есть волшебник SSIS, есть черный маг по SQL, и т.д: целая MMORPG команда.

      "«Кодеров по ТЗ»/токсичных «рок-звезд» нет и не будет от слова «совсем»." — очень правильный подход, к сожалению в моей ситуации тимлид токсичный рокстар, но это скоро решится сменой работы (мною и другими членами команды)
        0
        но это скоро решится сменой работы (мною и другими членами команды)
        сурово, но такова правда жизни. Видел похожие кейсы в иных места и не хочу допустить подобного развития событий в своей команде. Хотя повторюсь, мне повезло — ребята классные (я не всех нанимал, т.к. стал руководителем лишь в сентябре 2020, но с большинством работаю давно, т.к. сам вырос из разработчиков).
        0
        В таких статьях про аналитику очень хочется увидеть влияние проведенного анализа на бизнес решения.
        Тут за сотню дашбордов, много сотен частных задач! Это громадный тезаурус наверно. И мегаватты вычислений!!!
        Но вот самое интересное — система приняла 1 Тб и на одном дашборде поменялся индикатор один с ххх на yyy и есть искушение добавить и обратную связь и выдать сразу управленческое решение — «поменять в тарифе А цену с Х на Y»
        Ведь у управленцев не так много и «рычагов» управления — тариф поменять/добавить/убрать, денег добавить IT, вышку переставить и т.п. Выбор то существенно ограничен.
          0
          То о чем вы спрашиваете будет в 4 разделе статьи описано в рамках конкретных кейсов, но уже не мной) А вообще BI (включая рекомендательные сервисы интегрированные с управленческой и операционной отчетностью) и существует для того чтобы помогать принимать серьезные управленческие решения.
          0
          не понял акробатику с cloudera, какой смысл с 6.3 переезжать на 5.x? закрыли доступ к бинарникам они в на 6.3, если 6.3 успели скачать, зачем переезжать?
          161 Тб в вертике, это же наверно миллионы $$$ в год. я угадал?

          и еще, у на BO внедряли именно под соусом self BI, только он позволял пользователю самому рисовать отчеты какие надо
            0
            закрыли доступ к бинарникам они в на 6.3, если 6.3 успели скачать, зачем переезжать?
            если бы Yota была полностью независимой компанией, то конечно смысла нет — Вы правы. Но в материнской компании увидели риски.
            миллионы $$$ в год. я угадал?
            не угадали. Такой OPEX разве, что у Teradata может быть, но это лишь мое предположение.
            и еще, у на BO внедряли именно под соусом self BI, только он позволял пользователю самому рисовать отчеты какие надо
            круто, если у Вас так (подробнее расскажете?). Нам все равно приходиться делать все сложные визуализации самим. Не более 10% реализуется силами самих бизнес-заказчиков, а они у нас весьма скиловые. «self BI» — звучит круто в теории, а на практике только Excel может быть действительно self. Было бы круто услышать, если у кого встречаются кейсы аналогичные Вашему.
              0
              если бы Yota была полностью независимой компанией, то конечно смысла нет — Вы правы. Но в материнской компании увидели риски.

              не догоняю, в чем может быть преимущество 5.х без супорта над 6.3 без супорта?

              круто, если у Вас так (подробнее расскажете?). Нам все равно приходиться делать все сложные визуализации самим.


              я относительно далек от BI, но видел внутренние презентации. сложные визуализации делают на qlik, но замахались и в дополнение купили BO. презентовали, как тулзу подходящую продвинутым бизнес пользователям, которым будет быстрее (и дешевле) простые отчеты самим рисовать. показывали иерархическую структуру из нашей основной витрины, от туда можно было брать колонки и накидывать в пивот, BO сам догадывался как там чего заджоинить. простенькие графики / пирожки показывали. с виду выглядело много примитивней, чем у powerbi и соответственно много проще для бизнес пользователя.
              со стороны не выглядело как легаси. выглядело как более простенький тул, с которым у бизнес пользователя есть шанс справится без программиста
                0
                в чем может быть преимущество 5.х без супорта над 6.3 без супорта?
                особенности договорных отношений материнской компании и Cloudera (извините, без подробностей). Но для кейсов использования Hadoop в нашем случае support и не требуется.
                со стороны не выглядело как легаси. выглядело как более простенький тул, с которым у бизнес пользователя есть шанс справится без программиста
                насколько снизилась нагрузка от «бизнеса»? Пока звучит как предпосылки для реализации, которая случилась недавно. Искренне интересен результат (может мы не так своих вовлекаем?).
                  0
                  особенности договорных отношений материнской компании и Cloudera (извините, без подробностей). Но для кейсов использования Hadoop в нашем случае support и не требуется.

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

                  насколько снизилась нагрузка от «бизнеса»? Пока звучит как предпосылки для реализации, которая случилась недавно. Искренне интересен результат (может мы не так своих вовлекаем?).

                  тут особо рассказать не могу, мы данные процессим, а BI — отдельное царство куда у нас и доступа нет. на их страничке видно что что-то запустили, 150 юзеров лицензировано, подозреваю многие счастливы просто потому что альтернатива ждать когда кто-то наверху приоритизирует запрос на отчетик.
                  а так хоть что-то сами накликать могут.
                    0
                    У нас примерно также работает, но заказчики предпочитают «ходить к нам ногами» с приоритезацией.
                    тут особо рассказать не могу, мы данные процессим
                    а сферу и примерный размер(годовой оборот) компании можете назвать?
                      0
                      у нас теперь некая CAB session prioritizton хождение с заказами остановила. стало очень удобно отмазываться — CAB не приоритизировал, не можем взять в спринт.
                      кантора здоровая, фин услуги в европе, 24 страны, оборот под млрд евро.
                        0
                        отмазываться — CAB не приоритизировал, не можем взять в спринт.
                        счастливые… У нас по-иному построено, мы на своих бизнес-заказчиков не «кладем»… хотя, иногда, хочется)
                  0
                  не догоняю, в чем может быть преимущество 5.х без супорта над 6.3 без супорта?

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

                  Все отношения с Клаудера могут разруливаться через локального multiple service provider'а и купить саппорт даже в госухе под санкциями не проблема.
                    0
                    там чуть выше товарищ утверждает, что на 5.х у них какие-то секретные договоренности с клоудерой, каких нет на 6.х.
                      0
                      Ерунда какая то. Что 5ка есть community что 6ка. Community edition нет только у CDP 7. Единственная договоренность которая может быть с cloudera — это саппорт через локального провайдера поддержки, но при условии если поддержка покупается напрямую у cloudera, а не через реселера (IBM->МОНТ->клиент), например. К версии это никакого отношения не имеет. Хочется все же комментарии автора увидеть.
              0

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

                0
                Не очень понятно о каком именно архитекторе речь:

                • если речь об архитекторе DWH, то я описал кто ее выполняет (подрядчик)
                • если речь об «архитекторе всего решения», то выделенной роли нет, т.к. она не нужна в нашей модели разработки при которой один инженер выполняет задачу целиком; в случае необходимости с кем-то посоветоваться есть senior, тимлид, либо руководитель, но вообще 99% всех сложных вопросов решаются в чате

                т.е. дополнительных рисков, кроме описанных в статье, нет. Но может быть я не понял комментария?
                0

                Спасибо за пост.
                Если сейчас бы у вас был выбор бесплатного решения для DWH, что вы бы выбрали в 2021 году?
                Какой бесплатный дистрибутив Hadoop вы бы выбрали сейчас? Репозитории HortonWorks доступны до сих пор.
                Спасибо!

                  0
                  Проектирование DWH начинается, на мой взгляд, не с выбора технологий, а с анализа конечной цели.

                  Пример из складской логистики в которой я когда-то хорошо разбирался: решение о том, каким будет склад принимается на основе анализа потоков товаров (частота движения stock keeping unit) и анализа метрических параметров самой единицы хранения. Когда создана модель движения товаров, то посчитать экономику и выбрать наиболее оптимальную технологию хранения — уже просто.

                  С DWH полностью аналогично — анализ потоков данных, которые предполагается хранить и обрабатывать. Анализ частоты обращения к данным и приемлемой скорости ожидания ответа в том числе при ad-hoc выборках. После создания модели движения данных выбирается модель построения хранилища. Затем «натягивается» экономика решения. И только потом выбирается opensource или проприетарный вариант. Вполне возможна ситуация, при которой эффект для бизнеса будет таким, что лицо принимающее решение утвердит Teradata в качестве единственного варианта.

                  Отвечая на Ваш вопрос следует все же помнить об объемах, если данных в перспективе пары лет будет до 1 Тб и ad-hoc аналитики будут делать на паре млн строк, то зачем Hadoop? Хватит хорошей OLTP БД: наподобие Postgress (а дальше можно будет задуматься о Greenplum познав, что такое боль и унижение) или Maria DB (у них на июнь 2020 в бэте уже были колоночные решения).

                  А по вопросу дистрибутива Hadoop (но это на мой взгляд все-таки не про DWH, а про Data lake) у меня нет ответа, т.к. на горизонте 5-7 лет не вижу смысла использовать репозитории хотя и доступные, но считайте мертвого продукта. MapR RIP. Остается Cloudera, которая начала зарабатывать деньги причем очень резво. ArenaData — тут еще менее понятно на длительном горизонте планирования. С учетом сложностей в определении дистрибутива разбираться в зоопарке Hadoop становиться, на мой взгляд, еще менее интересно. Хотя кому-то может зайти Impala, Druid, Flume, но это от конкретных задач конечно же зависит.
                    0
                    Мне кажется у вас весьма поверхностные представления о возможностях Cloudera Hadoop. Это коробка полностью решает задачи классического DWH при правильных архитектурных подходах, а не только Data Lake. В том числе OLTP и time series нагрузку.
                    Все остальные дистрибутивы по факту это как раз боль и унижение, включая названными вами отечественный креатив. Именно потому он и позиционируется как часть какой то общей гетерогенной архитектуры в составе которой есть сборка GreenPlum.
                    Teradata это конечно технологический труп, от которого воняет уже лет 5 как.
                  0
                  промахнулся ответом
                    0
                    буду рад услышать об иных решениях, позволяющих обычным аналитикам в adhoc запросах оперировать >1 трлн строк за разумное время в минутах и без поддержки команды data engineer + dataops.
                    Exasol, Oracle Exadata. Поверх Hadoop — Jupyter Notebook, Apache Zeppelin, SmartView.
                    Поверх упомянутой Cloudea есть Cloudera Data Platform (CDP) Data Visualization (DV).

                    переезд на Oracle 19 имеет специфичную реализацию Oracle for BigData вместо старого доброго OGG. На текущий момент мы еще в процессе исследований, но как бы не пришлось свои костыли писать
                    Может, Вас с решениями Attunity познакомить, если аналог GG нужен? Можем дать поиграться.
                      0
                      Exasol

                      есть ли в России похожие реализации? Слышал только о Badoo, но там размеры кластера сильно меньше были в 2015 и непонятно как сейчас. Насколько знаю, Exasol преимущественно in-memory DB, т.е. не наш кейс.
                      Oracle Exadata

                      без подробностей, но как раз сравнивали большой prod кластер Exadata c нашим DWH на боевых данных. Exadata предсказуемо проиграла Vertica по скорости выполнения запросов, т.к. по сути есть шардированный Oracle. Данные были практически идентичными. Правда, не знаю об Exadata ничего с точки зрения TCO.
                      Поверх Hadoop — Jupyter Notebook, Apache Zeppelin, SmartView

                      мы с Вами под «аналитиками» понимаем разных пользователей. Мои даже слов таких не знают)
                      Поверх упомянутой Cloudea есть Cloudera Data Platform (CDP) Data Visualization (DV).

                      Предположу, что Вы лишь умозрительно допустили соответствие любых продуктов Hadoop условию «в adhoc запросах оперировать >1 трлн строк за разумное время в минутах». Насколько понимаю, это лицензионное название решения, где есть используемая нами Impala и производительность там ни разу ни на уровне Вертики отличаясь на 1-2 порядка. Хотя железо идентичное по CPU, RAM, сети (но для Vertica используются гораздо более производительные диски и нод в полтора раза больше).
                      Attunity

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

                        есть ли в России похожие реализации?


                        Ситимобил. Но это im-memory, да. Для решения оптимизационных задач, судя по всему.


                        мы с Вами под «аналитиками» понимаем разных пользователей. Мои даже слов таких не знают)


                        Меня смутило, что аналитикам нужно ">1 трлн строк за разумное время в минутах". Это ближе к Дата-сатанистам. Для selfe-service BI обычно нужно гораздо меньший объем транзакций гражданским аналитикам давать.

                          0
                          Меня смутило, что аналитикам нужно ">1 трлн строк за разумное время в минутах"… Для selfe-service BI обычно нужно гораздо меньший объем транзакций гражданским аналитикам давать.
                          Могу только повторить тезис из статьи «Как бы высокопарно это ни звучало, но Yota изначально — data driven business.» Так уж повелось, что доступ к данным внутри компании открыт для всех кому он необходим (под чутким надзором ИБ). Не я это придумал, но я полностью поддерживаю идею открытости. Да и трлн. строк о которых писал выше — это агрегаты(!). Первичные данные мы не храним ибо стоимость хранения будет космической и для компании это неэффективно.
                          Это ближе к Дата-сатанистам.
                          как сказал мой знакомый Архитектор Data SatansScience: «настоящая BigData — только в телекоме». Наверное, он прав.
                            0

                            В целом, люди чаще совершают звонки и пользуются интернетом, чем совершают покупки или финансовые операции. Но коллеги из поисковых систем, социальных сетей, крупных финансовых или торговых организаций, а так же кто занимается iot и m2m, скорее всего, поставят под сомнение что BD "только в телекоме" :D

                              0
                              Я полностью согласен с тем, что в России условный Яндекс + mail.ru + Сбер могут дать фору некоторым (но не всем) телеком-провайдерам. Однако «iot»-провайдеры вряд ли пропускают через себя петабайты данных в сутки… Но смысл спорить о «линейке»?)
                          0
                          «Предположу, что Вы лишь умозрительно допустили соответствие любых продуктов Hadoop условию «в adhoc запросах оперировать >1 трлн строк за разумное время в минутах». Насколько понимаю, это лицензионное название решения, где есть используемая нами Impala и производительность там ни разу ни на уровне Вертики отличаясь на 1-2 порядка. Хотя железо идентичное по CPU, RAM, сети (но для Vertica используются гораздо более производительные диски и нод в полтора раза больше).»

                          Наверное вряд ли при этом вы являлись экспертами по правильной настройке Impala и Hadoop под Impala. Иначе я не могу объяснить как она могла слить на 1-2 порядка Vertica с учетом того что Impala читает только те блоки, данные которых удовлетворяют соединения и условиям выборки (storage индексы), а в версии 3.4 на CDP появились еще страничные индексы уровнем ниже. Vertica так будет делать (тн SIP фильтр) если у вас сортировка колонки есть и правльная сегментация. Те ФМД вы заранее готовите под свои запросы. При внезапном ad-hoc с hash join Vertica превращается в обычную тыкву.

                          Другими словами, если сравнивать решение с тз cost per performance, то у Cloudera c Impala в качестве процессингового движка конкурентов нет.
                            0
                            При внезапном ad-hoc с hash join Vertica превращается в обычную тыкву.
                            напишите в личку Ваш профиль в телеге, добавлю в чатик пользователей Вертики (если Вас там еще нет), где над такими проблемами если и улыбнуться, но точно помогут не превращать в тыкву Вертику. Особенно там, где это еще и постараться надо сделать. Иногда и сам там помогаю страждующим, но редко читаю чат целиком.

                            Другими словами, если сравнивать решение с тз cost per performance, то у Cloudera c Impala в качестве процессингового движка конкурентов нет.
                            Вы ведь понимаете, что без конкретики звучит не сильно убедительно? Напишите о своем опыте развернуто. Видно, что Вам есть, что написать по сути — на Хабре мало приличных статей о хранилищах данных и экосистеме BI. Но пока лишь мнение против мнения (хотя мое развернуто в статье корпоративного блога настолько насколько это возможно).

                            PS: забавно, что Вы работаете в компании, которая 4 года назад была подрядчиком Yota BI по теме визуализации в SAP BO и пр. несложных работах. Но Вас не помню в той команде, которая на уровень архитектуры решения не выходила
                              0
                              Опыта работы с Vertiсa у меня ничуть не меньше вашего и помощь мне не требуется. Причем реального проектного, со слоями трансформации данных, витринами, аналитическими слоями и тд. Про чатик знаю, но не состою.

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

                              В видео варианте по Cloudera можно посмотреть тут, например: www.youtube.com/watch?v=iXoWA9XP2xw&list=PLqYhGsQ9iSEoE10dyEjp5QtVrNo-g92gC

                              Насчет вашего воспоминания забавного ничего нет. GBC был подрядчиком не 4 года назад, а 2013 году. Но по иронии в той команде я состоял, несмотря на той что в тот момент у вас работало около 250 чел, но занимался исключительно той частью вашего ХД что была на Oracle. Можете взять референс у того кто с вашей стороны руководил вашим подразделением — Алексей Щеглов (у вас давно не работает).
                                0
                                Насчет вашего воспоминания забавного ничего нет. GBC был подрядчиком не 4 года назад, а 2013 году. Но по иронии в той команде я состоял, несмотря на той что в тот момент у вас работало около 250 чел, но занимался исключительно той частью вашего ХД что была на Oracle. Можете взять референс у того кто с вашей стороны руководил вашим подразделением — Алексей Щеглов (у вас давно не работает).
                                Получается мы оба правы. GB до начала 2017 был у нас на контракте. Oracle DWH уже при мне был немного староват, а сейчас вообще отказываемся от него в изначальном виде. А Лешу помню, хотя вместе и не работали (он ушел до моего прихода).

                                Искренне жду Вашу статью — на Хабре и правда мало хороших материалов по экосистемам BI.
                                  0
                                  Ну а я на проекте оракловом был до 2014 года и ушел в другую команду еще раньше чем Леша из йота.
                        0
                        опять промахнулся(
                          +1
                          под ETL apache airflow не рассматривали?

                          Informatica PowerCenter уже устарела и не поддерживается, сейчас Informatica Big Data Management больше актуальнее
                            0
                            под ETL apache airflow не рассматривали?
                            Если бы сейчас создавали с 0, рассматривали бы. А в далеком 2012 до Airflow было 2 года, а до Apache Airflow — 4. Но сейчас наши инструменты нас полностью устраивают.
                            Informatica PowerCenter уже устарела и не поддерживается, сейчас Informatica Big Data Management больше актуальнее
                            Вы правы. Но от перемены названий суть продукта кардинально не поменялась — как был JVM под капотом, так он и остался. Остальное маркетинг.
                              0

                              Как насчёт DugitalRoute Mediation Zone? Оно же SAP CM?
                              Специально для телекома было сделано.

                                0
                                DugitalRoute Mediation Zone
                                Такие штуки, создаются под конкретного заказчика, и если не умирают, а переходят в стадию зрелого продукта, то покупаются большим игроком.
                                Оно же SAP CM?
                                Подтверждение моего предположения.

                                А все это я к тому, что бенефициаром оказывается лишь самый 1 клиент, под которого оно писалось, а для остальных внедрять такое комплексное решение — боль. Yota уже 14 лет существует и для нас рассматривать такие решения применительно только к BI — из области фантастики.

                                Все вышесказанное лишь мое скромное ИМХО с которым вполне можно поспорить.
                                  0

                                  Такая штука работает у многих операторов в мире. Она не была создана под конкретного заказчика. Это скорей набор инструментов. Под конкретный проект, настраивается индивидуально.
                                  В Ростелекоме без боли внедрено и работает уже давно (примерно с 2013 года), например.


                                  SAP их не купил. Они перепродают его под своим брендом.

                                    0
                                    Спасибо, буду знать для общего развития. Но для нашего кейса — не вариант. Да и упомянутый Вами оператор, с точки зрения BI, ни разу не бенчмарк.

                                    Но меня все-таки не покидает чувство, что переход на такие системы при полностью устраивающей собственной экосистеме — это как менять биллинг в успешно работающем телеком-операторе: дорого, больно, а главное не понятно «зачем?».
                                      0

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

                          Only users with full accounts can post comments. Log in, please.