2大数据分析平台主流有以下三种
1.在开源产品上搭建大数据分析平台。这个过程比较烦琐，还要对细节了解得比较清楚，如果后期根据业务做自定义扩展，则需要修改源码，优点是前期能够迅速搭建一个可用的大数据分析平台。大数据分析平台主流的在开源产品上搭建的主要有Grafana，superset等。
3.自建大数据分析平台。现在很多中型以上的公司，都会配备自己的大数部门进行数据的存储、清洗、分析、展现等工作，也有足够的研发实力自建大据分析平台，这样做的优点是可以根据自己的业务定制开发，实现满足自身业务需求的平台，缺点当然就是要投入一定的研发资源，前期需要有一定的技术积素。
总结：不过你不管使用哪种方式都需要考虑这三点情况：
1.安全性，大数据分析平台应采取安全性高的访问认证机制，重视自身系统建设以及保证数据的安全性
2.可拓展性，大数据的分析和应用不是一蹴而就的，需要长期持久的工作，随若业务的变化对于大数据分析平台的功能和要求也会不断变化。因此，需要满足业务的不断变化。
3.灵活性，在平台的设计和实施中要考虑与其他应用系统的整合，能够实多种类型的接口，并可以灵活地接入其他系统中，拓展服务类型和服务能力。
这里我们拿自建的分析平台做“白老鼠” (￣_,￣ )
3.拓展式的报表分析
数据分析平台首先要完成的就是对指标的报表性展示，比较简单的方案无非是前端写页面，后端接口在数据库查询相应字段，直接吐出数据。可是，这种传统的方式太依赖于前端，如果增加一个指标，前后端修改的成本都比较高。因此，为了以后数据分析平台的可扩展性，可以通过前端配置json，并在API下一层添加了QueryAdapter来把Api的接口翻译成相应的Sql，然后通过Sql查询数据库的形式，来提高前端的扩展性和报表的灵活性，具体架构如下图所示：
报表架构的UI层主要以单图和看板两种形式展现，单图主要是对指标进行某种样式的展现，例如日活跃用户数的折线图、日活跃用户数的表格、多平台日活跃用户数对比图等，并可以对单图进行多个维度的査询操作，它主要提供了如下功能：
(1)选择维度。可以选择多个维度，向下钻取，向上上卷。
(2)选择时间。可以选择昨天、过去7天、过去30天、过去90天、过去180天、过去365天以及自定义天数。
(3)选择图表样式。能够支持折线图、横向柱状图、竖向柱状图、表格地图、饼图等常用的图表样式。看板能够将相互关联的单图集合在一起，兼顾全面性与单独性，既能够从多图表中发现关联，又可以对单个图表深入分析，方便每天查看相应业务的数方式太定据。看板可以供不同的业务人员实现不同的使用场景：
1.产品经理的看板可能是项目的核心指标。
2.市场人员的看板可能是监控各个渠道来源指标以及转化率情况。
3.销售人员的看板可能是潜在客户的活跃度
3.1对于支持自定义图表的单图而言，在前端配置的JSON格式中，需要明确以下几个字段：
(1) datasource。数据源，也就是单图要查询的数据库、数据表，它包含了数据的地址、端口、数据库格式，数据库、数据表等，是数据展现的基础。
(2) metrics。在页面展现的指标，包括指标的计算类型、指标的ID、指标名称、指标别名等。是分析人员想按照什么分组査看数据。
(3) dimensions。指标的维度，相当于SQL中的分组方式 group的作用，也就是分析人员想按照什么分组查看数据
(4) filter。 filter用来设置过滤器，为前端报表实现筛选査询条件，它要规定每个维度应该以何种规则过滤，是等于、不等于、大于、小于，还是包含，还要规定维度的査询字段和査询值，
(5) orders。输出结果应该以哪一个指标排序。通常按照使用时间字段进行降序排序。
总结：
除了以上几个重要字段，还可以设置time、 limit等字段扩展更多功能。其实，有SQL基础的人应该都能看得出来，前端单图的JSON格式都是围绕SQL语法进行的，是组成一个业务査询SQL常用的一些语法，看板的实现逻辑也与上面单图的实现逻辑相似，不同的是要增加看板中包含哪些单图(即包含的每个单图的ID)，以及这些单图在看板中的位置等信息。有了支持可拓展的JSON配置格式，就可以在大数据分析平台配置出符合自已需求的单图与看板了。这样，比较灵活的日常的报表展现需求，这也说明大数据分析平台迈出了第一步。