и так далее

Понял, буду знать теперь))

Спасибо

Просто читал что и на Р и на питоне большинство библиотек мл овских на С написаны, думал для этого

Они-то уже написаны, для использования кресты не нужны

Лол

Забрал в копилочку

Бигдата - вещь в себе, особенно в корпоративных реализациях. У них своя жизнь. Сегодня тащили из hive простой запросец select min(x) from table. И строк то немного, сотни миллионов. Процессилось минуты 4. Таковы уж правила у настоящей бигдаты. Местные аналитики в шутку ее «ленточкой» называют

Кто-то сталкивался с пакетами antaresEditObject ?

К теме о биг дата. Товарищи, как аналитику данных преодолеть барьер и перейти на большие данные? Интересует больше дата инжиниринг. Есть задача организовать дата лейк, витрину, делать по данным базовые операции. Пока без машинного обучения. Как бы так чтобы не больно 🙈

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

Дата инженер больше программист, нежели аналитик, на мой дилетантский взгляд. Считается, что важный язык для ди - Scala (потому что Spark и Databricks). В принципе не важно, кмк, на чём писать (scala/python/r). Можно на любом. Но вот штуки для оркестрации и шедулирвоания (Airflow, Prefect, Dagster) написаны на питоне и таски для них надо писать на питоне.

Важен SQL. Это язык трансформации данных. Без этого никуда.

К вашей теме возвращаясь. Если данные уже лежат в БД и над ними просто надо поколдовать (ELT, а не ETL проесс), присмотритесь к инструменту DBT. Я его начал у нас использовать, уже 4 больших отчёта в PBI завязаны на витрины, которые созданы этим инструментом, все очень довольны. Если просто - это создание пайплайнов трансформации данных. Причём всё сохранёнными sql скриптами. В комплекте логирование, документирование и куча всяких очень полезных вещей. Очень рекомендую))

Спасибо большое )

Сугубо личное мнение, но вы не с той стороны запрягаете. Биг дата - довольно расплывчатое понятие, никто толком не знает, с какого момента данные становятся биг. Вопрос в том, какие данные у вас есть сейчас и какие задачи вам надо решать... И почему их не получается решить с имеющимися инструментами

Чтобы data lake строить, надо иметь опыт работы гораздо шире, чем аналитик, да и жизненного опыта тоже вагон потребуется. Руководитель + архитектор + системщик + разработчик + переговорщик + консалтер.
Все со стратегии начинается и красной нитью должен идти data governance. ETL --сугубо техническая задача, делать можно на чем угодно. open-source/вендорские решения...

@iMissile А доводилось ли сравнивать BQ и Clickhouse?

Мне интересно, что лучше будет для Shiny панелей, работающих на SQL запросах напрямую.

Нет.
1. Нигде bg в проде не встречали. Все данные, как правило, хранят во внутреннем контуре
2. Скорость сильно зависит от логики запросов.
3. Есть сетевые задержки, в ряде случаев они могут составлять сотни процентов от времени самого расчета. CH на 10 Гбит в том же датацентре где и шайни всяко быстрее. Счёт ведь на миллисекунды идёт при быстром обновлении

Вопрос слишком абстрактен

Можно тесты оттуда погонять и сверить

Из общих соображений по этим тестам полагаю, что bq значительно проиграет. Как многие другие

Если почитать https://cloud.google.com/blog/products/data-analytics/new-blog-series-bigquery-explained-overview, то понятно, что все будет зависеть от типа стораджа, на котором данные хранятся в облаке. Если внизу хадуп, то это сразу финиш, производительность против in-memory в тысячи раз.

Наворочено очень много, включая аутентификацию каждого запроса. Кроме сети еще и этот оверхед.

С аналогами дремеля можно и локально покопаться... когда-то играли с https://drill.apache.org/, но смысла большого не нашли. Ни рыба, ни мясо.

Наверное, самое полезное — это сидеть целиком в облаке и делать аналитику там же. Тогда будет максимальная выгода.

Кстати, о каких объемах данных идет речь? Почему для приложения не вытащить все на локальный сервер?

Спасибо за такой развёрнутый ответ! У меня вопрос исключительно поверхностный.

Общий объём данных около 20 - 30ТБ. Просто мне задали вопрос, на какой системе я хотел бы работать в дальнейшем. Сейчас BQ.

С CH пока не доводилось даже познакомиться. Мне предстоит работа по построению приложений на Shiny. Сейчас я всё реализую силами Google Cloud.