Тоже на данном этапе пользуюсь такой же почти связкой — LaTeX (TexStudio) + BibTeX (JabRef) + Git (bitbucket.org). bitbucket.org позволяет создавать приватные репозитории видные только вам, вот там и храню.
Спасибо за статью. То есть получается что Splunk передает данные Python-о в виде стандартных потоков данных (stdin, stdout) по типу Hadoop Streaming или как?
Если нужно вытащить данные из базы в агрегированном виде через ODBC и использовать Jupyter + Python в качестве основы для дальнейшего отображения в виде графиокв, то SQL это "самое то" на первых этапах анализа для тех кто уже знаком с SQL.
У меня у самого переиодически глючит 3D-ускорении в VirtualBox (к примеру не хочет раборать нормально Chrome, в то время как Unity вообще не запускается ни при каких условиях). VMware Player же идет как бесплатное приложение без 30 дневного граничения и им вполне можно пользоваться (правда я там еще не пробовал 3D ускорении само). Но если что, то при случае можно сконвертировать VM машину из VirtualBox-а в VMware и обратно.
Спасибо большое за отличное приложение. Пользуюсь уже неделю, очень удобно. Особенно нравится функциональность по скачиванию (кэшированию) видео — очень удобно, чтобы скачать нужные видео не нужно много бродить, достаточно нажать одну кнопку. Немного огорчает отсутствие хотя бы «тестирования» в самом приложении.
Спасибо вам громное за отличную статьи. И отдельно спасибо за статистику по нагрузке на реальных данных. Хотелось бы еще обратить внимание на то что у Exasol отличный результаты в «синтетических бенчмарках» аля TPC-H, в чем можно убедиться тут.
Так же хотелось бы отметить что «ругать» HDFS и превозносить Spark не стоит, так как судя по заявлениям создателей Spark, одно из решающих решений была поддержка как раз таки HDFS в самых первых версиях, что позволил интегрироваться в экосистему Hadoop достаточно безболезненно.
Так же нужно не забывать что Spark активно продвигается, так же самым O'Reilly, а это не маловажный фактор в популярности продукта (помимо технических характеристик).
Извините, но у вас не совсем верное «определение» big data. Более-менее адекватный сбор разных определений big data можно найти в статье "Undefined By Data: A Survey of Big Data Definitions". В то время как на ваше утверждение «Например, если мы используем RDBMS, то это уже 100% не Big Data» есть опровержение в публикации "MapReduce and parallel DBMSs: friends or foes?". На самом деле в большинстве случаев такое понятие как big data используется больше в маркетинговых целях.
Если так давно делали, то тогда имеет смысл интегрировать с Sympy (если есть время). Он в последнее время (несколько лет развивался в рамках Google Summer of Code) очень сильно шагнул вперед и много что умеет «из коробки».К примеру Sympy умеет очень неплохо отображать свои формулы в LaTex, MathML или MathJAX. Тут есть самописный небольшое пример, как из набора формул получить сохраненных в файле получить HTML или TEX с более-менее нормальным отображением — github.com/vdmitriyev/pycsvtoequation.
Спасибо большое за ваш пост. Выглядит очень интересно, но пока мне не очень понятно как именно все работает. Я посмотрел видео которые у вас в описании, после него стало больше понятно. Хотел попробовать демо о котором вы говорите, но оно не запускается (я про это — mc.homedevice.pro). К сожалению у меня нет рабочей среды Perl-а чтобы быстро развернуть ваш скрит и посмотреть как он работает. Но даже если я его разверну, я все равно не буду уверен что он сможет работать с Sympy и Python как это показано у вас в вашей презентации (что на видео). Если у вас есть какие-то другие записанные видео, или публикации с более детальным описанием работы, было бы просто здорово их посмотреть (это не открывается — zornica.tk/ignat99.pdf).
Спасибо за интерес. Частично можно увидеть как выглядят работы на буквально недавно поднятом сайте тут — pvl.iitu.kz. Там пока только краткое описание, плюс скриншоты, но думаю что хотя бы основное понимание как все выглядит будет.
Спасибо за статью. Спасибо что поделились. На первый взгляд у вас реализация просто замечательная и как раз в духе своего времени (Delphi + OpenGL). Мы тоже с небольшой группой студентов и преподавателем физики начали подобный проект под названием Виртуальные Физические Лаборатории где-то более 3 лет назад, потом правда проект заморозился на некоторое время. В качестве основных технологий тогда были взяты C# + XNA Framework (который к сожалению уже не поддерживается, но есть порт из XNA в HTML5, по крайней мере 3D моделей). Критерии выбора XNA были связаны прежде всего с простотой использования и наличие опыта разработки на .NET у студентов-разработчиков. Основная цель проекта была и остается простой — перешагнуть дефицит с наличием физического оборудования во время обучения физики на не профильных технических специальностях (в нашем конкретном случае это были и остаются в основном IT специалисты). Всего было реализовано 6 разных физических лабораторий 5 из них 3D формата. Теперь вот активно думаем направлениями для дальнейшего развитие.
Полностю согласен. Буквально на днях прочитал интересную статью, где в принципе простая агрегация данных + визуализация увеличила эффективность. Если интересно, вот статья — Utilizing machine data from robots to provide data driven insights and decisions target.github.io/analytics/robotics-analytics
Спасибо Александр за ваши посты, и Сергей за ваши интересные комментарии,
Хотелось бы высказать свое мнение. В целом вы весьма правы — тут можно действительно уйти в глубокую полемику. Но тем не менее хотелось бы выделить отдельно задачи, которые решаются в рамках построения того же Big Data Pipeline, которые обычно решаются отдельными людьми типа Data engineer. Как бы при этом давая большую свободу людям, которые занимаются непосредственно анализом данных и построением конечной модели (предсказание, рекомендации и т.д., суть не в этом), проще говоря Data Scientist. НО, думаю очень часто получается ситуация когда Data Scientist «и швец, и жнец, и на дуде игрец».
Если я не ошибаюсь, то поддержка в Spark DataFrame появилась сравнительно недавно (то есть с версии 1.4 — databricks.com/blog/2015/08/12/from-pandas-to-apache-sparks-dataframe.html ). Так что я бы не записывал это в «плюс» в историческом контексте.
Так же хотелось бы отметить что «ругать» HDFS и превозносить Spark не стоит, так как судя по заявлениям создателей Spark, одно из решающих решений была поддержка как раз таки HDFS в самых первых версиях, что позволил интегрироваться в экосистему Hadoop достаточно безболезненно.
Так же нужно не забывать что Spark активно продвигается, так же самым O'Reilly, а это не маловажный фактор в популярности продукта (помимо технических характеристик).
К сожалению ваш pdf я не получил.
Хотелось бы высказать свое мнение. В целом вы весьма правы — тут можно действительно уйти в глубокую полемику. Но тем не менее хотелось бы выделить отдельно задачи, которые решаются в рамках построения того же Big Data Pipeline, которые обычно решаются отдельными людьми типа Data engineer. Как бы при этом давая большую свободу людям, которые занимаются непосредственно анализом данных и построением конечной модели (предсказание, рекомендации и т.д., суть не в этом), проще говоря Data Scientist. НО, думаю очень часто получается ситуация когда Data Scientist «и швец, и жнец, и на дуде игрец».