This message was deleted.
# general
s
This message was deleted.
s
I haven't, but just thinking through this. If you are just pruning older data should be a matter of setting up retention rules, and running a kill task. You have the data split into time intervals (as folders) in Deep Storage and you have the metadata rows for the sys.segments table. I think that's all you need to backup: copy the segment files into a different bucket/folder and backup the metadata rows. In order to be able to restore them later, add those rows back into the sys.segments table and put the segment files back into their respective Deep Storage location... it would be nice to automate this.
a
Interesting @Sergio Ferragut let me look at this further, I could experiment with some of the older segments. Thanks!!
g
you can certainly back up the files on deep storage; that's the easiest way
check out the
loadSpec
of the
payload
column of each segment in your metadata store (that would be the
druid_segments
table in mysql/postgersql)
it has all the exact paths in deep storage to look for
a
Thanks @Gian Merlino I will do that. Looks like I need to take all that data and load it into a relational DB like Hive. I would imagine that I have to go through a Druid instance to do that...
g
you can use the dump-segment tool: https://druid.apache.org/docs/latest/operations/dump-segment.html however as that page points out:
> Note that the dump is not necessarily a full-fidelity translation of the segment. In particular, not all metadata is included, and complex metric values may not be complete.
so watch out for issues with complex fields, if you use any of those (like datasketches)
btw I'm wondering what the purpose of such pruning is? is it mainly a cost thing? we're planning some new features around being able to query data from deep storage without preloading it on Historicals; designed for use with older or less user data
if that sounds interesting i'd like to understand more about your needs here, as that will help us build the feature in a way that is useful to everyone
a
Hey @Gian Merlino thanks for the pointer to the tool, I don't have direct access to the file storage but I'll ask our team about this. We are doing this pruning to reduce the file system footprint of our Druid cluster, and this dataset was identified as one of the larger ones.
Hey @Gian Merlino I think I may go down the route of doing scan queries: https://druid.apache.org/docs/latest/querying/scan-query.html. While this means that I'll need to do more than 100,000 of these, I can rate limit them and keep track of offsets so I can restart the process. This can be fairly easily scripted and run off-hours, without impacting our application server that sits on top of Druid.