本文根据【2016 第七届中国数据库技术大会】现场演讲嘉宾欧阳辰老师分享内容整理而成。录音整理及文字编辑。
嘉宾介绍：
▲欧阳辰
欧阳辰，毕业于北京大学计算机系，获得硕士学位，喜欢互联网技术，架构设计，数据挖掘，质量改进，旅游阅读，是一个简单乐观，热爱生活的人。
正文：
大家好，很高兴参加这次大会。先简单介绍一下我自己。我在北大计算机系念完书以后不久加入到了Oracle公司，是中国Oracle研发的第一批员工，做了三年数据库企业软件。之后，2005年，我加入微软从事互联网方面的研发工作，主要做了两个项目:一个是搜索，一个是广告平台。去年一月份加入小米公司，从事大数据平台和广告平台的研发工作。
首先和大家分享一下我对大数据的感悟吧。提到大数据，大家可能马上就会想到4个v，快速、大量、变化、多样，那么我自己理解的大数据是什么呢?
因为现在各种数据的应用场景很多，但是在有些场景下，采样的数据不能够满足业务需求，我们需要一个完整的数据集来做处理业务。举个例子，在广告里面有一个精准投放的概念，就是了解用户兴趣爱好以后，然后精准的投放广告，这种投放的广告效果和用户体验都会比较好，那么这是怎么做到的?必须采用全量数据，假设我们只采样10%的用户去做这个数据处理，肯定是不科学的。
我自己觉得大数据需要全量数据，才能把业务做好。如果只用采样数据，做到的效果，我认为不叫大数据业务。实时数据的价值最大。大家很多时候都觉得大数据光鲜亮丽，其实在做大数据的过程很苦逼，需要经过数据清洗、数据挖掘等等过程。大数据很像红楼梦，金玉其外，其实内在有很多很多无奈。
大家都知道小米是一个手机公司，雷总经常说小米是一个互联网和软件公司，其实我个人理解除了这些，小米还是一个很好的大数据公司。我们有超过两亿的用户在使用小米的手机、电视和路由器等等。小米的数据量非常大，除了我们自己的数据，还有合作伙伴的数据，生态链的数据，那么怎么处理这些数据?
我们的数据基础架构还是很丰富和强大，采用的基本上都是开源技术。我们用Scribe收集一些Log，然后用ETL去处理数据。存储层我们针对不同场景采用了很多方案，包括HDFS、HBase和KUDU等等。HBase是小米投入比较大的技术。数据管理层，我们用Hue来做业务管理配置，Kerberos是传统的认证体系。数据分析层，我们也尝试了很多工具，例如传统的MapReduce，Spark, Strom，Hive，Impala以及新工具Druid和Elastic search。算法层，主要包括研究机器学习、自然语言、数据挖掘和统计分析的方向。
大数据的应用场景是困扰很多大数据人员的一个问题。大家都知道数据很有用，数据可以指导我们精细化运营，那么数据怎么变现呢?其实是一个非常难的问题，我自己总结了一下，大数据的直接变现场景有两个比较明确，一个是广告营销方面，包括精准投放，广告效果的跟踪。第二个就是互联网金融，互联网金融有很多泛征信的问题，所以很多金融服务愿意掏钱去买有价值的数据。其他方面只要是扶持业务精细化运营和正常发展，比如说防黄牛和图片分析处理的算法。
小米的技术应用场景有很多，我们有一个开放平台，提供类似友盟的统计服务。另外我们内部有一个实时分析系统，帮助我们查看手机销量、日活以及哪个地方的手机bug比较多。
实时数据分析包括数据收集、数据处理、数据建模、数据分析、数据可视化多个部分。其中数据分析也分好几个层次，最底下的一层叫做响应型分析，主要是收集数据，安排一定规格做报表，是比较基础的处理方法。第二个层次叫诊断型分析，主要是做竞品分析和趋势分析。第三个层次是数据分析很重要的一点，战略分析，包括制作战略方向、预测模型。有很多公司在做战略分析方面的工作，著名的有麦肯锡7S模型、波士顿矩阵分析图。最后一个层次叫做预测型分析，预测型分析可能是下一代数据分析的顶尖层次，很多时候是需要人工智能给我们一些真正的建议。我认为数据分析下一个比较热门的地方，就是预测型数据分析，现在的数据分析基本都是反映现状，很难给企业一些建设性意见，帮助企业继续发展。
我把大数据分析工具分为开源方案和商业方案两类。大规模实时数据分析的商业项目有HP vertica，Oracle Exadata、Teradata。Vertica是一个挺不错的工具，Facebook也在使用 Vertica解决方案来做商业分析，大家都知道Facebook本身就是一个很强的互联网公司，他也在釆用 vertica解决方案，就说明Vertica的数据处理量非常大，部署相对也比较简单，关键是速度快，兼容各种SQL查询工具。Exadata是Oralce和SUN合并以后，推出了软硬件一体机的服务器，效果非常好，它的响应速度非常快、可用性非常高，Oracle Exadata可以应用自如的在线处理TB级别的数据。
开源方案其实有2类工具，一类是MOLAP多维数据分析工具，包括Pinot、DRUID、ES、Kylin。另外一类是基于关系型数据库的ROLAP，这类工具大多是基于传统型数据库的解决方案，支持的数据规模比较小，数据处理的灵活性较低。
数据分析工具很多也很杂乱，我们应该怎么挑选这些工具呢?其实这些工具在CAP理论里都有自己的定位，这里有几个指标可供大家在挑选数据分析工具的时候参考一下。第一个是数据量处理分析的能力，第二是能够提供多少并发度，第三是实时性的能力以及总体的成本和分析系统的效率。
小米统计的数据平台包括了很多技术，我们有个入口层可以从终端直接把数据打到服务器。接入层使用LVS/NGIX，对于HTTPS，我们采用专用的硬件加大服务器吞吐量，Analytics Server上的Scribe Log把数据传到HDFS上，同时把同样的数据打印一份到Kafka里，kafka做分布式处理，然后MapReduce和Spark做一些批处理和实时处理。最后落盘的时候，我们会选择不同的落盘方式，落到ES上的直接接Kafka，数据比较稳定的，量小一些的，有结构的，(例如一些元数据和系统统计数据，会落到MySQL，在线的大量应用数据落地HBase里，数据量比较大且经常需要实时查询的会落到DRUID里。前端的服务大概分为两类，一类是运营，对每个产品进行精细化运营，另一类是洞察，老板或者管理者通过这个系统去查看一些核心指标。
我们在内部使用比较多的NoSQL是HBase，它是比较好数据库，比MySQL的存储容量大很多，基本上可以到P量级，且访问速度非常快。
我们在HBase的使用过程中也不断做了很多改进，比如我们提供名字服务，很多HBase可以通过名字去访问Cluster;HBase天生是不支持索引的，它只用key去找value，知道key才可能知道value，我们在内部实现了一个二级索引;salted table，在插入数据的时候，如果key比较接近，可能会落在一起，导致整个系统不平衡。Salted Table就是给它们加个随机数，让它们在落盘的时候更加平均;HBase以前不是强类型的，我们会在API加强类型的检查，让操作更规范一些。
除此之外，我们还对HBase在小米上的使用做了一些改进：单机多实例，减少Heap大小;BucketCache(Heap+Offheap);Compaction限速;Read/Write Quota限制;table/CF粒度的Replication限速;在线更新集群配置;新的HLog写模型;根据业务类型选择存储介质。
我们以前有很多数据是在MySQL中，那么如何实现从MySQL平滑迁移到HBase?
第一步是双写MySQL和HBase ，把所有最新的数据都放在两个数据库里，第二步就是把MySQL数据全部嵌入到HBase里面，这样理论上它们是有一样的数据。第三步就是双读，验证数据是否一致，如果不一致则需继续读取，直到数据完全一致，最后灰度返回HBase结果，完成整个迁移。
下面我们对比一下几种MOLAP的分析工具。
DRUID是采用JAVA开发语言的实时数据分析工具，是在2011年发布的，当时创始这个工具的公司叫MetaMarkets。MetaMarkets是一个互联网广告的分析公司，因为互联网广告里有大量的数据，所以它就开发了这样一个工具来做实时分析，它的特点是实时聚合，目前很多互联网公司都在使用，包括雅虎、小米、阿里，网易，新浪等等。
Pinot是去年11月份LinkedIn开源的实时分析软件，它跟DRUID都是JAVA语言开发的，输入输出都是json。LinkedIn在开源软件领域非常有名气，因为当时它把Kafka开源出来了。
Kylin以前是eBay的一个项目，去年eBay将它开源出来，它支持标准的OLAP/JDBC协议，并且和一些标准数据库连接。它的处理跟实时聚合可能有点不一样，Pinot的进程是把进来的数据变成列存储，简化存储，所以聚合会比较快。而Kylin更多的是做一些预处理、cache。
DRUID 支持很多功能，查询性能也比较好。DRUID是为OLAP工作流的探索性分析而构建。它支持各种filter、aggregator和查询类型，并为添加新功能提供了一个框架。现有的DRUID部署每天处理数十亿事件和TB级数据。
DRUID的架构比较经典，当查询语句来了之后，它会把请求发给两个节点，其中一个节点是Real-time，该节点主要存储最新的数据，另外一个是Historical节点，主要存储历史数据。
我们的广告系统里是这样应用DRUID的：在广告的前端有展现和点击过来时，我们有两条线可以走。一条线是通过Kafka直接到DRUID做聚合，然后再做展现。这是一条实时线，延时大概是1分钟左右。还有一条是可追溯的线，把log放到HDFS里，我们每天会有脚本去HDFS中拷贝存储，然后到DRUID里面去做矫正，最后会把这里面的结果和DRUID里面的数据重新挂一下。我们认为这些持久化数据是可以重跑的，所以我们是十分信任这条线上的数据。
Pinot是LinkedIn的工具，是分布式的实时OLAP数据分析平台，现在主要应用于LinkedIn内部，大概有50多个场景，比如“谁看了我的Profile”、“广告创建，跟踪”、“内部数据分析BI等”。据最新数据表明，Pinot的规模不到一千个节点，数据量不算太大，但是场景很多。它的SQL-Like查询不是标准的SQL而是提供一个类似SQL的工具，支持多种数据源，目前也在开发UDF。
Pinot的架构也是比较经典Lambda架构，查询来了以后，它主要查看两个节点,一个是历史节点，还有一个是realtime节点，中间协调采用的是Apache Helix，Apache Helix在调度能力和cluster管理能力方面要比DRUID好一些。Pinot在对SQL查询的支持方面花了很多力气，它的输入对象是类SQL，容易和传统的数据工具集成。
Kylin大家都知道是eBay开源的一个分析引擎，它提供了标准的SQL查询、提供了BI工具的集成，提供了完美的管理界面、任务监控、增量更新。
Kylin除了支持标准SQL查询，还支持Restful API查询，它会把查询Query记录下来，来自Hadoop的元数据会调度以前任务，把数据发到Query里。这样架构在一些预定义好的场景和数据下的执行速度是非常快的，比较适合每天的报表。如果业务有了很好的格式化工具或者报表以后，你只需要把数据源替换一下。以前，这部分查询功能可能需要从MySQL、SQL Server迁移到HBase接口。
我们也利用Kylin尝试过以下场景，例如API请求分析、广告返回类型的分析。我们发现它在响应时间和误差率方面的表现也不错。
KUDO是去年十月份开源的项目，小米也参与其中。KUDO最早是Cloudera做的项目，大家都知道Cloudera是一家非常棒的分布式Hadoop存储的技术公司。我们知道存储在开源方面有两个方案，一个是Hadoop HDFS，另一个是HBase。Hadoop HDFS的特点是批处理能力特别强，但是响应时间慢。HBase特点是小吞吐，低延时，简单的查询是可以，大批量的数据可能会有些挑战。KUDO其实是介于两者之间，无论响应时间方面还是数据处理量方面都是介乎两者之间。目前小米主要应用在服务质量监控和问题排查。
我们以前的数据处理方法是这样的：从数据源获取到数据以后，我们通过Hive和MapReduce Spark写到HDFS里面，将它变成列存储，用Impala工具查询。
但是现在我们应用了一个全新的模式，数据传到Kafka里去查，然后Storm传到KUDO里，最后采用两条路径陆续查，一条路径是Impala查询，另一条是直接查询。我们发现大部分的分析查询场景，都能满足我们的预期。
Elasic Search的核心引擎是Lucene，是一款实时分布式搜索引擎和分析引擎，支持全文检索，结构化搜索和分析。小米部分应用也是将log进行索引来做分析，主要应用在广告分析和查询方面。
数据可视化方面我们主要用一些的标准的开源工具，包括 Meteorite Saiku、Microsoft Power BI、Excel、Baidu eChart。
数据分析和数据处理中有一个概念叫数据隐私，它最早是1890年提出来的，2012年，欧盟颁布了一项的法律叫做《用户保护条约》，这个条约里规定了很多名词条例，2016年4月份，欧盟颁布了一个效力更强的条约，《欧盟通用数据保护条约》。该条约规定每个公司必须有一个CDO，禁止搜集个人特别信息，包括政治观点、性取向，保护儿童数据等等。在数据隐私方面，欧盟走的比较靠前。而在国内的话，我们还是在参考民法通则等一些老旧的方法。
在互联网里最重要的隐私数据叫PII，PII代表个人标识数据，这些信息能够关联到个体本身，比如说你的手机号、你的身份证号都能关联到你。
我认为大数据分析一定要以业务为基础，没有业务支持的大数据分析都是耍流氓，一定很难有好的收获，大数据分析一定要找到业务做落地点。
技术选型的指标不如想象中的重要，只要选用的技术用的精妙即可。举个例子，小米要在服务器中存储一些用户之间的消息信息，有些用户可能会查询消息，但查询的概率非常非常小，我们当时有两个选项，一个选项是使用Elasic Search，第二个就直接用HBase，如果用ElasicSearch会引入新的很多麻烦，包括基础的部署、安全等方面，所以我们就跟其他内容一样都放到HBase里面去做一些简单的查询，这样可以更好地保护安全。
在实时分析的时候，维度是一个永远的痛。
我们希望大家在做数据分析处理的时候，要像保护你的眼睛一样保护用户的隐私。
数据分析是挺难的一件事情，大家既然走上这个道路，我希望大家不忘初心，方得始终!特别是你想从业务中洞察出一些信息，它不仅需要你的技术牛逼，而且还需要数据的敏感性，能够发现自己的数据问题。数据分析的未来看似光明，实则道阻且长。