姒
7月5日，Kyligence融资暨新产品发布会在上海举行。Kyligence 团队宣布正式发布下一代企业级数据仓库产品与解决方案Kyligence Enterprise v3.0，及云端一站式大数据分析解决方案KyligenceCloud v2.0。新版解决方案革命性地实现了自动建模功能，并将在查询提速15倍的同时节省50%存储空间。
“借助Kyligence Enterprise v3.0，此前客户需要花费半年、一年的数据分析周期可以缩减至一两个月甚至更短的时间，使用传统国外数据仓库需要每年投入上亿，使用Kyligence产品后，投入缩减至几百万。在人力上，从40多人缩减至6个人左右。”Kyligence联合创始人兼CEO韩卿在接受投资界（ID：pedaily）采访时介绍道。
Kyligence 联合创始人兼CEO韩卿
Kyligence Enterprise v3.0发布，打造融合、智能数据仓库
作为本次发布会的重头戏之一，Kyligence 联合创始人兼CTO李扬，详细介绍了新版Kyligence Enterprise如何在保持PB级数据集上亚秒级查询响应速度的同时，革命性地实现自动化建模以承载企业日益增长的自动化需求。
对于Kyligence Enterprise3.0的行业定位，韩卿认为，它是一个融合智能的大数据平台，代表未来数据仓库的方向。
在今天数据呈指数级爆炸的时代，绝大部分的数据仓库项目仍然使用人工进行操作，这种原始的基于人工的数据分析方式显然已经远不能满足快速增长的业务需求。
韩卿表示：“下一代的数据仓库，一定是融合的、智能的数据仓库，通过将这些技术应用到数据仓库本身的技术变革中，能为许多产业带来变革。”
投资界了解到，新版Kyligence Enterprise引入了大量的机器学习技术，如自动建模技术可基于分析师的历史查询行为及学习记录，智能化地推荐数据建模，自动化地调优性能，且推荐和加速相关业务分析场景。同时，该产品还支持在企业的本地集群和云端部署在线数据分析服务，满足了企业的全场景分析需求。
在产品架构上，新版Kyligence Enterprise 采用了高性能的融合架构，实现了关键业务的亚秒级查询延迟，也支持海量数据的自主探索；数据源可对接分布式平台Hadoop的多重数据引擎，也可以对接传统的RDBMS；数据种类上，既可以对接实时数据流，也可以进行批处理。
“对比上一代查询引擎，新版Kyligence Enterprise 可实现查询提速15倍的同时节省50%存储空间，而对比市场上的同类查询产品，根据数据仓库典型查询场景测试中查询的完成度与查询的性能比较来看，都具有显著优势。”李扬介绍道，Kyligence Enterprise v3.0具有出色的数据分析能力，它的出现将有效降低企业人力成本，并成倍提升企业生产效率。
聚焦金融、电信、零售和制造4大领域，要成为数据仓库行业NO.1
在产品发布会上，Kyligence宣布完成由斯道资本领投，原有股东红点中国、思科、宽带资本、顺为资本跟投的1500万美元B轮融资，这也是Kyligence2年内的第三轮融资。
对于本轮融资计划，韩卿表示，本轮融资后，公司将主要在三个方面加大投入。其中包括加快产品技术研发；扩大市场和销售团队，以尽快扩张市场认知度；布局国际化发展，目前公司已在美国、欧洲拓展客户，接下来将会尤其在美国进行大规模扩张，真正做到技术出海。
目前，Kyligence旗下开发的产品服务已经获得超30家来自各行各业头部企业的付费支持，包括国泰君安、华为、联通、OPPO、上汽集团、太平洋保险集团、中国银联等企业。
在发布会圆桌论坛上，太平洋保险大数据平台负责人时爱民表示，大数据分析作为面向未来的IT技术服务，对太平洋保险而言早已不是一道选择题，而是一道必答题，太平洋保险之所以选择与使用Kyligence Enterprise，看中的就是Kyligence的技术实力与长期、持续的服务能力。
本轮领投的斯道资本中国风险投资团队合伙人张柏舟也表示：“我们很荣幸能成为Kyligence 的投资方。我们在尽职调查期间收集了广泛的客户意见，Kyligence 突出的能力让我们印象深刻，比如通过数据建模处理和AI 增强技术来预处理海量数据集并将延迟降低至亚秒级，通过整合Tableau、Power BI 甚至Microsoft Excel 等常用简单工具来获取新知，Kyligence 没有局限在简单的分析场景，而是致力于帮助客户快速而轻松地管理、访问和分析海量数据，远远超越了传统解决方案，堪称新一代数据仓库。”
目前，Kyligence商业化已经一一落地。韩卿表示，Kyligence的产品服务未来将主要专注于金融、电信、零售和制造四大领域的应用，因为这四大行业拥有大量的数据，对基于数据底层的架构和分析需求渴求极大。
就金融而言，韩卿称，传统金融机构客户更愿意尝试成熟的新技术。“有银行使用我们的技术进行了大半年的全面测试，最后看到他们平台和技术能力得到很大提升，最终选择了Kyligence的方案。”
关于公司未来3-5年的发展目标，韩卿透露，希望能在智能数据仓库里做到行业的NO.1，并能拓展整个全球市场。
投资界
通常情况下基于业务数据库数据分析人员也能完成数据分析需求，但是为什么要建数据仓库？
没有数据仓库时，我们需要直接从业务数据库中取数据来做分析。
业务数据库主要是为业务操作服务的，虽然可以用于分析，但需要很多额度的调整。
一，业务数据库中存在的问题
基于业务数据库来做分析，主要有以下几个问题：结构复杂，数据脏乱，难以理解，历史缺失，数据量大时查询缓慢。
结构复杂
业务数据库通常是根据业务操作的需要进行设计的，遵循3NF范式，尽可能减少数据冗余。这就造成表与表之间关系错综复杂。在分析业务状况时，储存业务数据的表，与储存想要分析的角度表，很可能不会直接关联，而是需要通过多层关联来达到，这为分析增加了很大的复杂度。
数据脏乱
因为业务数据库会接受大量用户的输入，如果业务系统没有做好足够的数据校验，就会产生一些错误数据，比如不合法的身份证号，或者不应存在的Null值，空字符串等。
理解困难
业务数据库中存在大量语义不明的操作代码，比如各种状态的代码，地理位置的代码等等，在不同业务中的同一名词可能还有不同的叫法。
这些情况都是为了方便业务操作和开发而出现的，但却给我们分析数据造成了很大负担。各种操作代码必须要查阅文档，如果操作代码较多，还需要了解储存它的表。同义异名的数据更是需要翻阅多份文档。
缺少历史
出于节约空间的考虑，业务数据库通常不会记录状态流变历史，这就使得某些基于流变历史的分析无法进行。比如想要分析从用户申请到最终放款整个过程中，各个环节的速度和转化率，没有流变历史就很难完成。
大规模查询缓慢
当业务数据量较大时，查询就会变得缓慢。
二，数据仓库解决方案
上面的问题，都可以通过一个建设良好的数据仓库来解决。
业务数据库是面向操作的，主要服务于业务产品和开发。
而数据仓库则是面向分析的，主要服务于我们分析人员。评价数据仓库做的好不好，就看我们分析师用得爽不爽。因此，数据仓库从产品设计开始，就一直是站在分析师的立场上考虑的，致力于解决使用业务数据进行分析带来的种种弊端。
数据仓库解决的问题
结构清晰，简单
数据仓库不需要遵循数据库设计范式，因此在数据模型的设计上有很大自由。
数据模型一般采用星型模型，表分为事实表和维度表两类。
其中事实表位于星星的中心，存储能描述业务状况的各种度量数据。
维度表围绕在事实表的周围，通过外键一对一的形式关联，提供了看待业务状况的不同角度。
星型模型使用方便，易于理解，聚焦于业务。
当我们做数据分析时，首先选定主题，比如分析用户注册情况；其次根据选定的主题找到对应的业务数据源，然后观察业务数据源提供了哪些分析角度，最后根据数据进行分析。
星形模型非常适合这个思路，并且大大简化了这个过程。下面以我们目前的模型来举例。
可复用，易拓展
星型模型不仅便于理解和使用，而且维度表还便于重复使用，维度表中字段易于拓展。
比如日期维度表，不仅可以被不同的事实表是使用，在同一张事实表里也可被复用，比如一个事实表里不同的操作日期，一个商品的订单有创建日期、付款日期、发货日期、退款时间、收货时间等等。
维度表中字段易于扩展，只要保证维度数据的主键不变，直接在维度表里添加新的字段内容即可，添加的新内容只会影响到维度表而已。而且，维度表通常数据量不大，即使完全重新加载也不需要花费多少时间。
数据干净
在ETL过程中会去掉不干净的数据，或者打上标签，使用起来更为方便。
注：由于数据清洗需要建立一定的规则，而目前的工作重心是数据建模和ETL系统设计，没有额外的时间精力设计清洗规则。为了保证数据的完整性，没有在当前的ETL中做清洗。
数据语义化／统一描述
各种状态都可以直接写成具体的值，不再需要使用操作码进行查询，SQL语句更自然，更易理解。
对于部分常用的组合状态，可以合并成一个字段来表示。比如在还款分析中，需要根据还款状态、放款状态／发货状态的组合来筛选出有效的订单，可以直接设置一个订单有效的字段，简化筛选条件。
对于同一含义的数据在不同情境下的表示，也可以统一描述了。比如对于放款日期的描述，在产品是消费贷时，指的是发货的日期，产品是现金贷时，指的是放款给用户的日期。这两个日期都是表示放款日期，就可以统一起来，同样也简化了筛选条件。
保存历史
数据仓库可通过拉链表的形式来记录业务状态变化，甚至可以设计专用的事实表来记录。只要有历史分析的需要，就可以去实现。
高速查询
数据仓库本身并不提供高速查询功能。只是由于其简单的星形结构，比业务数据库的复杂查询在速度上更有优势。如果仍然采用传统的关系型数据库来储存数据。在数据量上规模之后，同样也会遇到查询缓慢的问题。
但是，使用Hive来储存数据，再使用基于Hive构建的多维查询引擎Kylin，把星型模型下所有可能的查询方案的结果都保存起来，用空间换时间，就可以做到高速查询，对大规模查询的耗时可以缩短到次秒级，大大提高工作效率。
碎片时间
简言之，数据库主要面向业务中“交互”场景（如创建一个订单、收藏一件商品、删除一条评价等），提供对业务数据的读写操作功能。
数据库按照操作的数据模型划分，可以分为关系型数据库、键-值数据库、文档数据库、图数据库、等等。
数据仓库，则汇总了各个数据源的有价值数据。这些数据源可能包括公司内部系统的数据库、电子表格等，也可能是来自外部机构如社交网站、银行等。
通过对数据仓库中的信息进行分析和挖掘，可以从各个时间、区域、等维度对业务情况进行汇总分析，如：“双十一活动”的各种数据报告，哪个省份的人最爱买什么，等等。
当然，数据库和数据仓库的区别，从不同角度看会有不同的答案。我仅从我的角度给大家提供一点解读，希望对大家有用，谢谢。
chaohuang
相对于文件系统而言，数据库是易于查询和修改的格式化数据存储形式。各家软件公司又围绕它制作了管理系统和各种工具。
文件系统很好理解，打开电脑，那些文件夹啊，文件啊就是了。但文件系统不易于做复杂的分析和修改。为了满足这个需求，数据库就出现了。
本质上数据仓库也是数据库，为一种特定需求服务的数据库。服务于数据量大，需要进行复杂分析的场景。数据库还能应用于其他场景。比如事务性场景，如商业交易，买卖的记录和客户资料的存储更新。
希望对你有帮助
forGoldenAlex
我举例来说一下，这样也能帮助大家在以后的工作中去应用。我们都能理解数据库设计两张关联的表的时候用主键和外键，避免冗余啊，便于数据同步啊什么的。什么时候数据不用去冗余和数据也不用同步？答案就是档案。当你的数据像档案一样只是用来查询，统计和分析的时候就放到仓库里，反之数据还要有变更更适合放到数据库里。那么数据档案长什么样子呢？比如你发表了一篇论文，当时期刊的名字叫a影响因子不高，后来这个期刊改名字了影响信息也提高了，那问题来了你当时发表的论文应该哪个影响因子认定你的成绩呢？显然是名字为a的影响因子，而不是后面的影响因子。你可能想数据库也行呀。确实数据库不是不能实现而是数据库更喜欢用主键外键关联的方式描述这篇论文的，如果你新增期刊信息（把改了名字的期刊当成新期刊入基础信息库）你的基础信息就会随着各个刊物的发展而增长，这时你可以考虑直接把期刊的信息写到论文信息里固化，这就形成了档案，把这些档案从数据库里搬到仓库里去，也降低了当前业务数据库的存储压力降低数据量提高工作效率。
DOS4204053888
个人理解，数据仓库其实也是数据库的一种应用类型，主要与在线事务处理的数据库进行区别，数据仓库中的数据一般都是从生产系统中通过抽取，清洗，然后分类存储形成不同的主题仓库，最终服务于数据分析（比如BI）等用途
了不起的某某某某
瞎炒概念！
数据库本义就是因为数据量大，把存储空间比喻成仓库。如何命名呢？数据仓库拗口，而且笨拙不符合IT领域属性。所以才叫“数据库”。
现在把数据仓库拿出来说是，无聊至极！！！
