Как Вы обрабатываете маленькие наборы данных?
Что насчет подхода ниже?
Соедините оба фрейма данных перекрестно, добавьте столбец с функцией array_intersect , а затем отфильтруйте ваш объединенный набор данных, имеющий размер пересеченного результирующего столбца> 0. [113 ]
Например:
df1 = spark.read # ... Read your first source
df2 = spark.read # ... Read your other source
from pyspark.sql import functions as fn
joined = df1.crossJoin(df2). \
withColumn("common_join_keys", fn.array_intersect(fn.col("joinkey1"), fn.col("joinkey2")))
result = joined.filter(fn.size(fn.col("common_join_keys")) > 0) # your condition
result.show(truncate=False)
8 ответов
Если это маленькие подобные конфигурации данные, я использую некоторый простой и распространенный формат. ini, json и yaml обычно в порядке. Java и вентиляторы.NET также как XML. короче говоря, используйте что-то, что можно легко считать в объект в оперативной памяти и забыть об этом.
Поместите его в базу данных. Если это нечасто изменяется, кэшируйте его на своем среднем уровне.
Пример, который приходит на ум сразу, - то, что является соответствующим для хранения как перечисление и что является соответствующим для хранения в таблице базы данных "поиска".
Я склонен "разграничивать" с правилом, что, если это приведет к столбцу в базе данных, содержащей "магическое число", которое отображается на перечислимую величину, затем перечисление должно действительно существовать как справочная таблица. Если это не связано с данными, хранившими в базе данных (например, данные Конфигурации приложения, а не пользователь генерировал данные), то это - перечисление полностью.
У нас есть стандартный формат файла конфигурации (key:value) и класс для обработки его. Мы просто используем это на всех проектах. Главным образом мы просто устанавливаем персистентные свойства для наших приложений (разработка мобильного телефона), таким образом, это - соответствующая вещь сделать. YMMV
Конечно, это зависит от пользователя программного инструмента, который Вы разработали для потребления набора данных, независимо от размера?
Могло бы просто случиться так, что они знают Excel, таким образом, Ваш инструмент должен был бы проанализировать .csv файл, который они создают.
Если это записано для разработчиков, то, кто заботится о том, что Вы используете. Я не поклонник создания помех базам данных с незначительными или текущими данными как бы то ни было.
В случаях, где программа получает доступ к базе данных, я сохраню все там: легче для резервного копирования и перемещающихся данных.
Для небольших программ без доступа к базе данных я храню свои данные в настройках .NET, которые хранятся в XML-файле - конечно, это - функция c#, таким образом, это не могло бы относиться к Вам.
Так или иначе я удостоверяюсь, что хранил все данные в одном месте. Обычно база данных.
Я добавил бы его к базе данных в основной таблице:
- Резервное копирование и восстановление (Вы действительно хотите восстановить этот текстовый файл, правильно?)
- Для данного случая запрашивая (так как можно сделать это, будет инструмент SQL и соединять его с другими данными базы данных),
- Если столбец базы данных пуст, требования хранилища для него должны быть минимальными (ничто, если это - столбец NULL в конце таблицы в Oracle),
- Будет легче, если Вы захотите иметь несколько серверов приложений, поскольку Вы не должны будете сохранять несколько копий некоторого дополнительного файла конфигурации вокруг
- Помещение его в небольшую дочернюю таблицу только усложняет дизайн, не принося реальной пользы
Можно уже идти в ту же самую строку в базе данных как часть обработки так или иначе, таким образом, производительность вряд ли будет проблемой. Если Вы не, Вы могли бы кэшировать его в памяти.
Вы рассмотрели sqlite? Это основано на файле, который обращается к Вашему чувству, что "просто файл мог бы сделать" (нулевая конфигурация), но это - совершенно хорошая база данных и масштабы замечательно хорошо. Это поддерживает много API и существуют многочисленные фронтэнды для администрирования его.