Time Clustering is enabled by default on Databricks Runtime 11.2 and Databricks SQL (version 2022.35 and above). All unpartitioned tables will automatically benefit from ingestion time clustering when new data is ingested. We recommend customers to not partition tables under 1TB in size on date/timestamp columns and let ingestion time clustering automatically take effect.
1. Без разницы когда была создана табличка? Даже если на Runtime 9? То есть при чтении с клиентов 11.2 (кластер или SQL) типа он начнет как-то накапливать информацию по timestamp полю? и быстрее получать данные? Как она вообще узнает по какому timestamp полю ей начать оптимизацию, если я ничего не указал?
2. Или есть что прописать, чтобы зафорсить использование? Вот тут написано например:
> Databricks recommends running OPTIMIZE with ZORDER BY using a column that matches the ingestion order.
3. Если я сделаю ZORDER BY не только по ней, но и по другой колонке это сломает этот механизм?
В интернете как-то пусто на эту тему....
Я конечно попробую наверно, но там 1ТБ табличка, не хотелось бы сравнивать текущее кастомное партиционирование с чем-то вообще не понятным )
Время ingestion можно брать к примеру из delta log. Да, даже если создана в предыдущем рантайме будет работать. Иногда новые фичи требуют table protocol update, но не в этом случае. Детальнее : https://docs.databricks.com/en/delta/feature-compatibility.html Форсить ничего не нужно, итак будет работать. Zorder ничего не ломает. Всегда лучше применять zorder к колонкам которая содержит много разных значений. Каждая дополнительная колонка описанная в zorder будет несколько замедлять запросы содержащие только одну из них в фильтрах, но ускорять те, где они упоминаются вместе. Поэтому надо думать когда zorder делать по одной, а когда брать несколько. Не рекомендуется использовать больше четырех.
Ну и статистика по ней должна собираться ;-)
Обсуждают сегодня