"Live Bytes" means "memory which has been allocated, but not yet deallocated." It's important because it's the most easily graspable measure of "how much memory your app is using."
"Overall Bytes" means "all memory which has ever been allocated including memory that has been deallocated." This is less useful, but gives you some idea of "heap churn." Churn leads to fragmentation, and heap fragmentation can be a problem (albeit a pretty obscure one these days.)
"Real Memory" is an attempt to distinguish how much physical RAM is in use (as opposed to how many bytes of address space are valid). This is different from "Live Bytes" because "Live Bytes" could include ranges of memory that correspond to memory-mapped files (or shared memory, or window backing stores, or whatever) that are not currently paged into physical RAM. Even if you don't use memory-mapped files or other exotic VM allocation methods, the system frameworks do, and you use them, so this distinction will always have some importance to every process.
Those numbers cannot be compared really. Even pages belonging to a (shared) memory mapped file (e.g. a library) will count as resident pages for the task. But they will be ignored by the Leak Tester.
The important thing to note is that there is a conceptual difference between memory available to the process (in whatever way: readonly, read/write, executable or not) and memory allocated by you, within your program. Not all available memory is connected to an actual allocation you did (e.g. a shared library) and not all memory you allocate is necessarily resident in memory (e.g. a big malloc will not reserve physical memory for you right away, but only as soon as it is used).