`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Как изменилось финансирование ИТ-направления в вашей организации?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Дмитрий Гудков

[Де]Централизация песочниц

+11
голос

Похоже мировая мысль как-то до сих пор не определилась, насколько анализируемые данные должны быть централизованы в чем-то типа хранилища данных. Аналитические хранилища данных появились в 90х как ответ на разобщенность и несогласованность данных, хранящихся в разных учетных системах, бурно размножившихся с середины 60х годов. Хранилища данных явились инициативой топ-менеджмента компаний, желающих получить цельное и достоверное представление о деятельности своей организации. С тех пор централизация была возведена в культ, к ней стремились как к абсолюту, как к недостижимой линии горизонта. Централизация данных в разнообразных хранилищах и хабах принесла не только ожидаемое цельное видение бизнеса, но и немало выгод для ИТ - с точки зрения разнесения нагрузки, сокращения избыточности данных, упрощения контроля доступа, экономии на оборудовании и т.д.

Однако сейчас похоже маятник начинает двигаться в обратную сторону. И основными двигателями этого процесса являются уже не топ-менеджеры, а среднее звено менеджмента и ключевые аналитики, которые все больше недовольны теми ограничениями свободы, которые налагают на них хранилища данных и традиционные BI-платформы. Они все чаще нуждаются в своей собственной "песочнице", где они могли бы самостоятельно манипулировать достаточно большими массивами данных, связывать данные из ХД с внешними источниками, готовить ad-hoc отчеты, строить аналитические приложения и т.д. Другими словами self-service BI становится уже не просто произвольным визуальным конструированием отчетов из фиксированного набора показателей и размерностей, описанных в модели метаданных, а еще и произвольным изменением этой самой модели, выполняемого нетехническими специалистами. Причем этому процессу активно оппонируют как раз ИТ подразделения, справедливо опасающиеся неконтролируемого роста всевозможных витрин, витриночек и витринищ (в общем того, что называют datamarts), с неконтролируемым качеством данных в них.

Приведу два примера, сигнализирующих об этой тенденции:

Gartner, в отчете 2010 года по BI платформам первым же пунктом отметила тенденцию учащающегося использования на уровне департаментов BI-инструментов, позволяющих пользователям быстро и самостоятельно манипулировать данными - таких как QlikView и некоторых других in-memory платформ, при том что в организациях в целом за стандарт принята другая, более традиционная, BI-платформа. Gartner отмечает, что для бизнес-пользователей выгоды от их применения перевешивают возможные риски увеличения разобщенности данных.

Еще один пример - интервью Рэнди Ли (Randy Lea) МЗ Product and Services Marketing Teradata, опубликованному сегодня на tdwi.org. В этом интервью г-н Ли объясняет вывод новых, нетипичных для Teradata аналитических устройств (analytical appliance) как раз возрастающей тенденцией к самостоятельной манипуляции данными на уровне департаментов, в стороне от которой Teradata не хотела бы оставаться.

Очевидно, есть две крайности. Одна крайность - это пытаться все запихнуть в хранилище данных. Со всем требуемым проектированием и переделыванием моделей, ETL-процедур, метаданных BI и т.д. Однако даже самые убежденные сторонники централизации признают, что достичь этого на 100% невозможно да и нецелесообразно. С другой стороны, возвращаться к хаосу разобщенных данных тоже не хотелось бы - эта крайность уже хорошо известна. Но как сформулировать однозначный, хорошо работающий критерий, по которому определять - какие данных необходимо включать в ХД, а какие - нет? И какой должен быть размер "песочницы" для тех, кому она необходима как воздух?

Хорошего ответа на этот вопрос я пока не слышал.

+11
голос

Напечатать Отправить другу

Читайте также

Хороший ответ зависит от конкретных условий. Все данные так или иначе логически связаны между собой, но это совсем не повод их хранить в одном месте и в одной структуре. Связь между данными может осуществляться независимо от мест и способов их хранения. Для принятия правильного решения о способе связи данных (в одном хранилище или разных, синхронизация та или иная, или связь только логическая в разуме польователя или другими не ИТ средствами) необходимо 1. Разбить все данные на как можно более мелкие структуры (например информация о контрагенте может храниться в 10-ках связанных структур). 2. Связи структур скомпоновать в некоторые группы, (причем некоторая группа структур в одном хранилище может быть представлена в другом, некоторой простой конечной таблицей данных). 3. Оценить насколько в нескольких хранилищах (сузестующих или каких-то проэктируемых подсистем) структуры пересекаются. И если пересечение более например 20% - такие структуры должны быть в одном хранилице, а если менее, то в разных, но такой граничный процент будут зависеть еще и от технических возможностей оборудования, жесткости разделения прав доступа и других факторов, так что придется сопоставить все выгоды и потери от вариантов решения.

Я думаю в основе критерия должна лежать частота использования тех или иных данных. Часто используемые - грузить автоматом в ХД по стандартной процедуре. Редко используемые - пусть пользователи сами линкуют к отчетам. Вот только что значит "часто" и "редко" - это вопрос. Опять же, если пользователи начали делать свои витрины и подгружать туда свои данные - как этим управлять? Как регламентировать этот процесс, чтобы избежать разночтения одних и тех же показателей в разных витринах?

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

А надо ли отвечать на вопрос что такое "часто" и что такое "редко"? Может достаточно ранжировать отчеты по частоте использования и переносить в центральное хранилище столько из наиболее используемых, сколько позволяют имеющиеся ресурсы?
Кстати, в PoverPivot'е на SharePoint 2010 вроде бы обещают инструмент для мониторинга частоты использования отчетов в виде анимированной пузырьковой диаграммы, которая показывает как менялась частота использования со временем.

хорошая тема Дмитрий! Действительно эта тенденция сейчас наростает. Не скажу что она новая, просто количество централизованных внедрений начинает проявлять новые качества.
Почему бизнеса хотят песочники? Потому что это быстрее чем ожидать системного решения. И действительно нет жестких рамок, навязанных другими подразделениями. В т.ч. не надо никому ничего объяснять - готовы все делать сами.
Но при этом, часто неявно, остается необходимость основные данные получать из достоверного централизованного источника и регулярно.
По сути это не альтернатива а параллельный процесс ускоряющий получение результатов для конечных пользователей.

Именно так. Только в некоторых случаях это не просто ускорение процесса, потому что не хочется ждать долго, а жизненная необходимость. Например, при аудите в банках, аудиторы часто запрашивают информацию, которой нет в готовых отчетах. И таких запросов может быть очень много, но они бывают, скажем раз в год. Если под каждый такой запрос писать ETL, обновлять структуру данных в ХД, метаданные BI и строить отчеты - это займет месяцы, а кроме того это будет возможно востребовано через год-другой, а может и нет. С другой стороны, эти запросы могут потребовать достаточно массивной выборки и обработки данных, которую не получится сделать в Excel - не тянет он такие объемы. Вот и приходится под каждый чих все бросать и писать SQL. А вот с QlikView ответы аудиторам давать намного проще - проверено.

Что это за отчет такой ,что его месяц писать нужно?

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

Так все таки, что за отчеты такие (состав группировок например)?

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

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT