вот к стати неплохую утилиту нашел https://github.com/sethreno/schemazen/releases
работает быстро.

Пример вызывающего скрипта:

set r=D:\DATA\scripts
set s=SERVERNAME\DEV14
set db=DM

set d=%r%\%db%-%date:~10%-%date:~4,2%-%date:~7,2%_%time:~0,2%-%time:~3,2%-%time:~6,2%
D:\DATA\scripts\SchemaZen.exe script --server %s% --database %db% --scriptDir %d%

вставляем его в sql agent чтобы тот периодически скриптовал БД в отдельную папку с датой в названии.

Всем добрый день. Предлагаю свою инструкцию по установке HDP 2.2 с помощью Ambari:
ihorbobak.com/index.php/2015/05/06/installing-hadoop-using-ambari-server

Кого интересует детальная инструкция по установке дистрибутива от Hortonworks — можете ознакомиться с моей статьей:
ihorbobak.com/index.php/2015/05/06/installing-hadoop-using-ambari-server
ну а также здесь
ihorbobak.com/index.php/2015/06/23/installing-development-tools-on-hadoop
статья об установке средств разработки.

а почему бы вам здесь не написать статью с детальным объяснением как это делается? думаю не я бы один был бы благодарен. мы тоже были бы рады от других поучиться.

Если мы BI проект (в котором самая тяжелая часть — это ETL) уже сделали через прямые SQL запросы, то Вы уж простите — но не будем делать то же самое второй раз через обработки 1С или через COM только для того, чтобы замерить время. Так что я не смогу здесь удовлетворить Ваш запрос.

Но могу уверить вас в том, что если будете тянуть данные (я не о перечислениях, а о регистрах, документах и т.д.) через COM или через обработку 1С — то будет существенно медленее, чем потянуть SQL запросом.

Тут проблема в том, что вытянуть перечисление прямым запросом — невозможно. Вот собственно это единственная часть, которая тянется через COM, все остальное — через SQL.

>«И самый важный вопрос – нашелся ли 1С-программист и где он был все это время? „

Конкретно в этом проекте была ситуация, что программист 1с заказчика уволился, на его место взяли нового, на которого свалилась сразу куча задач, и времени делать обработки у него никак не было.

Заказчик тем не менее BI хотел. Поэтому мы сошлись на том, что тянем SQL запросами напрямую, а он соглашается с тем, что это все может в один момен вылететь (если вдруг поменяется конфигурация 1С), и соглашается с возможными ошибками в выборках данных.

Но еще раз: не рекомендую BI разработчикам так делать. лучше если 1С програмист у заказчика будет сам выдавать данные в промежуточную бд.

Если вы имели в виду «как мы брали данные фактов и измерений», то ответ: в этом проекте — писали прямые SQL запросы. Как писали — см. статью: показаны конкретные обработки, которые помогають написать эти запросы.

Единственная проблема была в том, что вытянуть названия элементов перечислений с помощью SQL запроса — невозможно. Это единственная штуковина, которую приходилось извлекать с помощью COM. Но это извлечение происходит 20 секунд где-то (по всем перечислениям). Согласитесь, в ETL процедуре не самое тяжелое место.

А так в большинстве проектов прямыми SQL запросами данные стараемся не вытягивать. Мы в основном делаем так: заказчик своими силами пишет обработку, которая выдает нам данные в промежуточную «буферную базу» (это может быть либо csv файлы, либо таблицы в sql server, либо dbf — что угодно), а мы тянем нашим UniveralETL или SSIS пакетом из этой буферной базы. Такой подход гарантирует корректность данных и распределение ответственности: программист 1С заказчика отвечает за правильность своих обработок, мы — за все, что дальше после буферной БД.
Но это уже другая тема.

Код приведен выше. Как видно

           foreach (dynamic catalog in a1CConn.Metadata.Enums)
            {
                string enumName = catalog.Name;
                dynamic query = a1CConn.NewObject("Query");
                query.Text = "select * from enum." + enumName;
                dynamic items = query.Execute().Unload();

....
(не буду сюда его еще раз вставлять)

>Почему бы не взять через COM все данные?
Потому, что тормознуто. Сделайте тест на нескольких десятках миллионов записей, и убедитесь сами.