Size: a a a

2020 December 23

GP

Grigory Pomadchin in Moscow Spark
er@essbase.ru
Java vs Scala API

народ, скажите знаете ли вы хоть какие то примеры того когда java API было не достаточно и нужно было решать задача через scala ?
я не знаю когда Java API оправдано по сравнению со Scala API
источник

e

er@essbase.ru in Moscow Spark
Мне его навязывают .нужны аргументы
источник

АЖ

Андрей Жуков... in Moscow Spark
Grigory Pomadchin
я не знаю когда Java API оправдано по сравнению со Scala API
в особо кровавом ынтырпрайзе
источник

GP

Grigory Pomadchin in Moscow Spark
er@essbase.ru
Мне его навязывают .нужны аргументы
навязывают скала апи? или жава апи
источник

GP

Grigory Pomadchin in Moscow Spark
Андрей Жуков
в особо кровавом ынтырпрайзе
ну это уже религиозный вопрос
источник

АЖ

Андрей Жуков... in Moscow Spark
Grigory Pomadchin
ну это уже религиозный вопрос
вопрос в подходе к стандартам 🙂 мы вот по tech radar начали с архами работать, стало проще жить
источник

GP

Grigory Pomadchin in Moscow Spark
er@essbase.ru
Мне его навязывают .нужны аргументы
если за скала апи аргументы нужны - то библиотека скаловая
я думаю самое целесообразное использовать жава апи к ней
никого не слушайте и пользуйтесь жава байндингами и отличным жава апи!
источник

GP

Grigory Pomadchin in Moscow Spark
Андрей Жуков
вопрос в подходе к стандартам 🙂 мы вот по tech radar начали с архами работать, стало проще жить
а кидани ссылок кстати
источник

GP

Grigory Pomadchin in Moscow Spark
тоже жава апи используете теперь?
источник

GP

Grigory Pomadchin in Moscow Spark
Андрей Жуков
вопрос в подходе к стандартам 🙂 мы вот по tech radar начали с архами работать, стало проще жить
ну религиозный тут было да о стандартах; все верно
источник

ПФ

Паша Финкельштейн... in Moscow Spark
er@essbase.ru
Java vs Scala API

народ, скажите знаете ли вы хоть какие то примеры того когда java API было не достаточно и нужно было решать задача через scala ?
я не верю в существование таких случаев чесгря
источник

GP

Grigory Pomadchin in Moscow Spark
Паша Финкельштейн
я не верю в существование таких случаев чесгря
да наверняка чет есть, только оно незначительно
упирается в красоту / удобство кола
источник

АЖ

Андрей Жуков... in Moscow Spark
Grigory Pomadchin
тоже жава апи используете теперь?
какразтаки нет
источник

АЖ

Андрей Жуков... in Moscow Spark
Grigory Pomadchin
а кидани ссылок кстати
https://opensource.zalando.com/tech-radar/
вот примерно так
источник

GP

Grigory Pomadchin in Moscow Spark
интересно
источник

GP

Grigory Pomadchin in Moscow Spark
спасибо
источник

ПФ

Паша Финкельштейн... in Moscow Spark
Grigory Pomadchin
да наверняка чет есть, только оно незначительно
упирается в красоту / удобство кола
Ну так да — это не "принципиально невозможно", это "некрасиво"
источник

ПФ

Паша Финкельштейн... in Moscow Spark
Всё джава апи такое )
источник
2020 December 24

e

er@essbase.ru in Moscow Spark
Многомерные расчеты
у меня есть пилот по переводу OLAP кубов Essbase на Spark c увеличением детализации до размеров BigData.

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

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

- Вопрос мой следующий , есть ли приемы или инструменты , которые упростят разработку. В идеале  - Очень хочется где нибудь один раз определить мета-модель , и потом дергать ее элементы.
Ну или на данном этапе подойдет подход, который позволит переопределять единичное значение в массиве , не затрагивая определения из других срезов.


если кто решал подобную задачу поделитесь пж. примерами кода )
источник

DZ

Dmitry Zuev in Moscow Spark
er@essbase.ru
Многомерные расчеты
у меня есть пилот по переводу OLAP кубов Essbase на Spark c увеличением детализации до размеров BigData.

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

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

- Вопрос мой следующий , есть ли приемы или инструменты , которые упростят разработку. В идеале  - Очень хочется где нибудь один раз определить мета-модель , и потом дергать ее элементы.
Ну или на данном этапе подойдет подход, который позволит переопределять единичное значение в массиве , не затрагивая определения из других срезов.


если кто решал подобную задачу поделитесь пж. примерами кода )
Троллейбус жпг
источник