Difference between system calls and library functions
Conceptually, a library function is part of your process.
At run-time, your executable code and the code of any libraries (such as libc.so) it depends on, get linked into a single process. So, when you call a function in such a library, it executes as part of your process, with the same resources and privileges. It's the same idea as calling a function you wrote yourself (with possible exceptions like PLT and/or trampoline functions, which you can look up if you care).
Conceptually, a system call is a special interface used to make a call from your code (which is generally unprivileged) to the kernel (which has the right to escalate privileges as necessary).
For example, see the Linux man brk.
When a C program calls malloc to allocate memory, it is calling a library function in glibc.
If there is already enough space for the allocation inside the process, it can do any necessary heap management and return the memory to the caller.
If not, glibc needs to request more memory from the kernel: it (probably) calls the brk glibc function, which in turn calls the brk syscall. Only once control has passed to the kernel, via the syscall, can the global virtual memory state be modified to reserve more memory, and map it into your process' address space.
Adding to Useless' answer:
Library functions are faster than system calls, and usually do not contain permission/security considerations, as they are running with the process' privileges and it's memory.
Syscalls on the other hand, since they run in the kernel, have access to everything in the system, and so they need to control what the calling process can do when it's calling them (verify that it has the permissions to open a file, for example), in addition, since syscalls are in the kernel, calling them requires a context switch in the CPU, which is a very heavy process relative to just calling a library call.
Syscalls usually reflect as system CPU usage in monitoring programs.