由最初的纯设备生产厂商渐渐发展为今天的智能设备设计商和互联网服务提供商，“魅族”转眼间已经历了十年的成长，其Flyme系统也在逐渐走向成熟。而依托于Flyme的魅族互联网服务也逐渐发展起来，随之而来的大数据需求也日渐增多。
为将海量数据得以更高效的应用，沉淀大批高质用户标签，并用数据辅以应用商和广告主的经营决策，魅族数据平台建设工作随之而起，迄今为止已两年有余。
魅族数据平台采用了业界主流的计算平台和开源技术，涵盖了Hadoop生态、流计算、机器学习等领域。截止现阶段，魅族数据平台已完成对魅族关联业务的各项数据支撑，长期计划中，它也将全面投入魅族AI计算平台和机器学习/AI业务的支撑能力研发中。
为了进一步探究魅族数据平台的技术迭代演进之路，了解其背后的选型思路、技术创新和在不断迈进过程中所踩过的坑、所规划的解决方案，InfoQ对魅族数据平台经理莫涵宇进行了深度专访，和他一起聊聊魅族数据平台的设计哲学和核心架构。
魅族为何要研发数据平台，源于哪些痛点？该款平台主要面向什么样的用户？
莫涵宇：早期魅族互联网业务的各种数据需求无法得到满足，使用第三方数据服务存在种种限制，更谈不上数据资产价值最大化的诉求，解决这些问题是魅族大数据团队成立的初衷。而一个稳定强大的大数据平台也成为我们开展服务的基础，基于此我们研发了魅族大数据平台。 目前魅族大数据平台的用户主要是基于 Flyme 生态的魅族互联网业务，此外还包括魅族科技其他非互联网业务，如财务、营销、手机研发、供应链、客服等。
在两年多的建设中，魅族数据平台经历了几次较大迭代？每次迭代都有哪些重大变化？
莫涵宇：在魅族平台发展及架构演进过程中一直强调数据是根本，是最重要的资产，同时强调保护用户隐私，所以从一开始就坚持数据获取走自研之路，而技术上更多坚持 Hadoop 开源组件为基础，并通过交流学习紧跟社区步伐，快速迭代实施。
总的来说，魅族大数据平台架构演进大致经历了如下几个阶段：
摸索阶段：在这个阶段，魅族自研了简单的行为上报 SDK，业务接入后开始可以统计 APP 启动次数、使用时长等基础指标。当时的 Hadoop 集群只有 6 台机器，ETL 过程也只是通过脚本方式来调度，统计报表因为没有直接可用组件，使用的是 Java+ 前端方式直接开发，效率比较低下。
平台基础框架搭建期：抱着拿来主意的思想，调度系统 1.0 及统计分析 1.0 版本在同事旧的经验基础上快速迭代开发上线。虽然调度系统并发不高，统计报表配置走的是 xml 配置方式，但魅族大数据专职的 ETL 同学已经可以基于调度平台进行模型设计、报表开发。接入的业务范围及输出形式也有了较大增长。
平台快速发展期：随着接入业务增长，业务对数据及平台的需求急剧增长，在此阶段调度系统进行了几轮快速的迭代，同时行为上报新 SDK、WebIDE、流平台、用户宽表等平台也快速推进上线。魅族平台初步具备了实时处理、简单的 SQL 查询能力。
平台完善期：经过一轮快速的平台建设，虽然一些基础平台及功能已经具备，但产品体验、性能、稳定性问题开始初显。在不影响业务的前提下，对多个平台进行了重构升级：1、行为上报升级为集 APP 注册、SDK 管理、自助测试等功能一体的统一上报平台；2、调度系统升级为集成开发平台，从原来 Shell 驱动改为基于 Java 开发的 Core+Runner 架构；3、魅族流平台经过多轮优化，处理了各种技术上的坑后稳定性有了显著的提升；4、用户宽表发展为用户洞察平台等：在基础平台功能及稳定性逐步完善的过程中，在满足业务运营需求基础上，直接为业务提供更多的支撑，比如对推荐、AI 等业务的支持。
产品导向期：经过前几个阶段的建设，魅族大数据平台体系基本建立。为了更好的提升数据服务的影响面，推进数据价值的落地实现，数据团队由早期被动接收需求变为主动贴近业务，与此同时对数据平台产品化、开放度、细节提出了更高的要求。目前我们正处于这个阶段。
魅族数据平台采用了哪些业界主流的计算平台和开源技术（请例举几项，并解释为何采用）？为满足平台性能及其他需求，魅族是否有哪些自研组件？
莫涵宇：魅族数据平台的基础计算平台都使用了业界主流的开源框架和技术，如 Hadoop、Spark、Hive、HBase、Kafka、Storm 等几乎大部分主流的数据开源技术，采用这些开源技术的好处显而易见。
首先相对商用产品，使用开源技术使得开发成本大幅度降低；其次，功能的订制可以更灵活和快速；此外，这些主流开源技术均有来自全世界的顶尖专家在参与研发和维护，使用它们能让我们更快的跟上行业技术的发展。
当然每家企业的应用场景都有自身特点和特殊性，开源框架和技术并不能完全解决我们所有的需求，所以我们针对性的研发了一些组件。例如：
为了解决 Sqoop 配置复杂、难以统计和跟踪的问题，我们研发了 cetus-Loader 组件，以实现文件到文件、数据库到文件、文件到数据库的传输，支持 MySQL、Hive、HBase 和文件系统，支持简单的配置和丰富的日志，并能在发生故障时（在保证性能的前提下）方便的回溯问题并解决故障。
另外，我们的流计算平台也进行了自研组件的整合。单纯使用 MQ、Spark Streaming、Storm 等都不能让整个流计算串起来，我们开发了接口组件、业务配置组件和平台管理组件，通过这些组件把几种开源框架整合起来，让整个流计算具备高可用可扩展易管理的特性，才真正解决了我们实时计算的需求。
您能否为 InfoQ 读者重点讲解从数据接入、数据清洗、存储计算到监控等环节，魅族数据平台的运作原理以及各个环节技术选型上的思考（包括走过的坑和解决方案的调整）？
莫涵宇：如图所示，魅族数据平台逻辑上分为数据源层，接入层，数据仓库和计算层，数据接口和应用层这些大的层次，数据的流动基本上会是从左至右的模式，数据的价值最终体现在接口和数据应用层，对于这些层面使用的组件，我们也经过较为谨慎的选型和多次迭代。
首先，早期基于业务规模较小的状况，我们的数据接入层并没有做特别的选型测试，而是完全自研开发了一个分拣程序进行数据的接入，随着数据量和业务规模的不断增长，我们发现原有的程序在扩展性和性能上都出现了瓶颈。最终我们结合同行的一些经验和自己的测试，重新规划了接入层的架构和实现，设计了新的接入组件：其中采集 SDK 一直是自研，主要考量是公司安卓领域的经验丰富，相关人才储备充足；批量数据加载组件 Cetus-Loader 考虑到行业内基础调用的相关技术非常成熟，我们仍然采取自研的体系，通过各种产品的标准 API 调用结合适当的预处理和配置去实现，配合管理平台也实现了数据接入流程的跟踪；我们的流平台 mz-Stream 除了业务管理部分，基础计算组件采用了 MetaQ 和 SparkStreaming，选用 metaq 有一些历史原因，从性能评估来看没有太大的问题，同时该组件已经是公司使用得较为成熟的组件，有专人维护，而 SparkStreaming 在 MiniBatch 处理上已经被证明了其灵活性和高效性。当然，从业界最流行的组件看，未来针对这两个部分我们还会再评估 Kafka 和 Strom 的引入。
当数据接入数据仓库后，我们会进行数据清洗（大部分清洗工作会在入库后进行）、存储和各种计算，这些过程我们选用了 Hadoop 生态的组件。这里的原因也很简单，Hadoop 有经过各大商业环境验证的比较成熟的解决方案，有足够强大的社区更新和支撑，HDFS、Hive、HBase、Spark 等都在各种领域证明自身的能力，从成本和效率的角度考虑，这些组件是不二的选择，至于 Kerberos、Ambari 等附加组件的使用也同样是围绕 Hadoop 而取舍。
经过基本处理形成领域和主题模型数据集，为我们的数据应用提供了丰富的数据来源。在数据接口和数据应用这一层，考虑到易于订制和扩展的需求，我们主要使用 Java 自研了各种数据产品，这些数据产品也同时使用了例如 Kylin、ES、Vertica 等查询引擎组件，为我们交互式应用提供支撑。
最后，贯穿这些环节需要一套任务调度系统和任务 / 指标监控系统。通过对一些开源产品，例如 Kettle 的分析，也包括专业人员过往的经验支撑，我们还是采取自研策略，相关产品对于每个过程的处理进行合理的任务调度，最大化计算资源的利用率，监控任务的执行情况和指标的合理性，对流平台的输入和输出对账，帮助整个数据应用的流程更为顺畅和高效。
这里顺便也提一个任务调度的坑。早期由于任务数较少，我们研发的第一版任务调度系统依赖了 Orale 存储过程和触发器进行逻辑计算，随着任务数和复杂度的增加，这种架构很快就捉襟见肘，我们不得不花费了很大的精力在短时间内重构了全新的任务调度系统，再花费了很长的时间进行迭代优化，更多使用内存计算和事件消息的机制。这个教训告诉我们在选型的时候简单的技术方案可以给我们当前的工作节省不少时间和精力，但如果对业务发展估计不足导致的技术前瞻性不足有时候也可能带来更大的代价。
是否有 Hadoop 集群演化过程的经验可以分享？遇到的主要问题和解决方案有哪些？
莫涵宇：魅族 Hadoop 集群一直坚持 Apache 社区路线，未使用商业服务。在演化过程中遇到、解决的问题不少，比较重要的问题有：
HDFS 问题：HDFS 是大数据平台的存储组件，它的稳定性对其他生态组件及整个大数据平台影响是非常明显的，对于功能 BUG，我们主要采用源码补丁修复升级、版本整体升级、调用规避等策略，必要时做些源码修复；对于 HDFS 性能问题，我们主要采取参数优化、集群按需拆分、架构调整 (如 HDFS Federation)、版本整体升级等策略；
Hadoop 生态技术组件协同工作时的兼容性问题：对选定的技术版本栈（Hadoop、Spark、HBase、Hive）等，进行整合部署调试，抽调典型生产任务类型进行验证，修复遇到的问题，并制定上线计划，分步骤实施上线。
计算性能问题：1、引入当下主流的内存计算引擎（如 Spark、Tez）等，替代老旧的 MR，实现计算平台整体性能提升；2、引入 Dr.Elephant、Eagle 等开源监控工具，经过团队技术消化并定制后，推广上线，实时监控并帮助开发人员去优化作业参数配置，从而达到提升计算性能的目的；3、定期的经验技术分享讲座、常态化的平台技术答疑。
数据及集群安全问题：随着数据及业务的快速增长，安全问题愈发突出，国家也出台政策文件号召重视大数据安全建设。魅族作为一个负责任的企业，一直把用户数据、用户隐私安全当作头等大事。2017 年，魅族大数据整合社区成熟开源技术（Kerberos、Ranger）以及自研 SCT 通用权限制等措施，重新梳理调整平台架构，建设了规范化、系统化的平台安全体系，实现后台终端到前端 Web 的安全权限控制全覆盖，同时也在公司层面逐步整理并制定向国家标准看齐的大数据安全规范。
能否分享一下 OLAP 引擎探索思路和目前的进展？
莫涵宇：一般来说，OLAP 引擎整体分为 OLAP 模型构建和解析引擎、数据查询引擎两个部分。我们最开始希望基于 Mondrain 做二次开发，与各类查询引擎对接。在预研过程中发现其与流行的一些大数据查询引擎存在兼容性问题、而使用传统 RMDB 又存在大数据量时的查询性能问题，另外各类查询引擎的扩展适配代价过高。因此我们先决定打造一个面向大数据的统一查询引擎，之后 Mondrain 与这个统一的查询引擎对接 (作为模型构建和解析引擎)。
而这个统一查询引擎应该具有以下特点：
A. 统一的 DSL；
B. 具备解析器和查询优化器；
C. 结合元数据和用户请求自动完成查询的 Pushdown；
D. 集成安全和监控解决方案；
E. 通过组合不同查询引擎的优势能力，在大数据环境下，面对筛选、模糊匹配、高基维排序、多维度聚合、实时性上都能够有比较好的表现。
我们在 OLAP 引擎建设中也做了一些工作：
A. 统一 DSL 目前已经接入 Kylin 和 MySQL，并在内部统计分析平台部分需求中上线；
B. 已经和公司统一监控进行了对接，安全方面通过 Ranger 扩展方式接入了自研的 SCT；
C. 正在尝试接入 ClickHouse，未来计划接入一些实时性较好、模糊搜索排序方面性能优秀的查询引擎，补充现有选型的不足；
D. 正在完善跟元数据平台的对接，以实现不同场景的查询 Pushdown。
魅族数据平台自研的自助分析、驾驶舱 (移动数据分析) 能够帮助使用者解决哪些问题？优势是什么？我们同时注意到，数据平台未来也计划在 AI 上加大技术投入，赋予其自身更多的 AI 能力，您是否能具体讲讲你们的技术实践计划？
莫涵宇：关于驾驶舱这个产品的研发，主要来源于管理层的需求。我们发现管理层经常无法坐在电脑前工作，他们需要在移动办公过程中随时查看一些业务数据，但单纯通过网页展示一方面有安全隐患，另一方面登录环节也是一个麻烦事，基于此我们提出了移动数据分析的概念，开发了驾驶舱这个产品。这个产品主要特点是在可视化呈现上可以灵活的嵌入 H5 页面，是一个灵活的 Hybrid 应用；数据上与内部的统计分析系统共享后台，保持数据的一致性；在安全上采取了充分的保障策略，通过系统指纹验证可以直接登录也简化了繁琐的登录流程。目前产品除了服务高管也已经在业务负责人中推广开，帮助各业务的同事方便的查看数据进行决策。
另外，针对非技术领域的同事，我们还开发了自助分析平台，这个平台主要的特点体现在前端交互部分，通过可视化操作的组件，用户不需要懂 SQL，可以通过简单的拖拉拽完成动态分析或者构建自定义报表，未来这个平台还需要支持更丰富的 OLAP 操作。我知道有人会问，Tableau 这些工具不是实现得很好么，其实在我们看来，Tableau 功能足够强大，但很多细节并不好用，包括一些时间控件，包括数据量较大的时候内存的控制，以及对一些订制需求的快速支持上都有局限性，这些因素促使我们开发一个更适合我们使用的数据可视化分析平台。
关于 AI 领域的探索业内的领先企业已经走得挺远了，我们同样需要能跟上时代的步伐，应对未来的挑战。针对 AI 领域的研究，我们目前计划在知识图谱，意图识别上做一些探索。
首先，知识图谱是很多 AI 应用的基础，包括搜索，推荐，意图的推断都能发挥重要的作用，当然考虑到百科图谱对我们来说代价太大，我们也不会往百科的方向发展，目前我们还处在业务调研的阶段，通过业务分析去界定建设图谱的领域和范围。
意图识别是另一个重要的 AI 研究方向，它与 NLP、模式识别和知识图谱都有关系。尽管业内已经有很多智能助手应用，但正如众多创业公司、团体还在意图识别领域发力一样，我们也认为市场足够广阔，垂直领域也足够丰富，我们会结合我们自己的场景去持续加强意图识别能力，除了进一步增强 onemind 能力，还可以应用在自身的智能助手，智能客服，搜索推断等领域。
目前魅族内部基于这个大数据平台做了哪些产品或应用？在哪些方面给魅族带来了提升？是否可以分享一到两个具体的案例？
莫涵宇：在魅族数据平台的建设过程中，我们针对实际的业务场景开发了一系列的数据产品和数据应用，包括统计分析平台 Orion，集成开发平台 Cetus，统一权限管理平台 SCT，用户洞察平台（用户画像），自助分析平台 lyra，数据统一上报平台 Norma 等，除了前面介绍过的产品，这里再介绍两个案例（原稿中有用户洞察平台的案例，这里没了）：
针对数据开发流程复杂的情况，我们研发了集成开发平台 Cetus，这个平台主要包括 webIDE 和调度系统两个部分。webIDE 是我们统一的编码平台，通过 web 编辑窗口进行脚本语言的编码，目前支持 HQL、Python、Shell 几种，平台也预留了更多语法的扩展性；调度系统实现数据处理日常任务的调度管理、各种查询、任务相关操作和故障处理，它与 webIDE 直接打通，用户可以直接编码后发布到调度系统或者直接在调度系统调用编码环境直接编写代码。Cetus 平台把我们日常的数据开发工作通过 IDE 管理起来，降低了任务开发上传脚本等流程的复杂度，同时把调度配置，故障处理等都整合在一个统一的平台下，大大提升了我们的开发效率的效果，很好的提升了用户体验。
另一个体现数据平台效率的产品是我们的用户洞察平台。这个平台的核心是用户画像系统，我们通过用户行为和设备属性的统计以及算法预测，建立了较为完善的用户画像，通过洞察平台可以对用户进行精准圈选，自定维度的洞察以及内容投放，平台同时也提供 API 调用，实现可被第三方系统和平台的调用的能力；丰富的用户画像数据也成为推荐算法的重要数据源，尤其是用户兴趣偏好标签，这些标签在各项内容推荐业务中发挥着重要的作用。随着用户洞察平台的完善，魅族互联网业务越来越依赖这一平台，通过对用户的精准识别我们大幅改善了内容推送的效果，很好的提升了用户体验。
您能否谈谈平台的价值和发展？您认为应该如何评估大数据平台的技术能力？从哪几个维度？魅族数据平台下一步的发展规划有哪些？技术上是否计划开源？
莫涵宇：数据平台并不那么显山露水，很多情况下甚至就像一座冰山，人们看到的只有那么一角，而在水面下有一个庞大的身躯支撑着整体。但大数据领域的人都知道，数据平台的能力决定了数据应用能达到的高度，所以对数据平台的价值我持绝对肯定的观点，也会不遗余力的推动平台向业界领先水平追赶。
评估一个大数据平台的能力，在我看来优秀的大数据平台应该具备以下一些特点：
高效性：包括执行的效率和开发的效率，相同的复杂度下单位时间处理的数据量越大则执行效率越高，相同的复杂度下开发流程越简单，则开发的效率越高。
稳定性：顾名思义就是平台正常运转和性能的稳定性，异常次数越少，异常时间越短则稳定性越高。
易用性：其实也是和效率相关的，对于用户来说，平台本身的交互应该更合理，让用户以更舒服的方式使用平台，更快的获得需要的结果。
安全性：这是一个不容忽视的问题，数据安全隐患无论对社会影响还是企业责任都是严重问题。
扩展性：当前的技术条件下我觉得优秀的数据平台应该具备良好的扩展性，资源投入的增加与处理能力提升应该尽可能趋于线性。
成本：企业投入和产出肯定要有一个合理的规划，开源技术的流行，Hadoop 生态的火爆，其实很大一个原因也还是考虑了成本。
魅族数据平台虽然经历了两年多的建设，但仍然在快速发展中，未来我们有两方面的规划，一方面仍然是提升对内服务的能力，对魅族业务做更好的支撑，另一方面，我们希望尝试走出去，首先给我们上下游的合作方，接入魅族开放平台的开发者和企业提供一些数据平台服务，包括 Flyme 生态下的排行分析、应用分析、Push 效果分析、行业报告等。
针对刚刚提到的一些应用场景，我们在 1 月 18 日已经发布了一款数据产品，叫做π（pi.meizu.com），圆周率是一个无限不循环的无理数，也寓意着数据价值的无限可能，欢迎我们的合作伙伴试用。更远来看，我们还希望外发 SDK 提供个性化统计服务，订制分析报告，开放 DMP 合作，期待能发挥更大的价值。
最后，开源这个方向是美好的，我们也期望能对行业做出一些力所能及的贡献，也能在社区开发者交流中获得更多成长，但目前来看条件还不是那么成熟，短期可能还没有该项计划。
采访嘉宾
莫涵宇（Neeke），魅族数据平台高级经理，具有十五年工作经验和十四年数据仓库与大数据开发应用经验，先后服务于某电信系统集成商，阿里巴巴，YY，魅族科技，过往主要从事数据平台建设，架构设计，数据处理等领域工作，目前负责魅族大数据平台的管理和整体业务规划，包括数据平台建设和数据应用服务（数据处理，报表，分析，预测，推荐算法，AI 图像和语义）