Table of Contents
前方導讀
對Vertica的回憶回到2015年，那時候的我不止18歲，當時根據項目需求，我調研實踐了Vertica，模糊記憶印象中當時Vertica的社區免費上限是100G，而不是現在的1000GB，當時向技術領導反映這個東西不錯可以應用于大數據系統項目，項目進行中突然一天卻被要求下架，原因是因為它是一個商業版的軟件。商務領導發話，公司發你們IT部門高薪，就是為了解決IT問題，為什么額外花錢購買一個商業版軟件，領導的思維更想你用開源的工具，然后是lambda框架也好、kappa框架也好或者unifield架構去解決大數據項目相關的問題。多年工作經歷，倍覺感受做一個IT項目關鍵核心取決于三要素，那就是人、方法論、工具等等。一流的人才和一流的方法使用三流的工具也能三個臭皮匠頂個諸葛亮。Vertica是一款即使你只是p1的水平也能輕松實現撐起企業級數據分析解決方案的好工具，作者對Vertica的技術本質理解，結合行業相關產品的對比，對未來數據分析技術方向做了一個探索，希望我把數據分析最關鍵核心技術的那一點說清楚了，希望我把Vertica的最關鍵的空間技術點也說清楚了，也希望各位展開OLAP的話題討論。基于本人能力水平有限，技術描繪不清或者筆力不到之上請批評指正。
開場白
一年一度的天下數據分析比武演講大會正式開始，擂臺上燈光閃爍，臺下選手摩拳擦掌，活動筋胳，躍躍欲試，面向最耀眼的舞臺中心。一個全身肌肉發達，胡子拉碴的大漢正在激情四射的演講， “我是Oracle RAC,我90年代就把業務分析遍及全球，全球案例有XX個，我的客戶有制造業的XX，金融業的XX，通訊行業的XXX ，我有點貴，但是我的性能很強大”。說完就要脫衣服秀他的胸肌 ，臺下觀眾馬上騷動起來，喊著要把Oracle家族驅逐。眾所周知，Oracle家族的確有實力，占據了大半壁的江山，一直是所有數據產品的公認的對手，近十年云計算和新技術興起，很多數據產品在不同業務場景都能與Oracle分庭抗禮，越來越敢和它叫板。司儀看見Oracle又惹仇恨了，趕緊出來救場。
司儀清了清嗓子，大喊"有請下一位選手，vertica"，大伙齊唰唰朝著一位其貌不揚的小伙子看去。
“大家好，我是美國選手vertica，出生在美國麻薩諸塞州，突然意識到他的外國選手身份對他不利，vertica補充了一句，我的父親是Michael Stonebraker!”
喧鬧的人群立刻安靜下來，Michael Stonebraker是一位獲得圖靈獎的計算機科學家，地位超群，他在關系數據庫方面的理論造詣和數據庫產品的應用貢獻至今對現今市場上的產品有很深的影響，他也是以下IT公司的創始人：包括Ingres, Illustra, Cohera, StreamBase Systems以及VoltDB。
天下數據分析流派
我出生在2005，至今16歲了，我致力于解決當前數據分析平臺日益增長的“大數據”和實時分析要求所帶來的挑戰，可以以傳統解決方案30%的成本，實現50倍-1000倍的性能提高。今天我的演講是天下數據分析流派調研，給各位數據分析產品定義一個標簽，穿插介紹我能干什么，給誰做了什么。我看天下數據分析勢力可以分為三個流派，傳統的數據集中式流派， 分布式計算流派、 新興技術的預處理流派，按照性質劃分我屬于分布式計算流派。
數據集中式流派的功夫以軟硬件一體結合為主，代表 作oracle exadata、sap hana，它們重視硬件建設，通過優化硬盤、內存、網絡達到更高的數據處理性能，但是成本太高，普通的中小企業用戶根本根本承受不起，數據集中式流派正在走下陂路，2019年sap hana大裁員就是一個預兆。說完，vertica指著oracle rac說，它也是數據集中式門派中的一員。
oracle rac紅著臉坐立不安，觀眾響起熱烈的掌聲。vertica潤了潤喉嚨，我介紹下預處理流派，中國的kylin和美國的druid都屬于這個派別。預處理門派的運功法門是把大數據變成小數據，首先確定數據的維度邊界，再通過集群強大計算能力綜合處理后放在另外一個高性能數據庫上。druid和kylin區別在于druid使用批理引擎處理歷史全量數據，同時也通過實時引擎處理實時增量數據，而kylin沒有對實時增量數據做處理，如果業務涉及的維度有變化，它重新預計算一遍。兩者很好，都能以廉價的方式，在不增長硬件的成本給予業務支持。但是預處理是一個蓄力的方式，需要了解業務維度，只能支持固定的分析業務場景，無法滿足自定義分析的需求 ， 業務瞬息萬變，數據實時更新，預處理跟不上數據的變化。
下面我介紹我所屬的分布式計算流派，分布式計算流派也有分支，分為非MPP家族 和MPP族，我就是屬于MPP家庭，非MPP成員有hadoop、mapredcue、spark等等。而我們MPP家庭 有greeplum、hawq、impala、presto、clickhouse等。我們與hadoop既對立又合作，更多時候我們MPP是彌補他們不足，我們分布式計算門派是解決單點性能不足的問題 ，通過把任務分解成多個子任務分配給分布式廉價多個機器，達到性能提升的目標。與hadoop不同的我們是并行計算，他們是兩階段計算，兩階段計算把全部業務邏輯 分成兩部分處理，上部分業務抽像成為map進行處理，下部分業務進行reduce處理。如果數據質量不好或者系統參數欠優甚至算子上的程序容易發生數據傾斜，造成計算時大量的數據集中指定的機器上。
人群中一陣騷動，那些使用hadoop遭遇數據傾斜的人都交 頭 接耳討論，的確MPP引擎很少發生shuffle情況。"那么MPP是怎么做到避免shuffle呢? 當然分布式系統最終肯定是會發生數據傳輸，我們是把全部業務邏輯 都在每一個計算節點執行，執行結果提交服務節點進行歸并。相對于兩階段而言，我們是全部業務放在MAP端進行處理，最后提交到指定的唯一的REDUCE端，這樣我們避免了大數據傾斜的數據熱點計算。 "
Greenplum
下面我介紹下我們的家族成員Greenplum，Greenplum是基于postgresql的基礎上開發，Greenplum的組件有master、segment、interconnect。簡單概括精要如下
- master是greenplum的主節點，是集群的入口，主要負責接收客戶端連接請求，對SQL語句生成查詢計劃，計劃分解成任務均勻分給每個計算節點。
- segment是greenplum的執行節點，每個segment可以視為一個獨立的PostgreSQL數據庫。
- interconnect是greenplum的網絡節點，負責匯聚合并數據，主要解決查詢執行中segment實例之間或者segment和master。
Greenplum的亮點創新，一般而言，Greenplum集群有master和segment就足夠了，但是Greenplum額外開了interconnect，通過interconnect減輕了master壓力，并減低內部網絡轉輸性能開銷，而且它繼承postgreSQL，所以有效獲得postgreSQL原始社會生態，讓那些postgreSQL的開發者能夠輕松使用上手。也是因為繼承postgreSQL，Greenplum使用還是傳統關系數據庫的B樹索引結構，這里汲及性能理論上限到磁盤傳輸速度和網絡傳輸速度的技術問題，這導致為什么會研發HAWQ。
我們簡單聊一下磁盤傳輸速度和網絡傳輸速度的技術理論問題 ，每一次分布式任務運行都會產生磁盤查找和網絡傳輸數據的動作。而postgreSQL是一個基于B樹頁存儲的數據，基本頁單元是8KB，如果任務汲及大量的數據查找，系統內部會有大量的硬盤數據查找動作。為了充分發揮硬盤的性能，我們會把存儲基本單元調大一點，讓它可以勉強跟上網絡的速度性能，否則分布式任務都會發生更多的數據查找，影響全局性能。hdfs不擅長小數據的處理，它的基本數據單元都是64M以上，hadoop1的block設置默認是64MB，后來hadoop2的block設置默認是128MB，目標是磁盤運轉速度跟上網絡傳輸速度。
Hawq
技術上來說，hawq大的改變，它替換了segment輪子，換上了hadoop牌，融進當前大數據主流的hadoop生態，hawq還做很有意思的改變，它支持ACID特性，為了做到這一點。它使用了orc存儲引擎，orc并非是一個純粹的列式壓引擎，它先按行組劃分，再按列組劃分。對于數據分析引擎來說，這個性能不會最好。
Impala
另外一個同樣基于hadoop的mpp成員impala，提到impala的核心處理技術，不得不說google dremel，google dremel是谷歌的實時處理系統，dremel深刻理解了MPP的精髓，它的查詢樹是金字塔狀的多層次查詢結構，由根節點、多個中間節點和多個葉子節點組成。葉子節點執行有部分結果直接向中間節點輸出，中間節點向頂部根節點匯報，頂部根節點最后統一輸出，最大化發揮數據貼近計算的特性。impala是基于dremel論文實現的MPP查詢引擎，底層默認用的是parquet，parquet是真正的列式引擎，更適合數據分析的業務場景。
presto
presto也是很出名的基于hadoop的MPP執行引擎，它是完全基于內存計算，在處理數據上有一個質的提升。相對于處理引擎的獨特之處，presto不是充分利用了內存，是完全使用了數據，通過接入數據源把數據全量加載到內存上，再對內存里的數據進行分析計算。缺點是多個節點的內存總量決定處理的數據大小，如果數據比內存大，presto容易掛掉，雖然presto一直在內存硬盤交換尋找方法，但是多年來沒有重大突破，截至2021年12月17日，presto最新版本是0.266.1，還沒有到標準的1.0版本。即使如此，presto仍然表現出強大的表現力，華為openleekeng就是基于presto基礎上研發的。
clickhouse
clickhouse是一款非常出色的MPP處理引擎，特立獨行，不走主流路線，它一開始就不打算融入hadoop，從索引到分區，從存儲引制到算法調度它是從零開始自我探索建設。它的杰作就是MergeTree，MergeTree是一個強大單機存儲引擎表，基于它的基礎上派生了ReplaceingMergeTree、SummingMergeTree、AggregatingMergeTree、CollapsingMergeTree、VersionedCollapsingMergeTree、GraphiteMergeTree六個引擎表，六個引擎表與MergeTree的關系，就像數據間中間件與數據庫的關系，中間件賦予數據去重、數據排序、數據聚合等特性。MergeTree的MPP特性本質就是多個MergeTree通過中間件分發路由組成的。MergeTree的性能很強，列式存儲、數據壓縮、向量化執行引擎是標配，存儲機制采用時間范圍分段的合并方式，能夠達到很高的壓縮比。clickhouse擅長個性化的大寬表數據集市業務場景。但是關聯多表業務場景性能不佳，甚至功能都達不到要求，經典的tpc-h基準測試和新型tpc-ds基準測試，clickhouse都沒法通過。
關于我
下面是自我介紹，我是一個基于列式存儲、實現MPP、去中心化、分布式、可擴展、高可用、多映射數據分布的數據庫。針對各種數據分析業務場景問題，我的絕招是數據映射，犧性空間換取時間的方式實現數據處理性能提升。
舉例一個表數據里面有A、B、C、D、E一共5個列字段，該表會針對不同的列名會冗余存儲多個物理視圖，每一個物理視圖是一個數據映射，vertica稱之為projection。
數據映射里面，針對業務規則對相關字段打索引和構建分區，如圖表所示，表數據有三個數據映射，一個數據映射以A、B做主鍵索引，一個數據映射以A、E做主鍵索引，一個數據映射以B、D做主鍵索引。vertica維護不同排序有重疊的映射，盡量使得每個查詢只來自于一個映射，為提高查詢性能，表查詢需要的列至少在一個映射中。
用戶發起三個SQL請求，每個請求挾帶不同的過濾條件，因為數據映射，Vertica將自動選擇用于該查詢的，都能擊中數據庫索引，不會造成回表追溯查找或者全盤掃描。
舉例一個兩表關聯查詢的例子，table1表有5個字段，table2有3個字段 ，兩表關聯過濾查詢返回結果果。一般的數據庫根據過濾條件遍列所有的列，包括A列、B列、D列、E列、F列,選擇B列、D列、F列返回。而Vertical是訪問指定的數據映射Project2，Project2只包括B列、D列、F列，耗時IO遠比全盤掃描快。
而創建Projection2的步驟很簡單，如下
(
B ENCODING RLE,
D,
F // Column List and Encodings
) AS
SELECT
t1.B,
t1.D,
t2.F
FROM table1 t1
INNER JOIN table2 t2 on t1.C = t2.C
ORDER BY t1.C
綜合比較
MPP流派的運功法門關鍵要點第一如何讓數據貼近計算，第二如何實現數據分布。數據貼近計算是MPP任務運行過程如何把存儲數據裝入進行計算，而數據分布則是數據的物理存儲方式，是選擇離散的哈希分布還是集中的范圍分布的方式，是純列式還是半列式。
以MPP運氣為內功根基，我們各有各的招式，Impala和我的集群架構都是去中心化，每一個節點都是平等的，當外面發出請求，會有一個節點上升成為協調主節點，根據你的準備好的資源，如果該節點宕掉，根據內部算法選舉出新的協調節點，此舉相對中心架構的master/slave模式無疑充分利用了集群性能。Impala背靠hadoop大樹好乘涼，我們開發了有屬于自己的獨立的存儲引擎機制。而presto采用全量數據加入內存，即使表數據沒有實現索引分區，它依然運行很快，但是大于內存的數據量業務場景，它束手無策，實驗室測試環境同樣的硬件配置表明，當數據量大于內存總和的條件下，spark能比presto處理更多的數據。clickhouse追求技術極致，基于硬盤的DBMS在空間、壓縮、CPU指令、合并都用上最優的算法，但是它的權衡卻忽略了用戶關聯多表的基本需求，笛卡爾乘積是數據庫連接操作最普通的存在。Greeplum和Hawq同屬一家公司，它們的市場定位方向開始向OLTP發展，在OLAP領域方面，他們存在共同的痛點，隨著數據量不斷滾大，數據處理能力下降，需要水平擴展機器提高處理性能，預處理派流派的druid的研發公司Metamarket,就是因為greeplum無法滿足業務需求而研發了druid。
我們Vertica的架構設計權衡多個因素，考慮了硬盤、內存、空間、壓縮、讀寫優化、算法、數據庫的基本關系代數操作、集合操作、連接操作等等，沒有為某個特定的業務場景放棄一些東西。我們最愿意犧牲的是空間，數據映射的本質是通過犧牲空間換取額外的物理視圖和索引的技術方式。
助力denodo數據虛擬化建設
客戶背景
Denodo創立于1999年，2002年推出Denodo 平臺第 1 版，2016年Denodo 發布 Denodo Platform 6.0，推出云中數據虛擬化和動態查詢優化。同年，Denodo 獲評 Gartner 數據集成魔力象限“遠見者”。2017年Denodo 發布 Denodo Platform 7.0，推出大規模并行處理 (MPP) 功能，以及業界首個完全集成的數據目錄。Denodo 獲評 Gartner 數據集成魔力象限“挑戰者”和 Forrester Wave 大數據結構“領導者”。Denodo 客戶 Autodesk 因使用數據虛擬化技術改造業務模式而榮獲 CIO100 獎。2019年Denodo正式進入中國，注冊成立丹諾德軟件（北京）有限公司。2020年Denodo 獲評 Gartner 數據集成工具魔力象限和 Forrester Wave 企業數據結構“領導者”，Denodo 宣布 Denodo Platform 8.0，加速混合/多云集成，使用 AI/ML 自動管理數據并提高性能。憑借20余年的創新歷程及行業領先的數據虛擬化解決方案，公司致力于在金融、制造、汽車、醫療等領域，通過實時統一數據資產、轉變國內企業的創新和業務運營方式，為最廣大范圍的企業、云端、大數據和非結構化數據來源，提供靈活、高性能的數據集成、數據抽象化和實時數據服務。
客戶愿景
Denodo廣泛應用于數據管理、主數據建設、大數據分析平臺、商業智能，幫助其解決供應商管理、監管合規性、數據即服務、系統現代化等多個復雜應用場景痛點，以傳統解決方案一半的成本，提升企業業務靈活性和投資回報率。
Denodo的愿景是，成為行業領先的數據虛擬化和邏輯數據結構供應商，通過創建邏輯數據層，幫助企業集中管理分散的數據，提升敏捷性，降低系統維護的復雜程度。借助此方法，用戶可以從高性能的單一訪問點獲取任何信息，并使其靈活地選擇自己喜歡的應用程序來使用信息。同時，數據虛擬化還消除了移動或復制數據的必要性，在帶來技術優勢的同時，還能節省 50% 至 60% 的數據集成成本。
Denodo與Vertica的關系
見官方公開聲明，官方強烈建議使用vertica做為Denodo的緩存管理使用工具。
In the current Denodo architecture, Denodo server does push down processing to other data sources.
However, it first retrieves data from disparate sources and performs a Join and other required processing in the Denodo server without caching. This requires a lot of system resources. Since Vertica has a more powerful processing capability, you can push the Join and other processing to Vertica and observe significant performance improvements. We recommend configuring Vertica as a cache. For more information about using Vertica as the cache and the different cache modes, see Vertica Integration with Denodo: Tips and Techniques.
來自 https://www.vertica.com/blog/tips-and-techniques-for-vertica-integration-with-denodo/
Denodo運行原理及技術分析
簡單概括Denodo，可以在無需共享任何數據源、數據結構、數據中心、或數據庫技術的情況下，合并來自不同數據源的實時數據，并讓這些數據真正能夠為企業所用。沒有Denodo，我們是通過sqoop或者dataX或者canal等工具對不同的數據源進行ETL，在數據倉庫中進行加工、提純、轉化操作，最后放到數據集市對外開放。Denodo把這一切做到了 透明化、自動化、智能化，那么它是怎么做到的？
Denodo的數據虛擬化有以下三個能力域。
1.統一數據語言的標準化和轉換層,對外提供SQL，屏蔽Python、Scala 、Java各種語言。
2.統一元數據標準規范，比如表格的結構、轉換和清洗操作、聚合等 。當使用數據虛擬化時，元數據規范只需要被執行一次，不需要把它們復寫給更多的數據消費者。換句話說，數據消費者共享和重復使用這些規范。
3.統一數據存儲中心，支持從多個數據存儲區中集成數據，具備數據下推往數據源執行的能力。
隱藏底層數據源(關系型數據庫、NOSQL、NEWSQL、數據倉庫)等技術訪問細節，將數據源的抽象和聚合要求將物理資源抽象出來，對外為用戶提供一個統一的數據接口。用戶在定義數據源的初始化配置文件后，能夠自由查詢和操作各個目標源的數據源，一言簡之，數據虛擬化技術實現前端與后端多源異構的解耦，輕量級簡單解決數據集成多源異構的困難。
數據虛擬化對外實現了高訪問性用性和高易用性，對內實現了多種數據處理技術協調共存，具備多源異構的數據處理能力
為什么Denodo需要Vertica？Denodo面對的是真正千萬噸海量數據壓力，它可以對接中臺，對接數倉或者各種不同的數據產品。在數據整合充分流動的過程中，數據源hadoop不斷在增大，oracle隨著業務增長也會上升，面對數據源的不斷水漲船高，Denodo需要一個穩定可靠的數據管理系統，對數據進行高效存儲管理。特別是多源異構的數據整合時，Denodo需要開辟一個暫存區和多模狀態數據存儲區區域 ，對數據進行有效的分類分級管理存放，Denodo的緩存數據管理系統需要達到以下指標要求。
- 數據暫存區支持的數據存儲空間能夠支持數據源。
- 支持分布式部署使用
- 支持分布式擴展
- 支持高可用，意外集群意外宕機能夠繼續使用。
- 隨著數據增長，能夠不增加節點的方式提高算力
- 支持自動自助查詢和即席查詢。
- 支持數據分析有關的所有函數和SQL操作
- 數據管理系統本身能與自治數據源有統一共識的接口。
- 可靠性、穩定性、輕捷的使用性
這一切vertica都做到了，所以高規格的Denodo是選擇Vertica做為緩存數據管理系統。
助力smartbi
客戶背景
廣州思邁特軟件有限公司（以下簡稱思邁特軟件）成立于 2011年，以提升和挖掘企業客戶的數據價值為使命，專注于商業智能(BI)與大數據分析軟件產品與服務，旗下主要產品是smartBI。
smartBI是民族BI軟件領先品牌，堅持踐行技術創新、“數盡其用”，顛覆了企業軟件必須依賴Web端瀏覽器的傳統習慣，充分融會貫通現有企業報表工具，為用戶提供豐富的展現力、強大的互動性和靈活的布局能力，嚴慎細實、全力以赴，有效支撐天問一號火星探測任務、神舟十二號載人飛行任務等高標準航天項目，為中國構建自主創新格局強根筑基。
smartBI與Vertica的關系
2017年7月27日，Smartbi Insight與HPE Vertica正式攜手，達成戰略合作，打造新一代MPP大數據自助分析方案，為客戶提供“基于新一代MPP的高性能大數據自助分析解決方案”。
對用戶來說，實現大數據分析需要同時具備功能易用的前端BI工具和性能強勁的數據平臺，Smartbi Insight專注于前端功能十幾年，形成了以電子表格、自助探索、分析報告為特色的數據展現分析功能，HPE Vertica作為新一代MPP數據庫軟件，從設計原理上有天然的性能優勢。因此，Smartbi Insight+HPE Vertica的強強聯合，將為客戶帶來必不可少的應用價值，也為廣大解決方案提供商提供了完備的產品組合。
https://www.kejixun.com/article/170807/358278.shtml
商業智能理解和痛點分析
商業智能實質上是數據轉化成信息和知識的過程。構建一個完整的商業智能系統需要以下幾種核心的技術：數據倉庫、數據挖掘和分析、ETL處理技術、聯機分析處理技術、可視化分析、大數據技術、元數據管理，最終用戶對商業智能的訪問使用包括：即席查詢、報表、聯機分析處理、數據挖掘等。
從數據到信息，從信息到知識，技術和相關工具必須提供基本的數據的存儲能力和數據的處理能力，目前所有的數據廣泛產品都包含這兩個能力，只是強弱高低之分已。單機分析能力弱，分布式能力強，MPP能力更強，計算能力是商業智能考察的一個重要指標，數據挖掘發現數據的規律也是商業智能重點考察的指標。
市場內大部分的BI產品都實現了數據的描述性分析，即把業務的運營過程和實時分析結合起來，通過把歷史數據和當前數據合并，用于營銷活動分析、銷售預測、風險管理。描述性分析做的事情是事后結論，即過去發生了什么事情，對數據更有價值和意義的是預測性分析和規范性分析，預測性分析做到將來要發生什么事情，規范性分析則做到什么樣的因素會導致這個事情的發生。
過去,BI產品為了預測性分析和規范性分析，都會集成開源或者成熟的學習框架，例如tensorflow或者Deeplearning4j，顯然機器學習框架與BI產品融合需要二次開發，即使融合成功，如果數據結果很多或者數據持續不斷的輸出，存在計算不一致性或者讀取數據錯誤等挑戰，發生錯誤后，需要重新對數據源讀取。
Vertica的數據庫內算法，讓預測性分析和規范性分析有了新的選擇。
數據庫內算法可以在每個計算節點獨立的執行，因此可以在計算節點級別實現新形式的分析處理，提供數據、統計的功能，確保移動是在數據庫內完成的，不是庫外接口數據傳輸在應用端完尥。通過移動計算接近數據，可顯著提高減少復雜算法(如k-means、邏輯或線性回歸）的計算時間。下面是庫外計算和庫內計算的對比圖。
附Vertica聚類算法實現的例子
Clustering Data Using k-means
This k-means example uses two small data sets named agar_dish_1 and agar_dish_2. Using the numeric data in the agar_dish_1 data set,
you can cluster the data into k clusters. Then, using the created k-means model,
you can run APPLY_KMEANS on agar_dish_2 and assign them to the clusters created in your original model.
Before you begin the example, make sure that you have loaded the Machine Learning sample data.
1.Clustering Training Data into k Clusters
Using the KMEANS function, run k-means on the agar_dish_1 table.
=> SELECT KMEANS('agar_dish_kmeans', 'agar_dish_1', '*', 5
USING PARAMETERS exclude_columns ='id', max_iterations=20, output_view=agar_1_view,
key_columns='id');
KMEANS
---------------------------
Finished in 7 iterations
(1 row)
The example creates a model named agar_dish_kmeans and a view containing the results of the model named agar_1_view. You might get different results when you run the clustering algorithm. This is because KMEANS randomly picks initial centers by default.
2.View the output of agar_1_view.
=> SELECT * FROM agar_1_view;
id | cluster_id
-----+------------
2 | 4
5 | 4
7 | 4
9 | 4
13 | 4
.
.
.
(375 rows)
3.Because you specified the number of clusters as 5, verify that the function created five clusters. Count the number of data points within each cluster.
=> SELECT cluster_id, COUNT(cluster_id) as Total_count
FROM agar_1_view
GROUP BY cluster_id;
cluster_id | Total_count
------------+-------------
0 | 76
2 | 80
1 | 74
3 | 73
4 | 72
(5 rows)
From the output, you can see that five clusters were created: 0, 1, 2, 3, and 4.
You have now successfully clustered the data from agar_dish_1.csv into five distinct clusters.
Summarizing Your Model
You can also view a summary of the model you created using the SUMMARIZE_MODEL function. This summary tells you how many cluster centers your model contains, along with other metrics.
=> SELECT SUMMARIZE_MODEL('agar_dish_kmeans');
-[ RECORD 1 ]---+-------------------------------------------------------------------------------------------------
SUMMARIZE_MODEL | k-Means Model Summary:
Number of clusters: 5
Input columns: x, y
Cluster centers:
0: {x: -7.4811859, y: -7.5257672}
1: {x: -3.5061558, y: -3.5570295}
2: {x: -5.5205715, y: -5.4919726}
3: {x: -1.5623823, y: -1.5056116}
4: {x: 0.4970753, y: 0.5111612}
Evaluation metrics:
Total Sum of Squares: 6008.4619
Within-Cluster Sum of Squares:
Cluster 0: 12.389038
Cluster 1: 11.210146
Cluster 2: 12.994356
Cluster 3: 12.639238
Cluster 4: 12.083548
Total Within-Cluster Sum of Squares: 61.316326
Between-Cluster Sum of Squares: 5947.1456
Between-Cluster SS / Total SS: 98.98%
Number of iterations performed: 6
Converged: True
Call:
kmeans(model_name=agar_dish_kmeans, input_table=agar_dish_training, input_columns=*, num_clusters=5,
exclude_columns=id, max_iterations=20, epsilon=0.0001, init_method=random, initial_centers_table=,
distance_method=euclidean, outputView=agar_training_view, key_columns=id
)
Clustering Data Using a k-means Model
Using agar_dish_kmeans, the k-means model you just created, you can classify the agar_dish_2 data set.
Create a table named kmeans_results, using the agar_dish_2 table as your input table and the agar_dish_kmeans model for your initial cluster centers.
Add only the relevant feature columns to the arguments in the APPLY_KMEANS function.
=> CREATE TABLE kmeans_results AS
(SELECT id,
APPLY_KMEANS(x, y
USING PARAMETERS
model_name='agar_dish_kmeans') AS cluster_id
FROM agar_dish_2);
The kmeans_results table shows that the agar_dish_kmeans model correctly clustered the agar_dish_2 data.
Smartbi支持各種各樣的數據產品，包括傳統SQL數據庫oracle、DB2、mysql，nosql系列hbase、cassandra、redis以及newsql系列hana、tidb，還有各種數據處理引擎spark、hive、presto等等，萬花叢中一點紅，唯獨Vertica與Smartbi結成戰略合作伙伴關系，不但是看中Vertica強大的計算能力，更重要的是Vertica對商業智能業務的理解。
未來數據分析技術展望
物理學里面抖動是一種物理現象，物體彼此之間互有聯系需要進行交互，如果物體太多產生的傳輸和通訊會破壞原來的系統的秩序穩定，導致熵混亂。用中國人的老話說，林子大了什么鳥都有，分布式系統技術存在的數據傳輸、節點通信、心跳感應、計算監控、計算調度和計算分布時刻都在發生，隨著集群節點不斷擴大，量變導致質變，集群的復雜度不斷提升，發生在DBA上面的事，抖動引起的故障級別叫做閃斷。閃斷就是有時候故障現象會出現，有時候故障現象不出現，有時候日志打印錯誤信息，有時候什么信息也沒有，你根本無法一下子定位到是系統問題、硬件問題、軟件問題、網絡問題。
從這個角度來看，集中式流派有獨特之處，它雖然昂貴，但是它可靠、穩定、高效，最重要是健壯，如果有世界末日發生洪水災害，人們登上諾亞方舟逃難，因為方舟空間有限，船上必然安放的是一個集中式流派的系統。如果地球還有幾千年的技術發展和文明進步，未來數據分析技術必然是分布式流派的世界，但是分布式集群越做越大，必然要面對抖動現象。例如greeplum集群上升到1000個節點，再往上擴展會有更多的問題和挑戰，例如你需要要考慮網段分配和長網絡傳輸耗時，其中一個節點的網卡異常或者系統不穩定，都會影響整個集群。在抖動問題的方案上，預處理和空間處理是較成熟理想的選擇，面對不斷增長的大數據隱式派生新空間，通過新空間的訪問減少IO，而不是全局空間接觸。
空間技術不但可以避免抖動，同時也是未來數據分析技術的主流方向，現在的數據中臺框架，從原始數據源層到數據域層、輕匯到重匯、個性化大表、數據集市其實就是空間技術的理念，通過對數據提前有效整合，做到應用需要時拿來就用，數據分析的比較其實就是如何對數據源實現高效的數據集成。不計較硬件成本的前提下，presto應該是最快的的MPP利器，但是presto只能處理內存范圍內的數據為人詬病。presto另辟溪徑，借助Alluxio在數據層面的優勢，實現presto與Alluxio的集成提供給客戶更優質的體驗。Alluxio通過管理內存和本地存儲，實現不同存儲系統之間的高效數據管理，達到加速數據訪問的目標。DorisDB的核心的秘密武器就是物化視圖，就是優化后的數據放進新空間，以至大數據增速下依然能保障原來的運行性能。
結尾詞
以上是Vertica兩個案例的介紹，我相信以后的數據分析技術發展，MPP是宏觀必備的基本條件，空間技術是細節的關鍵核心技術，永不過時的， 最近出現的中國選手StarRocks，它也是MPP的，至此我的演講完畢。我是Vertica，專業OLAP16年，我會繼續深耕數據分析領域，堅持100年不動搖，圍繞數據倉庫、信息管理、數據管理 、主數據管理、商業智能、數據中臺、倉湖建設、數字化轉型領域刻苦修行，大放異彩，希望我的經驗和能力能夠幫到大家，謝謝大家！
附Vertical相關入門和學習了解
https://www.vertica.com/documentation/vertica/11-0-x-documentation/
https://www.vertica.com/knowledgebase/
http://m.sunline.cc/db/210638 安裝方法
