+1 for this feature. 
Looks good to see the support for bitmaps to enable Flink handling computations 
in extremely high-dimensional scenarios. After reviewing the entire FLIP, I 
have one question:
Regarding the Bitmap#toBytes interface, I noticed that it will output bytes in 
RoaringBitmap format default. Does this imply a strong binding to the internal 
implementation of RoaringBitmap? For the writers on the sink table, they need 
to be aware that the bytes are in RoaringBitmap format, right?



--

    Best!
    Xuyang



在 2025-11-24 18:09:25,"Lincoln Lee" <[email protected]> 写道:
>+1 for this feature! Expanding the bitmap type will help users unlock more
>computation scenarios and integrate more easily with external systems.
>
>
>Best,
>Lincoln Lee
>
>
>dylanhz <[email protected]> 于2025年11月21日周五 11:07写道:
>
>> Hi everyone,
>>
>>
>> I would like to start a discussion about FLIP-556 Introduce BITMAP Data
>> Type[1].
>>
>>
>> Flink currently has no native, compressed data type for large integer
>> sets, forcing users to rely on external libraries like RoaringBitmap via
>> UDFs.
>> This limits performance, maintainability, and integration with Flink’s
>> type system and SQL engine.
>> We propose adding a built‑in BITMAP type based on RoaringBitmap to provide
>> compact storage, exact deduplication, and efficient set operations (AND,
>> OR, XOR) directly within Flink.
>>
>>
>> I have had some initial discussions with @Lincoln Lee and @Jark Wu
>> regarding this FLIP.
>> Looking forward to your feedback and suggestions.
>>
>>
>> [1]
>> https://docs.google.com/document/d/1YNgIt93iFboogHMoKbDD4LjP5UrfqtF65hitGKRtKMs/edit?usp=sharing
>>
>>
>>
>> --
>>
>> Best regards,
>> dylanhz

Reply via email to