Comments 10
Про п. 3 — все же есть MyST Markdown (вдохновленный как раз RMarkdown), который позволяет писать отчет с исполняемыми блоками кода.
Если я правильно понимаю, то это пакет с ограниченными целями — разработка html книг с возможностью перевода в pdf путем печати на pdf принтере. Ближайший сутевой аналог — AsciiDoc, но пока никак не RMarkdown. Поправьте, если не так.
RMarkdown существенно шире. Это и различные интерактивные отчеты, и генерация книг, отчетов, сайтов. Создание различных внешних представлений из одного исходника (word, tex, pdf). Возможность создания презентаций (например, xaringan).
Я даже не стал упоминать Shiny, чтобы не было споров, потому как по его мотивам появилось недавно такое направление и в python (Dash). Но это уж совсем vendor lock-in (Plotly). В plotly ужасно тесно.
Что касается R vs python — по тому же kaggle видно, что доля скриптов на R последние несколько лет неуклонно падает. Подозреваю, что не в последнюю очередь из-за того, что в R до сих пор нет приличного deep learning фреймворка, а велосипед R keras -> py keras не кажется особенно надежным. Может, R torch доведут до ума.
- Да,
data.tableпортируют. В тестах на производительность он есть. Но для чего пользоваться медленным полуфабрикатом, если есть оригинал? Поэтому даже не счел нужным упоминать. Совсем аутсайдерская экзотика, тем более что базисом в питоне выступаетpandas. - Все многообразие задач не сводится к
deep learning. Ну да, там питон используется активно. Но по сути это такая же клеевая прокладка между внешними платформами. Вся сила в платформах и понимании алгоритмов, а не в байндингах. - Есть еще интересные платформы, например, H2O.
А вот из-за отставания в
deep learning (модно-молодежно) R не стал популярной «прокладкой» к низкоуровневым библиотекам. Питон же постепенно переваривает все интересные фичи R (ну и других языков). Даже без deep learning в R не хватает удобного фреймворка для работы с GPU.H2O тянет за собой Java + еще один формат as.h2o + интересные ошибки — у меня не те масштабы, чтобы оценить удобство такого подхода.
так вроде уже отвязали torch от питона как от лишней тормозящей прослойки
с другой стороны если использовать только SQL (любой), то не нужно создавать новую инфраструктуру — все может работать на существующей инфраструктуре для продуктовых баз данных. Сами SQL специалисты в целом дешевле и более квалифицированные (за те же деньги для питониста-ДС можно взять убер скиллового SQL эксперта).
визуализацию вообще можно/нужно отдать в руки бизнеса (BI embedded into business), пусть каждый отдел который занимается бизнесом берет себе BI специалиста — тулы типа ПоверБИ/Табло могут покрыть 99% нужд бизнеса, они будут внедрены в контекст самого бизнеса и будет быстрый «feedback loop».
единственно куда нужно брать специалисов питон/R (без разницы какой язык) — это продуктовое машинное обучение, т.е. создание и поддержание новых продуктов с использованием МЛ. Причем это будет зависеть от ниши — если вы в computer vision — то вам нужен и питон и С++.
Если вы в финансах/страховании — то скорее всего у вас есть кодовая база на SAS, и нет смысла менять стек.
Так что грубо говоря без разницы какие там недостатки у пандас по сравнению с data.table, пандас вообще не нужен как таковой. Нужен:
1. SQL для ETL
2. решение для BI визуализации (powerBI, tableai, microstrategy, pentaho, qlikview, etc.), чтобы люди близкие к бизнесу, но далекие от ИТ могли сами себе свои диаграммы и отчетики клепать (self-service Business Intelligence так называемый)
если вам нужен МЛ, то:
3. нужен любой подходящий язык для разработки статистических моделей, которые приходят из ETL
4. подходящий рантайм для деплоя и мониторинга стат моделей в проде.
Мы уже обсуждали подобный подход, например, здесь: https://habr.com/ru/post/461463/.
Он вполне логичен.
Но на практике оказывается, что есть огромное количество задач, которые не могут быть решены классическим ETL и не натягиваются на модель прямоугольного табличного мира.
Вот тут вот рассказывали кусочек: https://www.meetup.com/ru-RU/rMoscow/events/267695103/. Мир DBA крайне ограничен, SQL неспособен работать в среде неструктурированных, многоформатных и обрывочных данных. Это все равно как битый блок на диске. Файл прочитать нельзя (DBA подход), но если это картинка, то и с одним битым блоком можно ее почти всю восстановить (DS подход).
Self BI — классные инструменты. Но у них есть 2 маленьких изъяна, которые сжирают все их преимущество.
а) нужны хорошие прямоугольные данные. далеко не для каждой задачи они существуют и могут быть получены ETL/DAD преобразованием.
б) self-analytics требует от человека совокупности навыков по обработке данных, их валидации, оценке качества и правдоподобности результата, знаний математики и программирования (какого-никакого), умения визуализировать результат. Обладают ли этими знаниями менеджеры, которые рисуют в табло дашбордики? Да за редким исключением. Поэтому и веры нет в отображаемые результаты и серьезную проверку показателей они зачастую не выдерживают.
Приходилось несколько лет работать с Oracle DBA рука об руку (telecom, realtime). Видел все их мучения, чтобы вроде простые вещи положить в структуру SQL. В конечном итоге они стали делать для сервисных (незвонковых) сложных запросов микс между оракловыми процедурами и доп. обработкой скриптовыми языками — разработчики просто устали прожигать жизнь, играя по чужим правилам.
В целом я говорю о комбинации R + Clickhouse. Никто SQL не отбрасывает, но его роль достаточно сильно снижается. Большая хранилка, быстрая считалка простых агрегатов. Все сложное — снаружи. Дешевле и быстрее.
Смогу ли я переубедить Вас? Нет, нет и еще раз нет. Но такой цели и нет. Наличие на руках множества выполненных проектов, когда DBA/BI/big data "сливались" еще на этапе формулировки задачи дают основание утверждать о жизнеспособности этого подхода.
R vs Python в продуктивном контуре