饿了么技术往事（中）( 二 )

按业务功能领域切分——拆库按照访问频率、动静态属性等等规则——垂直分表
基于Hash Partition（需要注意的是避免热点和Rebalance带来的成本）—— 水平Sharding
总之就是选择合适的 Partition 策略，降低数据库单个实例的负载。存储后来能支撑住千万级单量，除了上游队列的削峰、缓存的缓冲、数据库读写分离以外，也得益于适当的 Data Partition 策略。
二、大前端
其他团队还在拼命追赶业务、填坑补课的时候，大前端团队满足业务需求的同时，还为开源社区贡献出了非常优秀的产品 Element 。就在大家认为这支团队会继续在前端领域上一骑绝尘下去的时候，令人没有想到的是，这个团队几年后会爆发出巨大的潜力，成为整个架构体系升级中一个举足轻重的角色。为什么叫大前端，因为他们和传统的前端团队做的事情不太一样，后面会讲到。
体会和教训——找到优秀的工程师多么不容易
招聘优秀的工程师，持续招聘优秀的工程师，这是一句正确的废话。但是有多难，带过团队的应该都深有体会，特别是你的公司还没有自带光环的情况下。优秀的工程师会吸引来更多更优秀的工程师，反之亦然，面试这个过程是双向的，尤其是优秀的工程师。有业务压力的时候，主管很容易扛不住，降低要求。当时大前端团队校招淘汰率还是挺惊人的，换来的是这个团队的工程师很高的技术素养和基本功，为后面成为一个真正的全栈团队打下了的基础。
Leader的个人能力，决定了他（她）是这个团队的地基还是天花板。
三、大数据
基于 Hadoop、Spark、HBase 的经典大数据架构这个时候也搭建起来了，因为是自建的数据中心，所以这些产品都需要有一个专业的团队来运维，因此大数据也有了自己的运维和中间件团队。在这个阶段，在线和离线数据同步、数据治理上面还不完善，因为产品化还在路上，很多工具缺失，导致很多团队都要自己直接去从数仓取数，不得不维持运营团队支撑定制化的手工取数需求。各个团队喊得最多的就是大数据的人不够，想要自己做。核心还是业务发展太快。后面随着大数据团队逐渐壮大，更多强援加入，各个产品相继成熟才得以缓解。
四、风控安全
这是一个不得不说，但是也不能说太多的团队，所以这部分只能务虚一些，任何一个到了一定规模的企业，风控安全团队是“真”底线。其他技术团队在面对这个同样是负责技术的团队面前，有时候确实也挺一言难尽的，这个时候高层的支持至关重要。尤其是从 0 开始建设这个团队，对内的扫盲和对外风控，一样艰难。
如果说一个技术公司，系统毁了，有什么还能留下来，就还能重建，那肯定是数据（现在可能还要加一个算法模型）。有什么缺失了，随时都可能垮掉，那肯定是风控安全。
饿了么的这支风控安全团队，对内、对外、对线上、对线下、对其他……都面临很多挑战和冲突，堪称业务专家的羊毛党和无孔不入的黑客，确实令人叹为观止。而我们的风控也经历了从开始的粗粒度约束、到依赖业务规则针对各种补贴、账期等场景兜底、再到依赖算法模型实时风控主动拦截的阶段。
如果大家身边有做风控安全的同学，请珍惜，哪怕他们有时候看到系统到处是窟窿的时候，脾气暴躁。因为他们整天面对这么多黑暗面，还能对这个世界报以希望。开个玩笑，从人道的角度出发，这个团队需要定期的心理按摩。
【饿了么技术往事（中）】这个阶段，我们初尝了算法的威力。一开始只有搜索，但是还没有推荐召回系统，当时给推荐系统的物理机是我们能拿得出手的最好的物理机，其他业务系统分配的大都是虚机。系统上线以后，效果、转化率都还不错。之后不久这一待遇被另一个团队承包——负责配送履约的智能调度团队，大数据、机器学习、算法模型需要充分发挥功效，需要长时间紧贴业务、深刻理解业务，在智能调度领域我们也做过不少艰难的尝试、吃过不小苦头，直到我们有了自己的算法专家团队。