There’s a long history of reporting efforts within OpenMRS. One of the most successful & broadly useful solutions that got us through much of the journey through 1.x and 2.x was a reporting framework developed by @mseaton and the folks at PIH. Many orgs have looked for alternatives from this bespoke internal (OpenMRS module) approach to reporting directly from the normalized operational database because of performance issues (either slowing down the operation system and/or taking a long time to generate reports). Unfortunately, the majority of efforts to create flattened data for analytics/reporting needs has been done as siloed efforts (e.g., AMPATH, Mekom, PIH, Palladium, UCSF, etc.).
The OpenMRS community would benefit greatly from a shared approach to analytics; however, experience has shown that building analytics directly within the operational system (against the runtime database) has significant performance and scaling limitations. Also, given the number of freely available tools in this space (e.g., Apache projects), we should be leveraging existing powerful open-source solutions in this space instead of building our own.
@mseaton and I have been talking within the Analytics Engine Squad calls about a strategy for reporting within the OpenMRS community and came up with this proposal:
tl;dr - get two or more orgs aligned on a shared approach to CDC (change data capture) using debezium to generate some high value proof of concept tables (e.g., flat row-per-encounter & row-per-patient tables that are automatically kept up to date).
If you are going (or are forced to go) down the road of re-inventing the wheel inside OpenMRS and building OpenMRS-specific business intelligence tooling, I would suggest quick hacks that (1) can be thrown away once we have a more shared solution and (2) free up some of your dev cycles to help contribute to a shared solution. 
As @ssmusoke points out, you could probably get most of what you need from the reporting module for a near-term solution.