CU访谈录：DTCC讲师徐冬奇分享技术路上的挑战、踩坑、痛苦、成长 【总结分析】

徐冬奇：

来自百度基础架构部大数据团队架构师，擅大数据平台（OLAP分析、用户属性挖掘）、分布式存储等技术，目前关注广告平台。

2014-01-13 09:53 上传
下载附件
(26.99 KB)

以下为访谈的重点总结（point标识）和个人体会（mine标识）

point：

      Hadoop体系是个非常了不起的，围绕它业界建立并不断丰富了它的EcoSystem，从最传统的HDFS、MapReduce，到诸如Hive、Scribe、Zookeeper、HBase等等。我们的大数据工作实际上已经很难离开Hadoop了，在百度你经常会听到工程师说今天要跑个任务，百度的Hadoop集群已经是万级别的规模了，存储、计算、调度百度都研发了新一代的系统，尽管如此，其本源仍然是Hadoop体系。中小规模的公司，如果用到大数据，我建议义无反顾地去加入到Hadoop生态体系的怀抱，搭建一个Hadoop系统并不困难，从学习到配置各类参数搭建好两三天就够了，想要从大数据中查询用Hive；想要出天级报表，最简单的方法就是每天跑个Mapreduce任务或者写个HQL任务灌入到Mysql即可。

     

       数据处理大致可以分成两大类：联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing）。OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。由于两大系统应用领域有区别，侧重点自然也有区别，OLTP更多地侧重于ACID事务处理，ACID是指在可靠数据库管理系统中，事务(transaction)所应该具有的四个特性：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability），要做到这些，技术难度是很大的。而OLAP技术难点在于如何在海量历史数据中给定各个维度毫秒级别快速查询出想要的结果，技术往往涉及预聚集、物化视图、列存储、压缩、查询优化、谓词下推等等，对于OLAP来说，根据应用场景还可再细分，一个是报表系统，它的特点是查询QPS非常高、
7*24小时不停服务、查询往往通过web界面固化，一般面向数十万广告主、网站主的报表就是此类别；另一个就是OLAP分析系统，它的特点是查询QPS并不高，一天几千个查询，也不要求7*24小时服务，主要面向决策分析人员，查询时各个维度可随意组合，上卷、下钻随意进行。一个公司里会用OLAP做分析的分析师并不多，大部分人所使用的报表都是提前设计好的，针对所关注的点提前做了物化视图的优化。

      当然，OLAP与OLTP也有技术共通之处，很多时候我们在优化OLAP时，第一时间就会想OLTP类数据库系统他们怎么做的，是不是可以借鉴，例如谓词下推、索引选择、Partial Aggregation等等。在我们的系统中，我们专门针对OLAP开发了存储引擎，作为Mysql引擎，这样可在Mysql中写SQL来做毫秒级OLAP分析，这也可以看作OLAP与OLTP的碰撞和互补所长。

      做数据挖掘，前提是数据仓库要建设好，数据源质量要保证，由此各类ETL工作非常繁杂。随着移动互联网多屏时代已经到来，操作电脑、玩各种各样的手机app，看智能电视，那么如何将这些数据贯通起来成为非常关键。数据挖掘往往需要涉及数据清洗、特征提取、训练样本、模型训练，这里面其实各类算法差别不会太大，重点在于选取哪些数据，提取哪些特征，样本如何弄准确。 行为数据精准性是个大的工程，首先日志打印得对不对都是问号，各种各样的垃圾充斥其中，日志处理时各种各样的异常都需要去处理，再比如那么多服务器上的日志如何快速准确得收集。

      对新人的建议：我的建议是加入大公司大团队，只有在大数据中浸淫才能不断提升自身大数据知识和技能。之前也面试过人，说对Hadoop熟悉，在学校里跑过两个任务，但离真正的Hadoop工程师还很远，原因就在于没有有挑战的任务需要去解决，很多坑都没有踩过。具备良好素养的工程师都是通过不断踩坑成长起来的。

mine：

      技术的训练需要特定的场所，高级的技术尤是，不断地踩坑填坑，技术便不断被磨砺，这是一个必需的过程。