活动精彩实录 | Cassandra与职业发展

大家好，目前我在阿里云做数据库研发。我接触Cassandra比较早，属于机缘巧合。在接触Cassandra之前，我对分布式系统并不是特别了解。后来在学习像Cassandra这样的分布式系统之后，我就对分布式系统产生了兴趣。

正好那时想要创业，而且认识了Cassandra的作者Avinash。与他聊过之后，我决定加入他的团队。在这个团队中，我主要是基于Cassandra做了一个分布式的存储系统Hedvig，这个存储系统后来成为了很多银行的数据备份方案。

从做Cassandra开始，我最开始的定位主要还是做数据库的研发，当时也给社区贡献了一些bug fix。后来2016年回国后，我逐渐开始兼顾研发和运维两个方面的职责。尤其是最近一年做了更多运维工作，比如帮用户设计他们自己的系统。

在这个过程中，我对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的业务数据量都比较大，用户也比较多，但是没有人专职负责。所以如果生产或者集群出现问题，我都是兼职帮忙解决一下，包括运维和技术指导。

因为我们本身提供托管服务，跟其他两位嘉宾相比，我们的业务可能会更杂一些。

整体来讲，我觉得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在内的很多运维工作。

我主要从两个角度来谈这个问题。

第一，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打造成云原生、混合云和跨云环境下的大规模数据的分布式数据库的默认选项。因为社区非常活跃，紧跟各种新技术的发展，这个技术就能一直保持活力，不容易过时。所以你现在投入的时间在五年后、十年后还是会有助于你的工作和事业。

一般我的学习渠道主要是两个。

因为我是做研发的，所以我会看社区和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的相关课程，这些都是很有用的。

我跟大家差不多，主要是看官方的文档以及大牛的技术博客。学习过程中，还是要多看多实践，光看不练肯定是没用的。一般来说，我们都会针对学习的东西或者工作中遇到的问题搭建集群，做一些建模或是压力测试。通过比较多地进行实践，我们希望尽量把问题统统暴露出来，然后再通过社区或是博客寻找答案。

如果遇到一些比较难的问题，我可能就直接找邓为老师了（笑）。还有像是阿里云的郭超，你们都是比较热情的，在群里面提问题基本上都会很快得到你们的解答，效率特别高。

点击“阅读原文”至DataStax技术博客查看完整活动精彩实录以及活动视频录像，了解活动参与者的提问以及更多详细信息。