Comments 40
>>5. Agile? Нет… У нас своё
супер, спасибо, что поделились. Тоже опытным путем пришли к точно такому же подходу как и вы: тимлид и фулл-стек БИ, у каждого свои сильные стороны: есть Табло-джедай мастер, есть волшебник SSIS, есть черный маг по SQL, и т.д: целая MMORPG команда.
"«Кодеров по ТЗ»/токсичных «рок-звезд» нет и не будет от слова «совсем»." — очень правильный подход, к сожалению в моей ситуации тимлид токсичный рокстар, но это скоро решится сменой работы (мною и другими членами команды)
супер, спасибо, что поделились. Тоже опытным путем пришли к точно такому же подходу как и вы: тимлид и фулл-стек БИ, у каждого свои сильные стороны: есть Табло-джедай мастер, есть волшебник SSIS, есть черный маг по SQL, и т.д: целая MMORPG команда.
"«Кодеров по ТЗ»/токсичных «рок-звезд» нет и не будет от слова «совсем»." — очень правильный подход, к сожалению в моей ситуации тимлид токсичный рокстар, но это скоро решится сменой работы (мною и другими членами команды)
но это скоро решится сменой работы (мною и другими членами команды)сурово, но такова правда жизни. Видел похожие кейсы в иных места и не хочу допустить подобного развития событий в своей команде. Хотя повторюсь, мне повезло — ребята классные (я не всех нанимал, т.к. стал руководителем лишь в сентябре 2020, но с большинством работаю давно, т.к. сам вырос из разработчиков).
В таких статьях про аналитику очень хочется увидеть влияние проведенного анализа на бизнес решения.
Тут за сотню дашбордов, много сотен частных задач! Это громадный тезаурус наверно. И мегаватты вычислений!!!
Но вот самое интересное — система приняла 1 Тб и на одном дашборде поменялся индикатор один с ххх на yyy и есть искушение добавить и обратную связь и выдать сразу управленческое решение — «поменять в тарифе А цену с Х на Y»
Ведь у управленцев не так много и «рычагов» управления — тариф поменять/добавить/убрать, денег добавить IT, вышку переставить и т.п. Выбор то существенно ограничен.
Тут за сотню дашбордов, много сотен частных задач! Это громадный тезаурус наверно. И мегаватты вычислений!!!
Но вот самое интересное — система приняла 1 Тб и на одном дашборде поменялся индикатор один с ххх на yyy и есть искушение добавить и обратную связь и выдать сразу управленческое решение — «поменять в тарифе А цену с Х на Y»
Ведь у управленцев не так много и «рычагов» управления — тариф поменять/добавить/убрать, денег добавить IT, вышку переставить и т.п. Выбор то существенно ограничен.
не понял акробатику с cloudera, какой смысл с 6.3 переезжать на 5.x? закрыли доступ к бинарникам они в на 6.3, если 6.3 успели скачать, зачем переезжать?
161 Тб в вертике, это же наверно миллионы $$$ в год. я угадал?
и еще, у на BO внедряли именно под соусом self BI, только он позволял пользователю самому рисовать отчеты какие надо
161 Тб в вертике, это же наверно миллионы $$$ в год. я угадал?
и еще, у на BO внедряли именно под соусом self BI, только он позволял пользователю самому рисовать отчеты какие надо
закрыли доступ к бинарникам они в на 6.3, если 6.3 успели скачать, зачем переезжать?если бы Yota была полностью независимой компанией, то конечно смысла нет — Вы правы. Но в материнской компании увидели риски.
миллионы $$$ в год. я угадал?не угадали. Такой OPEX разве, что у Teradata может быть, но это лишь мое предположение.
и еще, у на BO внедряли именно под соусом self BI, только он позволял пользователю самому рисовать отчеты какие надокруто, если у Вас так (подробнее расскажете?). Нам все равно приходиться делать все сложные визуализации самим. Не более 10% реализуется силами самих бизнес-заказчиков, а они у нас весьма скиловые. «self BI» — звучит круто в теории, а на практике только Excel может быть действительно self. Было бы круто услышать, если у кого встречаются кейсы аналогичные Вашему.
если бы Yota была полностью независимой компанией, то конечно смысла нет — Вы правы. Но в материнской компании увидели риски.
не догоняю, в чем может быть преимущество 5.х без супорта над 6.3 без супорта?
круто, если у Вас так (подробнее расскажете?). Нам все равно приходиться делать все сложные визуализации самим.
я относительно далек от BI, но видел внутренние презентации. сложные визуализации делают на qlik, но замахались и в дополнение купили BO. презентовали, как тулзу подходящую продвинутым бизнес пользователям, которым будет быстрее (и дешевле) простые отчеты самим рисовать. показывали иерархическую структуру из нашей основной витрины, от туда можно было брать колонки и накидывать в пивот, BO сам догадывался как там чего заджоинить. простенькие графики / пирожки показывали. с виду выглядело много примитивней, чем у powerbi и соответственно много проще для бизнес пользователя.
со стороны не выглядело как легаси. выглядело как более простенький тул, с которым у бизнес пользователя есть шанс справится без программиста
в чем может быть преимущество 5.х без супорта над 6.3 без супорта?особенности договорных отношений материнской компании и Cloudera (извините, без подробностей). Но для кейсов использования Hadoop в нашем случае support и не требуется.
со стороны не выглядело как легаси. выглядело как более простенький тул, с которым у бизнес пользователя есть шанс справится без программистанасколько снизилась нагрузка от «бизнеса»? Пока звучит как предпосылки для реализации, которая случилась недавно. Искренне интересен результат (может мы не так своих вовлекаем?).
особенности договорных отношений материнской компании и Cloudera (извините, без подробностей). Но для кейсов использования Hadoop в нашем случае support и не требуется.
так дело не в супорте, а доступе бинарникам, патчам. ну ясно, на 5.х какие-то договоры есть.
насколько снизилась нагрузка от «бизнеса»? Пока звучит как предпосылки для реализации, которая случилась недавно. Искренне интересен результат (может мы не так своих вовлекаем?).
тут особо рассказать не могу, мы данные процессим, а BI — отдельное царство куда у нас и доступа нет. на их страничке видно что что-то запустили, 150 юзеров лицензировано, подозреваю многие счастливы просто потому что альтернатива ждать когда кто-то наверху приоритизирует запрос на отчетик.
а так хоть что-то сами накликать могут.
У нас примерно также работает, но заказчики предпочитают «ходить к нам ногами» с приоритезацией.
тут особо рассказать не могу, мы данные процессима сферу и примерный размер(годовой оборот) компании можете назвать?
не догоняю, в чем может быть преимущество 5.х без супорта над 6.3 без супорта?
По этому вопросу полностью поддержу. Смысла нет никакого, учитывая что шестерка все так же и остается бесплатной с комьюнити версией. Правда на днях закрыли дистрибутив для свободного скачивания на официальном сайте, но никто не мешает ставить со скаченного дистрибутива.
Все отношения с Клаудера могут разруливаться через локального multiple service provider'а и купить саппорт даже в госухе под санкциями не проблема.
По этому вопросу полностью поддержу. Смысла нет никакого, учитывая что шестерка все так же и остается бесплатной с комьюнити версией. Правда на днях закрыли дистрибутив для свободного скачивания на официальном сайте, но никто не мешает ставить со скаченного дистрибутива.
Все отношения с Клаудера могут разруливаться через локального multiple service provider'а и купить саппорт даже в госухе под санкциями не проблема.
там чуть выше товарищ утверждает, что на 5.х у них какие-то секретные договоренности с клоудерой, каких нет на 6.х.
Ерунда какая то. Что 5ка есть community что 6ка. Community edition нет только у CDP 7. Единственная договоренность которая может быть с cloudera — это саппорт через локального провайдера поддержки, но при условии если поддержка покупается напрямую у cloudera, а не через реселера (IBM->МОНТ->клиент), например. К версии это никакого отношения не имеет. Хочется все же комментарии автора увидеть.
Про архитектора то лукавство — позиции может и нет, но ведущая роль по-любому на ком-то висит. И это ещё один сигнал, что копятся риски, связанные с командой.
Не очень понятно о каком именно архитекторе речь:
т.е. дополнительных рисков, кроме описанных в статье, нет. Но может быть я не понял комментария?
- если речь об архитекторе DWH, то я описал кто ее выполняет (подрядчик)
- если речь об «архитекторе всего решения», то выделенной роли нет, т.к. она не нужна в нашей модели разработки при которой один инженер выполняет задачу целиком; в случае необходимости с кем-то посоветоваться есть senior, тимлид, либо руководитель, но вообще 99% всех сложных вопросов решаются в чате
т.е. дополнительных рисков, кроме описанных в статье, нет. Но может быть я не понял комментария?
Спасибо за пост.
Если сейчас бы у вас был выбор бесплатного решения для DWH, что вы бы выбрали в 2021 году?
Какой бесплатный дистрибутив Hadoop вы бы выбрали сейчас? Репозитории HortonWorks доступны до сих пор.
Спасибо!
Проектирование 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, но это от конкретных задач конечно же зависит.
Пример из складской логистики в которой я когда-то хорошо разбирался: решение о том, каким будет склад принимается на основе анализа потоков товаров (частота движения 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, но это от конкретных задач конечно же зависит.
Мне кажется у вас весьма поверхностные представления о возможностях Cloudera Hadoop. Это коробка полностью решает задачи классического DWH при правильных архитектурных подходах, а не только Data Lake. В том числе OLTP и time series нагрузку.
Все остальные дистрибутивы по факту это как раз боль и унижение, включая названными вами отечественный креатив. Именно потому он и позиционируется как часть какой то общей гетерогенной архитектуры в составе которой есть сборка GreenPlum.
Teradata это конечно технологический труп, от которого воняет уже лет 5 как.
Все остальные дистрибутивы по факту это как раз боль и унижение, включая названными вами отечественный креатив. Именно потому он и позиционируется как часть какой то общей гетерогенной архитектуры в составе которой есть сборка GreenPlum.
Teradata это конечно технологический труп, от которого воняет уже лет 5 как.
промахнулся ответом
буду рад услышать об иных решениях, позволяющих обычным аналитикам в 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 нужен? Можем дать поиграться.
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
спасибо большое, погуглю. Но пока писал статью мы уже на своем стэке решили возникший вопрос
есть ли в России похожие реализации?
Ситимобил. Но это im-memory, да. Для решения оптимизационных задач, судя по всему.
мы с Вами под «аналитиками» понимаем разных пользователей. Мои даже слов таких не знают)
Меня смутило, что аналитикам нужно ">1 трлн строк за разумное время в минутах". Это ближе к Дата-сатанистам. Для selfe-service BI обычно нужно гораздо меньший объем транзакций гражданским аналитикам давать.
Меня смутило, что аналитикам нужно ">1 трлн строк за разумное время в минутах"… Для selfe-service BI обычно нужно гораздо меньший объем транзакций гражданским аналитикам давать.Могу только повторить тезис из статьи «Как бы высокопарно это ни звучало, но Yota изначально — data driven business.» Так уж повелось, что доступ к данным внутри компании открыт для всех кому он необходим (под чутким надзором ИБ). Не я это придумал, но я полностью поддерживаю идею открытости. Да и трлн. строк о которых писал выше — это агрегаты(!). Первичные данные мы не храним ибо стоимость хранения будет космической и для компании это неэффективно.
Это ближе к Дата-сатанистам.как сказал мой знакомый Архитектор Data
В целом, люди чаще совершают звонки и пользуются интернетом, чем совершают покупки или финансовые операции. Но коллеги из поисковых систем, социальных сетей, крупных финансовых или торговых организаций, а так же кто занимается iot и m2m, скорее всего, поставят под сомнение что BD "только в телекоме" :D
«Предположу, что Вы лишь умозрительно допустили соответствие любых продуктов 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 в качестве процессингового движка конкурентов нет.
Наверное вряд ли при этом вы являлись экспертами по правильной настройке Impala и Hadoop под Impala. Иначе я не могу объяснить как она могла слить на 1-2 порядка Vertica с учетом того что Impala читает только те блоки, данные которых удовлетворяют соединения и условиям выборки (storage индексы), а в версии 3.4 на CDP появились еще страничные индексы уровнем ниже. Vertica так будет делать (тн SIP фильтр) если у вас сортировка колонки есть и правльная сегментация. Те ФМД вы заранее готовите под свои запросы. При внезапном ad-hoc с hash join Vertica превращается в обычную тыкву.
Другими словами, если сравнивать решение с тз cost per performance, то у Cloudera c Impala в качестве процессингового движка конкурентов нет.
При внезапном ad-hoc с hash join Vertica превращается в обычную тыкву.напишите в личку Ваш профиль в телеге, добавлю в чатик пользователей Вертики (если Вас там еще нет), где над такими проблемами если и улыбнуться, но точно помогут не превращать в тыкву Вертику. Особенно там, где это еще и постараться надо сделать. Иногда и сам там помогаю страждующим, но редко читаю чат целиком.
Другими словами, если сравнивать решение с тз cost per performance, то у Cloudera c Impala в качестве процессингового движка конкурентов нет.Вы ведь понимаете, что без конкретики звучит не сильно убедительно? Напишите о своем опыте развернуто. Видно, что Вам есть, что написать по сути — на Хабре мало приличных статей о хранилищах данных и экосистеме BI. Но пока лишь мнение против мнения (хотя мое развернуто в статье корпоративного блога настолько насколько это возможно).
PS: забавно, что Вы работаете в компании, которая 4 года назад была подрядчиком Yota BI по теме визуализации в SAP BO и пр. несложных работах. Но Вас не помню в той команде, которая на уровень архитектуры решения не выходила
Опыта работы с Vertiсa у меня ничуть не меньше вашего и помощь мне не требуется. Причем реального проектного, со слоями трансформации данных, витринами, аналитическими слоями и тд. Про чатик знаю, но не состою.
По поводу развернутой статьи, вы правы, не хватает тут такого толковых материала. Я уже даже написал, осталось только опубликовать. Надеюсь сделаю в ближайшее время. Нужно сделать последний шаг — согласовать с клиентом либо опубликовать обезличенный клиентский опыт.
В видео варианте по Cloudera можно посмотреть тут, например: www.youtube.com/watch?v=iXoWA9XP2xw&list=PLqYhGsQ9iSEoE10dyEjp5QtVrNo-g92gC
Насчет вашего воспоминания забавного ничего нет. GBC был подрядчиком не 4 года назад, а 2013 году. Но по иронии в той команде я состоял, несмотря на той что в тот момент у вас работало около 250 чел, но занимался исключительно той частью вашего ХД что была на Oracle. Можете взять референс у того кто с вашей стороны руководил вашим подразделением — Алексей Щеглов (у вас давно не работает).
По поводу развернутой статьи, вы правы, не хватает тут такого толковых материала. Я уже даже написал, осталось только опубликовать. Надеюсь сделаю в ближайшее время. Нужно сделать последний шаг — согласовать с клиентом либо опубликовать обезличенный клиентский опыт.
В видео варианте по Cloudera можно посмотреть тут, например: www.youtube.com/watch?v=iXoWA9XP2xw&list=PLqYhGsQ9iSEoE10dyEjp5QtVrNo-g92gC
Насчет вашего воспоминания забавного ничего нет. GBC был подрядчиком не 4 года назад, а 2013 году. Но по иронии в той команде я состоял, несмотря на той что в тот момент у вас работало около 250 чел, но занимался исключительно той частью вашего ХД что была на Oracle. Можете взять референс у того кто с вашей стороны руководил вашим подразделением — Алексей Щеглов (у вас давно не работает).
Насчет вашего воспоминания забавного ничего нет. GBC был подрядчиком не 4 года назад, а 2013 году. Но по иронии в той команде я состоял, несмотря на той что в тот момент у вас работало около 250 чел, но занимался исключительно той частью вашего ХД что была на Oracle. Можете взять референс у того кто с вашей стороны руководил вашим подразделением — Алексей Щеглов (у вас давно не работает).Получается мы оба правы. GB до начала 2017 был у нас на контракте. Oracle DWH уже при мне был немного староват, а сейчас вообще отказываемся от него в изначальном виде. А Лешу помню, хотя вместе и не работали (он ушел до моего прихода).
Искренне жду Вашу статью — на Хабре и правда мало хороших материалов по экосистемам BI.
опять промахнулся(
под ETL apache airflow не рассматривали?
Informatica PowerCenter уже устарела и не поддерживается, сейчас Informatica Big Data Management больше актуальнее
Informatica PowerCenter уже устарела и не поддерживается, сейчас Informatica Big Data Management больше актуальнее
под ETL apache airflow не рассматривали?Если бы сейчас создавали с 0, рассматривали бы. А в далеком 2012 до Airflow было 2 года, а до Apache Airflow — 4. Но сейчас наши инструменты нас полностью устраивают.
Informatica PowerCenter уже устарела и не поддерживается, сейчас Informatica Big Data Management больше актуальнееВы правы. Но от перемены названий суть продукта кардинально не поменялась — как был JVM под капотом, так он и остался. Остальное маркетинг.
Как насчёт DugitalRoute Mediation Zone? Оно же SAP CM?
Специально для телекома было сделано.
DugitalRoute Mediation ZoneТакие штуки, создаются под конкретного заказчика, и если не умирают, а переходят в стадию зрелого продукта, то покупаются большим игроком.
Оно же SAP CM?Подтверждение моего предположения.
А все это я к тому, что бенефициаром оказывается лишь самый 1 клиент, под которого оно писалось, а для остальных внедрять такое комплексное решение — боль. Yota уже 14 лет существует и для нас рассматривать такие решения применительно только к BI — из области фантастики.
Все вышесказанное лишь мое скромное ИМХО с которым вполне можно поспорить.
Такая штука работает у многих операторов в мире. Она не была создана под конкретного заказчика. Это скорей набор инструментов. Под конкретный проект, настраивается индивидуально.
В Ростелекоме без боли внедрено и работает уже давно (примерно с 2013 года), например.
SAP их не купил. Они перепродают его под своим брендом.
Спасибо, буду знать для общего развития. Но для нашего кейса — не вариант. Да и упомянутый Вами оператор, с точки зрения BI, ни разу не бенчмарк.
Но меня все-таки не покидает чувство, что переход на такие системы при полностью устраивающей собственной экосистеме — это как менять биллинг в успешно работающем телеком-операторе: дорого, больно, а главное не понятно «зачем?».
Но меня все-таки не покидает чувство, что переход на такие системы при полностью устраивающей собственной экосистеме — это как менять биллинг в успешно работающем телеком-операторе: дорого, больно, а главное не понятно «зачем?».
Sign up to leave a comment.
Business Intelligence на очень больших данных: опыт Yota