魅族大数据可视化平台建设之路
Posted 魅族开放平台
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了魅族大数据可视化平台建设之路相关的知识，希望对你有一定的参考价值。
魅族科技大数据平台架构师赵天烁
本文主要从现状&问题、当前目标、实现方案三个方面介绍可视化平台的建设之路。
一
现状&问题
大数据可视化与普遍意义理解的数据可视化不同，其面临的问题分两个不同的层面：一是数据层，二是可视化层。
数据层面
数据接入
即如何把不同渠道、不同格式的数据接入进来，原始数据不标准的结构化信息，不可以直接做可视化。
数据质量
即保证元数据指标清晰、数据内容直观、数据无误，使关心业务、关心数据的人得到数据里面的价值。
数据查询
大数据的呈现下，性能查询、数据的实施，如何解决大规模计算带来的可视化挑战，包括易用性、数据更新的频率，特别是大数据场景下，数据更新频次非常高，这些都是全新的问题。
数据安全
做大数据的人群，基本上都会建一个数据中台，但不同业务层面的整体的数据仓库一旦将不同来源的数据汇集到一起，权限的问题是避不开的，不同的业务团队及角色之间根据业务场景的不同，都有非常大的差异。
如何去指标维度级的鉴权、行级、列级鉴权，还有公司内部数据交换的时候如何做脱敏都是我们面临的问题。权限的控制有两种，一是直接鉴权，二是后置审计。
02
可视化层面：核心主题
组件
大数据可视化过程中，我们要思考如何用组件化的方式做条件样式、联动、自定义的方式支持专业用户的可视化。
功能特性
我们应思考如何做到常见的维度切换、自由排版、区域分组联动，最终使整个数据可视化呈现形成一个活的页面，更为关键的是，如何将分析的思路套进去。以期实现通过可视化平台把相关的数据思维与业务相结合，将专业用户的分析思路和视角用一种平台化的方式传递给业务同事，使分析的思路可复用化。
预警和通知
我们希望将关键性的指标直接规则化，甚至系统内置，跟元数据平台做打通，通过元数据第一时间指示核心指标的异常波动，第一时间推送给相关的人员。
多终端
多终端是体验层面的提升，我们不仅希望做PC端的网页页面和移动端APP的数据查看，还希望做行业级数据报告（不一定外发），内部传递形成一个可复用的产品，把数据的价值用更直观、更互动性的方式呈现出来，最后实现多端分享和互动。
二
当前目标
基础功能
基础功能就是常见数据源的支持。
灵活扩展
灵活扩展可用于解决前置数据层面的接入，80%的问题用平台化的方式解决，20%的问题提供插件化或者扩展的机制，即二八原则。
体验优化
数据可视化不是C端服务，是专业的应用场景。关注点在功能和满足业务诉求的层面，先谈能解决，再谈解决的好坏。
平台集成
我们希望魅族平台不只解决数据可视化问题，对于如何把数据从底层公共架构模型里面一层层剥下来，也是我们需要解决的问题。
场景封装
二八原则解决所有的业务后，接下来面临的问题是场景的封装和深入。解决了第一层的呈现问题以后，把数据化运营的思路贯穿在数据可视化的最终结果里面，就是场景化的垂直封装。
我们做的是一个组件、是一个工具、是一个平台还是一个解决方案还是生态？在实际做决策的时候，前面三部分，甚至第四部分是都是要考虑到的，它会影响我们职业的里程碑。
最终决策的是结论，我们结论的优先级如下：
满足基础功能
有可扩展性、二八原则，至少解决所有业务
工具优先于平台，先是工具，然后用平台化的思路解决整个数据流转过程中的价值变化问题
上下游的集成
三
实现方案
定制
正因为市场上，很多商业化产品并非销售所说的那么优异。魅族的可视化类型又要做一些特别细粒度的优化，所以我们基于这个考虑，为快速响应、满足自身的需求，优化自身的资源，我们采用少花钱的原则。毕竟商业化产品要付费，额外的定制费用同样不菲。
产品集成
安全集成
数据可视化平台希望和魅族平台做深度的集成。当公司面临重大阶段性问题的时候，如果只做简单的服务是不行的，所以我们首先要重视数据安全集成问题。
分析引擎集成
大多数做数据可视化不一定有分析引擎的能力，异构数据源的介入最常见的做法是给一个接入层，做简单的驱动接入或者连接的配置，最后的查验性能非常差。尤其多维分析，对大宽表的处理、高维数据的降维可视化。所以分析引擎我们也是自己来进行定制、接入，我们内部数据库的引擎，基于Hadoop生态有Hadoop或者这之上引入的开源场景等各种各样的类型。
数据化运营产品集成
我们的推荐平台、数据开放平台、精准营销平台、广告等，都会涉及数据可视化的内容，也都会借助数据可视化的能力。只不过在某个特定的业务场景里面有这个诉求，包括机器学习、图象识别等标签的结果，都跟数据可视化有关系。很多商业化的产品，在这个维度一定要定制开发，内部系统有些历史包袱或者设计上的传带问题，都很难商业化做通用。
复用
多点、大屏、PC、移动端等都可以页面复用。可视化的组件可以复用，可视化的区块在不同的业务场景里面都能用。这个复用不一定是平台级的复用，甚至可以做让业务系统、做区块级的可视化集成。数据接口层面的集成，既然对接公司的分析引擎，有统一的分析入口，完全可以做数据服务化。可视化平台在魅族最终并不是简单的呈现，下面集成的分析引擎，下面对接的元数据，各级的服务都可以拆分做服务化和平台化。
快速响应
如何高效效应，是我们非常关注的点。同时解决上述提到的问题都可以高效响应。
功能需求
内容需求
环境运维
查询性能
上面谈到不用商业化产品的原因，现在我们来具体的分析如何解决此问题。关于数据层，数据接入和质量、安全均是由大数据基础平台解决，我们更关注的是右边的数据访问层。
数据访问层在魅族内部有如下几个不同类型的引擎：
实时计算
实时计算中Spark Streaming、Storm、Tindex，Tindex均可以对时序做得很好。
OLAP
Vertica不便宜，成本也很高，正在被慢慢替换掉。随着业务的增长，定制化的需求会逐渐增长，我们开始使用Kylin。
Kylin的优势是去做OLAP分析，多维数据直接聚合，它是预计算的模式，性能比较好；劣势是实时性较差。
我们基Kylin做了一些定制，主力还是离线计算；此外，它不太擅长做大范围、高基维的排序和模糊检索，因为底层基于存储是Hbase，所以对模糊检索并不是特别适合。
我们做内部统一查询入口的时候，会考虑Kylin社区当前的动线和我们有哪些异同。
即系查询
右边的两个查询，一个是即系查询，第二个是TIDB基于Google的LE有一个商业化公司做分布式商业化解决方案。Kylin预计常见的并发度会高一些，甚至可以优化ETL过程。
文本检索
对于魅族来说，由于SQL成本太高，所以我们目前选择不做SQL。固定的研发周期，对于我们来说还是很困难的。所以我们最后做了统一概念模型，字段、指标、维度、参数、动态条件、分页、导出这几个诉求，是数据访问层里面常见的诉求。
如果要做数据挖掘和数据科学维度，SQL语言便无法满足此要求，这时就要对接一个技术生态。集成一些parcel的组件的库，把这些抽象的模型做成parcen的组件，只管最后的输入、输出。魅族当前已经开始着手做统一的SQL访问层，只用SQL解决传统数据分析领域的问题。
数据交换&模型集市
数据交换和模型集市，是数据可视化平台和元数据平台紧密合作做出来的东西。对于指标逻辑的梳理跟元数据一致性的控制较难把控，它的做法是把底层的东西做元数据打磨，导到元数据平台，形成模型集市。
首先推荐Superset。它的展示类型非常丰富、功能也很全面，而且它对权限的解决做得很深入。
很多开源的可视化解决方案并没有处理权限问题，但是这个软件可以做数据分析和挖掘，可以动态调一些指标、模型，包括做简单的降维处理等。
为了帮助大家更好的做选型，我将上述的两个软件做了全面的对比。
Superset的优势是可视化类型丰富、探索式分析+可视化、Dashboard构建、SQL编辑器、权限控制完善、开箱即用、支持主流数据源。劣势是自定义SQL的语义层、封装不完善、交互体验复杂、可视化效果一般。
Metabase的优势是探索式分析+可视化、可构建Dashboard、开箱即用、交互体验简洁实用、设计的完成度高、支持主流数据源、SQL编辑器。劣势是可视化类型较少，探索式分析自由度有限、权限控制比较简单。
可视化
魅族选择开源的产品，可视化的封装，要和成本、标准化定义和定制化需求做权衡，因为我们的选择直接决定了平台产品的边界和未来的走线。
魅族在实施具体方案时，可视化层遵循二八原则，80%用常用区块类型、视觉主题、布局结构、功能特性。
下面三张图是思维导图，第一张图是区块的类型、视觉主题、布局结构，下面的两张图是常用功能及扩展，这三张图反映了当前数据可视化平台面临的所有细节问题和选型的细节。
布局结构是基于网格的布局结构，尽量不要做绝对布局。
集成&服务化
最后我们来看一下集成服务化的问题，既然做统一概念模型，就可以变成服务化的平台。
上层可视化中需要的数据级和查询，都可以封装成一些服务，通过ID去指定查询的数据级。除了给可视化平台用，它还可以直接变成数据服务化的体系。
本文整理自第十二期魅族技术开放日《魅族大数据可视化平台建设之路》中魅族大数据平台架构师赵天烁的现场分享。
魅族开放平台
干货分享 | 平台动态 | 数据报告
以上是关于魅族大数据可视化平台建设之路的主要内容，如果未能解决你的问题，请参考以下文章