Не так давно я смотрел на красивые ролики HANA и посмеивался в кулачок. Типа решили всех обмануть красивой картинкой, в память базу затащили и поэтому все так быстро стало работать. Признаюсь — был неправ, вспылил. Почитал на днях подробнее про техническую архитектуру ханы — интересно. Я как программист старой школы жил в измерениях реляционных баз данных со строчным доступом. Потом появились в моем сознании документо-ориентированные базы. А теперь хана до меня дошла. Почитайте про column-based базы (не знаю как правильно на русский перевести).
Идея ханы очень простая — изменить способ доступа к данным и затащить все в память. В сумме это дает огромный прирост скорости, при котором работа с обычной ERP становится сопоставима с BW в части больших выборок (отчетов). Это открывает новые возможности для работы с большими данными в области ERP и HCM в частности.
Не так давно я писал про декластеризацию, еще не особо понимая, зачем она нужна. Сейчас прозрел. В HR Renewals 2 появился пульт управления расчетом заработной платы. Та самая волшебная кнопка — работать, которую любят и ждут все бухгалтера страны. Кроме того, что она красивая, зеленая, она еще умеет делать одну штуку, от которой все клиенты будут наши. Это сравнение расчета с предыдущим. Часто расчетчики спрашивают, а как можно сравнить результат расчета с предыдущим по фондам, чтобы увидеть подозрительные отклонения и найти ошибку. Получите-с. Все хана. Декластеризация позволила снять ограничения по скорости. Теперь к результатам расчета заработной платы можно обращаться быстро, мгновенно, пулей, вжик! Это означает, что мы мгновенно можем сравнить десяток тысяч табельных номеров с самими собой в прошлой жизни предыдущем периоде.
И волшебная кнопка может показать сравнение по фондам, по видам оплаты, по табельникам. Вот и быстрый способ найти ошибки в данных до того, как вся эта радость упала в контроллинг и свалилась в IDOCе из-за ограничения бюджета на СПП элементе. Кто встречал, тот молодец.
Что дальше? Декластеризация инфотипов и расчета заработной платы позволяет использовать новый механизм для аудита изменений инфотипов/данных. Появился вроде в 6 или 7 EhP. Это все теперь можно выгружать в BW и шлепать по попе пользователей за невыполнение транзакционной нормы в час. Руководители поддержки получат мгновенные KPI.
Быстрый доступ к данным открывает новые возможности для отчетности. Уже начали появляться элементы BW отчетов в ERP части. Порталы стали шуршать, а не скрипеть. Наряду с красивостями UI5 мы начали приближаться к реалтайм решениям в области управления предприятиями. Лет через цать на сотовом телефоне можно будет видеть погрузку песка в карьере в реальном времени с точностью до кубометра. В дашбордах на BOBJ Explorer 😉
Хотите еще интересностей? 😉
6 комментариев
KoStiK
Хотим. Как я понимаю выгрузку из кластера делаем ежемесячно после расчета ЗП? А место на сервере базис отжалеет, Если табельных в системе свыше 10К и системе не первый год? 🙄
Dmitry
Ага!
VirVit
В моем понимании ничего выгружать не надо. Система уже сама будет в таком виде записывать данные. То есть не в кластер, а в прозрачные таблички. Для пользователя ничего не меняется. Но места, вы правы, нужно будет существенно больше.
KoStiK
А как же:
HRDCT_LOAD_PT_B2 — Декластеризация -> Начальная загрузка для результатов оценки времени
и
HRDCT_LOAD_PY_UR — Начальная загрузка декластеризации результатов расчета зарплаты
ну и
HRDCT_LOAD_PY_RX — Расчет зарплаты — декластеризация — начальная загрузка
Или я не в тот лес пошёл?
Пока все не так радужно 🙁 .
ZGilGelad
Если я правильно помню, то для функционирования HANA необходимо не просто место на сервере, другое железо с большим объемом оперативной памяти, что стоит очччень немаленьких денег?
KoStiK
HANA у нас уже есть и успешно функционирует. Вот только хоцца ее по полной юзать. )