ReSQL.ru
     
powered by simpleCommunicator - 2.0.44     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / OLAP и DWH [игнор отключен] [закрыт для гостей] / SSAS Структуры интеллектуального анализа данных
24 сообщений из 49, страница 2 из 2
  2  все
SSAS Структуры интеллектуального анализа данных
    #40034039
Александр Бердышев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Александр Бердышев
Участник
ptr128


Если на следующем проекте на фазе НИОКР окажется эффективней Python - буду использовать его. Если вдруг окажется эффективней Julia - разберусь и с ней. Если эффективней окажется Spark или ClickHours - буду использовать их.
Никакого желания ограничивать себя "золотым молотком" не испытываю, чего и Вам желаю.

Я всегда искренне считал, что на этапе НИКОР просто необходимо рассматривать альтернативные варианты решения и сравнивать их. А не пытаться подогнать задачи проекта под уже освоенный "золотой молоток".

Работал я как-то на одном проекте, где нашёлся тоже любитель не ограничивать себя "золотым молотком". Дело усложняло то, что он был аж целым тимлидом соседней команды.
В итоге ядро системы работало на MS SQL Server, штук 15 подсистем тоже на MS SQL, а одна подсистема на MongoDB. При том, что там вообще не было никаких предпосылок использовать монгу, да и нагрузка в том месте была на 3 порядка ниже, чтобы о монге вообще стоило задумываться.
И всё взаимодействие с остальными системами и ядром - через API и "шину данных"
Стоит ли говорить, что во первых из-за такого подхода пришлось городить кучу костылей, зато ребята типа "напряжённо работают" и каждый спринт делают трудовые подвиги, которых можно было бы избежать, выбрав нормальный инструмент.
Во вторых отчётность и аналитика просто накрылась неприличным местом - потому что монга с MS SQL очень плохо интегрируется.
Вместо одного пакета на SSIS за неделю пришлось через шину данных и апи делать привлек
...
Рейтинг: 0 / 0
07.01.2021, 15:01
| Ответить | Цитировать | Написать  
SSAS Структуры интеллектуального анализа данных
    #40034040
Александр Бердышев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Александр Бердышев
Участник
привлекать ещё 2 команды и 2 месяца разработки.
В итоге вместо нормального подхода получилось ужасное чудовище, которое очень неудобно поддерживать и искать где ошибка - т.к. несколько команд пришлось задействовать.
Резюмируя: зоопарк разных технологий на одном проекте - плохо.
Использовать непопулярные технологии - тоже плохо, т.к. будут проблемы с интеграцией данных, поддержкой, поиском новых сотрудников.
...
Рейтинг: 0 / 0
07.01.2021, 15:06
| Ответить | Цитировать | Написать  
SSAS Структуры интеллектуального анализа данных
    #40034044
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ptr128
Участник
Александр Бердышев
Работал я как-то на одном проекте, где нашёлся тоже любитель не ограничивать себя "золотым молотком". Дело усложняло то, что он был аж целым тимлидом соседней команды.

Эти два предложения противоречат друг другу. Тимлид не имеет никакого права выбирать технологии. Он может только произвести прототипирование и предоставить руководству его результаты.

Тот же PostgreSQL у нас санкционировался на уровне совета директоров. Даже IT директор сам не решился включить его в инфраструктуру.

Как писал уже выше, сработала финансовая сторона, а так же давление со стороны госорганов на импортозамещение. Все же предприятие стратегического значения.
С R, как я уже писал выше, проблем не было, так как он уже использовался в инфраструктуре для финансовой дирекции.
...
Рейтинг: 0 / 0
07.01.2021, 15:21
| Ответить | Цитировать | Написать  
SSAS Структуры интеллектуального анализа данных
    #40034049
H5N1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
H5N1
Участник
ptr128

Вы не заметили, что сами себе противоречите? Если задачу можно решать в несколько потоков, то совсем не обязательно одним вызовом скармливать ей весь объем данных сразу.

нет, я не противоречу. если задачу можно в теории распараллелить, это вовсе не значит, что это в самом деле реально провернуть в реальной жизни. в реальной жизни у тебя фреймворк обучает датасет, который на вход получает train set, test set. по мне колхозить свои алгоритмы, которые смогут построить модель получая данные кусками не самая здоровая идея.

ptr128

Вам просто сложно осознать в голове концепцию того, что массу черновой работы по трансформации и очистке данных можно оставить на стороне SQL, отдавая plr/plpython только те задачи, которые они решают лучше, чем plpgsql. На практике, функции plr/plpython получаются довольно небольшими и простым. Ведь сам алгоритм реализуется в plpgsql. Бессмысленно кормить ту же ARIMA временной серией длиней нескольких сотен элементов. А вот подготовить временную серию длиной не более, чем в 300 элементов из миллиона - с этой задачей справляется plpgsql, задействуя оконные и/или агрегативные функции на R только в некоторые моменты.

Необходимое количество потоков не сложно реализовать через dblink средствами того же PostgreSQL. Это не менее эффективно, чем многопоточность средствами R или Python и позоволяет без особых проблем разпределять задачи не только между локальными ядрами, но и между серверами.

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

прелесть спарка в таких задачах, что там на входы, выход подаются датафреймы и это уже дело либы и спарка как это все порубить, разбросать на узлы и где-то собрать поток данных. но тут кто-то должен заморочиться и реализовать алгоритмы поверх датафрейма, который в связке со спарк распараллелится. но даже тут все равно большинство ML алгоритмов потребую где-то собрать где-то в одном месте большую матрицу и оно где-то упадет с OM.
...
Рейтинг: 0 / 0
07.01.2021, 15:53
| Ответить | Цитировать | Написать  
SSAS Структуры интеллектуального анализа данных
    #40034050
H5N1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
H5N1
Участник
ptr128

так только первую версию в продуктив в декабре запустили. Даже еще не открыли вакансии для ТП.
Сам я собираюсь только помочь в организации поддержки. Все результаты НИОКР обсуждались с руководством, риски учитывались и выбор технологий был санкционирован. Так что, строго говоря, это уже давно не моя головная боль.

что, реально кто-то на это смотрел и в самом деле санкционировал многопоточность через dblink колхозить ?
...
Рейтинг: 0 / 0
07.01.2021, 15:58
| Ответить | Цитировать | Написать  
SSAS Структуры интеллектуального анализа данных
    #40034056
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ptr128
Участник
H5N1
что, реально кто-то на это смотрел и в самом деле санкционировал многопоточность через dblink колхозить ?

А это то при чем? dblink родной и штатный компонент PostgreSQL. Его то зачем санкционировать? А эксперименты показали, что многопоточность все равно надо управляемым делать. Чтобы не оказалось, что последней было запущенно обучение модели, которое длится час, тогда как остальные, параллельные ей завершились за 5 минут.

H5N1
на вход получает train set, test set

И какого размера они могут быть, для того, чтобы был смысл скармливать их той же ARIMA? )))

H5N1
PG все равно, если не сдохнет то чудовищно проиграет на больших данных в задачах по трансформации и очистки данных альтернативам

"Чукча не читатель, чукча писатель?" (с)
Он уже выиграл у альтернатив. 4ТБ БД, свыше миллиарда атомарных событий на входе, фильтрация и трансформация производится за 30 минут. Прогнозирование по выбранным кластеризацией моделям двух миллионов временных серий - за 4 часа. Кластеризация временных серий кроссвалидацией при подборе моделей - за 15 часов. На данный момент второй сервер не запущен, а первый ограничен 24 ядрами. То есть, прогнозируется не менее, чем двукратное сокращение времени на прогнозирование и кластеризацию.
Хотя в целевые показатели (8 часов на прогнозирование и 24 часа на кластеризацию) мы и так вписываемся.

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

И в этом, как выяснилось, его недостаток.
1. В него надо данные загрузить, тогда как они у меня так и остаются в одной БД
2. Порубить тоже надо с умом, чтобы равномерно грузить узлы, а не долго ждать, пока последняя задача закончится на последнем узле.
...
Рейтинг: 0 / 0
07.01.2021, 16:22
| Ответить | Цитировать | Написать  
SSAS Структуры интеллектуального анализа данных
    #40034057
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ptr128
Участник
H5N1
что, реально кто-то на это смотрел и в самом деле санкционировал многопоточность через dblink колхозить ?

Сорри. Только что дошло, что Вы обыкновенный тролль. Это же надо быть полным дебилом, что задавать такой вопрос без целей троллинга.
...
Рейтинг: 0 / 0
07.01.2021, 16:29
| Ответить | Цитировать | Написать  
SSAS Структуры интеллектуального анализа данных
    #40034089
H5N1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
H5N1
Участник
ptr128

И в этом, как выяснилось, его недостаток.
1. В него надо данные загрузить, тогда как они у меня так и остаются в одной БД


plr/plpython это внешние по отношению к субд процессы. plpython запускает из папочки /bin питончик, делает коннекцию к субд и тащит каждый битик в питон. при этом затрачиваются гигантские ресурсы на конвертирование типов из субд в питоновские. никакой принципиальной разницы со спарком и его jdbc коннекции нет.
постгрес не умеет клатеризоваться, там нет колончатых структур, в посгресе нет компрессии. 4Тб постгреса выгрузятся в отсилы в 2Тб csv, т.к. блоках данных постгреса туча лишней для аналитики служебной информации. для аналитики использую greenplum, вариация массивно-параллельного постгреса с колончатой структурой. 2Тб csv упакуются в колончатый формат parquet всего в 0.7Тб

ptr128

2. Порубить тоже надо с умом, чтобы равномерно грузить узлы, а не долго ждать, пока последняя задача закончится на последнем узле.

у тебя уже натренированы модели, там нечего уже считать. для таких задач принято в реалтайме выдавать ответ имея уже натренированные модели. обычно читают из кафки и в реалтайме пишут в туже кафку ответ.
...
Рейтинг: 0 / 0
07.01.2021, 21:16
| Ответить | Цитировать | Написать  
SSAS Структуры интеллектуального анализа данных
    #40034115
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ptr128
Участник
H5N1,

H5N1
plr/plpython это внешние по отношению к субд процессы

Ложь. И то, и другое выполняется в среде PostgreSQL. Внешние языки подключаются к PostgreSQL через so и выполняются в его среде.

H5N1
делает коннекцию к субд

Ложь. Обмен данныеми происходит через параметры. В крайнем случае - через SPI (Server Programming Interface).

H5N1
затрачиваются гигантские ресурсы на конвертирование типов из субд в питоновские. никакой принципиальной разницы со спарком и его jdbc коннекции нет

Ложь, так как трансформация данных в памяти на порядок менее ресурсоемка, чем пересылка этих же данных через JDBC.

H5N1
постгрес не умеет клатеризоваться

Ложь. Средств для этого более чем достаточно, начиная с примитивных Crunchy Proxy, Pgpool2 с Kubernetes и т.п. и заканчивая готовыми решения для бизнес аналитики, как CitusDB.

H5N1
там нет колончатых структур

Ложь. Даже если не нравится cstore, то есть тот же CitusDB.

H5N1
в посгресе нет компрессии

Ложь, так как TOAST так же и компрессиия, а если мы храним данные в массивах, то они точно будут попадать под сжатие TOAST, если специально с этим не бороться.

H5N1
4Тб постгреса выгрузятся в отсилы в 2Тб

Ложь, так как в БД в основной своей массе массивы четырехбайтовых real, каждый элемент которых при преобразовании в текст станет занимать в два раза болььше места.

Прошу прощения, но зачем Вы нагло лжете с умным видом?
...
Рейтинг: 0 / 0
08.01.2021, 02:39
| Ответить | Цитировать | Написать  
SSAS Структуры интеллектуального анализа данных
    #40034116
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ptr128
Участник
H5N1
у тебя уже натренированы модели

Днем да. Но это мне даже не интересно, так как взяв из них прогноз на следующие 8 недель я больше к ним не обращаюсь.

Но модели надо, во-первых, обучать/дообучать каждую ночь, во-вторых, надо кластеризовать вектора, заново выбирая модель кроссвалидацией каждую неделю.
Больше всего волнует распределение по вычислительным узлам как раз обучаемых моделей.
...
Рейтинг: 0 / 0
08.01.2021, 03:10
| Ответить | Цитировать | Написать  
SSAS Структуры интеллектуального анализа данных
    #40034121
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ptr128
Участник
ptr128

H5N1
4Тб постгреса выгрузятся в отсилы в 2Тб

Ложь, так как в БД в основной своей массе массивы четырехбайтовых real, каждый элемент которых при преобразовании в текст станет занимать в два раза болььше места.


На всякий случай, чтобы не быть голословным, приведу пример на одной из табличек.
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
  CREATE TABLE dv3.time_series_arrays (
    VectorId    integer     NOT NULL,
    Cnt         integer     NOT NULL,
    Std         real        NULL,
    AvgHours    real        NOT NULL,
    QLNorm      real        NOT NULL,
    Perc        real[]      NOT NULL,
    TimeInHours real[]      NOT NULL,
    OperDate    timestamp[] NOT NULL,
    MaxDate     date );
  CREATE UNIQUE INDEX time_series_arrays_Idx ON dv3.time_series_arrays (VectorId);



Row Count Estimate: 1 866 021
Disk Space: 2,2G
Rel Size: 771M

Код: plsql
1.
COPY dv3.time_series_arrays TO '/backup/pg_backup/time_series_arrays.txt'



Код: plaintext
1.
2.
3.
ls -l --block-size=G /backup/pg_backup/time_series_arrays.txt

-rw-r--r--. 1 postgres postgres 40G Jan  8 05:03 /backup/pg_backup/time_series_arrays.txt

Разница в 18 раз. Устроит?
...
Рейтинг: 0 / 0
08.01.2021, 05:12
| Ответить | Цитировать | Написать  
SSAS Структуры интеллектуального анализа данных
    #40034437
Фотография Критик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Критик
Участник
ptr128
.опытка решить задачу на MS SQL требовала обязательно Enterprise из-за ограничения на 4 ядра у R Service у Standard. А это свыше 7 тыс. вечнозеленых ежемесячно за 32 ядра


Таки реально ежемесячно?
Какой вид лицензии, можно со ссылкой на их сайт? Или это премьер-поддержка?
...
Рейтинг: 0 / 0
09.01.2021, 18:41
| Ответить | Цитировать | Написать  
SSAS Структуры интеллектуального анализа данных
    #40034453
Фотография vikkiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vikkiv
Участник
Критик,

Вроде если в лоб то похоже на это:
(13'748+(15x5'434))/12=$7'938

https://docs.microsoft.com/en-us/sql/sql-server/editions-and-components-of-sql-server-version-15?view=sql-server-ver15#Programmability
FeatureEnterpriseStandardBasic R integration 1 YesYesAdvanced R integration 2 YesNoBasic Python integrationYesYesAdvanced Python integrationYesNo1 Basic integration is limited to 2 cores and in-memory data sets. << (т.е. 4 "ядра" это наверное с HT,
. . . ну или больше если процессора другого класса,{где-то читал что работают над такими архитектурами})
2 Advanced integration can use all available cores for parallel processing of data sets at any size subject to hardware limits.

https://www.microsoft.com/en-gb/sql-server/sql-server-2019-pricing
EditionsOpen no level price (US$)Licensing modelEnterprise$13'748 [1] 2 core packStandard – per core$3'586 [1] 2 core packStandard – server$899 [1] Server [2] Standard - CAL$209CAL

Subscriptions and add-onsPrice (US$)Licensing modelSQL Server Enterprise5434 USD/year2 core packSQL Server Standard1418 USD/year2 core pack
[1] Pricing represents open no level (NL) estimated retail price. For your specific pricing, contact your Microsoft reseller.
[2] Client access licences (CALs) are required for every user or device accessing a server in the Server + CAL licensing model. See the product use rights for details.

Но с SA конечно дешевле, а если действительно корпоративный клиент - то там ещё меньше.
зависит от версии конечно (на 2014/2016/2017 другие цены были)

A если все физические ядра лицензировать - то виртуалки на них уже без ограничений.
(по операционкам конечно другой вопрос)
...
Рейтинг: 0 / 0
09.01.2021, 19:24
| Ответить | Цитировать | Написать  
SSAS Структуры интеллектуального анализа данных
    #40034458
Фотография vikkiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vikkiv
Участник
А вот, "вспомнил"/нагуглил: у IBM с десяток лет (начиная с POWER7 платформы) х3 тредов, на POWER10 уже x8 тредные на каждое ядро..
правда непонятно насколько это аналогичные трэды в обычном понимании и как там с совместимостью для SQL Server

Кстати - а что помешало при таких-то навыках написать свою собственную CLR побыстрее под SP для интеграции R/Python с SQL Server в обход всех ограничений безопасности из-за контейнерной изоляции процесса?

хотя наверное понятно - если уже есть готовое и проверенное стандартное решение на рынке то зачем изобретать велосипед с кучей возможных проблем себе на будущее
...
Рейтинг: 0 / 0
09.01.2021, 19:59
| Ответить | Цитировать | Написать  
SSAS Структуры интеллектуального анализа данных
    #40034467
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ptr128
Участник
vikkiv
Кстати - а что помешало при таких-то навыках написать свою собственную CLR побыстрее под SP для интеграции R/Python с SQL Server в обход всех ограничений безопасности из-за контейнерной изоляции процесса?

Во-первых, решение на PostgreSQL не надо было писать. Оно есть.
Во-вторых, если PostgreSQL порождает под каждое соединение свой отдельный процесс (fork) и падение интерпретатора приведет к падению только этого процесса, то MS SQL монолитен, и там есть риск падения всего сервера.

Уверен, что в MS не дураки сидят, и, похоже, сделали такую архитектуру вызова внешних скриптов именно для их изоляции от Database Engine.
...
Рейтинг: 0 / 0
09.01.2021, 20:37
| Ответить | Цитировать | Написать  
SSAS Структуры интеллектуального анализа данных
    #40034703
Фотография Критик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Критик
Участник
vikkiv,

Ну, амортизировать ПО за год - этот вариант только для миллиардеров )

Есть корп скидки - там цена часто падает до 2х раз.
Плюс есть всякие акции, когда можно обменять ненужные лицензии Oracle на нужные MS. Можно банально арендовать ПО, или арендовать ПО сразу с железом в облаке. Вариантов куча, только коллега рассмотрел самый дорогой )
...
Рейтинг: 0 / 0
10.01.2021, 18:54
| Ответить | Цитировать | Написать  
SSAS Структуры интеллектуального анализа данных
    #40034710
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ptr128
Участник
Критик,

не тупите. Явно же написано 5434 USD/ year за 2 ядра. Посчитайте для 32 и 64 уже сами.
...
Рейтинг: 0 / 0
10.01.2021, 19:31
| Ответить | Цитировать | Написать  
SSAS Структуры интеллектуального анализа данных
    #40034807
L_argo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
L_argo
Участник
Куда катится этот мир.....
Одних только аббревиатур и технологий - на страницу.

Неужели кто-то верит, что затратив кучу времени и космический бюджет, эти новомодные модельки дадут бизнесу выигрыш хотя бы на 5% больше затраченного бюджета ? Не говоря уже про 20%.

Не надоело забивать гвозди платиновым молотком ?
...
Рейтинг: 0 / 0
11.01.2021, 10:37
| Ответить | Цитировать | Написать  
SSAS Структуры интеллектуального анализа данных
    #40034813
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ptr128
Участник
L_argo
новомодные модельки дадут бизнесу выигрыш хотя бы на 5% больше затраченного бюджета ? Не говоря уже про 20%.


Поясните Ваш метод расчета рентабельности, пожалуйста.

Обычно, считают сначала сокращение затрат, а уже потом сравнивают их со стоимостью разработки.
Например, в моем случае, уже подтвержденные 5% сокращения затрат на логистику есть 10 миллиардов рублей в год. При том, что бюджет еще 100 миллионов не превысил. То есть достигнутая рентабельность 9900%
...
Рейтинг: 0 / 0
11.01.2021, 10:54
| Ответить | Цитировать | Написать  
SSAS Структуры интеллектуального анализа данных
    #40034834
L_argo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
L_argo
Участник
ptr128
L_argo
новомодные модельки дадут бизнесу выигрыш хотя бы на 5% больше затраченного бюджета ? Не говоря уже про 20%.


Поясните Ваш метод расчета рентабельности, пожалуйста.

Обычно, считают сначала сокращение затрат, а уже потом сравнивают их со стоимостью разработки.
Например, в моем случае, уже подтвержденные 5% сокращения затрат на логистику есть 10 миллиардов рублей в год. При том, что бюджет еще 100 миллионов не превысил. То есть достигнутая рентабельность 9900%
Я должен пояснять ???
Это вы должны пояснить свой метод расчета рентабельности и профита. Откуда эти фантастические 9900% взяты ?

Кто решил, что сокращение затрат на логистику именно благодаря новым алгоритмам, без которых ранее это сокращение было невозможным ?

Помниццо в одной компании не вели учет ГСМ. Выдавали просто, кто сколько заявлял. Потом ввели обязательную и простую процедуру отчета о потраченных ГСМ. "Неожиданно" расход ГСМ упал более чем в 2 раза.

Очень вероятно, что в Ваших 9900% имел место похожий феномен: просто навели порядок в БП, а ИИ и ИТ-хипстеры на самом деле не при чем.
...
Рейтинг: 0 / 0
11.01.2021, 12:02
| Ответить | Цитировать | Написать  
SSAS Структуры интеллектуального анализа данных
    #40034841
H5N1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
H5N1
Участник
ptr128

Во-первых, решение на PostgreSQL не надо было писать. Оно есть.
Во-вторых, если PostgreSQL порождает под каждое соединение свой отдельный процесс (fork) и падение интерпретатора приведет к падению только этого процесса

можешь пояснить, если ты понимаешь то это совершенно сторонний от субд процесс, нафига клоунаду с "ложь" устроил ?
и лапоть, csv файлик упакуй.

ptr128

Уверен, что в MS не дураки сидят, и, похоже, сделали такую архитектуру вызова внешних скриптов именно для их изоляции от Database Engine.

в мс не дураки, потому для задач ML они mssql2019 big data clusters выкатили со spark поверх hdfs.
...
Рейтинг: 0 / 0
11.01.2021, 12:26
| Ответить | Цитировать | Написать  
SSAS Структуры интеллектуального анализа данных
    #40034853
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ptr128
Участник
H5N1,

потому что незачем лгать публично. Это все равно выясниться, так как легко проверяемо.
Или Вы просто тролль, который несет пургу о том, чего даже не знает?
...
Рейтинг: 0 / 0
11.01.2021, 13:26
| Ответить | Цитировать | Написать  
SSAS Структуры интеллектуального анализа данных
    #40034855
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ptr128
Участник
L_argo
ptr128уже подтвержденные 5% сокращения затрат на логистику есть 10 миллиардов рублей в год. При том, что бюджет еще 100 миллионов не превысил. То есть достигнутая рентабельность 9900%


Откуда эти фантастические 9900% взяты ?
Вы местный клоун или считать не умеете?
Если при бюжете проекта в 100 млн. затраты сократились на 10 млрд, то какая рентабельность проекта?

L_argo
Кто решил, что сокращение затрат на логистику именно благодаря новым алгоритмам, без которых ранее это сокращение было невозможным ?

Этот вопрос в сфере деятельности дирекции по логистике. Я даже не вникал в те документы, которые они предоставили на совет директоров. Только удивился, что так мало, но потом уже разобрались, что ряд диспетчеров саботировали рекомендации по адресации из модели, адресуя вагоны по своему личному разумению, как это делали предыдущие 20 лет. Но это уже отдельная история.

L_argo
просто навели порядок в БП

Точно клоун )))
Да, научились в Excel оптимизировать адресацию вагонов )))
Причем 20 лет не могли это сделать, а как только систему внедрили вдруг сумели )))

L_argo
Я должен пояснять ???

Естественно. Вы же как-то считали рентабельность только исходя из бюджета проекта, не учитывая сокращения затрат ))))
...
Рейтинг: 0 / 0
11.01.2021, 13:40
| Ответить | Цитировать | Написать  
SSAS Структуры интеллектуального анализа данных
    #40034874
L_argo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
L_argo
Участник
Вы же как-то считали рентабельность только исходя из бюджета проекта, не учитывая сокращения затратЯ вообще ничего не писал про расчет рентабельности.
Рентабельность не такой простой вопрос, как Вы тут пишете.

Я всего лишь сказал, что затратив на проект 10млн. нужно получить за некий период хотя бы 10.5 млн экономии.
А еще лучше, если превысить ставку банковского депозита, т.к. просто положив 10 млн. в банк можно получить гарантированную прибыль и без всяких ИТ-проектов. :)

В противном случае - пустая трата времени и ресурсов.

Методика расчета экономии может быть очень сложной. И при этом надо правильно оценивать истинные причины этой экономии.

Очень часто "экономический эффект" - банальная подмена понятий и присвоение себе чужих заслуг.
Что полюбляют делать разного рода эффективные менеджеры и внедренцы.

зы: Раз уж пошло дело про вагоны и РЖД, то можно погулить про "белорусский метод". Когда "эффективные менеджеры" начали сокращать обходчиков, помощников машинистов и связистов.

rus-etrain.ruПомощников машинистов тогда и убрали. Именно на это время и приходится самая страшная катастрофа в истории Белоруссии - столкновение пасс. поезда с хвостовой частью электрички. Крыжовка, май 1977 года.
...
Рейтинг: 0 / 0
11.01.2021, 14:48
| Ответить | Цитировать | Написать  
24 сообщений из 49, страница 2 из 2
  2  все
Форумы / OLAP и DWH [игнор отключен] [закрыт для гостей] / SSAS Структуры интеллектуального анализа данных
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru             Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=49&msg=40034874&tid=1857209]:
 0ms
get settings:
 9ms
get forum list:
 13ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 39ms
get topic data:
 13ms
get forum data:
 3ms
get page messages:
 62ms
get tp. blocked users:
 2ms
others: 12ms
total:  161ms
созд. / загр.: 161ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]