#javascript #python #r #python-3.x #julia
Вопрос:
Есть ли какой-либо эквивалентный способ подключения данных, подобных тому, что мы делаем в программном обеспечении BI (например, Power Bi или Tableau), а затем запрашивать у них?
Для уточнения:
мы используем явное объединение, например, в языках программирования new_table = inner_join(a,b, by = c) , чтобы новая таблица вычислялась и была окончательной, но в инструментах BI мы вводим модель данных, вы можете видеть модель на картинке, она сейчас не вычисляется, затем мы выполняем запрос нескольких таблиц без какого-либо явного объединения. Программное обеспечение само решает, как вовремя извлекать данные из модели данных.
HR_tables %>% group_by(DEPARTMENTS$department_name) %>% (sum(EMPLOYEES$salary))
Комментарии:
1. Я проголосовал за то, чтобы закрыть этот вопрос в его нынешнем виде, поскольку он слишком широкий, а также неясный. Похоже, вы хотите, возможно, объединить две или три таблицы, а затем выполнить простую операцию группирования и суммирования, что, безусловно, возможно в python, r, julia или большинстве других языков, которые имеют какой-то объект, подобный фрейму данных.
2. Это кажется довольно широким, но я не думаю, что это неясно. Все базы данных SQL поддерживают представления с использованием
create viewинструкции, и соответствующие языки могут подключаться к таким базам данных.3. Я никогда не видел такой возможности ни на одном из этих языков. пусть она будет открыта.
4. Я голосую за повторное открытие этого вопроса. Автор должен отредактировать его и явно указать, что он спрашивает о представлениях для фреймов данных. Обратите внимание, что Julia имеет самую широкую поддержку нематериализованных данных, возможно, почти из всех языков программирования. У вас есть
@view, естьSparseArraysBandedMatricesи так далее. Следовательно, разговор о нематериализованных фреймах данных имеет смысл. Кстати,DataFrames.jlвы можете решить не создавать копию столбца с помощью[!, :colname]селектора.5. Я не знаком с BI. Это звучит как ленивая таблица данных, но где на самом деле хранятся данные? В удаленной базе данных? В файлах на вашем диске? В не ленивых таблицах данных (в Julia и Python это был бы фрейм данных)?
Ответ №1:
Идея использования оптимизатора запросов с нематериализованными представлениями в реляционной системе, такой как хранилище данных, обычно не имеет прямого следствия ни на одном из этих языков. Вы действительно видите такого рода оптимизатор в действии в таких системах, как Mahout Samsara или Tensorflow.
Другой аналог традиционного оптимизатора реляционных запросов можно найти в Julia в том смысле, что оптимизатор может преобразовывать широковещательные выражения. Во многих случаях ненужное выделение данных в таком выражении может быть сведено к нулю путем преобразования того, что кажется конвейером, в прогрессивную мутацию на месте.
Вы также видите некоторые аналогичные отложенные вычисления в системе LazyArrays в Julia, но, опять же, это не ориентировано на оптимизацию реляционных соединений, которую вы описали ранее.
Частью недостатка этих систем в Julia и в Spark является разница в фокусе. Нематериализованные представления и сложная оптимизация соединений проявляются в системах, где преобладают нормализованные формы (например, реляционные системы). Нормализованные формы очень хороши, когда вы хотите всегда видеть последние обновления, скажем, адрес человека. В меньшей степени объединения также становятся важными, когда у вас есть центральная таблица фактов, которая ссылается на измерения, как в архитектуре snowflake (опять же, ссылка на актуальную информацию, такую как адреса и номера телефонов, считается преимуществом.
Однако во многих более современных системах гораздо больше внимания уделяется дизайну потоков данных и сохранению данных в том виде, в каком они были изначально представлены. Большинство соединений состоят из очень больших наборов данных или даже потоков данных в реальном времени с относительно небольшими таблицами измерений, или они представляют собой очень большие наборы данных с очень большими наборами данных. Соединения обычно сводятся к минимуму в этих системах из-за акцента на денормализованных данных, что является частичным следствием географически распределенных систем и частично следствием сосредоточения внимания на сохранении данных в том виде, в каком они изначально появились, а не на их полном обновлении. Оптимизация тривиальных соединений, которые появляются в этих системах, довольно проста, и для этого вам обычно не нужен оптимизатор, основанный на затратах.
В таком контексте предположения, лежащие в основе вашего вопроса, действительно неприменимы.