Манифест быстрой аналитики от ГК Luxms
О ключевых принципах и инструментах перехода от аналогового управления к цифровому рассказывают Сергей Шестаков, генеральный директор ГК Luxms, и Александр Тютюнник, директор по развитию группы компаний.
Сергей Шестаков, генеральный директор
ГК Luxms
ГК Luxms
Александр Тютюнник, директор по развитию группы компаний
Все медленно. И это правильно
Мир информационных технологий развивается крайне медленно. Когда-то давно, когда мы учились в институте, концепция, по которой системы нужно делить на транзакционные и аналитические, уже не была откровением. Первые системы предназначались для ежедневной рутинной операционной деятельности и должны были обеспечивать непротиворечивость, удобство и скорость доступа к транзакционным данным. Вторые системы должны были организовать складирование информации в хранилище, пригодное для сложных аналитических запросов и действий, отчетности. OLAP и OLTP. И это не могло быть неправильным.
Три десятилетия компании совершенствуют и усложняют OLTP и строят хранилища. Концепция оставалась прежней, системы усложнялись, а их количество росло. И это не то что бы неправильно, просто мир изменился. И такое деление сегодня — на OLAP и OLTP — не более чем условность, упрощение, классификация, необходимая разве для студентов.
Как выглядела крупная солидная организация двадцать или тридцать лет назад? Штат в несколько тысяч человек, из которых (внимание!) далеко не все были пользователями ПК. Существенная часть сотрудников могла не иметь навыков работы с компьютером вообще. В свою очередь их руководители начали активнее использовать компьютер с ростом скорости интернета, но и то в основном для личных «серферских» целей. Основная масса пользователей оставалась просто операторами ПК и вводила информацию. На такую структуру имелась пара отделов со штатом по пять-десять человек, которые готовили исследования, отчеты и презентации для руководства. Средний менеджмент использовал компьютер для просмотра и одобрения сложных операций, разбирательства в нестандартных кейсах и построения таблиц.
Сейчас все обстоит совершенно по-другому. Во-первых, в крупной успешной организации работает существенно меньше людей. Большой штат теперь скорее обуза и говорит о неэффективности и/или о принадлежности государству, или о «доисторическом» происхождении структуры. «Операторов ПК» больше нет. Транзакций в том смысле, в каком они раньше понимались в ИТ-индустрии, также не существует, точнее, они стали совсем другими. Это больше не дебет, кредит, номер, сумма, не конечная финальная, как правило, бухгалтерская часть операции, а все параметры вместе: условия, договоры, комиссии, версии, ссылки, сканы и т. п. Пользователями П К или смартфона на рабочем месте теперь являются все. Используемых данных больше на порядки. При этом они как бы «нанизываются» на понятие транзакции, которое, в свою очередь, продолжает распухать. Такая «распухшая» транзакция проходит теперь через множество различных систем. Плюс само OLTP как понятие остается незыблемым, но просто отодвигается на вторичные роли при управлении компанией, а управление, в свою очередь, переходит в BI-системы, в продвинутую версию старой идеи OLAP.
С информацией теперь работают все, при этом аналитиками стали тоже фактически все. Даже если ты кладовщик на складе, у тебя есть скрипт, процесс, SLA, коммуникационная политика, FAQs, внутренний портал, план, и все это живет внутри различных систем. То есть кладовщик тоже стал аналитиком. Он работает с десятком систем, у него есть интерактивные запросы, он смотрит свои и чужие показатели, он — объект и субъект мониторинга в новом цифровом мире.
Но это только надводная часть «айсберга». А «на глубине» мы видим несколько различных транзакционных систем, несколько хранилищ и аналитических систем, десяток специализированных и важных источников, еще десяток менее важных. Все открыто.
Принципиально разные базы данных, используемые одновременно. API у всего со всем, шины, микросервисы. И самое главное — все пользователи работают со всеми решениями.
У светлых умов не раз возникало желание изобрести некую «волшебную таблетку» — продукт, который покрывал бы все потребности компании и позволял бы избавиться от вынужденного «зоопарка» систем. Так постепенно на рынке появлялись новые аббревиатуры — ERP, DSS, BI. Но по факту концепция оставалась прежней, то есть технологии внутри оставались старыми, но их упорно пытались приспособить к дивной новой корпоративной реальности.
К сожалению, новые классы систем не могут избавиться от неполноценности и стать «центром всего». Они содержат огромное количество «культурных слоев» и «доисторических апокрифов» внутри. Такое громоздкое и разваливающееся лоскутное одеяло не может претендовать на лидерство. «Не развалиться бы по ходу» — таков девиз любой транзакционной системы сегодня.
BI победил. Однако это странная победа — просто все остальные участники сошли с дистанции. Налицо техническое поражение прикладного программного обеспечения. Настоящей транзакционной системой сейчас является центральная аналитическая система, потому что транзакции сегодня — это решения, и именно аналитика встала в основу работы «правильной» организации. В 2021 году решения принимают в онлайне, на основе полных и непротиворечивых данных.
Обратите внимание на название этого раздела — по-другому и не могло быть.
Мир информационных технологий развивается крайне медленно. Когда-то давно, когда мы учились в институте, концепция, по которой системы нужно делить на транзакционные и аналитические, уже не была откровением. Первые системы предназначались для ежедневной рутинной операционной деятельности и должны были обеспечивать непротиворечивость, удобство и скорость доступа к транзакционным данным. Вторые системы должны были организовать складирование информации в хранилище, пригодное для сложных аналитических запросов и действий, отчетности. OLAP и OLTP. И это не могло быть неправильным.
Три десятилетия компании совершенствуют и усложняют OLTP и строят хранилища. Концепция оставалась прежней, системы усложнялись, а их количество росло. И это не то что бы неправильно, просто мир изменился. И такое деление сегодня — на OLAP и OLTP — не более чем условность, упрощение, классификация, необходимая разве для студентов.
Как выглядела крупная солидная организация двадцать или тридцать лет назад? Штат в несколько тысяч человек, из которых (внимание!) далеко не все были пользователями ПК. Существенная часть сотрудников могла не иметь навыков работы с компьютером вообще. В свою очередь их руководители начали активнее использовать компьютер с ростом скорости интернета, но и то в основном для личных «серферских» целей. Основная масса пользователей оставалась просто операторами ПК и вводила информацию. На такую структуру имелась пара отделов со штатом по пять-десять человек, которые готовили исследования, отчеты и презентации для руководства. Средний менеджмент использовал компьютер для просмотра и одобрения сложных операций, разбирательства в нестандартных кейсах и построения таблиц.
Сейчас все обстоит совершенно по-другому. Во-первых, в крупной успешной организации работает существенно меньше людей. Большой штат теперь скорее обуза и говорит о неэффективности и/или о принадлежности государству, или о «доисторическом» происхождении структуры. «Операторов ПК» больше нет. Транзакций в том смысле, в каком они раньше понимались в ИТ-индустрии, также не существует, точнее, они стали совсем другими. Это больше не дебет, кредит, номер, сумма, не конечная финальная, как правило, бухгалтерская часть операции, а все параметры вместе: условия, договоры, комиссии, версии, ссылки, сканы и т. п. Пользователями П К или смартфона на рабочем месте теперь являются все. Используемых данных больше на порядки. При этом они как бы «нанизываются» на понятие транзакции, которое, в свою очередь, продолжает распухать. Такая «распухшая» транзакция проходит теперь через множество различных систем. Плюс само OLTP как понятие остается незыблемым, но просто отодвигается на вторичные роли при управлении компанией, а управление, в свою очередь, переходит в BI-системы, в продвинутую версию старой идеи OLAP.
С информацией теперь работают все, при этом аналитиками стали тоже фактически все. Даже если ты кладовщик на складе, у тебя есть скрипт, процесс, SLA, коммуникационная политика, FAQs, внутренний портал, план, и все это живет внутри различных систем. То есть кладовщик тоже стал аналитиком. Он работает с десятком систем, у него есть интерактивные запросы, он смотрит свои и чужие показатели, он — объект и субъект мониторинга в новом цифровом мире.
Но это только надводная часть «айсберга». А «на глубине» мы видим несколько различных транзакционных систем, несколько хранилищ и аналитических систем, десяток специализированных и важных источников, еще десяток менее важных. Все открыто.
Принципиально разные базы данных, используемые одновременно. API у всего со всем, шины, микросервисы. И самое главное — все пользователи работают со всеми решениями.
У светлых умов не раз возникало желание изобрести некую «волшебную таблетку» — продукт, который покрывал бы все потребности компании и позволял бы избавиться от вынужденного «зоопарка» систем. Так постепенно на рынке появлялись новые аббревиатуры — ERP, DSS, BI. Но по факту концепция оставалась прежней, то есть технологии внутри оставались старыми, но их упорно пытались приспособить к дивной новой корпоративной реальности.
К сожалению, новые классы систем не могут избавиться от неполноценности и стать «центром всего». Они содержат огромное количество «культурных слоев» и «доисторических апокрифов» внутри. Такое громоздкое и разваливающееся лоскутное одеяло не может претендовать на лидерство. «Не развалиться бы по ходу» — таков девиз любой транзакционной системы сегодня.
BI победил. Однако это странная победа — просто все остальные участники сошли с дистанции. Налицо техническое поражение прикладного программного обеспечения. Настоящей транзакционной системой сейчас является центральная аналитическая система, потому что транзакции сегодня — это решения, и именно аналитика встала в основу работы «правильной» организации. В 2021 году решения принимают в онлайне, на основе полных и непротиворечивых данных.
Обратите внимание на название этого раздела — по-другому и не могло быть.
Медленно. Потому что глубоко
Данных с каждым годом и каждым витком развития технологий используется все больше. И те данные, которые вам нужны сейчас, у вас наверняка есть, но теперь они где-то очень далеко и глубоко. Или же раздобыть их очень дорого. Это новая парадигма — этакий прекрасный набор инструментов, который лежит где-то на холодном балконе, поэтому, когда нужно закрутить шуруп, проще воспользоваться кухонным ножом. Тем временем дорогой набор продолжает ржаветь на балконе.
Однако вернемся к данным и их ключевой роли в нашем новом цифровом «датацентричном» мире. У ИТ нет и не может быть никакой собственной повестки, никакой более важной задачи автоматизации еще одного транзакционного процесса с помощью еще одной системы, кроме задач пользователей, угнетенных аналитическими запросами. Пользователей, ожидающих, когда же наконец запрос будет отработан, и мечтающих, чтобы результатом отработки оказалось не предупреждение о превышении квоты по ресурсам на экране. Дело не только в том, чтобы принести «гаечные ключи» с балкона, теперь у каждого должен быть индивидуальный набор «ключей». Но вместо этого всем почему-то хочется чуда.
Человеческий мозг так устроен, что, сталкиваясь с проблемой, он ищет, точнее, хочет найти решение. И при этом часто хватается за соломинку. Мир долго искал панацеи — уникальной новой технологии. Но сколько ни называй множество хранилищ с мусорными данными красивым словом «озеро», по факту они остаются болотом, и озерами данных слывут только в докладах на конференциях, даже если на это спустить кучу денег.
Сложный многомерный мир не вмещается ни в одну технологию. Мозг нам в помощь — упрощаем сами. Неструктурированное озеро данных практически невозможно заставить работать за разумные деньги.
Данных с каждым годом и каждым витком развития технологий используется все больше. И те данные, которые вам нужны сейчас, у вас наверняка есть, но теперь они где-то очень далеко и глубоко. Или же раздобыть их очень дорого. Это новая парадигма — этакий прекрасный набор инструментов, который лежит где-то на холодном балконе, поэтому, когда нужно закрутить шуруп, проще воспользоваться кухонным ножом. Тем временем дорогой набор продолжает ржаветь на балконе.
Однако вернемся к данным и их ключевой роли в нашем новом цифровом «датацентричном» мире. У ИТ нет и не может быть никакой собственной повестки, никакой более важной задачи автоматизации еще одного транзакционного процесса с помощью еще одной системы, кроме задач пользователей, угнетенных аналитическими запросами. Пользователей, ожидающих, когда же наконец запрос будет отработан, и мечтающих, чтобы результатом отработки оказалось не предупреждение о превышении квоты по ресурсам на экране. Дело не только в том, чтобы принести «гаечные ключи» с балкона, теперь у каждого должен быть индивидуальный набор «ключей». Но вместо этого всем почему-то хочется чуда.
Человеческий мозг так устроен, что, сталкиваясь с проблемой, он ищет, точнее, хочет найти решение. И при этом часто хватается за соломинку. Мир долго искал панацеи — уникальной новой технологии. Но сколько ни называй множество хранилищ с мусорными данными красивым словом «озеро», по факту они остаются болотом, и озерами данных слывут только в докладах на конференциях, даже если на это спустить кучу денег.
Сложный многомерный мир не вмещается ни в одну технологию. Мозг нам в помощь — упрощаем сами. Неструктурированное озеро данных практически невозможно заставить работать за разумные деньги.
Медленно. Потому что «холодно» и неправильно
Ошибки угнетают. Неправильные ошибочные инвестиции больше всех сдерживают прогресс, технологии стремительно меняются. Но интригой и тайной покрыт этот процесс, сокровенное знание доступно очень немногим и тщательно скрывается — терять работу никто не хочет.
ИТ-архитекторы — новая инквизиция современной корпоративной культуры. Они герои и заложники одновременно, ведь все новое со временем устаревает. А, к сожалению, не во многих культурах есть право на ошибку, уважение к признанию ошибки, истинная культура инноваций с постоянным поиском новых разумных решений. Всегда более легкий путь — подставить «кликабельный костыль».
«Священный ореол» новых прорывных костров для лишних денег акционеров привлекает снова и снова. И суровая правда корпоративных хранилищ — зачастую неконсистентные и «непрерывно устаревающие» управленческие данные — не дает развиваться. Замкнутый круг, особенно с учетом того, что ИТ-новаторов среди крупных корпораций обычно очень мало.
Отдельная тема — так называемые холодные данные. В нашем понимании речь идет о данных, доступ к которым требуется редко. Это данные, которые хранятся на менее эффективных по скорости доступа носителях, неструктурированные, замусоренные, не подготовленные для удобного поиска, неудобно или неправильно «проключеванные». Данные, структура хранения которых предполагает использование в запросах многих таблиц и дополнительных справочников. Данные, хранимые в очень длинных строках или столбцах. В общем случае их требуется перед использованием найти в источниках, достать, переформатировать, почистить, отсортировать, отфильтровать, проверить, «повернуть» или сделать еще какие-либо специальные процедуры и наконец «подать на клиента» в правильном виде.
Но структура хранения данных в старых legacy-системах не соответствует необходимости принимать решения в онлайне и оперативности аналитической поддержки этого процесса. И это факт. Что же тогда делать?
Ошибки угнетают. Неправильные ошибочные инвестиции больше всех сдерживают прогресс, технологии стремительно меняются. Но интригой и тайной покрыт этот процесс, сокровенное знание доступно очень немногим и тщательно скрывается — терять работу никто не хочет.
ИТ-архитекторы — новая инквизиция современной корпоративной культуры. Они герои и заложники одновременно, ведь все новое со временем устаревает. А, к сожалению, не во многих культурах есть право на ошибку, уважение к признанию ошибки, истинная культура инноваций с постоянным поиском новых разумных решений. Всегда более легкий путь — подставить «кликабельный костыль».
«Священный ореол» новых прорывных костров для лишних денег акционеров привлекает снова и снова. И суровая правда корпоративных хранилищ — зачастую неконсистентные и «непрерывно устаревающие» управленческие данные — не дает развиваться. Замкнутый круг, особенно с учетом того, что ИТ-новаторов среди крупных корпораций обычно очень мало.
Отдельная тема — так называемые холодные данные. В нашем понимании речь идет о данных, доступ к которым требуется редко. Это данные, которые хранятся на менее эффективных по скорости доступа носителях, неструктурированные, замусоренные, не подготовленные для удобного поиска, неудобно или неправильно «проключеванные». Данные, структура хранения которых предполагает использование в запросах многих таблиц и дополнительных справочников. Данные, хранимые в очень длинных строках или столбцах. В общем случае их требуется перед использованием найти в источниках, достать, переформатировать, почистить, отсортировать, отфильтровать, проверить, «повернуть» или сделать еще какие-либо специальные процедуры и наконец «подать на клиента» в правильном виде.
Но структура хранения данных в старых legacy-системах не соответствует необходимости принимать решения в онлайне и оперативности аналитической поддержки этого процесса. И это факт. Что же тогда делать?
Пример целевой архитектуры аналитической системы
Правильное может и должно быть быстрым
Каковы же новые формы борьбы за священный прогресс, за данные, за легкий и простой доступ к ним? Здесь нет одного отдельного рецепта — здесь работает только сразу много всего в комплексе.
Детальный бизнес-анализ и упрощение запросов, оптимизация ETL-процессов, оптимизация бизнес-логики аналитических систем за счет датацентричной архитектуры, каскадная подготовка данных для использования, создание слоя «горячих» и «теплых» данных, MPP и многие другие современные и эффективные технологии, которые просто не уместились в настоящий «Манифест быстрой аналитики», — вот этот набор в самых общих чертах.
Необходимо ограничить бизнес в полете его фантазии. Отказаться от подхода «мы так хотим, а вы обеспечивайте». Все имеет цену и эффект и должно быть очень детально оценено на целесообразность и эффективность. Из тысячи сотрудников с аналитической функцией только единицам реально нужно грузить данные из какого-нибудь SAP BW и крутить в онлайне многомерные кубы со ста миллиардами строк. А системы всем ставят одинаковые. В каких-то компаниях вообще не нужно крутить многомерные кубы, а если «припрет», то будет достаточно одного рабочего места и компьютера помощнее — им вовсе не нужно лезть на сервер. Выделенный компьютер аналитика — только одно из возможных решений.
ETL — тоже бесконечная область оптимизации. Множество решений, множество технологий. Но концепция тоже уже не работает. Теперь это не только «Extract, Transform, Load». Теперь важно давать обратную связь по данным, отслеживать их происхождение, анализировать, почему и на какой стадии мог произойти сбой. Это могут далеко не все ETL-процессоры. И ETL должен быть при этом очень скоростным. JBDС — это, конечно, удобно и всем знакомо, но часто в современном технологическом стеке самое удобное оказывается одновременно самым медленным. Альтернатива — более широкое использование нативных коннекторов, например, FDW или HTTP, чтобы обеспечить прямой доступ к данным без дополнительных преобразований.
Идем далее. Берем данные «тепленькими» и когда они нужны. Концепция слоев данных должна использоваться повсеместно. Чтобы обеспечить скорость обработки информационных запросов, организуем работу трех слоев данных: «горячих», «теплых» и «холодных». Для этого модернизируем ETL-процессы и создаем «горячий» и «теплый» слой данных (например, технология Luxms Data Boring или любая другая). Разные СУБД по-разному подходят для различных слоев данных. Слой быстрых, «горячих» данных лучше строить на массивно-параллельных системах с высокой скоростью отклика. Пример: ClickHouse.
Хранение слоя «теплых» данных хорошо обеспечивают такие MPP СУБД, как Greenplum, Oracle Exadata. Для «холодных» данных можно использовать Hadoop или S3.
Архитектурный ответ тоже есть — датацентричность. Оптимизация исполнения бизнес-логики за счет датацентричной архитектуры, в частности, при запросах детализации данных. Эффективность трехзвенной архитектуры — сегодня уже не аксиома, а теорема, доказательство которой в конкретной среде часто приводит к обратным выводам. Датацентричность подразумевает перенос вычислений ближе к исходным данным, максимальное использование новейших возможностей систем управления данными. Принцип датацентричности в аналитической системе должен проявляться в широком использовании хранимых процедур в базе данных для реализации бизнес-логики и размещении сервера приложений и основной бизнес-логики внутри базы данных. Получаем датацентричность ядра системы, желательно еще и написанного на датацентричном языке — PL/pgSQL. Эти идеи были подробно изложены в докладах наших коллег из ГК Luxms в журнале ACM (Association for Computing Machinery) и на конференциях PostgresConf 2019 в Нью-Йорке и реализованы в BI-платформе Luxms BI, используемой в ряде крупнейших российских клиентов. Максимально короткий путь прохождения ответа из базы данных на клиент (в двухзвенной клиент-серверной архитектуре) — это очень важно.
Каковы же новые формы борьбы за священный прогресс, за данные, за легкий и простой доступ к ним? Здесь нет одного отдельного рецепта — здесь работает только сразу много всего в комплексе.
Детальный бизнес-анализ и упрощение запросов, оптимизация ETL-процессов, оптимизация бизнес-логики аналитических систем за счет датацентричной архитектуры, каскадная подготовка данных для использования, создание слоя «горячих» и «теплых» данных, MPP и многие другие современные и эффективные технологии, которые просто не уместились в настоящий «Манифест быстрой аналитики», — вот этот набор в самых общих чертах.
Необходимо ограничить бизнес в полете его фантазии. Отказаться от подхода «мы так хотим, а вы обеспечивайте». Все имеет цену и эффект и должно быть очень детально оценено на целесообразность и эффективность. Из тысячи сотрудников с аналитической функцией только единицам реально нужно грузить данные из какого-нибудь SAP BW и крутить в онлайне многомерные кубы со ста миллиардами строк. А системы всем ставят одинаковые. В каких-то компаниях вообще не нужно крутить многомерные кубы, а если «припрет», то будет достаточно одного рабочего места и компьютера помощнее — им вовсе не нужно лезть на сервер. Выделенный компьютер аналитика — только одно из возможных решений.
ETL — тоже бесконечная область оптимизации. Множество решений, множество технологий. Но концепция тоже уже не работает. Теперь это не только «Extract, Transform, Load». Теперь важно давать обратную связь по данным, отслеживать их происхождение, анализировать, почему и на какой стадии мог произойти сбой. Это могут далеко не все ETL-процессоры. И ETL должен быть при этом очень скоростным. JBDС — это, конечно, удобно и всем знакомо, но часто в современном технологическом стеке самое удобное оказывается одновременно самым медленным. Альтернатива — более широкое использование нативных коннекторов, например, FDW или HTTP, чтобы обеспечить прямой доступ к данным без дополнительных преобразований.
Идем далее. Берем данные «тепленькими» и когда они нужны. Концепция слоев данных должна использоваться повсеместно. Чтобы обеспечить скорость обработки информационных запросов, организуем работу трех слоев данных: «горячих», «теплых» и «холодных». Для этого модернизируем ETL-процессы и создаем «горячий» и «теплый» слой данных (например, технология Luxms Data Boring или любая другая). Разные СУБД по-разному подходят для различных слоев данных. Слой быстрых, «горячих» данных лучше строить на массивно-параллельных системах с высокой скоростью отклика. Пример: ClickHouse.
Хранение слоя «теплых» данных хорошо обеспечивают такие MPP СУБД, как Greenplum, Oracle Exadata. Для «холодных» данных можно использовать Hadoop или S3.
Архитектурный ответ тоже есть — датацентричность. Оптимизация исполнения бизнес-логики за счет датацентричной архитектуры, в частности, при запросах детализации данных. Эффективность трехзвенной архитектуры — сегодня уже не аксиома, а теорема, доказательство которой в конкретной среде часто приводит к обратным выводам. Датацентричность подразумевает перенос вычислений ближе к исходным данным, максимальное использование новейших возможностей систем управления данными. Принцип датацентричности в аналитической системе должен проявляться в широком использовании хранимых процедур в базе данных для реализации бизнес-логики и размещении сервера приложений и основной бизнес-логики внутри базы данных. Получаем датацентричность ядра системы, желательно еще и написанного на датацентричном языке — PL/pgSQL. Эти идеи были подробно изложены в докладах наших коллег из ГК Luxms в журнале ACM (Association for Computing Machinery) и на конференциях PostgresConf 2019 в Нью-Йорке и реализованы в BI-платформе Luxms BI, используемой в ряде крупнейших российских клиентов. Максимально короткий путь прохождения ответа из базы данных на клиент (в двухзвенной клиент-серверной архитектуре) — это очень важно.
Пример целевой архитектуры аналитической системы
Для реальной цифровизации и внедрения правильных новых технологий нужны в первую очередь смена культуры организации, объективная апробация и сравнительные тесты. Интересным примером может быть опыт архитектурных инноваций в части использования СУБД ClickHouse в качестве «горячего» слоя данных для оптимизации использования вычислительных мощностей при сложных аналитических запросах на больших данных.
Массивно-параллельная обработка данных, реализация механизмов вертикального и горизонтального масштабирования — это, как говорится, «The last, but not the Least». Все это чудо правильной аналитической системы для реальных Big Data должно жить на современном «железе» на многих узлах, в кластере, с требуемой для бизнеса отказоустойчивостью.
Для реальной цифровизации и внедрения правильных новых технологий нужны в первую очередь смена культуры организации, объективная апробация и сравнительные тесты. Интересным примером может быть опыт архитектурных инноваций в части использования СУБД ClickHouse в качестве «горячего» слоя данных для оптимизации использования вычислительных мощностей при сложных аналитических запросах на больших данных.
Массивно-параллельная обработка данных, реализация механизмов вертикального и горизонтального масштабирования — это, как говорится, «The last, but not the Least». Все это чудо правильной аналитической системы для реальных Big Data должно жить на современном «железе» на многих узлах, в кластере, с требуемой для бизнеса отказоустойчивостью.
Пример целевой архитектуры аналитической системы
Управленческая система нашего времени — BI
Процесс управления сегодня нуждается в точной и подробной информации для принятия решений. Данные нужно тщательно собрать, обработать, проанализировать и представить лицам, принимающим решения. На каждом этапе могут возникнуть проблемы, которые влияют на качество данных и ведут к некорректным выводам. Это ошибки, нестыковки, пропуски, задержки, искажения. Для этого и внедряются аналитические системы — BI. Они повышают полноту данных, обеспечивают удобный доступ к ним. Анализ становится удобнее и оперативнее. Быстрее проверяются гипотезы, быстрее запускаются необходимые мероприятия. В результате успешнее достигаются цели. BI помогает сегодня контролировать процессы, анализировать показатели эффективности и готовить интерактивные отчеты.
Пользователи BI — лица, принимающие решения, топ-менеджеры, линейные руководители, аналитики и эксперты, исполнители в важных, требующих мониторинга процессах. Есть несколько типовых классов задач, которые сейчас успешно решает BI. Много систем — много данных — много измерений. Простые данные — высокая детализация, в том числе географическая. Красивая визуализация — привлечение внимания к данным. Интерактивность — игровая форма работы с данными для всех исполнителей. Исключение интерпретации данных.
Среди важных функциональных направлений — self-service. Это свобода экспертов, их активная работа с данными без программирования (подключение к источникам, подготовка визуализации, загрузка данных, настройка отчетов и системы оповещения). Больше не нужно просить ИТ загрузить что-то куда-то.
Быстрый запуск функционала — очень важное свойство современной BI-системы, исходя из всего вышесказанного. Бизнесу нужно дать возможность быстро запустить визуальный контроль данных в одном разрезе с быстрой перенастройкой или вообще отказом от мониторинга. Это возможно только при определенной пластичности BI-системы и ее приспособленности к быстрой настройке дэшбордов за считаные недели от момента возникновения идеи до запуска на реальных данных.
Апробация моделей искусственного интеллекта на озерах данных — еще одно важнейшее направление перспективного развития аналитических решений. «Светлые хакеры», адепты AI/ML, требуют развития в этом направлении. Анализ и сравнение экспертных моделей — это то, что сейчас могут делать только специализированные системы. Далее будет требоваться их интеграция внутрь BI-платформ, например, с применением библиотек Greenplum MADlib Extension. Платформа BI должна позволять запускать AI/ML модели в массивно-параллельном режиме, накапливать результаты прогонов с различными параметрами и визуально проводить сравнительный анализ. Осуществлять обработку с использованием правил и методов машинного обучения, уметь встраивать обработку математическими методами: проводить статанализ, запускать, например, кастомные скрипты на R/Python, осуществлять текстовую аналитику методами NLP.
Процесс управления сегодня нуждается в точной и подробной информации для принятия решений. Данные нужно тщательно собрать, обработать, проанализировать и представить лицам, принимающим решения. На каждом этапе могут возникнуть проблемы, которые влияют на качество данных и ведут к некорректным выводам. Это ошибки, нестыковки, пропуски, задержки, искажения. Для этого и внедряются аналитические системы — BI. Они повышают полноту данных, обеспечивают удобный доступ к ним. Анализ становится удобнее и оперативнее. Быстрее проверяются гипотезы, быстрее запускаются необходимые мероприятия. В результате успешнее достигаются цели. BI помогает сегодня контролировать процессы, анализировать показатели эффективности и готовить интерактивные отчеты.
Пользователи BI — лица, принимающие решения, топ-менеджеры, линейные руководители, аналитики и эксперты, исполнители в важных, требующих мониторинга процессах. Есть несколько типовых классов задач, которые сейчас успешно решает BI. Много систем — много данных — много измерений. Простые данные — высокая детализация, в том числе географическая. Красивая визуализация — привлечение внимания к данным. Интерактивность — игровая форма работы с данными для всех исполнителей. Исключение интерпретации данных.
Среди важных функциональных направлений — self-service. Это свобода экспертов, их активная работа с данными без программирования (подключение к источникам, подготовка визуализации, загрузка данных, настройка отчетов и системы оповещения). Больше не нужно просить ИТ загрузить что-то куда-то.
Быстрый запуск функционала — очень важное свойство современной BI-системы, исходя из всего вышесказанного. Бизнесу нужно дать возможность быстро запустить визуальный контроль данных в одном разрезе с быстрой перенастройкой или вообще отказом от мониторинга. Это возможно только при определенной пластичности BI-системы и ее приспособленности к быстрой настройке дэшбордов за считаные недели от момента возникновения идеи до запуска на реальных данных.
Апробация моделей искусственного интеллекта на озерах данных — еще одно важнейшее направление перспективного развития аналитических решений. «Светлые хакеры», адепты AI/ML, требуют развития в этом направлении. Анализ и сравнение экспертных моделей — это то, что сейчас могут делать только специализированные системы. Далее будет требоваться их интеграция внутрь BI-платформ, например, с применением библиотек Greenplum MADlib Extension. Платформа BI должна позволять запускать AI/ML модели в массивно-параллельном режиме, накапливать результаты прогонов с различными параметрами и визуально проводить сравнительный анализ. Осуществлять обработку с использованием правил и методов машинного обучения, уметь встраивать обработку математическими методами: проводить статанализ, запускать, например, кастомные скрипты на R/Python, осуществлять текстовую аналитику методами NLP.
Выводы
- BI — ключевой актив современной организации, основа цифрового управления;
- для цифрового управления нужно обладать всей полнотой информации в режиме онлайн;
- будущее — за датацентричными архитектурами, с поддержкой одновременной работы со слоями «горячих», «теплых» и «холодных» данных в массивно-параллельном режиме (MPP), в том числе с MPP-поддержкой AI/ML-моделирования.
P. S. Озвученные в нашем Манифесте правила быстрой аналитики — это лишь идеи, пусть и работающие у многих заказчиков. С ними можно согласиться или нет. Но одну мысль мы хотим донести еще раз. Цифровизация всего и вся неизбежна. Лавину данных уже не остановить. Их количество будет только возрастать, причем экспоненциально. Принятие решений все больше переходит в формат реального времени и становится более цифровым, а не интуитивным. Поэтому аналитические системы — это уже must have для любой уважающей себя организации. Они переросли в важный стратегический актив, и тренд этот с нами надолго. Поэтому, чтобы соответствовать новой реальности, жить «по-старому» уже не получится. Придется меняться. Свои варианты перехода к цифровому управлению мы постарались озвучить в настоящем Манифесте.
Контакты