如何在Windows 7系统下安装Ubuntu-Kylin 16.04 LTS构成双系统

一，划分磁盘分区已安装Windows7旗舰版。在磁盘管理里面将D盘的100G压缩出40G（计算机-右击-管理-存储-磁盘管理）的空间给Ubuntu。ubuntu本身大概需要3G的空间，大家可以根据自己磁盘空间的大小合理安排分区。二，设置启动项1、下载最新版本的Grub4DOS，下载并解压缩后将目录中的grldr,grldrmbr，grubexe三个文件复制到C盘根目录下2、在下载好的Ubuntu1004LTS系统iso文件中，casper文件夹目录下，找到vmlinuz、initrdlz解压，并复制到C盘根目录下。3、C盘根目录下建立menulst文件，内容为：titleInstallUbunturoot(hd0,0)kernel(hd0,0)/vmlinuzboot=casperiso-scan/filename=/ubuntuisoroquietsplashlocale=zh_CNUTF-8initrd(hd0,0)/initrdlz4、在C盘根目录新建一个文件命名为bootini。内容如下：[bootloader][operatingsystems]c:\grldrmbr="ubuntu"5、将下载的Ubuntu1004LTS系统的iso文件复制到C盘根目录。三，硬盘安装Ubuntu重启机器。在启动项选择ubuntu进入Ubuntu桌面。打开终端，输入代码:sudoumount-l/isodevice这一命令取消掉对光盘所在驱动器的挂载，否则分区界面找不到分区。双击安装Ubuntu，根据提示进行安装即可。这里介绍一下安装过程中涉及到的分区问题:选择“手动”"使用最大的连续空间，点击“前进”开始安装，一直“下一步”直到安装完毕四，修复Windows7启动项重新启动ubuntu之后，结果发现选择windows7的启动项，又进入到Ubuntu的安装界面。下面来说明如何修复，进人Ubuntu系统，打开“应用程序---附件--终端”，命令如下sudogedit/etc/default/grub修改GRUB_TIMEOUT="10"然后在终端中输入sudoupdate-grubupdate命令会自动找到windows7启动项。并且自动更新/boot/grub/grubcfg文件。进入“位置---计算机---win7系统盘“将安装Ubuntu系统时复制到C盘的那些文件(vmlinuz，initrdlz，grldr，grldrmbr，grubexe，menulst，bootini，ubuntuiso)全部移到回收站。特别是ISO文件，如果不删除，重启进入win7后，又将进入Ubuntu的安装界面。五，升级更新Ubuntu安装Ubuntu后，首先配置软件源，服务器选”中国的服务器“，再更新语言包，安装插件，安装后你会发现在win7里你看不见Ubuntu所用的磁盘，而在Ubuntu里你会看到电脑磁盘所有的分区！

银河麒麟是由国防科技大学、中软公司、联想公司、浪潮集团和民族恒星公司合作研制的闭源服务器操作系统。此操作系统是863计划重大攻关科研项目，目标是打破国外操作系统的垄断，研发一套中国自主知识产权的服务器操作系统。

涉嫌造假:在2006年4月27日网友Dancefire的一篇技术分析文章中指出，通过对麒麟操作系统进行反汇编，麒麟操作系统与美国开放源代码的FreeBSD操作系统53版本相似度竟然在90%以上。更多的证据指出，麒麟操作系统仅仅是对开源的FreeBSD进行了一定的修改，根本不是新闻媒体所说的“中国独立研发成功”和“拥有完全自主版权的内核”。

开放麒麟和银河麒麟的主要区别在于背景和目标。开放麒麟是由国家工业信息安全发展研究中心等单位联合成立的，而银河麒麟是由国防科技大学研制的。两者在开源操作系统领域都有一定的地位，但目标有所不同。开放麒麟致力于打造具有自主创新技术的开源桌面操作系统，而银河麒麟的目标是打破国外操作系统的垄断，研发一套中国自主知识产权的服务器操作系统。

华为的产品线可以说是非常丰富，进入笔记本电脑市场也有好几年了，但是一直没有进入台式电脑领域。不过，这种情况可能很快就会改变，因为一份新的报告显示，华为商场将会上架一款搭载鲲鹏920的台式电脑。

此前有报道称华为推出了面向专业人士的工作站PC，将会搭载鲲鹏920处理器，与英特尔工作站竞争。自那以后，其他报道也浮出了水面，称该公司也在考虑进入消费者个人电脑市场。由于冠状病毒的流行，在家办公变得越来越普遍，进而个人电脑和笔记本电脑的整体销量有所增长。

一位微博博主最近也注意到多个即将上市的台式电脑，型号为“黄河K680 G1”。目前这台PC的具体还没有，某些规格已经透露了。台式机配备了鲲鹏920 八核处理器，配备8GB DDR4 2666MHz内存和256GB 固态硬盘。它还配备了AMD Radeon R7 430显卡，配有DVD光驱、键盘和鼠标。标配180W的电源，运行Kylin操作系统。

鲲鹏920处理器是去年初发布的，采用7nm工艺，基于2019年推出的ARM架构，最多64个核心，最高频率26GHz，并支持PCIe 40、八通道DDR4内存，号称同类产品业界性能最高，可用于服务器、数据中心和桌面市场，以及面向企业客户的台式机产品。

就目前的规格来看，看起来并不是针对工作站的高性能电脑，很可能是针对的日常办公需求，而不是大型 游戏 或内容创作。

用什么linux版本的系统最好？

发行版:UbuntuCentOSDebianFedoraOpenSuseFreeBSDArchLinuxLinuxMintDeepinoracleLinuxKylinDebian非常适合用于服务器Gentoo非常适合学习LinuxUbuntu新手最喜欢的版本RHEL系统管理员必备CentOS我的最爱

linux好用的版本？

1、RedHat版本，55和60为最新，也是目前培训、学习、应用方面，知名度最高的Linux发行版本，对硬件兼容性来说也是非常不错的，版本更新速度很快，对新硬件和新技术支持较好。

2、Debian版本50和60最新，在社区版的Linux系统算是较好的，文档和资料脚都，尤其是英文的。不过在国内市场占有率也是具有一定局限性，关键是上手较难，但是在所有的Linux发行版本之中，这个版本相对于是比较自由的版本。

linux哪个版本好用？

Linux系统版本众多，不同版本用途不同，情况不同选择有所差异：

1、运维和分布式开发可以选择红帽版本：红帽版本主要分为了RHEL和centos，新手学习的时候如果不想太过于折腾，可以直接使用conetos，和RHEL在操作使用层面上完全没有区别的，只是来源有所区分，分为了开源免费和企业收费两种。国内运维所采用的教材一般都是redhat，所以都是基于RHEL的。细分版本的情况下，初学者可以安装一个带有桌面的centots6或者7,都可以。

2、具有生产力的工具可以选择ubuntu版本：对于生产力版本最大的要求就是稳定了，ubuntu就是非常不错的选择，死机崩溃几乎可以避免了。还可以选择fedora版本，也是非常不错的，也具有非常不错的稳定性，不过整体来说还是ubuntu，各种生产力软件都适用于它，不用浪费时间找软件。而且还拥有海量的知识库，互联网上可以找到关于ubuntu的一切问题解决方案，非常适合初学者学习。

3、日常使用可以选择deepin、manjaro版本：相对于来说更加省心一些。deepin对于从Windows迁移过来的用户是非常不错的选择，高度兼容Windows风格和操作习惯的系统，可以适配Windows下的软件，可以让初学者快速融入其中。manjaro版本，拥有所有Linux桌面版本中最大的软件仓库，最多适配的桌面环境、最简单易用的应用管理方式，如果作为家用的情况下，是非常适合的选择。

linux十大最佳系统？

1Ubuntu。

Ubuntu是基于Debian的开源Linux操作系统。Ubuntu非常流行，许多其他发行版都是从它衍生出来的。Ubuntu服务器对于构建高性能、高可伸缩性、灵活和安全的企业数据中心非常有效。

2RedHatEnterpriseLinux（RHEL）

RedHatEnterpriseLinux（RHEL），是RedHat开发的用于商业用途的开源Linux发行版。它基于Fedora，RHEL上提供的大量软件都是首先在Fedora上开发和测试的。

3、中兴新支点服务器操作系统（CGSL）

中兴新支点服务器操作系统是国内的服务器系统，由中兴旗下子公司中兴新支点研发，新支点操作系统产品还包括工业操作系统、桌面操作系统等。新支点服务器操作系统是一款具有高可用性、高性能以及良好的安全性、可管理性等特征的电信级操作系统。

4、SUSELinuxEnterpriseServer

SUSELinuxEnterpriseServer是由SUSE构建的开源，稳定且安全的服务器平台。它旨在为物理、虚拟和基于云的服务器提供支持。它非常适合支持可视化和容器的云解决方案。

5、CentOS（社区操作系统）Linux服务器

CentOS是RedHatEnterpriseLinux（RHEL）的稳定且开源的衍生产品，所以在操作上与RHEL兼容。另外CentOS是免费的，因此如果您想使用RHEL又不想通过订阅而支付大量的费用，那么您可以尝试一下。CentOS拥有社区支持，因此您还是可以获得其他社区成员和用户的支持。但毋庸置疑的是，付费版产品的支持和服务会更加周到，有问题也能得到更及时的解决。

linux系统哪个版本最好？

个人比较推荐Debian这个发行版本。

DebianGNU/Linux于1993年首次公布，至今已经有近30年历史了。

当然其他版本比如openSUSE，Slackware，ArchLinux，Ubuntu也是很不错的Linux发行版本。

1、中标麒麟操作系统：中标麒麟Linux桌面软件是上海中标软件有限公司发布的面向桌面应用的操作系统产品。中标麒麟开发了与windows操作系统非常接近的图形化桌面。习惯使用windows操作系统的用户，只需做简单的适应性学习即可在该图形化桌面下完成软件安装、文档编辑、浏览网页、播放视频音频等操作。

优点：为windows用户迁移到该操作系统提供了方便，使用户能够迅速掌握新系统，可节省大量人员培训成本。

缺点：与其他软件兼容性差，响应速度慢。与服务器兼容欠佳，系统运行时，高级别进程在执行低级别文件后会降低级别，而低完整级进程不可能通过执行文件提升自己的权限。

2、银河麒麟操作系统：银河麒麟（Kylin）是由国防科技大学研制的开源服务器操作系统。此操作系统是863计划重大攻关科研项目，目标是打破国外操作系统的垄断，研发一套中国自主知识产权的服务器操作系统。

优点：银河麒麟操作系统具有性能领先、生态丰富、体验提升、云端赋能、融入移动、内生安全等优点。

缺点：在其稳定性、性能和标准化这方面，还有进一步提升空间。

3、云针操作系统（CloudNeedle OS）：分为服务器操作系统、桌面操作系统、移动操作系统、物联网操作系统四个版本，该操作系统适用于各种智能终端，是一款能够把各大操作系统的软硬件生态完全兼容和直容的新型革新纯国产无国界操作系统。其研发公司云针科技系列产品主要包括以云针操作系统为核心的软件产品，与合作开发生产嵌入该操作系统的服务器、消费终端（电脑、电视、平板、手机、智慧盒）、物联网终端等硬件产品，及虚拟化应用服务，可见生态集群极其丰富。

优点：一个内核就将服务器终端到消费终端、物联网终端全面打通的全新操作系统；从办公到娱乐，同时兼容直容安卓应用和windows应用，独具特色的丰富应用生态，相应速度更快，更安全可靠，并革新了美国软件生态的下载、卸载、安装等复杂的操作过程，更加高效，便捷。同时，完全直容和兼容目前国际国内市场上大部分算力终端设备（含芯片）及软件，完美打通“云－边－端”，真正实现了生态、生活、生产算力的全方位归集与精准调度运营。

缺点：由于是初上市的全新纯国产无国界操作系统，还不被大多数人所熟知，需进一步打进消费者市场，让更多人发现。

4、深度Linux(Deepin)Deepin：原名Linux Deepin，于2014年4月更名为Deepin，常被称为“深度 Linux”，是一个致力于为全球用户提供美观易用，安全可靠的Linux 发行版。它不仅仅对最优秀的开源产品进行集成和配置，还开发了基于 HTML5 技术的全新桌面环境、系统设置中心、以及音乐播放器，视频播放器，软件中心等一系列面向日常使用的应用软件。

优点：Deepin 简单易用，桌面美观，能够很好的代替Windows系统进行工作与娱乐，深受用户好评。

缺点：性能优化不足，软件难兼容，应用生态不健全等一系列问题仍旧需要不断完善。

5、UOS统一操作系统：统一操作系统筹备组是由多家国内操作系统核心企业自愿发起，成员包括中兴新支点、中国电子集团(CEC)、武汉深之度科技有限公司、南京诚迈科技。2019年7月，筹备组联合技术研发团队正式成立，并在广州、武汉、南京、北京等地组织了数百人的研发团队开始研发工作。

优点：UOS采用开源共创社区研发模式，鼓励上下游产业链厂商和技术人员参与研发工作贡献代码，共同打造符合行业用户需求的安全、易用、稳定的操作系统产品。今年内将发布UOS的第一个版本，实现不同的CPU平台上统一发布渠道，统一应用商店、统一交互体验、统一内核版本、统一文档和开发接口。

缺点：但对于普通用户来说，缺点也很明显，缺少日常软件、游戏的生态环境极大地阻碍了系统在消费市场的发展。

6、华为鸿蒙系统（HarmonyOS）：鸿蒙OS是华为公司开发的一款基于微内核、耗时10年、4000多名研发人员投入开发、面向5G物联网、面向全场景的分布式操作系统。鸿蒙的英文名是HarmonyOS，意为和谐。 基于AOSP的一款操作系统，华为基于安卓生态开发的应用能够平稳迁移到鸿蒙OS上做好衔接——将相关系统及应用迁移到鸿蒙OS上，差不多两天就可以完成迁移及部署。

优点：这个新的操作系统将打通手机、电脑、平板、电视，并且该系统是面向下一代技术而设计的，能兼容全部安卓应用的所有Web应用。若安卓应用重新编译，在鸿蒙OS上，运行性能提升超过60%。鸿蒙OS架构中的内核会把之前的Linux内核、鸿蒙OS微内核与LiteOS合并为一个鸿蒙OS微内核。创造一个超级虚拟终端互联的世界，将人、设备、场景有机联系在一起。同时由于鸿蒙系统微内核的代码量只有Linux宏内核的千分之一，其受攻击几率也大幅降低。

缺点：虽然鸿蒙系统可以兼容安卓应用，基于AOSP，但不是真正完全适配的软件，使用起来总是有些不稳定，其系统框架下的APP应用数量太少，局限性强，使其饱受诟病，鸿蒙OS基于Android系统的常用应用，也同时受谷歌的框架服务GMS制约，出国使用不了，导致核心技术始终受制于人的局面。

美团各业务线存在大量的OLAP分析场景，需要基于Hadoop数十亿级别的数据进行分析，直接响应分析师和城市BD等数千人的交互式访问请求，对OLAP服务的扩展性、稳定性、数据精确性和性能均有很高要求。本文主要介绍美团的具体OLAP需求，如何将Kylin应用到实际场景中，以及目前的使用方式和现状。同时也将Kylin和其它系统（如Presto、Druid等）进行了对比，阐述了Kylin的独特优势。

作为公司的平台部门，需要给各个业务线提供平台的服务，那么如何建设一个满足各种需求的公司平台级OLAP分析服务呢。首先，一个开源项目在公司真正落地会遇到很多障碍，这主要是由各个业务线不同的数据特点和业务特点决定的，所以本文会介绍一下美团的数据场景有什么特点；其次，针对这些数据特点，尤其是和Kylin设计初衷不太相符的部分，有什么样的解决方案；第三，目前OLAP领域还没有所谓事实上的标准，很多引擎都可以做类似事情，比如普通的MPP，Kylin，或者ES等。这些系统之间的对比情况如何，应该如何选择，我们也有部分测试数据可以分享；最后，简单讨论一下未来准备在Kylin上做的工作。

1、美团的数据场景特点

第一个特点是数据规模和模型特点。一方面从数据规模上来讲，事实表一般在1亿到10亿量级，同时还有千万量级的维表，也就是超高基数的维表。另一方面，数据模型是一开始遇到的最大困难。因为Kylin最初的设计是基于一个星形模型的，但很不幸由于各种原因，很多数据都是雪花的模型，还有其它的模型，比如所谓“星座”模型，也就是中间是两张或者三张事实表，周围关联了其它很多维表。业务逻辑决定了这些数据的关联方式非常复杂，根本无法用经典标准的理论来解释。

第二个是维度。维度最理想的情况是固定的，每天变化的只是事实表。但实际上维度经常会变，这可能和行业特点有关，比如组织架构，相关的维度数据可能每天都会变化。除此之外还可能要用今天的维度去关联所有的历史数据，因此要重刷历史数据，相应的开销也比较大。

第三个是数据回溯的问题。比如发现数据生成有问题，或者上游出错了，此时就需要重跑数据。这也是和经典理论模型有区别的。

从维度的角度来看，一般维度的个数在5-20个之间，相对来说还是比较适合用Kylin的。另一个特点是一般都会有一个日期维度，有可能是当天，也有可能是一个星期，一个月，或者任意一个时间段。另外也会有较多的层次维度，比如组织架构从最上面的大区一直到下面的蜂窝，就是一个典型的层次维度。

从指标的角度来讲，一般情况下指标个数在50个以内，相对来说Kylin在指标上的限制并没有那么严格，都能满足需求。其中有比较多的表达式指标，在Kylin里面聚合函数的参数只能是单独的一列，像sum(if…)这种就不能支持，因此需要一些特别的解决方法。另外一个非常重要的问题是数据的精确性，目前在OLAP领域，各个系统都是用hyperloglog等近似算法做去重计数，这主要是出于开销上的考虑，但我们的业务场景要求数据必须是精确的。因此这也是要重点解决的问题。

在查询上也有比较高的要求。因为平台的查询服务可能直接向城市BD开放，每次会有几十、上百万次的访问，所以稳定性是首先要保证的。第二要求有很高的性能。因为用Kylin主要是为了实现交互式的分析，让使用者能够很快拿到结果，所以需要秒级响应。

另外经常会有人问到，Kylin有没有可视化的前端，在我们内部更多是由业务方来做，因为原来本身就有这样的系统，以前接的是MySQL等其它的数据源，现在可以直接使用Kylin的JDBC driver对接起来。

以上是美团在OLAP查询方面的一些特点。在用Kylin之前，实际上有一些方案，但效果并不理想。比如用Hive直接去查，这种情况下，第一个是慢，第二会消耗计算集群的资源。尤其每个月第一天，大家都要出月报，跑的SQL非常多，全提到集群上去，并发度限制导致跑的比平时更慢。我们原来也做过预聚合的尝试，这个思路跟Kylin很像，只不过是自己做这个事，用Hive先把所有的维度算出来，然后导入MySQL或者HBase。但是这个方案并没有像Kylin这么好的模型定义抽象，也没有从配置到执行，预计算，查询这样整体的框架。现在通过使用Kylin实现了低成本的解决这些问题。

2、接入Apache Kylin的解决方案

针对上述的问题，经过大量的尝试和验证，目前主要的解决方案有以下几点。

最重要的第一点，就是采用宽表。所有非标准星型的数据模型，都可以通过预处理先拉平，做成一个宽表来解决。只要能根据业务逻辑把这些表关联起来，生成一张宽表，然后再基于这张表在Kylin里做数据的聚合就可以了。宽表不只能解决数据模型的问题，还能解决维度变化、或者超高基数的维度等问题。

第二点是表达式指标的问题，也可以通过提前处理解决。把表达式单独转成一列，再基于这列做聚合就可以了。实际上宽表和表达式变换的处理可以用hive的view，也可以生成物理表。

第三个是精确去重的问题，目前的方案是基于Bitmap。由于数据类型的限制，目前只支持int类型，其它包括long、string等类型还不支持。因为需要把每个值都能映射到Bitmap里,如果是long的话开销太大。如果用哈希的话就会冲突，造成结果不准确。另外Bitmap本身开销也是比较大的，尤其跑预计算的时候，如果算出来的基数很大，对应的数据结构就是几十兆，内存会有OOM的风险。这些问题后面我们也会想一些办法解决，也欢迎在社区里一起讨论。（补充说明：目前已在153版本中实现了全类型精确去重计数的支持。）

从整个系统的部署方式上来说，目前Server采用了分离部署的方式。Kylin Server本质上就是一个客户端，并不需要太多资源，一般情况下使用虚拟机就能够满足需求。

实际的部署情况可以看这张图，左下角的是hadoop主集群，用于执行每天所有hadoop作业。中间最重要的是Kylin01和02这两个server，是用于线上环境的serve。其中kylin01是生产环境，这个环境一方面要负责从主机群上跑计算，把数据导到HBase，另外也要响应前端的请求，从HBase里读数据。如果想新增一个Cube的话，需要在kylin02上操作，也就是预上线环境。所有业务方人员的cube数据模型定义都是在kylin02上做，没有问题后由管理员切到kylin01上。

这样做的一个好处是kylin01作为一个线上服务能保证稳定性，甚至权限控制能更严格一些；第二，预上线环境下开发完成后，管理员可以在投入生产前进行一次review，保证cube的效率。

右上角是另外的调度系统。整个数据仓库的数据生产都是通过这个调度系统来调度的，其中的任务类型很多，Kylin的cube build任务也是作为其中的一种类型。在上游的数据就绪以后，根据配置的依赖关系，自动触发Cube建立的过程。

左上角这边还有一个完全独立的线下测试集群，这个集群是完全开放的，主要是给用户做一些最开始的可行性调研或者评估的工作，但同时也不保证稳定性。

一个开源的系统从社区拿回来，到真正的落地，再到上生产，这个过程相对还是比较长的，这里并没有太多的技术问题，更多的是一些流程上的经验。就是如何在各个阶段给业务方提供更好的服务，使得接入Kylin的过程更顺畅，沟通成本更低。整个过程主要分为四个阶段。

第一个阶段是方案选型，业务方根据业务需求，选择一些方案进行调研。我们在这个阶段提供了需求的Checklist，从数据模型，维度各个方面列出来比较详细的点，可以让业务方自己对照，确定需求是不是能够被满足。

在确定Kylin能满足需求的基础上，接下来是第二步，线下探查，也就是线下评估或者测试。我们提供了非常详细的接入文档，以及线下测试的环境。第三步是线上开发，我们也有一些文档支持，基于抽象出来的场景，每个场景怎么配置Cube，或者做哪些预处理，如何优化等，能够给业务方一个指导性的意见。

最后是开发完成后的切表上线。这个过程目前还是由管理员来操作，一方面是为了避免误操作或者滥操作，另一方面也会对cube进行review，帮助进行优化。

3、主流OLAP系统对比分析

通过和其它同学交流，有一个感觉就是大家都觉得Kylin还不错，但并不是特别有信心，或者不知道非要用它的理由是什么，或者它和其它系统的对比是什么样的？这里也有部分测试结果可以和大家分享。

整个测试基于SSB的数据集，也是完全开源的，实际上是专门用于星型模型OLAP场景下的测试。整个测试数据集是非常标准的五张表，可以配置一些参数决定生成的数据集规模，然后在不同的规模下做不同查询场景的测试。现在已经完成的测试的系统包括：Presto，Kylin13，Kylin15和Druid。数据规模包含千万、亿、十亿三种规模；维度个数为30个；指标个数为50个。典型的测试场景包括：上卷、下钻，和常用的聚合函数。

这里挑选了典型的五个查询场景：一个事实表的过滤和聚合；五张表全关联之后的查询；两个Count Dstinct指标和两个Sum指标；后面两个查询包含8~10个的维度过滤。

这张图是千万规模下的一个测试结果，包括了四个系统。我们在用Kylin或者其它系统之前没有专门用于OLAP分析的引擎，只能用通用的。Presto是其中表现非常好的引擎，但是在OLAP这种特定的场景下，可以看到不管跟Kylin还是Druid相比差的都比较多，所以前两个测试包含了Presto结果，后面就没有包含了。

这里比较有趣的现象是在第三个查询，Kylin15反而比Kylin13要慢一些。这个地方我们还没有搞清楚是什么原因，后面会详细的看一下。当然这个也可以证明数据没有修改过，是真实的测试数据。

从后面的两个查询上可以看到，在千万规模的级别，和Druid还是有比较大的差距。这主要和它们的实现模式相关，因为Druid会把所有的数据预处理完以后都加载到内存里，在做一些小数据量聚合的时候，可以达到非常快的速度；但是Kylin要到HBase上读，相对来说它的性能要差一些，但也完全能满足需求。

在亿级的规模上情况又有了变化，还是看后面两个查询，Kylin13基本上是一个线性的增长，这个数据已经变得比较难看了，这是由于Kylin13在扫描HBase的时候是串行方式，但是Kylin15反而会有更好的表现，这是因为Kylin15引入了HBase并行Scan，大大降低了扫描的时间。Kylin15的数据会shard到不同的region上，在千万量级上数据量还比较小，没有明显的体现，但是上亿以后，随着数据量上升，region也变多了，反而能把并发度提上去。所以在这里可以看到Kylin15表现会更好。这里也可以看出，在数据量成数量级上升后，Kylin表现的更加稳定，在不同规模数据集上依然可以保持不错的查询性能。而Druid随着数据量的增长性能损失也成倍增长。

刚才是在性能方面做的一些分析，其实对于一个系统来说，性能只是一个方面，除此之外，我们也会去考量其它方面的情况，主要有以下四点。

第一，功能的完备性。刚才提到我们所有的数据必须是精确的，但是现在基本上没有哪个系统能完全覆盖我们这个需求。比如Druid性能表现确实更好，但是它去重计数没有办法做到精确。

第二，系统的易用性。作为一个平台服务，不仅要把系统用起来，还要维护它，因此要考虑部署和监控的成本。这方面Kylin相对来说也是比较好的。Druid一个集群的角色是非常多的，如果要把这个系统用起来的话，可能光搭这个环境，起这些服务都要很长的时间。这个对于我们做平台来讲，实际上是一个比较痛的事。不管是在部署，还是加监控的时候，成本都是相对比较高的。另外一个查询接口方面，我们最熟悉或者最标准，最好用的当然是标准SQL的接口。ES、Druid这些系统原来都不支持SQL，当然现在也有一些插件，但是在功能的完备性和数据的效率上都不如原生的支持。

第三，数据成本。刚才提到了有些数据需要做一些预处理，比如表的拉平或者表达式列的变换，除此之外还有一些格式的转化，比如有的系统只能读TEXT格式，这样都会带来数据准备的成本。另一方面是数据导入的效率。从数据进入数据仓库到真正能够被查询，这个时间中间有多长。数据存储和服务的时候需要多少机器资源，这个都可以归为数据成本，就是使用这个数据需要付出的成本。

第四，查询灵活性。经常有业务方问到，如果Cube没定义的话怎么办？现在当然查询只能失败。这个说明有的查询模式不是那么固定的，可能突然要查一个数，但以后都不会再查了。实际上在需要预定义的OLAP引擎上，这种需求普遍来讲支持都不是太好。

这张图是各个系统全方位的一个对比。

从查询效率上看，这里表现最不好的就是Presto，表现最好的应该是Druid和Kylin15，两者不相上下。从功能完备性上来讲，确实Presto语法和UDF等等是很完备的，Kylin会稍微差一些，但比Druid好一点。

系统易用性上区别不是太大，这里主要考虑有没有标准的SQL接口或者部署成本高不高，用户上手能不能更快，目前来看Druid接口上确实不够友好，需要去翻它的文档才知道怎么去写查询的语法。

在查询成本上，Presto是最好的，因为几乎不需要做什么特殊的处理，基本上Hive能读的数据Presto也都能读，所以这个成本非常低。Druid和Kylin的成本相对较高，因为都需要提前的预计算，尤其是Kylin如果维度数特别多，而且不做特别优化的话，数据量还是很可观的。

最后从灵活性上来讲， Presto只要SQL写出来怎么查都可以，Druid和Kylin都要做一些预先模型定义的工作。这方面也可以作为大家选型时候的参考。

刚才比较客观的对比了几个系统，接下来再总结一下Kylin的优势。

第一，性能非常稳定。因为Kylin依赖的所有服务，比如Hive、HBase都是非常成熟的，Kylin本身的逻辑并不复杂，所以稳定性有一个很好的保证。目前在我们的生产环境中，稳定性可以保证在9999%以上。同时查询时延也比较理想。我们现在有一个业务线需求，每天查询量在两万次以上，95%的时延低于1秒，99%在3秒以内。基本上能满足我们交互式分析的需求。

第二，对我们特别重要的一点，就是数据的精确性要求。其实现在能做到的只有Kylin，所以说我们也没有什么太多其他的选择。

第三，从易用性上来讲，Kylin也有非常多的特点。首先是外围的服务，不管是Hive还是HBase，只要大家用Hadoop系统的话基本都有了，不需要额外工作。在部署运维和使用成本上来讲，都是比较低的。其次，有一个公共的Web页面来做模型的配置。相比之下Druid现在还是基于配置文件来做。这里就有一个问题，配置文件一般都是平台方或者管理员来管理的，没办法把这个配置系统开放出去，这样在沟通成本和响应效率上都不够理想。Kylin有一个通用的Web Server开放出来，所有用户都可以去测试和定义，只有上线的时候需要管理员再review一下，这样体验就会好很多。

第四，最后一点就是活跃开放的社区和热心的核心开发者团队，社区里讨论非常开放，大家可以提自己的意见及patch，修复bug以及提交新的功能等，包括我们美团团队也贡献了很多特性，比如写入不同的HBase集群等。这里特别要指出的是核心团队都是中国人，这是Apache所有项目里唯一中国人为主的顶级项目，社区非常活跃和热心，有非常多的中国工程师。特别是当你贡献越来越多的时候，社区会邀请成为committer等，包括我自己及团队成员也已经是Apache Kylin的committer。同时也非常高兴看到以韩卿为首的Apache Kylin核心团队在今年初成立的创业公司Kyligence，相信可以为整个项目及社区的发展带来更大的空间和未来。

4、未来工作

在未来工作方面，我们认为Kylin还有一些不理想的方面，我们也会着力去做优化和改进。

第一，精确去重计数。刚才提到只支持Int，接下来有一个方案会支持所有的数据类型，能够扩展大家使用精确去重的场景范围（补充说明：目前该功能已在153版本中实现）。

第二，在查询效率和Build效率上也看到了一些可以优化的部分。比如队列资源拆分，我们所有计算集群的资源都是按照业务线核算成本的，但是现在Kylin本身还不太支持，这个我们也会抓紧去做，相信在很多公司也有类似的需求。还有大结果集和分页。当结果到了上百万的量级时，查询时延会上升到几十秒。同时在查询的时候有可能需要排序并且分页，就是把结果全读出来之后，根据其中的一个指标再order by，这个开销也是比较大的。我们也会想办法进行优化。

最后，Kylin15之后有明细数据和Streaming特性出来，后面也会做这方面的尝试。

5、Q&A

Q1：之前在Build的时候一直提到成本的问题，能给出一个估计值吗，如果一百亿的数据，需要多少时间？

孙业锐：有一个简单数据，大概是两亿行数据，维度的话有十四五个，Build时间不超过两个小时，Build出来的数据是五六百G。

Q2：原始值是多大？

孙业锐：把这个数据抽出来之后，就是只参与Build的数据压缩后只有几个G。

Q3：Kerberos认证失效的问题你们遇到过没有？

孙业锐： Kerberos认证完之后，会在本地临时目录下有一个ticket问题，每天在外部定时刷新一下就可以了，服务是不用停的。

主持人：我补充一下我们为什么选择SQL接口？Kylin解决的是真正的用户面是谁，其实是业务人员和分析人员，他只会SQL，几乎那些人很少说再学个JAVA，所以能给他一个标准的SQL这个是让他上船最快的事情。其实这就是易用性很重要。

刚才看到了Kylin在千万级规模和亿级规模的表现，如果数据规模上到十亿，百亿，千亿的时候，我相信Kylin应该会秒杀所有一切。因为我们现在有另一个案例，生产环境上千亿规模的一张表，可以做到90%查询在18秒以内。另外我觉得非常好的一点，像美团、京东这边贡献了很多patch，其实就是把需求提出来，大家可以一起来做。

作者介绍

孙业锐，美团高级工程师，Apache Kylin Committer。2012年毕业于电子科技大学，曾在奇虎360工作，负责Hadoop平台建设，2015年加入美团。目前主要负责数据生产和查询引擎的改进和优化，专注于分布式计算，OLAP分析等领域，对分布式存储系统亦有丰富经验。