Ну, вроде все до меня уже написали. Причем по большей части - по делу.
Могу лишь поделиться нашим опытом довольно многих интеграций с 1С.

Согласен с Критиком, что инициатором лучше если будут ETL-процедуры и лучше "вытягивать", чем "выталкивать". Согласен с Alex_496, что непременно на этапе ETL должна быть и очистка и трансформация, потому что это правильно;)

Мы не приемлем решений (настолько насколько это бывает возможно), когда данные для хранилища выгружаются 1С-ом. Все наши многочисленные попытки получить приемлемый результат этим способом кончались, в результате, переходом на прямые запросы к БД 1С. Проектов было относительно немало и говорить в этом случае о кривизне рук разработчиков выгрузок из 1С, по-видимому, не приходится. Просто они это делают по-своему, не так как обычно требуется для хранения данных в хранилище. Как результат - данные получаемые из хранилища, заполненного по всем правилам с помощью обращения напрямую к БД 1С в обход движка и данные, полученные с помощью "выгрузок" внутренними средствами 1С практически всегда расходились и практически всегда было можно показать, и заказчик с этим соглашался, что с помощью правильно написанных прямых запросов к БД получаются более "правильные" данные. Именно поэтому мы отказались от заполнения хранилища с помощью промежуточных файлов (txt, xml). К тому же это очень долго (недопустимо долго) при достаточно больших объемах данных, хранящихся в 1С, особенно, если невозможно или нецелесообразно инкрементальное заполнение хранилища.

Сам способ реализации доступа к данным базы 1С (через view или каким иным способом через SSIS пакеты) не так принципиален, тут возможны варианты. А вот строить OLAP на вью к таблицам 1С далеко не всегда хорошая идея. Годится только от безысходности при весьма ограниченных бюджетах. Этот путь ведет к серьезным ограничениям функциональности.

Существуют определенные риски, когда 1С-ка при бездумных обновлениях, или странных методах разработке может менять названия таблиц и полей, но по нашему опыту ощущения опасности реализации таких рисков несколько преувеличены, хотя они и не сведены к 0. Это замечание особенно имеет смысл при более менее "устоявшейся" системе.

Что касается " В 1с есть, по сути, свой инструментарий для кубов", то это миф. Никакого "родного" олапа в 1С нет, а то что есть, это близко не олап.

Что касается stage-таблиц. На наш взгляд, это вопрос исключительно деталей реализации проекта. Когда-то они могут быть вполне оправданным и удобным решением, когда-то - лишний этап. Зависит от многих обстоятельств. А вот то, что данные всегда в хранилище лучше "чистить" и "трансформировать", а иногда и предрасчитывать - сие есть факт.

Когда ETL происходит быстро, т.е. минуты, макс. пару десятков минут, всегда можно "договориться" с расписанием регламентных работ, чтобы с ними не толкаться задницами при доступе к таблицам БД. За это время можно выгрузить десятка полтора, в том числе и немаленьких справочников (измерений), мемберов так на несколько сот тысяч, и несколько таблиц фактов с несколькими десятками миллионов транзакций.

Alex_496на ETL десятки минут :)
А тут могут быть варианты. Взять данные за десятки минут - это одно. Сложить их в хранилище в нужном формате - это другое :) Решаем по разному, в зависимости... Но в 1С действительно чаще всего не бывает уж очень много данных. Она, похоже, при этом помирает. Да и, как правило, 1С далеко не всегда единственная система, из которой данные поступают. Я же говорил не о всем ETL, а о процессе забора из нее данных.

paul310То, что Вы не умеете работать с инструментами для анализа данных и подготовки отчетности на данной платформе вовсе не означает, что этих инструментов нет.
Вот давайте только без переходов на личности. Про "инструментарий для кубов" Вам все уже написали. Иначе, сейчас пойдет ремарка про то, что Вы не понимаете что такое OLAP (точнее MOLAP), и разницу между OLTP и OLAP системами. Нет там в 1С ничего кроме сводной таблицы. Архитектура хранения данных в 1С не та, не OLAPовская.
paul310"По-своему"? Это как? Просто бред какой-то... Выкатываешь людям реквест с подробным описанием формата xml файла, механизма его формирования и требуемой периодичности выгрузки - какие проблемы могут возникнуть?

Вы разницу в скорости извлечения данных из 1С когда-нибудь замеряли при при использовании разных способов? И о чем Вам говорят полученные результаты замеров?

По-своему? Ну как самый недавний вариант. Документ - есть, проводка - есть. Деньги на аналитиках - есть. Только вот 1С работает со смещение дат в 2000. И часть этих проводок с деньгами висит на датах типа 2022-02-21. Тогда как подавляющее большинство проводок на датах типа 4012-01-31. Результат - часть проводок (и соответственно денег, количеств) в выгрузки не попадает. Там много еще чего интересного можно получить или не получить в выгрузках. Возможно, такие кривые проводки и можно "выудить" в выгрузки, но для этого надо догадаться что они там есть. И как правило они туда не попадают. Специалисты по 1С, пока им пальцем на такие косяки не покажешь, могут об этом даже не догадываться. Выгрузки из 1С, как правило, получаются какие-то "как-будто через щелочку полученные". Я понимаю, что можно говорить о кривизне рук разработчиков. Но работаем с тем что есть. А есть то, о чем я пишу.

Еще раз, представление о том, что
автордоступ напрямую к БД - это чисто административный гемор в крупной конторе.
чаще всего имеет сильно преувеличенный характер. Риски есть, но на наш взгляд, они перекрываются преимуществами прямого доступа.

paul310проще аналитиков обучить ей пользоваться, чем городить отдельный проект с dwh и olap.
Недавно на проекте по интеграции с 1С даже несложные плоские отчеты не отрабатывали, выдавая ошибку о нехватке памяти на очень нехилом выделенном под 1С сервере).

OLAP отчеты на тех же данных возвращали результат практически мгновенно, причем несколько (5-7) аналитиков на лету строила свои запросы одновременно. Ну, да что объяснять вполне очевидные и всем известные вещи. Sapienti sat...