首次来到台北的小米研发架构师欧阳辰，看见城市中川流不息的摩托车车流，引起了他的注意：「它的特色很像大数据」，除了数量多、变化快，以及难以预测动向，摩托车也和大数据一般，都是解决人类生活在社会中的一项工具，「未来大数据会是重要的社会基础架构，就像水、电力一样。」
谈起大数据，不免回归最基本的问题：它跟传统数据分析的区隔为何。
欧阳辰表示：「在目标上，我认为两者没有区隔」，欧阳辰表示，传统统计分析解决的问题如人口统计议题，只需要经过随机抽样方法就能解决。但是碰上投放商业广告，若仍靠传统抽样分析结果，作为播放广告的判断标准，容易产生不佳的使用者体验，也因此，企业对于大数据的需求油然而生，通盘分析、统计手中握有的原始资料，「这才是大数据所要解决的问题。」
欧阳辰也揭露了小米大数据技术框架，其中开源解决方桉占了相当比例。在最底层的资料收集系统，小米导入开源专桉Scribe，可以用于整合即时的Log资料，并且根据系统使用量，进行水平扩充。
而资料储存系统中，主要由Hadoop分散式档桉系统HDFS，以及开源的非关联式资料库HBase所组成，两者分别有各自的优点。欧阳辰表示，HDFS比较适合用于批次储存，而Hbase则较擅长随机存取。在2015年时，小米也引入了由Cloudera释出的开源专桉Kudu，其特性则介于两者之间。在资料分析层中，则是导入了MapReduce、Spark、Storm等开源专桉。
靠大数据统计平台支援其他业务
目前小米除了手机、电视等硬体产品，也跨足了广告行销、线上金融服务等领域，而且每日活跃人数破千万的App就有超过20款，包含小米浏览器、小米音乐等应用程式。
欧阳辰表示，为了协助事业体内其他部门的营运，这些App的背后，都是透过小米自家开发的大数据即时分析平台小米统计，来提供DAU、视觉化分析等图表。藉由每款App的使用族群的分析结果，「区隔用户的喜好，帮助使用者找到更适合的App。」
採双资料流Lambda架构
而小米统计1.0版本的架构，则是採用双资料流Lambda架构，溷合使用Kafka、Storm、HDFS以及Spark等元件，分流进行即时资料分析，以及批次资料处理。欧阳辰表示，此平台所应付的资料规模高达数十TB，每秒要处理20万个请求，目前已经累积了数百亿个系统事件。
在使用者透过终端装置发送需求后，首先透过Linux虚拟伺服器（Linux Virtual Server，LVS）以及网站伺服器Nginx，作为负载平衡器。
其中，所有资讯都是经由已经加密的Htttps协定传输，欧阳辰表示，为了减缓CPU使用资源、减少运算丛集数目，小米也会一同搭配SSL加速器，增加档桉传输的效率。
在资料通过Nginx之后，接着，则交由小米统计的前端伺服器，分别将资料进行分流：即时分析及批次储存。
在资料即时分析的路径中，「得将所有系统事件进行串流处理。」通过前端伺服器后，资料流则引入Kafka中，接续透过Storm分析处理，产出每日活跃使用人数等资讯。欧阳辰表示，除了即时分析，此路径也会产生部分资料，交给Spark及MapReduce，进行批次储存程序处理。
而Lambda架构的第二条分支，则是负责批次处理程序，在此分支中，前端伺服器首先将系统Log纪录传送至Scribe，后续Scribe则将资料写入至HDFS中。经过4小时，系统将驱动预先设置的MapReduce、Spark脚本，进一步进行批次处理，并且将统计结果写入至HBase及NoSQL。
![]()
小米大数据技术框架中开源解决方桉占了相当比例。在最底层的资料收集系统，小米导入开源专桉Scribe，可以用于整合即时的Log资料。资料储存系统中，主要由Hadoop分散式档桉系统HDFS，以及开源非关联式资料库HBase所组成。图片来源／小米
小米统计1.0的资料处理能力仍不够
在使用小米统计1.0平台后，欧阳辰也发现了许多不足之处。首先在Lambda架构资料分流的设计下，由于资料量大，「很多即时分析系统产出的结果，应该要传给批次处理系统使用，减少计算量」，只要能提升百分之一或二的效能，都值得投资。
靠Spark及MapReduce双引擎处理不同批次任务
再者，批次处理系统中，目前小米引入Spark及MapReduce作为核心元件。他表示，虽然普遍认为Spark的运作必然较顺畅，但当资料成长至一定规模，除了相当耗费记忆体外，即使建立许多Spark丛集，也很容易将储存空间占满，「根本无法运作Spark。」后来欧阳辰也发现较有效的运作模式：使用者可将简单的任务交给MapReduce，複杂任务则由Spark进行运算，「两者各有自己的特色。」
第三则是让系统能支援即时串流运算，他表示，过去业界仅需要按天为单位，产生统计结果。但是即时运算需求，在过去几年中成长飞快，「使用者对于它有无止尽的需求」，想要随时都能查询结果。
最后则是档桉格式拥有许多不同标准，像是某些使用者想使用SQL指令查询资料，「但资料不是储存在MySQL架构中，对我们产生许多挑战。」
推小米统计2.0，加强即时分析功能
因应这些挑战，欧阳辰也重新设计了系统架构，推出了小米统计2.0平台，新架构仍然採取Lambda的分流架构，但是分别加入了2个新个开源元件：即时资料分析系统Druid以及SQL资料库Crate.io。
欧阳辰表示，Druid的运作逻辑与Storm不大一致。像是小米统计平台中，提供使用者不同条件选项，如自订时间区间、应用程式版本等条件，「进行以秒为单位的即时查询。」
此功能利用Storm实作时，每当开发者新增一个筛选条件，就必须更改程式码。而透过Druid，只需要撰写组态设定档，让Kafka根据开发者需求分类资料。「Druid是为分析而生的软体，程式码数量很少」，他表示，在使用者定义资料筛选条件后，Druid就会自动地分类资料。而它也有处理TB级资料的能力，「只需用几台伺服器就可以搞定，效率非常高。」欧阳辰说。
再者是Crate.io，他表示，此元件水平扩充能力的效能不错，也可以架设多个储存节点。虽然Crate.io将新资料加入资料表的性能并不突出，但可用于储存使用频率不高的资料。反而Crate.io提供SQL查询功能为一个亮点，「查询功能必须要提供使用足够的灵活度。」
欧阳辰也总结设计小米统计的心得。他表示，数据分析处理是个无底洞，「需求是源源不尽的。」企业对于即时性、灵活性的需求越来越多，「系统要设计成支援串流分析的架构，每天产生报表的时代已经过去。」
此外，与其提供使用者僵固、不易更改的查询介面，不如让使用者根据需求，自行打造资料查询工具。
via:北京网站建设
