Вы кстати тоже ходите в него через JDBC который внутри всё в tsv перегоняет?
Недавно у Clickhouse появился Arrow Flight SQL в качестве нового интерфейса, через spark-flight-connector тратится на порядок меньше CPU на десериализацию vs старый JDBC.
Только это все хорошо, а на практике все равно spark.read.parquet - и вперёд... Или, что ещё интереснее, df.write.mode("append").parquet(hive_table_location) из рандомного пайплайна :-).
Так имена таблиц остаются захардкоженными, можно пойти дальше, и во всей реализации бизнес-логики использовать pyspark.DataFrame как входные параметры, или дойти до подхода dagster с ассетами и iomanager'ами. Но в целом, контракт на уровне схемы каталога это тоже вариант, со своими плюсами.
Чтобы не зависеть от окружения, все что нужно - зашито внутри реализации провайдера. Ну и provisioner - костыль by design, здесь попытались сделать красиво, но к этому дизайну вопросы тоже есть.
Все верно, но дьявол в нюансах. Почему именно с полным надо сравниваться? Да и если не углубляться в настройку, то нет, установка у клика - один шаг. А на выходе по функциональности сразу имеется практически все что пиарят в статье. Если с python-duckdb сравниваться - то надо помнить про chdb.
По бенчам datalake режима - duckdb после прогрева ощутимо ускоряется, а в cold run ведёт кликхаус. При этом datalake режим у клика более честный, а в нативном режиме он всё-таки быстрее чем duckdb, если я правильно запомнил когда смотрел сегодня днём.
Очень много критичных неточностей, и многовато воды, возможно стоит переписать статью так, чтобы в большей степени отразить собственный опыт. Как происходило знакомство, на каких задачах clickhouse хорошо себя проявил, какие возможности больше всего впечатлили.
Не очень понял, это ведь тот же RLHF только в профиль? Почему не сравнивались с методами из RL? С хорошей теорией по идее можно и RLHF ускорить, но сравнение пока у них только с принципиально более проигрышными методами?
Когда дело касается криптографии необходимо консультироваться со специалистом. Описанный алгоритм имеет мало общего с RSA, а разложение случайного 512-битного числа на простые множители будет проходить меньше чем за секунду на одном ядре любого современного процессора при использовании тривиальных алгоритмов из "школьного" курса.
Hidden text
Возмущение в силе, чувствую я, дзен покинуть урлы этого поста ведут.
Это хорошо, когда процессы выстроены так, что без ревью код рандомного отдела не залезет в общий даталейк.
Вы кстати тоже ходите в него через JDBC который внутри всё в tsv перегоняет?
Недавно у Clickhouse появился Arrow Flight SQL в качестве нового интерфейса, через spark-flight-connector тратится на порядок меньше CPU на десериализацию vs старый JDBC.
Для истории стоит отметить, что разработка Servo была одной из причин появления Rust.
Возможно стоит смотреть ещё шире.
Только это все хорошо, а на практике все равно spark.read.parquet - и вперёд... Или, что ещё интереснее,
df.write.mode("append").parquet(hive_table_location)из рандомного пайплайна :-).Так имена таблиц остаются захардкоженными, можно пойти дальше, и во всей реализации бизнес-логики использовать pyspark.DataFrame как входные параметры, или дойти до подхода dagster с ассетами и iomanager'ами. Но в целом, контракт на уровне схемы каталога это тоже вариант, со своими плюсами.
"Сегодня мы узнали как вместо перевода крутой большой технической статьи получить вольный пересказ от ChatGPT."
Чтобы не зависеть от окружения, все что нужно - зашито внутри реализации провайдера. Ну и provisioner - костыль by design, здесь попытались сделать красиво, но к этому дизайну вопросы тоже есть.
Две статьи под копирку, отрицательной технической ценности, и с unfair использованием бренда clickhouse.
Все верно, но дьявол в нюансах. Почему именно с полным надо сравниваться? Да и если не углубляться в настройку, то нет, установка у клика - один шаг. А на выходе по функциональности сразу имеется практически все что пиарят в статье. Если с python-duckdb сравниваться - то надо помнить про chdb.
По бенчам datalake режима - duckdb после прогрева ощутимо ускоряется, а в cold run ведёт кликхаус. При этом datalake режим у клика более честный, а в нативном режиме он всё-таки быстрее чем duckdb, если я правильно запомнил когда смотрел сегодня днём.
"chatgpt, дай сравнительную таблицу" это не про то как принято сравнивать системы на хабре :-(
"Лёгкий", "сравним". И где? Оно же всяко по факту в 5 раз тяжелее clickhouse и в 50 медленнее?
Очень много критичных неточностей, и многовато воды, возможно стоит переписать статью так, чтобы в большей степени отразить собственный опыт. Как происходило знакомство, на каких задачах clickhouse хорошо себя проявил, какие возможности больше всего впечатлили.
Не очень понял, это ведь тот же RLHF только в профиль? Почему не сравнивались с методами из RL? С хорошей теорией по идее можно и RLHF ускорить, но сравнение пока у них только с принципиально более проигрышными методами?
Удачи в следующем проекте. Ну и выше уже замечали что не все шишки обязательно набивать самому.
"Самые популярные аббревиатуры значение которых часто путают"
Не, чот я сам тут загнался :-).
Когда дело касается криптографии необходимо консультироваться со специалистом. Описанный алгоритм имеет мало общего с RSA, а разложение случайного 512-битного числа на простые множители будет проходить меньше чем за секунду на одном ядре любого современного процессора при использовании тривиальных алгоритмов из "школьного" курса.