算法和数据架构本来就是相辅相承的，互相运作才能达到最佳效果。同样，算法和数据处理也是操作系统的核心部分。魅族手机操作系统 Flyme 在为用户提供优秀的交互体检和完美的服务过程中，利用机器学习技术和大数据平台架构的搭建，给用户最精准的内容推荐，和流畅的操作感受。
以下是对李梦婷博士和张欢引老师的采访，就机器学习、算法提升，和数据平台架构优化等问题进行解答。如果想要面对面请教二位技术问题，可以来参加在 ArchSummit 深圳架构师峰会上举办的魅族技术晚场活动，两位老师到时候均会带领不同的小组进行更深入的技术话题讨论，报名链接请戳“阅读原文”。
InfoQ：在目前的个性化推荐以及互联网广告平台中，用户画像应用是非常广泛的。魅族主要是通过几个维度来刻画一个用户的，每个维度具体又包含什么？
李梦婷：魅族团队主要从六个方面刻画用户：人口属性（比如性别，年龄等，可为用户提供基本的人群服务）、位置属性（比如常驻省份、常驻城市等，可为用户提供场景化服务）、设备属性（比如屏幕尺寸、电池容量等，可为用户提供最佳的使用感受），业务属性（比如使用时长、操作偏好等，可为用户提供更好的业务体验），兴趣属性（比如金融、体育等，可为用户精准推荐感兴趣的内容），最后一个是消费属性（比如常用支付方式等，可为用户提供更贴心的服务）。
InfoQ：如果用户特征和标注集合缺失的话，常规机器学习方法难以发挥应有的效用。根据魅族的实践，是如何解决这类问题的？
李梦婷：数据缺失是一种很常见的情况，碰到这种状况，我们的团队通常会先根据其他已有的特征来计算出相似用户群，从而填充某些缺失的画像特征值。除此之外，部分特征我们也会结合先验知识（Priori Knowledge，是先于经验的知识），甚至是采用人工标注或者与第三方机构合作的方式，构造出标注样本。这些样本除了用于机器学习训练之外，也会在一些特定的场景直接用，比如直接人群定向。
InfoQ：经过长时间的功能完善，目前为止，魅族智能思维引擎 One Mind 又做了哪些性能和算法模型上的改进？
李梦婷：One Mind 在之前的几个版本基础上已经做了非常多的技术和功能改进，比如引入深度学习技术，能够更加准确地识别出用户当前的状态，以及挖掘用户的行为习惯，进而给出智能化决策，提供各种使用场景下的智能解决方案；在”快省稳“方面，我们对算法进行了优化，提升了使用 App 预测的效率，并且引入了天气、位置等环境因素，从而使得预测结果命中率更高。
InfoQ：从您的角度来看，若要更好的实现您当前研究的推荐等工作，那么魅族接下来需要在移动 AI 方面有哪些投入？需要更关注哪些 AI 技术点？
李梦婷：可以说，AI 只是一小部分，提升一项功能的实力，需要从整个产品的综合角度来考量，我觉得主要可以归纳为以下几方面：
系统本身：延续之前提出的“快省稳”观念，采用个性化的系统资源调度方案，从根本上提升用户体验；
精准推荐：在信息泛滥的今天，让用户始终能够快速准确地获取到自己感兴趣的信息，从内容层面上提升用户体验；
智能应用：探索前沿深度学习技术，为用户提供语音指令、图像处理等人工智能应用，从使用层面上提升用户体验。
李梦婷多次谈到“提升用户体验”，可见，魅族是真的希望通过技术手段提高产品的可用性，进而获取用户的好口碑。听完李梦婷的讲解，我们再来听听魅族数据平台研发组长、架构师张欢引老师关于魅族大数据平台搭建的那些事。张欢引老师目前主要负责魅族数据平台研发团队管理，组织关键技术及架构评审。在大数据平台构建方面有丰富的经验。
InfoQ：您之前负责过千万级以上项目的架构设计、开发部署工作，对于架构设计和部署工作，您觉得需要遵循什么样的规律，需要提前考虑避免哪些设计上的坑？有没有什么经验可以简单分享？
张欢引：高并发架构设计需要遵循的规律或者原则是有很多的，在这里，我就从高并发、高可用的角度简单做下个人的经验汇总和梳理：
抽象化：将产品或业务中的对象进行抽象，方便业务扩展，避免业务发展或一些小的变动而去重新设计架构。
分层原则，并尽可能把请求往前移：互联网产品一般分为用户层（浏览器、客户端等）、接入层、应用层、服务层、数据层，并通过一些措施将不必要的请求尽可能挡在靠前一点的层级，比如 CDN 缓存、静态缓存、有效性判断等。
模块化原则：将复杂问题通过模块化、接口化等进行简化，同时各模块尽可能无状态设计，方便做横向扩展、负载均衡，避免单节点等问题。
优化瓶颈点：找出整个架构中各层、各模块对并发影响最大的地方并细化设计。比如说瓶颈在数据层，可以考虑采用分库分表分区、DB 缓存、NoSQL 技术等方案；比如发现一个模块处理量上不去，但负载一直比较低，这就应该考虑提高并发量或是引入异步处理。
做好监控及自我防护：这个原则更多的是提高系统的可用性，监控（或收集、反馈）是自我防护的前提。自我防护的方式方法很多，比如说限流（恶意请求屏蔽，防雪崩处理）、分流（负载均衡、故障节点自动踢除、跨机房部署）等，在必要时需考虑降级处理。
关于架构设计需要规避的坑及一些实用的经验，这里也简单分享几点：
架构设计不能脱离业务本身。在做设计前，必须对业务受众、产品形态、产品交互及基础数据配置进行深入思考，并做适当的归纳、抽象后再进行设计，同时要考虑后面可能会出现什么样的问题。
对用户规模、系统请求量、后续增长等进行评估，从而确定架构目标、可能存在的瓶颈点。同时我们也要避免过度设计，比如说一个小项目，在可预期较长时间内数据量不会超过一两百万，数据表设计时却刻意使用分库分表。
尽量复用已成熟的组件，而不重新制造轮子。
对于架构中会使用的新技术、新组件，一定要做好预研，并结合业务场景进行测试（包括性能测试）、分析。避免为了使用新技术而使用，比如一个项目，使用 MySQL 就能满足查询性能要求，但刚学了 NoSQL，听说查询有较大提升，结果刻意把表拆解为 NoSQL 的多份数据，最后复杂度大大提高。
针对已有系统架构进行升级时，必须考虑新旧系统兼容性问题，并确定新系统上线方案。
缓存是种使用比较多而且有效的手段，但要避免设计考虑不全造成数据不一致。
InfoQ：魅族的大数据平台搭建，更多的是针对移动用户的数据采集、行为分析，可不可以简单介绍一下魅族大数据平台架构演进历程？
张欢引：在魅族平台发展及架构演进过程中一直强调数据为本，数据是最重要的资产，同时强调保护用户隐私，所以从一开始就坚持数据获取走自研之路，而技术上更多坚持 Hadoop 开源组件为基础，并通过多沟通、多学习的方式快速迭代实施。总的来说，魅族大数据平台架构演进大致经历了如下几个阶段：
摸索阶段：这一阶段，魅族自己开发了个体用户行为上报 SDK，业务接入后开始统计 App 启动次数、使用时长等基础指标。当时 Hadoop 集群才 6 台，对应的 ETL 过程都是通过脚本方式来调度。统计报表因为没有直接可用组件，使用的是“Java+ 前端”的方式直接开发，效率比较低。
平台基础框架搭建期：抱着拿来主义的思想，调度系统 1.0 及统计分析 1.0 版本在旧的经验基础上快速迭代开发上线。虽然调度系统并发不高，统计报表配置走的是 XML 配置方式，但魅族大数据专职的 ETL 同学已经可以基于调度平台进行模型设计、报表开发。接入的业务范围及输出形式也有了较大增长。
平台快速发展期：随着接入业务增长，业务对数据及平台的需求急剧增长。在此阶段调度系统进行了几轮快速的迭代，同时行为上报 SDK、WebIDE、流平台、用户宽表等平台也快速推进上线。魅族平台初步具备了实时处理、简单的 SQL 查询能力。
平台完善期：经过一轮快速的平台建设，虽然一些基础平台及功能已经具备，但产品体验、性能、稳定性问题开始暴露。在不影响业务的前提下，对多个平台进行了重构升级：行为上报升级为集 App 注册、SDK 管理、自助测试等功能于一体的统一上报平台；调度系统升级为集成开发平台；从时间轮询触发 shell 调度模式发展为 core+runner polling 架构；魅族流平台经过多轮优化并处理了各种技术上的坑后，稳定性有了显著的提升；用户宽表发展为用户洞察平台等。在基础平台功能及稳定性逐步完善的过程中，在满足业务运营需求基础上，直接为业务提供更多的支撑，比如说内容推荐、AI 等业务的支持，自助能力的提升等等。
产品导向期：或称精耕细作期。经过前几个阶段的铺垫，魅族大数据平台体系基本建立。为了更好的扩大数据的价值，数据团队由早期被动接收需求，逐渐向主动贴近业务转变，与此同时对数据平台产品化、开放度、细节点提出了更高的要求。目前我们正处在这个关键阶段。
InfoQ：目前，您主要负责包括统一上报、集成开发平台及流计算平台、用户分析洞查、自助分析、智能推荐等魅族大数据技术平台体系基本建立工作，期间是不是一帆风顺的？有没有尝试新的技术和方案？
张欢引：整体来说，平台建设的方向及各阶段的核心目标是对的，但具体的执行过程中困难重重，像人员招聘困难，资源与需求不匹配，业务方对数据持怀疑态度、早期数据基础组件比较欠缺、快速增长带来成本增长等。但是公司对大数据平台建设给出了有效的支持，在前述的几个阶段快速发展后，已经为公司从进销存、固件、各 App 等的运营、业务支撑等提供了全方位的数据支持。
在技术及方案选择上，魅族大数据平台的建设一直在不断紧跟行业前沿，预研并尝试一些最新的技术和方案。比如用户洞查平台 ES、HBase 的使用、流平台前期 MetaQ、Spark Stream 的使用及后面 Kafka，Storm 的接入；数据安全 Kerberos，Ranger 的使用等。在此过程中也踏了一些坑，走了一些弯路，当然其中也有一些是受限于需求紧迫及当时依赖的平台或组件而做出的选择。
InfoQ：因为您会对内部技术架构进行前期的评审，所以想问一下，评审过程中会考虑哪些因素，有什么规则或者长远的考虑？
张欢引：评审是一件很有意思的事情，因为你需要处在一个更高的角度来给出你的想法和更好的解决方案，既要能提出问题，还要能解决问题。通常情况下会考虑如下一些因素：
该功能与产品定位是否一致，目前的紧急程度如何？
用户受众、规模及增长预期如何？
与公司或团队其他项目的关系如何，是否可以复用？
技术选型是否有做实际的场景测试？测试结果、结论如何？
方案是否可行，是否有现成平台或组件可用？该方案是最终方案还是临时方案。是否存在技术瓶颈？业务单点等问题？
该方案的成本如何（包括带宽、服务器、计算资源），对用户体验及隐私是否有影响？
该方案后继运维及运营成本如何等。
在海量数据时代，对数据挖掘和研究的方式方法会更多，数据的价值也会被更大化的挖掘。希望大数据技术爱好者能共同参与到技术经验交流，合力开采大数据这座矿山，交流地址戳“阅读原文”
