In SQL server the partitioning have cycle like Table -> on Partition Schema -> on File Group (f1,f2,f3,f4,....)
For example in Oracle :
A filegroup in SQL Server is similar to tablespaces in Oracle, it is a logical storage for table and index data that can contain one or multiple OS files.
but how about MariaDB does it have File Group ?
Not as such. What are you trying to achieve? Keep in mind that some things like that exist because disks used to be smaller than databases. Today, there is rarely an issue. Furthermore RAID controllers, SANs, etc, eliminate the need (or even the desirability) of manually deciding what file goes where. OS's have ways to concatenate multiple volumes, even on the fly. Etc.
MyISAM has the ability to say where the data goes and where the index file goes. But MyISAM is all but dead. Even there, it was folly to put the data on one drive and the indexes on another. In performing a query, first the index is accessed, then the data. That is little, if any performance was gained. Simple RAID striping is likely to do better.
InnoDB has a way to spell out ibdata1, ibdata2, etc. That dates back to the days when the OS could not make a file bigger than 2GB or 4GB. It is essentially never used today.
InnoDB tables can either be all in ibdata1 or scattered among individual .ibd files. But I don't really think this is what you are talking about. With this "file per table", tiny tables are inefficiently stored. MySQL 8.0 will improve on that slightly by letting you put multiple tables in a given "tablespace", akin to .ibd file.
An InnoDB tablespace contains all the data and indexes for a given table or set of tables. Partitioned tables, when file_per_table, had each partition live in a different .ibd file. This may be changing with 8.0.
All of these are hardly worth noting. I would guess that only 1% of systems need to even think about it. Simply let MySQL/MariaDB do what it wants; it's good enough.
A related thing... In the '80s and '90s some vendors had "raw device" access because they thought they could do better than going through the OS. Again, OS's have improved, RAID controllers are sophisticated, and SANs exist. So raw is no longer important. (I don't think MySQL ever had it.) It's bound to have be a big development and maintenance problem for the vendor.
How many DBAs have put tmpdir in a separate partition, only to find that things are crashing because it was not big enough. Ditto for RAM-disk.