|
继续整理诸葛io创始人&CEO孔淼在AWS技术峰会2017上的演讲《 数据驱动企业商业价值增长》下篇，上篇传送门 今天重点解读诸葛io技术架构的优势以及大数据分析模型。 1、“多租户”式平台同时支持很多百亿级大型应用，直面高并发面临的挑战且保证高速响应，实时准确。 2、找到用户与设备的关系，透过设备来追踪背后真正的用户 3、真实的用户会话采集，绝非通过规则“人为切割”会话（session） 海量数据并发「无压力」用户会话真实「不切割」点击图片查看大图 ➤数据收集端 诸葛io的数据采集采用的是LVS+Nginx+Lua，而不是简单的Nginx，之所以这样设计是因为： -我们的“多租户”平台要同时支持很多大型应用，例如“墨迹天气”，“Flipboard红板报”等大数据量的数据上传； -我们是率先采用https协议的数据采集分析平台，所以比http高并发面临的挑战会更大； -我们要保证高响应的速度； 此外，诸葛io的私有部署也同时支持该架构，保障用户数据上传的实时性，准确性。 ➤数据分析模型 诸葛io的数据分析模型更高级，我们的模型是“用户-触点（设备）-会话-事件”： a. 会话是行业分析的标准，我们的模型基于实时还原用户会话场景，而不是通过“规则”来人为切割； b. 诸葛io对“用户”的判断一直以来都是行业比较领先的规则，传统的“用户”其实是“设备”，而我们能找到用户与设备的关系，透过设备来追踪背后真正的用户，包括不限于： -用户注册前的匿名行为与注册后行为的关联 -单用户的多设备（跨平台）行为关联 -单设备多用户的行为还原 为了支持这样的数据模型，我们需要更复杂的服务端逻辑处理，Codis是领先的Redis分布式组件，让我们的实时匹配更可扩展，而SSDB是兼容Redis协议的硬盘存储，支持海量的关系存储。 ➤基础存储、索引、OLAP 诸葛io同时支持SaaS和私有化部署，所以有统一的ETL以及差异化的数据存储和查询引擎，基础存储基于S3和HDFS。Redshift是很多硅谷最顶尖的公司都使用的技术，包括Airbnb, Yelp, Pinterest等等，我们致力于给国内客户提高更高品质的云端分析能力，所以也采用了更好的基础设施。 站在AWS的肩膀上诸葛io依托AWS可灵活拓展的云计算平台，可降低持续成本，无需购买服务器等前期设备，快速实现数据应用，缩减基础设施成本及时间成本；企业搭建大数据平台的目的是应用而不是运维，所以诸葛io通过AWS平台降低企业运维成本；此外为了便于诸葛io在其他方面的探索，比如在AI方面进行探索，通过AWS平台提供的AMI可极大地降低研发成本。 总之，基于AWS平台弹性化的丰富功能，更人性化的设计方案，更高质量的全球服务，为诸葛io提供了优质的基础设施服务： 1、功能丰富 AWS的功能非常丰富，除了EC2作为基础机器之外，PaaS方面，我们使用了EMR/ S3/Redshift等组件，小的功能方面，还包括AMI镜像备份恢复，用户的IAM权限分配，Instance机器种类和外置磁盘EBS的选型，分布式S3的文件存储功能以及工作中产生的业务需求等。 2、弹性化 诸葛io在搭建基础设施之初，就以满足海量数据规模计算为目标，随着诸葛io每年企业客户呈指数级的增长，再次证明最初的坚持是正确的。 海量数据并发，当系统负载、QPS偏高时，常出现CPU利用率达到100%的情况，此时诸葛io即可通过调用AWS API接口来实现弹性扩容，包括主机的分配、流量的分配、IP的绑定、域名解析的配置以及存储服务等。 3、全球服务 能够在节约成本的前提下，非常方便的进行扩容和Hadoop/Spark数据计算，在全球部署自己的数据中心，帮助诸葛io为全球企业客户提供服务。 ➤Amazon EMR Amazon EMR 是一种 Web 服务，它能让企业、研究人员、数据分析师和开发人员能够轻松、经济高效地处理海量数据。 大数据平台基于Hadoop，技术复杂度非常高，对诸葛io而言，底层的运维压力和成本压力非常大。因为动辄一个客户可能就是数百TB级的数据，我们必须选择非常灵活、低成本的方式来支撑业务，所以我们选择EMR。 此外，Hadoop有很多发行版，在选择不同的Hadoop版本时，EMR帮助诸葛io更快捷地筛选适合我们的发行版套餐，Hadoop在组件的更新和支持上非常迅速，帮助诸葛io及时跟进最新技术来调整方案。 基于Amazon EMR易操作，易于设置集群/Hadoop/节点、在重试失败任务等方面具有很高的可靠性、允许任何规模处理数据来灵活控制成本支出、通过自动配置Amazon EC2防火墙设置保证数据安全，灵活自定义群集，使用成本的优势，为诸葛io搭建一个强大的技术支持。 ➤EMR & S3 有效结合 采用AWS的S3（数据采集平台）存储数据，可对分散的数据进行有效的集中管理，满足对不同框架的输入需求，甚至支持Redshift的直接查询，而且有高持久性。在诸葛io的实际运用中，通过将EMR与S3的有效结合，降低数据传输成本，增加数据存储能力扩展性，增强计算能力的扩展性，提高伸缩响应速度，摊薄存储与计算成本。 ➤Redshift 随着诸葛io的客户越来越多，Greenplum的方案已不再适合SaaS服务，因为它虽然查询性能很好，可一旦海量并发时便遇到性能瓶颈。 在研究国外架构时，Redshift是airbnb等很多知名公司的选择，所以，在尝试后我们发现Redshift的确是基于数据仓库优化，包括基于S3之后在海量数据加载和计算时有非常不错的表现，另外，考虑到业务方案和基础架构，诸葛io也选择了兼容性和适配性更好的Redshift。 此外，Redshift可以利用现在使用的 SQL 语法和 BI 工具，对 Amazon S3 中的 EB 级数据进行查询，二者范围内可进行无缝查询，具有极高的扩展性；通过 AWS 管理控制台或 Amazon Redshift API 使用任何系统快照或用户快照来恢复群集，系统元数据恢复后，群集就可供使用，并且可在用户数据在后台输出时开始运行查询，具有快速恢复能力；在未使用Redshift之前主要使用Greenplum作为数据仓库，二者都是基于postgresql，数据迁移到新数据仓库后对应用中查询改动量较小，平滑迁移，更易于迁移。 大数据的技术发展势不可挡，大数据技术的发展将会越来越多样化，企业必须跟上技术发展趋势并结合数据与价值输出。随着更为复杂的用户需求涌现，精细化数据分析将成为驱动企业业务增长的关键功能。 诸葛io围绕这些趋势所产生的问题，结合用户-触点（设备）-会话-事件模型，提供了一站式的数据分析解决方案，从数据接入到自助式的场景分析，最后再将底层进行清洗和整合过的数据，完整开放给企业，以便实现企业数据相关价值的挖掘。 诸葛io以用户跟踪技术和简易集成开发的方法，帮助移动应用的运营者挖掘用户的真实行为与属性，帮助互联网产品更快、更简单的通过数据驱动产品分析从而实现业务增长，商业价值的提升。 Ps.昨天的回应，有小伙伴称我们“太软弱太面了”； 也有小伙伴误会了另一家，让另一家友商躺枪的； 还有小伙伴表示“路转粉”，夸我们大气，或者夸我们“打赢了口水仗”， 其实归根结底不过是双输。 所以无论是第一时间直言相告，或是仗义转发，还是为我们出谋划策鼓励我们走诉讼程序的小伙伴，诸葛君感谢大家的支持，但是此事希望就此翻篇，谈到诸葛君时我们希望是业务场景深刻理解方面的认同，或对专业服务方面的嘉奖，而不仅仅是“企业格局”。 再Ps.这些委屈不算什么，真正让市场君心疼的，是我们的运营小哥，也是一位聪明好学且认真负责的年轻人，帮助中心的文档就是他主导整理的。虽然大家都让他别往心里去，但他还是熬夜对比了所有友商的文档，今天早上一脸沮丧的跟我说，“xx姐我看过了，只有这一段话有雷同，这段话是我们之前的材料里一直在用的，我没注意，就直接整理进了帮助中心文档，对不起给公司惹了麻烦。”2000多页的文档整理起来并不容易，他一定下了不少苦功夫，而喜悦成果上线还不到24小时，就因为采用了一个一样的“通用的技术名词解释”就否定了其他2000多页的工作。这样以偏概全的恶意诋毁，伤害了这样一个无辜的年轻人，我认为友商欠他一个道歉！ 再再Ps.故意抄一段技术词描述？怎比得上友商对产品功能方面的抄袭，昨天的推文文末列举了两年来一些创新功能的上线时间，有心人不妨对比两家类似功能的上线时间，谁是“追随者”不言自明。 再再再Ps.今年3月份wuli孔淼大大转给我一份邮件，就是昨天的邮件贴图，让我们各自检查下。当时我就跟老板说，你太太太单纯了，看着吧，肯定这个邮件早晚会截图贴出来。老板一脸呆萌“我回了邮件说自查一下，是不是上套了？”我说你不回复他们也会贴出来，表示“多次与你沟通未取得回应”，有心为之防不胜防。如今，市场君该夸自己料事如诸葛？ 再再再再Ps.友商老板和wuli孔淼大大的最近一条微信还是在去年6月，称“还是要正常的竞争就可以了，还是要避免撕逼”，那就当做友商最近接二连三挑起的事端并不是桑老板授意的。 回到刚才的话题，我不知该怎么告诉一个年轻人“人性本恶”，但我真心觉得我们新的文档很棒，无论是逻辑架构、还是呈现方式，以及详实度，都是在赞赞哒！另外，帮助中心的基础分析功能都有指导视频，声音和操作都来自于这位诸葛君哟！支持他就去听一听然后在线留言给他吧！（有不明白的地方也可以问他嗷~） |
|
|
