姒
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領域屬性。所以才叫“數據庫”。
現在把數據倉庫拿出來說是，無聊至極！！！
