Using VARCHAR keys or INT
There's not a clear-cut answer to your question without more information. However, your choice should be basically based on:


Ease of data loading: if you leave the keys as they are, you'll save a lot of trouble creating the equivalent INTEGER ids (you would need an equivalence table between every pair; and use this translation table when you import the data using an ETL process). If all keys are 22 chars in length, you're probably better of using char(22) instead of varchar(22) 1. (Against AUTO_INCREMENT)
Size: if the size of your dataset is very large, making the translation will save you a significant amount of space in both table rows and indexes. If there are lots of indexes with several varchar(22) and extra columns, you can hit the limit on index size 2. The smaller the indexes (and tables) the more performant a system is to query. (Pro AUTO_INCREMENT)
New keys: if you want to add more rows to your dataset, it will be easier to have an AUTO_INCREMENT key than to have a mechanism to generate varchar(22) unique ids. (Pro AUTO_INCREMENT)


Depending on your particular needs, balance the pros and cons, and choose.

Given the nature of the Yelp Dataset, I'd probably go for the INT, just for size efficiency. You'll need to translate business_id, review_id, user_id and photo_id. Provided you'll have to translate from JSON to CSV already, and convert arrays to normalized subtables, before being able to upload the different collections, doing one extra step shouldn't be that difficult.



Notes:



  If your content is a fixed size, you'll get better performance with CHAR.


from: What's the difference between VARCHAR and CHAR?

  maximum index key length is 1536 bytes when the page size is 8KB, and 768 bytes when the page size is 4KB.


from 14.8.1.7 Limits on InnoDB Tables




Side note: Consider using PostgreSQL and MADLib. I think this combination might give you some useful tools for this kind of challenge.