فلینک ۲.۳ فایلسیستم S3 بومی و بدون هدوپ آورد
خلاصهٔ کاملتر
فلینک برای بخش زیادی از کارش به فایلسیستم زیرین تکیه میکنه: خوندن و نوشتن دادهٔ اپلیکیشن، متریالایز کردن سینکهای استریمی و ذخیرهٔ چکپوینت و سیوپوینت برای ریکاوری. به گفتهٔ نویسندهها (گابور شوموگی و سامرات دِب)، سالها پشتیبانی از S3 تو فلینک یعنی انتخاب بین دو پلاگین مبتنی بر هدوپ که هرکدوم مصالحهٔ خودشون رو داشتن. با فلینک ۲.۳ یه گزینهٔ بهتر اومده: flink-s3-fs-native، یه فایلسیستم S3 که از پایه و بدون هدوپ مخصوص فلینک نوشته شده.
مشکل قدیمی این بود: پلاگین Hadoop دور کلاینت S3A پیچیده میشد و RecoverableWriter داشت، پس سینکهای exactly-once کار میکردن — ولی کل درخت وابستگی hadoop-common و AWS SDK v1 رو هم با خودش میآورد. پلاگین Presto مسیر خوندن سریعتری داشت و برای چکپوینت توصیه میشد، ولی RecoverableWriter نداشت، یعنی سینک فایلی exactly-once باهاش کار نمیکرد. خلاصه یا سینک دقیق داشتی یا مسیر خوندن سبک، نه هر دو.
پلاگین بومی این معامله رو کلاً حذف میکنه. هیچ hadoop-common و SDK نسخهیکی درکار نیست، پس اون بار اضافه — Jackson، Guava، protobuf، Jetty و استک Kerberos/Zookeeper — و سیل CVEهای بیربط به S3 هم میره کنار. جارِ شِیدشدهٔ بومی حدود ۱۳ مگابایته؛ کمتر از نصف پلاگین هدوپ (۳۰ مگ) و هفت برابر سبکتر از Presto (۹۳ مگ). یه نکتهٔ انطباقی هم هست: AWS SDK for Java 1.x از پایان ۲۰۲۵ به end-of-support رسیده، یعنی پایهٔ هر دو پلاگین قدیمی عملاً بازنشسته شده.
مسیر I/O بومی async-first ـه: خوندن و نوشتن از S3TransferManager در SDK v2 استفاده میکنه که پشتش کانکشنهای multiplex شدهٔ Netty NIO هست و گلوگاه thread-per-request رو نداره. بازیابی حجیم state هم بهصورت انتقالهای همزمان دستهای انجام میشه — همون کاری که تا الان آدمها با ابزار بیرونی مثل s5cmd میکردن. نوشتن exactly-once هم با NativeS3RecoverableWriter و multipart upload پیاده شده و آپلود نیمهکاره بعد از خطا قابل ادامهست.
اعداد بنچمارک روی Amazon EKS با ۲۰ گیگ state روی RocksDB و چکپوینت کامل هر ۶۰ ثانیه گرفته شدن. میانگین throughput از حدود ۹۲ به ۲۰۰ مگابایت بر ثانیه رسیده و میانگین زمان چکپوینت از ۹۰.۱ ثانیه به ۴۸.۸ ثانیه (۱.۸۵ برابر سریعتر). p99 هم از ۱۶۵ به ۷۷ ثانیه اومده. تو stateهای کوچیک (۰ تا ۲ گیگ) شتاب به ۴.۵ برابر هم میرسه و حتی تو stateهای بزرگتر بالای ۲ برابر میمونه.
مهاجرت هیچ تغییر کدی نمیخواد و یه عملیات سطح دیپلویه: پلاگین قدیمی رو از پوشهٔ plugins/ بردار، جارِ بومی رو بذار، کانفیگ رو مرور کن و کلاستر رو ریاستارت کن. کلیدهای کانفیگ هم تمیزتر شدن و همه زیر یه فضای نام s3.* جمع شدن:
# Before (Hadoop plugin)
fs.s3a.access.key: ...
fs.s3a.connection.maximum: 100
# After (Native plugin)
s3.access-key: ...
s3.connection.maximum: 100چکپوینتها و سیوپوینتهای قبلی روی S3 کاملاً خونده میشن و فایلسیستم بومی با دادهٔ نوشتهشده توسط هر دو پلاگین قدیمی سازگاره — دوطرفه. حتی میتونی هر دو جار رو کنار هم نگه داری؛ یه priority قابل تنظیم انتخاب میکنه کدوم برنده بشه، پس برگشت به عقب فقط یه فلیپ کردن اولویته.
تو فلینک ۲.۳ این پلاگین آزمایشی و opt-in ـه؛ یعنی feature-complete و تو مقیاس تولیدی چند شرکت بزرگ در حال اجراست، ولی جامعه هنوز داره بازخورد جمع میکنه. دو پلاگین قدیمی عملاً وارد فاز نگهداری شدن (فقط رفع باگ و مسائل امنیتی). برای ۲.۴ هم کانفیگ per-bucket، پشتیبانی از کلاینت AWS CRT، متریکهای عملیات S3 و خوندن/نوشتن جریانی روی نقشهست.
نکات کلیدی:
- flink-s3-fs-native تو فلینک ۲.۳ اومده: بدون هدوپ، روی AWS SDK v2، آزمایشی و opt-in.
- هم چکپوینت سریع و هم سینک exactly-once رو یکجا میده؛ دیگه لازم نیست بین Hadoop و Presto انتخاب کنی.
- چکپوینت بهطور میانگین ۱.۸۵ برابر سریعتر (۴۸.۸ در برابر ۹۰.۱ ثانیه) و تو stateهای کوچیک تا ۴.۵ برابر.
- جار حدود ۱۳ مگابایته در برابر ۳۰ و ۹۳ مگابایت، و درخت CVEهای هدوپ حذف شده.
- مهاجرت بدون تغییر کد: تعویض جار و کلیدهای تمیز s3.*؛ دادههای قبلی کاملاً سازگارن.
