Cassandra與職業發展 | 阿里雲欒小凡 × 蔚來汽車張旭東 × 網龍闕乃禎
活動精彩實錄 | Cassandra與職業發展
大家好，我叫鄧為，我目前在DataStax擔任領航架構師。我在DataStax工作了7年多的時間，也有7年多的Cassandra經驗，我在大數據和數據庫領域的經驗則有大約十多年的時間。很高興今天能夠邀請大家到我們的活動中，來聽聽我們的嘉賓們與職場相關的經驗和感悟。
我們今天的嘉賓來自三個不同的公司，他們都是在Cassandra數據庫方面有很多年經驗的專家。
首先是阿里雲高級技術專家欒小凡。14年第一次接觸Cassandra，追隨Cassandra的作者Avinash創業，構建了軟件定義存儲產品hedvig。16年加入阿里，從事Ali HBase和阿里自研雲原生數據庫lindorm的開發工作。20年開始回歸Cassandra，負責阿里雲Cassandra的開發工作。
接着是蔚來汽車資深軟件開發工程師張旭東。目前在蔚來汽車從事數據平台、數據倉庫相關研發工作。17年開始接觸Cassandra，對於Cassandra的使用有較深的理解，將Cassandra成功運用於多個公司項目中。
最後一位是網龍公司軟件開發工程師闕乃禎。近6年來在網龍參與im即時通訊，推送服務，iot的設計開發。這些項目對cassandra有重度依賴，期間同時負責基礎服務平台cassandra的運維、監控、開發指導工作。
非常感謝嘉賓們能抽出寶貴的周末時間與大家分享經驗。
—
Q：能否簡單介紹自己的背景以及你是如何開啟Cassandra之路的？
欒小凡
大家好，目前我在阿里雲做數據庫研發。我接觸Cassandra比較早，屬於機緣巧合。在接觸Cassandra之前，我在Oracle工作，主要負責數據庫硬件加速方面的內容，那時候我對分佈式系統並不是特別了解。
後來在學習像Cassandra這樣的分佈式系統之後，我就對分佈式系統產生了興趣。正好那時想要創業，而且認識了Cassandra的作者Avinash。與他聊過之後，發現他對數據庫和存儲產品的見解比較深入，所以我決定加入他的團隊。在這個團隊中，我主要是基於Cassandra做了一個分佈式的存儲系統Hedvig，這個存儲系統後來成為了很多銀行的數據備份方案。
基本上就是借這麼一個機會，我開始了解Cassandra。從做Cassandra開始，我最開始的定位主要還是做數據庫的研發，當時也給社區貢獻了一些bug fix。後來2016年回國後，我逐漸開始兼顧研發和運維兩個方面的職責。尤其是最近一年做了更多運維工作，比如幫用戶設計他們自己的系統。
在這個過程中，我對Cassandra也有了更深的理解以及它周邊的生態，比如用戶現在比較關注的可能是Spark、ES，以及它們與Cassandra的結合方式。早期的我雖然對Cassandra有所理解，但是對它的周邊理解不多。後來在學習的過程中，我也看了很多DataStax的文章，這些文章為用戶提供了很多方便，有很多東西是我之前在社區都沒有關注到的。
在我現在工作中，Cassandra佔到了50%-60%，主要是在研發和運維方面。
張旭東
大家好，我叫張旭東，目前在蔚來汽車北京的軟件部門從事數據倉庫相關的工作。我大概15-16年還在獵豹移動做廣告和新聞推薦的時候，團隊里就已經在用Cassandra存一些新聞推薦相關的文章、customer profile相關的數據。這也給了我一個了解Cassandra的契機。
三年前來到蔚來汽車，發現軟件部門已經在多個業務線使用Cassandra了。也是從那時開始，我不僅從理論上更是從實戰上了解Cassandra的原理和使用。
為什麼當初公司沒有選擇像是MySQL那樣知名的數據庫，而是選擇了Cassandra呢？據我了解，主要是有這麼幾個原因：
– 公司需要一個NoSQL數據庫來存儲大量數據。在NoSQL數據庫中，通過一些技術文檔和benchmark了解到，相較於HBase來說Cassandra的性能要更好一些。
– Cassandra從2.0版本開始提供CQL這種查詢語言，它的表達能力相對HBase來說更強一些。
– 公司那時也有意願探索新的技術。那時團隊中的一些人在雅虎工作時一直在用HBase，後來他們看到了Cassandra，也想要去了解一下它的原理和使用。
現在我們是跟隨Cassandra線上的開源版本對其進行使用和維護，集群也都用的是最新版本的Cassandra 3.11.8。我們存儲最多的是與車聯網相關的數據，目前我們的數據總量達到了千億級別，將近百T。目前公司用的是在AWS EC2上自行搭建的Cassandra集群，未來可能也會考慮使用AWS上的Cassandra雲服務，把集群託管出去。
闕乃禎
大家好，我是闕乃禎，我來自網龍公司，我從2014年開始接觸Cassandra。
當時我們成立了一個新的子公司，主要專註於教育相關的業務，比如網校通、信息推送、教育IoT一類的業務。因為我之前有HBase的經驗，團隊里有NoSQL相關經驗的人又比較少，所以我當時就開始負責這一塊的工作。
當時我們可能也是比較激進，大概兩三個月就把Cassandra搬上了生產環境。因為我之前也沒有Cassandra的經驗，那時候就用了兩三個月閱讀了社區文檔，還跑了demo做練習。這些做完後，我們就開始小規模地上線，把Cassandra放入生產環境。由於我們比較激進，其實剛開始的階段踩了不少坑。這個踩坑的過程持續了一兩年，等集群開始穩定下來，業務規模也慢慢上來了。
在這之後，我就比較側重於業務方面的開發，比如IM即時通訊、Push IoT，一直持續到現在。目前主要用Cassandra的業務數據量都比較大，用戶也比較多，但是沒有人專職負責。所以如果生產或者集群出現問題，我都是兼職幫忙解決一下，包括運維和技術指導。
—
Q：你們現在工作中的技術棧里會用到的和Cassandra相結合的技術都有哪些呢？
欒小凡
因為我們本身提供託管服務，跟其他兩位嘉賓相比，我們的業務可能會更雜一些。
整體來講，我覺得Cassandra更適用於兩種場景。一是大數據相關的場景，比如和Spark做一些結合進行離/在線的分析+實時。二是仰賴於Cassandra zero downtime（零宕機時間）的特性，因為它的QUORUM的讀寫模型導致它的穩定性和可用性相比傳統的HBase或MySQL來講更高，所以我們也發現有很多用戶用Cassandra做線上訪問。比如最早Facebook將Cassandra應用於Inbox（郵箱的收件箱）這樣的場景，或者可以用於IM（即時通訊）或消息推送的場景。
在這種場景下，我們發現除了Cassandra的二級索引可以提供非常好的讀的檢索能力以外，用戶還有一些額外的需求。比如用戶希望把數據和ES結合在一起，也就是同樣的數據會在寬表裡放一份，在ES或者Solr裏面再放一份。這樣就可以實現一些功能，比如對IM的關鍵詞做分詞檢索。這些方面我們能夠看到用戶是有比較大的需求的。
Cassandra還有一個很強大的能力，就是它可以作為MySQL的歷史庫。當MySQL的數據放不下時，用戶可能會尋求一些NoSQL的解決方案，但NoSQL的查詢能力相比MySQL可能略弱一些。總的來說，Cassandra+Solr/ES其實是一個非常好的解決方案。
除此之外，我們也在探索Cassandra能不能跟一些底層的文件系統做一些結合。比如我們把Cassandra的實時數據通過一些服務的方式生成像是Parquet或ORC格式的文件，然後交給Spark或Hive做一些分析，由此形成一個離/在線的場景。這也是我們看到用戶確實是在這樣做的。
張旭東
我們這邊的技術棧比較相似，我分成兩個方面介紹吧。
我們主要有兩撥人在使用Cassandra，一是後端在線服務，主要用Cassandra來存APP的數據。對於車聯網來說，我們會以車輛ID或車輛電池ID為主鍵，然後做一些查詢方式比較固定的點查詢。對於一些非固定的查詢，我們會和MySQL結合使用。另外如果要全文檢索的話，我們需要和ES結合使用。
*由於通信質量不佳而中斷
闕乃禎
其實技術棧都是很通用的，我想說的其實前面都已經提到了。像是IM、IoT、收件箱、消息記錄這樣的數據，我們都用Cassandra來存儲。像是IM這樣比較敏感的數據或是信息流的過濾，我們需要做一些風控審計，所以我們需要做檢索或事後分析。
我們會用Spark、Storm或者Flink做一些實時的流控、敏感詞過濾以及惡劣行為的監測，總之就是會清洗一遍信息流。關於事後的檢索，我們會用Kafka將數據同步到一個ES集群，實現像是聊天記錄檢索這樣的功能。
另外我們會把Ceph上面的文件的二級索引一類的信息同步到我們的Cassandra集群中，也就是將Cassandra和Ceph這樣的塊存儲一起結合使用。
鄧為
欒小凡老師剛剛說的內容很有意思，包括怎麼把Cassandra的數據以Parquet或者ORC的形式放到分佈式的文件系統上面。這其實也是DataStax在研究和發展的東西，我們將來也會有一些相關的開源的貢獻。Cassandra是用來處理實時的熱數據的，怎麼把這些熱數據儘快地導成冷數據，以一種高效的方式長期存儲，讓其他人有一個分析的平台——相信社區很多同學會對這方面感興趣，我們以後可以多多交流。
根據我為很多財富100強公司諮詢的經驗來看，現在很多大數據處理的框架和引擎都非常相像，比如Kafka、用於流處理的Spark Streaming、Flink、用於搜索的Elastic Search或是Solr。包括我們DataStax Enterprise（企業版Cassandra）也是以Cassandra為核心，又集成了Spark和Solr。也就是說如果你用DataStax Enterprise的話，你就可以直接在Cassandra數據庫里進行搜索。如果你要做分析處理的話，也可以直接使用我們的DSE Spark release。
總的來說，確實有很多東西是相通的。不過最近我看到「雲原生」這個概念非常火，所以現在整個Cassandra社區（不光是中國社區，包括美國、歐洲、澳洲等）中有很多公司都在考慮怎麼把Cassandra搬到Kubernetes環境里。因為Cassandra本身很容易做到靈活伸縮、在線擴展以及多雲支持，所以Cassandra和Kubernetes這種環境其實非常相匹配。
在這方面，DataStax為開源社區做了很多貢獻。昨天在大型全球會議KubeCon上，DataStax發行了一個新的Cassandra版本，叫做K8ssandra。也就是說我們現在正式有了一個在Kubernetes環境下使用的Cassandra發行版本，這個版本可以被用於生產環境。不僅如此，K8ssandra還自動管理了包括repair在內的很多運維工作。
—
Q：如果作為初學者，面對眾多數據庫的選擇，為什麼要花費時間精力學習Cassandra？
欒小凡
我主要從兩個角度來談這個問題。
第一，Cassandra本身是一個非常實用的數據庫。而且它已經被非常多的大型跨國公司在使用，包括像是Apple和Netflix，所以說Cassandra是經過了長時間生產考驗的數據庫。
在公司選型的時候，通常大家都會選擇一個關係型數據庫(relational database)，比如像是MySQL。但一旦你的數據增多，你必然要考慮如何將更多的數據存在一個實時的數據庫中並獲得比較好的查詢性能。在這種場景下，Cassandra其實是你非常好的選擇。
如果你能學習這樣一個棧，未來能匹配到的公司數量也會相對較多。目前國內使用Cassandra可能還不如國際上普遍，但總體還是處於快速增長的狀態，我相信未來會有更多的國內公司開始使用Cassandra。
第二，如果你是一個學生或是剛剛開始工作，可能你對分佈式系統並不是特別了解。Cassandra其實是在去中心化設計下一個非常好的範例。
最早的去中心化系統（比如Dynamo）大都不是開源的，一般人很難獲取豐富的學習資料。對於分佈式系統來說，要麼就是主從結構（master/slave）要麼就是去中心化的架構，兩者分別的代表其實就是HBase和Cassandra。如果你能把這兩個系統搞清楚，這對你未來設計分佈式系統是非常有好處的。
學習Cassandra，你可以從DataStax的文檔中學習了解這個系統的設計和使用，並且可以自己搭一個Demo。我最開始學習Cassandra就是通過這種方式，會自己構造一些小的業務場景，然後在AWS或阿里雲上買一個服務，之後再用這個服務去跑自己的Demo以便了解Cassandra的設計和使用。我覺得這對大家了解分佈式系統和Java這門語言都會很有幫助。
張旭東
欒老師剛才提到的也正是我想說的。對於初學者來說，Cassandra能夠加深你對數據庫和分佈式系統的理解，以及並幫助你理解Bigtable和Dynamodb這兩篇論文的細節是如何實現的。
如果你想要鑽研，你可以看Cassandra在單機上是怎麼實現LSM的，這是很多分佈式數據庫都採用的一個結構。簡單說，就是把熱數據寫到memtable，然後數據會定期被flush到sstable。這個結構在很多OLAP和OLTP引擎中都有用到，非常常見。
了解Cassandra之後，你可以以Cassandra為跳板，進一步了解更多其他流行的分佈式數據庫的底層實現，也就是可以舉一反三。這對你之後學習其它的數據庫都會很有益處。
闕乃禎
前面兩位老師講得很好，我再補充一點。Cassandra上手很快，像是DataStax Getting Started的demo，隨便調一調可能只要1-2個小時。而Cassandra從集群搭建起來到庫表的增刪改查語句都能跑通，這個過程非常快，這會讓你很快就有成就感。
另外Cassandra的運維相較HBase一類的數據庫來說比較簡單，對於初創公司來說，如果沒有充足的運維人員，開發人員就得又當爹又當媽，可能用Cassandra就比較合適，公司也能節約一些成本。
第三點就是國內的招聘網站上可以看到越來越多崗位的招聘需求會提到有Cassandra一類的數據庫的使用經驗。我相信如果你有這方面的經驗，這會對你找工作有一定的幫助。
鄧為
我有一些粗淺的想法，想要做一些補充。一方面，Cassandra作為一個流行的數據庫，如果你的工作中本來就要用到，那麼你當然有理由去學習和精通。但是最重要的，就像欒老師說的，Cassandra其實是把分佈式系統中比較重要的理論和比較精華的算法都做了工程上的實現。
另外Cassandra這種無主(masterless)架構在傳統的數據庫中其實是很難實現的，Cassandra不僅能夠實現這種架構，還能在實際生產環境中被很多大公司採用並應用於很多核心業務，摸爬滾打十多年的時間，這充分證明了這些分佈式系統理論和算法的實用性。
如果你把Cassandra吃透，你再去看很多其他的分佈式系統，包括最新的數據庫和分佈式系統，你會覺得很多常用概念其實是一通百通。所以即使你是個學生，只是抱着學習的目的來了解Cassandra，以後你再學習其他的高並發、低延遲、大數據量的分佈式數據存儲平台，你就會有一個很好的基礎。
另外Cassandra這個技術本身也在與時俱進。比如針對Kubernetes，現在社區就有很多新的動作，想把Cassandra打造成雲原生、混合雲和跨雲環境下的大規模數據的分佈式數據庫的默認選項。因為社區非常活躍，緊跟各種新技術的發展，這個技術就能一直保持活力，不容易過時。所以你現在投入的時間在五年後、十年後還是會有助於你的工作和事業。
—
Q：你們在系統學習Cassandra時會用到什麼樣的資源？如果工作中碰到問題，你們去哪裡尋找答案呢？
欒小凡
一般我的學習渠道主要是兩個。
因為我是做研發的，所以我會看社區和DataStax的文檔和jira issues，以便了解最近社區在做的功能、修補的bug以及準備release的東西。我也會去看大家的討論，可以從社區大牛的討論中汲取經驗、獲取靈感。
第二個部分我會從源碼入手，比如當我在日常運維中發現問題或有不理解的地方，我可能會直接切入源碼。Cassandra的源碼是開源且相對規範的，所以在看源碼的過程中，我不僅對Cassandra有更深的理解，也學習到大家使用Java這門語言的小技巧。
至於我們剛才提到的certification，我覺得還是很有必要的。尤其是在你剛剛進入這個行業的時候，針對證書考試的學習能夠幫助你快速成長，並且可以增加大家對你的認可度。
比如我們招聘的時候，有時候還是比較難判斷候選者對於Cassandra的了解程度，或者我們招聘DBA時會想要知道他有哪些技能。像是Oracle也會比較看重相關的證書，因為它是一個比較複雜的系統，有很多可以調優的地方。Cassandra其實也是一樣的，如果你能有一個證書，我們會認為你會Cassandra的運維有一定程度的了解，那我們也會對你優先考慮。
張旭東
我這邊主要是兩個學習渠道。一是因為公司已經在大規模使用Cassandra，而我作為一個使用者，我會看公司同事寫的Cassandra周邊工具和API。二是Cassandra官方文檔。有些東西不能想當然，我們得看文檔里對於每個特性的最佳實踐是什麼，包括像是線程數、key怎麼存儲、key的大小等。這些還是需要細扣文檔。
如果想要系統性學習，我當初看了《Cassandra權威指南》的第二版。這個版本跟Cassandra 3.0有些差距，但是大部分原理還是通用的，所以還是有些幫助的。（《Cassandra權威指南》第三版針對Cassandra 3.x和4.0，關注DataStax微信公眾號並在後台回復【CDC3】即可下載電子版。）
另外關於Cassandra Certification，Dev和Admin兩種我都考了。因為我是先使用了Cassandra幾年，最近才考的這個證書。我感覺Certification里的這些考題和我日常使用Cassandra時需要注意的關鍵點是非常契合的。另外我還和我們team的Cassandra DBA也溝通了一下，問了他們做的事情和遇到的問題。他們的回答和我在Cassandra Certification for Amin這個考試中遇到的題目很相關的。
所以建議大家有時間還是要看一下這個證書考試，至少可以看看DataStax的相關課程，這些都是很有用的。
闕乃禎
我跟大家差不多，主要是看官方的文檔以及大牛的技術博客。學習過程中，還是要多看多實踐，光看不練肯定是沒用的。一般來說，我們都會針對學習的東西或者工作中遇到的問題搭建集群，做一些建模或是壓力測試。通過比較多地進行實踐，我們希望盡量把問題統統暴露出來，然後再通過社區或是博客尋找答案。
如果遇到一些比較難的問題，我可能就直接找鄧為老師了（笑）。還有像是阿里雲的郭超，你們都是比較熱情的，在群裏面提問題基本上都會很快得到你們的解答，效率特別高。
—
Q：SAI是否會對Cassandra將來的使用帶來比較大的變化？
（SAI功能現已在DataStax Enterprise和DataStax Astra中上線，點擊此處詳細了解SAI。）
欒小凡
因為SAI還沒有完全進入社區，所以目前我們還沒將這個功能投入生產使用。但是我們已經看了文檔，對這個功能還是非常期待的。SAI的功能還是很強大的，而且像是我們LSM樹這種模型的寫性能雖然比較好，但是我們所說的local index或是其他index方案都涉及到「寫前讀」的問題。SAI應該能夠比較好的解決這個問題，所以我對它的期待是至少它會較大地提高寫性能。
在讀的方面，SAI的功能也是比較強大的。之前我們需要依賴ES或是外部檢索所做的事情，可能我們就可以比較容易地在Cassandra裏面直接完成了。所以我對SAI的期待是能夠解決一部分不涉及分詞的搜索場景。我們一直在密切關注社區的相關動態，等這個功能正式release，我們也期待我們的用戶能儘快地用上。
張旭東
我們這邊也很期待SAI。正好前兩天我們的Cassandra DBA報了一個問題，有人在使用二級索引（老版本的SASI索引）時遇到了問題，最後也沒用成二級索引。包括這幾年有一些場景我們想用二級索引，但是因為看了官方文檔中提到的限制，所以比較遺憾一直都沒有用起來。總的來說我也是非常期待SAI這個功能，希望它可以早日在社區正式release。
—
Q：Cassandra和ES的結合是否常見？
欒小凡
目前我確實看到這方面的需求，比較常見的是在圈人或營銷的場景下，可能會選擇用ES篩選出一部分人群，然後再用Cassandra回查，拿到他們的具體信息。
第二種常見場景就是消費記錄和聊天一類的場景，這些場景的查詢維度相對較多，尤其在消費記錄那種特別寬的表裏面會有非常多的字段，用戶可能會選擇某幾個字段進行查詢。這種不太確定Schema的查詢對Cassandra本身local index的方案並不是特別友好，當然我們前面聊到的SAI不知道是否能解決這個問題。但目前的話就是把數據在ES里放一份，方便用戶進行查詢。
張旭東
我們這邊主要利用ES的前端檢索功能，比如我們蔚來的APP有一些搜索的場景會需要中文詞的分詞。ES的查詢出結果後，為了性能，我們還會到Cassandra里回查。總的來說就是應用在中文檢索的場景下。
闕乃禎
我們也會用到ES的情況還是挺多的，比如IoT場景對設備信息的檢索，還有一些指令信息和歷史記錄檢索的場景，我們會把原數據放在Cassandra中，但是索引會放到ES上面。
—
Q：在多DC橫跨多地的情況下，你們如何實現備份恢復？
欒小凡
我們確實有關注到用戶這方面的需求。Cassandra本身存儲的可能是比較關鍵的數據，雖然snapshot是一個不錯的功能，但是有時候用戶需要的其實是物理備份。
這種情況下，我們推出了一個我們自己的解決方案，叫BDS。它可以把Cassandra的sstable託管到我們的一些對象存儲上面去，比如AWS的S3或阿里雲的OSS這樣的系統，從而實現硬備份。在這個基礎上，我們也在跟社區貢獻一個叫sidecar的解決方案，本質上可以將其理解為Cassandra的CDC（change data capture，數據改變捕捉）。
我們傳統的拖文件的方案可能會存在一定的時效性(的問題)，比如在內存或commitlog裏面的數據其實是沒辦法快速回放的。如果這時候做恢復的話，可能會存在幾分鐘的gap。如果集群本身掛了的話，有些數據可能就丟掉了。所以如果我們有了CDC的sidecar，我們就有了一個毫秒級的方案。如果大家沒有我們的服務，也可以拉一個CDC的sidecar的組件，然後通過Spark和Kafka實現這種備份方案，實現Cassandra的秒級恢復。
張旭東
我們的備份方案一般通過一些大數據組件，比如研發集群上我們會用全量備份。DBA方面我們還在探索中，比如多DC同步，我們想把AWS的數據同步到騰訊雲時也遇到一些問題，尤其是那種遷移數據。
闕乃禎
我們會把重要的數據通過Kafka同步到ES集群或其他集群中去，其他的數據就用快照(snapshot)的形式備份。像是一些海外對數據本土化要求比較高的，我們會把所有的數據同步到我們的Ceph集群。
