Отчеты F # и "уровень предприятия"

На основе вашего фактического опыта, технический документ или другого уважаемого справочного исследования, является ли F # в настоящее время жизнеспособным инструментом для отчетов корпоративного/корпоративного уровня?

^{Внимание: перед голосованием, чтобы закрыть этот вопрос как "не конструктивный", пожалуйста, прочитайте бит внизу.}

Фон
В настоящее время я работаю в крупной корпорации, которая активно использует множество различных инструментов отчетности, включая (но вряд ли ограничивается) SAS, Cognos, SSRS и даже хорошее изложение COBOL. Каждый инструмент имеет свое законное место, и многие из них в большинстве случаев эквивалентны в наборе функций и т.д. Большинство наших инструментов могут легко выводиться в PDF, Excel и базы данных и в этих случаях прекрасно работают.

К сожалению, моя организация, как и многие другие, использует электронные таблицы Excel, любит ее или ненавидит, мы тратим много часов на то, чтобы использовать консольные приложения .NET для извлечения информации и вставки информации в электронные таблицы Excel. (Мне не интересно спорить о достоинствах или недостатках этого подхода. Это то, что есть, и я не могу изменить его.)

Как и технологии отчетности, перечисленные выше, они падают, когда речь заходит о передовых ETL от или в электронных таблицах. Они просто не были разработаны для этого, и хотя они отлично умеют форматировать отчет в виде таблицы Excel, они не очень хорошо обновляют существующую таблицу или извлекают данные определенным образом (извлекайте только значения, выделенные красным цветом, например). Поэтому мы заканчиваем тем, что пишем LOT консольных приложений .NET, чтобы сделать этот бит. (Опять же - не заинтересован в обсуждении подхода. Это то, что есть. Я знаю - мне тоже это не нравится.)

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

Итак, мы заканчиваем тем, что пишем два приложения для одной задачи - например, задание SAS для загрузки данных из нескольких источников данных, выполняем преобразования и сохраняем результат в постоянном или временном местоположении, а второй .NET чтобы получить результаты и загрузить их в таблицу. (Я знаю.)

Точка
В последние пару лет я много слышал и слышал о F #, и я немного потрудился в этом. Я изучил OCAML в колледже, и мне нравится функциональное программирование. Когда вызывается, я хотел бы сделать все программирование для конкретного отчета на одной платформе (если не на одном языке). Однако вопрос заключается в том, готов ли язык F # и .NET Framework к отчетности на уровне предприятия - и я говорю о том, что должен работать точно и эффективно. Microsoft, безусловно, продает его трудно, но я хочу знать, действительно ли кто-то, кто имеет опыт работы в других технологиях отчетности, попробовал это в производственной среде. Как он сравнивается с другими технологиями отчетности и может ли он легко интегрироваться в корпоративную среду? Как вы обращались к безопасности? Правильно, какой профиль памяти требуется F # (мы говорим миллионы записей)? Хорошо ли он обрабатывает табличные данные? Это эффективно? Насколько легко его поддерживать (особенно, если код растет)? Какие сторонние надстройки, плагины и т.д. Необходимы для того, чтобы что-то работать (или он может делать все, что угодно)? Сколько работы (часы программирования и т.д.) Требуется по сравнению с другими системами отчетности (для аналогичных результатов)?

Если у вас нет опыта работы с F # или если вы используете только F #, то меня не интересует ваше мнение - я бы хотел услышать от тех, кто действительно преодолел этот пробел и может связать, по опыту, возможности и недостатки в использовании F # в качестве механизма отчетности для больших данных (миллионы записей, выводимых в различные форматы).

Я видел несколько вопросов, которые уже охватывают некоторые из этих оснований:

Но им уже несколько лет. Несколько версий позже, F # до задачи? Или я собака лаем по неправильному дереву?

ИЗМЕНИТЬ

Просто для ясности я особенно заинтересован в F # new информационно-насыщенном программировании. До F # 3.0 это была просто интересная технология, но F # недавно добавленные возможности для использования поставщиков типов баз данных и выражения запроса выглядят так: жизнеспособной альтернативой другим технологиям создания отчетов. Microsoft, безусловно, предлагает.

Допустимый ответ будет содержать учетную запись первого лица (или ссылку на документированное тематическое исследование) внедрения механизма отчетности на уровне предприятия, построенного в F #, и сравнения с другой технологией отчетности любого прирост производительности или потери и т.д. Это не должно быть слишком подробным - достаточно, чтобы убедить среднего (компетентного) менеджера, что F # будет подходящей/неподходящей технологией для обработки объемных/пакетных данных. Это сделано? Кто сделал это? Каковы были результаты? Насколько сложной была реализация (по сравнению с аналогичными технологиями)? Он хорошо работает?

Почему я задаю субъективный вопрос?
Как и большинство лучших участников stackoverflow, я часто голосую, чтобы закрыть субъективные вопросы. Согласно FAQ, следует избегать субъективных вопросов, но они не запрещены полностью. Часто задаваемые вопросы о ссылках на шесть рекомендаций по большим субъективным вопросам, которые я попытался выполнить. Пожалуйста, прочитайте эти рекомендации перед голосованием, чтобы закрыть этот вопрос.

Ответ 1

Как он сравнивается с другими технологиями отчетности и может ли он легко интегрироваться в корпоративную среду?

Я не знаю, как F # сравнивается с другими технологиями отчетности, но я развернул его в более чем одной корпоративной среде, и он в основном такой же, как С#, т.е. простой и надежный.

Как вы обращались к безопасности?

То же, что и С#.

Правильно, какой профиль памяти требуется F # (мы говорим миллионы записей)?

Я нашел одну ошибку GC в .NET за 5 лет использования, и она не была специфичной для F #. У меня было несколько проблем с большими объектами (опять же, не с F #), но, в общем, GC является надежным и эффективным и собирает агрессивно.

Я обработал миллиарды записей и нашел F # чрезвычайно быстрым и очень надежным. Обратите внимание, что F # используется в Microsoft Bing AdCenter (для размещения объявлений) и Microsoft Halo 3, для обоих из которых требуются обработанные терабайтные наборы данных.

Хорошо ли он обрабатывает табличные данные?

Да, и у вас есть легкий parallelism (см. модуль Array.Parallel), но его основная сила по сравнению с другими инструментами заключается в управлении структурированными данными, такими как деревья и графики.

Эффективен ли он?

Да.

Наш текущий клиент, одна из крупнейших в мире страховых компаний, продемонстрировал 10-процентное улучшение производительности с С++ до F # (а также сокращение размера кода на 10 раз).

Предыдущий клиент увидел улучшение производительности, перемещая компилятор из OCaml в F #. Это впечатляет, потому что OCaml был специально разработан для написания компиляторов и очень быстро.

Бывший клиент заставил нас переписать свою торговую платформу, и мы увидели улучшения пропускной способности и латентности 100x, хотя мы перешли от не-GC С++ к GC'd F #.

Насколько легко поддерживать (особенно, если код растет)?

Простота обслуживания. В ML добавление функций не требует проблем, а система статического типа уловов дает вам много обратной связи при расширении типов соединений.

Наш текущий клиент поставил свой первый код F # в живую в апреле прошлого года, и у его сопровождающего не было проблем, несмотря на то, что он вообще не тренировался в F # (или OCaml).

Какие дополнительные сторонние надстройки, плагины и т.д. необходимы для того, чтобы что-то работать (или он может делать все из коробки)?

Мы никогда не использовали (но мы продаем два!). Единственными сторонними вещами, которые я рассматривал, являются элементы управления WPF, которые, опять же, не специфичны для F #.

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

Не знаю, извините. Похоже, у нас есть работа с Dialogue и HP Extreme, поэтому я скоро узнаю...

Насколько сложной была реализация (по сравнению с аналогичными технологиями)?

Код F # намного проще, чем старые основные языки, такие как С++, С# и Java.

Я хотел бы подчеркнуть, что F # действительно выплачивает дивиденды, когда вы используете его, чтобы атаковать проблемы, которые слишком сложны для решения, используя более традиционные инструменты, а не просто переписывать старый код в F #.

Например, наш текущий клиент использует механизм бизнес-правил, который стоил им около 1 000 000 фунтов стерлингов, но он не решает их бизнес-задачи (борьба с большими столами, борьба с математикой), поэтому я написал им демо-версию на заказ бизнес-правил двигателя за одну неделю в около 1000 строк кода F #. Я не мог бы сделать это с помощью любого другого инструмента.

Ответ 2

Чтобы ответить на ваш вопрос - вы на правильном пути. Я говорю об этом как о ком-то, кто создал ряд отчетов и больших систем данных. Я построил одну из платформ Big Data Analytics, используемых на eBay в Scala и R. В последнее время я построил Hadoop/Hive F # Type Provider для MSRC. Я могу сказать, что ничто не приближается к стеку F #.net для этой цели. Отличная производительность, простой в использовании встроенный интерфейс, множество библиотек, REPL, Type Providers, WPF для составления диаграмм. Начиная с MSRC, я создаю полнофункциональную F # IDE, которая может быть встроена в Excel, где вы можете использовать провайдера типов для взаимодействия с книгой в комплекте с Intelisense. Напишите мне, если вы захотите его увидеть.

Edit

Конечно; Я заменил одну из моих клиентов базу данных Infobright на F #, используя данные в памяти и механизм с нуля. Это сократило время запроса на 10 с ГБ данных с 30 минут до 100 с миллисекунд. Все это заняло у меня 6 часов, чтобы построить и было всего несколько сотен строк кода. База данных была базой для веб-службы отчетов, которая после обновления стала более гибкой.

В то время как на eBay я делал свою большую обработку данных (объемную/пакетную) в R. Основные плоские файлы составляли 10 с ГБ, поэтому они были слишком большими для Excel. R сделал огромное количество ненужного распределения памяти во время пропусков агрегации; 10 ГБ станет 40 ГБ и будет ползти до остановки, как только он запустит файл подкачки. В зависимости от данных это займет минуты, часы или никогда не закончится. Есть заплаченные R-библиотеки, которые исправляют это, но они ограничивают другими способами. Выполнение агрегатов в F # привело к уменьшению до 100 с миллисекунд с постоянным пространством. Эти скопления составляли 10 с строк кода, примерно такие же, как и у R, но гораздо проще для понимания и проверялись по типу. Ошибка выполнения R-теста после часа обработки из-за опечатки приводит в бешенство.

Я использовал кубы OLAP (например, Microsoft Analysis Services), но эти системы были полностью затмеваны кластерами Big Data и машинами большой памяти. Теперь легко создать собственную машину большой памяти с F # и новым сборщиком мусора в .net 4.5.

Надеюсь, что это поможет.

Ответ 3

Я не уверен, насколько это помогает, но есть несколько документов о F # на веб-сайте Microsoft. Первый, который я привел ниже, специально упоминает статистическую обработку/базы данных, поэтому он может быть наиболее полезным из трех.

Также существует поставщик типа R для F #, что упрощает взаимодействие между F # и R.

Ответ 4

Если вы надеетесь создать "систему отчетности корпоративного уровня с лучшей автоматизацией Excel", я думаю, что вы лаете правое дерево (т.е. это выполнимо), но в дереве есть медведь (а не белка), Другими словами, это редко стоило бы. Теперь, может быть, ваша ситуация является исключением. Чрезвычайные потребности требуют чрезвычайных мер. Но, интересно, есть ли способ абстрагировать биты этого, которые невозможно сделать с помощью вашей системы отчетности, и сосредоточиться на улучшении взаимодействия... вместо того, чтобы строить все с нуля. Правильный подход, я думаю, будет зависеть от деталей, которые вы знаете лучше всего, и, я полагаю, слишком много, чтобы перечислять здесь.

Ответ 5

Я однажды проверил F # для агрегирования по текстовому файлу с разделителями табуляции, содержащему 890 000 записей (500 МБ) примерно через 20 секунд. Он должен быть еще быстрее на более новом оборудовании с Win8 и .Net 4.5. Я думаю, что он достаточно быстро.

Не знаете, каковы ваши требования к отчетности, но проверьте службы SQL Server Analysis Services (SSAS) и службы Reporting Services.

В настоящее время SSAS имеет встроенный в память модуль. Я недавно проверил это с 1 миллиардом строк. Запросы таблицы сводной таблицы Excel, суммирующие более миллиарда строк, произошли примерно через 2 секунды.

Ответ 6

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