WOT技术门诊寄语：没有天生的信心，只有不断培养的信心
为大数据和较新的快速数据架构提供基础设施并不是一个饼干切割的问题。两者对硬件和软件基础设施都有着显著的调整或改变。较新的快速的数据架构与大数据架构有着显著区别，并且快速数据提供了真正的联机事务处理工具。理解大数据基础设施建设能够帮助你做出正确的硬件和软件选择。
11月8日 ，链家网大数据资深架构师 赵国贤做客WOT技术门诊第四期群友互动课堂，针对链家网在大数据基础设施建设 ，从最初的技术支持报表需求，到年初的技术实现自助报表需求，到现在的技术搭建平台提供数据分析、数据获取服务所遇到的问题分享了自己的经验。，希望能给更多对大数据基础设施建设感兴趣的小伙伴带来帮助。
赵国贤
现就职链家网资深工程师，负责链家网大数据平台的基础架构方向，专注构建大数据基础平台。2011曾供职于新浪，改造过scribe，把当时的全网的行为数据收集方式从离线改造为实时收集，参与了大数据平台从无到有的整个发展历程，负责了当时新浪的实时数据统计系统storm并改造部分统计需求，极大提升了数据的实时性，2013年供职于搜狗数据分析平台高级工程师，建立一套完备的数据平台，支撑了公司的数据需求。
以上语音主要分三块介绍：大数据的演进、大数据的架构、大数据安全，重点介绍数据安全遇到的一些具体的问题。
以下为语音直播实录：
1.介绍链家网大数据的演进之路
链家已经成立十五年，线下经纪人13万名，围绕的线下房产交易，有大量的运营需求需要数据支撑，分城市、分商圈、分门店的情况都需要细分。所以，在链家网成立初期，集团运营数据需求就已经有了，故在2015年初就搭建了第一套系统来支持数据报表，逐渐围绕着上层需求，构建起了链家网大数据架构。也是在那时，成立的大数据部门，为公司做好数据支撑。链家已经成立十五年，线下经纪人13万名，围绕的线下房产交易，有大量的运营需求需要数据支撑，分城市、分商圈、分门店的情况都需要细分。所以，在链家网成立初期，集团运营数据需求就已经有了，故在2015年初就搭建了第一套系统来支持数据报表，逐渐围绕着上层需求，构建起了链家网大数据架构。也是在那时，成立的大数据部门，为公司做好数据支撑。
2.介绍链家网大数据的架构
链家网大数据从最初的技术支持报表需求，到年初的技术实现自助报表需求，到现在的技术搭建平台提供数据分析、数据获取服务，这正是链家网大数据这一年多所经历的，其中涉及到的架构变迁、新技术方案的引入、大数据平台化等等，链家网大数据的架构。
3.链家网大数据的数据安全
链家网是一家极其重视数据的公司，更加重视数据安全，大数据部门无论从上层的API服务，中间层的工具链、一直到底层的基础平台集群都有都有相应的权限控制和认证方案，我们采用分层的方法保证数据安全，防止渗透。采用最小可用的原则让需要的人接触到需要的数据，但是不会过度授权。另外数据安全是一个比较大的议题，包括服务的认证、用户的授权、数据的加密等，如果发散讲的话，我估计一天也讲不完，下面我重点介绍一下链家网大数据集群的数据安全方案以及遇到的一些坑，集群我们采用开源的Hadoop、Spark、以及一些相应的组件，比如Hive、Presto、HBase等，基本上所有的存储、计算都会在集群内完成，这就对集群的安全提出非常大的挑战，经过前期的调研和实践，当前我们主要采用Kerberos + 基于自研的权限分配方案 + 自研的审计功能，Kerberos主要解决机器与服务的认证、自研的权限分配方案主要解决用户的授权、自研的审计功能主要解决记录谁使用了集群都做了什么。当然在实践安全方案的过程中，我们也遇到各种各样的问题。下面简单列举几点给大家分享一下
1)kerberos本身的复杂性
Kerberos是一种网络认证协议， 其设计目标是通过密钥系统为客户机 / 服务器应用程序提供强大的认证服务。该认证过程的实现不依赖于主机操作系统的认证，无需基于主机地址的信任，不要求网络上所有主机的物理安全，并假定网络上传送的数据包可以被任意地读取、修改和插入数据。在以上情况下， Kerberos 作为一种可信任的第三方认证服务，是通过传统的密码技术(如：共享密钥)执行认证服务的。我们这边也用了一段时间去熟悉kerberos的认证流程，实现Kerberos的HA方案等，这里也建议如果想启用Kerberos的用户一定要弄清楚kerberos的认证流程，这样实现安全方案的时候会事半功倍。
2) 安全Yarn使用Linuxcontainer
链家使用的是基于Hadoop2.4.1的定制开发版本，安全集群的Yarn必须使用Linux Container，但是 Container-executor 和 Container-executor.cfg 必须 做特殊的权限配置，对运维提出更高的要求。
3) datanode的启动方式
Datanode必须使用JSVC启动，并且启动的Datanode必须有Sudo权限，因为安全Datanode使用低于1000的端启动的，但是Hadoop2.6.1的版本以后就不存在这个问题，链家这边也在考虑升级到Hadoop2.6.1版本上。
4) 集群的组件多，Hive(HiveServer2、Metastoreserver)、Oize、Spark等，需要逐一的测试保证平滑的过渡。
5) 刚才在第四点的时候我们谈到平滑过渡，是指从无安全的集群过渡到有安全的集群，比较突出的问题是保证业务的平滑过渡和保证集群的平滑升级，这里给出的建议是在确保安全方案的执行性，平滑过渡性的同时，一定要保证准备好完备的Rollback方案。
6) kerberos的过期失效问题
我们现在采用的方案是定期刷新Ticket sss，另外在加上一点就是关于数据加密的问题，因为数据加密的话就会对易用性等产生影响，链家这边得规划是对数据分层管理，根据不同的层级选择不同的加密措施来保证数据的安全。
公告：以下为11月8日 WOT技术门诊群 交流互动内容
问题一：您认为在云上开发大数据平台可能会面临哪些技术难点，特别是在稳定性和高可用方面，您有哪些好的建议?
关于在云上开发大数据平台，现在无论是Aws还是阿里云都提供了大数据的相关组件，能够比较容易的组建公司的底层数据平台，可能谈不上技术难点，比较关键的是云平台都会依赖相关的云的相关组件，比如AWS的EMR可能和s3结合起来会更容易使用，另外就是大数据平台都会根据业务做专有化定制开发与底层优化。云上也比较难于实现各种组件的灵活搭配。稳定性和高可用方面的话，大部分云厂商都会提供高稳定性和高可用的保证，这里提供的经验就是，一定要自己在上层或者其他方法实现内部的高可用方案。
问题二：像搭建链家这样的地产大数据架构时，数据结构和类型有什么样的特点?您如何进行数据存储架构的选型?
和其他公司相通性的就是数据都有行为数据与业务数据，但不同点就是业务数据更复杂，维度更多，比如商圈、门店等等，另外就是我们对数据的实时性要求更高，维度的组合更多，在选型上我们既有传统的MySQL、也有列式存储HBASE，也有部分的ES来解决我们的业务需求。
问题三：更新、查询都比较频繁的大增量数据时如何存储?每天会新增10G+吧，ES的话，更新会造成大量的版本数据，造成冗余;关系型数据库的话，感觉数据量一大，查询、更新效率是个问题。HBase可行吗?之前用HBase时rowkey设计考虑写负载，导致spark读取很慢。
我觉得这种场景首先要做一下压测看一下，系统的瓶颈在哪里，是由于网卡的压力大，还是磁盘IO大，还是内存的压力等等，只有有了这些压测数据，我们才能够知道我们的存储系统的瓶颈在哪里，你所说的rowkey设计考虑写负载，导致spark读很慢，也如上所说系统的瓶颈在哪里，才能够基于瓶颈做优化和提升性能，另外我们专门做过HBase的优化，通过做二级缓存、升级ssd等来提升HBase的性能，还得根据业务的特点做一些优化，你所说的这种场景HBase是完全能够满足需求的。
【本文由赵国贤于2016年11月8日，在WOT技术门诊第四期《大链家网大数据基础设施建设》语音直播分享以及和群成员答疑互动的内容整理而成。如需转载请注明出处为WOT】
